Open GoogleCodeExporter opened 8 years ago
Initial support for KDE is done in /trunk.
The code is dirty and messy.
But it indicates that a grand menu server for Gnome and KDE should listen from
various sources for new menu bar creation events, regularize the information to
{transient(parent), container window, communicate, type}, then invoke a
callback for
new client then to its client list.
Also applies for client destroying.
Original comment by rainwood...@gmail.com
on 22 Feb 2008 at 2:08
Original comment by rainwood...@gmail.com
on 22 Feb 2008 at 2:08
You need collaboration with both GNOME and KDE... Ugh, almost forgot about XFCE,
sorry (; .
Original comment by jakub.ru...@gmail.com
on 22 Mar 2008 at 3:38
Hi, (I'm antalmir)
I would like to take out this issue for the graveyard because of a recently
released
project: QGtkStyle (http://labs.trolltech.com/page/Projects/Styles/GtkStyle).
It is a QT4 style engine that render USING GTK, so it will just need a little of
collaboration to have all of our Qt4 softwares like the Gtk ones (I tested it,
it's
perfect).
Good bye !
Original comment by thys...@gmail.com
on 16 May 2008 at 8:07
I am lost on this issue.
Once the trunk for 0.5 and 0.5 api are stable, I'll contact them.(if their
project is
still alive then).
Original comment by rainwood...@gmail.com
on 21 Jul 2008 at 7:07
Hi,
It is now official: QGtkStyle will be included in Qt 4.5 (and it is very
powerful).
So now, you're sure that this project will always be alive ;)
What do you plan on this ?
Original comment by thys...@gmail.com
on 24 Sep 2008 at 9:20
Some thoughts on this issue:
1. Qt dosen't provide a dynamic patching system as Gtk's GTK_MODULES. Meanwhile
this
needs more details of compiler for how to override the virtual function in the
runtime . So most feasible way is to patch Qt directly.
2. Some results of studying KDE: kwindowsystem.h is the replacement of libwnck,
plasma is to applet, XML and DBus are built-in modules in Qt, but I needs more
efforts on how to use the API.
3. Check QGtkStyle. Dose that make sense for our project?
Original comment by fengsh...@gmail.com
on 10 Oct 2008 at 1:51
I have two approaches for Qt/KDE compatibility:
a. First write the plasma applet(with the aid of kwindowsystem.h) to hold the
GlobalMenu from GTK applications,
then patch QT itself
b. patch QT to so that the menus can be made available for gnomenu-navigator.
then write the plasma applet.
Anyways, perhaps writing a C++ binding for libgnomenu and libgmarkupdoc will be
very
helpful since
1 QT is C++
2 after some further refactoring I can strip all GTK dependency in them to
seperated
la targets.
Original comment by rainwood...@gmail.com
on 10 Oct 2008 at 2:43
So Baghira won't help (rememeber: the Globalmenu equivalent for Qt, official) ?
Original comment by thys...@gmail.com
on 11 Oct 2008 at 8:10
It may help or not, but the approaches are fundamentally different. GlobalMenu
relies
on a bloated RPC framework for remote widgets, whereas Baghira uses a
superficial
server side window reparenting for remote widgets.
Original comment by rainwood...@gmail.com
on 11 Oct 2008 at 3:10
Original comment by rainwood...@gmail.com
on 29 Oct 2008 at 4:52
The snow makes everything slippery.
Original comment by rainwood...@gmail.com
on 19 Dec 2008 at 7:55
fengshenx, did you had time to look into the issue?
Original comment by rainwood...@gmail.com
on 20 Jan 2009 at 11:13
Maybe this will help you with developing the QT-compatibility:
http://forum.kde.org/kde4-and-the-macos-menubar-t-10019-7.html
http://cloudcity.sourceforge.net/ (There is XBar's source code... It may would
be
intresting?)
http://frinring.wordpress.com/2009/01/29/mac-style-menubar-for-kde-4-and-others/
http://frinring.files.wordpress.com/2009/01/x-bar.png (Xbar in action, in KDE
ofcourse...)
Original comment by miikka.v...@gmail.com
on 5 Feb 2009 at 6:40
I'm confused. This issue is about porting global menu for KDE, is that right?
What
about having Qt applications using the global menu in Gnome?
Original comment by daniel...@gmail.com
on 6 Mar 2009 at 8:25
No, it's about having Qt application using the global menu in Gnome/Xfce. KDE
already
has its own globalmenu.
By the way, Qt 4.5 is released. It should now be easy to integrate Qt applis in
Globalmenu with a beautiful UI.
Original comment by thys...@gmail.com
on 7 Mar 2009 at 10:49
is it possible to make non-Kde QT apps work with the menu?
Original comment by mlinch...@gmail.com
on 10 Mar 2009 at 3:13
@mlinchits, not at the moment, but I believe that is the plan for this item...
I was hoping that the gtkstyle plug-in for Qt, which renders Qt apps using
native GTK
widgets would work for this, however after trying it, it seems the menu is not a
globalmenu compatible type widget. There was an item opened in the gtkstyle
tracker:
http://code.google.com/p/qgtkstyle/issues/detail?id=43&can=1&q=globalmenu ,
but it was marked invalid... which is fair enough because globalmenu is not an
official part of Gnome yet.
So lets hope they come up with something here. :D
Original comment by ironst...@gmail.com
on 10 Mar 2009 at 7:35
wiki: PlanForQTStyle
Original comment by rainwood...@gmail.com
on 11 Nov 2009 at 11:26
Any progress on this?
Original comment by sto...@gmail.com
on 12 Feb 2010 at 3:07
Ubuntu in its new edition of netbook is going to have similiar thing. They, as
far as I can see have made the
QT and GTK display global menu.
http://www.youtube.com/watch?v=_FQGuUETJaA&feature=player_embedded
Maybe use some of ther stuff to bring it to global menu project?
https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationMenu
Original comment by ivan.jov...@gmail.com
on 29 May 2010 at 2:32
Yes they got the QT part done.
More or less I would say ubuntu's app-menu will deprecate Global Menu, when
their
patches to GTK merges upstream.
Original comment by rainwood...@gmail.com
on 29 May 2010 at 4:11
Haven't they used gnome-globalmenu as the basis of their changes?
Even if they merge their global menu upstreams, one should be here to ensure it
is
available accross desktop environments… through a panel applet, or
independently.
Original comment by thys...@gmail.com
on 29 May 2010 at 4:18
I was under impression that it's going to be a Netbook version thing only, with
specific changes to fit their
new "Unity" shell. Sure, one could use it on the desktop but it's going to
bring dependecies form that netbook
shell and who-knows-what.
Besides, Global Menu is and, again in my impression, will remain to be more
advanced and suitable for
desktop users. If you could add the QT part, it will make it that much cooler :)
Original comment by ivan.jov...@gmail.com
on 29 May 2010 at 4:32
Yes.. Ubuntu's Appmenu is... primitive, and severely buggy at the moment. The
Qt support is nice, but if we could have that in Globalmenu, it would be
superior in every way
Original comment by erikas.aubade@gmail.com
on 20 Oct 2010 at 3:56
I've implemented this using a QMenuBar plugin, the same way Ubuntu's Appmenu
does it.
https://gitorious.org/firefox-gnome-globalmenu/qt4-gnome-globalmenu
Note that you need Qt4.7 and Ubuntu's QMenuBar plugin system patch (for example
available here https://aur.archlinux.org/packages.php?ID=40317 ). While it
should work on Qt4.8, I've not tried.
The plugin also hacks the WM_NAME on the session leader window for Qt
applications so that the menu applet gives more meaningful application names.
Original comment by javispe...@gmail.com
on 9 Oct 2011 at 12:53
should move this entire project to the saem bas as ubuntu and kde's global
menu. the implementation is now less buggy than this solution and has support
from several desktop teams. Also the dbusmenu integration allows for many
possibilities in new menu development. I love all the desktops, and i think
gnome-shell deserves an actively developed global menu that works on qt and can
take advantage fo all the people making plugins and stuff for firefox,
libre-office, callibre, etc
Original comment by ikeah...@gmail.com
on 8 May 2012 at 12:11
I personally disagree, which is why I still keep using it (and therefore fixing
it when it breaks on my systems, which all use Gentoo stable). Using D-Bus is a
very bad idea, because it does not work with X11 network redirection or windows
handled by other users' processes (that is, root). Of course, using X11 means
it dies when X11 dies, but since I want to hold on X for as long as possible...
Original comment by javispe...@gmail.com
on 8 May 2012 at 8:08
Original issue reported on code.google.com by
rainwood...@gmail.com
on 21 Feb 2008 at 12:15