Re: KDE file dialog

[Valorie Zimmerman]

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

Re: KDE file dialog

[Kai Uwe Broulik]

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

[Thomas Lübking]

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

[Martin Graesslin]

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

[Kevin Kofler]

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

[Thomas Lübking]

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]

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

[Martin Graesslin]

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

[Marco Martin]

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

[Sven Brauch]

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

[Thomas Lübking]

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

[Sven Brauch]

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

[Martin Graesslin]

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

[Mark Gaiser]

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

[Marco Martin]

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

[Martin Graesslin]

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

[Martin Graesslin]

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

[Thiago Macieira]

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

[Thomas Lübking]

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

[Sven Brauch]

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

[Sebastian Kügler]

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

[Mark Gaiser]

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

[Mark Gaiser]

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

[Martin Koller]

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

[Sven Brauch]

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 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

[Thiago Macieira]

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

[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.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

Re: KDE file dialog

[Sven Brauch]

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

[Luigi Toscano]

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

[Martin Koller]

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

[Riccardo Iaconelli]

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

[Aleix Pol]

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

[Riccardo Iaconelli]

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

[Luigi Toscano]

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

KDE file dialog

[Martin Koller]

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 ?

-- 
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