Doing some idle web-browsing, I came across this recent thread, which
I found very interesting. Let me start by introducing myself: I am an
academic, working in computational mathematics, which has me run
simulations and data analysis some, usually a small fraction of my
time, write (using LaTeX), and do ordinary office tasks a (too large)
fraction of it. I started running my first self-owned Linux box with
Redhat 4.2 and have pretty much followed all of the Fedora releases,
maybe skipping an occasional few. So the fact that I ended up reading
fedora-desktop at all indicates in some way that there is lingering
dissatisfaction with the state of Fedora, but a lot of the comments
expressed I find encouraging enough to try to spend time to put my
thoughts down in a consistent way.
First some historical remarks. Up until Fedora 14, I was actually
looking forward to new releases as, despite of occasional breakage,
there was a steady increase in quality and capabilities. The point
when Fedora, in my experience, really blew it was the transition to
Gnome 3 in Fedora 15, and for two independent reasons:
(a) The sudden requirement to have working accelerated graphics
drivers in the default install broke the default install on several
perfectly good systems.
(b) Pulling out fundamental UI paradigms from under one's feet
feels in some way like bodily assault, as all carefully learned
workflows and muscle memory suddenly start bumping you every step you
take while trying to get real work done. Note that this is not a
general critique of Gnome 3 which, with some reservations I will
comment on later, I find interesting and a perfectly acceptable
approach from a UI development perspective.
What I object to (I have to admit that it makes me angry to this day)
is that it is considered acceptable at the distribution level (!) to
break user's setup (hardware as well as workflows) in such fundamental
ways without providing adequate fallbacks. I have heard technical
arguments why this was not possible, and these are possibly strong
arguments for all I can tell, but the mere existence of Mate today
attests that the pain for the developers cannot have been
insurmountable. I also do appreciate the fact that the transition to
an accelerated desktop has probably given a good push to graphics
driver development. At least all of my systems noadays run fine in
accelerated mode. Still, all this is no excuse for breaking user
systems at a fundamental level without having a fallback that is at
least as good as what worked in the past. To put it another way: as a
technically minded user (not system developer!), I do appreciate
living on the bleeding edge and do not mind filing the occasional bug
report or working around upgrade-related problems, but part of the
unspoken deal is that I should not fear that the distribution pulls
the rug from under me. If Fedora cannot maintain this fundamental
trust, it will lose testers, early adaptors, and end users.
So to get the main points, let me state a few principles of how I
would like "my" distribution to be:
1. Chose evolutionary over revolutionary changes whenever possible.
2. Do not remove features (even misfeatures - someone might rely on
them) without really good reason (pure aesthetics is a good reason,
IMO, but not a "really good reason"). If you do, do it a prepared
and well-documented way.
3. Treat "developers" as users who are pushing the envelope more than
others, not as a fundamentally different group. A good
distribution, UI, desktop, you name it should scale well from
novice users to specialists. Trying to draw a line will alienate
people on both sides of it.
4. Don't let any one desktop environment define the distribution. The
task of the distribution is to _integrate_ different pieces of
software so that they can be used together without interference or
pain.
5. That said, desktop environment proliferation is not part of a
solution, it is part of the problem.
For 1: There are some big changes that appear to work (at least from
my perspective, the systemd transition was such as case - it surprised
me rather unpleasantly when forced to debug a nonbooting system after
gdb decided it would only work with accelerated graphics drivers, but
the new workflow was sufficiently well documented and coherent so that
this was ultimately a non-issue), but in most cases the pain of
throwing away a well-understood codebase for something new seems to
outweigh the gains by far (here the anaconda and fedup transitions
are a case in point).
For 2: This appears to be well understood in kernel and basic
infrastructure circles, but at higher levels in the stack, this
mindset is IMO underdeveloped.
For 3: In my experience, I run into either technical issues or
usability problems more often when doing "developer" work, but the
issues are not necessarily qualitatively different from "ordinary"
computer use. Typical situations that a "developer" encounters (many
open windows, independent parallel instances of applications,
long-running jobs that produce occasional feedback and need monitoring
from time to time, running jobs and/or keeping user data on the LAN or
even "in the cloud", large amounts of installed applications (because
various users on the network have different preferences) are just
expressions of a scalability regime which includes the "ordinary" user
in the center. Thus, any improvement in handling "extreme" behavior
will benefit all users in the end.
For 4: From a user perspective, the problem is not that all g* or k*
applications should maximally look and behave alike. That's a task
for purists and the respective upstreams. As a user, for the better
or worse, I am exposed to a variety of different electronic devices,
operating systems, applications of various heritage, web applications,
etc. So consistency for me is always relative to what's out there in
the world, not to the best-practice example from a small homogeneous
software ecosystem. So the distribution should treat all software as
equal and make sure it works optimally in a heterogeneous software
environment.
Here my main gripes are:
- Currently I have Gnome, KDE, and cinnamon installed (that is on my
personal desktop where it might be of questionable value, but in a
workgroup/university setup, this is commonplace). The menus are a
terrible mess of triplicate utilities without structure, generic
names, sometimes identical looking entries which are difficult to
navigate if one does not already know what one is looking for.
- No clear separation between system configuration and desktop
configuration. I don't need three printer configuration utilities,
I need one that works. These are distribution-wide issues, not
desktop issues. (I can see that the different desktops like to roll
their own thing, and that is fine with me. However, the
distribution should go for one option which is the optimally
maintained one and use it from all other desktops. For a users it
does not make ANY difference if it's the Gnome or cinnamon or KDE
tool or something entirely different as long as it is logically laid
out and it works.)
- At higher levels in the stack, distributions should choose
best-of-breed default applications, not necessarily those who are
the "official" desktop environment champions. Case in point: I have
always been biased toward using Gnome rather than KDE applications
when both exist, with one exception: As a document viewer (and
that's a pretty central complex application), okular is such an
advance over evince that IMO it really deserves the "Document
Viewer" name in the defaults. (The main points: using the "trim
margin" feature of okular, most PDF documents which occur in the
wild can actually be read at an acceptable magnification without
in-page scrolling on modern screens; the page caching of okular is
notably better than evince's which is unacceptably slow with
bitmapped, i.e. scanned documents even on good hardware.)
So Fedora should bundle what is the best, not what is the "politically
correct" application for a given desktop.
For 5: I would very much wish if Fedora would take a lead in unifying
at least the Gnome based desktops (Gnome 3, Gnome classic, cinnamon).
They all have the same underlying infrastructure, which appears sound
for all I know, and the differences are IMO more political than
anything else.
To be precise, I have to say that from an aesthetic perspective, I
like Gnome 3, and at least in principle I agree with the philosophy
that one should not need hundreds of configuration options if the
defaults are well chosen and the important ones are there.
However, and this is what I feel is most relevant to the "developer"
discussion: Gnome 3 default fails for me mainly due to the missing
taskbar. (I know there are extensions, but that is beside the point.)
I'll start by saying that, from a purely aesthetic perspective, I
actually dislike the taskbar: it is taking vertical screen real estate
from me and it starts looking ugly, with ridiculously shortened
application names, when the number of windows gets large.
Unfortunately, this is precisely the regime when the Gnome overview
mode (I am using cinnamon right now, so I have both for direct
comparison) becomes outright unusable. The problem with overview is
that when there are too many windows, I cannot read, or can hardly
read the text while, at the same time, I have no good sense of the
mapping of the logical order of the windows to the display order in
overview mode. The taskbar, while also unable to provide meaningful
text, still has an accurate history of the order in which the windows
where opened. This means that I can usually find the window I need
surprisingly quickly and reliably while overview mode greets me with
an unusable mess and even ALT-tab is often hard to use (e.g., I am
comparing the output of an old and a new run after I fixed my code.
The labeling of the two windows is identical, the output looks very
similar. So which is which? No problem if I have a strict time line,
impossible with anything else).
Abstractly speaking, the problem is with best handling a number of
40-80 and more open windows, and here the taskbar is the least bad.
(Windows seems to have a hierachical, application-based system, which
I have not explored very much, and I am not sure if this is not
incurring more problems than it solves.)
A second workflow where I absolutely depend on the taskbar is for
spotting small differences in graphical output or data visualization
where I move one window over the other and flip the upper window on
and off from the taskbar. This is arguably a very specialized use
case ("developer/scientific workstation"), but is incredibly useful
and without replacement in the Gnome 3 paradigm.
So, if I could have a wish unconstrained by politics and internal
technical issues, I would like to see the best features of cinnamon
merged into Gnome classic and make Gnome classic a runtime (not
start-up time) configurable option (maybe a set of related options) in
standard Gnome 3. Call it even "expert mode" and hide it somewhat
away from casual users. That would go a long way of reaching a wide
range of users with a single setup and also reassure users that their
workflows are welcome and long-term supported.
I have toyed both with current Gnome classic and cinnamon, so for the
record a list of features that make me (mildly) prefer cinnamon. I
think they are relevant to get a "developer user" point of view:
- Taskbar in cinnamon is right-clickable as it used to be in Gnome 2.
- It is possible to configure a "vertical maximize" feature, which is
more useful than the various edge-snap options as, especially for
developer use, the width of windows is usually well-defined and
should not be changed, but one often wants maximal number of
viewable lines. I think it would make a lot of sense to make this
feature defined (rather have it as part of a broad set of otherwise
relatively uninteresting configuration options)
- I came to like the "single taskbar at bottom" approach as I usually
plug in an external screen into a laptop which is sitting physically
above the (ultrabook) laptop, so I want it logically above, too. I
did this for years also with the old Gnome 2, so the top bar on the
primary screen is not a deal breaker, but in this secondary over
primary screen scenario (which I think is the only natural one for
the plug-into-laptop situation), it feels more natural not to have a
top bar on the primary screen. Minor detail though. (Related to
this, Gnome and Gnome classic had a persistent bug in this
configuration which I filed but I don't think is fixed at least
according to bugzilla, which is indeed a dealbreaker.)
- The panel editing and configuration seemed very natural (better than
when I tried Gnome classic), but this may be just a moment's
impression, so I do not attach weight to this. I do like (most of)
the the cinnamon defaults, though, in particular the relatively
minimal vertical footprint of the taskbar, and the windows and
virtual screen switcher.
- I don't remember if this is only a Gnome thing or also a
Gnome-classic thing: If I tell the UI to open a second instance of
an application, I would expect a second instance and not to be shown
the first.
My conclusion is that there is nothing in cinnamon which could not be
done in Gnome (classic) without a major break in design philosophy.
(As much as I like cinnamon in general and appreciate the work going
into it, lingering bugs (I have filed a few) make it look like the
maintenance burden is at the brink of feasibility.)
Two more remarks on what I find extremely important from a "developer"
perspective:
- Focus follows mouse (or sloppy focus) and
- right/middle mouse copy/paste.
I am mentioning this because I have seen these features, probably
because they deviate from "expected" behavior in other operating
systems, be relegated from standard in the old days to "dig deep in
preferences", resp. talk about changing right/middle mouse behavior in
Gnome. I have worked on systems without them, but I find them such
tremendous productivity boosters that I keep coming back to them as
soon as I can. (Note: I am writing this on a laptop which does not
even have a physical middle-mouse, so I enabled three-finger tap to be
equivalent to middle-mouse - this looks like a hack, but it's actually
so convenient that I find myself using the three-finger tap even when,
like now, I have a physical mouse attached. So again, this would be a
good feature for standardization - I don't even care how it is mapped
to taps or gestures as long as remains consistently reliably available
on modern hardware.)
OK, this was a long post, but I have the impression that there is
actually an audience of Fedora developers somewhat appreciative of
such ideas. I think it would buy Fedora a lot of trust if things were
thought through from the workflows and needs across the spectrum of
existing users, including specialists and "power users". I.e., be
inclusive in your approach to the extent possible with honest effort,
it's going to benefit ALL users.
Regards,
Marcel
---------------------------------------------------------------------
Marcel Oliver Phone: +49-421-200-3212
School of Engineering and Science Fax: +49-421-200-3103
Jacobs University m.oliver@xxxxxxxxxxxxxxxxxxxx
Campus Ring 1 oliver@xxxxxxxxxxxxxx
28759 Bremen, Germany http://math.jacobs-university.de/oliver
---------------------------------------------------------------------
--
desktop mailing list
desktop@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/desktop
