Wednesday, January 19, 2011

Ubuntu's "Additive Decision" To Include Qt

Jono Bacon(Ubuntu's Community Manager, and a great musician) recently posted on his own blog regarding Ubuntu's "additive decision" to include the Qt libraries with Ubuntu 11.10. However, let's take a look at another one of Ubuntu's additive decisions, in essence: Unity.

Here is a timeline of Unity events:

  1. Canonical announces Unity for their netbook-centric edition only.
  2. Later, they backtrack, and announces it as the default experience for Ubuntu.
  3. Corrolating with the inclusion of the Qt libraries, Canonical announced Unity 2D - which is written with Qt.

Now we can examine the why's. First off, Canonical knew Unity was big. They knew it was controversial. They knew people needed "easing in" in a way. It would have been foolish to immediatly announce Unity for the desktop, and maybe they were not even sure of it at that point. Later, however, they decide to make Unity the default. I won't discuss reasoning or anything here, but it is obvious that they wanted to from a much earlier time. Finally, it seems Canonical has decided to make a switch to Qt. Otherwise, why would they include Qt? Developers yes, but they are developing a large aspect of Unity now using Qt. It does not seem like a purely developer oriented move.

In a simple and witty dialogue here is the same timeline:

  1. "Hey look guys, this is Unity, our netbook edition is going to rock!"
  2. "Unity is so awesome, we're going to switch everything!"
  3. "Hey look developers, we have Qt now!"
  4. "Oh hey guys, we're just going to switch to Qt now. Nothing to see here"

Just to clarify guys, I think Ubuntu is doing great stuff. Also, I think that the move to Qt is a good one. Qt has some great stuff going for it. It's modern, flexible, cross platform and a great coding experience. I think Canonical is being a bit predictable but doing it in a way that causes hype, and that's great. Only time will tell, but I doubt they are going to maintain two totally different code bases for Unity 2D and Unity 3D.

Thomas

=-=-=-=-=
Powered by Blogilo

Monday, January 17, 2011

Gnome 3: A Day Late and a Buck Short


Here it is. The future of the gnome desktop. It has several obvious additions over the Gnome 2 desktop, namely the activity launcher, the dock, and the new panel, and even a new window manager(dubbed "mutter"). Many people are very excited about this release, coming to a desktop near you in April of this year(2011), they have reason to be. Gnome has not released a new major version in nearly ten years, instead choosing to evolve on there old technology. Generally, this has worked well, but it has not reached forward significantly. Gnome 2 is basically very similar experience wise as it was ten years ago. It feels dated. Despite beautiful themes and great artists, Gnome still feels dated. So they decided to change that.

Gnome 3 is a new release, a new major release at that. Gnome 3 breaks API compatibility with many of the old APIs in Gnome 2, and as you can see has a very new desktop shell(dubbed "Gnome Shell"). Let's pause for a minute and compare this Gnome 3 release with KDE's 4th major release. KDE trully changed the desktop. KDE's new desktop is the definition of modern. They left everything behind and started fresh, which is how it has to and should be sometimes. It helps to get a fresh take on things.

However, If you take a closer look at the applications running on this Gnome 3 desktop, you may notice something - they are exactly the same as those Gnome 2 applications, with minimal or no change. That is ok for Gnome's legacy "evolutionary" development policy, but is it enough for a revolutionary release? No, it is not. Gnome 3's main innovation is Gnome Shell, which is the next topic.
Gnome Shell started as a project to revolutionize the desktop metaphor as we know it. However, there is a few problems with the implementation:
  • In order to access your applications and files, you must go to a special "activities" screen to select them.
  • The dock is a near clone of Mac OS X's.
  • The top panel doesn't display tray icons,they are displayed in the lower right.
Let's discuss the first bullet. To access your applications and files, you press a button to go to the activities screen. This is not a menu, this is a special screen which displays open windows, has a search bar, and provides access to applicatons and files. In my opinion, this is a huge productivity slow down. Rather than finding things through a simple menu, you instead have to open a new screen and find them there. Granted, most used applications can be kept in the dock, but it can be a bit of a hassle.

Which brings me to my next point, Gnome Shell looks like a straight copy of Apple's Mac OS X in several ways, the search bar, top panel, dock, etc. This is not so bad of a thing, but is it really innovation?

Lastly, as you can see in the screenshot, tray icons aren't kept with the other seemingly "tray" icons in the top right. They are kept in the lower left, which just makes no sense to me. I use tray icons a lot, so this is a big deal to me. I'd prefer it to be uniform.

Finally, I would like to note that my feelings on Gnome 3 are pure opinion and are based on an unfinished project. I want to see both Gnome and KDE innovate and succeed. It's better for the community as a whole.

Thomas
=-=-=-=-=
Powered by Blogilo

Sunday, December 12, 2010

What Is Polar?

I feel I have spoken about Polar many times without explaining what exactly is Polar. Polar is an advanced package manager taking influence from package managers like Pacman, Ports, Zypper, and Yum. Polar provides automated package building, just feed it a spec file written in the ruby language. This functions exactly like Pacman's PKGBUILD and makepkg, but with the added power and elegance of Ruby. After writing the spec file, you just run Bake on the spec file. Viola, automated package building. Polar also supports dependency resolution, conflict handling, upgrading, and soon, rollback. Polar is incredibly fast as well, at least 4x faster than pacman in my tests. This is mainly due to Polar's lack of a database, it just uses pure ruby configuration and information files. Polar is an ongoing project, and I am putting a lot of work into it. If anyone wants to help, please email me.

Thomas