On 2011-12-14, at 12:34 AM, Matthias Clasen wrote:
> On Tue, Dec 13, 2011 at 12:21 AM, Tristan Van Berkom wrote:
>
>> GMenuModel in itself is a little stuck, it depends on GActions which
>> are really tied into the whole DBus thing, so even though conceptually
>> it might not be IO, actually it
On Tue, Dec 13, 2011 at 12:21 AM, Tristan Van Berkom wrote:
> GMenuModel in itself is a little stuck, it depends on GActions which
> are really tied into the whole DBus thing, so even though conceptually
> it might not be IO, actually it is an IPC data model (I'm really starting
> to think we sho
On Tue, 13 Dec 2011 at 14:21:37 +0900, Tristan Van Berkom wrote:
> I would have to disagree about treemodel, data models, yes, would
> be nice to push down the stack from way on top in GTK+, but why
> not glib ? Of course I think the treemodel interface would have to
> be re-engineered to reach our
On Tue, Dec 13, 2011 at 6:53 AM, Matthew Brush wrote:
> 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`
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 many
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 many apps linking to
> GIO without GTK+ a
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
comm
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
> >>> fol
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?
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 n
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 a
hi Paul,
On Sun, 2011-12-11 at 16:33 -0500, Paul Tan wrote:
> 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"
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 th
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?
Stefan
> There is related work in the 'wip/gmenu' branc
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 server-
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
automati
On Fri, Dec 9, 2011 at 9:34 AM, 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 allow plu
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, bec
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 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 dropdow
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 searc
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
htt
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 m
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
On Fri, 09 Dec 2011 09:14:31 -0500
Ryan Lortie 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 Gtk would
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, 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
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).
I
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 wrote:
> Le jeudi 08 décembre 2011 à 19:00 -0500, Ryan Lortie a écrit :
>> 1) ever
hi,
On Fri, 2011-12-09 at 09:18 +, jcup...@gmail.com wrote:
> I suppose I could have a single menu tree with everything from every
> window type rolled together, but then I'd need a way to grey out
> irrelevant items per-window, which is almost the same thing as
> multiple menus. And I'd think
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
gt
On Fri, Dec 9, 2011 at 6:11 PM, Petr Tomasek 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 different
hi;
On 9 December 2011 09:11, Petr Tomasek 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 different
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 different per–window menubars? I’m thinking about
> > Empathy here,
On 9 December 2011 04:34, Allin Cottrell 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 app al
On Thu, 2011-12-08 at 19:58 -0500, Ryan Lortie wrote:
>
> > I assume Windows will behave like GNOME 2 here. In the GNOME 2 case, is
> > the app menu collapsed with the menubar somehow?
>
> Correct assumption.
Windows actually has an "application menu" thing. If you right-click on
the applicatio
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–wi
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'
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! W
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
On Thu, 08 Dec 2011 19:00:01 -0500
Ryan Lortie 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 this. I assum
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.
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,
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 sam
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 thi
45 matches
Mail list logo