Re: future of development for the desktop

["Jasper St. Pierre" <jstpierre mecheye net>]

On Mon, Jun 11, 2012 at 6:43 PM, Enrico Weigelt <weigelt metux de> wrote:
> * Gour <gour atmarama net> wrote:
>
>> Found it...it talks about gtk3 2x slower than gtk2 which I really did
>> not notice and cannot say how good that benchmark is to reflect real
>> speed.
>
> Well, AFAIK, gtk had become much more dynamic than its older versions.
> Maybe that's the problem: too many dynamic (heap) allocations,
> lookups, etc, etc.

Are you sure that's the cause of a slowdown? Did you make observations
and measure data?

> hmm, what could we possibly do about it ?
>
> Perhaps support efficient static allocations (.data segment), combined
> with a DSL (and an, maybe even platform/target specific compiler) for
> expressing the UI structures - something like Glade's XML files, but
> meant for compiling instead of dynamic loading.
>
> Just some examples.
>
> Menus: (picked the example from the gtk tutorial (*1))
>
> <menu id="main_menu" static="true" readonly="true">
>    <submenu title="/_File">
>        <item title="/_File/_New" hotkey="<control>N" handler="print_hello" />
>        <item title="/File/_Open" hotkey="<control>O" handler="print_hello" />
>        <item title="/File/_Save" hotkey="<control>S" handler="print_hello" id="save" readonly="false"/>
>        <item title="/File/Save _As" id="main_menu_save_as" readonly="false"/>
>        <separator />
>        <item title="/File/Quit" hotkey="<control>Q" handler="gtk_main_quit" />
>    </submenu>
>    <submenu title="/_Options" />
>        <item title="/Options/Test" />
>    </submenu>
>    <submenu title="/_Help" align="right">
>        <item title="/_Help/About" />
>    </submenu>
> </menu>
>
> This notation has some interesting aspects:
>
>    * the id attribute of the menu tells the menu compiler how the menu variable
>      (or macro) should be named. the compiler might also create several helper
>      inline functions macros or macros for operating on that menu (at least
>      for initialization and destruction)
>    * the entries for save and save-as also have id's, which just means they should
>      be accessible from the code as variables (or macros) and provide helper
>      macros/functions
>    * the static=true tells the menu compiler to generate some static struct (in .data)
>    * the menu's id will be used for the generated variable name
>    * the readonly=true tells it that the we never want to change anything here,
>      so it can decide to put that even into .cdata
>    * the item title's are just the gettext keys for the visual text, *not* the
>      path as used in GtkItemFactoryItem (the hierachy information is already
>      encoded in the XML structure)
>    * the hotkeys could be even translated into some (perhaps even platform
>      specific) input event code (so we dont need any mapping at runtime)
>    * handler functions are expected to be already (prototype-) defined
>
> In the end, the compiler will generate some .h and .c file holding all the code
> for that menu and it's items.
>
> Our application might now initialize the menu (if there's some initialization
> needed at all) by calling GTK_MENU_main_menu_init(). It can enable/disable the
> save entry via GTK_MENU_ITEM_main_menu_save_enable(b). (<- b is a boolean flag).
>
>
> By this approach we could also describe all the individual widgets,
> windows, etc, by our own DSL and let the compiler handle the actual
> code generation. Initial versions would just translate to the current
> object types (hmm, shall we call that "classes" ? ;-o), later versions
> would use specialized ones, where it also can directly generate
> internal structures.
>
> This approach, IMHO, has several advantages:
>
> a) we can do more RAD (maybe not that far as with Glade's dynamic
>   loading) and make the whole application code easier to read/write
> b) do performance/size optimizations behind the scenes, without
>   having to touch individual applications (once they're ported to
>   that new approach, of course ;-)).
>
>
> Maybe we shoud review a bunch of smaller and larger gtk applications
> and destill out some requirements catalog for that.
>
>
> What do you think about that idea ?
>
>
> cu
>
> [1] http://www.gtk.org/tutorial1.2/gtk_tut-13.html
> --
> ----------------------------------------------------------------------
>  Enrico Weigelt, metux IT service -- http://www.metux.de/
>
>  phone:  +49 36207 519931  email: weigelt metux de
>  mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
> ----------------------------------------------------------------------
>  Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
> ----------------------------------------------------------------------
> _______________________________________________
> gtk-list mailing list
> gtk-list gnome org
> https://mail.gnome.org/mailman/listinfo/gtk-list



-- 
  Jasper