Subject: Re: [linux-audio-dev] Re: chrome
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Thu May 25 2000 - 22:18:26 EEST
>> Except: I'm in interested in getting musicians and sound engineers to
>> use Linux.
>
>Oops; I was primarily interested in making music, and creating tools to
>do this with. Am I on the wrong mailing list?
I don't know about you, but I'm not spending 60-70hrs a week creating
tools that I will be the only user of. That means getting other people
to use Linux and the tools we create.
>> Yes, you can play it too them over and over and show them how good it
>> sounds. But when they can *the same plugins* (or better) using a VST
>> GUI, why bother with Octal, or Linux at all ? Oh, yes,
>
>...
>
>> I think this chrome-aversion is a kind of inverted snobbery on the
>> part of *nix users. If the user is blind, they won't be using a GUI at
>
> It is not "snobbery" to suggest that something other than
>chrome can drive the quality and userbase of an application.
Point well made.
Problem is: there just isn't much evidence for this kind of migration
in the audio/MIDI world yet. For office apps, GTK and Qt and even
Motif are doing a reasonable job of providing people with apps that
look somewhat similar to their Windows counterparts, thus making the
jump in search of stability, flexibility, etc. much less
intimidating. In the case of audio/MIDI apps for Linux, they pretty
much all look like just another office app, which makes the it much
harder for musicians to see why they should start using Linux.
>Also, saying that "chrome isn't essential" isn't the same as
>"chrome-aversion." There is a practical argument against excessive
>chrome, which I'm getting to.
I agree with the notion that "chrome isn't essential". I just happen
to think that its important *enough* that an API/library that doesn't
make optional chrome as easy as, say, vstGUI does is not adequate for
my own goals.
>? I question your assumption that any consistent/host-controlled
>interface approach is going to be "butt ugly." For instance, I'm using
>GTK+ for GNU OCTAL. Now while there are many silly/ugly GTK themes,
>there are also quite a few *really* good-looking ones.
Yes, but the pixmap engine has several key bugs, and is fundamentally
not the same as a "skin". Why not ? The pixmap engine doesn't support
replacing whole objects in the image with pixmaps, just altering how
components of them are drawn. There is no way, for example to use the
pixmap engine to do a pixmap-only button. This is why XMMS doesn't use
GTK themes, amongst other programs that don't. You also can't use a
specifically-colored background for a specific text entry when a
pixmap theme is being used, since the engine takes control of this.
Sure, these are just bugs, and they will be fixed. But I don't
consider the GTK theme engine(s) (though they are *VERY* nice, and I
use them some of them time) to be equivalent to what skins or vstGUI
can do for a program.
It's clear that
>the OCTAL scheme isn't the same as your scheme (no DTD's even) but I do
>not think this is going to be butt-ugly. Early tests have told me quite
>otherwise; that it will in fact look nice. No, maybe not revolutionary
>or mind-blowing; but nice.
Nice is good. Nice is even fine. Its just I've seen a very simple way
to make mind-blowing, and I don't want to be forced to settle for just
"nice".
>And I mean functionally different, not just in appearance. For if the
I only meant appearance. Linux themes (at least for GTK) do not allow
adequate retheming of elements like the scrollbar. It is still defined
as two arrows, a gutter and a bar. The arrows and the gutter are
shared with all other objects that use arrows and gutters. Thats all I
meant.
>If, however, the widgets will need to differ **functionally**, as in
>"the reverb's scrollbar ACTS differently from the sine-wave generator's
>scrollbar" we have a different situation. I think what you're saying is
Well, I'm not saying that, but I might be saying that the
user-interaction model associated with the normal scrollbars in Linux
GUI toolkits is often not ideal for audio applications. Maybe all
audio apps can use a new type of scrollbar, thats fine.
>I am getting to my point now :-). You wrote above that people shouldn't
>claim that "attractiveness, appeal, intuitiveness" etcetera are mutually
>exclusive with power, accessibility, flexibility. You are absolutely
>correct in that there is no such neccessary exclusion. However, you are
>missing an important attribute that can cancel out all those you cited:
>Consistency.
yes, I've read and contributed to this argument in other forums. I
like consistency too. But you are mixing up two things here:
1) consistency of interactive behaviour
- what happens when i click on a knob ? a slider ?
- what happens when i click and drag ?
etc.
2) consistency of appearance
I would contend that most skins, all themes and vstGUI demonstrates
very nicely that you can have (1) without requiring (2).
>The "practical argument" I mentioned at the top of my post is that
>excessive focus on chrome-freedom can tend to cause neglect of the
>usability and consistency aspects, even if only because chrome can take
>so much time to implement.
Sure, if you focus on traditional widget-based approaches to
chrome. If you use the "sets-of-pixmaps approach", the time spent on
it is just the time spent creating and arranging pixmaps, which is a
wholly distinct process from GUI programming.
I was not making the argument that these
>qualities are mutually exclusive, nor did I make the argument that
>somehow wanting a chromey interface makes you a loser (the "arrogance"
>you cited above.) I said nothing of the sort--given that themes.org is
>becoming its own mini-demoscene, I don't know how anyone could really
>maintain such a position.
I don't find themes.org particularly compelling, and i visit it at
least a couple of times a week. Enlightenment is pretty awesome, and
its themes system is very different from GTK+'s. The theme systems in
other WM's is OK, but they solve a very limited set of problems.
>* This is a side issue, but I also object to your throwback stereotype
>of *nix people. If you entertain the (old) idea that *nix people can't
>be artists or musicians or poets or anything besides Un1x HaX0rz, I
>can't say that would be terribly inviting to a non-computer-savvy
>musician or tech who is thinking about switching from Win32 to your
>software on the UNIX or Linux platforms.
I think you need a thicker skin. I *am* a *nix person: I've been
overjoyed with Unix systems for the last 16 years or so. I'm also a
musician, occasionally poetic, and most of the time something a long
way from a Un1x HaX0r. Nevertheless, there is a real truism that most
of the people I know who are fans of Unix (myself frequently included)
have paid very little attention to chrome in our interfaces, and when
challenged about this tend to dismiss chrome as not very important,
even when the questioner is clearly suggesting that it is.
If this strikes you as personal jabbing, I apologize. It was directed
as much at myself as anyone else.
>endless politicizing is actually one of the primary reasons why I
Now *this* pisses me off! "endless politicizing" ? do you mean that
we're not talking about specific chunks of code or other detailed
technical issues ? The issues that are being discussed around LADSPA
are very significant elements of the design. They have profound
consequences for its usage. There are people here with widely
differing points of view on the right way to go, and thus there are
real debates between those points of view. If you want an end to this
kind of thing, then just use your own plugin API where nobody else has
to agree to anything, or come up with a suggestion so clearly a winner
that we all fall into line. I don't think that anyone here is
grandstanding on behalf of their applications, their prowess, their
reputations, or even particular ideologies. There are thoughtful,
insightful contributions from many people, and I think its a great
discussion.
I also think that you, as much as anyone else, have valuable insights
to offer, and have already offered some. Thanks.
--p
This archive was generated by hypermail 2b28 : Fri May 26 2000 - 04:53:13 EEST