Re: GTK+ Application class

[Xavier Bestel <xavier bestel free fr>]

On Thu, 2006-10-26 at 15:25 +0200, Rodrigo Moya wrote:
> On Thu, 2006-10-26 at 15:41 +0300, Mart Raudsepp wrote:
> > On Thu, 2006-10-26 at 10:39 +0200, Xavier Bestel wrote:
> > > On Thu, 2006-10-26 at 10:26 +0200, Rodrigo Moya wrote:
> > > 
> > > > yay, so it's probably better to have convenience functions on
> > > > GtkApplication, like:
> > > > 
> > > > gtk_application_create_dialog
> > > > gtk_application_create_main_window
> > > 
> > > The problem I see with this approach is that the 'typical app window'
> > > concept is evolving (we saw the introduction of toolbars, statusbars,
> > > maybe we will need a drag-n-drop-to-save-document icon or macosx-like-
> > > side-menus or whatever the next fad is as a standard feature).
> > 
> > Indeed it can evolve quite a bit.
> > 
> > Considering what a typical dialog/toplevel usually contains, it could be
> > beneficial if this GtkAppWindow would also be capable of hiding some of
> > the layout information from the programmer - so that it could become
> > more themeable in that area, instead of requiring packing all this into
> > an application programmer selected GtkContainer (usually a GtkVBox). For
> > example see many of the blue sky ideas on gnome-look[1] and other
> > places[2].
> > 
> > a set_gadget (statusbar, menubar, etc) should give most of what's needed
> > there, but I'm not sure that covers all cases.
> > 
> yeah, usually a "main app" window has 4 areas: menubar, toolbar, status
> bar and working area (which is setup by the app as needed), so why can't
> we just have set_* functions for all of them? Then, if we change the
> layout, like in the gnome-look mockup, we only need to change the
> GtkApplication implementation to lay out things differently.

I don't think the problem is simply in the layout. Maybe there will be a
5th area to deal with, and you 4-areas-only rigid structure, even with
it's à la carte layout, won't fit.

	Xav