Re: why are there no themes for galeon? and is galeon 1.3 cooler than 1.2, let's vote

On Tue, 15 Mar 2005, Adam Hooper wrote:
> A more Galeon-related example: in Epiphany there is no "Quit" feature.
> Why not, even though people have asked for it? Because no user has come
> up with a valid reason for putting it there. All it does is closes every
> window when you hit Ctrl-Q by mistake. The *real* issue is that users
> don't know that logging out of GNOME will automatically save their
> session, including all open browser windows.

... except that X session management is so restrictive that I've not yet
been able to find a way to get it working for me without losing
substantial functionality. My standard configuration has windows open
from apps running on multiple machines, some via SSH tunnels and some
not, some with specialized environment variables and elaborate pieces of
scriptage setting up their command-line arguments.

All xsm remembers is that `app {name} was {here}'. It certainly doesn't
have a way of capturing the (critically important) state information
that app {name} was started by {complicated command} on {host}.

I haven't even found a way to get the session manager to ignore some
apps (the ones which run on remote machines, i.e., about half of them)
so that I can start them by hand. No, they always get restarted, and
they get restarted on the *local machine*, bogging it down to a crawl in
some cases and simply failing in others (because the apps don't *exist*
on the local machine).

Now I'm not experienced enough with X session management to know if most
of the missing state should be preserved by the window manager or by the
app itself, or even by gnome-session: but whichever it is, it's not
doing it. (This remains true whichever WM I try, in my experience: I've
tried sawfish and fvwm recently.)

I suspect a design flaw in X session management, but, again, I haven't
studied it in enough detail. In any case, you shouldn't have to read
docs on X session management in order to get `ssh foobar galeon' to save
itself out, difficult problem though it is. Remote window display is
a difficult problem, but I didn't need to read the X Protocol spec
to get that to work.

>                                              (I don't mean to start a
> flame war about this particular issue. I know Galeon is often used
> outside of GNOME and I don't know if "Quit" is important to those
> users.)

I have real difficulty believing that there are *no* GNOME users of
Galeon who ever want to close their web browser.

>     The simple fact is that users are trying to solve their *real*
> issue (logging out and back in without destroying their session) by
> coming up with a wrong solution.

How can you possibly tell that users would never want to close Galeon?
Perhaps --- off the top of my head --- they're trying to

- free up memory for another job (Galeon is not small)
- cleanly disconnect all clients on a remote machine which is about
  to go down and on which Galeon is running
- vape a Galeon whose rendering thread has gone into an infinite loop
  (there are still sites around that do this, alas, although I don't
  run across them often anymore)
- free up virtual desktops
- or any of a million other reasons.
or perhaps they simply don't want to do any web browsing for a while and
want to get Galeon out of the window list.

The first reason is particularly true given the titanic size of the
pixmaps which Galeon throws at the X server: I've seen it using over
512Mb in the X server in the past, and I know *I* don't have enough
memory to take that kind of hit all the time.  (Restarting it sometimes
reduces the hit. Oh! Guess what! That requires shutting Galeon down
too!)


(I've noticed that the GNOME world in general appears to have forgotten
about the *remote* parts of X. The per-display and per-host parts of
X resource handling don't appear to have any analogue in Gtk, for
starters...)

> - Discover what it is the user *really* wants.
> - Find a way to get the user what he wants in a painless manner, without
> disturbing the experience for users who *don't* want it.

While this is certainly true of *some* users (typically the ones with
limited domain experience), it equally certainly *isn't* true of a
*large* subset of users on Unix platforms. (Most people on *all*
platforms have at least a limited amount of domain experience with web
browsers now, of course... hell, there've been so many competing Unix
web browsers that I sometimes wonder if there are any Unix developers
who haven't at some point written one!)

This whole argument feels to me like a justification for ignoring any
and all requests which you don't like the sound of, without needing to
find an actual problem with the request; just say `you don't really want
to do that' and ignore it. While you of course have the prerogative to
do that, as do we all, some of us are actually fond of *listening* to
users unless we have a good reason for saying `no'. We find it tends not
to lose us users if we don't patronise the living daylights out of them.

> - Say "no" when he doesn't want to do something.

I wish I had your powers of telepathy. I'd have expected the user to
know his own wants better than anyone else does. (Indeed, in my day job,
the users are often bad at *expressing* what they want to do, but I've
never yet found a case where a user has asked to do something which he
really didn't want to do at all. Users don't ask us to add features just
because they want to make our lives difficult!)

Now we may disagree with the substance of a user's request, or think
that we know a better way to do whateveritis than that which user has
suggested, but we can't say that *the user* doesn't know what he wants
unless we know that he's got one of a limited set of very severe mental
disorders.

> These tasks are incredibly difficult. Add to this the complication that
> a massive proportion of the user-base doesn't even know how to give
> feedback or make feature requests. In such a situation, it's impossible
> for developers to know the best way to do things.

Agreed :( but that makes it all the more important that if a user *does*
find some way to talk to us, that we don't blow him off with comments
about we know what he wants to do better than he does, which *sound*
fantastically arrogant whether or not they have a basis in fact.


But since the GNOME world appears to segregate the userbase into
inexperienced users, whose comments can be ignored because they don't
know what they're doing, and experienced users, whose comments can be
ignored because GNOME isn't aimed at them, I'm sure everything I'm
saying will be totally ignored or blown off with non sequiturs. As
usual. (You'd think the latter criterion would disqualify GNOME
developers from making decisions about their own software, but oddly
enough it seems not to.)

-- 
> ...Hires Root Beer...
What we need these days is a stable, fast, anti-aliased root beer
with dynamic shading. Not that you can let just anybody have root.
 --- John M. Ford


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click