Re: GTK+ Application class

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]