Terminal for ASU

[Scott Petersen]

Is it just my inability to find things or is there truly no terminal 
application for ASU in the standard repositories?

Does anybody have any recommendations for a terminal for ASU? I tried to 
get openmoko-terminal2 to run but it crashes every time.

Cheer
Scott Petersen

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Terminal for ASU

[C R McClenaghan]

I think I tried "vte" from the repos and it worked. I couldn't get the  
built in keyboard to come up so I abandoned ASU for the time being.  
Since I didn't have a keyboard, by worked I mean I could start it.

Chris

On Jul 20, 2008, at 7:15 PM, Scott Petersen wrote:

> Is it just my inability to find things or is there truly no terminal
> application for ASU in the standard repositories?
>
> Does anybody have any recommendations for a terminal for ASU? I  
> tried to
> get openmoko-terminal2 to run but it crashes every time.
>
> Cheer
> Scott Petersen
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Terminal for ASU

[Ken Restivo]

On Sun, Jul 20, 2008 at 07:56:58PM -0700, C R McClenaghan wrote:
> I think I tried "vte" from the repos and it worked. I couldn't get the  
> built in keyboard to come up so I abandoned ASU for the time being.  
> Since I didn't have a keyboard, by worked I mean I could start it.
> 
> Chris
> 
> On Jul 20, 2008, at 7:15 PM, Scott Petersen wrote:
> 
> > Is it just my inability to find things or is there truly no terminal
> > application for ASU in the standard repositories?
> >
> > Does anybody have any recommendations for a terminal for ASU? I  
> > tried to
> > get openmoko-terminal2 to run but it crashes every time.
> >


Crap.

I was considering opening a bug report (enhancement, probably) on this-- the 
ASU needs a terminal.

But I don't want to get smacked down with a "ASU will never have a terminal, 
it's not a supported use case" closure for it.

*Will* the ASU have a terminal app that works with the Qtopia environment? Or 
is that something I shouldn't expect to work?

-ken

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Terminal for ASU

[Brian C]

Ken Restivo wrote:
> Crap.
> 
> I was considering opening a bug report (enhancement, probably) on this-- the 
> ASU needs a terminal.
> 
> But I don't want to get smacked down with a "ASU will never have a terminal, 
> it's not a supported use case" closure for it.
> 
> *Will* the ASU have a terminal app that works with the Qtopia environment? Or 
> is that something I shouldn't expect to work?
> 
> -ken

1. It's an open platform, so it's inevitable that it will have a terminal.

2. If it were not possible to have a terminal on ASU, then OpenMoko
should just abandon ASU immediately.

Therefore, you should feel free to open the bug.

Brian

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Terminal for ASU

[Ken Restivo]

On Sun, Jul 20, 2008 at 08:20:46PM -0700, Brian C wrote:
> Ken Restivo wrote:
> > Crap.
> > 
> > I was considering opening a bug report (enhancement, probably) on this-- 
> > the ASU needs a terminal.
> > 
> > But I don't want to get smacked down with a "ASU will never have a 
> > terminal, it's not a supported use case" closure for it.
> > 
> > *Will* the ASU have a terminal app that works with the Qtopia environment? 
> > Or is that something I shouldn't expect to work?
> > 
> > -ken
> 
> 1. It's an open platform, so it's inevitable that it will have a terminal.
> 
> 2. If it were not possible to have a terminal on ASU, then OpenMoko
> should just abandon ASU immediately.
> 
> Therefore, you should feel free to open the bug.
> 

I'll wait to see if anyone responds with "Sure, it has one, or you can use any 
terminal with it, here's how you get it to work, get it into the 
menu/icon/illume thing, make it use the keyboard, blah blah blah".

If I can avoid annoying the devs with unnecessary bug reports, I will.

Hey, I noticed that someone just added a Full-QWERTY configuration to the ASU 
keyboard, and a little icon for choosing which keyboard layout to use on the 
fly. Bravo!! Very glad to see that.

-ken

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Terminal for ASU

[Sascha Peilicke]

> *Will* the ASU have a terminal app that works with the Qtopia environment?
> Or is that something I shouldn't expect to work?

Take a look at qtopia.net, several applications for Qtopia are listed there 
(terminal and file manager for example). Don't know if they work on ASU right 
away because they where written for Qtopia. Hope it helps:

http://www.qtopia.net/modules/mydownloads/viewcat.php?cid=2

-- 
Sascha Peilicke
http://saschashideout.de

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Terminal for ASU

[Sven Klomp]

On Monday 21 July 2008 05:30:09 Ken Restivo wrote:
> On Sun, Jul 20, 2008 at 08:20:46PM -0700, Brian C wrote:
> > Ken Restivo wrote:
> > 1. It's an open platform, so it's inevitable that it will have a
> > terminal.
> >
> > 2. If it were not possible to have a terminal on ASU, then OpenMoko
> > should just abandon ASU immediately.
> >
> > Therefore, you should feel free to open the bug.
>
> I'll wait to see if anyone responds with "Sure, it has one, or you can use
> any terminal with it, here's how you get it to work, get it into the
> menu/icon/illume thing, make it use the keyboard, blah blah blah".

Hm, I'm using the openmoko-terminal2 without problems on ASU. The tricky part 
was to use the Illume keyboard with GTK applications. At freeyourphone.de was 
a hint that you have to install ONLY  matchbox-keyboard-im (see 
http://wiki.openmoko.org/wiki/Complete_QWERTY_Keyboard_On_The_Freerunner) and 
GTK applications will start Illume keyboard. I know, it is strange. However 
it worked :-)

Sven

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Terminal for ASU

[The Rasterman]

On Mon, 21 Jul 2008 11:18:50 +0200 Sven Klomp <[EMAIL PROTECTED]> babbled:

> On Monday 21 July 2008 05:30:09 Ken Restivo wrote:
> > On Sun, Jul 20, 2008 at 08:20:46PM -0700, Brian C wrote:
> > > Ken Restivo wrote:
> > > 1. It's an open platform, so it's inevitable that it will have a
> > > terminal.
> > >
> > > 2. If it were not possible to have a terminal on ASU, then OpenMoko
> > > should just abandon ASU immediately.
> > >
> > > Therefore, you should feel free to open the bug.
> >
> > I'll wait to see if anyone responds with "Sure, it has one, or you can use
> > any terminal with it, here's how you get it to work, get it into the
> > menu/icon/illume thing, make it use the keyboard, blah blah blah".
> 
> Hm, I'm using the openmoko-terminal2 without problems on ASU. The tricky part 
> was to use the Illume keyboard with GTK applications. At freeyourphone.de was 
> a hint that you have to install ONLY  matchbox-keyboard-im (see 
> http://wiki.openmoko.org/wiki/Complete_QWERTY_Keyboard_On_The_Freerunner) and 
> GTK applications will start Illume keyboard. I know, it is strange. However 
> it worked :-)

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.
personally i think you need a manual control because, as such, many apps and
toolkits will not be changed, or they will get it wrong and give you a keyboard
when you don't want one, or decide not to give you one when you do... but
that's not my call.

but you will ned the matchbox- or multitap im module to send these messages.
qtopia-x11 has been patched todo this too. the illume keyboard also understands
a newer and much more reliable method of auto-requesting a virtual keyboard
(properties on your window), and i think holger has added support in qtopia-x11
for that now, but it also understands the older MB and multi-tap protocol... if
people want other protocols supported...let me know the details.

-- 
Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]>

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Terminal for ASU

[Al Johnson]

On Monday 21 July 2008, Carsten Haitzler 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. personally i think you need a manual control because, as such,
> many apps and toolkits will not be changed, or they will get it wrong and
> give you a keyboard when you don't want one, or decide not to give you one
> when you do... but that's not my call.

The designers' idea is great, but in practise I suspect you're right. Please 
can we at least have a manual override as a configure option, even if it's 
not on by default? 


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Terminal for ASU

[The Rasterman]

On Mon, 21 Jul 2008 22:32:47 +0100 Al Johnson <[EMAIL PROTECTED]>
babbled:

> On Monday 21 July 2008, Carsten Haitzler 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. personally i think you need a manual control because, as such,
> > many apps and toolkits will not be changed, or they will get it wrong and
> > give you a keyboard when you don't want one, or decide not to give you one
> > when you do... but that's not my call.
> 
> The designers' idea is great, but in practise I suspect you're right. Please 
> can we at least have a manual override as a configure option, even if it's 
> not on by default? 

sorry. "not in the design". it's not specified as a config option. i'm only
doing what's in the spec as there is much unhappiness if i do otherwise. if you
REALLY want the button you will have to hack the theme to put it back in (as its
just a theme element that emits a signal when pressed).

