No fallback mode in GNOME 3.8

As announced by the release team two weeks ago, the fallback mode will be gone in GNOME 3.8. The decision was taken after some discussion on the mailing list back in June and in October, as well as some discussion during Boston Summit 2012. We also have a wiki page detailing the discussion arguments.

In my opinion, the biggest issue we had with the fallback mode is that, with only a few cycles, it quickly became clearly not tested enough, and lacked manpower for proper evolution along with other GNOME 3 changes. This resulted in a much lower quality than what we expect from GNOME. Moreover, several applications actually started requiring Clutter, and therefore didn't work anymore in a real fallback manner (ie, where you have no proper 3D acceleration); this means the fallback mode, when really used as a fallback, was not offering a fully usable desktop, and would be considered more like an alternative shell than a fallback mode.

Where does this leave us?, you might ask.

Well, for a start, GNOME 3.x had several iterative cycles to bring tons of improvements. Many users who were using the fallback mode because they didn't like the GNOME Shell experience are now happy with 3.6. But we're going an extra step starting with the next version: there is an explicit goal of having the project provide a set of extensions to help even more people preferring the fallback mode experience. The tentative list of what the extensions would provide is classic alt-tab, task bar, minimize/maximize buttons, and a main menu. This effort is being publicly tracked, so everyone can participate: if you're interested in contributing to these extensions, don't hesitate, I have no doubt help will be welcomed! Update: this topic is being discussed on desktop-devel-list right now!

There will also be work on improving GNOME 3 when running with software rendering. Of course, llvmpipe was a good start, and llvmpipe itself is getting better and better. But in addition, there are plans to offer a reduced resources mode, with fewer animations, that would be used in different circumstances, including when using software rendering. This should really improve the performances under llvmpipe.

There might be cases where these improvements will not be good enough in 3.8 (or with the Mesa and llvmpipe versions available at that time), resulting in a GNOME version that people might not consider acceptable in terms of performance or hardware support. Things will improve with time, obviously, and 3.10 will solve more and more issues; hence I would recommend to people hitting such issues to stay with 3.6 for a few more months.

All in all, the community is working on having future versions of GNOME, starting with GNOME 3.8, offer an improved alternative to the fallback mode.

Future of gnome-panel (and other fallback components)

Of course, this raises the question of what happens to the components of the fallback mode: gnome-applets, gnome-panel, gnome-screensaver, metacity, notification-daemon, polkit-gnome, etc. These components don't necessarily have to go away: they're just not part of what the GNOME project officially releases, and people are welcome to keep working on them. It's really up to each maintainer.

As for myself, I do not intend to keep maintaining gnome-panel after 3.6.x. I did a 3.6.2 release a few days ago, and it might well be what I consider my final release. If there's a strong push for some patches, there could be a 3.6.3 tarball... So, if you want to keep gnome-panel alive, contact me and you can become maintainer. As long as I either know you, or I can see that you have some minimal coding abilities, you'll get the maintainer hat for free :-)

Now, I believe a group of people could well adopt all the fallback components and keep building a great desktop, on top of other GNOME 3 bricks. They wouldn't even have to restrict themselves to what the GNOME 3 vision is (which is something that blocked some people from seriously contributing to gnome-panel). I don't think it'd be actually too much work: the code is already there! Of course, there would be some compatibility bits removed from other GNOME modules that would need to be moved elsewhere, but in most cases, it's really just about moving the code, not re-implementing things.

To be honest, I would really have loved if the MATE people had taken such an approach (maybe it's not too late?). I think it's a more reasonable effort than effectively forking all of GNOME 2, including obsolete technologies, as the amount of work is much more reasonable.

I'm eager to see if a group will step up to keep alive this old code, which represents thousands of hours from many of us! I wouldn't use it, but it would still make me happy :-)

Almost three years passed since latest release of QJson. A lot of stuff happened in my life and QJson definitely paid for that. I have to admit I’m a bit ashamed.

