[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-03-29 21:18:03
Message-ID: 4D924C8B.7040305 () kde ! org
[Download RAW message or body]

On 29/03/2011 22:01, Thomas Lübking wrote:
> 2. Feature restriction (still minor)
> -----------------------------------
> a) QDusMenu cannot possibly handle QWidgetActions. This would be an  
> immediate blocker, but they won't work on MacOS either (so they should  
> simply not exist)

Actually they do work on Mac OS, but with a few restrictions.

> Therefore, while not an ultimate blocker this might be source of some  
> annoyance - I know that Aurélien has patched out the stupid throbber for  
> this reason. There might however be more incidents like this (in less  
> popular applications)
> A certain fail (even for the menubar) is kdevelop (weird menubar layout)  
> which is simply blacklisted in XBar, but just because it's kdevelop and  
> not knotrelevant - which must not be broken either.

KDevelop works correctly with appmenu-qt, I only had to patch its corner
widget.

> Passing the popups across dbus obviously raises the chance of resp.  
> failure, not only because Nokia refused [1] to add official support for  
> texted separators (aka "headers") and therefore fix the paint order of  
> QMenu items...

dbusmenu-qt comes with special code to support KDE menu title.

> b) QAction::data() can carry all kinds of QVariants, being expected at the  
> attached slot (I do that alot ;-)

This should work just fine: on the application side, the object which
emits triggered() is the one passed to QMenuBar.
> 
> 3. Code state uncertainty
> ---------------------------
> Theoretically the application state might rely on certain events of the  
> popups, ie. ideally listen to the aboutToShow signal (this is a general  
> approach to create dynamic content in menus), less ideally by catching  
> QEvent::Show or ::Hide in an eventFilter()

aboutToShow() is supported. Setting event filters on QMenu is not.

> Also it's possible to link one slot to the menus triggered signal instead  
> of many slots to the action ones, so this signal as to (properly) fire as  
> well.

> I don't know whether the QDBusMenu patch includes it, but this event  
> "faking" has to be patched into QMenu to ensure things keep working (been  
> the ultimate stopper on my side, then ;-)

I haven't tested QMenu::triggered(QAction*) but judging from QMenu code
it should work because it is emitted by a slot connected to the
QAction::triggered() signal. I guess I would have received a few bug
reports from Ubuntu Maverick users if it was broken :)


> 
> Epilogue:
> ----------
> While in general open to other concepts of the menubar (in general i avoid  
> to add one in the first place - it's a stupid dumpster for "i'll find a  
> better solution later on") i do not share the opinion that this is a  
> trivial task.
> I mean: trivial to add to a kwin deco - sure. Trivial to export a random  
> foreign menu from a platform plugin etc. - errrrm.... rather not ;-)
> It will include to
> a) ensure to cover non-regular menu usages
> b) walk through KDE applications and ensure they do NOT contain a  
> QWidgetAction in a QMenu...

I did that before Maverick was released. One application I did not fix
for lack of time is Kopete, which has a special menu item to select
smileys. I may have missed others though.

> c) walk through KDE applications and ensure their menu slots have proper  
> input sanitation

Not sure what you mean here.
> 
> Summary:
> ----------
> Putting the menubar into a toolbutton is trivial, passing it across dbus  
> is probably not :-(

That is what appmenu-qt does, am I missing something?

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]