On Friday 21 June 2002 16.05, Vincent Touquet wrote:
[...]
> >It's like replacing the graphics of a game; drawing a bunch of
> > images for each object, whereas normal ("GTK+ style" themes
> > consist of generic textures and images used by all widgets.
>
> Thats exactly what I'm aiming at :)
> I didn't mean themeability in the themes.org sense of the word.Ok; then we're thinking along the same lines, basically. :-) > Just an abstraction of functionality: > - sliderbars > - rotational knobs from 1-10 > - rotational knobs without beginning and end > ... Yes... Although I'm trying to figure out a way to design a slightly lower level abstraction, where it's more like assembling a very small set of logic building blocks into widgets. For example, a slider bar would be a draggable object tied to a "path" object, that restricts it's movement. A rotational knob would be an object pinned to the background with a single point "patch" that restricts movement to nothing, but allows rotation. > Just how far you can go, I don't know. Same here - but I think you can do a great deal with a sensible design. If you can create a whole game (well, not another Q3A, but anyway) without hacking a single line of code, one would assume that visual GUI building could be slightly more powerful than the Delphi or Visual Basic variants. (BTW, Delphi isn't that far off - if you're into databases... The actual GUI toolkit is still rather "stupid" and restrictive, though.) > Someone mentioned that the xmms coding style was > to be avoided. Actually, I have to agree, although it's not as simple as "XMMS is bad". There are two parts; the GUI and the window management. XMMS messes with *both*, for no good reason, and it doesn't even result in a good user interface. The bypassing of the window manager is just stupid and pointless in this case, and has XMMS integrate poorly no matter what desktop you're using. It doesn't provide anything of use, but it *does* disable most of the nifty features of your favourite WM. There are applications that should preferably use their own internal WM - in some cases, maybe even a whole desktop enviroment, but they are few, and your average media player (which is just supposed to play music while you're hacking :-) is *not* one of them. > I was thinking about some callback model: > you provide the callback to redraw your > knob after you changed the parameters. That's one way, and I definitely think there should be hooks like that. However, I think about 95% of the work can be done by the toolkit, without any application code at all. This goes for the interaction between "logic objects" as well, but I actually think the rendering is the *easy* part in this regard. If you have a rendering library with the usual shapes, images, textures etc, the actual rendering is just a matter of passing it a list of operations with arguments. (Heard of OpenGL display lists...?) Throw in some very basic flow control (iterators, simple conditionals etc), and you have a simple "scripting language" for which code can easilly be generated by something like a structured drawing program. You just draw your GUI as a structured image, and then you select visual objects and connect them to logic objects in various ways to make the GUI dynamic and interactive. > This way you could plug the functionality > of the knobs etc. in your program, In my design, you'd "ask" certain logic objects about some of their properties. (In the slider example; "Knob, where on the path object are you now?" or "Knob, tell me where on the path object you are whenever you're dragged.") > just > by providing the graphics and using > the toolkit you want... Yes. Provide some data generated by that "dynamic structured graphics" (DSG :-) drawing program I'm talking about, and there's not much code left for you to hack WRT the GUI. And anyone can grab your DSG data and start fiddling around with the objects in the editor, pretty much like you can fiddle around with the data of a game. Oh, and it should be possible to implement this on top of any toolkit that supports basic "drawing area" widgets. (I plan to do it for SDL, OpenGL, GTK+ - and possibly Borland's VCL, if I'm bored some day.) > Obviously I must have missed all the difficult parts ;) Well, any design takes at least three times as long to implement as you could possbly imagine - if it works out at all, that is. So, check back in a few years, and I might have something to demo! ;-) //David .- M A I A -------------------------------------------------. | Multimedia Application Integration Architecture | | A Free/Open Source Plugin API for Professional Multimedia | `---------------------------> http://www.linuxdj.com/maia/ -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter | `-------------------------------------> http://olofson.net -'
