alex diavatis | August 14, 2012

From the 200 extensions to the new 200 Gnome Apps!

This post was made with another stylesheet and it might be messed up!

What is in common with the golden winner of 100 & 200m in 2012 (and 2008!) Olympic Games and Gnome3? They are both born to run fast and break records!

The so unpopular Gnome3 won the Product of Year and Best Desktop Environment in Linux Journal Readers’ Choice Awards ’11, in every release makes a new record in extensions.gnome.org (almost 200!) and forces daily Blogs/Magazines to devote pages for it!

Gnome3 is sponsored by the largest Open Source company globally (Red Hat), is supported by colosseum firms (Intel, Oracle, IBM etc), it runs open standards (Feedesktop, FSF), it shares technologies with innovative new arrivals (Chrome OS, Tizen, WeTab), it syncs with few clicks with the largest Cloud Services (Google, Facebook, MS), it runs probably the most (or one of the most) devoted users community that an open source project ever had ..and is not for sale! It is an Open Source Desktop (aka OS) made by people, for the people!

Let the self-declared as “Professional Tech Journalist and Writers” on some famous popular Magazines, desperately looking for when Linus (who by the way has blamed every single thing but his code!) will blame Gnome3; when a Gnome Developer will have a “bad moment” to make a huge story out of it, and let them collect every single user complaining about this huge change from Gnome2 to Gnome3, to decide that Gnome3 grows unpopular.

The real problem of Gnome3 isn’t the Gnome Shell. Gnome Shell is a really smart idea as a whole (infrastructure and UI) but it just needs more polish, more time, more feedback to become better. And it will. The real problem of Gnome isn’t if Nautilus dropped the compact view. Jesus, was that so important?

The real problems of Gnome

This is my personal perspective of what is wrong with Gnome and I’ll make it really quickly.

Marketing: I don’t mean marketing to a commercial market as this was never the goal of Gnome (at least so far). Marketing in terms of providing users and contributors with better services to upload their themes, their extensions (which after 1.5 years are still in beta and not even easy discover-able!), providing some simple start-up guides with Gnome for the totally new users, and all these simple things.

Xorg: The life giver and the cancer at the same time for every Linux Desktop. The center of the universe. X Server can make Chuck Norris to crash. Linus can’t debug X Server. Gnome/ GTK 3.6+ (hopefully) will run in Wayland. So KDE. Huge, vast improvement.

Applications: Suppose you built your Gnome App. Where to publish it? How to package it? ..Let’s Google it. Naah not even Google can help you to that! Ubuntu solved that problem with Launchpad and the Software Center. But Ubuntu also seems to drop a bit of Gnome in every release.

There are solutions and Gnome and Free Desktop work on that, but I don’t know how soon we will see a Unified Apps Center that runs in every Distro, no matter the package manager.

C / SDK / Documentation: Most people cannot write in C. Most people cannot write in any language without an SDK. Add to the previous two the poor documentation and you get a full package ”I cannot develop with Gnome”.

This is the most serious issue of Gnome. Or should I say it was? Yes Gnome3 most important change is that FINALLY Gnome Team does documentation. Gnome Team FINALLY provides some tools to begin developing with Gnome Technologies. It is not ready yet, but it is coming. I made a quick start guide to begin with Gnome.

Alan Day in his blog about GNOME OS, he basically talks about SDK about developing and deployment. But many Tech Magazines focused in Gnome OS release which Alan never said that it will happen. Gnome OS is a platform to test the vanilla Gnome.

“But first, a clarification. The idea of GNOME OS has been around for a couple of years, and there has been a fair amount of confusion about what it means. Some people seem to have assumed that GNOME OS is an effort to replace distributions, so let me be clear: that is not the case. While the creation of a standalone GNOME OS install does feature as a part of our plans, this is primarily intended as a platform for testing and development. In actual fact, all of the improvements that we hope to make through the GNOME OS initiative will directly improve what the GNOME project is able to offer distributions.”

These are in my opinion the serious problems of Gnome. But the way I see it, Gnome Team has identified them and does amazing work in every direction. I see more people to involve with the project and a see a very healthy contribution from the community. I have Gnome since version one point something and first time I can see so much involvement in Gnome. A draw back was what happened with Ubuntu and Unity. But that belongs to past. It was tough at first, but we are now dealt with it and we’re ignoring it.

From the 200 extensions to the new 200 Gnome Apps!

The Gnome community made almost 200 extensions for Gnome Shell, why? Because it was easy and cool! Yes making UI in JavaScript is cool. And is easy. It is quite easy. Gnome Shell extensions have many constraints and they cannot replace a stand alone App. So what if build 200 new Gnome Apps for Gnome 3.6, in pure JavaScript?

