Re: [gtk-list] Thirdparty widgets and Guile

Marius Vollmer <> writes:

> Hi,
> what do you think about this?
> Wrapping 3rd party widgets
> --------------------------
> When writing new widgets for Gtk you should provide a stylized
> description of them, just like the core Gtk package provides
> "gtk.defs"
> Write your own defs file and install it along with the new widgets.
> If your widget (or the package of all widgets that you want to treat
> as one unit) is called "foo", call the defs file "foo.defs" and
> install it as <prefix>/share/gtk/foo.defs

Well, sounds good. But there are a few problems that make it sound a
bit impractical for now in general. One is the problem Ken pointed out
with the current incompleteness of the defs format. The other is that
many systems don't have a good way of having one dynamically loaded
module link against another.

With Perl for example, if loads links against, and
then links against, then they will be linked
against different instances of the library! This is easy enough to
handle on ELF systems (and some others), so maybe (thinking about
Perl) it will be enough to get the necessary small patch added to Perl
and live with things not working on older systems like SunOS. The
other alternative is to use the horrible hack of accessing all Gtk
functions through a virtual table. (This is done by the Tk module for

Third party widgets are also in general a sticky issue.

- If every widget is distibuted separately, there will be a horde of
incompatible widgets floating around, and no-one is going to be able
to compile any Gtk programs.

- If we add everything to Gtk, then Gtk will become horribly bloated
with trivial widgets, and with widgets that sort of work, but aren't
really right. (Because people, for good reason, want to get things
working, not spend years figuring out the best way.)  And we'll have
to leave them all in, because otherwise we'll break things.

- So we should just discourage people from writing widgets altogether,
unless they can spend the time to get it right. ;-) But then we miss
out on reuse, and some things, like a Grid widget, just can't be done
completely in a weekend of work.

- Perhaps the solution _is_ to distribute everything separately, and
just make things really easy to find, easy to compile and very
standard. (A mini-CPAN, so to speak, to go back to Perl) But even at
simplest level getting this set up would be a ton of work.

- Another possibilty is to bundle extra widgets into a package
separate from Gtk itself. (Like the Tix library for Tcl/Tk).  This
would have the advantage that it would warn developers that if they
want to be completely standard, they should stick to the widgets in
Gtk itself, but if they were willing to deal with more unstable/less
tested code, they could use the Gtk-extras library as well. On the
other hand, this combines some of the disadvantages of the first two
approaches - an extra thing to compile and keep up to date, and a lot
of bloat that people don't need.

Not too be discouraging - just pointing out some of the issues
involved here. But certainly a standard way of handling language
bindings will be a component of whatever solution we end up


[ not sent to the gnome list, because I've sort of diverged frmo
  the original topic ]

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