A friendly note that KDE SC 4.5.1 will be tagged on 26 August.

So keep those bug fixes coming.

> Read More... | Digg This!

Today I had a call with Jussi from the Ubuntu IRC Council. We spent some time discussing a range of different topics, but then Jussi raised an important question which I think could benefit from some community discussion. Today we have many methods of providing free support for our users – the Ubuntu Forums, Launchpad Answers, [...]

> Read More... | Digg This!

When I first heard about Free Software in 1998 I was mesmerized by it’s potential. Sure, back then the software was complex and some would argue ugly, but underneath the rough edges was a thing of beauty — the opportunity for people to come together to make new things, and anyone with the inclination and [...]

> Read More... | Digg This!

I am just beginning to get into the planning stages for the next cycle for my team, and as part of this cycle we would like to really focus on attracting more developers to participate in Ubuntu. We would like to see more people interested in getting involved in packaging, fixing bugs, and joining our [...]

> Read More... | Digg This!

Hot on the heels of the announcement of the Natty Narwhal, I am tickled pink to announce the details of the next Ubuntu Developer Summit taking place in Orlando, USA from 25th – 29th October 2010. We also have a brand new Ubuntu Developer Summit website which provides all the details about how to get [...]

> Read More... | Digg This!

This morning at 8:19AM Pacific, the OGB passed:

