Re: Do we need DBusMenu in the Shell?

[Alberto Ruiz <aruiz gnome org>]

Hello Giovanni,

I am glad you want to contribute possitively, but I am afriad that
opening a discussion in any mailing list would solve the solution.

What we need are patches for GtkApplication to expose main menu
information, and start a discussion based on the code proposals (and
the proposers should be ready to rework and take into account the
concerns of the maintainers) .

We need patches for different applications to expose extra information
using dbusmenu as a soft dependency accepted upstream.

Anything else other than that is making the situation even worse IMHO,
or at least it won't lead us anywhere. As long as there people not
only proposing code, but willing to work on it to make it upstreamable
and maintainers willing to help them on it, things will go smoothly.

I am familiar with libdbusmenu through my work on the LibreOffice
DBusMenu extension and I am happy to give you, or anyone willing to
make this work to assist in understanding how it works I am more than
happy to help not only in terms of code but also communicating with
the maintainers of the affected modules.

So let's stop discussing and let's get some work done :-)

Thanks a lot,
Alberto

2011/3/12 Giovanni Campagna <scampa giovanni gmail com>:
> Open Planet GNOME. Almost half of the latest posts relates on GNOME, KDE
> and Canonical collaboration story, which is all around libappindicator
> and StatusNotifier / dbusmenu.
> One year ago, libappindicator was rejected because it needed integration
> in GNOME Shell and Gtk+. Three days, Unity was unveiled, and everything
> went well with considering Ubuntu community the "bad guys" that forked
> GNOME, starting with Ayatana. I of course know this is not true, but
> this is the impression I got from the outside (I only started
> contributing to GNOME some months later).
> Today, on the other hand, things reversed. Public opinion is now that
> GNOME rejected, and still is opposing, Canonical per se. And of course,
> all the flaming around GNOME Census didn't help here. We don't want a
> large part of our user base to consider GNOME Shell a Red Hat project
> (again, this is what is perceived from the outside).
> First, because this is not true: not just Novell, Intel, and all the
> various other companies, but also a great of individuals are making up
> what GNOME 3 will be, in Fedora, OpenSuse, Debian, Gentoo, Arch and
> maybe Ubuntu as well.
> Second, because even if all developers were paid by one organization, we
> would have failed if we didn't pass the message that GNOME is a body, a
> project, and an organization, but most important GNOME is a community of
> people, working for the advancement of free software.
> We're about to release GNOME 3. We need the best publicity to have this
> adopted by the majority of people. After all, our goal is a GNOME
> desktop on every system, right? But if people switch to Xfce or KDE or
> Unity (or, ugh, Mac OS and Windows) for political issues with the
> project, rather than usability, design, technical bugs, then we're
> wasting our precious developer time.
> So I think we should give Canonical and the general public a big signal
> of collaboration. It doesn't matter if this will have no direct effect
> in terms of code and upstreaming of patches, we'll have done the right
> thing and people will know.
> The small step I'm talking about is support of DBusMenu icons in GNOME
> Shell Message Tray. Yes, it does not fit the design (which calls for
> notifications, not menus) and it is not used by anything inside GNOME
> now. But code is there, in a bug where I proposed for the status area;
> it would require some changes to adapt to last Gnome Shell version, but
> is mostly fine, and has no external dependencies (implements the DBus
> protocol directly).
> Anyway, the reason I'm proposing this is not technical (libnotify with
> persistence is by far better than StatusNotifier, I think we all agree
> here), it is political.
> We need to show we're open to technologies developed elsewhere, no
> matter how dirty they are. Look at browsers and HTML5, which is the most
> horrible application platform ever invented by man: they're all
> competing on who is be the most compatible with the others and with the
> spec.
> I hope this will start a positive discussion, at least to make sure
> we're not ignoring this, which is a serious issue from a PR standpoint.
>
> Giovanni Campagna
>
> _______________________________________________
> gnome-shell-list mailing list
> gnome-shell-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-shell-list
>



-- 
Un saludo,
Alberto Ruiz