Call to arms! A new GUI for Linux

[Anton Markov]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Lennart Sorensen wrote:
|>How can we talk about a unified interface when basic drag 'n' drop of
|>text doesn't work properly between QT and GTK, the "busy" icon which is
|>supposed to show when an application stops loading (Application Startup
|>Notification) does not work properly, or opening images from Konqueror
|>in The Gimp causes multiple instances of The Gimp to open. I am sure the
|>list can go on.
|
|
| So all applications should support finding an instance of themselves and
| adding the passed file as a new document rather than launching a new
| copy of the program?  What if that isn't what the user wants?

At least programs that support multiple document interfaces should
support this feature. This is especially true for web browsers and
e-mail clients. Getting Firefox to open links in a new browser window
rather than a new instance still involves (writing a script to) calling
"mozilla-firefox-xremote-client" with very confusing options. While the
Debian package contains a script that does this automatically, it still
looks like a quick hack rather than a well-thought-out system. And while
I take back part of what I said about The Gimp, since I found
"gimp2.0-remote" which will open everything in a new instance, it just
goes to show that there is no unified interface for it.

A good system would allow the user to select whether or not to open a
new instance. I realize that certain programs that support "projects"
such as Quanta also prefer to open a new instance, but at least the KDE
"DCOP Registration" allows the user to select between "multiple
instances" and "single instance". A system-wide interface/standard would
be nice.

|
|
|>The point is that icons can be turned off, one can place a shortcut bar
|>at the top of the screen with configurable keyboard shortcuts, there is
|>Klipper for the "global clipboard", and some distributions already ship
|>with a graphical bootup screen. Keyboard shortcuts are also
|>configurable, and a tab-based window manager can also be developed on
|>top of the current infrastructure.
|>
|>The real problem lies in the _system-wide_ contact list, _universal_
|>application drawers, and other _system-wide_ features. If all
|>applications exported meta-data such as supported file types,
|>description, interface, etc. through a DCOP-like interface, it would
|>possible to create a global "recent documents" list that can be filtered
|>for each specific application (if I understand your ideas right). As for
|>keyboard shortcuts, we need a real UI designer to sit down and draw up a
|>set of specifications, and for both KDE and GNOME people to follow it.
|
|
| And in which language should the keyboard shortcuts make sense?

That is actually a good question. Then again, shortcuts already don't
make sense in any language; why is "cut" Ctrl-x and "paste" Ctrl-v.
Perhaps it would be possible to make the shortcuts different in
different locales, especially with different keyboard layouts. But it
has to be at least partially consistent with other operating systems; at
least the universal open, save, copy, paste, cut, quit commands should
follow the current conventions (where the commands make sense).

|
|
|>Unfortunately non of this will happen with the current mind-set of
|>choice = 10 different email clients, unless all of those ten project
|>leaders will agree on the same set of keyboard shortcuts and APIs. A
|>unification of QT and GTK2, with a good wxWindows interface would go a
|>long way. It would also free up a ton of developers to work on other
|>(although perhaps less interesting problems).
|
|
| Similar problem.  What if they have different features, how do you make
| keyboard shortcuts make sense for all features for all programs in all
| languages?

I was talking more about keeping the basic shortcuts consistent,
although it's already pretty good. I wasn't even focusing on keyboard
shortcuts in my last message; I just picked it as a (bad) example. I
would just personally find such a guide very useful when/if I write a
program with a GUI.

As for the multi-lingual issue, I would think that most users would
prefer a consistent vs. culturally correct shortcuts. For the Qwerty
keyboards it would probably follow the more or less "established"
conventions (Ctrl-o, Ctrl-s, Ctrl-c, Ctrl-v), etc. Perhaps a system-wide
keyboard shortcut scheme could be installed to suit the user's needs.
Again, you raise a very good point.

|>Another good feature would be a global CVS-like system built into the
|>implementation-independent filesystem code, which would keep track of
|>which applications opened each file and a Changelog of the application's
|>actions. For example, if you create an SVG in Sodipodi and then touch it
|>up in The Gimp and convert to a PNG, you could go back, make a change to
|>the SVG in Sodipodi, and The Gimp will know how to re-apply your
|>touch-ups to update the final PNG.
|
|
| Part of what I have always liked about unix/linux systems is that each
| tool tends to do one thing, but does it very very well.  Integration of
| too many features and tieing programs directly together tends to add
| feature creep, introduce complexities to the coding and usually a ton
| more bugs.  I want simple programs that do their particular job well,
| and if you can control them entirely from commandline/script then it's
| perfect since I can simply script those steps I want the gimp to do to
| the sodipodi file and repeat it on any input file (or input file change)
| that I want, which is to me MUCH better than having the programs talk to
| each other and discuss changes and such.  It sounds like you want to do
| between applications what current high end CAD systems do internally for
| their geometry data (everything is a tree structure of dependant
| variables, and relative specifications where if you change the size of
| something, everything made dependant on that size will update).  Very
| complex to implement well, and doing it between applications sounds even
| more tricky and probably not worthwhile.

I absolutaly agree with you about the power of simple Bash scripts and
the complexity of such a system, but in my experience Bash intimidates
many people (including myself), and thus makes this functionality
illusive. I find it sad that most KDE applications can not be controlled
directly with command-line arguments (asides from basic KDE/QT/X options).

I was thinking more of unifying the various scripting engines that many
applications already (Gimp's LISP interpreter, KDE's DCOP, for example),
and _allow_ (not force) programs to store an application-dependant
changelog with the files without altering the file format. This would
maintain compatibility, while allowing an average user to access at
least a part of the power available through shell scripts. I think
graphic artists would be especially interested in the ability to at
least partially automate their workflow without having to learn bash or
even look at a command line.

I hope that clarifies my ideas somewhat. I am just trying to be
constructive.

- --
Anton Markov <("anton" + "@" + "truxtar" + "." + "com")>

GnuPG Key fingerprint =
5546 A6E2 1FFB 9BB8 15C3  CE34 46B7 8D93 3AD1 44B4

*** LINUX - MAY THE SOURCE BE WITH YOU! ***
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBdDemRreNkzrRRLQRArP+AJ4g0WloNVRX+tsoIe2FGdfWostCMgCfTMP9
16U+HszF/H0QoQShwA/68oM=
=uINS
-----END PGP SIGNATURE-----
--
The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml