Terminal for ASU

[steve]

Ask your questions stroller.

I'll  do my best to answer them.




 

-----Original Message-----
From: Carsten Haitzler (The Rasterman) [mailto:raster at openmoko.org] 
Sent: Wednesday, July 23, 2008 6:16 AM
To: List for Openmoko community discussion
Cc: Stroller; steve
Subject: Re: Terminal for ASU

On Wed, 23 Jul 2008 04:32:34 +0100 Stroller <stroller at stellar.eclipse.co.uk>
babbled:

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

it was in fact said that "the community can create their own packages" - so
as such you are expected to fork - create modified packages with different
config.
as such only maybe 1% of the config e/illume has is actually accessible (in
a
gui) in a sane usable way. can't change wallpaper, can't choose a new theme,
can't modify sizes of things, cache sizes, framerates.... this is a design
decision, and thus forces you to fork.

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

correct. if you have problems with this - i am not the guy to talk to as it
has been made clear that i am just a programmer here.

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

welcome to openmoko. i get paid to program. i am not a designer (as i have
been
told) and thus am not qualified to make decisions there (so i have been
informed). i am paid to program. so that is what i will do.

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

i'm keeping out of it. if design wishes to be part of the community, they
can.
if not - they can stay silent. up to them.

--
Carsten Haitzler (The Rasterman) <raster at openmoko.org>