yes automatic keyboard popup is good, but we don't live in a world where we can
guarantee and force every app to behave perfectly. lots of things are
"ported" (recompiled) and forcing them to add patches to bring up keyboards is
just yet another barrier to porting and leaves us with less software :(

even though automatic cars are ... automatic - they STILL have manual gears you
can use - auto doesn't always get it right! :) 100% auto should only be
considered once there is nothing left alive that ever could need a manual
override. we are very far from that reality :(

(as such the protocol used by matchbox keyboard/multi-tap is very error prone
as anyone can send a message and the keyboard can be left in all sorts of
erroneous states. the property-based one i implemented is reliable as the
keyboard state desire is a property of the windows - thus the focused window's
keyboard property determines if keyboard should be there or not, but this so
far is a private protocol implemented by e. it is not documented, nor has it
been standardised. all of this should go to freedesktop.org and be proposed as
wm-spec extensions for "mobile devices" and then adopted, specified, and
implemented everywhere, tested well, then.. when all this is done.. the manual
button may have a chance of being removed...)

-- 
Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]>

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Terminal for ASU

[Al Johnson]

On Monday 21 July 2008, Carsten Haitzler wrote:
> On Mon, 21 Jul 2008 22:32:47 +0100 Al Johnson
> <[EMAIL PROTECTED]>
>
> babbled:
> > On Monday 21 July 2008, Carsten Haitzler 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. personally i think you need a manual
> > > control because, as such, many apps and toolkits will not be changed,
> > > or they will get it wrong and give you a keyboard when you don't want
> > > one, or decide not to give you one when you do... but that's not my
> > > call.
> >
> > The designers' idea is great, but in practise I suspect you're right.
> > Please can we at least have a manual override as a configure option, even
> > if it's not on by default?
>
> sorry. "not in the design". it's not specified as a config option. i'm only
> doing what's in the spec as there is much unhappiness if i do otherwise. if
> you REALLY want the button you will have to hack the theme to put it back
> in (as its just a theme element that emits a signal when pressed).

GRR...defective by design. You've made a fair summary of my feelings on 
automated keyboards too. So what does the spec say about when there's another 
input device like a bluetooth or USB keyboard?

> yes automatic keyboard popup is good, but we don't live in a world where we
> can guarantee and force every app to behave perfectly. lots of things are
> "ported" (recompiled) and forcing them to add patches to bring up keyboards
> is just yet another barrier to porting and leaves us with less software :(
>
> even though automatic cars are ... automatic - they STILL have manual gears
> you can use - auto doesn't always get it right! :) 100% auto should only be
> considered once there is nothing left alive that ever could need a manual
> override. we are very far from that reality :(
>
> (as such the protocol used by matchbox keyboard/multi-tap is very error
> prone as anyone can send a message and the keyboard can be left in all
> sorts of erroneous states. the property-based one i implemented is reliable
> as the keyboard state desire is a property of the windows - thus the
> focused window's keyboard property determines if keyboard should be there
> or not, but this so far is a private protocol implemented by e. it is not
> documented, nor has it been standardised. all of this should go to
> freedesktop.org and be proposed as wm-spec extensions for "mobile devices"
> and then adopted, specified, and implemented everywhere, tested well,
> then.. when all this is done.. the manual button may have a chance of being
> removed...)



___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Terminal for ASU

[Stroller]

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.
> personally i think you need a manual control because, as such, many  
> apps and
> toolkits will not be changed, or they will get it wrong and give  
> you a keyboard
> when you don't want one, or decide not to give you one when you  
> do... but
> that's not my call.

Hi Carsten,

Sorry to trouble you, but who are these designers, please?

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.

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?

Stroller.


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Terminal for ASU

[JW]

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

surely this is a prime candidate for a motion detection / gesture detection
to bring up the keyboard

easy - no extra button needed

geeks who enable their gesture of choice get the keyboard when they want it

carsten can you build in the sleeping gesture as you go?

jw
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Terminal for ASU

[Cédric Berger]

Indeed I fail to see the advantage of having no manual triggering of keyboard.
On my desktop PC, I have never dreamt of my keyboard popping out of a
drawer when it thinks I should need it...

And this morning, after my daily opkg upgrade... I rebooted ASU and I
am stuck, not even able to enter my SIM PIN !!
Because... there was no keyboard on the screen !





On Tue, Jul 22, 2008 at 00:21, Al Johnson <[EMAIL PROTECTED]> wrote:
>> On Monday 21 July 2008, Carsten Haitzler wrote:
>> sorry. "not in the design". it's not specified as a config option. i'm only
>> doing what's in the spec as there is much unhappiness if i do otherwise. if
>> you REALLY want the button you will have to hack the theme to put it back
>> in (as its just a theme element that emits a signal when pressed).
>
> GRR...defective by design. You've made a fair summary of my feelings on
> automated keyboards too. So what does the spec say about when there's another
> input device like a bluetooth or USB keyboard?
>
>> yes automatic keyboard popup is good, but we don't live in a world where we
>> can guarantee and force every app to behave perfectly. lots of things are
>> "ported" (recompiled) and forcing them to add patches to bring up keyboards
>> is just yet another barrier to porting and leaves us with less software :(

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Terminal for ASU

[The Rasterman]

On Mon, 21 Jul 2008 23:21:22 +0100 Al Johnson <[EMAIL PROTECTED]>
babbled:

> On Monday 21 July 2008, Carsten Haitzler wrote:
> > On Mon, 21 Jul 2008 22:32:47 +0100 Al Johnson
> > <[EMAIL PROTECTED]>
> >
> > babbled:
> > > On Monday 21 July 2008, Carsten Haitzler 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. personally i think you need a manual
> > > > control because, as such, many apps and toolkits will not be changed,
> > > > or they will get it wrong and give you a keyboard when you don't want
> > > > one, or decide not to give you one when you do... but that's not my
> > > > call.
> > >
> > > The designers' idea is great, but in practise I suspect you're right.
> > > Please can we at least have a manual override as a configure option, even
> > > if it's not on by default?
> >
> > sorry. "not in the design". it's not specified as a config option. i'm only
> > doing what's in the spec as there is much unhappiness if i do otherwise. if
> > you REALLY want the button you will have to hack the theme to put it back
> > in (as its just a theme element that emits a signal when pressed).
> 
> GRR...defective by design. You've made a fair summary of my feelings on 
> automated keyboards too. So what does the spec say about when there's another 
> input device like a bluetooth or USB keyboard?

it says nothing... not specified as a design parameter. :) (another good reason
for a manual overried until auto-detection of a bt/usb keyboard is flawless.
even with a bt keyboard - it may be on, in your pocket or bag, but you may not
want to use it.. thus want a manual "give me a virtual keyboard anyway - bt
keyboard there or not". :)

i'm with you on this and i understand why an automatic keyboard is goo d(no
need to always manually bring it up when you'd want it anyway), but manual
control is going to be needed for a long time to come as it may never always
automatically do it right for you... :)

> > yes automatic keyboard popup is good, but we don't live in a world where we
> > can guarantee and force every app to behave perfectly. lots of things are
> > "ported" (recompiled) and forcing them to add patches to bring up keyboards
> > is just yet another barrier to porting and leaves us with less software :(
> >
> > even though automatic cars are ... automatic - they STILL have manual gears
> > you can use - auto doesn't always get it right! :) 100% auto should only be
> > considered once there is nothing left alive that ever could need a manual
> > override. we are very far from that reality :(
> >
> > (as such the protocol used by matchbox keyboard/multi-tap is very error
> > prone as anyone can send a message and the keyboard can be left in all
> > sorts of erroneous states. the property-based one i implemented is reliable
> > as the keyboard state desire is a property of the windows - thus the
> > focused window's keyboard property determines if keyboard should be there
> > or not, but this so far is a private protocol implemented by e. it is not
> > documented, nor has it been standardised. all of this should go to
> > freedesktop.org and be proposed as wm-spec extensions for "mobile devices"
> > and then adopted, specified, and implemented everywhere, tested well,
> > then.. when all this is done.. the manual button may have a chance of being
> > removed...)
> 
> 
> 
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community


-- 
Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]>

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Terminal for ASU

[The Rasterman]

On Tue, 22 Jul 2008 02:39:01 +0100 JW <[EMAIL PROTECTED]> babbled:

> >
> >
> > 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?
> >
> 
> surely this is a prime candidate for a motion detection / gesture detection
> to bring up the keyboard
> 
> easy - no extra button needed
> 
> geeks who enable their gesture of choice get the keyboard when they want it
> 
> carsten can you build in the sleeping gesture as you go?

what gesture, where? how? how ill this be able to not conflict with operation
of other apps? i am not so hot on gestures - especially ones that use up the
"whole screen" or parts o the screen where apps run - as now gestures fight for
usability with apps themselves. there is no coordination. example:

if the gesture was "slide up the screen from bottom to top" - how is this
gesture different from me dragging my finger to scroll a list in the application
on my screen? how do i make sure only ONE of these happens (the keyboard pops up
OR the scroll happens) and not both?

IMHO - gestures are black magic box filled with cans of worms. i'd rather avoid
them unless you can guarantee the flow of the user action and
where it will go. it's not so simple.

either way - there WAS a button.. it was in the top-left corner of the screen
that was blank and unused anyway. it used up no extra screen space and was
obvious to hit. it was by far the best option available so far. if you hack the
illum theme (edje_decc illme.edj to decompile - edit the .edc and run build.sh
to rebuild... copy it back in place). you can add the button back - if you can
find it.

-- 
Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]>

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Terminal for ASU

[The Rasterman]

On Tue, 22 Jul 2008 02:05:48 +0100 Stroller <[EMAIL PROTECTED]>
babbled:

> 
> 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.
> > personally i think you need a manual control because, as such, many  
> > apps and
> > toolkits will not be changed, or they will get it wrong and give  
> > you a keyboard
> > when you don't want one, or decide not to give you one when you  
> > do... but
> > that's not my call.
> 
> Hi Carsten,
> 
> 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 am not one way or another here. not going to defend or dob-in. i have
no vested interests one way or another. 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. i am not going to get into it again. i am staying neutral - i
have my professional opinions and personal ones, but my job is to implement
what is designed by others to the best of my ability - if something is
technically not possible or utterly infeasible - i can't do it, but removing a
manual keyboard button is perfectly easy to do, and so it gets done.

if i hadn't made it clear.. i am being neutral on this - i am simply stating
the facts as they are. i am not wanting to beat anyone one over this. i am
just  stating facts. emotions and opinions thereafter are entirely those of
people as they wish to express them - they were not intended or written here.
just sticking to facts.

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

> 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. i argued that this was a bad move for many
technical reasons (porting of apps such as SDL games that don't use gtk or qt
that now all need modifications, i listed the apps it will break, the reasoning
of not always wanting a virtual keyboard (ie an entry box may be focused, but
you just want to READ the content, not edit) etc. etc.) but it was made
entirely clear that the button had to go - arguments or not. as i remember the
reasons being that "it cluttered the interface", was "confusing", "unnecessary"
and that "all applications can be modified to talk the protocol anyway". or
something to that effect. this was a while ago so i'm a little hazy on the
reasons - but it was something like that.

again - i'm neutral. i'm just a programmer. i just implement code.

-- 
Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]>

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Terminal for ASU

[Kalle Happonen]

Carsten Haitzler (The Rasterman) wrote:
> On Tue, 22 Jul 2008 02:39:01 +0100 JW <[EMAIL PROTECTED]> babbled:
>
>   
>>> 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?
>>>
>>>   
>> surely this is a prime candidate for a motion detection / gesture detection
>> to bring up the keyboard
>>
>> easy - no extra button needed
>>
>> geeks who enable their gesture of choice get the keyboard when they want it
>>
>> carsten can you build in the sleeping gesture as you go?
>> 
>
> what gesture, where? how? how ill this be able to not conflict with operation
> of other apps? i am not so hot on gestures - especially ones that use up the
> "whole screen" or parts o the screen where apps run - as now gestures fight 
> for
> usability with apps themselves. there is no coordination. example:
>
> if the gesture was "slide up the screen from bottom to top" - how is this
> gesture different from me dragging my finger to scroll a list in the 
> application
> on my screen? how do i make sure only ONE of these happens (the keyboard pops 
> up
> OR the scroll happens) and not both?
>   
I'm not sure, but I think he meant gesture as in accelerometer. Double 
tap the phone for instance, or tap it on the bottom and it slides up, 
and tap it on the top and it slides down... or...

Kalle

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Terminal for ASU

[Ken Restivo]

On Tue, Jul 22, 2008 at 09:01:24AM +0200, =?ISO-8859-1?Q?C=E9dric_Berger_ wrote:
> Indeed I fail to see the advantage of having no manual triggering of keyboard.
> On my desktop PC, I have never dreamt of my keyboard popping out of a
> drawer when it thinks I should need it...
> 
> And this morning, after my daily opkg upgrade... I rebooted ASU and I
> am stuck, not even able to enter my SIM PIN !!
> Because... there was no keyboard on the screen !
> 
> 

I experienced this today too. It rendered my FR useless. Everything I'd finally 
gotten working yesterday (VTE, Minimo, tasks app) stopped working today, and 
I'm stuck with, essentially, a brick.

The keyboard doesn't even pop up automatically anymore, and there's no way to 
add it.

Can someone document what hacks are available to bring the Illume keyboard 
back, and to manually trigger it with that little "qwerty" button that used to 
be there, in case the designers decide they don't want users to be able to type 
things in anymore?

Thanks.

-ken

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Terminal for ASU

[Ken Restivo]

On Tue, Jul 22, 2008 at 11:36:27PM +1000, Carsten Haitzler wrote:
> On Tue, 22 Jul 2008 02:05:48 +0100 Stroller <[EMAIL PROTECTED]>
> babbled:
> 
> > 
> > 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.
> > > personally i think you need a manual control because, as such, many  
> > > apps and
> > > toolkits will not be changed, or they will get it wrong and give  
> > > you a keyboard
> > > when you don't want one, or decide not to give you one when you  
> > > do... but
> > > that's not my call.
> > 
> > Hi Carsten,
> > 
> > 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 am not one way or another here. not going to defend or dob-in. i have
> no vested interests one way or another. 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. i am not going to get into it again. i am staying neutral - i
> have my professional opinions and personal ones, but my job is to implement
> what is designed by others to the best of my ability - if something is
> technically not possible or utterly infeasible - i can't do it, but removing a
> manual keyboard button is perfectly easy to do, and so it gets done.
> 
> if i hadn't made it clear.. i am being neutral on this - i am simply stating
> the facts as they are. i am not wanting to beat anyone one over this. i am
> just  stating facts. emotions and opinions thereafter are entirely those of
> people as they wish to express them - they were not intended or written here.
> just sticking to facts.
> 
> > 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.
> 
> > 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. i argued that this was a bad move for many

Please tell me who told you to do this so I can flame him :-) He ruined my 
whole afternoon.

> technical reasons (porting of apps such as SDL games that don't use gtk or qt
> that now all need modifications, i listed the apps it will break, the 
> reasoning
> of not always wanting a virtual keyboard (ie an entry box may be focused, but
> you just want to READ the content, not edit) etc. etc.) but it was made
> entirely clear that the button had to go - arguments or not. as i remember the
> reasons being that "it cluttered the interface", was "confusing", 
> "unnecessary"
> and that "all applications can be modified to talk the protocol anyway". or
> something to that effect. this was a while ago so i'm a little hazy on the
> reasons - but it was something like that.
> 
> again - i'm neutral. i'm just a programmer. i just implement code.
> 


Smart move.

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

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



___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Terminal for ASU

[Jacob Peterson]

Ken, I too feel your pain.  I had just stated to get things setup, then I
decided to update and to my surprise, all applications requiring a keyboard
are now useless.  I ended up reverting back to the July 21st snapshot for
now, but I will try editing the illume theme and rebuilding once I can
locate the required tools to edit the themes.

Having a manual keyboard button is an important feature.  The automatic
keyboard is not going to read my mind and know if I want it visible or not.
There may be times that I want the extra screen space to look at something
without half the screen taken up as the automatic keyboard suggests or maybe
the automatic keyboard isn't 100% bug free with 100% of applications
properly implementing support for it.  In a perfect world, a system without
a manual button might be feasible.  However this is far from a perfect world
and with an open system like this it is unrealistic to expect 100% of all
applications that can/will be used, to work perfectly with the automatic
keyboard.  Hopefully the order to remove the button will be reversed, as it
is sorely missed.

-Jacob

On Tue, Jul 22, 2008 at 8:39 PM, Ken Restivo <[EMAIL PROTECTED]> wrote:

> On Tue, Jul 22, 2008 at 09:01:24AM +0200, =?ISO-8859-1?Q?C=E9dric_Berger_
> wrote:
> > Indeed I fail to see the advantage of having no manual triggering of
> keyboard.
> > On my desktop PC, I have never dreamt of my keyboard popping out of a
> > drawer when it thinks I should need it...
> >
> > And this morning, after my daily opkg upgrade... I rebooted ASU and I
> > am stuck, not even able to enter my SIM PIN !!
> > Because... there was no keyboard on the screen !
> >
> >
>
> I experienced this today too. It rendered my FR useless. Everything I'd
> finally gotten working yesterday (VTE, Minimo, tasks app) stopped working
> today, and I'm stuck with, essentially, a brick.
>
> The keyboard doesn't even pop up automatically anymore, and there's no way
> to add it.
>
> Can someone document what hacks are available to bring the Illume keyboard
> back, and to manually trigger it with that little "qwerty" button that used
> to be there, in case the designers decide they don't want users to be able
> to type things in anymore?
>
> Thanks.
>
> -ken
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Terminal for ASU

[Holger Freyther]

On Wednesday 23 July 2008 03:39:54 Ken Restivo wrote:

> Can someone document what hacks are available to bring the Illume keyboard
> back, and to manually trigger it with that little "qwerty" button that used
> to be there, in case the designers decide they don't want users to be able
> to type things in anymore?

Asking for "hacks" is almost certainly the wrong thing to do. So keyboard 
stopped working in your org.openmoko.asu.stable build? Well, then let us 
track down the regressions in e and illume.

no hacks needed.
z.

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Terminal for ASU

[Holger Freyther]

On Wednesday 23 July 2008 05:32:34 Stroller wrote:

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

Check the openmoko-devel/disto-devel archives from back then. Sure the 
decision was made "in private" as someone walked into raster's office and 
discussed this in person. The mailing list thread on the issue and the 
request for me to change Qtopia to send the matchbox hints were done in 
public.

I know that not everyone wants to read the development mailinglists and that 
it is quite hard to keep track with every OM mailinglist (I don't) but on the 
other hand just because I'm unaware of certain threads doesn't make 
things "private".


regards

z.

PS: If you can't find the discussion from back then I can give you a hand to 
search the archives.

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Terminal for ASU

[Holger Freyther]

On Wednesday 23 July 2008 05:56:41 Jacob Peterson wrote:
> Ken, I too feel your pain.  I had just stated to get things setup, then I
> decided to update and to my surprise, all applications requiring a keyboard
> are now useless.  I ended up reverting back to the July 21st snapshot for
> now, but I will try editing the illume theme and rebuilding once I can
> locate the required tools to edit the themes.

The theme files are "edje" files. There is edje_cc to compile them from edc 
files and there is edje_decc to decompile them (can be compiled with edje_cc 
again).

So get a illume.edj where raster forgot to remove the "QWERTY" button, get the 
next rev (fixing up that "oversight"), decompile both edj files, see the 
difference, patch in the keyboard button.

Ask someone in the community to provide illume-theme packages which are 
up-to-date but have the qwertz button present?

I hope this hint helps
z.

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Terminal for ASU

[Jacob Peterson]

On Tue, Jul 22, 2008 at 11:30 PM, Holger Freyther <[EMAIL PROTECTED]>
wrote:

> On Wednesday 23 July 2008 05:56:41 Jacob Peterson wrote:
> > Ken, I too feel your pain.  I had just stated to get things setup, then I
> > decided to update and to my surprise, all applications requiring a
> keyboard
> > are now useless.  I ended up reverting back to the July 21st snapshot for
> > now, but I will try editing the illume theme and rebuilding once I can
> > locate the required tools to edit the themes.
>
> The theme files are "edje" files. There is edje_cc to compile them from edc
> files and there is edje_decc to decompile them (can be compiled with
> edje_cc
> again).
>
> So get a illume.edj where raster forgot to remove the "QWERTY" button, get
> the
> next rev (fixing up that "oversight"), decompile both edj files, see the
> difference, patch in the keyboard button.
>
> Ask someone in the community to provide illume-theme packages which are
> up-to-date but have the qwertz button present?
>
> I hope this hint helps
>z.
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>


I was able to easily reverse the theme changes and restore the "QWERTY"
button (thanks Zecke and Raster =) ).  However the keyboard seems to be in a
non-functional state from what I can tell.  It stopped automatically coming
up after the update which removed the manual "QWERTY" button and my patched
theme is unable to coax it into existence either.  I will try to track down
what I can tomorrow and file a bug report if necessary.

-Jacob
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Terminal for ASU

[The Rasterman]

On Wed, 23 Jul 2008 06:20:29 +0200 Holger Freyther <[EMAIL PROTECTED]> babbled:

> On Wednesday 23 July 2008 03:39:54 Ken Restivo wrote:
> 
> > Can someone document what hacks are available to bring the Illume keyboard
> > back, and to manually trigger it with that little "qwerty" button that used
> > to be there, in case the designers decide they don't want users to be able
> > to type things in anymore?
> 
> Asking for "hacks" is almost certainly the wrong thing to do. So keyboard 
> stopped working in your org.openmoko.asu.stable build? Well, then let us 
> track down the regressions in e and illume.

right now - the keyboard (internal one) may or may not be enabled depending what
svn rev u get. i have not been updating the svnrev in asu.dev because i KNOW
what revs have it enabled or not. i need to make this a config option - i know,
but right now it's a 1 function call to create the internal kbd.

for me - the kbd works reliably with the internal keyboard. i have a test app
that can request the keyboard "automatically" (and i can have it request
different kinds of kbds) or request no kbd - at least on my desktop it works
100% of the time beautifully. i have run it on my freerunner too - and it works.

so you'll have to wait for dust to settle here.

-- 
Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]>

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Terminal for ASU