It doesn’t need boring compiling. It doesn’t need dependencies (except if you do some crazy things!). You don’t need complex package managers. You just download it and it runs! You can deploy them in Ubuntu’s Software Center easily, or in your personal web pages. Emmanuele Bassi spot me today an amazing page with JavaScript /Gtk samples that I was ignoring.

You will find Windows, Dialogs, Progress Bars, Spinners, Buttons and Data Entries and many more, within 50 lines of code and with tutorials.

Don’t miss to see it, Don’t miss to try it!

I am very optimistic about the future of Gnome and I strongly believe that you can make some profit by building some small Apps with donation or even selling them! Yorba does!

This article was posted in Ideas, Software and tagged gtk, javascript. Bookmark the permalink. Follow comments with the RSS feed for this post.Post a Comment or leave a trackback: Trackback URL.

Philip Witte

Honestly, I wish more software was written in D.

D has modern productivity language features comparable to C# and Java, without sacrificing the power and efficiency of native binaries. Granted it hasn’t really been an option until just recently, but It would be great to see more software move to D with proper SDKs and documentation.
- liam
  
  Well, gnome has Vala. That seems modeled on a earlier version of c#, and it is quite fast.
  If you want D write the xml bridge to gobject and with introspection you get your bindings.
  - Philip Witte
    
    No, Vala in it’s current state is not as fast as C/C++, D, or even Mono C#, though I’m sure that will improve in the future.
    
    Beyond that however, Vala suffers from a few very important design mistakes:
    
    First, it’s ref-counted not garbage collected. This is arguably slower and less stable, plus very easy to introduce circular references which will prevent memory from being collected all together. Honestly, I would probably rather manually manage memory than have to analyse every reference for those tricky-to-find ref loops.
    
    Second, there’s no overloads or operators in Vala, which is a big deal when creating and using math libraries. If you write game code, or anything math oriented really, this is serious issue.
    - liam
      
      http://jpaflacerda.wordpress.com/2011/11/08/vala-benchmarking/
      Vala seems to be pretty close in speed to C. For short tests, mono, as expected, is the slowest.
      The ref count GC is very fast (since even sophisticated GC techniques like Java uses still lead to unpredictable stutters ). Of course, you can end up with unreachable allocations, but it doesn’t seem to be a huge problem. My guess is that the most common cause of leaks are cyclic references and for those Vala expects the developer to recognize them as such and mark them as weak refs. As you say, it can be tricky.
      Vala really seems designed for rapid development without suffering from unacceptable performance, so it’s not always going to be the best choice, but the lack of overloading support is strange (the reason seems suspect, IMHO).
      - Philip Witte
        
        Those Mono benchmarks are probably flawed, in that they’re testing from start to finish. Mono always has a bit more to start up because of it’s heavy VM and JIT, while C applications (which Vala is) do not. I did a few simple math tests (vectors and matrices) ~6-8 months ago between D, C/C++, Mono, and Vala and Vala was the slowest. My tests didn’t compare the startup costs, only performance of “runtime” code (code that would be executing “in game” for example). It’s possible that I wasn’t compiling with all the appropriate flags, though I did my research well there, so I doubt it had anything to do with that.
        
        That said, my recent tests between D, C/C++ and Mono have shown that Mono is significantly slower than native languages. Also, those benchmarks are interesting since Vala seems to perform identically to C. So it looks like I need to do more tests with Vala, just to be sure.
        
        Concerning memory, I think GC is better all around. Modern GC’s are incremental, not “stop the world”, and don’t suffer from random stutters unless you’re pushing memory to the brink in which case you’ll have memory issues regardless. Plus you have easy ways to mark blocks as non-collected for things like Memory Pools where you’re managing everything yourself anyways. The big performance problem with ref-counting is you have to count each reference always, whereas in GC you can scan incrementally and stop when a time threshold is met. Since most applications usually aren’t allocating/deallocating memory every cycle the GC has more than enough time to collect at it’s own pace, instead of slowing down everything along the way. With the big added benefit to the programmer of not having to worry about memory cycles at all.
        
        You also get things like memory compression with GC, where I don’t think that exists in Ref Counted systems (granted, I don’t know if that’s a design or implementation issue). Also, the lazy-deallocation of GC is usually a good thing (for performance and memory recycling), while in Ref Counting you have to manually craft that, or pay for deallocation at the end of each scope.
