A Desktop Seismic Shift to Qt

by Dietrich Schmitz

No one questions that KDE Plasma Workspaces is the top ranking desktop gui in pure robust features and asthetics.

It's one beautiful working environment.  What is KDE written in?: Qt

Qt is the same framework used to create the Apps which run in the KDE desktop environment, the same framework used to develop the original KHTML, which was acquired and ported to WebKit by Apple.

Qt has a long history behind it and has evolved through the years and endured change of ownership several times over, now in the hands of Digia and under their governance via the Qt Project.

This advanced framework has a fine reputation using the Lesser GNU Lesser General Public License, which makes everyone in the open source community quite happy.  The technology advancements put it on equal or, arguably, better footing than its competing GTk framework.

There was a period of uncertainty when TrollTech was purchased by Nokia, and the disposition of licensing was put into question.  Fortunately, Nokia saw fit to find the LGPL acceptable.

So, today we see a trend with new Desktop iterations using Qt making recent appearances.  First, Razor-Qt, then KLyDE, now we see a port of LXDE which uses the deprecated GTk2 framework is being made using Qt and will be named LXDE-Qt, appropriately.

It seems that gradually a stronger interest in Qt is being taken and, given LXDE's latest move, at least one Desktop which currently runs on GTk2 is hedging their bets and moving to Qt.  They might have simply chosen to migrate to GTk3, but that wasn't done.  Is the effort to migrate too steep of a climb?  Apparently so.  The LXDE community have done a great job setting up a wiki which addresses the technical challenges in migrating GTK projects to Qt--surely a big help to the community at large.  Hats off to LXDE for doing that.

So, this is a very interesting trend indeed.  Please take a look on the LXDE website to see how well the LXDE port has progressed.  I will certainly try LXDE-Qt at the earliest opportunity.

-- Dietrich

Related articles

• Digia releases Qt 5.1
• Plasma Workspaces 4.11: A long term release
• Plasma Workspace: present and future
• The Unwitting Linux Saboteurs

Read More

Google's Chrome Packaged Apps (Local) Development Strategy

by Dietrich Schmitz

I've been watching Google's progress for some time.

We've seen most recently related technology improvements made to the Linux Kernel that specifically relate to support for software drivers and hardware on the Google Chromebook.

A few months ago, we saw the newest Pixel Chromebook arrive on the scene with superior display and other performance characteristics -- arguably as good as Apple's Retina MacBook line.

Now another adjustment to Chrome was announced in May for the official development of Google Chrome Packaged Apps.  This page explains packaged apps in further detail and includes a video.

If you watch the video which tries to explain what Packaged Apps are, Google talk euphemistically in terms which won't say we're writing local Apps, but if you read between the lines, that's really what they are doing.  Pay close attention Folks, these won't be half-baked Javscript Apps.  No, they'll be running with Native Client (NaCl) C/C++ compiled executables which are the fastest compiled code one can have driving any application.  Here's a brief text explaining what to expect when running a packaged app:

How they behave 

Packaged app pages always load locally. This allows apps to be less dependent on the network. Once a user installs an app, they have full control over the app's lifecycle. Apps open and close quickly, and the system can shut apps down at any time to improve performance. Users can fully uninstall apps. 

Without any effort on your part, your apps will launch offline. But you will need to put some effort into making sure user data is stored locally while offline and then synced back up to your data server once online (see Offline First).

You see, the Apps will be free-standing and so will run outside of the browser, but still use their fork of WebKit, called Blink, which is at the heart of Chrome.   Blink won't be recognizable after they've finished refactoring and tearing out the parts they don't want--it has been reported they already have removed over 8.8 millions lines of code.

And that's another thing they did which is beginning to make more sense.  They now can modify the WebKit code to their heart's content to satisfy both browser and packaged apps as they see fit without upstream hassles.

So, that leaves us where?

It leaves us with the proposition that Google know there is still a need for good local Desktop software, a la the days of Microsoft Windows past, only they aren't saying it.  Microsoft still have a market for Windows-based legacy x86 software which have always had the performance characteristics and the gold standard applications which so many still rely upon today and Google know they can't capture this traditional buyer's market without local Apps.  Local Apps still rule.

Initially, it seems they released a photography-driven app which comes pre-installed on the Pixel Chromebook.

And rest assured, there will be others to follow.  Applications fuel sales.  It's that simple.

With the recent disclosure of the NSA PRISM surveillance program, that leaves a major stigma attached to doing anything in the Cloud, which can potentially hinder sales of their Cloud-based Chromebook.  How long that stigma stays around remains to be seen, but, Google isn't placing all of their eggs in one basket.

Realistically, Google can go in any direction after whatever market they choose--and they usually do.  They have the know-how, cash, and have shown themselves to be quite capable at software development--innovative in fact, much to Microsoft's disliking and worry.

Can Google pull off writing a decent Office clone packaged App?  If they did, that might really send sales through the roof.  All they have to do is make up their minds to do it and it will happen, which should be one of the major concerns at One Microsoft Way.

So, watch the video above and see if you agree with my thinking.

-- Dietrich

Related articles

• Living with Chromebook: Giving Google's OS a second chance
• The Puzzling Case of Google Chromebook Packaged Apps
• Chromebooks: Best PC for Your Bucks or Overpriced Browser Shells?
• How Google plans to rule the computing world through Chrome

Read More

Internet Time: Don't Blink

by Dietrich Schmitz

It's just another day at Linux Advocates.  The pace of news is per usual frenetic. 

One constant that is ever-present on the Internet: Change

In a story on TechCrunch Google made the decision today to fork WebKit to 'Blink' to advance their projects in the name of "speed and simplicity".  The statement from Google's VP of Engineering:

This decision clearly wasn’t made lightly. Indeed, as Upson stressed when I talked to him yesterday, “management asked a lot of hard questions” about this move, but in the end, the decision was made in order to reduce the technical complexity of evolving Google’s rendering engine in the direction the team wanted to go in.

This is, needless to say, going to be another 'game changing' move.  It's rather unsettling because as most developers become used to WebKit's complexities, now yet another fork is being introduced that will yet result in it's own variation.

Whether or not other vendors adopt Blink remains to be seen and depends on exactly what Google's Engineering Team plan to do with it and why.

It seems that they are dealing with a mix of technical issues and upstream latency from other contributing sources who need to be in sync on their own development timelines.

This is always problematic and the move to a fork relieves the need to deal with upstream hindrances as they deconstruct WebKit and freely make major changes to it without interference or raising an uproar with the open source community.  Recalling also, that for their own good reasons as it turned out, Apple forked the Konqueror browser's KHTML engine to WebKit.

Will Blink be welcomed?  I suspect not at least initially, but we need to let the dust settle and find out what develops as time takes it course.  It appears that Blink will be surfacing sooner than later in Chrome and ChromeOS, offering speculation that at least initially the changes in WebKit to Blink are minimal at first.

Well, there you have it.  Living on Internet time.  Never a dull moment.

-- Dietrich

[Edit: 4/4/2013 - This Developer FAQ page will answer many questions you may have.]

Related articles

• Google Chrome/OS to use new rendering engine 'Blink' based of predecessor Webkit
• Google forks WebKit with Blink, a new web engine for Chromium and Chrome
• Google forks WebKit with new Blink rendering engine for Chrome and Opera

Read More