Not to criticize your decision, but just to correct a couple of factual
details in your e-mail:
On Thu, 2010-05-06 at 12:20 -0400, Dan Winship wrote:
As for the trayicons in the message tray, it is possible that
tray-side-menu-rendering, as in libappindicator, would be useful for our
design
belatedly...
On Fri, 19 Feb 2010 10:42:02, Olav Vitters wrote:
On Thu, Feb 18, 2010 at 09:42:58PM -0600, Ted Gould wrote:
Q: Does this fit the the design goals for GNOME Shell?
A: I can't speak for the designers of GNOME Shell but they've talked
about how the top panel should behave like a
On Wed, 2010-02-24 at 15:32 +0100, Alexander Larsson wrote:
In gnome-bluetooth, I'd like to have bold menu items to represent
connected devices. I would also like to have some control over
whether
device names will be ellipsised (or how). Both of which are
currently
not possible with
One thing I forgot to point out initially is that there has been some
discussion of the StatusNotifier 'spec' that is used here, on
xdg-list:
http://lists.freedesktop.org/archives/xdg/2010-January/011228.html
___
desktop-devel-list mailing list
On Mon, 2010-02-22 at 00:25 +, Bastien Nocera wrote:
On Mon, 2010-02-22 at 11:18 +1100, Danielle Madeley wrote:
On Fri, 2010-02-19 at 22:54 -0600, Ted Gould wrote:
It would be much cleaner to
either expose the underlying dbus api or proxy something that is
explicitly designed
On Fri, 2010-02-19 at 22:54 -0600, Ted Gould wrote:
It would be much cleaner to
either expose the underlying dbus api or proxy something that is
explicitly designed with this in mind: GtkActions.
That's a great idea. What do you think would be a good API/name for a
function that did
On Mon, 2010-02-22 at 11:18 +1100, Danielle Madeley wrote:
On Fri, 2010-02-19 at 22:54 -0600, Ted Gould wrote:
It would be much cleaner to
either expose the underlying dbus api or proxy something that is
explicitly designed with this in mind: GtkActions.
That's a great idea. What
On Thu, Feb 18, 2010 at 09:42:58PM -0600, Ted Gould wrote:
Q: Does this fit the the design goals for GNOME Shell?
A: I can't speak for the designers of GNOME Shell but they've talked
about how the top panel should behave like a menu bar in many ways.
This would definitely support that.
Hi;
I would like to propose libappindicator as an external dependency.
libappindicator is a simple library that provides a way for an
application to put a menu inside an application specific area, most
typically on a panel. It also provides a fallback to generic KDE
Status Notifier Item and
Le vendredi 19 février 2010, à 14:16 +0100, Christian Persch a écrit :
Hi;
I would like to propose libappindicator as an external dependency.
libappindicator is a simple library that provides a way for an
application to put a menu inside an application specific area, most
typically on a
Hi;
Am Fri, 19 Feb 2010 09:18:10 -0600
schrieb Cody Russell brats...@gnome.org:
On Fri, 2010-02-19 at 14:16 +0100, Christian Persch wrote:
Also, why is this LGPL 23-only instead of the usual LGPL
2.1-or-later?
Because seriously, everything should be this way. None of us should
be saying
On Fri, 2010-02-19 at 10:42 +0100, Olav Vitters wrote:
On Thu, Feb 18, 2010 at 09:42:58PM -0600, Ted Gould wrote:
Q: Does this fit the the design goals for GNOME Shell?
A: I can't speak for the designers of GNOME Shell but they've talked
about how the top panel should behave like a menu
On Fri, 2010-02-19 at 11:00 +0100, Frederic Peters wrote:
I would like to propose libappindicator as an external dependency.
libappindicator is a simple library that provides a way for an
application to put a menu inside an application specific area, most
typically on a panel. It also
On Fri, 2010-02-19 at 14:16 +0100, Christian Persch wrote:
I would like to propose libappindicator as an external dependency.
libappindicator is a simple library that provides a way for an
application to put a menu inside an application specific area, most
typically on a panel. It also
On Fri, 2010-02-19 at 16:34 +0100, Christian Persch wrote:
Really? The FSF *recommends* that you add the or later clause; see
e.g. [1].
And if you are concerned about what the later [L]GPL version will say,
you should at least keep open the possibility to use it, by
designating
a trusted
On Thu, Feb 18, 2010 at 10:42 PM, Ted Gould
Q: Shouldn't this be in GTK+?
A: Apparently not.
Huh ? Not a very helpful answer. If you are proposing an API that
directly conflicts with something that is already provided in GTK+,
you should really have a better one...
Looking at the api docs
On Fri, 2010-02-19 at 23:20 -0500, Matthias Clasen wrote:
If you are proposing an API that
directly conflicts with something that is already provided in GTK+,
you should really have a better one...
I guess I don't feel like it's a conflict. I feel like it's an
extension similar to how other
17 matches
Mail list logo