- http://profiles.google.com/l33ts0n Arron Washington
  
  D, the language whose homepage links to a non-existing domain when you click on “Editors” or “More Tools.”
  
  Trolling aside, I tinkered with D in the past, and its a very nice language — especially after they finally wrangled the whole Phobos / Tango deal — but it’s still and has always lacked tooling support. One of the necessary trade-offs for me to deal with a staticly typed language (I normally do Python or Ruby) is robust tooling: an IDE with an integrated debugger, code completion (this IS a static language, after all), and the rest of the typical goodies are pretty much required. D still doesn’t have those, but hell, Ceylon, Kotlin, Dart — even Phantom if you wanna go there — have robust IDE support even though they’re all much younger. It really makes you question D and its value proposition when everything else seems to be zipping past it so quickly in terms of tooling support.
  - Philip Witte
    
    MonoDevelop + Mono-D is actually quite good at project management, refactoring, and code-completion (though it’s not done yet). So the IDE support is improving a lot. One of the main reasons D’s been slow with tooling support is in part because of early design choices which are being fixed, and in part because it’s meta programming is so powerful you need to perform a huge deal more static analysis on the code to understand what variables exist and what types they are. C++ has very poor code-completion support in the majority of IDEs, even after so long, because it has similar ability.
    
    Again, MonoD is tackling these issues, and there’s a joint effort to standardize the parser and make that available to dev tools, but yes, it’s not quite there yet. Luckily though, D is now very stable and could be used to write some high-end commercial apps.
    
    Honestly though, I’ve been spoiled by the convenience of languages like C#, but I’m not willing to sacrifice performance in some areas (nor do I think you should have to choose between the two). So really, only D offers the kind of productivity features (within the language) _and_ the performance of C/C++. I can’t really think of another option at this point.
liam

Regarding applications, ostree seems to be part of the attempt to help with this.
From my research ostree looks to be an umbrella project for linux DE’s. It is supposed to include a continuous integration service that spits out installable binaries for gnome. This encompasses unit testing so there are no regressions (though to reach the goal of being regression fre a few other pieces are needed like replacing the package system with something that is more aware of the relationships between code units, a swell as snapshotting, which seems to be tied to btrfs), a new way of handling installs (no more packages, now we get bundle, like osx, and no more package manager, since packages are now gone—don’t freak, the metadata of packages will be replaced with something supposedly much better), and,.most important of all, a way to run a multiroot system (allows for parallel installs). This last bit looks to be useful for development since you could keep one root up to date with the latest Gnome builds and be able to seemlessly, and somehow safely, share user data across roots.
This is a huge part of Gnome OS.
I’ll be going to a talk Colin is giving on Wed about ostree. Hopefully he can fill in some details for me.
BTW, despite what Gnome has been saying, Gnome certainly looks to be going in the direction of a distro. They certainly seem to be thinking about it in that way to me.
I’d also add one more thing to the list above: the alienation of long time gnome CONTRIBUTORS with regards to the direction of gnome. Simply read some of the mailing lists over the last two months in particular (see gnome desktop, nautilus, gtk, at a minimum, and of course the gnome shell ml). Frankly, one of the most disturbing things is the lack of transparency with regards to design decisions. Yes, you can see mockups, but you can’t read the thoughts that went into their making. Someone suggested that major Gnome design decisions (like the new nautilus… btw, the fud that was apparently used as justification for the redesign is truly disturbing;quite simply, this should NEVER happen) be introduced in a major forum (like the gnoke desktop ml) but the idea was shot down by Allan Day (and possibly others). Design should be an open process and involve all stakeholders, not something that is done on an unrecorded irc channel.
Pingback: Links 16/8/2012: Calligra 2.5, LibreOffice 3.5.6 Released | Techrights
ScionicSpectre

It is amusing to me how we have such amazing technology, but it’s true that until recently the resources to help developers actually interact with this technology has been so severely lacking. I think Qt has done a pretty good job of getting people involved with their toolkit- of course, the relationship with Qt and KDE is insanely different from GTK and GNOME. GTK is largely a product of GNOME these days, while KDE has traditionally been a ‘consumer’ of Qt.

Still, GNOME 3.0 itself was a huge achievement. I almost feel guilty to be asking even more of it now, but to see how much we can do with the resources we have is very encouraging. Some of it will be rough, but we have the capacity to really push it to the limit. I will be very happy to see a new flux of applications made based on GNOME 3′s emerging HIG, especially if it inspires people to come up with creative ideas for applications that have been ignored in the past due to the WIMP-focused era of GNOME 2.

I think we’re really going to pick up some steam. As the vision of GNOME is more fully realized, and we get these new applications, I think people will begin to realize it was the right direction to go. I’m sure Ubuntu users won’t be able to resist some of the upcoming goodies, even if they don’t think they agree with the design ethos now.