Subject: Re: [linux-audio-dev] ladspa GUI proposal
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Wed May 31 2000 - 00:41:38 EEST
>be done so that it's not tied to a particular toolkit. That need not be worse
>than writing a widget for a specific toolkit. (After all, gtk+ widgets are
>written using gdk, which is not *that* much nicer than Xlib.)
well, i see your point, but each gtk widget draws upon a lot of
functionality that comes from things like GtkObject. the drawing
routines are certainly nothing more than a wrapper for Xlib, but a
real widget is quite a bit more than this.
>The main disadvantages of this scheme then are:
> - we need to come up with a reasonable set of base widgets
> - customised widgets only work under X11. Ordinary ones work under
> anything.
> - we need to define an interface between the plugin's Xlib using
> functions, and the host
> - it would be hard for people to add pre-existing toolkit widgets
> into a plugin (although for some toolkits it is possible via
> a bit of hackery)
> - custom widgets won't follow all the conventions of the host toolkit
>
>The advantages on the other hand include:
> - toolkit independance
> - easy to use for the majority of cases
> - allows host control or chrome at the host's choosing
> - allows arbitrary widgets to be created and used (eg eq curve editing,
> oscilloscopes)
> - allows pixmap usage if desired
> - could be implemented either via XML or a C api
>
>Does this sound more palatable?
Its certainly worth thinking about. I'll try do that. My main, immediate
(knee-jerk) objection is that even though you've tried hard to make it
sound otherwise, you're really talking about writing another toolkit,
albeit one with a very limited set of widgets, and no high level
support for extensions.
>The main reasons I dislike pixmaps is because of their inflexibility. The
>colours and size of a pixmap cannot be easily altered. As a result, they tend
>to be either too big or too small depending on your resolution, or get scaled
>and become blocky. There's not much chance of a pixmap solution working well
>with a user's preferences for anything; colours, shapes, sizes, fonts etc.
>
>XMMS is a good example of these problems. It uses a pixmap titlebar, instead
XMMS is everybody's favorite whipping boy in this respect. Lets take a
better example. I don't use Enlightenment, but my impression is that
it makes *heavy* use of pixmaps, but does so in a way that doesn't
seem to lead to the kind of complaints that I hear about xmms.
Also, note that pixmap solutions aren't *intended* to cater to user's
preferences, at least not by just setting a "foreground"
attribute. The notion is that they are being used for elements whose
on-screen representation is better made using a complex object rather
than something decomposable into simple fg/bg/edge/fill sections. If
the user doesn't like the particular image used, they can't fix it by
just changing the "color", because there is no such attribute. I don't
see this as a bug or design error; rather, its evidence of a
*different* design strategy. The fact that xmms screws it up doesn't
suprise me; I *feel* that I've seen enough examples of this strategy
working fairly well to suggest that it can work. When it does work, I
think it leads to much more usable interfaces than those built with
typical widget notions such as those built into GTK, Qt and the rest.
--p
This archive was generated by hypermail 2b28 : Wed May 31 2000 - 01:17:02 EEST