Re: Pluggable widget types and implementations

2006-12-08 Thread Tim Janik
On Fri, 8 Dec 2006, Damon Chaplin wrote: > On Fri, 2006-12-08 at 13:13 +0100, Tim Janik wrote: >>> Applications could then use different sets of widgets for different >>> parts of the interface, just by switching the default factory: >>> gtk_set_default_object_factory (factory); >> >> the only d

Re: Pluggable widget types and implementations

2006-12-08 Thread Tim Janik
On Fri, 8 Dec 2006, Tristan Van Berkom wrote: > On Fri, 2006-12-08 at 17:49 +0100, Tim Janik wrote: > [...] >>> This abstraction would ensure that there is no confusion at the GType >>> level, if we start substituting types at the GType level then types >>> will inevidably be substituted underneat

Re: Pluggable widget types and implementations

2006-12-08 Thread Tristan Van Berkom
On Fri, 2006-12-08 at 17:49 +0100, Tim Janik wrote: [...] > > This abstraction would ensure that there is no confusion at the GType > > level, if we start substituting types at the GType level then types > > will inevidably be substituted underneath unsuspecting code, that > > doesnt sound safe to

Re: Pluggable widget types and implementations

2006-12-08 Thread Tim Janik
On Fri, 8 Dec 2006, Tristan Van Berkom wrote: > On Fri, 2006-12-08 at 16:27 +0100, Tim Janik wrote: > [...] >>> >>> i.e. >>> gtk_stock_appoint_type ("file-chooser", >>> MYLIB_TYPE_SEXY_FILECHOOSER); >> >> this is simply not possible without introducing a seperate widget typ

Re: Pluggable widget types and implementations

2006-12-08 Thread Tristan Van Berkom
On Fri, 2006-12-08 at 16:27 +0100, Tim Janik wrote: [...] > > > > i.e. > > gtk_stock_appoint_type ("file-chooser", > > MYLIB_TYPE_SEXY_FILECHOOSER); > > this is simply not possible without introducing a seperate widget type > naming system which we aren't planning to do (e.

Re: Pluggable widget types and implementations

2006-12-08 Thread Tim Janik
On Fri, 8 Dec 2006, Tristan Van Berkom wrote: > On Fri, 2006-12-08 at 14:36 +, Damon Chaplin wrote: >> I don't have any specific examples. I just thought using a factory was a >> more flexible approach - better than adding XXX_appoint_type() functions >> for each widget. > > Would there be an

Re: Pluggable widget types and implementations

2006-12-08 Thread Tristan Van Berkom
On Fri, 2006-12-08 at 14:36 +, Damon Chaplin wrote: > On Fri, 2006-12-08 at 13:13 +0100, Tim Janik wrote: > > On Fri, 1 Dec 2006, Damon Chaplin wrote: > > > > > On Tue, 2006-11-28 at 14:53 +0100, Tim Janik wrote: > > >> Hey all, > > >> > > >> this is a proposal for allowing pluggable widget t

Re: Pluggable widget types and implementations

2006-12-08 Thread Damon Chaplin
On Fri, 2006-12-08 at 13:13 +0100, Tim Janik wrote: > On Fri, 1 Dec 2006, Damon Chaplin wrote: > > > On Tue, 2006-11-28 at 14:53 +0100, Tim Janik wrote: > >> Hey all, > >> > >> this is a proposal for allowing pluggable widget types and implementations, > >> assorted bug report: http://bugzilla.gn

c/invoke for gobject-introspection?

2006-12-08 Thread Michael Lawrence
Hi, I understand that one of the hurdles for gobject-introspection is the fact that its dependency libffi is not actively maintained. Has anyone considered c/invoke? http://www.nongnu.org/cinvoke/ Michael ___ gtk-devel-list mailing list gtk-devel-lis

Re: Pluggable widget types and implementations

2006-12-08 Thread Tim Janik
On Fri, 1 Dec 2006, Damon Chaplin wrote: > On Tue, 2006-11-28 at 14:53 +0100, Tim Janik wrote: >> Hey all, >> >> this is a proposal for allowing pluggable widget types and implementations, >> assorted bug report: http://bugzilla.gnome.org/show_bug.cgi?id=356864 > > How about a sort of widget/objec

GtkDrawingArea - Circles - Gdk-DirectFB-Message: unimplemented

2006-12-08 Thread rafeeqh shaik
Hi I crosscompiled all the gtk+ libraries ARM processor and when i run the gtkperf i am getting the the following results. I chaged the count for gtkperf. Information: ./gtkperf ===| DirectFB 1.0.0-rc1 |=== (c) 2001-2006 United