What I love about Unity

[Nenad]

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
>