I have attended Guademy 2008 in the beautiful city of Valencia this year and presented a talk on WebKit and the Qt integration, produced some demos showing to embed QWidgets and QObjects into the QWebPage and how to interact with it, my other talk was a look at Qt 4.4. While preparing the slides I was in a constant wow mode. It is incredible what the Trolls added to Qt 4.4. It was probably a bit too much but it highlights what a team of excellent programmers can achieve when they focus on a common goal. Qt developers keep on rocking!
It was nice to catch up with some of my fellow KDE developers, see some GNOME developers, talk with local developers. I think events like the Guadec are really helpful, not only you can catch up with developers from your village, but also to see people from other villages and projects and discuss and get inspired. It inspired me to give KDE4 a try, fix some bugs, write a mail (which is still in the moderation queue) to kde-devel on KNumInput.
So whatever you want to develop Guademy into for the following years, make sure to keep it a place where people from the different desktop and non-desktop Opensource and Free Software projects can come together and talk to each other. There are things GNOME can learn from us, there are things we can learn and should learn from GNOME. I sincerly believe that whatever makes GNOME and KDE different we have more in common than what separates us.
So thanks a lot for organizing Guademy, your hospitality and see you next year.
PS: Because Jos asked, blogger.com works in the demo browser, this post is created with it.
Analytics
Tuesday, April 29, 2008
Friday, April 04, 2008
Slowly getting frustrated with Qtopia
So I have been working on this Qtopia integration. Being a good Free Software citizen I report the issues (most of the time with patches) upstream. Because I don't like non public tasks and prefer discussions on patches I had to decide to use the qtopia-interest mailinglist (note the increased volume since february). The amount of feedback, even on obvious issues is kind of low, admitingly disappointing. I understand creating a generic framework which is easy to customize for very different kind of devices is very hard. But this is what Trolltech decided to do with Qtopia, so I ask for advice how I can achieve my customisation as it is currently not possible, the feedback is zero, none, nada. This is something that engineers, creators of frameworks should love to discuss, use cases, approaches to API... no interest at all from Trolltechs side.
But where the frustration starts is copy and paste. Their approach to platform integration is, copy an existing platform, sed -i s/THEIR_NAME/YOUR_NAME/g, hack on it until it is working, copy code from the Qtopia libraries and change one line, add device specific code to the core Qtopia libraries, have five copies of yuv blending code (unaccelerated, bytewise..., we had to call the ambulance for raster...). So I have had to fix bugs/asserts/crashes on copy and pasted code where someone fixed the original code in qmodemsiminfo.cpp but forgot to update all places where they copy and pasted the whole class to. In this case certain modems send different responses when no simcard is inserted, a perfect example for abstraction (removal of copy and paste, fix without copy and paste).
With C and C++ you have languages where you can change/extend the behavior of so called "objects" (coming from Object Orientated Programming) with something called "subclassing". You do not need to copy the sourcecode to achieve that.
With Linux we have gained generic input systems (started in 2.4, really used in 2.6), sysfs (2.6) and I'm specially proud that a couple of device classes (battery, backlight, led...) originated from our handhelds community and found their way into mainline. So instead of writing one class for one battery, you can create one class that is going to work for every battery, with a stable userspace interface. When raster saw that, he read the battery class specification and implemented it. And it doesn't look like Qtopia will gain support for these 'classes' of devices anytime soon, instead you, as an integrator, have to manually parse your special device, no help is coming.
When doing hardware development, you don't follow the waterfall model. You create hardware, write drivers, work on GUI stuff, have iterations on everything (new hardware, new kernel, new GUI). The kernel gets better suspend resume handling, the initialisation order of drivers change. The input device numbering in userspace change as well (/dev/input/eventX). Because the kernel developers knew that these numbers in userspace will be random, they added ioctl's to get the vendor id, product id, version and name. So sane code would have a class/factory where you create an input device handler for a given Vendor and Product ID, or name of the device (e.g. "Neo1973 keyboard"), I would hide this behind a nice API where you only have to deal with the actual handling of keyboard data. Qtopia's approach to this is... Right, Copy and Paste and using hardcoded device numbers. So in the neo case you have four copies of this code, they don't include linux/input.h but duplicate the struct and use magic numbers instead of the defines..
You have to rush, you do mistakes, you do stupid things and this is kind of acceptable but what really frustrates me is that they justify their behavior. They justify copy and pasting the same code to four places (and changing the class name) as a way to avoid bloat (which the abstraction would add) and that hardcoding the random device number is the right thing to do and that finding the right device is bloat and not needed.
So dear people can someone explain me where the world of someone who has grown up in the Free Software world, started to program here, getting review and comments, creating patches, polishing them, reworking them due feedback is disjunct with the world of copy and paste. As a buddhist I know that my world is not better than their world, only different. So please can some one help me to understand how their world is different, how I could understand them, how one can help them to recognize that copy and paste and layering violations create more problems than they solve?
But where the frustration starts is copy and paste. Their approach to platform integration is, copy an existing platform, sed -i s/THEIR_NAME/YOUR_NAME/g, hack on it until it is working, copy code from the Qtopia libraries and change one line, add device specific code to the core Qtopia libraries, have five copies of yuv blending code (unaccelerated, bytewise..., we had to call the ambulance for raster...). So I have had to fix bugs/asserts/crashes on copy and pasted code where someone fixed the original code in qmodemsiminfo.cpp but forgot to update all places where they copy and pasted the whole class to. In this case certain modems send different responses when no simcard is inserted, a perfect example for abstraction (removal of copy and paste, fix without copy and paste).
With C and C++ you have languages where you can change/extend the behavior of so called "objects" (coming from Object Orientated Programming) with something called "subclassing". You do not need to copy the sourcecode to achieve that.
With Linux we have gained generic input systems (started in 2.4, really used in 2.6), sysfs (2.6) and I'm specially proud that a couple of device classes (battery, backlight, led...) originated from our handhelds community and found their way into mainline. So instead of writing one class for one battery, you can create one class that is going to work for every battery, with a stable userspace interface. When raster saw that, he read the battery class specification and implemented it. And it doesn't look like Qtopia will gain support for these 'classes' of devices anytime soon, instead you, as an integrator, have to manually parse your special device, no help is coming.
When doing hardware development, you don't follow the waterfall model. You create hardware, write drivers, work on GUI stuff, have iterations on everything (new hardware, new kernel, new GUI). The kernel gets better suspend resume handling, the initialisation order of drivers change. The input device numbering in userspace change as well (/dev/input/eventX). Because the kernel developers knew that these numbers in userspace will be random, they added ioctl's to get the vendor id, product id, version and name. So sane code would have a class/factory where you create an input device handler for a given Vendor and Product ID, or name of the device (e.g. "Neo1973 keyboard"), I would hide this behind a nice API where you only have to deal with the actual handling of keyboard data. Qtopia's approach to this is... Right, Copy and Paste and using hardcoded device numbers. So in the neo case you have four copies of this code, they don't include linux/input.h but duplicate the struct and use magic numbers instead of the defines..
You have to rush, you do mistakes, you do stupid things and this is kind of acceptable but what really frustrates me is that they justify their behavior. They justify copy and pasting the same code to four places (and changing the class name) as a way to avoid bloat (which the abstraction would add) and that hardcoding the random device number is the right thing to do and that finding the right device is bloat and not needed.
So dear people can someone explain me where the world of someone who has grown up in the Free Software world, started to program here, getting review and comments, creating patches, polishing them, reworking them due feedback is disjunct with the world of copy and paste. As a buddhist I know that my world is not better than their world, only different. So please can some one help me to understand how their world is different, how I could understand them, how one can help them to recognize that copy and paste and layering violations create more problems than they solve?
Subscribe to:
Posts (Atom)