So here we go, QJson 0.8.0 is out!

What changed

A lot of bugs has been smashed during this time, this new release will fix issues like this one and this in a nicer way.

QJson’s API is still backward compatible, while the ABI changed.

Symbian support

Some work has also been done to get QJson work on the Symbian platform. The development happened a long time before Symbian was declared dead.

Currently I do not offer any kind of support for the Symbian platform because IMHO Symbian development is a mess and given the current situation in the mobile world I don’t see any point in investing more efforts on that.

Obviously Symbian patches and documentation are still accepted, as long as they don’t cause issues to the other target platforms.

QMake support

QJson always used cmake as build system but since some Windows developers had problems with it I decided to add some .pro files. That proved to be a bad choice for me since I had to support two build systems. I prefer to invest my time fixing bugs in the code and adding interesting features rather then triaging qmake issues on Windows. Hence I decided to remove them from git.

If you are a nostalgic you can still grab these files from git. They have been removed with commit 66d10c44dd3b21.

Relocating to Github

I decided to move QJson’s code from Gitorious to Github. Github’s issue sysyem is going to replace Sourceforge’s bug tracking system.

I currently use Github a lot, both for personal projects and for work, and I simply love it. I think it offers the best tools in the market and that’s really important to me.

QJson’s website and mailing lists are still going to be hosted on Sourceforge.

---

I think that’s all from now. If you want more details about the changes introduced take a look at the changelog or checkout QJson’s website.

Some weeks ago, I had the pleasure to do a talk at the openSUSE conference in Prague, about systemd (its current state in openSUSE and what we plan for the future) and dracut (mkinitrd replacement).

For those of you who didn't attend the conference, you can watch my talk on YouTube (thanks to openSUSE awesome video team for the recording):

And you can even get my slides ;)

Maybe some people already expected this to happen, but for me it is still a surprise that I actually did it. I put myself up as a candidate for the openSUSE Board. 

I started the XWT project almost one year ago and athough I talked about it at FOSDEM, I never found the time to formally present it. Those are busy days at Xamarin! Anyway, let’s go ahead.

XWT is an open-source cross-platform UI toolkit for Mono and .NET. What’s special about XWT is that it is built on top of the native widget toolkit of each supported platform. So rather than a new widget toolkit implemented from scratch it is an abstraction that wraps the native toolkits using a common API. The end goal of XWT is to allow building applications which look and feel native in each platform. Here are some screenshots of a sample application running with the GTK and Cocoa backends:

GTK backend

Cocoa backend

I initially created XWT with the idea of building MonoDevelop on top of it. Around this time last year we had a discussion about how we could improve the look & feel of MonoDevelop in Mac and Windows. MonoDevelop is built with GTK# 2, which worked very well on Linux, but which had (and still has) some issues on other platforms. Although GTK is a cross platform toolkit, not all backends have the same quality, and not all features are completely implemented. So XWT would allow us to have a native look and still reuse most of the code. However, rebuilding MonoDevelop with XWT is a lot of work and we needed to fix the Mac and Windows issues as soon as possible, so we decided to invest our efforts in fixing the most annoying GTK bugs instead of going the XWT route.

Even though we are not going to immediately migrate all of MonoDevelop to XWT, at Xamarin we have started using it for some UI code that needs run in MonoDevelop and Visual Studio. An example of this is the Android designer. The designer is implemented in XWT, and we use the GTK backend when running MonoDevelop and a WPF backend when running on Visual Studio:

The designer running on GTK in MonoDevelop

The designer running on WPF in Visual Studio

XWT vs Native Toolkits

At Xamarin we have always advocated for using the native toolkit of each platform in order to take advantage of all features offered by the platform and be able to build the most visually rich and performant applications. How does XWT fit on this idea?

XWT has three important design features:

