Re: Community contributions to core apps features. (Was: Terminal for ASU)
rakshat hooja wrote: It is already linked from the front page, but clearly from not those places it should be from :) But you have good points. Openmoko is open, but its development is not exposed in the open as much as I'd like for an open source project to be. The Openmoko folks are still a bit mysterious to me, with the exception of the few who regularly post on these mailing lists. I think the line between Openmoko employee and a contributing, trusted community member should be made more fuzzy. More SVN / GIT rights to the people, more contributing directly to http://svn.openmoko.org/ instead of just external projects at projects.openmoko.org http://projects.openmoko.org etc. You are right but I think that the problem lies in the fact that Openmoko has not been able to provide any entry point where new people joining the list (after the release of the freerunner) can figure out who and where to ask what question. The Openmoko people are pretty open and if you will ask for something long enough you will get an answer/ access from them. Michael Shiloh of Openmoko used to interface with the community and answer their questions after getting the information from the developers in a regular community update. I think Steve and Michael still do that? You are right, Steve and I still do that. My formal job is to ease communication between the community and the company. As I am not in Taiwan I am somewhat out of the loop of many of the decisions and processes. In fact, as the OP suggests, I am that fuzzy person between the community and the company. I've let Steve do the updates for the past while because as the decision maker on when and what to ship, he has much more visibility into the schedule than I do. There was clearly nothing I could contribute in that realm, and there is rarely anything I can add on top of Steve's updates. Maybe we should have a page on the wiki describing who does what at Openmoko and who to address what question to We have the beginning of such a wiki page, and I'll expand my job description. and also an introductory email for new subscribers listing out similar things. Good idea. The best answer to the question who do I ask this question? usually is it's better to ask it on the list, since (a) if the best person to ask isn't available, chances are someone else on the list will answer pretty quickly and (b) your answer will benefit others both now and in the future through the archives and perhaps (c) we try to be as open as possible. Ask on the list unless it is private. But your point is taken, and this should be in such an introductory email. It has been almost an year since I wrote my first email to Openmoko (actually to Sean to which Michael Shiloh replied) I can assure you that Openmoko people try their hardest to be open and responsive to community suggestions/ questions. But often it takes time for the question/ request to reach the correct person who can answer it / respond to it. Indeed. The degree to which we are all overwhelmed is astonishing. I have never worked at a job where each of us wore so many hats, and where each hat involved so much email and related conversations. For example, I was thrilled yesterday when I got my _unread_ mail message count down below 1000. Whee! We do sincerely try to do our best. Sometimes we fail because we don't know what is best, but usually we delay simply because we don't have the time. We really do rely on the community to take some of the load off of us. This is why I was so thrilled to so the wiki maintenance volunteers. A well maintained, informative wiki will free up the time of Openmoko engineers to do what they need to do, instead of answering questions that are already answered in the wiki but simply can't be found. I should add that we are very much aware that many of you on this list already perform this task and already reduce our workload by helping and answering. The well maintained wiki will help free your time up, so you too can be doing more important things (like helping us?) rather than answering questions that are already answered. Along these lines I should mention that the testing, reporting, and bug filing that you are doing for OM 2008.8 is tremendously helpful. Please keep this up. An identified problem and a well defined, reproducible bug report saves so much time for the engineer assigned to fix it. Thank you. Finally, my primary job is to keep you all happy. If you have any complaints, questions, problems, suggestions, or other comments, please do write me, either on the list of privately. It is both my job and my personal wish to keep and to further strengthen an involved, active, enthusiastic, and productive community. I still believe that the most amazing devices have yet to be imagined, and are more likely to come from you than from us simply
Re: Terminal for ASU
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
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
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: Community contributions to core apps features. (Was: Terminal for ASU)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thanks for posting that link Rashat! I'm waiting for Stroller to get an answer too, but it's nice to know who to complain to about what after this :) ~ I want my KEYBOARD SWITCH back, I do! ~ Lisa -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFIjIa81sOMhsR36UsRAthKAJ4oMwaLF8ktJTOTN+N+4pg9D49mZQCgridn MR21pkary5efNvY+F5myvjU= =MAVw -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Terminal for ASU
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
Community contributions to core apps features. (Was: Terminal for ASU)
On 26 Jul 2008, at 03:10, steve wrote: Ask your questions stroller. I'll do my best to answer them. Hi Steve, Thanks for your reply. I've posted my questions - or rather a request for openness clarification - already in this thread. Because the background of the thread already contains all context you ought to need, it's difficult to know where to start asking you questions. Let me try. On 21 Jul 2008, at 19:47, Carsten Haitzler (The Rasterman) wrote: the problem is the designers decided that ASU is not to have any manual keyboard toggle button because it will disturb the design and/or confuse users, so all apps and toolkits need modification to talk a protocol to bring up the keyboard on demand (no manual controls). that is why you need to do this. personally i think you need a manual control because, as such, many apps and toolkits will not be changed, or they will get it wrong and give you a keyboard when you don't want one, or decide not to give you one when you do... but that's not my call. - Who are the designers who decided that ASU is not to have any manual keyboard toggle button because it will disturb the design and/ or confuse users please? Was this a group of Openmoko employees? Or a single individual at Openmoko? Does this person have a specified role managing the design of ASU? Who do users bitch to if they don't like design decisions? - How do you respond to Raster's suggestion that a manual override will be needed? - Is a complicated protocol to bring up the keyboard on demand - which each input method will need to be patched to support - *really* better than a simple button? - Will it be difficult to accommodate this protocol when porting an input method (Dasher, for instance) to Openmoko? Or will it be simple enough to do so that it easily justifies that lack of a manual keyboard button? No. Ignore those questions. This is only a small thing. I haven't followed the details of the problem closely - it was Raster's i wanted to do this this way, but i wasn't allowed to that surprised me - but it looks like the problems that this introduces aren't unmanageable. What is of more concern is the connotations of this decision. As far as we (end-users on -community) are able to determine, a feature was removed by the process of someone @openmoko saying I don't like that and emailing Raster (or IRCing him or walking into his office) and saying pull that without saying to the users hey, before we do this, are you using that feature? do *you* think it's ugly or confusing? Openmoko has always promoted itself as fully open - to quote Michael's words a couple of days ago: the goal of the project is not to create a new cellphone, but rather, that by being open, we allow and encourage innovation, and that by working with you, the open source community, we tap into a huge pool of imaginative, creative, very smart and hardworking innovators. I have always understood Openmoko's openness to encompass the *entire breadth* of Openmoko software development. It's great if we can write apps for the Freerunner, but I can already write apps for Symbian or Windows Mobile. It's great that I can fork the code Openmoko are writing commercially and make modifications to the application manager or the dialler but that's obviously a duplication of effort - I thought you wanted the community to help contribute to the core applications, too. Isn't this the case? Let's talk about the hypothetical community member Bob. Bob has a great idea a feature that he'd like to see on his mobile phone. Let's say he's meeting Charlie at cafe near the Linux convention and he thinks it'd be great if I could select Charlie in my phone's addressbook and - alongside 'call contact' and 'SMS contact' - it said 'Send my location'. I'd just click that and it could SMS my GPS location to Charlie and on Charlie's phone it would pop up a message 'Bob has sent you his location by SMS. Would you like to see where he is?' and then show a map with my location on it (or at least a needle showing distance and direction). Under a normal community development process Bob has some idea of whether or not other developers might like this idea. He can message them on IRC and say would you include that in the main tree? Bob can hack together a bit of code showing a working prototype and post patches to the mailing list knowing that the community will at least consider it. They might say cool idea, but no-one'll use it, so we don't want it in the core distro, they might say it needs a lot of polish, they might say add a configuration option to enable/disable it. But even if they ultimately reject it, Bob can submit his code with some idea of the shared goals of the other developers and knowing that the idea will be considered on the merits of whether the other developers think it's cool or not. I guess
Re: Community contributions to core apps features. (Was: Terminal for ASU)
On Sat, Jul 26, 2008 at 1:16 PM, Stroller [EMAIL PROTECTED]wrote: There's apparently no design document saying where ASU (or whatever) is going in terms of features. We don't know who to contact in order to get approval for our concepts before we waste a lot of time on them. I agree with your points and questions and am waiting for answers for Steve but have you seen this http://wiki.openmoko.org/wiki/ASU_Feature_Plan It is pretty easy to see the ASU features and who to contact. Rakshat ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Community contributions to core apps features. (Was: Terminal for ASU)
On 26 Jul 2008, at 09:46, rakshat hooja wrote: On Sat, Jul 26, 2008 at 1:16 PM, Stroller [EMAIL PROTECTED] wrote: There's apparently no design document saying where ASU (or whatever) is going in terms of features. We don't know who to contact in order to get approval for our concepts before we waste a lot of time on them. I agree with your points and questions and am waiting for answers for Steve but have you seen this http://wiki.openmoko.org/wiki/ASU_Feature_Plan It is pretty easy to see the ASU features and who to contact. Had I seen this? Absolutely not! And I do wish I had seen it before. I won't comment further at this time, but I'll amend the wiki later (cc'd to documentation as a reminder) so that some other relevant pages link to it it's easier to find. Stroller. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Community contributions to core apps features. (Was: Terminal for ASU)
2008/7/26 Stroller [EMAIL PROTECTED]: I won't comment further at this time, but I'll amend the wiki later (cc'd to documentation as a reminder) so that some other relevant pages link to it it's easier to find. It is already linked from the front page, but clearly from not those places it should be from :) But you have good points. Openmoko is open, but its development is not exposed in the open as much as I'd like for an open source project to be. The Openmoko folks are still a bit mysterious to me, with the exception of the few who regularly post on these mailing lists. I think the line between Openmoko employee and a contributing, trusted community member should be made more fuzzy. More SVN / GIT rights to the people, more contributing directly to http://svn.openmoko.org/ instead of just external projects at projects.openmoko.org etc. I would guess this is going to happen more with the development of FSO? -Timo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Community contributions to core apps features. (Was: Terminal for ASU)
It is already linked from the front page, but clearly from not those places it should be from :) But you have good points. Openmoko is open, but its development is not exposed in the open as much as I'd like for an open source project to be. The Openmoko folks are still a bit mysterious to me, with the exception of the few who regularly post on these mailing lists. I think the line between Openmoko employee and a contributing, trusted community member should be made more fuzzy. More SVN / GIT rights to the people, more contributing directly to http://svn.openmoko.org/ instead of just external projects at projects.openmoko.org etc. You are right but I think that the problem lies in the fact that Openmoko has not been able to provide any entry point where new people joining the list (after the release of the freerunner) can figure out who and where to ask what question. The Openmoko people are pretty open and if you will ask for something long enough you will get an answer/ access from them. MichaelShiloh of Openmoko used to interface with the community and answer their questions after getting the information from the developers in a regular community update. I think Steve and Michael still do that? Maybe we should have a page on the wiki describing who does what at Openmoko and who to address what question to and also an introductory email for new subscribers listing out similar things. It has been almost an year since I wrote my first email to Openmoko (actually to Sean to which Michael Shiloh replied) I can assure you that Openmoko people try their hardest to be open and responsive to community suggestions/ questions. But often it takes time for the question/ request to reach the correct person who can answer it / respond to it. Rakshat ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Community contributions to core apps features. (Was: Terminal for ASU)
rakshat hooja wrote: It is already linked from the front page, but clearly from not those places it should be from :) But you have good points. Openmoko is open, but its development is not exposed in the open as much as I'd like for an open source project to be. The Openmoko folks are still a bit mysterious to me, with the exception of the few who regularly post on these mailing lists. I think the line between Openmoko employee and a contributing, trusted community member should be made more fuzzy. More SVN / GIT rights to the people, more contributing directly to http://svn.openmoko.org/ instead of just external projects at projects.openmoko.org http://projects.openmoko.org etc. You are right but I think that the problem lies in the fact that Openmoko has not been able to provide any entry point where new people joining the list (after the release of the freerunner) can figure out who and where to ask what question. The Openmoko people are pretty open and if you will ask for something long enough you will get an answer/ access from them. Michael Shiloh of Openmoko used to interface with the community and answer their questions after getting the information from the developers in a regular community update. I think Steve and Michael still do that? Maybe we should have a page on the wiki describing who does what at Openmoko and who to address what question to and also an introductory email for new subscribers listing out similar things. It has been almost an year since I wrote my first email to Openmoko (actually to Sean to which Michael Shiloh replied) I can assure you that Openmoko people try their hardest to be open and responsive to community suggestions/ questions. But often it takes time for the question/ request to reach the correct person who can answer it / respond to it. Rakshat ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community This seems trivial but I think it is important. Even though open-source communities often strive to be non-heirarchical it is important that there be project leaders and that the people involved with development know these people and what their roles are. If you've just come on board (like I have) you could almost be forgiven for thinking that the Openmoko project is a loose-knit group of enthusiasts casually meandering from one platform to the next with no real direction for the past 12 months, and I think at least having a visible core team who send community updates on a regular basis is a step towards getting everyone singing from the same hymn sheet. These and other such details need to be prominently displayed on the wiki. I guess the core aim of Openmoko is to liberate the mobile platform and put technology back in the hands of the end-user through open-source software, however people are only going to get on board if it works. I have to say that I am left slightly underwhelmed after a couple of days with my FreeRunner - as a development platform it is brilliant and the geek in me certainly doesn't regret the purchase, however it is frustrating that after a years worth of open development I am still unable to use it as my primary phone (purportedly the main purpose of the device) due to hardware and software issues. Remember that Linux is set to capture the mobile market in a seriously big way over the next few years so we are far from the only ones doing this, and I think that if Openmoko is to remain competitive rather than be relegated to a hobbyist device then progress needs to be made in leaps and bounds rather than dribs and drabs, at least in the usability department. Perhaps a little cohesion would be a step in the right direction. Hopefully this is seen as constructive and not a whiny rant - I figure that this mailing list is intended for this type of discussion? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Community contributions to core apps features. (Was: Terminal for ASU)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This problem is common to all the process / firms: who must to take the important design decision? There can be two possibility: A) Who code B) Who doesn't code but can have a global vision of the project To choose between these two alternatives is not easy. Who code know well how it run, what the hardware can do. Who don't code, may have a global vision of the project, he know which are the objectives, deadlines, etc. etc. I am a programmer: when I receive a work I receive the specification and I must follow it. It happen that from time to time I think: but this is a stupid request / non sense. But I have to follow. According me the best solution is a between A and B. B know where to go, and A know which is the better way of to take it. So, on openmoko will be a very nice thing that on the morning they get a very good coffe in a table and A and B, because A can do nothing without B and B can do nothing without A. Then there is the thirth element C) The end users The end user are who in the end will pay and will use the phone. Their request are important but there are two big problems: 1) Often C don't know how it is running 2) All C's have different needs and different wishes. Is impossible to have all the persons happy. An example GTA3 must to have a camera? For me is NO, for another person may be the same, but for another is very important to get it. Who must to win? So I think decisions must be taken by A union B reading from time to time also what say C. A opensource project / phone DOESN'T mean a democratic process. In a future I hope that some persons will start to build a S.O. for Openmoko but driven by a different organization. This will let Openmoko to put all his resourses on the hardware part, while the SOFTWARE part is managed my another organization (Like it happen now with PC and OS) But in every case, it is only a my idea :) Regards Michele Renda -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiLGOEACgkQSIAU/I6SkT1xqQCghYBc12Os3BsskIRYxw3nyKRc HuUAoIgu5kqrzuS1JfPV0pJjo+Ih5f0l =78YY -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Terminal for ASU
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
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
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
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
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
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
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
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
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
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
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
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)
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
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
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)
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
*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
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
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
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
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
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
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
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
Terminal for ASU
Is it just my inability to find things or is there truly no terminal application for ASU in the standard repositories? Does anybody have any recommendations for a terminal for ASU? I tried to get openmoko-terminal2 to run but it crashes every time. Cheer Scott Petersen ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Terminal for ASU
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
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
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
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
