[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-12 10:06:51
Message-ID: 4DA4243B.9050003 () kde ! org
[Download RAW message or body]

On 12/04/2011 01:07, Thomas Lübking wrote:
> Am 11.04.2011, 23:21 Uhr, schrieb Aurélien Gâteau <agateau@kde.org>:
> 
>> So, what do you suggest then?
> Have a clean cut. You're effectively breaking a class.
> Have a QDBusMenuBar and QDBusMenu (or whatever name) with explicit  
> restrictions. Depreach legacy QMenuBar/QMenu.
> Given Martin's additional comment about the rather required menu  
> restructuration (when converting a menubar into a toplevel popup) this  
> should be no problem.
> Or have it 100% (and not 98%) transparent.
> 
> Wanna do it seriously? Then Do - It - Right. No hacks. No "should" - That  
> is simply not required.

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.

There have always been differences among platforms supported by Qt which
led to some features not being available everywhere. QSystemTrayIcon is
a good example of this. I believe supporting dbusmenu-based platforms
should be as transparent as possible, even if this means documenting
that some features won't work on these platforms.

>> The design of this patch has been defined during some private
>> Nokia-Canonical meeting, so I am confident it is what they want.
> Ok, read the proposed patch now ;-)
> Since it only abstracts the menubar and defers the implementation to  
> (system specific and functionally restrictable) plugins there should be no  
> problem from their side at all.
> Maybe they're still working on the WP7 port :-P
> 
> 
>> Not sure what you mean with reparenting QWidgetActions. What would be
>> the new parent?
> Sorry, "QXEmbed it to the actual menu" ;-)

I was afraid you were thinking about that. That is not going to happen:
one of the goals of dbusmenu is to ensure the workspace is in charge of
the rendering, not the application. It cannot be done with QXEmbedded
widgets.

> PS: I hope this does not sound like i'd try to talk you or anybody out of  
> something.
> I just don't see why we should attempt to hack sth. in, risking even minor  
> breaks, while being in every position to easily have a clean solution -  
> even if it invokes a short transition time.
> And if it's stuffed on top I just dare to call for a solution covering  
> 100% of all cases, even if it requires rather unelegant compatibility code.

I am very much against the clear-cut approach because it will lead to
inconsistency between applications ported to the new class you propose
and applications not ported.

If I take the example of the in-house applications you mentioned
previously, 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.

In the worse case, it is relatively easy to disable dbusmenu support for
an application if it really is unusable without custom widgets in its
menubar: one can either set the QT_X11_NO_NATIVE_MENUBAR environment
variable before starting the application. or do the very minor fix of
calling:

  QCoreApplication::setAttribute(Qt::AA_DontUseNativeMenuBar);

in main().

> PPS: yes, i nevertheless here and there tend to bash Ubuntu for various  
> reasons, sosumi ;-)
> You may however be sure that this has no impact on my positions at all.  
> I'm neither religious nor a politician, opposing good ideas from the wrong  
> corner.

It certainly makes your messages annoying to read. And the amount of
smileys, SCNR or xml tags does not mitigate that feeling.
_______________________________________________
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]