Qtopia questions

Lorn Potter lpotter at trolltech.com
Sat Jul 26 20:58:26 CEST 2008


Holger Freyther wrote:
> On Saturday 26 July 2008 07:47:14 Lorn Potter wrote:
> 
>> I have been told, a lot of them seem to be "I don't like the way you do
>> this, my way is better", or 'code clean-ups', or such that do not fix
>> any real bugs at all, or are specific to the Neo, and not taking into
>> consideration that many other (buggy) devices have to remain working.
> 
> Not quite true, some examples:
> 	- ThemedView changes and speed up's should apply to Qtopia

applied to 4.4 at least. If it didn't manage to get 4.3, I can look into 
it. Our attention is on 4.4


> 	- Various fixes to CallScreen (see our bugtracker).
> 		- If you showed the keypad, remote hang up, make a call...
havent seen this.

> 		- Display one call as "Hold", "Connected" and "Dialing" at the same time 
> 		  (Menu, Buttons, Display)
havent seen this one either

> 		- many more such things...
> 	.... many more. So from the ~360 patches about 5 of them make things harder 
> for other people.
> 
> My approach:
> 	- I do clean up the incosistent usage of 1, 3, 4 spaces mixed with tabs and 
> placing braces and #ifdef's randomly. If you write code like that you want to 
> hide something and the reason I have to touch this code is because there is 
> something hiding.

We don't take patches for 'code cleanups'. There's a reason for this. 
Customers get patches, and they don't like unnecessary lines of code 
being changed. It can make it difficult to see what the real changes are.

> 	- I create the most simple patch for the issue as possible. One patch one 
> issue. Obviously sometimes I don't understand the consequences of my change 
> as the whole code is so fragile.
> 	- I care little about BC, if I need to add a parameter to a method I do so, 
> the commit messages state so though.

well, we do. or try to. Especially in a .x release mode.

> 
> Example:
> 	- Plain Qtopia is starting timers to guess when a call was missed, when all 
> the data of an incoming call is present (combining RING, CRING and other 
> notifications). This creates all funny kind of bugs as this guessing is mixed 
> with %CPI. So Qtopia thinks the call was missed, but you get a %CPI and 
> suddenly we report a new call. And you see "Disconnected" and "Incoming" in 
> the callscreen.

The reason for this, is because some modems that we have to deal with do 
not work correctly without this. The calypso does not exhibit this 
behavior, but it needs to be left in.


> 
> 	- So I decided to solely rely on %CPI information for our code. One way would 
> have been to just remove the timers from the libraries and be happy. If I did 
> so you could have claimed that I don't think about other devices. So as I 
> care about the consequences for other devices where timers might be needed I 
> added methods to make starting of timers optional. So just because some 
> modems are worse than the TI Calypso you shouldn't punish modems that are 
> better.... 

So our customers buggy modems are just supposed to not work?


And again I fix this kind of things because it failed in reality..
> not because I have fun thinking about all the possible race conditions 
> available in the Qtopia source.
> 
> 	- I think the approach and implementation is reasonable. If you don't think 
> so open up and start discussing it.

we do internally. we can't discuss this publicly because it involves 
customers that do not want to be open/discussed or have their 
competitors know what they are doing/what hardware/software bugs they 
are seeing.

> 
> 
> 
>> We have implemented some of his patches. I personally have done a few of
>> them, some after having to patch the patch.
> 
> Please communicate... I get zero feedback on changes. The patch might have 
> been seen, the patch might have been integrated... the patch might have been 
> fixed differently is not the way to go if you want to interact with the 
> OpenSource and FreeSoftware community.

The themedview patch needed some ifdef taken out. I think there were others.

> 
> 
>> As well, we have been working on getting 4.4 ready to release. There are
>> quite a few changes in 4.4, and quite a few have to be manually
>> integrated and such.
> 
> well, release Qtopia4.4 beta's rsync. I can see the upcoming Qt 4.5 code today 
> as well, so what is keeping you from releasing Qtopia4.4 snapshot code today?

All I can say is that there is some discussion over this (always has 
been), and there is agreement down here over certain things.


You have to realize too, that Qtopia is not a finished end product. It 
is a starting point for our customers, and that is how they use it. They 
do not take the code, whip up a device config and ship it. They 
customize the heck out of it. The Philips devices that ran Qtopia 2 you 
would not even know it is Qtopia, except for little clues. There is a 
certain Qtopia 4 gps/phone that you would hardly know it's Qtopia/Linux 
as well.




-- 
Lorn 'ljp' Potter
Software Engineer, Systems Group, Trolltech, a Nokia company




More information about the community mailing list