Re: Move KDED out of frameworks?
El Divendres, 28 de març de 2014, a les 20:55:02, Boudewijn Rempt va escriure: On Fri, 28 Mar 2014, Kevin Krammer wrote: The D-Bus session/user daemon is also something that needs to be treated in a platform specific way as a dependency. E.g. on Windows there could be a D-Bus installer that applications bundle and run if necessary, very much like Games bunlding an DirectX installer. Oh no, I never would do that... It would still cost me many hours of my life dealing with it, and it would still give my users no advantage at all. There just isn't any reason an application like Krita would need an ipc solution -- and any library that insists on coming with one is just not going to make the cut. (Heck, it's just like sycoca... That thing has cost me weeks of my life, all totted up, and has not delivered anything useful at all.) That's a really not helpful nor constructive sentence. Cheers, Albert ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Move KDED out of frameworks?
On Saturday, 2014-03-29, 01:21:24, Aleix Pol wrote: On Fri, Mar 28, 2014 at 9:14 PM, Kevin Krammer kram...@kde.org wrote: I thought I was obvious that I was addressing the Aleix's concern about portability of frameworks requiring D-Bus, but I must have failed at that. I'll try to make it more clear: a framework that can be built on a platform, run on that platform and provide its functionality on that platform can be considered supported on that platform. And, additionally, the whole point of having different frameworks is the ability to choose which ones to use, which at least for me implied not having to use a framework that does not provide any features an application needs. Cheers, Kevin Well, I think that what Boudewijn means is that even though we can use DBus on Windows, we might not really want to. Not only for deployment constraints but also because then you need to take care of having it running and management. It can be more of a promo statement more than actual technical advice, but I prefer happy users of few frameworks than slightly frustrated users of many frameworks... I am not saying that we have to use D-Bus in frameworks that require out-of- process components, we can of course always use a hand crafted communication mechanism based on QLocalSocket/-Server, even on platforms that have D-Bus as part of the system installation. I am just saying that frameworks using D-Bus can be used on more platforms than just Linux. All frameworks with dynamic dependencies need to have deployment documentatation. Whether that is bundling a D-Bus installer or bundling plugins and setting custom search paths or bundling a plugin installer. And, most importantly, it is the application developer's choice which frameworks they need and which just optionally use on certain platforms. I just don't see a point in telling application developers that a certain framework is not available on certain platforms when in fact it is but some application developers might chose not to use it due to deployment requiremens. Qt doesn't restrict its supported platforms to Linux just because that is the platform where it comes pre-installed. If a platform without system Qt is widely used there can even be initiatives to remedy that somewhat, like Ministro does on Android. In other words, I don't think it's enough to be able to build and run. I think that it's fundamental also to be able to deploy it and provide an seamless and integrated experience to the user. Of course, I never stated anything to the contrary. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Move KDED out of frameworks?
Hello, On Thursday 27 March 2014 23:25:24 Àlex Fiestas wrote: First of all sorry for sending this email so late in the release process, but today has been the first day in months that I have been able to work fully concentrated on Frameworks. KDED is a weird framework, while it is a solution it is still really tied to what was once known as KDE, just to mention a few things: -It always registers org.kde.kded5 in the bus, allowing only 1 instance -It plays a role in startkde startup sequence -It checks for KDE session for loading or not some modules -Manages sycoca freshness -Integrates with ksplash -... So for the moment I'd like to move KDED into kde-workspace (not into the repo but in the git structure) until we clean and remove all ties to KDE and make it more of a solution for any desktop. Since it does not install any header (kdbusaddons does it instead) we won't break anything with it. What do you think? I admit it somewhat bothered me a couple of times too... I think you are right, it is more a runtime part of the workspace and doesn't really makes sense as a framework. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Move KDED out of frameworks?
On 27/03/14 22:25, Àlex Fiestas wrote: Hi there First of all sorry for sending this email so late in the release process, but today has been the first day in months that I have been able to work fully concentrated on Frameworks. KDED is a weird framework, while it is a solution it is still really tied to what was once known as KDE, just to mention a few things: -It always registers org.kde.kded5 in the bus, allowing only 1 instance -It plays a role in startkde startup sequence -It checks for KDE session for loading or not some modules -Manages sycoca freshness -Integrates with ksplash -... So for the moment I'd like to move KDED into kde-workspace (not into the repo but in the git structure) until we clean and remove all ties to KDE and make it more of a solution for any desktop. Since it does not install any header (kdbusaddons does it instead) we won't break anything with it. What do you think? In principle, I agree. In practice, a lot of our frameworks have a runtime dependency of some sort on it.[0] Alex [0]: http://lxr.kde.org/search?v=kf5-qt5_filestring=_string=kded5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Move KDED out of frameworks?
On Friday 28 March 2014 11:30:25 Alex Merry wrote: In principle, I agree. In practice, a lot of our frameworks have a runtime dependency of some sort on it.[0] Alex [0]: http://lxr.kde.org/search?v=kf5-qt5_filestring=_string=kded5 I can't talk for other frameworks but in the case of Solid it is a mistake since it makes code that is cross-platform not cross-platform anymore. During the next week I will either remove that or make it platform specific (kde integration). signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Move KDED out of frameworks?
On Fri, Mar 28, 2014 at 12:32 PM, Àlex Fiestas afies...@kde.org wrote: On Friday 28 March 2014 11:30:25 Alex Merry wrote: In principle, I agree. In practice, a lot of our frameworks have a runtime dependency of some sort on it.[0] Alex [0]: http://lxr.kde.org/search?v=kf5-qt5_filestring=_string=kded5 I can't talk for other frameworks but in the case of Solid it is a mistake since it makes code that is cross-platform not cross-platform anymore. During the next week I will either remove that or make it platform specific (kde integration). Well yes, actually we should (re-)consider whether frameworks that depend on QtDBus in general if they're cross-platform or not. [1] Aleix [1] http://www.proli.net/2014/03/19/kde-sdk-next-how-will-we-develop-in-a-year/ ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Move KDED out of frameworks?
On Friday, 2014-03-28, 12:54:42, Aleix Pol wrote: On Fri, Mar 28, 2014 at 12:32 PM, Àlex Fiestas afies...@kde.org wrote: On Friday 28 March 2014 11:30:25 Alex Merry wrote: In principle, I agree. In practice, a lot of our frameworks have a runtime dependency of some sort on it.[0] Alex [0]: http://lxr.kde.org/search?v=kf5-qt5_filestring=_string=kded5 I can't talk for other frameworks but in the case of Solid it is a mistake since it makes code that is cross-platform not cross-platform anymore. During the next week I will either remove that or make it platform specific (kde integration). Well yes, actually we should (re-)consider whether frameworks that depend on QtDBus in general if they're cross-platform or not. [1] D-Bus does run on most platforms, at least on desktop. There was a thread on the Qt development list a short while ago which discussed enabling QtDBus by default in Windows and Mac builds. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Move KDED out of frameworks?
On Fri, 28 Mar 2014, Kevin Krammer wrote: The D-Bus session/user daemon is also something that needs to be treated in a platform specific way as a dependency. E.g. on Windows there could be a D-Bus installer that applications bundle and run if necessary, very much like Games bunlding an DirectX installer. Oh no, I never would do that... It would still cost me many hours of my life dealing with it, and it would still give my users no advantage at all. There just isn't any reason an application like Krita would need an ipc solution -- and any library that insists on coming with one is just not going to make the cut. (Heck, it's just like sycoca... That thing has cost me weeks of my life, all totted up, and has not delivered anything useful at all.) I know that for me, as a developer, I could use ipc to coordinate settings changes and check whether autosave files belong to another running instance of the application, but it still isn't worth the effort. I also know that for other applications it's essential, but dbus won't help anyone make better paintings more expeditiously, and, really, is all that my project is about. Boud ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Move KDED out of frameworks?
On Friday, 2014-03-28, 20:26:59, Boudewijn Rempt wrote: On Fri, 28 Mar 2014, Kevin Krammer wrote: D-Bus does run on most platforms, at least on desktop. There was a thread on the Qt development list a short while ago which discussed enabling QtDBus by default in Windows and Mac builds. It might 'run' -- but I still wouldn't want to distribute any application that uses dbus on windows or osx. In fact, for krita on Windows, I've hacked kdelibs 4 to disable dbus completely, and I'd do the same for osx, if I had the time. Just answering the questions of the people who get worried by their firewalls or other security software reporting DANGER! because dbus tries to make a local network connection is already too much of a pain. I know, that is currently a problem of the Windows port, i.e. it using TCP instead of named pipes which are more an equivalent to Unix sockets. (as evident by QLocalSocket/-Server using that instead). The D-Bus session/user daemon is also something that needs to be treated in a platform specific way as a dependency. E.g. on Windows there could be a D-Bus installer that applications bundle and run if necessary, very much like Games bunlding an DirectX installer. Such a D-Bus installer would also register a startup hook that runs D-Bus on session start or user login, whatever makes sense for the platform. Frameworks that need D-Bus, e.g. KIO would then have the D-Bus installation as a deployment requirement. As with all frameworks it is up to the application developer which one they want to depend on and which one they treat as options. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Move KDED out of frameworks?
On Friday, 2014-03-28, 20:55:02, Boudewijn Rempt wrote: On Fri, 28 Mar 2014, Kevin Krammer wrote: The D-Bus session/user daemon is also something that needs to be treated in a platform specific way as a dependency. E.g. on Windows there could be a D-Bus installer that applications bundle and run if necessary, very much like Games bunlding an DirectX installer. Oh no, I never would do that... It would still cost me many hours of my life dealing with it, and it would still give my users no advantage at all. There just isn't any reason an application like Krita would need an ipc solution -- and any library that insists on coming with one is just not going to make the cut. I thought I was obvious that I was addressing the Aleix's concern about portability of frameworks requiring D-Bus, but I must have failed at that. I'll try to make it more clear: a framework that can be built on a platform, run on that platform and provide its functionality on that platform can be considered supported on that platform. And, additionally, the whole point of having different frameworks is the ability to choose which ones to use, which at least for me implied not having to use a framework that does not provide any features an application needs. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Move KDED out of frameworks?
On Fri, Mar 28, 2014 at 9:14 PM, Kevin Krammer kram...@kde.org wrote: On Friday, 2014-03-28, 20:55:02, Boudewijn Rempt wrote: On Fri, 28 Mar 2014, Kevin Krammer wrote: The D-Bus session/user daemon is also something that needs to be treated in a platform specific way as a dependency. E.g. on Windows there could be a D-Bus installer that applications bundle and run if necessary, very much like Games bunlding an DirectX installer. Oh no, I never would do that... It would still cost me many hours of my life dealing with it, and it would still give my users no advantage at all. There just isn't any reason an application like Krita would need an ipc solution -- and any library that insists on coming with one is just not going to make the cut. I thought I was obvious that I was addressing the Aleix's concern about portability of frameworks requiring D-Bus, but I must have failed at that. I'll try to make it more clear: a framework that can be built on a platform, run on that platform and provide its functionality on that platform can be considered supported on that platform. And, additionally, the whole point of having different frameworks is the ability to choose which ones to use, which at least for me implied not having to use a framework that does not provide any features an application needs. Cheers, Kevin Well, I think that what Boudewijn means is that even though we can use DBus on Windows, we might not really want to. Not only for deployment constraints but also because then you need to take care of having it running and management. It can be more of a promo statement more than actual technical advice, but I prefer happy users of few frameworks than slightly frustrated users of many frameworks... In other words, I don't think it's enough to be able to build and run. I think that it's fundamental also to be able to deploy it and provide an seamless and integrated experience to the user. Being cross-platform I think it also means that the user doesn't feel like in a KDE/Linux bubble within his Windows/Mac/Android system. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Move KDED out of frameworks?
Hi there First of all sorry for sending this email so late in the release process, but today has been the first day in months that I have been able to work fully concentrated on Frameworks. KDED is a weird framework, while it is a solution it is still really tied to what was once known as KDE, just to mention a few things: -It always registers org.kde.kded5 in the bus, allowing only 1 instance -It plays a role in startkde startup sequence -It checks for KDE session for loading or not some modules -Manages sycoca freshness -Integrates with ksplash -... So for the moment I'd like to move KDED into kde-workspace (not into the repo but in the git structure) until we clean and remove all ties to KDE and make it more of a solution for any desktop. Since it does not install any header (kdbusaddons does it instead) we won't break anything with it. What do you think? Cheers. signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
