Re: Terminal for ASU

2008-07-28 Thread 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

2008-07-28 Thread 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

2008-07-28 Thread 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


RE: Terminal for ASU

2008-07-27 Thread 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

2008-07-26 Thread 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

2008-07-26 Thread 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

2008-07-25 Thread 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

2008-07-25 Thread 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

2008-07-25 Thread 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:
  ...
  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

Re: Terminal for ASU

2008-07-24 Thread 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

2008-07-24 Thread 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

2008-07-24 Thread 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

2008-07-24 Thread 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

2008-07-24 Thread 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... 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 

Re: Terminal for ASU

2008-07-24 Thread 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

2008-07-23 Thread 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


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

2008-07-23 Thread 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: Terminal for ASU

2008-07-23 Thread 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

2008-07-23 Thread 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 misnaming these individuals (this  
 individual?). A design document is required for a design, so that  
 everyone can see the rationale for decisions. Everything 

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

2008-07-23 Thread 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)

2008-07-23 Thread 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


Re: Terminal for ASU

2008-07-23 Thread 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

2008-07-23 Thread 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

2008-07-23 Thread 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

2008-07-23 Thread 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

2008-07-23 Thread Michael Sheldon
Dale Schumacher wrote:
 On Wed, Jul 23, 2008 at 4:40 PM, The Rasterman Carsten Haitzler 
 [EMAIL PROTECTED] mailto:[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

2008-07-23 Thread 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] mailto:[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

2008-07-22 Thread 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

2008-07-22 Thread 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

2008-07-22 Thread 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

2008-07-22 Thread 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

2008-07-22 Thread 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

2008-07-22 Thread 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

2008-07-22 Thread 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

2008-07-22 Thread 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

2008-07-22 Thread 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

2008-07-22 Thread 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

2008-07-22 Thread 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

2008-07-21 Thread 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

2008-07-21 Thread 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

2008-07-21 Thread 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

2008-07-21 Thread 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

2008-07-21 Thread 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

2008-07-21 Thread 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

2008-07-21 Thread 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

2008-07-21 Thread 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

2008-07-20 Thread 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

2008-07-20 Thread 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

2008-07-20 Thread 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

2008-07-20 Thread 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