On 12/29/2011 02:23 PM, Jo-Erlend Schinstad wrote:
In light of a recent thread on this list, I thought I'd provide my
perspective of what Unity is, why I think it's important and why I
actually came to love it. Just to eliminate any doubt, I'll start by
saying that I'm not affiliated with Canonical and I'm not part of the
Unity project. I have no stakes.
I think the most important thing to understand about Unity is that it is
not primarily a program or a desktop. It is primarily a set of
specifications which are implemented in different ways. The two most
prominent implementations are Unity and Unity 2D, but there are already
several others. Since Unity is a set of specifications, it is possible
to implement parts of it without that being considered an incomplete
implementation. For instance, the indicators are supported on LXDE,
It is really nice that you put effort in explaining what is all about
Unity. From your description I could understand that motivating reason
is an architectural change how applications interact with underlying
data providers, services and APIs underlying operating system provides.
A story about indicators, etc. sounds as really good set of
architectural choices. Having said that, architectural cleanup should
not negatively affect existing user base by removing some workflows.
Backward compatibility might slow down overall progress but green field
development results in own set of problems. Ironically, technical people
who would otherwise support architectural changes introduced with Unity
are resistant to these changes because of some user interface
shortcomings.
Xfce, Windows, KDE and others. This is very important. For instance,
people are complaining about not all Gnome Panel applets being ported to
Gnome Panel 3 yet. This is because the applets become part of the panel
itself, meaning that it has to be completely compatible or it won't
work. This is not the case with indicators, which is why all indicators
are already supported on Gnome Panel 3. The panel just needs to support
the indicator specification and then all indicators automatically work.
It is also an uncomplicated specification, so it's easy and quick to do.
This about simplicity of specification is very nice. Simple specs have
chance to survive reality checks across releases (and get more
complicated later).
According to your description these specs are easy to implement for
remaining panels, then why support for look & feel of Gnome Panel was
marginalized remains unclear.
So an indicator actually connects to the indicator service and tells it
what it wants to display. Then it's up to the service to display it
properly according to its environment. This means that indicators will
look native to the environment it is used in without any kind of extra
work. For instance, an indicator that's primarily targeted at Ubuntu
desktop, will look as if it was designed for KDE when that's your
desktop or as if it was designed for Windows when you run it in that
environment. It could also be displayed as text if you don't run a
desktop at all. Further, since indicators are implemented using remote
procedure calls, you could easily run an indicator on a website and have
it integrate with the desktop -- regardless of operating system.
From your description, data providers are cleanly separated from
application logic and application presentation layers and this is also
very reasonable.
Indicators and notifications are omnipresent across devices and
operating systems. Having a uniform way of adding support for all
operating systems without any kind of extra programming, is highly
valuable. It's valuable to users as well, since it means that an
indicator written in GTK will look and feel identical to an indicator
written in Qt. This increases knowledge re-usability.
Quicklists are also useful. These provides useful actions for an
application. What useful means, is up to the application and how to
access these tools is up to the environment. Unity launchers and Windows
taskbar entries work mostly the same way in this regard. That's not
necessary at all. Again, application developers decides what is
available and the operating system says how to access it.
Unity lenses and scopes are also interesting. Here too, there is a clear
separation between user interface and background services, to an even
higher degree. First, you have the scopes that provides data from a
given source. This can be anything from your personal information, a
corporate server or an online search engine. Then you have the lenses
which chooses which data sources to use when searching, and finally you
have the presentation. Since the scopes provide data in a uniform way,
Looks like some variant of Model-View-Controller. Also fine.
the lens developers doesn't have to know anything about the source. The
lens developer then simply selects what data sources to search and
retrieve data from, and how this should be laid out. It doesn't do the
presentation itself, but only defines _what_ to do. Finally, you have an
application that displays the lenses according to the definitions. This
means that once an operating system or desktop supports lenses, all
lenses will automatically work and will look native to that desktop.
In summary, Unity is not about how things look. Indeed, we should have
different ways of interacting with your computer and applications. Unity
dash and other components should look and feel different in Lubuntu,
Kubuntu, Windows and OS X. Users should not be expected to understand
the difference between Qt, GTK, XUL or any other toolkit. What
programming language was used to create the software is also not
relevant to the user. Whether the primary focus of the developer is on
Gnome or KDE, should not matter. If it's a browser application, it
should still become part of your desktop like any other application.
This is why the name is so fitting; it unites programming languages,
toolkits, desktops, platforms and operating systems.
Similar attempts in past decade or two: with multi platform libraries
and frameworks (e.g. Qt, ACE, boost, Apache libs, ...) and of course
with VM such as Java, .Net etc.
All of them contributed in serving some user groups, and none of them
fulfilled "One size fits all" promises. The same will happen to Unity I
guess.
In the upgrade from Gnome Panel 2 to Gnome Panel 3, we have "lost" some
applets. Of course, applets can be upgraded as well, but all of them
must be upgraded and there's reason to believe that not all of them will
be. This is a problem, and something that we must actively try to avoid
in all future. This is part of what Unity does, and is probably one of
True.
the things I love most about it. The implementations are not perfect,
but the specifications are really good. I would much rather use a bumpy
implementation of a good specification than to use a perfect
implementation of a bad idea.
True, clean architecture is often a good investment. Just is needed to
take care more about transition from old to new in a way that existing
users are seeing benefits and are not left with feeling of being
marginalized. I think that your post provides good, high level overview
of Unity. Thank you.
Thanks for reading.
Jo-Erlend Schinstad
--
ubuntu-desktop mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
