Terminal for ASU

[Stroller]

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.