[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Enlightenment (or not!) Try windowmaker with Gnome
>>>>> "Simon" == Simon Brown <simon [at] cliffestones.demon.co.uk> writes:
[windowmaker and gnome]
Do you have a version of Windowmaker specifically compiled for Gnome?
I know that Debian has specialized Windowmaker packages for both Gnome
and KDE. (I use the vanilla one.) It's supposed to only enable
features, but I wouldn't be surprised if it fixed bugs too.
Simon> Though I'm sure Stephen will tells us all were doomed or
Simon> something
No, I think Gnome and KDE are good things. I don't use them, I don't
need them (mostly I find the mouse to be an annoyance). But the
drag'n'drop metaphor is really important to a lot of things I don't do
very much (image manipulation and 2-d editing of web page layouts, for
example). General object brokering is a great idea too. It's
inexcusable that on-screen numerical tables are ever anything but an
embedded spreadsheet, for example, and their contents should always be
accessible using some sort of database protocol. But these things are
not (yet, anyway) central to text manipulation, that's all, and that's
where I live.
Enlightenment? I dislike the implementation. Surface pretty,
structure sloppy. Eterms are pretty but not practical (they don't
handle even ASCII text correctly, and forget about Japanese). Window
managers should be not noticed until a menu is popped up. EsounD is a
resource hog for no good reason.
But themes! Themes are great. Everybody's doing themes, but I
believe Enlightenment was the first in open source to implement them.
What I object to are tools that take care of the routine stuff but
then proceed to go on holiday when something doesn't work quite
right. And sloppy, non-standard-conformant implementation.
X11, believe it or not, does configuration right in the sense that it
provides appropriate _structure_ for smart configuration tools. The
problem with config scripts is that they do not work with the data
that the application does. Instead, they write a text file based on
the _syntax_ of a configuration language, but normally know nothing
about its _semantics_.
X, on the other hand, uses _resources_. Resources are attached to
widgets, and therefore form a hierarchy (which is enough "semantics"
for this purpose). The resource database for each instance of an
application is built from hard-coded values, system-wide configuration
files (in /usr/X11R6/lib/X11/app-defaults/), user configuration files
(~/.Xresources), and command line options (in order of increasing
precedence). These are all parsed by the same set of resource
database routines in Xlib (actually Xmu IIRC).
What this standard library db API means is that a configuration client
(editres and viewres are standard X11R6 clients, check 'em out) can
see the configuration _in exactly the same form that the application
does_. editres is a clumsy, one-resource-at-a-time, proof-of-concept
prototype; it can't easily do "themes" for a single app, let alone for
a whole desktop. But it should be the fallback for configurators.
Unfortunately, it's easier to write scripts that become ever more
complex and breakable to do what you think is necessary in text form,
and fixing their bugs is easier than figuring out how to (1) structure
the resources and (2) analyze them in the config client.
Not to mention the fact that the X notion of resources is rather
clumsy in many ways. But that could be improved.
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
---------------------------------------------------------------------
Sheffield Linux User's Group - http://www.sheflug.co.uk
To unsubscribe from this list send mail to
- <sheflug-request [at] vuw.ac.nz> - with the word
"unsubscribe" in the body of the message.
GNU the choice of a complete generation.