Re: [gtk-list] Re: Thirdparty widgets and Guile
- From: Marius Vollmer <mvo zagadka ping de>
- To: gtk-list redhat com
- Subject: Re: [gtk-list] Re: Thirdparty widgets and Guile
- Date: 02 Nov 1997 13:03:02 +0100
Owen Taylor <owt1@cornell.edu> writes:
> 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.
Yes, but let's pretend it is complete.
Actually, I plan to introduce a `backdoor' mechanism to slip in
arbitrary extra information for a particular language. I currently
have a file "guile.details" in guile-gtk that contains some Guile
specifica that I don't want to stuff into gtk.defs. These files can
be installed along with the defs files (there will be conventions to
avoid name clashes). The detail file contains such things as type
conversions (that let you specify colors with strings, for example).
The writer of a widget is not supposed to provide such a file for
every stubber out there that uses the defs file. But I'm sure that
these details files will come in handy for quick, pragmatic hacks.
> The other is that many systems don't have a good way of having one
> dynamically loaded module link against another.
Umm, I have to say that I have no experience with this and I intend to
just ignore this issue until it screws us.
I can only imagine that this will be a problem with genuine dynamic
linking (aka dlopening), not with shared libraries that are linked at
build-time.
> 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.
Why should they be incompatible to one another? Ok, it might be a bit
naive to try to link *all* widgets that are out there into your
application...
I think I'll modify the "build-guile-gtk link" command to allow you to
specify only a certain set of widgets.
> - 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.
This can't work, I'm afraid. Being able to disribute widgets
independently from Gtk is important and will happen anyway.
> - 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.
Right.
> - 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.
We can at least try. Unfortunately progress will be very slow on my
part. Getting this up to speed will probably require a few days
undivided attention. Maybe the christmas holidays will provide for
hacking opportunities...
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]