On Fri, 2011-12-09 at 08:47 -0500, Ryan Lortie wrote:
On Fri, 2011-12-09 at 09:50 +0100, Alexander Larsson wrote:
Windows actually has an application menu thing. If you right-click on
the application on the panel you can get app-specific operations in the
menu. I'm not sure if the normal
On 12/12/2011 03:24 AM, Matthew Brush wrote:
On 12/11/2011 12:14 PM, Stefan Sauer wrote:
On 12/09/2011 01:00 AM, Ryan Lortie wrote:
hi,
Today I landed the GMenuModel work on glib master. A release will be
following shortly.
Just one quick question - why is this in GLib? Is that to allow
On Mon, 2011-12-12 at 10:18 +0100, Stefan Sauer wrote:
On 12/12/2011 03:24 AM, Matthew Brush wrote:
On 12/11/2011 12:14 PM, Stefan Sauer wrote:
On 12/09/2011 01:00 AM, Ryan Lortie wrote:
hi,
Today I landed the GMenuModel work on glib master. A release will be
following shortly.
On 12/12/2011 03:24 AM, Matthew Brush wrote:
On 12/11/2011 12:14 PM, Stefan Sauer wrote:
On 12/09/2011 01:00 AM, Ryan Lortie wrote:
hi,
Today I landed the GMenuModel work on glib master. A release will be
following shortly.
Just one quick question - why is this in GLib? Is that to allow
On 12/12/2011 10:45 AM, Ryan Lortie wrote:
On Sun, 2011-12-11 at 18:24 -0800, Matthew Brush wrote:
My (probably misguided) opinion is that if this type of stuff can't go
into GTK+ for some reason, there should be a `glib-ui` or `glib-gnome`
library or something like this. I have doubts how
Hi,
It would be nice if the new menu system can still
support dynamic (programmatic) adding and deleting
submenu/menuitems, just like what we already have
now in gtk2. Examples are the Favorite menu in
MS IE, and the Bookmarks in other browsers.
If possible, would you consider bringing back the
On 12/11/2011 12:14 PM, Stefan Sauer wrote:
On 12/09/2011 01:00 AM, Ryan Lortie wrote:
hi,
Today I landed the GMenuModel work on glib master. A release will be
following shortly.
Just one quick question - why is this in GLib? Is that to allow
command-line apps to have a menu?
I tried to
On 9 December 2011 04:34, Allin Cottrell cottr...@wfu.edu wrote:
On Thu, 8 Dec 2011, Ryan Lortie wrote:
Today I landed the GMenuModel work on glib master [...]
Menubars are no longer a per-window concept. They are now set for the
entire application. This is done for two reasons:
1) every
hi;
On 9 December 2011 09:11, Petr Tomasek toma...@etf.cuni.cz wrote:
On Thu, Dec 08, 2011 at 07:58:50PM -0500, Ryan Lortie wrote:
hi,
On Fri, 2011-12-09 at 01:34 +0100, Andrea Bolognani wrote:
Does this mean different windows belonging to the same application will
not be able to have
On Fri, Dec 9, 2011 at 6:11 PM, Petr Tomasek toma...@etf.cuni.cz wrote:
On Thu, Dec 08, 2011 at 07:58:50PM -0500, Ryan Lortie wrote:
hi,
On Fri, 2011-12-09 at 01:34 +0100, Andrea Bolognani wrote:
Does this mean different windows belonging to the same application will
not be able to have
Le jeudi 08 décembre 2011 à 19:00 -0500, Ryan Lortie a écrit :
1) every app already has the same menubar (content) in each window
You obviously didn't write that email using evolution...
Regards,
Xavier Claessens.
___
gtk-devel-list mailing list
Hey guys,
just one thing that I don't have quite clear...
how will the extensibility be managed for the menus?
i.e adding a new menuitem from a plugin.
Regards.
On Fri, Dec 9, 2011 at 11:40 AM, Xavier Claessens xclae...@gmail.com wrote:
Le jeudi 08 décembre 2011 à 19:00 -0500, Ryan Lortie a
hi,
On Fri, 2011-12-09 at 14:39 +0100, Nacho wrote:
just one thing that I don't have quite clear...
how will the extensibility be managed for the menus?
i.e adding a new menuitem from a plugin.
If the plugin can gain access to the GMenu then it can modify it
(adding/removing items, etc).
In
On Fri, 2011-12-09 at 09:50 +0100, Alexander Larsson wrote:
Windows actually has an application menu thing. If you right-click on
the application on the panel you can get app-specific operations in the
menu. I'm not sure if the normal usecase for these match what the app
menu is typically used
hi Tristan,
Thanks for the questions.
On Fri, 2011-12-09 at 14:56 +0900, Tristan Van Berkom wrote:
I think that the (twice) mentioned solution to this problem sounds
elegant enough, i.e. if you have 2 windows with different menubars
then they can easily be '2 applications' at least in terms
On Fri, 09 Dec 2011 09:14:31 -0500
Ryan Lortie de...@desrt.ca wrote:
Back to the extendablity question: I've played with this before and
come up with a semi-reasonable system to support it. There would be a
type='' attribute added to menuitems. If this attribute was present
on the item then
hi Jannis,
On Fri, 2011-12-09 at 15:34 +0100, Jannis Pohlmann wrote:
I guess this is unrelated but I have a question regarding extensions as
well. Will there be functionality similar to GtkUIManager-based merging
with placeholders in the GTK part of GMenu?
We use this heavily in Thunar to
On Fri, 2011-12-09 at 09:14 -0500, Ryan Lortie wrote:
The bad news is this: I don't expect this to be supported on a
per-application basis or to be possible to use at all from the menubars
of an application. We need to make sure menus will continue to work on
all platforms (including the mac
On Fri, 2011-12-09 at 09:56 -0500, Ryan Lortie wrote:
The way this works is with questions.
Uhm. *sections.
Don't write email while trying to have a conversation at the same time,
kids :)
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
hi,
On Fri, 2011-12-09 at 09:58 -0500, Shaun McCance wrote:
I find it extremely unfortunate that GTK+ will be restricted to using
the least common denominator. That's the kind of thing you get from
wrapper libraries like wxWidgets.
In particular, from what I can tell, it means the
On 12/09/2011 01:00 AM, Ryan Lortie wrote:
We may add other types of menus in the future. A jumplist/dock menu
comes to mind.
Do you plan on/Would the current Gmenu infrastructure allow something
like the mockups in [1] ? Especially, menus like the Mega-menu mockup
for EoG adding a dropdown
Will the new api allow one to write a gui that looks and feels
like it was made with the old api?
Thanks,
Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
On Fri, 2011-12-09 at 00:25 -0500, Ryan Lortie wrote:
hi,
On Thu, 2011-12-08 at 19:24 -0800, John Ralls wrote:
I think that you misunderstand how mac os works.
Yes, a single menu bar is displayed at the top of the screen. This is
correct behavior according to Fit's Law, because you
On Fri, Dec 9, 2011 at 9:34 AM, Jannis Pohlmann jan...@xfce.org wrote:
I guess this is unrelated but I have a question regarding extensions as
well. Will there be functionality similar to GtkUIManager-based merging
with placeholders in the GTK part of GMenu?
We use this heavily in Thunar to
hi,
On Fri, 2011-12-09 at 11:12 -0500, Morten Welinder wrote:
Will the new api allow one to write a gui that looks and feels
like it was made with the old api?
Yes.
Simply provide a menubar and no application menu and use
GtkApplicationWindow. You will get the menubar added for you
hi,
On Fri, 2011-12-09 at 16:07 +0100, Steve Frécinaux wrote:
Do you plan on/Would the current Gmenu infrastructure allow something
like the mockups in [1] ? Especially, menus like the Mega-menu mockup
for EoG adding a dropdown menu in the title bar [2] would seem to be
feasible
hi,
Today I landed the GMenuModel work on glib master. A release will be
following shortly.
There is related work in the 'wip/gmenu' branch of Gtk+ that will
hopefully be landing soon. There is a trivial example in
gtk+/examples/bloatpad.c that demonstrates some of the ideas here.
The main
I haven’t looked at the code yet, but a couple questions came to mind
while reading your summary. Hope you don’t mind if I ask them.
Menubars are no longer a per-window concept. They are now set for the
entire application. This is done for two reasons:
1) every app already has the same
hi,
On Fri, 2011-12-09 at 01:34 +0100, Andrea Bolognani wrote:
Does this mean different windows belonging to the same application will
not be able to have different per–window menubars? I’m thinking about
Empathy here, with its Buddy List and Conversation windows having
different menubars,
On Fri, 2011-12-09 at 01:34 +0100, Andrea Bolognani wrote:
I haven’t looked at the code yet, but a couple questions came to mind
while reading your summary. Hope you don’t mind if I ask them.
Menubars are no longer a per-window concept. They are now set for the
entire application. This
On Thu, 08 Dec 2011 19:00:01 -0500
Ryan Lortie de...@desrt.ca wrote:
The main thing to understand about this work is that we are changing
how menus work in Gtk+. The days of constructing a GtkMenuBar widget
and packing it into a VBox at the top of your window are gone.
First of all: I like
On Dec 8, 2011, at 4:58 PM, Ryan Lortie wrote:
hi,
On Fri, 2011-12-09 at 01:34 +0100, Andrea Bolognani wrote:
Does this mean different windows belonging to the same application will
not be able to have different per–window menubars? I’m thinking about
Empathy here, with its Buddy List and
On Thu, 8 Dec 2011, Ryan Lortie wrote:
Today I landed the GMenuModel work on glib master [...]
Menubars are no longer a per-window concept. They are now set for the
entire application. This is done for two reasons:
1) every app already has the same menubar (content) in each window
Whoa!
hi,
On Thu, 2011-12-08 at 19:24 -0800, John Ralls wrote:
I think that you misunderstand how mac os works.
Yes, a single menu bar is displayed at the top of the screen. This is
correct behavior according to Fit's Law, because you can bang the
pointer to the top of the screen and it can't
On Thu, 2011-12-08 at 19:24 -0800, John Ralls wrote:
On Dec 8, 2011, at 4:58 PM, Ryan Lortie wrote:
hi,
On Fri, 2011-12-09 at 01:34 +0100, Andrea Bolognani wrote:
Does this mean different windows belonging to the same application will
not be able to have different per–window
35 matches
Mail list logo
