Qtopia questions

Holger Freyther zecke at openmoko.org
Sat Jul 26 17:14:44 CEST 2008

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
	- Various fixes to CallScreen (see our bugtracker).
		- If you showed the keypad, remote hang up, make a call...
		- Display one call as "Hold", "Connected" and "Dialing" at the same time 
		  (Menu, Buttons, Display)
		- 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.
	- 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.

	- 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.

	- 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.... 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 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.

> 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?


More information about the community mailing list