Re: KDE file dialog
On Monday, February 29, 2016 9:42:11 PM CET Sven Brauch wrote: > Hey, > > On 02/28/2016 03:58 PM, Luigi Toscano wrote: > > This is what I use: > > export QT_QPA_PLATFORMTHEME=kde > > > > and you need the integration plugin installed. It used to be part of > > Frameworks (frameworksintegration), it will be part of Plasma (but > > hopefully still usable without). > > It isn't, unfortunately. For example, it requires KSNI support, because > for some weird reason that is part of the platform theme. > > So using QT_QPA_PLATFORMTHEME=kde is basically not a viable solution for > any non-plasma desktop out there. Instead you are stuck with a 3rd party > solution like qt5ct to at least set the Qt / icon theme (color scheme is > quite hard already), and there is basically no viable option to get e.g. > KDE file dialogs back (instead of the unusable Qt5 default ones). > > Quite a step back from KDE 4 times right now, unfortunately :/ I'm a little bit surprised by this sub-thread and the reasoning. Apparently nobody is interested in writing and maintaining a qpt-plugin for non-plasma. The Plasma devs are willing to maintain such a plugin and then get complaints that it focuses on Plasma. Seriously? If you think Qt's default is too bad, improve Qt. If you think it needs a more generic qpt-plugin which can be used outside of Plasma: do it. But don't complain to people doing actual work. Cheers Martin signature.asc Description: This is a digitally signed message part.
Re: KDE file dialog
On Wednesday 02 March 2016 09:42:06 Martin Graesslin wrote: > If you think Qt's default is too bad, improve Qt. If you think it needs a > more generic qpt-plugin which can be used outside of Plasma: do it. But > don't complain to people doing actual work. ^^This -- Marco Martin
Re: KDE file dialog
On Wed, Mar 2, 2016 at 9:42 AM, Martin Graesslin wrote: > On Monday, February 29, 2016 9:42:11 PM CET Sven Brauch wrote: > > Hey, > > > > On 02/28/2016 03:58 PM, Luigi Toscano wrote: > > > This is what I use: > > > export QT_QPA_PLATFORMTHEME=kde > > > > > > and you need the integration plugin installed. It used to be part of > > > Frameworks (frameworksintegration), it will be part of Plasma (but > > > hopefully still usable without). > > > > It isn't, unfortunately. For example, it requires KSNI support, because > > for some weird reason that is part of the platform theme. > > > > So using QT_QPA_PLATFORMTHEME=kde is basically not a viable solution for > > any non-plasma desktop out there. Instead you are stuck with a 3rd party > > solution like qt5ct to at least set the Qt / icon theme (color scheme is > > quite hard already), and there is basically no viable option to get e.g. > > KDE file dialogs back (instead of the unusable Qt5 default ones). > > > > Quite a step back from KDE 4 times right now, unfortunately :/ > > I'm a little bit surprised by this sub-thread and the reasoning. Apparently > nobody is interested in writing and maintaining a qpt-plugin for > non-plasma. > The Plasma devs are willing to maintain such a plugin and then get > complaints > that it focuses on Plasma. Seriously? > > If you think Qt's default is too bad, improve Qt. If you think it needs a > more > generic qpt-plugin which can be used outside of Plasma: do it. But don't > complain to people doing actual work. > > That's always the kind of reasoning FOSS people give. "If you don't like it, provide patches to improve it". I don't really like that argument.. But yes, i even sometimes give that argument if someone wants to have something that i don't like to make ;) I don't think that improving Qt is an option here. Qt has a default simple fallback style. It uses that when there is nothing. I'm not so sure if improving Qt's default to be more fancy would be such a good thing. So lets continue this reasoning with the assumption that the Qt defaults as they are right now remain as is and a plugin has to be written to improve the situation. A question for you and Thiago. @Martin G, would it be acceptable to have two plugins: 1. A basic "KF5" plugin that integrates Qt with KF5 and the plasma style, no other plasma specific stuff besides it's theme. Lets call this "kf5_qpa" 2. A plugin _on_top_of_that_ which integrates with the very specific plasma things. Lets call this "plasma_qpa" @Thiago, how would you write a plugin like that? Can this be done simply by inheriting? So the "plasma_qpa" plugin would inherit from the "kf5_qpa"? Or is there another simpler way of achieving the same goal? @Martin G, if such a plugin is made, would the plasma people use this structure? Since i would hate it if this would end up with two close to identical plugins, one maintained by plasma, one slowly bit rotting away. If it is that "simple" then i'm willing to put some time into it and get it working.
Re: KDE file dialog
On Wednesday, March 2, 2016 11:08:30 AM CET Mark Gaiser wrote: > On Wed, Mar 2, 2016 at 9:42 AM, Martin Graesslin wrote: > > On Monday, February 29, 2016 9:42:11 PM CET Sven Brauch wrote: > > > Hey, > > > > > > On 02/28/2016 03:58 PM, Luigi Toscano wrote: > > > > This is what I use: > > > > export QT_QPA_PLATFORMTHEME=kde > > > > > > > > and you need the integration plugin installed. It used to be part of > > > > Frameworks (frameworksintegration), it will be part of Plasma (but > > > > hopefully still usable without). > > > > > > It isn't, unfortunately. For example, it requires KSNI support, because > > > for some weird reason that is part of the platform theme. > > > > > > So using QT_QPA_PLATFORMTHEME=kde is basically not a viable solution for > > > any non-plasma desktop out there. Instead you are stuck with a 3rd party > > > solution like qt5ct to at least set the Qt / icon theme (color scheme is > > > quite hard already), and there is basically no viable option to get e.g. > > > KDE file dialogs back (instead of the unusable Qt5 default ones). > > > > > > Quite a step back from KDE 4 times right now, unfortunately :/ > > > > I'm a little bit surprised by this sub-thread and the reasoning. > > Apparently > > nobody is interested in writing and maintaining a qpt-plugin for > > non-plasma. > > The Plasma devs are willing to maintain such a plugin and then get > > complaints > > that it focuses on Plasma. Seriously? > > > > If you think Qt's default is too bad, improve Qt. If you think it needs a > > more > > generic qpt-plugin which can be used outside of Plasma: do it. But don't > > complain to people doing actual work. > > That's always the kind of reasoning FOSS people give. "If you don't like > it, provide patches to improve it". > I don't really like that argument.. But yes, i even sometimes give that > argument if someone wants to have something that i don't like to make ;) > > I don't think that improving Qt is an option here. Qt has a default simple > fallback style. It uses that when there is nothing. I'm not so sure if > improving Qt's default to be more fancy would be such a good thing. So lets > continue this reasoning with the assumption that the Qt defaults as they > are right now remain as is and a plugin has to be written to improve the > situation. > > A question for you and Thiago. > @Martin G, would it be acceptable to have two plugins: > 1. A basic "KF5" plugin that integrates Qt with KF5 and the plasma style, > no other plasma specific stuff besides it's theme. Lets call this "kf5_qpa" What is that "kf5" plugin you talk of? Sorry this just does not make sense. The plugin we have (and soon had) in frameworks is setting the defaults for Plasma. There are no generic defaults for frameworks. It just does not make sense. If you think Qt's fallback is not good enough, then improve it. Don't make KDE do that work for Qt. That's thinking like Qt were a closed project. > 2. A plugin _on_top_of_that_ which integrates with the very specific plasma > things. Lets call this "plasma_qpa" Certainly not. > > @Thiago, how would you write a plugin like that? Can this be done simply by > inheriting? So the "plasma_qpa" plugin would inherit from the "kf5_qpa"? Or > is there another simpler way of achieving the same goal? > > @Martin G, if such a plugin is made, would the plasma people use this > structure? Since i would hate it if this would end up with two close to > identical plugins, one maintained by plasma, one slowly bit rotting away. No, because everything in the current plugin is Plasma specific. If we want to change the font, we will do so! We don't want a discussion with "that breaks on Openbox". We doing the work don't care about openbox or whatever. I only see disadvantages here. Cheers Martin signature.asc Description: This is a digitally signed message part.
Re: KDE file dialog
Hey, On 03/02/2016 11:19 AM, Martin Graesslin wrote: > No, because everything in the current plugin is Plasma specific. Meh. In some kind of theoretical view you are right, I do see that. Pragmatically, that's just not true, most of the things in the plugin are not plasma specific at all, for example: colour schemes, Qt style, icons theme, single/double click, file dialogs. All this is exactly as useful in plasma as it is in any other environment, and applies to the exact same set of applications. In fact the only plasma-specifc thing I know about is KSNI. > Apparently nobody is interested in writing and maintaining > a qpt-plugin for non-plasma. There is one, qt5ct, but if you want to make that as useful as the plasma one, you need to reimplement half of systemsettings5 for no real reason. > We doing the work don't care about openbox or whatever. I find that a little surprising. I thought we were building a set of applications that aim to work well in any environment. Right now, kate looks and works _much_ better on Windows than if you start it with the default settings in openbox (you don't even have icons on openbox!). As a developer of kate and as a person doing "the work" there I find that a bit frustrating. Yes, there could be a dedicated platform theme for that, but there's only one sensible thing it can do right in almost all cases, which is "the same as the plasma one". Greetings, Sven signature.asc Description: OpenPGP digital signature
Re: KDE file dialog
On Mittwoch, 2. März 2016 11:19:42 CEST, Martin Graesslin wrote: On Wednesday, March 2, 2016 11:08:30 AM CET Mark Gaiser wrote: On Wed, Mar 2, 2016 at 9:42 AM, Martin Graesslin wrote: ... What is that "kf5" plugin you talk of? The origin of this thread was that the default Qt file dialog sucks, so there's desire for the KIO KFileWidget (but kio is already tier3 ??) The KDE QPA plugin however has some trouble on non-plasma environment (apparently notably on the Systray/SNI part), so it cannot be used outside plasmashell. I *assume* that the core problem is that the plasma QPA isn't sufficiently robust, eg. if the SNI daemon doesn't come up (I once had it crashing here what drove me into the mentioned FD exception through mindless dbus calls - not funny) it should probably give up and resort to letting through the unhooked FDO systray. Imo that's a more issue: IPC is I/O, ie. unreliable. You cannot provide functionality that relies on working IPC, but hard-relying on it is bad design (nb. that the failing kded module make _every_ Qt client using QSystemTray unusable and trying to knock out your system) => fix the QPA to handle I/O (dbus etc.) more robust and everyone's happy? Cheers, Thomas --- If anyone would like to discuss whether pushing SNI or which systray protocol should be used or is better: Spare yor time. I firmly believe that the systray is a completely braindead concept, no matter how it's done. You wanted to go for a backend/frontend implementation itfp.
Re: KDE file dialog
On 03/02/2016 11:56 AM, Thomas Lübking wrote: > Imo that's a more issue: IPC is I/O, ie. unreliable. You cannot provide > functionality that relies on working IPC, but hard-relying on it is bad > design (nb. that the failing kded module make _every_ Qt client using > QSystemTray unusable and trying to knock out your system) > > => fix the QPA to handle I/O (dbus etc.) more robust and everyone's happy? Yes, seems like a good approach to me. I think I fixed part of the crash a while back (b45544f3d4 in knotifications, I think there's another trigger for it somewhere though), but it seemed very hard to fall back to the default system tray icons if KSNI is unavailable :/ signature.asc Description: OpenPGP digital signature
Re: KDE file dialog
On Wednesday 02 March 2016 11:19:42 Martin Graesslin wrote: > > What is that "kf5" plugin you talk of? Sorry this just does not make sense. > The plugin we have (and soon had) in frameworks is setting the defaults for > Plasma. There are no generic defaults for frameworks. It just does not make > sense. > > If you think Qt's fallback is not good enough, then improve it. Don't make > KDE do that work for Qt. That's thinking like Qt were a closed project. improve that one, or make a different one, may sound like a project LxQt people may be interested into as well, wether is maintained in Qt tree or not. That shouldn't stop us wanting a QPA more closely integrated with our own desktop product -- Marco Martin
Re: KDE file dialog
On Wednesday, March 2, 2016 11:46:01 AM CET Sven Brauch wrote: > Hey, > > On 03/02/2016 11:19 AM, Martin Graesslin wrote: > > No, because everything in the current plugin is Plasma specific. > > Meh. In some kind of theoretical view you are right, I do see that. > Pragmatically, that's just not true, most of the things in the plugin > are not plasma specific at all, for example: Let's look at each of your examples: > colour schemes, to be configured in kcm colors, code is in plasma-desktop (part of Plasma) > Qt style, default is breeze (part of Plasma), configured in kcm style, code is in plasma- desktop > icons theme, configured in kcm icons, code in plasma-desktop > single/double click, configured in kcm input, code in plasma-desktop > file dialogs. As someone complaining about GTK file dialogs in Plasma I am very against KDE Plasma file open dialogs used outside of Plasma. On other desktops it should use the file dialog of that desktop. > All this is exactly as > useful in plasma as it is in any other environment, and applies to the > exact same set of applications. No, it's not useful without configuration, which makes it useless without Plasma. > In fact the only plasma-specifc thing I > know about is KSNI. no it's not. What about setting the look'n'feel package, the setting of breeze as widget style, the integration for KWin/Wayland? That's all Plasma specific. > > > Apparently nobody is interested in writing and maintaining > > a qpt-plugin for non-plasma. > > There is one, qt5ct, but if you want to make that as useful as the > plasma one, you need to reimplement half of systemsettings5 for no real > reason. ah but systemsettings5 is also part of Plasma. > > > We doing the work don't care about openbox or whatever. > > I find that a little surprising. I thought we were building a set of > applications that aim to work well in any environment. yes our applications should work great in any environment without relying on Plasma being installed! > Right now, kate > looks and works _much_ better on Windows than if you start it with the > default settings in openbox (you don't even have icons on openbox!). As > a developer of kate and as a person doing "the work" there I find that a > bit frustrating. then fix Qt to load the icons properly! There is no magic "break things outside Plasma" in frameworks. Seriously: if it doesn't work without workarounds added by Plasma it's a severe bug which needs to be fixed. > > Yes, there could be a dedicated platform theme for that, but there's > only one sensible thing it can do right in almost all cases, which is > "the same as the plasma one". If that's the case it should be the default in Qt. If there is only one sensible way, the Qt default is not sensible and should be changed. Let's fix Qt, not workaround bugs with a KDE powered QPT plugin! Cheers Martin signature.asc Description: This is a digitally signed message part.
Re: KDE file dialog
On Wednesday, March 2, 2016 12:09:17 PM CET Sven Brauch wrote: > On 03/02/2016 11:56 AM, Thomas Lübking wrote: > > Imo that's a more issue: IPC is I/O, ie. unreliable. You cannot provide > > functionality that relies on working IPC, but hard-relying on it is bad > > design (nb. that the failing kded module make _every_ Qt client using > > QSystemTray unusable and trying to knock out your system) > > > > => fix the QPA to handle I/O (dbus etc.) more robust and everyone's happy? > > Yes, seems like a good approach to me. I think I fixed part of the crash > a while back (b45544f3d4 in knotifications, I think there's another > trigger for it somewhere though), but it seemed very hard to fall back > to the default system tray icons if KSNI is unavailable :/ Just saying: I wrote that SNI integration and I have never heard of that problem before Sven mentioned it here. Cheers Martin signature.asc Description: This is a digitally signed message part.
Re: KDE file dialog
On Mittwoch, 2. März 2016 12:51:28 CEST, Martin Graesslin wrote: On Wednesday, March 2, 2016 12:09:17 PM CET Sven Brauch wrote: On 03/02/2016 11:56 AM, Thomas Lübking wrote: ... Just saying: I wrote that SNI integration and I have never heard of that problem before Sven mentioned it here. The client deadlocked flooding the dbus. Only happened if the SNI daemon was/is unreachable. See bug #350288 and linked dupe. Iirc it was not the SNI daemon which crashed, but some other ded module (taking kded with it, causing this as follow-up and made me wonder what would happen if someone simply unticked that daemon => unusable system) Cheers, Thomas
