On 22 Jul 2008, at 14:36, Carsten Haitzler (The Rasterman) wrote: >> ... >> Sorry to trouble you, but who are these designers, please? > > i'll let them speak up if they wish to be part of a debate on this. > it's up to > them.
I'd be grateful if someone @openmoko could be a bit transparent about this. > ... i have technical reasons why i think the > move to remove any such manual control is a bad thing and have made > them clear > often enough. This is why openness would be beneficial to the community. After all the efforts that Openmoko have made over being open, I am just amazed that design decisions that affect everyone are being made in secret. >> I think many of us would like to contribute to the ASU, seeing as >> how it's the future of Openmoko, so this would appear to be a >> limitation upon community contributions. > > as such we are paid by openmoko to do what we are told to do by > the design > department and that is what we then do. you in the community can go > and do your > own themes and patches and packages and do what u want. Openmoko promotes itself as an "open" company soliciting contributions from community developers. That's great! But if that means I can only develop apps that run ON the phone - or if I want to code for core apps then I need to fork - it would be great if they could say so. Sorry to use the alarmist word "fork" here, I don't mean it that way. But right now it appears difficult to contribute changes to the ASU window manager (if I'm understanding correctly that that is the component which is missing a manual keyboard toggle button). It is pointless me doing so if I have to maintain this patch all on my own and no-one else is going to benefit. If I want to add a manual keyboard toggle button then that's exactly the scenario - if other people want to use it I effectively have to "fork" the code, maintaining a whole package or firmware image, simply so people can download it from my website. >> Where are the design documents which say "no keyboard toggle button >> should be included", please? If one wishes to contribute code or >> patches to ASU then I guess it's necessary to know this, or one will >> find patches rejected because they don't meet this design >> specification? > > well design documents are pretty thin on the ground. i was told so in > email/irc directly to do this. i had a manual button there > originally and was > explicitly told to remove it. Right. So right now there's no point in members of the community trying to contribute patches to core features or functionality, lest these patches get declined because the designers don't happen to like them. Even worse is the prospect of you saying "great! this is really useful, I'll add it to git" and then the community member feeling disappointed (pissed off) later when you're told to remove it. IMO it's crazy for you (the senior developer to ASU? you're surely the most active?) to have his hands tied by these shadowy "designers" who can interfere apparently on a whim. Especially when they're coming up with crazy decisions that are technically poor!! On 21 Jul 2008, at 19:47, Carsten Haitzler (The Rasterman) wrote: >>> ... >>> the problem is the designers decided that ASU is not to have any >>> manual keyboard toggle button because it will disturb the design >>> and/or confuse users, so all apps and toolkits need modification >>> to talk a "protocol" to bring up the keyboard on demand (no >>> manual controls). that is why you need to do this. They asked you to take out a simple button, in favour of a whole protocol, when no protocol currently exists? Aside from the points you make about porting existing (Gnome, KDE, whatever) applications to ASU, what's the hard in keeping the button until this protocol is later developed? Please would the "designers" speak up so we can flame them directly. Presently I think you're misnaming these individuals (this individual?). A design document is required for a design, so that everyone can see the rationale for decisions. Everything that's implemented should have a reason (stated in the design document), and that a button might "disturb the design and/or confuse users" is not a rational reason for having broken apps which can't use a bloomin' keyboard. Making ad-hoc demands for change after the fact is not "designing" it is *meddling*. Stroller. _______________________________________________ Openmoko community mailing list email@example.com http://lists.openmoko.org/mailman/listinfo/community