• User interfaces implemented using XWT can be embedded inside a native UI. It means you can build your application using the native toolkit when you need advanced platform features, and you can use XWT for more simple UI that can be shared.
• XWT backends are built on top of native toolkits, so XWT widgets really look and behave like native widgets.
• XWT is a UI toolkit abstraction, so it’s about abstracting common UI idioms as widgets. XWT will have support for the most common widgets such as entries or buttons, but it will also provide higher level widgets which are more “semantic”. It means that XWT applications will be constrained to use those higher level UI idioms, but each of those idioms can have a platform-specific implementation which takes full advantage of the native toolkit features, and which can abide for the platform UI guidelines. 

There is a tradeoff between portability and functionality. XWT is not for everybody. It wont have the richness and the low level features of a native toolkit, so it will not be suitable for applications which require advanced UI features.

Design Principles

XWT looks like GTK#. It uses a similar layout model and class names. That’s basically to make it easier to migrate GTK# code to XWT, not because GTK# is superior to everything else (although maybe it is). However, there are notable differences. The API design has an important focus on simplicity and usability. Here are some important differences with respect to GTK:

• The widget hierarchy is mostly flat. There is a Widget class and most of other classes directly subclass it. There are no unnecessary infrastructure classes. For example, there is no Container class, any widget can have children if they need to.
• Widgets are visible by default (I still haven’t figured out the reason why they are hidden by default in GTK).
• No concept of GdkWindow. You have a widget, that’s all.

I’m a firm believer of usability-oriented API design. Many libraries are designed using complex class hierarchies and abstractions whose purpose is to make the library code easier to reuse and maintain. That is, the code is designed to facilitate the work of the library developer, not the work of the library consumer. That’s a bad approach since the library will be implemented by only few developers, but potentially consumed by thousands of developers.

Features

Here are some details about what’s currently supported by XWT:

• XWT currently supports 3 backends with different level of development: GTK, Cocoa (Mac) and WPF (Windows).
• XWT can instantiate more than one backend at a time, and run those side by side (with some limitations). For example, you can have XWT use Gtk and Cocoa in the same application, depending on what is hosting your code.
• The basic widget library is mostly complete.
• It has a drawing API, very similar to Cairo.
• There is no visual designer yet, nor any markup language for representing windows. My plan is to use XAML or a simplified version of it.
• XWT can be extended in different ways.
• Applications can create subclasses of XWT widgets, or create new widgets.
• New backends can be plugged into XWT
• Existing backends can be extended
• The API is not yet stable and can change at any time.

Future

The work on XWT will continue, there is still a lot to do. XWT is already already included in the MonoDevelop core. Although we don’t plan to do a big migration effort, we plan to gradually use XWT in the implementation of new features.

If you are interested in XWT, you can get the source code from here:
https://github.com/mono/xwt

There is also a mailing list:
http://groups.google.com/group/xwt-list

And an IRC channel:
irc://irc.gimp.org/xwt

Contributions are welcome!

Like everything, openSUSE is not perfect. Bugs crop here and there, or there is missing / quirky functionality that users may run into. Being a distribution of heterogeneous software, this means that bugs fall into these categories:

• Upstream bugs in the software shipped by openSUSE

• Bugs in the packaging

• Bugs in distribution-specific setups or that derive from interactions with these setups (e.g. kernel, low level software stack, etc.)

To improve the distribution and to act like good FOSS citizens, distribution bugs need to be divided from upstream bugs: the former need to be properly fixed by openSUSE, the latter need to be communicated upstream so that everyone would benefit when they are fixed, including our favorite green distro.

Also, when dealing with bugs, one also runs into bugs that are invalid (local errors, for example), duplicated reports, or already fixed in newer versions.

So, how do we start improving openSUSE, and in particular the KDE part of openSUSE (since that’s what we’re talking about), from the current situation? An effective method is to triage open bug reports, verifying if they can be reproduced, reporting upstream bugs in the appropriate place, and closing off duplicate reports.

And to this aim, we will have a bug squashing session on 15th and 16th November, where you can help with reducing the number of KDE bugreports reported for openSUSE (and we for sure have more than enough of those). If you would like to help KDE in openSUSE, feel free to join.

