Re: GTK+ Application class

[Tristan Van Berkom <tvb gnome org>]

Rodrigo Moya wrote:
[...]
> > That could be a route to explore - I think its really important to
> > keep GtkWindow really simple in that respect though - it could be
> > a dialog - it could be a popup window, a popup menu - or even a tooltip,
> > So I would suggest that if we bind such logic into GtkWindow - making
> > it some kind of hybrid composite widget - we should definitly do
> > that in a GtkAppWindow subclass (that could be then used by the
> > GtkApplication in question).
>
> and why not have:
>
> gtk_window_new -> as it is now
> gtk_window_new_dialog (buttons,...)
> gtk_window_new_main_app(menus, toolbar, etc)
>
> ?

Simple - dialogs already pull in alot of irrelevant crap into
the gtkwindow as a composite widget (response id management,
embedded mainloop running etc, logic that is particular of a dialog).

A tooltip or a context menu is a GtkWindow - a tooltip is not a
dialog and a tooltip is not a "main_app" either, I'm convinced
that adding such a convenience wrapper to transform a GtkWindow as is
into a composite widget will undoubtedly pull in more "main_app" related
logic, accessories, more convinience - basicly alot of cruft that dont
need to be associated with a base class that is currently strictly/simply
a toplevel widget in gtk+ (maybe not that strictly, but should be IMO), and
is way way complex enough as it is.

That is not to mention the extra headache and hackery/trickery I would
have to play to handle the GtkWindow genericly in Glade, consider that
twisted "items" property on the combobox that when libglade finds an item -
it will create the liststore for the combobox as if it were created with
_new_text()... I just think we'll have a much more powerfull/simple toolkit
all around if stick to simple building blocks that make sence.

Cheers,
                 -Tristan