Re: [gtk-list] GLE, a first draft

[Tero Pulkkinen <terop students cc tut fi>]

Tim Janik <Tim.Janik@Hamburg.Netsurf.DE> writes:
> GLE is to become the Gtk+ Layout Engine, which pretty much describes
> what it actually does.
> my goal is to simplify application building using the Gtk+ toolkit in
> general. the application programmer should only care about writing the
> apropriate signal handlers, and the layout can be composed by clicking
> and dragging widgets on an application window or editing the widget
> tree of a certain window along with modifying the properties of certain
> widgets. once a programmer has registered his signal handlers/callback
> functions with GLE, he should be able to connect them on the fly to
> any widget at will.

What you've been thinking sounds really good.

I've been thinking of similar thing too... Something that makes applications
independent of the gui used, and your ideas look exactly like that.

I've been thinking of the following development cycle for applications
needing GUI:

1) initial gui (programmers rarely have time to do this one well... but
   it gives ideas of what the application needs from the user)
2) coding (corba?) interface for the application and implementing 
   functionality based on original user interface
3) improving the gui... the functionality is updated...
4) Shipping the product
5) end user modifying the gui to move menu items/functionality, adding
   menu items to run shell scripts -- maybe internationalism support for
   new languages or target audiences could be added after shipping, etc...

> if the programmer is in the need to retrive a certain widget pointer
> e.g. the widget pointer to the main window, this should be achivable
> as simple as a call like window = gle_widget_handle ("MainWindow")
> (if he had named it so).

Also, the gui editor should also be able to ask application what names
are available and what kind of objects they are(input/output, type of
information etc). That way the gui editor could generate part of the
gui or make manual gui creation much easier. This requires that GUI
editor needs to be able to figure out names of properties and types of
properties.

Thus GUBI could be used to create the gui without information from the
application, but if it can read what properties are available and
needed by the application, the only thing people creating the gui
needs to do is to select proper gui element from several widgets that
can output filenames or dates or other types. This way also position
of scrollbars and unimportant things for the application developer
need not be fixed inside the application. (think what this does for
example to gimp's toolbar - if the gimp itself only has information
that these services are available and GUBI could be used to create
different toolbars after the product have been shipped...)

Applications should be coded in terms of what the application requires
from the user (like in terms of filenames, strings, dates, numbers
etc, instead of in terms of file_selection_dialog, text_widget,
calendar_widget or scrollbar). Still applications need access to widgets
or parts of widgets and to handle different kinds of events coming
from widgets - but main development should not be done with widgets at
all.

> now i thank you for your patience and am curious about your comments!

Hope this helps.

-- 
-- Tero Pulkkinen -- terop@modeemi.cs.tut.fi --