KDE file dialog

Martin Graesslin mgraesslin at kde.org
Wed Mar 2 10:19:42 GMT 2016


On Wednesday, March 2, 2016 11:08:30 AM CET Mark Gaiser wrote:
> On Wed, Mar 2, 2016 at 9:42 AM, Martin Graesslin <mgraesslin at kde.org> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20160302/3bf0cd46/attachment.sig>


More information about the kde-core-devel mailing list