[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kwin
Subject:    Re: concerning dbusmenu powered menus in the titlebar
From:       Thomas_Lübking <thomas.luebking () gmail ! com>
Date:       2011-04-12 17:30:27
Message-ID: op.vtt5k0x79bmiid () localhost ! localdomain
[Download RAW message or body]

Am 12.04.2011, 12:06 Uhr, schrieb Aurélien Gâteau <agateau@kde.org>:

> I have a different approach: I consider (KDE | GNOME) + dbusmenu as a
> different platform, with different constraints, and I believe Qt
> applications can adapt to these constraints. I was actually quite
> surprised when Thiago explained to me they consider Linux distributions
> as their upstreams: the distribution provides a platform and Qt adapts
> to it.
Well, while it's 100% correct that Qt considers KDE (just as Gnome) to be  
upstream, i've yet not seen an "#ifndef QT_UBUNTU" etc.
Also that's not the point: you're about to change (read: "possibly break")  
an existing Qt upstream - Qt's role doesn't matter here, esp. with a  
plugin driven QMenu/Bar.

> There have always been differences among platforms supported by Qt which
> led to some features not being available everywhere.
Yes, and perfectly covered by Q_WS_*
The problem is that you attempt to remove present features from a present  
platform in a minor release - unless Qt introduces such cut for you and  
withdraws Q_WS_X11 from KDE/GNOME and introduces eg Q_WS_LDE  
(LinuxDesktopEnvironment) to silently introduce DBusMenu powered QMenu  
(what would require compiling for this "architecture") to actually enable  
usercode to ensure feature completeness on all platforms.

>> QX11Embed
> I was afraid you were thinking about that. That is not going to happen:

So you
a) do not want a clean cut
b) do not want a fallback solution (ugly or not) to ensure compatibility  
for what you claim is no problem anyway
c) but rather rush in, effectively break a class and therefore risk to  
break existing downstream code?

To make that clear:
I think the possibility to have QWidgetActions in menus is a plain bug.  
The menus should have proper support for some general things and get rid  
of QWidgetAction cludges (therefore i'd prefer the clean cut), BUT
there are few ways to put a sense/strategy into this strategy - esp. with  
the Ayatana thing in mind.
http://mail.kde.org/pipermail/plasma-devel/2009-September/008108.html
http://lists.kde.org/?t=125362626900003&r=3&w=2

And to add this as well:
I actually and still think that the plasma popup implementation is too  
"noisy" and the particular point of the battery down message was flawed on  
plasmas side, but that's not the point either.
I sense a pattern.

> I believe the number of applications which would break
> because they use custom widgets in their menus is much smaller than the
> number of applications which would look inconsistent with the rest of
> the platform because they would not be ported to your new class.
I certainly agree on the quantity but there's a difference in quality.
It's one thing to have an offer not taken and a completely other thing to  
"silently" take away existing functionality.

The latter one does simply not match my nature but, while i will keep  
opposing such move, i'm actually not in charge here at all and if you  
insist to backward break a class (through a KDE platform plugin, i  
assume?) it has actually to be discussed with and on k-c-d whether such is  
acceptable behavior.


Cheers,
Thomas

-- OT
> It certainly makes your messages annoying to read. And the amount of
> smileys, SCNR or xml tags does not mitigate that feeling.
Maybe simply don't make me - and many others. It's not like ppl. would  
object the name or so.
As long as i'm printing smileys it means: i don't like these things at  
all, but i don't hate you either ;-)
_______________________________________________
kwin mailing list
kwin@kde.org
https://mail.kde.org/mailman/listinfo/kwin

[prev in list] [next in list] [prev in thread] [next in thread]