[The Rasterman]

On Tue, 22 Jul 2008 16:08:55 +0200 Kalle Happonen <[EMAIL PROTECTED]>
babbled:

> > what gesture, where? how? how ill this be able to not conflict with
> > operation of other apps? i am not so hot on gestures - especially ones that
> > use up the "whole screen" or parts o the screen where apps run - as now
> > gestures fight for usability with apps themselves. there is no
> > coordination. example:
> >
> > if the gesture was "slide up the screen from bottom to top" - how is this
> > gesture different from me dragging my finger to scroll a list in the
> > application on my screen? how do i make sure only ONE of these happens (the
> > keyboard pops up OR the scroll happens) and not both?
> >   
> I'm not sure, but I think he meant gesture as in accelerometer. Double 
> tap the phone for instance, or tap it on the bottom and it slides up, 
> and tap it on the top and it slides down... or...

hmm accelerometer - not going there right now. i have never played with them,
but - i do see there being a good use of them for something like this. twitch
phone up for displaying keyboard, twitch down for hiding. but until i have got
accelerometers firmly in hand - i'm sticking to the screen and buttons as
input. not saying "no" - just saying "not there yet".

need to consider if i should be listening to them in E as another kind of input
device and generate internal events, or if there should be a daemon messaging
commands or emitting keystrokes based on gestures. lots of things to solve
there before using accelerometers for this

