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!

Hello =]

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!

As some of you might have noticed I’ve created a repo on GitHub for F-Spot under the mono umbrella – F-Spot on GitHub!

I have left the repository on git.gnome.org/f-spot and will try to sync up changes in master regularly. I’d like to thank the awesome GNOME project for hosting F-Spot and want to be clear that I have absolutely no plans of dropping GNOME support in F-Spot nor diminish F-Spot’s GNOME integration in the future. On the contrary, as the .NET bindings for the GNOME  3  platform are improving I expect to be working on further GNOME integration for F-Spot.

The goal in moving F-Spot over to GitHub is purely for the benefit of its development technically as well as to breath new life into the project through the wider GitHub community and feature set.  Github provides several really cool features, one of the features that I’m looking forward to taking advantages of is the pull request system.

Currently, contributors will typically clone a repository, create a patch that fixes some bug, file that bug in Bugzilla and attach the patch, which then sit and wait in the hope that the developers will notice the bug and accept the patch.  What seems to happen with projects, particularly F-Spot, is those bugs will sit there and bit rot.  Either someone will come alone, see the bug and possibly rebase the patch against git master or it’ll be forgotten until it’s no longer valid.  The pull request interface isn’t some silver bullet, but I see it making the process much simpler and much more discoverable for both patch contributors and maintainers alike.

With the GitHub system, it’s really simpler for any user to come along and fork F-Spot.  Once forked they can fix a bug and do a pull request.  At this point there is a nice list of pull requests or shame list (a list of all the patches I haven’t addressed yet!).  There are some other features such as issue tracking and a built-in wiki that comes with GitHub which I’m not sure if it will get used, but time will tell.

Another goal I have for the project is to port it over to OS X and Windows.  GitHub has a nice client for both platforms as well as conveying the idea that F-Spot is intended to be cross-platform application with GNOME support more clearly than being on GNOME’s git does.

I hope everyone will appreciate this new workflow and will enjoy the improvements that are to come in F-Spot.  I’m excited to continue development on F-Spot and look forward to the future of such an awesome photo management.

Español

Despues de la fiesta de lanzamiento del openSUSE 12.2 que tuvo lugar en Madrid , el Martes que viene [06/11] tendrá lugar fiesta de lanzamiento en Barcelona! Mas información podéis encontrar aqui.

English

After the openSUSE 12.2 Release Party took place in Madrid , the next Tuesday [06/11]  the openSUSE 12.2 Release Party will take place in Barcelona! More info can be found here.