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?
posted by zecke @ 1:01 AM
11 Comments:
This is a really shocking report in my opinion. I think copy & pasting is one of the most crucial mistakes you can make when you need a very flexible framework. As you add more and more copies, changing the behavior of all of them will become more and more complicated and end in absolute chaos.
I know that a very large telecom company here in Germany recently still used an accounting system based on copy & paste, it was (is?) a complete mess and troubles with it cost the company a lot of money. It isn't their fault, as this system grew historically (it even existed before oop became popular), but if you have the chance to do it better, please do it!
hmm lets see.. copy a working device profile and change names, etc. or start all over from scratch..
really, give it a break.
How about we talk about buggy hardware and the software workarounds needed...
oh dear god! code resuse! copy and paste!
hehe,2nd anonymous from Trolltech(?). There is nothing against code reuse but if two devices need the same code (+800 lines of code) for the same thing, you should put this code into a library.
Copy and Paste has alwyays the danger of bitrot, put the common code in a common place, this tends to be a library, if you have fear about the code size, make it a static library linked into it.
For starting integration, there is nothing wrong with a skelteton, or a script to create one. The problem starts with copying whole classes over and over again and letting things bitrot.
Device profiles...
That's one thing I'd do differently if I knew how they'd be abused.
The idea was simple, people need to pass around patches, commandlines, code, etc. to make Qtopia work on a device. It was unweidly and error-prone. Why not just package that up into a single directory activated by a simple configure -device mydevice?
The initial implementation was done for convenience so it covered only the things that had been encountered, generally has a series of general-purpose hooks into existing functionality. As with all build system functionality, the old methods continued to work fine (but will be deprecated and removed at some point in the future).
As time went on though people did more and more with device profiles. The big problem is that most of these things were implemented as special cases instead of general purpose functions. Want to support a device-specific config file? Surely you'd whack a handler in 1 place for that right? In Qtopia, it's explicit for every file that gets installed! The adding of libraries and apps that aren't really device-specific was the next logical error (starting with things like the Logging app, originally in the Greenphone device profile despite being mostly device-agnostic). The copied drivers... ew. I'm actually quite surprised that nobody thought to refactor these as they added new ones, even if it was just a basic "pull the common bits out and leave the rest as-is" refactoring.
It's something that I have worked to improve but there's only so much you can do to a system like this incrementally (without breaking all existing device profiles, something we just can't do). As time goes on I'll work to root out the problems caused by lack of build system support (eg. replace conf file special cases with a general case) but it'll take time and that has to be balanced against everything else I'm expected to do (and when something isn't actively broken it's hard to consider it more important than something that is).
Well, that's enough ranting from me. Hopefully this helps to reveal a bit how things got so bad and gives assurances that someone is thinking of ways to fix the problem.
Hindsight is always 20/20. Yes, there are a lot of things we could have done differently. Sometimes it isn't possible to know what should be abstracted until after the fact.
Judgement calls are made on the fly, and we go back and deal with them later when we have the time. No one is perfect, and I'm sure there are quite a number of examples in your code we could point at and say "huh?". The only truism in software is "everyone's code is crap in someone else's eyes".
We thank you for pointing out these things, but please be aware that our time pressures can make it difficult to address them the second they are discovered.
We want to work with the community on this issue. If you've found an actual bug then great - we want to know about it. But when it comes to opinions about what the code should look like ... well, opinions differ. :-)
It's a good thing that Zecke brings this to the surface, although I have noticed that Qtopia has QA problems without the intensive scrutiny he has been giving it.
To be fair to Trolltech, the copy paste method (lol) is a standard way in the Telecom, and probably countless others, sector. It is a pragmatic approach to the extreme, one where you don't care about reuse. You'll find this used in projects that are under enormous time pressures, which are all of them these days. This is exactly the area where the open source design method is superior, we are forced to do abstraction layers and good design because if the nature of the process. Most of the Qtopia Platform Trolls probably came from the telecom sector and are thus used to the cp/pst method.
Re: Rhys@Trolltech
No, you have to be PART of the community, not work WITH the community. That is the only possible way to interact with us and benefit from it. Never forget that.
It took you so long to find out that Qtopia is crap? I found that out years ago on my Zaurus SL5500. From a user POV I find it horrible. Qtopia was never updated for Zaurus, even though Troll had a pic of it on their website for years. Not that I find GPE any better... :-P
Qtopia Core (Qt/Embedded) is great, because Qtopia Core is nothing other than Qt. But it falls short when it comes to integration. Trolltech is a software company and knows next to nothing about hardware. They made the decision to leave hardware integration with the end user. For commercial embedded device manufacturers, this makes sense. But if you're an open source developer playing around with a board you bought online, it can be frustrating.
Qtopia was never updated for Zaurus, even though Troll had a pic of it on their website for years.
Huh?? You mean Sharp never updated their version of Qtopia. Trolltech released Qtopia 2 various roms for different Zaurus. They are even still available on qtopia.net. There are device profiles currently in Qtopia 4 for c3200.
To be fair to Trolltech, the copy paste method (lol) is a standard way in the Telecom, and probably countless others, sector.
Give me a f*^(ing break. What text editor does not have copy/paste abilities?
No, you have to be PART of the community, not work WITH the community.
Trolltech IS a part of the "community". You have to work with the "community" to be a part of it. and in case you haven't heard, Qtopia is released under the GPL, in it's entirety.
Trolltech is a software company and knows next to nothing about hardware.
I would not say that. I am sure they have some very competent engineers working on device integrations, often help the hardware guys out.
Look at the Openmoko Neo phone. I heard Trolltech had it up and running in one week making phone calls, sending sms! It still has heaps more functionality, and stability than the "default" software openmoko has been developing
Hi i am in need of Qtopia Professionals with 2-4yrs of exp in Qtopia for my client in Bangalore. I find it difficult to get the resumes from the market. Can u pls help me out
Regards
Sathish
sathish@qusolconsultancy.com
Post a Comment
<< Home