-- 
Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]>

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Terminal for ASU

[The Rasterman]

On Wed, 23 Jul 2008 04:32:34 +0100 Stroller <[EMAIL PROTECTED]>
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: Terminal for ASU

[Ken Restivo]

On Wed, Jul 23, 2008 at 11:16:22PM +1000, Carsten Haitzler wrote:
> 
> > 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.
>

If you've been mismanaged/micromanaged so badly that you've had to adopt what 
Neitzche called the "Sklavmoral"-- or  "I'm not paid to think, I'm only paid to 
wash the floors"-- attitude in order to survive, it doesn't bode well for 
OpenMoko.

In any case, you're doing great work, so "illigitimum non carborundum".  I 
can't tell you how delighted I was when I saw the "qwerty" button suddenly 
appear after doing an opkg upgrade! And the ability to choose different 
keyboard layouts from a pop-up menu was great. I thought to myself, "now THIS 
is a well-managed project, critical features that I need are being added 
without even asking for them, and the progress is daily!". And now of course it 
is gone.

Can someone please document what hack is necessary to add that button back in? 
And, yes, if anyone wants to please fork the necessary package, I will 
subscribe to that feed instead, because the ability to use an on-screen 
keyboard on a Linux phone is a must-have for me. The Illume keyboard with 
Full-QWERTY is excellent and I love it. I need to be able to launch it manually 
in order to use it with Minimo and openmoko-terminal2-- the two apps I 
purchased the phone to use.

If some more "elegant" method is designed later on, and works, I'll switch to 
it. But for now I need a working keyboard in the terminal, and web browser, and 
all the other apps.

I'm sure all this will get sorted out eventually, and rough going like this is 
normal in the early days, so no big deal.

-ken

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Terminal for ASU

[David Samblas]

Ken, I think you have read my mind , translate it to english, and post
in the list, well maybe the latin sentences and references to kant are
replaced by basic complain :) 
El mié, 23-07-2008 a las 13:54 -0700, Ken Restivo escribió:
> On Wed, Jul 23, 2008 at 11:16:22PM +1000, Carsten Haitzler wrote:
> > 
> > > 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.
> >
> 
> If you've been mismanaged/micromanaged so badly that you've had to adopt what 
> Neitzche called the "Sklavmoral"-- or  "I'm not paid to think, I'm only paid 
> to wash the floors"-- attitude in order to survive, it doesn't bode well for 
> OpenMoko.
> 
> In any case, you're doing great work, so "illigitimum non carborundum".  I 
> can't tell you how delighted I was when I saw the "qwerty" button suddenly 
> appear after doing an opkg upgrade! And the ability to choose different 
> keyboard layouts from a pop-up menu was great. I thought to myself, "now THIS 
> is a well-managed project, critical features that I need are being added 
> without even asking for them, and the progress is daily!". And now of course 
> it is gone.
> 
> Can someone please document what hack is necessary to add that button back 
> in? And, yes, if anyone wants to please fork the necessary package, I will 
> subscribe to that feed instead, because the ability to use an on-screen 
> keyboard on a Linux phone is a must-have for me. The Illume keyboard with 
> Full-QWERTY is excellent and I love it. I need to be able to launch it 
> manually in order to use it with Minimo and openmoko-terminal2-- the two apps 
> I purchased the phone to use.
> 
> If some more "elegant" method is designed later on, and works, I'll switch to 
> it. But for now I need a working keyboard in the terminal, and web browser, 
> and all the other apps.
> 
> I'm sure all this will get sorted out eventually, and rough going like this 
> is normal in the early days, so no big deal.
> 
> -ken
> 
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Terminal for ASU

[The Rasterman]

On Wed, 23 Jul 2008 13:54:49 -0700 Ken Restivo <[EMAIL PROTECTED]> babbled:

> On Wed, Jul 23, 2008 at 11:16:22PM +1000, Carsten Haitzler wrote:
> > 
> > > 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.
> >
> 
> If you've been mismanaged/micromanaged so badly that you've had to adopt what
> Neitzche called the "Sklavmoral"-- or  "I'm not paid to think, I'm only paid
> to wash the floors"-- attitude in order to survive, it doesn't bode well for
> OpenMoko.
> 
> In any case, you're doing great work, so "illigitimum non carborundum".  I
> can't tell you how delighted I was when I saw the "qwerty" button suddenly
> appear after doing an opkg upgrade! And the ability to choose different
> keyboard layouts from a pop-up menu was great. I thought to myself, "now THIS
> is a well-managed project, critical features that I need are being added
> without even asking for them, and the progress is daily!". And now of course
> it is gone.

sorry to give false hope - that was just me... doing things... things slipped
through - i enable the button so i can do debugging and play with the keyboard
without having to go run or write special apps (i also have a special app to
test auto-keyboard hint properties too - but that's another matter). :) i
actually don't really intend for a lot of he current ugly guts of kbd changes
to be seen as well - it's all a work in progress, but the illume keyboard now
has everything except:

1. actual dictionary lookup + correction. (got the infra - just missing the
dict bit).
2. the ability to either enable or disable it and optionally run another
keyboard app (illume's keyboard won't always be what you want. it's really
meant to be the no-frills "really efficient" keyboard that comes for free (so to
speak) with your desktop env at very little overhead). it likely will never do
handwriting recognition or try emulate dasher... or many things, but for a
basic nuts and bolts inputs mechanism that is easily extended by users with new
layouts and gets the job done, its here and comes for "free" (as such if the
keyboard is never shown the code is never paged in and it uses no memory
resources. even if used - code is dynamically paged, so its paged out again when
not used).

> Can someone please document what hack is necessary to add that button back
> in? And, yes, if anyone wants to please fork the necessary package, I will
> subscribe to that feed instead, because the ability to use an on-screen
> keyboard on a Linux phone is a must-have for me. The Illume keyboard with
> Full-QWERTY is excellent and I love it. I need to be able to launch it
> manually in order to use it with Minimo and openmoko-terminal2-- the two apps
> I purchased the phone to use.

unfortunately you're out of luck. people who pay me want qtopia's keyboard -
and so they shall get it. illume's internal keyboard is/will be disabled. i
haven't had time to make any way to enable illume's internal one by config yet.

> If some more "elegant" method is designed later on, and works, I'll switch to
> it. But for now I need a working keyboard in the terminal, and web browser,
> and all the other apps.
> 
> I'm sure all this will get sorted out eventually, and rough going like this
> is normal in the early days, so no big deal.

edje_decc (from edj-utils) the illume.edj file (enligtenment theme installed
in /usr/share/enlightenment/data/themes). in the directory find the .edc file -
edit. search for a comment string "don't look at me".  here are 3 of them.
notice the line above i the same entry - just commented out with a different
value. comment out the line with the "don't look at me" comment and UNCOMMENT
the line above. you'll get a keyboard button. rebuild the file (build.sh or
edje_cc file.edc) and copy the .edj file back on top of the original... restart
E (killall -HUP enlightenment will do the job - along with a dozen other
mechanisms... all but 1 disabled). :)

-- 
Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]>

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Terminal for ASU

[Dale Schumacher]

On Wed, Jul 23, 2008 at 4:40 PM, The Rasterman Carsten Haitzler <
[EMAIL PROTECTED]> wrote:

> edje_decc (from edj-utils) the illume.edj file (enligtenment theme
> installed
> in /usr/share/enlightenment/data/themes). in the directory find the .edc
> file -
> edit. search for a comment string "don't look at me".  here are 3 of them.
> notice the line above i the same entry - just commented out with a
> different
> value. comment out the line with the "don't look at me" comment and
> UNCOMMENT
> the line above. you'll get a keyboard button. rebuild the file (build.sh or
> edje_cc file.edc) and copy the .edj file back on top of the original...
> restart
> E (killall -HUP enlightenment will do the job - along with a dozen other
> mechanisms... all but 1 disabled). :)
>

...and then post the results somewhere the user community can get it.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Terminal for ASU

[Michael Sheldon]

Dale Schumacher wrote:
> On Wed, Jul 23, 2008 at 4:40 PM, The Rasterman Carsten Haitzler 
> <[EMAIL PROTECTED] > wrote:
> 
> edje_decc (from edj-utils) the illume.edj file (enligtenment theme
> installed
> in /usr/share/enlightenment/data/themes). in the directory find the
> .edc file -
> edit. search for a comment string "don't look at me".  here are 3 of
> them.
> notice the line above i the same entry - just commented out with a
> different
> value. comment out the line with the "don't look at me" comment and
> UNCOMMENT
> the line above. you'll get a keyboard button. rebuild the file
> (build.sh or
> edje_cc file.edc) and copy the .edj file back on top of the
> original... restart
> E (killall -HUP enlightenment will do the job - along with a dozen other
> mechanisms... all but 1 disabled). :)
> 
> 
> ...and then post the results somewhere the user community can get it.

