An Open Letter to Ubuntu Developers (apologies for the length) First of all, I would like to thank all that participate in Free Software. I could write for days about how I appreciate individual upstream projects and the work done by various distributions, but for brevity I'm lumping all this into one big thank you.
This is not meant to be a series of rants, please do not take it as
such.
I am hoping this will come across as a comprehensive series of
observations of desktop Linux usage, from a long-time (and I like to
think, competent) Linux user / sysadmin.
I am targeting this at the developers of Ubuntu.
I could have broken this down and targeted specific upstreams, but for
better or worse, I believe Ubuntu is gaining serious mainstream traction
on the desktop, and I think this will reach more people and have more
impact if I target Ubuntu specifically.
Having said that, none of this letter is intended to be Ubuntu specific,
instead being applicable across distros and upstream projects.
1) Applications, and their dependence on desktop environment libraries
Currently certain application rely on specific desktop environment
libraries to operate.
As examples,
if you install kate on stock Ubuntu 10.04, you pull in 108 packages,
totalling 330Mb
akonadi-server exiv2 gdebi-kde icoutils install-package kate
kdebase-runtime
kdebase-runtime-data kdebase-workspace-bin
kdebase-workspace-data
kdebase-workspace-kgreet-plugins kdelibs-bin kdelibs5
kdelibs5-data
kdepim-runtime kdepimlibs-data kdepimlibs5 kdesudo kpackagekit
ksysguardd
kubuntu-debug-installer libakonadiprivate1 libattica0 libaudio2
libboost-program-options1.40.0 libclucene0ldbl libdbusmenu-qt2
libexiv2-6
libiodbc2 libkephal4 libkfontinst4 libkscreensaver5 libksgrd4
libkworkspace4
libmng1 libmodplug0c2 libmpcdec3 libmysqlclient16
libpackagekit-glib2-12
libpackagekit-qt-12 libphonon4 libplasma-applet-system-monitor4
libplasma-geolocation-interface4 libplasma3 libplasmaclock4
libplasmagenericshell4 libpolkit-qt-1-0 libprocesscore4
libprocessui4
libqca2 libqimageblitz4 libqt4-assistant libqt4-dbus
libqt4-designer
libqt4-help libqt4-network libqt4-opengl libqt4-qt3support
libqt4-script
libqt4-scripttools libqt4-sql libqt4-sql-mysql libqt4-svg
libqt4-test
libqt4-webkit libqt4-xml libqt4-xmlpatterns libqtcore4 libqtgui4
libsolidcontrol4 libsolidcontrolifaces4 libsoprano4 libssh-4
libstreamanalyzer0 libstreams0 libtaskmanager4 libweather-ion4
libxcb-shape0
libxcb-shm0 libxcb-xv0 libxine1 libxine1-bin libxine1-console
libxine1-misc-plugins libxine1-x mysql-client-core-5.1
mysql-common
mysql-server-core-5.1 oxygen-icon-theme packagekit
packagekit-backend-apt
phonon phonon-backend-xine plasma-dataengines-workspace
plasma-scriptengine-javascript plasma-widgets-workspace
polkit-kde-1
python-kde4 python-packagekit python-qt4 python-sip
shared-desktop-ontologies software-properties-kde soprano-daemon
ttf-dejavu
ttf-dejavu-extra update-manager-kde virtuoso-nepomuk
By contrast, if you install gedit on stock Kubuntu 10.04, you pull in 62
packages, totalling 72Mb
esound-clients esound-common gamin gedit gedit-common
gnome-mime-data gvfs
gvfs-backends indicator-application launchpad-integration
libappindicator0
libart-2.0-2 libaudiofile0 libavahi-glib1 libbonobo2-0
libbonobo2-common
libbonoboui2-0 libbonoboui2-common libcdio-cdda0
libcdio-paranoia0 libcdio10
libdbusmenu-gtk1 libesd0 libgail18 libgamin0 libgdu0 libgnome2-0
libgnome2-common libgnomecanvas2-0 libgnomecanvas2-common
libgnomeui-0
libgnomeui-common libgnomevfs2-0 libgnomevfs2-common
libgtksourceview2.0-0
libgtksourceview2.0-common libgvfscommon0 libindicator0
libjson-glib-1.0-0
liblaunchpad-integration1 libnotify1 libproxy0 libsexy2
libsoup-gnome2.4-1
libsoup2.4-1 libstartup-notification0 libwnck-common libwnck22
libxcb-atom1
libxcb-aux0 libxcb-event1 libxres1 notification-daemon
policykit-1-gnome
python-cairo python-gconf python-gnome2 python-gnomecanvas
python-gtk2
python-gtksourceview2 python-pyorbit zenity
Note the requirement for MySQL client libs when installing kate on
Ubuntu, and the requirement for Esound when installing gedit on Kubuntu.
These are obviously needed for some DE libraries, and (you'd hope)
should not impact the functionality of a simple GUI text editor.
I understand the fact that desktop environments provide a multitude of
services / functionality, including being platforms on which other
applications can be built.
But surely it's desirable (and possible) for apps to be DE agnostic, and
depend on plumbing libraries that are common (and shared) across DE's.
There must be a way for the plumbing elements of today's DE's to be
shared, and for the look & feel of a GUI app to be nothing more than a
very thin wrapper over a standard base.
I've never seen the logic in tying applications to specific DE
libraries.
Please do not think I'd trying to advocate the need for a single desktop
environment (far from it)
I like the choices that are available, and believe it sparks competition
and innovation.
but do one thing, and do it well, and currently desktop environments
seem to do a whole host of generic tasks, using their own bespoke
libraries, that could be split out into cross-environment libraries.
It's not like this is uncharted territory, either
There's a few examples of protocols / APIs that cater for new features /
abilities in specific implementations
OpenGL being one
Would it not be possible for all DE's to adhere to a standard protocol
Then, for example, if KDE 5, or Gnome 3.7 introduce a new concept, this
can be dealt with by an extension to the protocol
If the new concept is picked up by other DE's, then it can be written
into the core protocol
2) Everything's a file
This Unix philosophy seems to have been forgotten in many of today's
applications / userland servers
Wouldn't it be wonderful if the sound being output to the systems
soundcard(s) or individual apps were available via a file
Completely independent of whatever sound system (ALSA, OSS, OpenAL) or
sound server (PulseAudio, Jack) happens to be in use
cat /dev/snd/stereo_out1 > ~/speaker_output.wav
cat /dev/snd/pid_1234 > ~/app_output.wav
rather than the various custom and bespoke recording programs / shell
scripts that are needed currently
Also with capturing screencast videos
(ignoring arguments about codecs / containers)
cat /dev/display/xscreen1 > ~/desktop_screencast.ogm
cat /dev/display/pid_1234 > ~/app_screencast.ogm
Taking this one step further, if all AV produced by apps are available
via files, I think the process of combining various AV streams would be
greatly simplified.
Pipe the video stream from your screenA into a multiplexer
Cat audio streams from appX and appY into a mixer, and pipe combined
audio into the multiplexer
Redirect multiplexer output to a file
Don't think of the above as the typical user-facing way of doing things
More a standard framework for writing GUI apps to achieve such tasks.
I think this would greatly simplify, standardise, and enhance such GUI
helper apps for manipulating AV on a desktop machine, as all AV is dealt
with in a standard (and simple) way, and again, it would be sound system
and sound server agnostic.
3) Link GUI & CLI operations using common syntax
I'm in two minds about including this,
as this is not a usual use-case for the majority of people
but I'd love for all GUI applications to be invokable via the CLI, using
some standard syntax
I've found that often times I'll use a GUI app to perform some set of
operations, then I'm wanting to perform the same operations across
multiple files, and currently I'm forced to find alternative apps of
automating said operations
Eg. I've recently needed to perform the following operations on several
hundred photos
in order for them to blend in with a user-configurable webpage colour
scheme
(Making an image whose background gradually fades to transparent at the
image boundaries)
- Open image in the Gimp
- add a transparent layer
- Select all
- Shrink selection by 5px
- Feather selection by 5px
- Invert selection
- Clear selection (to transparent)
- Save as a PNG
Surely it should be possible to automate such GUI operations using a CLI
interface
and if you've got experience with a specific desktop app, I think it
would be hugely beneficial if you could keep using the same program both
on the GUI and on the CLI
for IMG_FILE in $IMG_FILES; do
gimp-cli
--process="layer-add:transparent;select-all;select-shrink:5px;select-feather:5px;select-invert;select-clear;file-save:${IMG_FILE}.png"
$IMG_FILE
done
I can think of a few examples of complex GUI operations that would
benefit from easy CLI automation
If some sort of standard syntax could be developed to automate
operations via a CLI interface, I'd die happy
And (this may be a little too ambitious, but just suppose) if the syntax
of these CLI operations could be sufficiently generalised across all GUI
applications, you could, given an arbitrary CLI command, spit back out a
simple bullet point set of GUI instructions for users to follow.
CLI is universally English, GUI is not.
This may be beneficial to documentation writers and translators
Write one command, and ask it to output GUI instructions in x number of
languages
but that's probably not very do-able, I admit.
Anyway, if you got this far, then thanks for reading.
As I said at the start, this is just a collection of things I think
(from my POV) could be done to improve the overall experience that is
Linux.
--
Tony Atkinson
Email: tatkinson...@googlemail.com
PGP: F2B9184B
signature.asc
Description: This is a digitally signed message part
-- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