Whereas Oracle has continued ignore requests to appoint a liaison to work with the OGB concerning the future of OpenSolaris development and our community, and Whereas Oracle distributed an email to its employees on Aug 13 2010 that set forth Oracle's decision to unilaterally terminate the development partnership between Oracle and the OpenSolaris Community, and Whereas, without the continued support and participation of Oracle in the open development of OpenSolaris, the OGB and the community Sun/Oracle created to support the open Solaris development partnership have no meaning, and Whereas the desire and enthusiasm for continuing open development of the OpenSolaris code base has clearly passed out of Oracle's (and thus this community's) hands into other communities,

Be it Resolved that the OpenSolaris Governing Board hereby collectively and individually resigns, noting that under the terms of the OpenSolaris Charter section 1.3.5 the responsibility to appoint an OGB passes to Oracle.

Also see the OGB Call Agenda.

> Read More... | Digg This!

I don’t tend to blog about appeals, but I came across this terribly sad story and I really want to encourage you all too also pledge and support him. Here is what happened, written by a friend of Colin: Colin & I have been close friends for 13 years when we started our MBA [...]

> Read More... | Digg This!

Disclaimer: I've never followed XCB development, this may have all been discussed already, but I hope this post is at least helpful as a data point illustrating what I understood and didn't understand.

Julien Danjou was disappointed recently because after porting dbus-launch to XCB, we had a bit of a "what's the point?" reaction to the patch. Why move "#ifdef XCB" up into apps, when libX11 is already a compat layer that uses XCB if available?

However, XCB remains a useful idea. For the litl OS shell, we've discovered that we really need certain X requests to be async. I ended up digging into the XCB code to find an obscure bug. Since I'd just read a bunch of XCB code, I figured I'd try to expand on the API docs. Hopefully someone can fix up my docs efforts and land them upstream. (If you happen to notice bugs in my docs patch, please comment on the bug.)

Better docs ought to help people know when and how to use XCB. But the library could also benefit from two larger changes inspired by the higher-level desktop toolkits.

1. Better support a main loop, in addition to threads.

Heck, even server-side developers are piling on this bandwagon lately. XCB goes to a lot of trouble to support multithreaded operation. Unfortunately, multiple threads messing with UI code is highly problematic for most actual Linux toolkits and apps. (More conceptually: because X replies are always returned in request order, and the X server is single-threaded, everything is serialized anyhow...)

I filed a bug with my theory on what XCB needs for better main loop support. Please, comment on the bug with corrections and improvements.

I'd like to be able to queue a reply handler as a main loop callback, something that's difficult with XCB as it stands, unless I'm missing something.

2. Export the protocol introspection data (and use it to "dynamicize" protocol bindings)

XCB is in the pre-gobject-introspection school of binding implementation, i.e. libraries full of autogenerated stubs. (Not saying gobject-introspection invented dynamic stubs; COM and CORBA have it, as does Qt, doubtless many other things before that. But gobject-introspection is the GNOME version.)

I filed another bug proposing that XCB could export a binary "typelib" for the protocol. This could remove all request-specific code from non-C language bindings. It could make the C language bindings smaller, too. And it makes it easy to write debugging tools and code.

If the C bindings were dynamic, they could export two other flavors of each request without adding bloat: a "fire and forget" flavor that ignores both errors and replies; and a blocking, synchronous flavor (matching the convenience of libX11). These two flavors would be nice to have, without them XCB code can be more verbose than it ought to be. (It's a poor advertisement for XCB when the patch to go from libX11 to XCB adds extra lines of code, which happens most of the time when you make a request with a reply - at least two lines in xcb, vs. one in Xlib.)

A bonus suggestion!

An easy X protocol debug hook would be fantastic. xtrace doesn't provide easy customization for a particular debugging problem or particular application. I'm thinking something like:

void xcb_set_trace(xcb_connection_t *c,
                   xcb_trace_callback_t out_callback,
                   void *out_closure,
                   xcb_trace_callback_t in_callback,
                   void *in_closure);

Where I'm not sure yet if xcb_trace_callback_t should just take raw bytes to be parsed by the app, or should be passed something higher-level including sequence numbers and opcodes. A problem with higher-level would be the need to parse the requests Xlib pushes through xcb_writev() inside XCB. A potential middle road would provide raw bytes to the trace callbacks, but export a simple X protocol parser API that apps could use for tracing.

A trace hook wouldn't be as useful without exporting the protocol description "typelib" so apps and tools can make sense out of what they're seeing.

Adding XCB utility

At the moment, for a single-threaded application XCB only helps you vs. Xlib in a narrow set of situations where you are willing to block on a reply eventually, but not right now. This is handy to "batch" requests as in the tutorial examples (search for useXCBProperly).

But XCB could offer much more, such as main loop async callbacks, dynamic language bindings, and debug/trace support. These are simple features to add to XCB, that would have been hard to add to the old libX11 codebase.

Just a bit more "what's in it for me?" would be helpful when it comes to convincing apps and toolkits to port over to XCB.

One more thing!

While I'm posting: it seems to be hard (impossible?) to use libxcb-glx because libGL doesn't export a way to get or set the context tag. Not sure where to file this bug or if I'm just missing something.

> Read More... | Digg This!

OK, before I begin, this is going to be a terribly presented ramble. I have written it, proof read it, and proof read it again, and it still sounds like a child with a crayon wrote it. This is because my thoughts are unstructured, but I am keen to share them anyway. Patience is appreciated, [...]

> Read More... | Digg This!

GSoC 2010 is finished. I would like to share my opinions with you.

It was great summer. I want to thank you all, especially Anne Marie Mahfouf, for trusting me I am good candidate. I learned a lot. Working with kdelibs and qt was an exciting experience to me. Trust me, I learned a lot. I believe that my little contribution will improve the quality of KHangMan. Hope so

Thank you annma, dfaure, djustice, hubnerd, Nightrose, pinotree, reavertm, SadEagle, sandsmark, sreich, thiago and others not mentioned for you help, support and answering to my questions. Anne Marie, you were very, very good mentor

Below is the summary of successes and new TODOs.

Successess

1. Recent files support
2. XML-based KHangMan themes. Now artists can easly create new themes and add them to application without code modification. Anne Marie wrote a document about creating 'new' themes.
3. Spiral mode - order of words to be guessed depends on user's individual results. Words hardest to user are displayed much often, than easier. Each user has his own list of words hardness. Spiral mode stores info in XML file. The files below show the way of activating Spiral mode and sample file with user's results. Words whose haven't been ever guessed, or not aren't listed in XML file.
   
4. Some bugs were found
5. Some bugs were patched

Things waiting to be done

1. Fixing saving recent files list, when applications is closed by pressing X
2. Cleaning hangovers of hard-coded themes. Probably prefs.h has to be cleaned
3. Patching switchable hangman images. Many bugs were found.

Meanwhile I had HDD failure with complete data lost, so I had delay. However, I want to stay with KHangMan after GSoC, so this delay doesn't seem to be important.

Thank you all for this GSoC!
Now I'm taking some days off. Expect next part of my questions (and commits ) for about 1.5 week.

Thanks!

> Read More... | Digg This!

Though this entry will be the last one about my GSoC, it certainly won't be the last one about my work on Krita or even on its new Transformation Tool. It was a great summer, I had a lot of fun working on this project. It was all the more stimulating so as I could follow the progress of the other GSoC students working for Krita. Everyone did such an incredible job, it gave me the envy and the energy to complete my project and make it as it is.

I'll be brief about what I did the past two weeks, as I prepared 3 small screencasts which will show you what the new tool looks like and how to use it.
Two weeks ago, I had just implemented warp functionality, so I still had some work to do on the UI.
First I changed the way to switch between Free Transform and Warp mode, so that the Tool Options Widget changes depending on the mode.
In warp mode, the user can either use default control points placed like a grid whose density can be changed, or place the control points by himself/herself.
In the paper I used as reference for the maths, 3 deformation functions were described, and I had only implemented one (affine). Thus I then added similitude and as-rigid-as-possible deformation functions.

Here is a picture I produced with the tool, which illustrates the difference between those functions. From left to right : original image (sorry if it's not very nice, I made it myself), warped using affine function, similitude function, and rigid-as-possible function.

Last week I essentially cleaned the code, fixed some bugs/weird behaviours, and changed some icons.

To close this entry, I wanted to show the results of my hard work, so here are some screencasts of the tool in action :

• Using Free Transform mode.
• Using Warp mode.
• And a last one using Warp mode to show the difference between warp functions.

> Read More... | Digg This!

This Friday (20th August) me and Ubuntu translations man David Planella want to spend the day making sure translations in Kubuntu are in tip top shape. Do join us on IRC in #kubuntu-devel if you want to help out. See the wiki page for some things we will be checking.

> Read More... | Digg This!

If you enjoy the box of marbles demo, now we extend it to include some basic network support. The premise is simple, look at this short video first (or watch on YouTube):

The code to handle the physics of the marbles remains the same, i.e. we just use Chipmunk physics engine. However, I added a simple feature to transfer marbles from one place to another. To keep it simple, it is done using UDP. The Qt network module supports UDP quite well, making the datagram code short and readable.

The intended use of this example is easy: run the desktop version and then run the mobile version (tested with Nokia N900). Each instance should find each other and start communicating. Again, we simplify the situation here and handle only 2 (two) peers. To facilitate troubleshooting, the application window title will contain the network address information, if the two peers are fully connected. To avoid complicated setup, discovery is carried out automagically through broadcast. This makes such a demo runs only under the same subnet, which is not a big deal.

It would have been much more fun doing the transfer between two smartphones (instead of a phone and my laptop). However, I own only one Nokia N900. Hint: I will not refuse your donation of Nokia N8 or (preferably) MeeGo-powered Nokia N9 (i.e. the N900's successor, whatever the real name is).

If you want to give it a try, head to the usual X2 repository and look at demo/marblenet subdirectory. Again, have the patient to follow the README file before you start compiling it.

Of course, feel free to extend this example to suit your (more wild) fantasy!

> Read More... | Digg This!

Follow up of the discussion about new UI elements: "it may look weird" first-look opinions vs positive results of usability testing. GMail has removed "select all/select none/..." buttons with single combo box for exactly one reason: elegance or UI uncluttering.

How do you like it? Feel free to share your comments below after a few days (preferably using the UI e.g. in gmail).

> Read More... | Digg This!

So, as looking that everyone is in the hiring mode...

Yes, Collabora is hiring. So if you are passionate for open source, want join a company that share the same passion as well, want to work from any place in the world and have at least some of these skills below, then we want to know you.

• KDE
• Qt
• Qml ( Qt Quick )
• C++
• WM and Graphics as a plus

Consider itself a serious KDE hacker? Don't be shy, we want to know you too ! KDE is an important part of our lifes now.

Then, what are you waiting for ?
Share your hacking ninja code skills contacting us at our hiring info channel, also known as email .

> Read More... | Digg This!