http://www.mikeasoft.com/~mike/illume.edj

This restores the button for me, but I'm in the same situation as a few 
other people whereby the keyboard doesn't appear under any 
circumstances, whether triggered by an entry field or by pressing the 
restored "qwerty" button.

Cheers,
  Mike.

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Terminal for ASU

[The Rasterman]

On Thu, 24 Jul 2008 00:01:15 +0100 Michael Sheldon <[EMAIL PROTECTED]> babbled:

> Dale Schumacher wrote:
> > On Wed, Jul 23, 2008 at 4:40 PM, The Rasterman Carsten Haitzler 
> > <[EMAIL PROTECTED] > wrote:
> > 
> > edje_decc (from edj-utils) the illume.edj file (enligtenment theme
> > installed
> > in /usr/share/enlightenment/data/themes). in the directory find the
> > .edc file -
> > edit. search for a comment string "don't look at me".  here are 3 of
> > them.
> > notice the line above i the same entry - just commented out with a
> > different
> > value. comment out the line with the "don't look at me" comment and
> > UNCOMMENT
> > the line above. you'll get a keyboard button. rebuild the file
> > (build.sh or
> > edje_cc file.edc) and copy the .edj file back on top of the
> > original... restart
> > E (killall -HUP enlightenment will do the job - along with a dozen other
> > mechanisms... all but 1 disabled). :)
> > 
> > 
> > ...and then post the results somewhere the user community can get it.
> 
> http://www.mikeasoft.com/~mike/illume.edj
> 
> This restores the button for me, but I'm in the same situation as a few 
> other people whereby the keyboard doesn't appear under any 
> circumstances, whether triggered by an entry field or by pressing the 
> restored "qwerty" button.

thats because the keyboard that is internal is currently turned off in code -
you require an external one (matchbox qwerty and multitap will work - and
qtopia now provides one).

-- 
Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]>

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Terminal for ASU

[arne anka]

> If you've been mismanaged/micromanaged so badly that you've had to adopt  
> what Neitzche called the "Sklavmoral"-- or  "I'm not paid to think, I'm

well, nietzsche told a lot of stuff and ended up in the funny farm in due  
time ... and if his own morale was that much better than sklavenmoral is  
up to discusssion.
anyway, what raster tries to say, imho, is: do not bother _him_ with your  
criticism but the designers themselves -- saying he's only the programmer  
makes imo sufficiently clear that he's not teh one to make that decistions  
and as he wrote before his opinion is not taken in account.
so, if you want to have it changed, bother the design department.

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Terminal for ASU

[Hugo Mills]

On Thu, Jul 24, 2008 at 09:30:03AM +0200, arne anka wrote:
> anyway, what raster tries to say, imho, is: do not bother _him_ with your  
> criticism but the designers themselves -- saying he's only the programmer  
> makes imo sufficiently clear that he's not teh one to make that decistions  
> and as he wrote before his opinion is not taken in account.
> so, if you want to have it changed, bother the design department.

   The problem here is that we can't, because the design department
don't seem to be engaging at all. We don't know who they are, and they
don't seem to be listening to the discussions on this list.

   Hugo.

-- 
=== Hugo Mills: [EMAIL PROTECTED] carfax.org.uk | darksatanic.net | lug.org.uk 
===
  PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
  --- In my day, we didn't have fancy high numbers.  We had ---  
   "nothing", "one", "twain" and "multitudes".   


signature.asc
Description: Digital signature
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Terminal for ASU

[Stroller]

On 24 Jul 2008, at 08:30, arne anka wrote:

>> If you've been mismanaged/micromanaged so badly that you've had to  
>> adopt
>> what Neitzche called the "Sklavmoral"-- or  "I'm not paid to  
>> think, I'm
>
> well, nietzsche told a lot of stuff and ended up in the funny farm  
> in due
> time ... and if his own morale was that much better than  
> sklavenmoral is
> up to discusssion.
> anyway, what raster tries to say, imho, is: do not bother _him_  
> with your
> criticism but the designers themselves -- saying he's only the  
> programmer
> makes imo sufficiently clear that he's not teh one to make that  
> decistions
> and as he wrote before his opinion is not taken in account.
> so, if you want to have it changed, bother the design department.

I did mean to reply to one of Carsten's earlier (yesterday) messages  
and say "I'm not having a go at you personally, mate".

But it is in order to badger the "design department" that we're  
posting to -community on the subject.

We don't seem to have contact details for the "design department" and  
with Carsten washing his hands of the matter (apparently justifiably)  
Openmoko seem to be ignoring the subject. How else can we get  
Openmoko to take our opinions into account, other than to post here?

Stroller.


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Terminal for ASU

[Yorick Moko]

the unabomber would know what to do! :)

No, seriously: enough openmoko-members read these mails.
It seems unimaginable that none of the design team has seen this
thread. It's about time they spoke up or that someone at openmoko
(Steve, Michael, Neng-Yu Tu ?) gave us some more info about the design
departement and how they implement the "openeness" of the project
there (no offence meant). Because it seems they are pretty closed to
the community, but this is just an impression and I might be wrong and
would like to see me proven wrong).

y

On Thu, Jul 24, 2008 at 1:24 PM, Stroller
<[EMAIL PROTECTED]> wrote:
>
> On 24 Jul 2008, at 08:30, arne anka wrote:
>
>>> If you've been mismanaged/micromanaged so badly that you've had to
>>> adopt
>>> what Neitzche called the "Sklavmoral"-- or  "I'm not paid to
>>> think, I'm
>>
>> well, nietzsche told a lot of stuff and ended up in the funny farm
>> in due
>> time ... and if his own morale was that much better than
>> sklavenmoral is
>> up to discusssion.
>> anyway, what raster tries to say, imho, is: do not bother _him_
>> with your
>> criticism but the designers themselves -- saying he's only the
>> programmer
>> makes imo sufficiently clear that he's not teh one to make that
>> decistions
>> and as he wrote before his opinion is not taken in account.
>> so, if you want to have it changed, bother the design department.
>
> I did mean to reply to one of Carsten's earlier (yesterday) messages
> and say "I'm not having a go at you personally, mate".
>
> But it is in order to badger the "design department" that we're
> posting to -community on the subject.
>
> We don't seem to have contact details for the "design department" and
> with Carsten washing his hands of the matter (apparently justifiably)
> Openmoko seem to be ignoring the subject. How else can we get
> Openmoko to take our opinions into account, other than to post here?
>
> Stroller.
>
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Terminal for ASU

[Ken Restivo]

On Thu, Jul 24, 2008 at 07:40:49AM +1000, Carsten Haitzler wrote:
> On Wed, 23 Jul 2008 13:54:49 -0700 Ken Restivo <[EMAIL PROTECTED]> babbled:
> 
> > On Wed, Jul 23, 2008 at 11:16:22PM +1000, Carsten Haitzler wrote:
> > > 
> > > > 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.
> > >
> > 
> > If you've been mismanaged/micromanaged so badly that you've had to adopt 
> > what
> > Neitzche called the "Sklavmoral"-- or  "I'm not paid to think, I'm only paid
> > to wash the floors"-- attitude in order to survive, it doesn't bode well for
> > OpenMoko.
> > 
> > In any case, you're doing great work, so "illigitimum non carborundum".  I
> > can't tell you how delighted I was when I saw the "qwerty" button suddenly
> > appear after doing an opkg upgrade! And the ability to choose different
> > keyboard layouts from a pop-up menu was great. I thought to myself, "now 
> > THIS
> > is a well-managed project, critical features that I need are being added
> > without even asking for them, and the progress is daily!". And now of course
> > it is gone.
> 
> sorry to give false hope - that was just me... doing things... things slipped
> through - i enable the button so i can do debugging and play with the keyboard
> without having to go run or write special apps (i also have a special app to
> test auto-keyboard hint properties too - but that's another matter). :) i
> actually don't really intend for a lot of he current ugly guts of kbd changes
> to be seen as well - it's all a work in progress, but the illume keyboard now
> has everything except:
> 
> 1. actual dictionary lookup + correction. (got the infra - just missing the
> dict bit).
> 2. the ability to either enable or disable it and optionally run another
> keyboard app (illume's keyboard won't always be what you want. it's really
> meant to be the no-frills "really efficient" keyboard that comes for free (so 
> to
> speak) with your desktop env at very little overhead). it likely will never do
> handwriting recognition or try emulate dasher... or many things, but for a
> basic nuts and bolts inputs mechanism that is easily extended by users with 
> new
> layouts and gets the job done, its here and comes for "free" (as such if the
> keyboard is never shown the code is never paged in and it uses no memory
> resources. even if used - code is dynamically paged, so its paged out again 
> when
> not used).
> 
> > Can someone please document what hack is necessary to add that button back
> > in? And, yes, if anyone wants to please fork the necessary package, I will
> > subscribe to that feed instead, because the ability to use an on-screen
> > keyboard on a Linux phone is a must-have for me. The Illume keyboard with
> > Full-QWERTY is excellent and I love it. I need to be able to launch it
> > manually in order to use it with Minimo and openmoko-terminal2-- the two 
> > apps
> > I purchased the phone to use.
> 
> unfortunately you're out of luck. people who pay me want qtopia's keyboard -
> and so they shall get it. illume's internal keyboard is/will be disabled. i
> haven't had time to make any way to enable illume's internal one by config 
> yet.

Ah wait, then I wasn't using the correct name for it.

The Qtopia keyboard-- whatever the default one is in qpe-- with the Full-QWERTY 
mode, *is* in fact what I want.

It's a great keyboard. I like that it has a simple mode, a Full-QWERTY mode, 
and a numeric mode. I thought Illume was the default keyboard but I guess qpe 
is. In any case, it's great, and I'm happy with it.

> 
> > If some more "elegant" method is designed later on, and works, I'll switch 
> > to
> > it. But for now I need a working keyboard in the terminal, and web browser,
> > and all the other apps.
> > 
> > I'm sure all this will get sorted out eventually, and rough going like this
> > is normal in the early days, so no big deal.
> 
> edje_decc (from edj-utils) the illume.edj file (enligtenment theme installed
> in /usr/share/enlightenment/data/themes). in the directory find the .edc file 
> -
> edit. search for a comment string "don't look at me".  here are 3 of them.
> notice the line above i the same entry - just commented out with a different
> value. comment out the line with the "don't look at me" comment and UNCOMMENT
> the line above. you'll get a keyboard button. rebuild the file (build.sh or
> edje_cc file.edc) and copy the .edj file back on top of the original... 
> restart
> E (killall -HUP enlightenment will do the job - along with a dozen other
> mechanisms... al

Re: Terminal for ASU

[The Rasterman]

On Thu, 24 Jul 2008 13:40:51 -0700 Ken Restivo <[EMAIL PROTECTED]> babbled:


> > unfortunately you're out of luck. people who pay me want qtopia's keyboard -
> > and so they shall get it. illume's internal keyboard is/will be disabled. i
> > haven't had time to make any way to enable illume's internal one by config
> > yet.
> 
> Ah wait, then I wasn't using the correct name for it.
> 
> The Qtopia keyboard-- whatever the default one is in qpe-- with the
> Full-QWERTY mode, *is* in fact what I want.
> 
> It's a great keyboard. I like that it has a simple mode, a Full-QWERTY mode,
> and a numeric mode. I thought Illume was the default keyboard but I guess qpe
> is. In any case, it's great, and I'm happy with it.

actually - the illume one is the on with the 3 modes (the dictionary icon
top-left, the layout icon top-right to select layout). they are in fact very
similar... :)

