>other apps on the same computer. The lengths these tools go to >in replicating real-world controls like dials, which are awful >to use with a mouse, is both charming and repulsive.
actually, they're extremely wonderful to work with a mouse when properly designed. my dials use the rms distance from the dial center as the primary controller, so you can move in any direction, not in a circle. then i add modifier keys to scale the rate of change. i've also added code that optionally scales based on the x-axis distance from the dial center, so that if you move a long way from dial and then go up and down, you get large changes, but if you are close to the dial center, you get small ones. all in all, its a vastly more powerful numeric value controller than anything offered by a "standard widget set". the same goes for 2D pucks moved around on a rectangle to control 2 parameters at the same time. you folks writing spreadsheets, IDE's, editors and system control panels probably never come across the need to control parameters in the way that audio stuff does. >Like Havoc, I understand the advantages of sticking to standard GTK >widgets. But doing so might be suicidal for a nascent standard in >the music software world. Still, I would stay inside a GTK framework >for the compliance and compatibility reasons Havoc gives. his reasons are good ones. but what of the developers who want to write VST hosts with Qt (or even Motif, god help them)? > For >this reason, Canvas seems like the way to go, since you should >be able to mix i18n widgets like text entry boxes together with >custom cutesy pixmap buttons. That won't work. The VSTGUI API wouldn't permit such a distinction. And besides, the canvas has some oddities if you start mixing widgets and pixmaps (quite ignoring the phenomenal ugliness of the GTK+ widgets under the default GTK+ theme to start with :) > And since I'm eagerly awaiting >the announcement of a GNOME-based VST work-a-like, I don't object >to restricting plugin-using apps to the GTK main loop. I refuse to use audio applications that use desktop environments. The problem space that GNOME & KDE address (at least for now) is orthogonal to the one faced by audio+MIDI apps. We already have seen a number of cool applications that have chosen KDE or GNOME for nothing more than some particular chunk of configuration management or integration into some kind of app toolbar - the result is that at least 50% of the linux population can't or won't use them. it makes me really angry. i think that every person sitting down thinking about using KDE or GNOME should first ask themselves "is the feature that i get from the desktop environment worth excluding a huge part of my potential user base?" i would also differentiate between those parts of each toolkit that really can be used standalone and those that are integral to the overall system. i routinely use libxml2, for example, despite not having GNOME installed on my machine. sorry to sound so negative when i know you were passing on some encouragement. but these issues, being down on graphical widgets and using desktop envs. really gets me worked up :) --p _______________________________________________ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