There are no special technical knowledge requirements except for basics like being able to use the Bugzilla interface at http://bugzilla.novell.com. Having a recent KDE version installed is recommended (use either KDE:Release:49, KDE:Distro:Factory or KDE:Unstable:SC).

On the wiki page at http://en.opensuse.org/openSUSE:Bug_Squashing_KDE we tried to sum up everything relevant (comment and corrections welcome). Please make sure you read the bug screening guidelines at http://en.opensuse.org/openSUSE:Bug_Screening_KDE too.

If you want to help, hop during those days on the #opensuse-kde IRC channel on the Freenode network.

Happy bug hunting!

As announced on the opensuse-kde mailinglist, KDE SC 4.9.3 packages are available from the KR49 repo.

With those packages comes akonadi 1.8.1 which includes a lot of fixes from the recent KDEPIM coding sprint. It should improve performance and more importantly, KDE SC 4.9.3 and akonadi 1.8.1 should solve all known data loss bugs. A special thanks to all the PIM developers putting a lot of effort into improving KDE’s PIM stack!

You can find instructions on how to update on the openSUSE wiki.

A few weeks back I had the opportunity to attend the MonkeySpace conference.

For all of you that missed it, I highly recommend planning on attending it next year.  If you did miss it, this year is not completely lost as the awesome folks over at Monkey Square are planning on making the videos of the sessions available at some future date.

I had a great time meeting some awesome people and attending some great sessions.  There are several really exciting technologies out there that are worth following discussed at the conference.

Here is a bit of a recap of some of the sessions that I attended.

First, The top secret keynote that Miguel De Icaza delivered.  The major topic was the release of Mono 3.0 and the future of the ecosystem.  Some of the really cool features of Mono 3.0 is full c# 5.0, System.Net.Http, TPL DataFlow, Code Contracts, entity framework, razor, asp.net mvc 4, F# 3.0, and 64bit support on OS X.  The 3.0 release is very exciting not to mention lots of ‘lameness’ will be going away with the new async stuff.  There are also improvements to sgen the new garbage collection system in Mono that should help improve performance.  Mono is seeing a lot of success in the gaming side of the market as well.  Some other areas that will receive focus are code analysis, bug finding, and profiling tools.  In the next year Xamarin expects to deliver new MonoTouch and Mono for Android versions based on 3.0.  Very exciting stuff!!!

Second, ServiceStack.  This was a very full session and I was lucky to find a spot to stand in at the back of the room.  Sadly this meant that I missed parts of this presentation, but definitely plan to look more seriously into it once I get the chance as a replacement for wcf.  Hopefully the video comes out sooner than later for this one!

Third, GitHub.  Phil Haack did a great job presenting on GitHub and the awesomeness that it is.  I had seen some of it before, but really like seeing the command line style interface that is built into the web interface in action.  He also did a demo of the API that is available and there were some really cool things in there.  I’m very interested in the possibility to integrate pull requests into some Continuous Integration system.  It would be cool to know right away if the pull request would break the build or not.

Fourth, Vernacular.  Aaron Bockover, now a Xamarin employee, was great enough to post his slides here.  If you are working on a project that is targeting multiple platforms and need it to support multiple locales then this is definitely a project you need to check out.  Very promising!

Fifth, Mobile Development with C#(book).  Greg Shackles is definitely someone to follow and watch in this market segment.  He has been doing some great work including writing a book about it.  If you are considering writing a mobile app that is targeting multiple platforms I definitely recommend picking up this book.

Sixth, Effective MonoDevelop.  Michael Hutchinson is an awesome developer that has contributed a great deal to the MonoDevelop project.  His blog has some great tips that makes using MonoDevelop even better.  It is definitely worth the read.

 

Apart from all of the sessions there was plenty of time to hang out with some rockstars in the Mono community.  It is always great to chat with them in person and get feedback on questions and problems.  I am definitely looking forward to next year’s conference!  Keep up the great work!

 