> > edje_decc (from edj-utils) the illume.edj file (enligtenment theme installed
> > in /usr/share/enlightenment/data/themes). in the directory find the .edc
> > file - edit. search for a comment string "don't look at me".  here are 3 of
> > them. notice the line above i the same entry - just commented out with a
> > different value. comment out the line with the "don't look at me" comment
> > and UNCOMMENT the line above. you'll get a keyboard button. rebuild the
> > file (build.sh or edje_cc file.edc) and copy the .edj file back on top of
> > the original... restart E (killall -HUP enlightenment will do the job -
> > along with a dozen other mechanisms... all but 1 disabled). :)
> 
> Thanks. I may have a play with that later.
> 
> Someone posted an .edj file to make the "qwerty" button re-appear on the
> default QPE keyboard, and with that, and now that I'm pointed to the correct
> downloads.openmoko.org repository, life is once again good.
> 
> Thanks again for all your hard work on this!

cool.. no problems. :)

-- 
Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]>

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Terminal for ASU

[Sean Moss-Pultz]

I will reply over the weekend.

   -Sean




Yorick Moko wrote:
> the unabomber would know what to do! :)
> 
> No, seriously: enough openmoko-members read these mails.
> It seems unimaginable that none of the design team has seen this
> thread. It's about time they spoke up or that someone at openmoko
> (Steve, Michael, Neng-Yu Tu ?) gave us some more info about the design
> departement and how they implement the "openeness" of the project
> there (no offence meant). Because it seems they are pretty closed to
> the community, but this is just an impression and I might be wrong and
> would like to see me proven wrong).
> 
> y
> 
> On Thu, Jul 24, 2008 at 1:24 PM, Stroller
> <[EMAIL PROTECTED]> wrote:
>> On 24 Jul 2008, at 08:30, arne anka wrote:
>>
 If you've been mismanaged/micromanaged so badly that you've had to
 adopt
 what Neitzche called the "Sklavmoral"-- or  "I'm not paid to
 think, I'm
>>> well, nietzsche told a lot of stuff and ended up in the funny farm
>>> in due
>>> time ... and if his own morale was that much better than
>>> sklavenmoral is
>>> up to discusssion.
>>> anyway, what raster tries to say, imho, is: do not bother _him_
>>> with your
>>> criticism but the designers themselves -- saying he's only the
>>> programmer
>>> makes imo sufficiently clear that he's not teh one to make that
>>> decistions
>>> and as he wrote before his opinion is not taken in account.
>>> so, if you want to have it changed, bother the design department.
>> I did mean to reply to one of Carsten's earlier (yesterday) messages
>> and say "I'm not having a go at you personally, mate".
>>
>> But it is in order to badger the "design department" that we're
>> posting to -community on the subject.
>>
>> We don't seem to have contact details for the "design department" and
>> with Carsten washing his hands of the matter (apparently justifiably)
>> Openmoko seem to be ignoring the subject. How else can we get
>> Openmoko to take our opinions into account, other than to post here?
>>
>> Stroller.
>>
>>
>> ___
>> Openmoko community mailing list
>> community@lists.openmoko.org
>> http://lists.openmoko.org/mailman/listinfo/community
>>
> 
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Terminal for ASU

[Jim Morris]

Hugo Mills wrote:
> 
>The problem here is that we can't, because the design department
> don't seem to be engaging at all. We don't know who they are, and they
> don't seem to be listening to the discussions on this list.

I'm going to weigh in here with my 2 cents worth.

This so called design department should all be fired IMHO :)

They took Qtopia which is a very nice UI and turned it into ASU which IMHO is 
unintuitive, and 
doesn't work at all well from a usability standpoint (the coding is excellent 
however ;)

2007.2 was also unintuitive and ugly, so if its the same guys, I recommend they 
read a few books on 
designing usable UIs that end users want to use. (or maybe Apple patented that 
design ;)

I have been playing with ASU for a few days now, and am switching back to 
Qtopia, as it has 
frustrated me beyond belief, the last straw is when it let me remove the 
configuration tool from the 
UI so now it can't be put back, and there is no terminal where it could be 
fixed.

I also found the UI is not very consistent on whether you tap or double click 
to get stuff to work, 
or maybe that is a bug? I end up tapping some icons 5 times before anything 
shows up. (Maybe its 
just slow?)

Anyway enough whining :) I'll look at ASU again in 2 months and see if this 
design team has gotten 
its act together and has started listening to its customers (ie us).

Thanks for the soap box.. next...


-- 
Jim Morris, http://blog.wolfman.com

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

RE: Terminal for ASU

[steve]

Ask your questions stroller.

I'll  do my best to answer them.




 

-Original Message-
From: Carsten Haitzler (The Rasterman) [mailto:[EMAIL PROTECTED] 
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 <[EMAIL PROTECTED]>
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:
&g

Re: Terminal for ASU

[Jim Morris]

Jay Vaughan wrote:

> I'm with you on that, it seems like its just too late to be doing ASU, 
> this should've been sorted out months ago, before hardware was actually 
> shipping to customer (hacker and non- alike), so for me I'm sticking 
> with the godamn ugly 2007.2 for now, simply because its what the phone 
> came with: and thats the point.  ASU is too little, too late.
> 

Try Qtopia, its more what I expected a phone like this to look like, and it 
mostly works.


-- 
Jim Morris, http://blog.wolfman.com

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Terminal for ASU

[Jay Vaughan]

> Anyway enough whining :) I'll look at ASU again in 2 months and see  
> if this design team has gotten
> its act together and has started listening to its customers (ie us).


I'm with you on that, it seems like its just too late to be doing ASU,  
this should've been sorted out months ago, before hardware was  
actually shipping to customer (hacker and non- alike), so for me I'm  
sticking with the godamn ugly 2007.2 for now, simply because its what  
the phone came with: and thats the point.  ASU is too little, too late.

;
--
Jay Vaughan





___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

RE: Terminal for ASU

[steve]

Hehe. I did my honors on Neitzche.

Stroller,

If you want to talk to design then just send me mail.



 






 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Stroller
Sent: Thursday, July 24, 2008 4:24 AM
To: List for Openmoko community discussion
Subject: Re: Terminal for ASU


On 24 Jul 2008, at 08:30, arne anka wrote:

>> If you've been mismanaged/micromanaged so badly that you've had to 
>> adopt what Neitzche called the "Sklavmoral"-- or  "I'm not paid to 
>> think, I'm
>
> well, nietzsche told a lot of stuff and ended up in the funny farm in 
> due time ... and if his own morale was that much better than 
> sklavenmoral is up to discusssion.
> anyway, what raster tries to say, imho, is: do not bother _him_ with 
> your criticism but the designers themselves -- saying he's only the 
> programmer makes imo sufficiently clear that he's not teh one to make 
> that decistions and as he wrote before his opinion is not taken in 
> account.
> so, if you want to have it changed, bother the design department.

I did mean to reply to one of Carsten's earlier (yesterday) messages and say
"I'm not having a go at you personally, mate".

But it is in order to badger the "design department" that we're posting to
-community on the subject.

We don't seem to have contact details for the "design department" and with
Carsten washing his hands of the matter (apparently justifiably) Openmoko
seem to be ignoring the subject. How else can we get Openmoko to take our
opinions into account, other than to post here?

Stroller.


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Terminal for ASU

[Jay Vaughan]

> Try Qtopia, its more what I expected a phone like this to look like,  
> and it mostly works.


I tried it, but to be frank I'm a little more inclined to want to go  
with the 'open' side of things, even if its messy and chaotic, than  
the 'commercial vendor slipping us open guys a sugary treat so we  
don't out-do them' approach, which is what I think Qtopia is, really ..

;
--
Jay Vaughan





___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

RE: Terminal for ASU

[steve]

Oh  the design team have been  listening.

I convinced people to let ASU be released when it was pre alpha. Very early
in development.
Primarily so that the community could have a look at and make constructive
feedback.

So I owe the design Team an apology.

 

Steve 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Hugo Mills
Sent: Thursday, July 24, 2008 12:39 AM
To: List for Openmoko community discussion
Subject: Re: Terminal for ASU

On Thu, Jul 24, 2008 at 09:30:03AM +0200, arne anka wrote:
> anyway, what raster tries to say, imho, is: do not bother _him_ with 
> your criticism but the designers themselves -- saying he's only the 
> programmer makes imo sufficiently clear that he's not teh one to make 
> that decistions and as he wrote before his opinion is not taken in
account.
> so, if you want to have it changed, bother the design department.

   The problem here is that we can't, because the design department don't
seem to be engaging at all. We don't know who they are, and they don't seem
to be listening to the discussions on this list.

   Hugo.

--
=== Hugo Mills: [EMAIL PROTECTED] carfax.org.uk | darksatanic.net | lug.org.uk 
===
  PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
  --- In my day, we didn't have fancy high numbers.  We had ---  
   "nothing", "one", "twain" and "multitudes".   


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Terminal for ASU

[Stroller]

Believe it or not, Steve, sarcasm is not the same thing as wit.

I am sure you have plenty of wit at your disposal. You do yourself a  
disservice in failing to exercise it.

Stroller.



