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

List:       kwin
Subject:    Re: concerning dbusmenu powered menus in the titlebar
From:       Aurélien Gâteau <agateau () kde ! org>
Date:       2011-04-13 8:27:51
Message-ID: 4DA55E87.3080001 () kde ! org
[Download RAW message or body]

On 12/04/2011 19:30, Thomas Lübking wrote:
> 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.

If the default behavior of a platform supported by Qt is for
applications to expose their menubars through dbus, Qt adapts to it.
Whether this platform is a variant of another platform or a brand new
platform does not really matter.

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

True, there is no compile-time check. But there is a run-time check: the
Qt::AA_DontUseNativeMenuBar flag tells you whether you can expect
QWidgetAction in menus to work or not.

Note that all platforms differences are not perfectly covered by Q_WS_*.
I choose QSystemTrayIcon for this very reason: on Mac OS
QSystemTrayIcon::showMessage() won't work if Growl is not installed.

>>> QX11Embed
>> I was afraid you were thinking about that. That is not going to happen:
> 
> So you
> a) do not want a clean cut

Correct.

> b) do not want a fallback solution (ugly or not) to ensure compatibility  
> for what you claim is no problem anyway

We do not want an ugly fallback solution based on XEmbed. If there was
an elegant one we would probably consider it.

> c) but rather rush in, effectively break a class and therefore risk to  
> break existing downstream code?

We are not rushing in: we are developing a new platform with new ways to
present menus and we are making the necessary work with toolkits (keep
in mind we have GTK, and now XUL and Uno support as well) to ensure
applications integrate correctly.
Unfortunately this means that a few applications are not going to work
correctly on this platform. I think this is a price Canonical is willing
to pay, as much as I can speak on behalf of Canonical.

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

What is the connection between these messages and the current discussion?

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

I see your point about silently taking away functionality. One way to
avoid this would be for the platform plugin to disable itself as soon as
one unsupported action is added to the menu. What do you think of this?

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

Makes sense. For the record, the plugin already exists. You can find it
here:

https://launchpad.net/appmenu-qt/

Aurélien
_______________________________________________
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]