Re: Pluggable widget types and implementations

[Tristan Van Berkom <tvb gnome org>]

Ross Burton wrote:
> On Tue, 2006-11-28 at 14:53 +0100, Tim Janik wrote:
>
> > Resulting in gtk_file_selection_new() to return objects of the custom type 
> > gtkfileselector_derived_type, and gtk_printer_selection_new() to return
> > objects of the custom type iface_implementation_type.
>
>
> How would this interact with libglade/GtkBuilder, where dialogs are
> created at runtime?  I'm guessing that GtkBuilder uses g_object_new() to
> construct the objects.

It would be an object created somehow internally by gtk+, either as
an element of a composite widget or the delagate of some application
GObject I suspect, the net result is that you dont have fine grained
control on that portion of the UI anymore.

/me strays a little offtopic...

As someone with a background writing applications for the touchscreen,
I'm happy to see there's been an interest over the last year... my
personal opinion is that the desktop is not for the touchscreen, and that
touchscreen apps are marginally different in the way they interact with
the user and will always be highly customized, I think the best thing
to do for these corner cases (touchscreen, cellphone keybad driven
interfaces etc..) is to make gtk+ more customizable at the widget/object level
as much as possible (example add properties to the GtkScale to make is more
usable on the touchscreen, but let the developer set those properties).

While having a feature that will make virtually any app usable on a
touchscreen interface at the flip of a "touchscreen mode" switch sounds
kindof cute, I know that its of no value to us ("us" here is: touchtunes.com,
the company I write jukeboxes for)... and unless the home pc market is
moving from the mouse pointer to the touchscreen, I dont see much value
in this feature.

So in closure, yeah "appointed types" sound like an interesting way
to have "themable widget implementations" so to speak, the idea doesnt
suck, but I hope it is not a solution to a problem that doesnt exist.

Also, as an afterthought, hows this alternative:
   - Add GtkVirtualKeyboard
   - Add properties to some widgets to make them usable on the touchscreen
   - Extend GtkAction so that it supports all activatable widgets as proxies
     (i.e. GtkButton GtkRadioButton GtkHScale etc...)
   - Use one glade file for the touchscreen, and another glade file for
     the desktop, use GtkActions for a high level of code abstraction
     (some code would be optional on the touchscreen, i.e. virtual keyboard
     handling etc).

That would be a "touchscreen portable" application, with customizable UI
and abstraction, and most importantly it helps to preserve gtk+'s pristine
simplicity that I value so highly :)

Cheers,
                      -Tristan