Hello everybody!
Here I am again, trying to add my two mexican pesos and turn a flame war
into a constructive discussion. Yes, I have already been told that I am
overoptimistic ;-).
Let me start with a me-too: like most (all?) of you, I too love BB
(that's why I feel concerned), I too find it is very useful as it is
(that's why I use it) and I too trust the developpers.
But here comes a question: what is the purpose of this mailing list? My
belief is that it is a way for the developpers and the actual and
potential contributors to get feedback from the users. To get ideas and
suggestions about what can be improved and how it can be improved.
Therefore, event if we all know that BlackBox is a Good Thing,
discussing how it can be made a Better Thing is an appropriate topic for
this mailing list. Sure, the developpers make the final decisions, but
that should not prevent the others to do their best to give useful
feedback.
Now comes the question of what is good and what is bad. Here is my
suggestion, sorted by decrasing priority:
A. Is good whatever the developpers consider good.
B. Is good whatever the users consider good.
Well, not *very* helpful. Let me give another try, but first let me
define "ressource efficiency". A window manager is ressource efficient
if it does not eat more (memory/CPU cycles/network bandwidth/screen
space) than needed. It's a shortcut for "clean, lean, slim, light and
fast". So here comes my second try, in terms of goals for BB
developpment:
1. BB sould be as ressource efficient as possible for those who do
not want the extra functionnality given by bbaps.
2. BB should allow those who want it to have a slightly higher level
of functionnality.
3. BB should be ressource efficient for those who use some of this
extra functionnality.
I guess there is no need for me to justify point 1, nor to justify why
it is number 1. Enough contributors have already pointed out that this
is the essence of BB, and that it is strongly related to point A.
Now to point 2. Clearly there are users who use bbapps, so they find
that useful. More importantly, the fact that this point is addressed by
the current version of blackbox means that the developpers pay attention
to this point.
Finally comes point 3. It seems to me that this should be a wish of any
user of a bbapp. If you use a bbapp it's beacuse you want some extra
functionnality. If you use BlackBox it's probably because you like
ressource efficiency.
Currently, BlackBox does a pretty good job in fullfilling points 1 and
2. That's not the case with point 3. Eric Hanson already pointed out
that the current implementation of the bbapps use X as a middleman. This
is a waste of CPU cycles and network bandwidth (for X terminals).
Gregory Barlow made us notice that bbkeys uses nearly as much memory as
blackbox. This is also looks like a waste.
Since there is not a lot of room for improvement on points 1 and 2 (is
there? well, keyboard navigable menus...), why not consider point 3? Of
course, improving on this should not have a negative impact on the
previous points.
Now it becomes a technical question: how to make the combination
blackbox + some bbapps more efficient without making blackbox proper
less efficient.
I suggested a loadable module apporach. I believe it should reduce CPU
waste (no context switching, no extra job for X), bandwidth waste (no
talking through X) and probably memory waste (less duplication of code).
Aaron Seigo said this should not be a very difficult path.
Alex Buell suggested a plug-in approach. I don't really know how this
works (communication through pipes?), and how it compares with the
current approach and with the module approach. But I would be happy to
learn more on this.
Oh, I almost forgot
4. The level of extra functionnality desired should be easy to
configure at the user level.
It has been pointed out that the current .xinitrc approach may not be
the best solution.
Regards,
Edgar.
--
Edgar Bonet Tel : +1 607 255-9349
LASSP -- Cornell University Fax : +1 607 255-6428
Clark Hall e-mail : [EMAIL PROTECTED]
Ithaca, NY 14853, USA web : www.edgar-bonet.org