On 28 Jul 2008, at 22:11, steve wrote:

> Oh  the design team have been  listening.
> ...
> So I owe the design Team an apology.

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Where's edje_decc? (was: Re: Terminal for ASU)

[Marcel]

Am Dienstag 22 Juli 2008 15:04:59 schrieb Carsten Haitzler:
[...]
> either way - there WAS a button.. it was in the top-left corner of the
> screen that was blank and unused anyway. it used up no extra screen space
> and was obvious to hit. it was by far the best option available so far. if
> you hack the illum theme (edje_decc illme.edj to decompile - edit the .edc
> and run build.sh to rebuild... copy it back in place). you can add the
> button back - if you can find it.

Where can I find this "edje_decc"? Searching the om and debian repos didn't 
turn up anything useful, google the same. I'd really like to add a button for 
my own app to zhone so that I don't need to start it with x-tunneling all the 
time. Same for the agpsui... :)

-marcel

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Where's edje_decc? (was: Re: Terminal for ASU)

[The Rasterman]

On Wed, 23 Jul 2008 15:04:12 +0200 Marcel <[EMAIL PROTECTED]> babbled:

> Am Dienstag 22 Juli 2008 15:04:59 schrieb Carsten Haitzler:
> [...]
> > either way - there WAS a button.. it was in the top-left corner of the
> > screen that was blank and unused anyway. it used up no extra screen space
> > and was obvious to hit. it was by far the best option available so far. if
> > you hack the illum theme (edje_decc illme.edj to decompile - edit the .edc
> > and run build.sh to rebuild... copy it back in place). you can add the
> > button back - if you can find it.
> 
> Where can I find this "edje_decc"? Searching the om and debian repos didn't 
> turn up anything useful, google the same. I'd really like to add a button for 
> my own app to zhone so that I don't need to start it with x-tunneling all the 
> time. Same for the agpsui... :)

it comes with edje... there is edje_cc and edje_decc (they are used to compile
and decompile themes files). edje is in testing in debian... otherwise
enlightenment.org - and grab cvs... or download snapshot tarballs.


-- 
Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]>

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Where's edje_decc? (was: Re: Terminal for ASU)

[Jacob Peterson]

On Wed, Jul 23, 2008 at 8:47 AM, The Rasterman Carsten Haitzler <
[EMAIL PROTECTED]> wrote:

> On Wed, 23 Jul 2008 15:04:12 +0200 Marcel <[EMAIL PROTECTED]> babbled:
>
> > Am Dienstag 22 Juli 2008 15:04:59 schrieb Carsten Haitzler:
> > [...]
> > > either way - there WAS a button.. it was in the top-left corner of the
> > > screen that was blank and unused anyway. it used up no extra screen
> space
> > > and was obvious to hit. it was by far the best option available so far.
> if
> > > you hack the illum theme (edje_decc illme.edj to decompile - edit the
> .edc
> > > and run build.sh to rebuild... copy it back in place). you can add the
> > > button back - if you can find it.
> >
> > Where can I find this "edje_decc"? Searching the om and debian repos
> didn't
> > turn up anything useful, google the same. I'd really like to add a button
> for
> > my own app to zhone so that I don't need to start it with x-tunneling all
> the
> > time. Same for the agpsui... :)
>
> it comes with edje... there is edje_cc and edje_decc (they are used to
> compile
> and decompile themes files). edje is in testing in debian... otherwise
> enlightenment.org - and grab cvs... or download snapshot tarballs.
>
>
> --
> Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]>
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>


There is also an edje-utils package available from opkg which contains those
tools.

-Jacob
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Community contributions to core apps & features. (Was: Terminal for ASU)

[Stroller]

On 26 Jul 2008, at 03:10, steve wrote:

> Ask your questions stroller.
>
> I'll  do my best to answer them.

Hi Steve,

Thanks for your reply. I've posted my questions - or rather a request  
for openness & clarification - already in this thread. Because the  
background of the thread already contains all context you ought to  
need, it's difficult to know where to start asking you questions. Let  
me try.

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.  personally i think you
   need a manual control because, as such, many apps and toolkits will
   not be changed, or they will get it wrong and give you a keyboard
   when you don't want one, or decide not to give you one when you
   do... but that's not my call.

- Who are the designers who decided that ASU is not to have any  
manual keyboard toggle button because it will "disturb the design and/ 
or confuse users" please? Was this a group of Openmoko employees? Or  
a single individual at Openmoko? Does this person have a specified  
role managing the design of ASU? Who do users bitch to if they don't  
like "design decisions"?
- How do you respond to Raster's suggestion that a "manual override"  
will be needed?
- Is a complicated "protocol" to bring up the keyboard on demand -  
which each input method will need to be patched to support - *really*  
better than a simple button?
- Will it be difficult to accommodate this protocol when porting an  
input method (Dasher, for instance) to Openmoko? Or will it be simple  
enough to do so that it easily justifies that lack of a manual  
keyboard button?

No. Ignore those questions.

This is only a small thing. I haven't followed the details of the  
problem closely - it was Raster's "i wanted to do this this way, but  
i wasn't allowed to" that surprised me - but it looks like the  
problems that this introduces aren't unmanageable.

What is of more concern is the connotations of this decision. As far  
as we (end-users on -community) are able to determine, a feature was  
removed by the process of someone @openmoko saying "I don't like  
that" and emailing Raster (or IRCing him or walking into his office)  
and saying "pull that" without saying to the users "hey, before we do  
this, are you using that feature? do *you* think it's ugly or  
confusing?"

Openmoko has always promoted itself as "fully open" - to quote  
Michael's words a couple of days ago:

   the goal of the project is not to create a new cellphone, but rather,
   that by being open, we allow and encourage innovation, and that by
   working with you, the open source community, we tap into a huge
   pool of imaginative, creative, very smart and hardworking innovators.

I have always understood Openmoko's openness to encompass the *entire  
breadth* of Openmoko software development. It's great if we can write  
apps for the Freerunner, but I can already write apps for Symbian or  
Windows Mobile. It's great that I can fork the code Openmoko are  
writing commercially and make modifications to the application  
manager or the dialler but that's obviously a duplication of effort -  
I thought you wanted the community to help contribute to the core  
applications, too. Isn't this the case?

Let's talk about the hypothetical community member Bob. Bob has a  
great idea a feature that he'd like to see on his mobile phone. Let's  
say he's meeting Charlie at cafe near the Linux convention and he  
thinks "it'd be great if I could select Charlie in my phone's  
addressbook and - alongside 'call contact' and 'SMS contact' - it  
said 'Send my location'. I'd just click that and it could SMS my GPS  
location to Charlie and on Charlie's phone it would pop up a message  
'Bob has sent you his location by SMS. Would you like to see where he  
is?' and then show a map with my location on it (or at least a needle  
showing distance and direction)".

Under a normal community development process Bob has some idea of  
whether or not other developers might like this idea. He can message  
them on IRC and say "would you include that in the main tree?" Bob  
can hack together a bit of code showing a working prototype and post  
patches to the mailing list knowing that the community will at least  
consider it. They might say "cool idea, but no-one'll use it, so we  
don't want it in the core distro", they might say "it needs a lot of  
polish", they might say "add a configuration option to enable/disable  
it". But even if they ultimately reject it, Bob can submit his code  
with some idea of the shared goals of the other developers and  
knowing that the idea will be considered on the merits of whether the  
other developers t

Re: Community contributions to core apps & features. (Was: Terminal for ASU)

[rakshat hooja]

On Sat, Jul 26, 2008 at 1:16 PM, Stroller <[EMAIL PROTECTED]>wrote:

>
>
> There's apparently no design document saying where ASU (or whatever)
> is going in terms of features. We don't know who to contact in order
> to get approval for our concepts before we waste a lot of time on
> them.


I agree with your points and questions and am waiting for answers for Steve
but have you seen this

http://wiki.openmoko.org/wiki/ASU_Feature_Plan

It is pretty easy to see the ASU features and who to contact.

Rakshat
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Community contributions to core apps & features. (Was: Terminal for ASU)

[Stroller]

On 26 Jul 2008, at 09:46, rakshat hooja wrote:
> On Sat, Jul 26, 2008 at 1:16 PM, Stroller  
> <[EMAIL PROTECTED]> wrote:
>
>> There's apparently no design document saying where ASU (or whatever)
>> is going in terms of features. We don't know who to contact in order
>> to get approval for our concepts before we waste a lot of time on
>> them.
>
> I agree with your points and questions and am waiting for answers  
> for Steve but have you seen this
>
> http://wiki.openmoko.org/wiki/ASU_Feature_Plan
>
> It is pretty easy to see the ASU features and who to contact.

Had I seen this? Absolutely not!
And I do wish I had seen it before.

I won't comment further at this time, but I'll amend the wiki later  
(cc'd to documentation as a reminder) so that some other relevant  
pages link to it & it's easier to find.

Stroller.




___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Community contributions to core apps & features. (Was: Terminal for ASU)

[Timo Jyrinki]

2008/7/26 Stroller <[EMAIL PROTECTED]>:
> I won't comment further at this time, but I'll amend the wiki later
> (cc'd to documentation as a reminder) so that some other relevant
> pages link to it & it's easier to find.

It is already linked from the front page, but clearly from not those
places it should be from :)

But you have good points. Openmoko is open, but its development is not
exposed in the open as much as I'd like for an open source project to
be. The Openmoko folks are still a bit "mysterious" to me, with the
exception of the few who regularly post on these mailing lists.

I think the line between Openmoko employee and a contributing, trusted
community member should be made more fuzzy. More SVN / GIT rights to
the people, more contributing directly to http://svn.openmoko.org/
instead of just "external" projects at projects.openmoko.org etc. I
would guess this is going to happen more with the development of FSO?

-Timo

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Community contributions to core apps & features. (Was: Terminal for ASU)

[rakshat hooja]

>
>
> It is already linked from the front page, but clearly from not those
> places it should be from :)
>
> But you have good points. Openmoko is open, but its development is not
> exposed in the open as much as I'd like for an open source project to
> be. The Openmoko folks are still a bit "mysterious" to me, with the
> exception of the few who regularly post on these mailing lists.
>
> I think the line between Openmoko employee and a contributing, trusted
> community member should be made more fuzzy. More SVN / GIT rights to
> the people, more contributing directly to http://svn.openmoko.org/
> instead of just "external" projects at projects.openmoko.org etc.


