Re: KDE file dialog
Martin Koller ha scritto: > In KDE4 times there was a common file dialog for the applications, I think > this is what KFileDialog was made for. > Now where some applications are already ported to KF5, there seems to be no > such thing anymore > (or it does not work here). > KFileDialog is deprecated, QFileDialog does not have the functionality of > KFileDialog (e.g. aside preview). > As I find KFileWidget having e.g. preview possibility, I assume QFileDialog > would use this widget via > the platform integration, right ? > If so, does this only work when running plasma5 as desktop or is there a way > to get the KDE4 features > in KF5 application file dialogs even when running inside a KDE4 session ? > 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). The idea is that other desktop environments will provide their own integration plugin, but I agree that there are use cases where this won't happen (run application as root, run as another user, minor Qt-based desktop environments, etc). That said, I'm just an user regarding Plasma stuff. Ciao -- Luigi
Re: KDE file dialog
On 28 February 2016 at 15:58, Luigi Toscano wrote: > > This is what I use: > export QT_QPA_PLATFORMTHEME=kde (btw, shouldn't this be "plasma"?) -Riccardo -- Pace Peace Paix Paz Frieden Pax Pokój Friður Fred Béke 和平 Hasiti Lapé Hetep Malu Mир Wolakota Santiphap Irini Peoch שלום Shanti Vrede Baris Rój Mír Taika Rongo Sulh Mir Py'guapy 평화
Re: KDE file dialog
On Sun, Feb 28, 2016 at 8:01 PM, Riccardo Iaconelli wrote: > On 28 February 2016 at 15:58, Luigi Toscano wrote: >> >> This is what I use: >> export QT_QPA_PLATFORMTHEME=kde > > (btw, shouldn't this be "plasma"?) The string is in Qt, AFAIR. It probably can't be changed until Qt 6 if we don't want to mess with existing installations. Aleix
Re: KDE file dialog
On 28 February 2016 at 20:06, Aleix Pol wrote: > The string is in Qt, AFAIR. It probably can't be changed until Qt 6 if > we don't want to mess with existing installations. We should still probably alias it and deprecate 'kde', so that people can start using the right name correctly. Bye, -Riccardo -- Pace Peace Paix Paz Frieden Pax Pokój Friður Fred Béke 和平 Hasiti Lapé Hetep Malu Mир Wolakota Santiphap Irini Peoch שלום Shanti Vrede Baris Rój Mír Taika Rongo Sulh Mir Py'guapy 평화
Re: KDE file dialog
On Sunday 28 February 2016 15:58:20 Luigi Toscano wrote: > Martin Koller ha scritto: > > In KDE4 times there was a common file dialog for the applications, I think > > this is what KFileDialog was made for. > > Now where some applications are already ported to KF5, there seems to be no > > such thing anymore > > (or it does not work here). > > KFileDialog is deprecated, QFileDialog does not have the functionality of > > KFileDialog (e.g. aside preview). > > As I find KFileWidget having e.g. preview possibility, I assume QFileDialog > > would use this widget via > > the platform integration, right ? > > If so, does this only work when running plasma5 as desktop or is there a > > way to get the KDE4 features > > in KF5 application file dialogs even when running inside a KDE4 session ? > > > > 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). ok, good. I've now installed frameworksintegration and I've now the preview feature back - but I have also now (in my POV) ugly black-and-white icons which I don't like. Installing systemsettings5 (openSuse 13.2) does not show any icon related section (in fact it only shows 6 different sections). I'd like to have the oxygen icons as in all my other KDE4 apps. Where can I set this ? Should a KF5 app (with frameworksintegration) not also use the settings from a still used KDE4 desktop ? How would this work in e.g. a gnome desktop ? P.S.:I have also installed all oxygen5 related things I found, e.g. oxygen5-icon-theme, oxygen5-style -- Best regards/Schöne Grüße Martin A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? () ascii ribbon campaign - against html e-mail /\- against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at -- Best regards/Schöne Grüße Martin A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? () ascii ribbon campaign - against html e-mail /\- against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at
Re: KDE file dialog
Martin Koller ha scritto: > On Sunday 28 February 2016 15:58:20 Luigi Toscano wrote: >> Martin Koller ha scritto: >>> In KDE4 times there was a common file dialog for the applications, I think >>> this is what KFileDialog was made for. >>> Now where some applications are already ported to KF5, there seems to be no >>> such thing anymore >>> (or it does not work here). >>> KFileDialog is deprecated, QFileDialog does not have the functionality of >>> KFileDialog (e.g. aside preview). >>> As I find KFileWidget having e.g. preview possibility, I assume QFileDialog >>> would use this widget via >>> the platform integration, right ? >>> If so, does this only work when running plasma5 as desktop or is there a >>> way to get the KDE4 features >>> in KF5 application file dialogs even when running inside a KDE4 session ? >>> >> >> 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). > > ok, good. I've now installed frameworksintegration and I've now the preview > feature back - > but I have also now (in my POV) ugly black-and-white icons which I don't like. > Installing systemsettings5 (openSuse 13.2) does not show any icon related > section > (in fact it only shows 6 different sections). > I'd like to have the oxygen icons as in all my other KDE4 apps. > Where can I set this ? The icon kcm is currently part of the plasma-desktop source package (but it does not depend on it). I don't know how it is packaged in openSUSE. But see below (qt5ct) > Should a KF5 app (with frameworksintegration) not also use the settings from > a still used KDE4 desktop ? frameworksintegration is going to be part of plasma, in fact. There would need to be an "old plasma" integration. Or you can use an alternative system to set it, like https://sourceforge.net/projects/qt5ct/ > How would this work in e.g. a gnome desktop ? Afaik the Gtk+ style is used. There is also this project for a better integration, see https://fedoraproject.org/wiki/Changes/QGnomePlatform Ciao -- Luigi
Re: KDE file dialog
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 :/ Best, Sven signature.asc Description: OpenPGP digital signature
Re: KDE file dialog
On segunda-feira, 29 de fevereiro de 2016 21:42:11 PST 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). If you're not in the Plasma desktop, you should get the dialogs from the desktop you're in. For example, if you're in GNOME, the GTK style plugin should get the GTK dialogs. The only left-over is for a Qt 5 app on a KDE 4 desktop. In that case, I'd argue that the Plasma plugin should be loaded, but it needs to be installed too. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center
Re: KDE file dialog
On terça-feira, 1 de março de 2016 00:44:05 PST Sven Brauch wrote: > > If you're not in the Plasma desktop, you should get the dialogs from the > > desktop you're in. For example, if you're in GNOME, the GTK style plugin > > should get the GTK dialogs. > > But that assumes the desktop you're in actually provides this > functionality. Only if it's a Qt-based desktop. If it's another desktop, then it's Qt's job to integrate with it properly. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center
Re: KDE file dialog
On 02/29/2016 11:09 PM, Thiago Macieira wrote: >> 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). > If you're not in the Plasma desktop, you should get the dialogs from the > desktop you're in. For example, if you're in GNOME, the GTK style plugin > should get the GTK dialogs. But that assumes the desktop you're in actually provides this functionality. And I think basically all desktops but Plasma and GNOME don't do that (mine certainly doesn't, it doesn't even _have_ its own file dialog). In this case the default is quite bad (the Qt5 file dialog is, sorry to say, terrible) and the chances to change it are hard to reach or not available. I don't think that is a great situation. I guess the problem here is that some Look&Feel decisions require a specific desktop (e.g. KSNI) while others don't, but they are grouped into the same module. Probably this doesn't affect enough people to be of interest to anyone, though. Greetings, Sven signature.asc Description: OpenPGP digital signature
Re: KDE file dialog
On Monday 29 February 2016 21:34:13 Luigi Toscano wrote: > > Should a KF5 app (with frameworksintegration) not also use the settings > > from a still used KDE4 desktop ? > > frameworksintegration is going to be part of plasma, in fact. There would need > to be an "old plasma" integration. Or you can use an alternative system to set > it, like https://sourceforge.net/projects/qt5ct/ is this project a different frameworksintegration plugin ? I thought it's just to _configure_ things. Using it here results in: - oxygen icons as I like - good - no file dialog preview feature again ... - not good So basically I can: - not use plasma framework integration (no file preview) - use plasma framework integration with file preview but having ugly icons, different fonts, colors, ... basically having an ugly mixture of KDE4 and KDE5 things. am I missing an option ? -- Best regards/Schöne Grüße Martin A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? () ascii ribbon campaign - against html e-mail /\- against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at
Re: KDE file dialog
Op 29 feb. 2016 11:10 p.m. schreef "Thiago Macieira" : > > On segunda-feira, 29 de fevereiro de 2016 21:42:11 PST 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). > > If you're not in the Plasma desktop, you should get the dialogs from the > desktop you're in. For example, if you're in GNOME, the GTK style plugin > should get the GTK dialogs. > > The only left-over is for a Qt 5 app on a KDE 4 desktop. In that case, I'd > argue that the Plasma plugin should be loaded, but it needs to be installed > too. > That is only true in a "KDE and gnome world". There are more "environments" out there. I specifically left out the "desktop" word since there are environments out there where you might argue if it deserves the "desktop" suffix. I for instance quite often fire up openbox. It doesn't have a Qt theme platform plugin and should IMHO not aim to make one. Plasma has a fine plugin which works wonderfully on openbox and makes qt dialogs look fancy instead of ugly. I let my openbox environment think that I'm in plasma by setting "QT_QPA_PLATFORMTHEME=kde" and that thankfully still works just fine. I do think that it's a massive shame on the plasma folks for moving this plugin into plasma itself for supposed "better integration" which I seriously doubt. As of this moment it's still working fine, but there is undoubtedly going to be a point in time where the plugin only works when some very specific plasma part is required for it to function, that will probably make it useless on non plasma environments. They should have never went this route and leave the framework theme as is, without plasma.. But that's my opinion. They have theirs, they know mine and that is all just fine. They do the work so they are very much allowed to do this. It just sucks. > -- > Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org >Software Architect - Intel Open Source Technology Center >
Re: KDE file dialog
On Tue, Mar 1, 2016 at 7:42 PM, Sven Brauch wrote: > Hey, > > On 03/01/2016 07:37 PM, Mark Gaiser wrote: > > but there is > > undoubtedly going to be a point in time where the plugin only works when > > some very specific plasma part is required for it to function > That is already the case; try running an application with a systray > icon, it will not work (or in older versions even make dbus run out of > file descriptors (!)). > Otherwise I agree with your reasoning. I'm just not sure what we can > effectively do about it. Having the plugin in an extra repository imo > doesn't help much, and I really don't mind having plasma installed. > > A few things come to mind.. 1. Create bug reports. But they will likely be closed as invalid or won't fix since they "think" the're doing the right thing. 2. Fork. I did fork frameworkintegration for a very short time because the noto font requirement was completely screwing my system up. They basically said i should just swallow it and learn to live with it. Which i refused so i forked, but it turned out to be more easily fixable by blacklisting some weird fonts in the noto package then keeping a fork alive. I really don't see why they are heading this way. Isn't it possible to have the platform theme as it was before (with no plasma deps) for others to use and then some "more fancy" plugin on top of that which would implement just the plasma specific things? That way everyone would be happy.
Re: KDE file dialog
On Tuesday, March 01, 2016 06:45:14 PM Martin Koller wrote: > On Monday 29 February 2016 21:34:13 Luigi Toscano wrote: > > > Should a KF5 app (with frameworksintegration) not also use the settings > > > from a still used KDE4 desktop ?> > > > > > > frameworksintegration is going to be part of plasma, in fact. There would > > need to be an "old plasma" integration. Or you can use an alternative > > system to set it, like https://sourceforge.net/projects/qt5ct/ > > is this project a different frameworksintegration plugin ? > I thought it's just to _configure_ things. > > Using it here results in: > - oxygen icons as I like - good > - no file dialog preview feature again ... - not good > > So basically I can: > - not use plasma framework integration (no file preview) > - use plasma framework integration with file preview but having ugly icons, > different fonts, colors, ... basically having an ugly mixture of KDE4 and > KDE5 things. > > am I missing an option ? Doing your own integration plugin. (I know, not necessarily what you want to do, but it *is* an option.) -- sebas http://www.kde.org | http://vizZzion.org
Re: KDE file dialog
Hey, On 03/01/2016 07:37 PM, Mark Gaiser wrote: > but there is > undoubtedly going to be a point in time where the plugin only works when > some very specific plasma part is required for it to function That is already the case; try running an application with a systray icon, it will not work (or in older versions even make dbus run out of file descriptors (!)). Otherwise I agree with your reasoning. I'm just not sure what we can effectively do about it. Having the plugin in an extra repository imo doesn't help much, and I really don't mind having plasma installed. Best, Sven signature.asc Description: OpenPGP digital signature
Re: KDE file dialog
On Dienstag, 1. März 2016 19:42:58 CEST, Sven Brauch wrote: Otherwise I agree with your reasoning. I'm just not sure what we can effectively do about it. Build option to build the kde/plasma QPA into a strict "KF5" (tier 1) QPA? Forking sucks terribly and a tier 1 QPA might be interesting for eg. lxqt users (drawing them into KF5) Having the plugin in an extra repository imo doesn't help much, and I really don't mind having plasma installed. The repo is probably not that much of an issue. Most users would get it from their distro and that could build two QPAs and ship the KF5 variant extra. Only exception are devs and gentoo users and it's not *that* much disk space. Alternative solution would be git submodules, but that looks like quite some work (notably since you'd want the kf5 version that you still need to find some repo for to default off while the plasma version defaults on) Cheers, Thomas
Re: KDE file dialog
On terça-feira, 1 de março de 2016 21:20:03 PST Mark Gaiser wrote: > Isn't it possible to have the platform theme as it was before (with no > plasma deps) for others to use and then some "more fancy" plugin on top of > that which would implement just the plasma specific things? That way > everyone would be happy. Yes. Just volunteer to write that plugin. It may be even accepted as part of the Qt Project. The point is that it's not going to happen without developer effort. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center
Re: KDE file dialog
On Tuesday, March 1, 2016 7:37:55 PM CET Mark Gaiser wrote: > Op 29 feb. 2016 11:10 p.m. schreef "Thiago Macieira" : > > On segunda-feira, 29 de fevereiro de 2016 21:42:11 PST 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). > > > > If you're not in the Plasma desktop, you should get the dialogs from the > > desktop you're in. For example, if you're in GNOME, the GTK style plugin > > should get the GTK dialogs. > > > > The only left-over is for a Qt 5 app on a KDE 4 desktop. In that case, I'd > > argue that the Plasma plugin should be loaded, but it needs to be > > installed > > > too. > > That is only true in a "KDE and gnome world". There are more "environments" > out there. I specifically left out the "desktop" word since there are > environments out there where you might argue if it deserves the "desktop" > suffix. I for instance quite often fire up openbox. It doesn't have a Qt > theme platform plugin and should IMHO not aim to make one. Plasma has a > fine plugin which works wonderfully on openbox and makes qt dialogs look > fancy instead of ugly. > > I let my openbox environment think that I'm in plasma by setting > "QT_QPA_PLATFORMTHEME=kde" and that thankfully still works just fine. > > I do think that it's a massive shame on the plasma folks for moving this > plugin into plasma itself for supposed "better integration" which I > seriously doubt. Please watch your words! I don't want to be shamed just because you are badly informed. Yes we need it for better integration. Yes this already happened. For example yesterday Johnathan presented me a Wayland live CD, I run it, started an application and reported back to him that plasma-integration was missing. Just by looking at one window I was able to see that it was missing. So maybe there are real things in that plugin which provide better integration. Cheers Martin signature.asc Description: This is a digitally signed message part.
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
Re: KDE file dialog
Martin Graesslin wrote: > No, because everything in the current plugin is Plasma specific. If we > want to change the font, we will do so! Forcing a default font as you have done is a bad idea even on Plasma. It is not the desktop environment's business to pick a default font. (And yes, I know GNOME does it too, with a much worse font (really poor glyph coverage). That's not a reason to do the same.) Distributions set up distribution-wide "Sans", "Serif" and "Monospace" aliases for a reason. The fonts are carefully selected by the distribution based on a variety of criteria, including glyph coverage (OK, Noto is great there; your previous default Oxygen was not, though!), quality, looks, etc. And most importantly, the distro-wide aliases ensure consistency across applications using different toolkits. Desktops deciding they know better break this. Kevin Kofler
Re: KDE file dialog
On Sunday, March 6, 2016 1:48:13 AM CET Kevin Kofler wrote: > Martin Graesslin wrote: > > No, because everything in the current plugin is Plasma specific. If we > > want to change the font, we will do so! > > Forcing a default font as you have done is a bad idea even on Plasma. It is > not the desktop environment's business to pick a default font. (And yes, I > know GNOME does it too, with a much worse font (really poor glyph coverage). > That's not a reason to do the same.) Distributions set up distribution-wide > "Sans", "Serif" and "Monospace" aliases for a reason. The fonts are > carefully selected by the distribution based on a variety of criteria, > including glyph coverage (OK, Noto is great there; your previous default > Oxygen was not, though!), quality, looks, etc. And most importantly, the > distro-wide aliases ensure consistency across applications using different > toolkits. Desktops deciding they know better break this. I don't know how often we have heard over the last decade that Plasma's look and feel is terribly because of fonts. We addressed that point and selected a good default font. Now that's not correct either. People make up your mind: either you do your job and use good default fonts or you don't complain that we select the font for you. You cannot have both. Cheers Martin signature.asc Description: This is a digitally signed message part.
Re: KDE file dialog
On Sonntag, 6. März 2016 11:34:32 CEST, Martin Graesslin wrote: I don't know how often we have heard over the last decade that Plasma's look and feel is terribly because of fonts. I'd have assumed that'd be because of the freetype rasterizers being, errr ummm... shit (almost as shit as cleartype ;-) - and be resolved by the CFF rasterizer? Cheers, Thomas
Re: KDE file dialog
Hi, > Distributions set up distribution-wide "Sans", "Serif" and "Monospace" > aliases for a reason. The fonts are carefully selected by the distribution > based on a variety of criteria, including glyph coverage We tried to keep font decisions to distributions before Plasma 5 and it always made me cringe how terrible fonts looked in screenshots from other people and was one of the first things I had to change on every fresh install. Now we pick some sane defaults that make it look good and unified across distributions. Cheers, Kai Uwe
Re: KDE file dialog
I realize I'm slightly orthagonal to the original topic, but On Sat, Mar 5, 2016 at 11:14 PM, Kai Uwe Broulik wrote: > Hi, > >> Distributions set up distribution-wide "Sans", "Serif" and "Monospace" >> aliases for a reason. The fonts are carefully selected by the distribution >> based on a variety of criteria, including glyph coverage > > We tried to keep font decisions to distributions before Plasma 5 and it > always made me cringe how terrible fonts looked in screenshots from other > people and was one of the first things I had to change on every fresh > install. Now we pick some sane defaults that make it look good and unified > across distributions. > > Cheers, > Kai Uwe We've recently had a group working on trying to improve KDE <> distro relationships by improving communication. Yes, there is the packager list and release-team, but they are about the nitty-gritty of released packages. So the Distribution Outreach Program has asked for the Distributions list [1] to be created, where larger issues like these can be hashed out. All interested KDE people and all interested distribution people are invited to participate, no matter what your role. The KDE community wants KDE software to work well everywhere. And the wonderful people working to distribute KDE software want it to work well in each of our distros. Together we can make magic happen. Valorie 1. https://mail.kde.org/mailman/listinfo/distributions -- http://about.me/valoriez