Introduction

A few days after  the openSUSE conference is over, it is the right moment to write my report.

For me it was the first openSUSE Conference which i attended to. It was the first time that i was surrounded by hundred of Geekos during 4 days and interacted with people from the openSUSE Community , SUSE  other distribution and other FOSS projects as well. People from openSUSE , Gentoo , Ubuntu , Fedora have been there to collaborate, make a presentation , discuss about FOSS and at the end of the day have a beer (pivo, in Czech). So what did i do during the oSC2012?

What did i do

First of all , at Day Zero, the whole Greek community went to the Venue so as to help with the setup up and explore the Venue as well. It is a truth that i I was amazed by the infrastructure, the coordination and the high level of education provided by the University. I had the opportunity to get into a laboratory and  saw that the students do make their own experiments there. At the end of the day we drunk a couple of beers and personally  discussed with the Spanish spoken guys. We had fun by expressing our ideas and interact with people who live far away from European continental .

Actually the first day i  helped at the registration desk  by giving swag ,all the necessary staff and piece of information to the recently (or not) registered attendees. By the second day and until the end of the conference i worked at the Social Media team with Kostas Koudaras and Jos Poortvliet. Our goal was to spread to the social media (twitter,google+,facebook) the presentations,talks,workshops and what was going on during the conference. In that way people who attended to the conference were up-to-date for what is going on and people who didn’t attend had  also the opportunity to enjoy the conference by watching the live streaming. Finally i did translate some of the tweets in Spanish , so the Spanish spoken people be up-to-date as well.

Presentations-Attendance

Apart from what did i do , i attended to some presentations. So here i list the presentations:

1) Agustin Benito Bethencourt: SME as target for GNU/Linux distributions

2) Jos Poortvliet: openSUSE Around the World

3) Lightning talks

4) Prof. Joe Doupnik: A complete server to assist charities

5) openSUSE Project meeting

6) Izabel Valverde: The openSUSE Travel Support Program

7) Kostas Koudaras: Ambassadors 2.0

8) Michal Hrušecký: Whats new in openSUSE Connect

9) Kostas Koudaras: oSC13 The Spirit and the City

I admit that i would like to attend the following presentations but finally it wasn’t possible :

1) Henne Vogelsang: Building RPMs for starters…

2) Stephan Kulow: Packaging of perl/python/ruby/java

My presentation

Apart from attending at some presentations i did make my own. Actually my presentation was related to my failure  in GSOC 2012 with openSUSE Project. I explained to the crowd [ok i admit i was a bit nervous , it was my first presentation in an international conference] who am i , which are my plans and encouraged people to participate at the next Google Summer of Code with openSUSE Project. Finally i mentioned that what a failure does mean and what doesn’t mean in that case. My presentation  is available here.

Interaction-Feedback

In my opinion it’s very important to interact with people during a conference. Apart from the presentations you gain experience, you discuss with other people about an idea that you have in common. So my interaction was :

a) Met people from Latin America (Sebastian, Axel) and discuss with them about the community there.

b) Met Baltasar Ortega who owns the kdeblog.com and become collaborator of the blog. Now my spanish posts  appear also at kdeblog.com

c) Discussed with my mentor of GSOC 2012 about my next steps at the project

d) Discuss about participation of openSUSE Project @ LinuxCon with Jos Poortvliet and met Ralf Flaxa as well

d) My openSUSE Member application was accepted. Also i became member of openSUSE Member Officials Team

e) Met Ramon Roca and discuss with him about his project

f) Joined the conference by another point of view : as a volunteer who worked on a group.

g) Beers,beers,beers

Conclusion

According to some people, FOSS conferences are dominated by corporate representatives promoting their products.I disagree with that  because in my point of view FOSS conference are dominated by participants , volunteers , FOSS communities and FOSS companies. The main point is the interaction between all of these parts .

See you at the next openSUSE Conference!