You are right but I think that the problem lies in the fact that Openmoko
has not been able to provide any entry point where new people joining the
list (after the release of the freerunner) can figure out who and where to
ask what question. The Openmoko people are pretty open and if you will ask
for something long enough you will get an answer/ access from them.
MichaelShiloh of Openmoko used to interface with the community and
answer their
questions after getting the information from the developers in a regular
community update. I think Steve and Michael still do that? Maybe we should
have a page on the wiki describing who does what at Openmoko and who to
address what question to and also an introductory email for new subscribers
listing out similar things.

It has been almost an year since I wrote my first email to Openmoko
(actually to Sean  to which Michael Shiloh replied) I can assure you that
Openmoko people try their "hardest" to be open and responsive to community
suggestions/ questions. But often it takes time for the question/ request to
reach the correct person who can answer it / respond to it.

Rakshat
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Community contributions to core apps & features. (Was: Terminal for ASU)

[Aaron Sowry]

rakshat hooja wrote:
>
>
>
> It is already linked from the front page, but clearly from not those
> places it should be from :)
>
> But you have good points. Openmoko is open, but its development is not
> exposed in the open as much as I'd like for an open source project to
> be. The Openmoko folks are still a bit "mysterious" to me, with the
> exception of the few who regularly post on these mailing lists.
>
> I think the line between Openmoko employee and a contributing, trusted
> community member should be made more fuzzy. More SVN / GIT rights to
> the people, more contributing directly to http://svn.openmoko.org/
> instead of just "external" projects at projects.openmoko.org
>  etc. 
>
>
> You are right but I think that the problem lies in the fact that 
> Openmoko has not been able to provide any entry point where new people 
> joining the list (after the release of the freerunner) can figure out 
> who and where to ask what question. The Openmoko people are pretty 
> open and if you will ask for something long enough you will get an 
> answer/ access from them. Michael Shiloh of Openmoko used to interface 
> with the community and answer their questions after getting the 
> information from the developers in a regular community update. I think 
> Steve and Michael still do that? Maybe we should have a page on the 
> wiki describing who does what at Openmoko and who to address what 
> question to and also an introductory email for new subscribers listing 
> out similar things.
>
> It has been almost an year since I wrote my first email to Openmoko 
> (actually to Sean  to which Michael Shiloh replied) I can assure you 
> that Openmoko people try their "hardest" to be open and responsive to 
> community suggestions/ questions. But often it takes time for the 
> question/ request to reach the correct person who can answer it / 
> respond to it.
>
> Rakshat
>
>
>
> 
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>   
This seems trivial but I think it is important. Even though open-source 
communities often strive to be non-heirarchical it is important that 
there be project leaders and that the people involved with development 
know these people and what their roles are. If you've just come on board 
(like I have) you could almost be forgiven for thinking that the 
Openmoko project is a loose-knit group of enthusiasts casually 
meandering from one platform to the next with no real direction for the 
past 12 months, and I think at least having a visible core team who send 
community updates on a regular basis is a step towards getting everyone 
singing from the same hymn sheet. These and other such details need to 
be prominently displayed on the wiki.

I guess the core aim of Openmoko is to liberate the mobile platform and 
put technology back in the hands of the end-user through open-source 
software, however people are only going to get on board if it works. I 
have to say that I am left slightly underwhelmed after a couple of days 
with my FreeRunner - as a development platform it is brilliant and the 
geek in me certainly doesn't regret the purchase, however it is 
frustrating that after a years worth of open development I am still 
unable to use it as my primary phone (purportedly the main purpose of 
the device) due to hardware and software issues. Remember that Linux is 
set to capture the mobile market in a seriously big way over the next 
few years so we are far from the only ones doing this, and I think that 
if Openmoko is to remain competitive rather than be relegated to a 
hobbyist device then progress needs to be made in leaps and bounds 
rather than dribs and drabs, at least in the usability department. 
Perhaps a little cohesion would be a step in the right direction.

Hopefully this is seen as constructive and not a whiny rant - I figure 
that this mailing list is intended for this type of discussion?


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Community contributions to core apps & features. (Was: Terminal for ASU)

[Michele Renda]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

This problem is common to all the process / firms: who must to take the
important design decision?

There can be two possibility:

A) Who code

B) Who doesn't code but can have a global vision of the project


To choose between these two alternatives is not easy. Who code know well
how it run, what the hardware can do.

Who don't code, may have a global vision of the project, he know which
are the objectives, deadlines, etc. etc.

I am a programmer: when I receive a work I receive the specification and
I must follow it. It happen that from time to time I think: but this is
a stupid request / non sense. But I have to follow.

According me the best solution is a between A and B. B know where to go,
and A know which is the better way of to take it.
So, on openmoko will be a very nice thing that on the morning they get a
very good coffe in a table and A and B, because A can do nothing without
B and B can do nothing without A.

Then there is the thirth element

C) The end users

The end user are who in the end will pay and will use the phone. Their
request are important but there are two big problems:

1) Often C don't know how it is running
2) All C's have different needs and different wishes. Is impossible to
have all the persons happy.

An example GTA3 must to have a camera? For me is NO, for another person
may be the same, but for another is very important to get it.
Who must to win?

So I think decisions must be taken by A union B reading from time to
time also what say C. A opensource project / phone DOESN'T mean a
democratic process.


In a future I hope that some persons will start to build a S.O. for
Openmoko but driven by a different organization.
This will let Openmoko to put all his resourses on the hardware part,
while the SOFTWARE part is managed my another organization (Like it
happen now with PC and OS)

But in every case, it is only a my idea :)

Regards
Michele Renda
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkiLGOEACgkQSIAU/I6SkT1xqQCghYBc12Os3BsskIRYxw3nyKRc
HuUAoIgu5kqrzuS1JfPV0pJjo+Ih5f0l
=78YY
-END PGP SIGNATURE-

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Community contributions to core apps & features. (Was: Terminal for ASU)

[Lisa]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Thanks for posting that link Rashat!  I'm waiting for Stroller to get an 
answer too, but it's nice to know who to complain to about what after 
this :)
~  I want my KEYBOARD SWITCH back, I do!
~   Lisa
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFIjIa81sOMhsR36UsRAthKAJ4oMwaLF8ktJTOTN+N+4pg9D49mZQCgridn
MR21pkary5efNvY+F5myvjU=
=MAVw
-END PGP SIGNATURE-


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Community contributions to core apps & features. (Was: Terminal for ASU)

[Michael Shiloh]

rakshat hooja wrote:
> 
> 
> 
> It is already linked from the front page, but clearly from not those
> places it should be from :)
> 
> But you have good points. Openmoko is open, but its development is not
> exposed in the open as much as I'd like for an open source project to
> be. The Openmoko folks are still a bit "mysterious" to me, with the
> exception of the few who regularly post on these mailing lists.
> 
> I think the line between Openmoko employee and a contributing, trusted
> community member should be made more fuzzy. More SVN / GIT rights to
> the people, more contributing directly to http://svn.openmoko.org/
> instead of just "external" projects at projects.openmoko.org
>  etc. 
> 
> 
> You are right but I think that the problem lies in the fact that 
> Openmoko has not been able to provide any entry point where new people 
> joining the list (after the release of the freerunner) can figure out 
> who and where to ask what question. The Openmoko people are pretty open 
> and if you will ask for something long enough you will get an answer/ 
> access from them. Michael Shiloh of Openmoko used to interface with the 
> community and answer their questions after getting the information from 
> the developers in a regular community update. I think Steve and Michael 
> still do that? 

You are right, Steve and I still do that.

My formal job is to ease communication between the community and the 
company. As I am not in Taiwan I am somewhat out of the loop of many of 
the decisions and processes. In fact, as the OP suggests, I am that 
fuzzy person between the community and the company.

I've let Steve do the updates for the past while because as the decision 
maker on when and what to ship, he has much more visibility into the 
schedule than I do. There was clearly nothing I could contribute in that 
realm, and there is rarely anything I can add on top of Steve's updates.


Maybe we should have a page on the wiki describing who
> does what at Openmoko and who to address what question to

We have the beginning of such a wiki page, and I'll expand my job 
description.




  and also an
> introductory email for new subscribers listing out similar things.

Good idea. The best answer to the question "who do I ask this question?" 
usually is "it's better to ask it on the list, since (a) if the best 
person to ask isn't available, chances are someone else on the list will 
answer pretty quickly and (b) your answer will benefit others both now 
and in the future through the archives and perhaps (c) we try to be as 
open as possible. Ask on the list unless it is private. But your point 
is taken, and this should be in such an introductory email.


> 
> It has been almost an year since I wrote my first email to Openmoko 
> (actually to Sean  to which Michael Shiloh replied) I can assure you 
> that Openmoko people try their "hardest" to be open and responsive to 
> community suggestions/ questions. But often it takes time for the 
> question/ request to reach the correct person who can answer it / 
> respond to it.

Indeed. The degree to which we are all overwhelmed is astonishing. I 
have never worked at a job where each of us wore so many hats, and where 
each hat involved so much email and related conversations.

For example, I was thrilled yesterday when I got my _unread_ mail 
message count down below 1000. Whee!

We do sincerely try to do our best. Sometimes we fail because we don't 
know what is best, but usually we delay simply because we don't have the 
time.

We really do rely on the community to take some of the load off of us. 
This is why I was so thrilled to so the wiki maintenance volunteers. A 
well maintained, informative wiki will free up the time of Openmoko 
engineers to do what they need to do, instead of answering questions 
that are already answered in the wiki but simply can't be found.

I should add that we are very much aware that many of you on this list 
already perform this task and already reduce our workload by helping and 
answering. The well maintained wiki will help free your time up, so you 
too can be doing more important things (like helping us?) rather than 
answering questions that are already answered.

Along these lines I should mention that the testing, reporting, and bug 
filing that you are doing for OM 2008.8 is tremendously helpful. Please 
keep this up. An identified problem and a well defined, reproducible bug 
report saves so much time for the engineer assigned to fix it. Thank you.

Finally, my primary job is to keep you all happy. If you have any 
complaints, questions, problems, suggestions, or other comments, please 
do write me, either on the list of privately. It is both my job and my 
personal wish to keep and to further strengthen an involved, active, 
enthusiastic, and productive community. I still believe that the most 
amazing devices have yet to be imagined, and are more