Re: [Debian/FSO] openmoko-panel-plugin: inflexibility in events processing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi paul, Am 23.11.2008 um 09:50 schrieb Paul Fertser: Hello everybody! [..] Ok, now to the topic: The default installation of fso-frameworkd provides quite sensible rules.yaml, that can be customized to one's needs. By default it suspends the system on short power button press. But openmoko-panel-plugin wants to show a menu on the same event. Doesn't make sense to me ;) Moreover, the problem is that the only way to disable the menu i found is to modify the source. Not quite cool. I think that handling (i.e. performing actions) events is not a job a panel-plugin should do at all. We already have oeventsd, which is flexible enough, i think. Moreover the menu presented doesn't make sense. "apm -s" is not what i want to perform for suspending (appropriate dbus method is). And "sudo shutdown ..." is not very useful in the absence of sudo (i don't mind running as root... yet). The other problem is the virtual keyboard handling. Again, i don't think it's appropriate for a panel-plugin to react on a button for showing keyboard. And it's not configurable. Imagine i want to use two keyboards with different layout concurrently for some time. I need to customize the pkill command to close only one keyboard, not both. And then i need another button for another action. And so on. What do you think about it? first: if you don't like it, just don't use it .. ;) if you don't want panel-plugin to react on the hardware-buttons, you could edit /etc/panel-plugin.conf and remove the entry 'buttons' from the 'plugins'-line in '[main]' same with the keyboard-launcher or simply do the same via the config- panels .. i am working on more flexibility / configurability for the future but as i (and also sebastian) don't do this as a full-time-job, it needs some time .. ;) you also could edit the frameworkd-rules-file and disable the action for power-button (i did it this way as i want to have more options than suspending on pressing the powerbutton) ciao christian (morlac) adams - -- - -BEGIN CONTACT BLOCK- eMail:[EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] - --END CONTACT BLOCK-- - -BEGIN GEEK CODE BLOCK- Version: 3.1 GCS$/IT;d-;s:;a?;C++(+++)>;UL;P++(+++)>; L++(+++);E---;W++;N(+);o?;K?;!w;!O;!M+>;!V;PS(+);PE; Y+;PGP++;t+(++);5(+)>++;X(+);R*;tv->+;b++(+++);DI++; D++(+++)>;G(+)>++;e+>+++;h-()>++;r++;y++; - --END GEEK CODE BLOCK-- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iD8DBQFJKV1Er81gVylJyzERAhPYAKCinlRGDI1Pjbkc6zPGc+1dJ+WacACgnI0o XqeW6AXyKt0MCqbSBbodLTQ= =NZ7G -END PGP SIGNATURE- ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Re: [Debian/FSO] openmoko-panel-plugin: inflexibility in events processing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 23.11.2008 um 15:21 schrieb Paul Fertser: Hi, Christian Adams <[EMAIL PROTECTED]> writes: first: if you don't like it, just don't use it .. ;) But i do like it. And i like to see improvements going in the right direction ;) if you don't want panel-plugin to react on the hardware-buttons, you could edit /etc/panel-plugin.conf and remove the entry 'buttons' from the 'plugins'-line in '[main]' Oh yes, now i see it. I don't do python yet, so i missed it while i was reading the source. But it seems i don't have an option of enabling just AUX button. will add a config-option to en-/disable (re)action on power-/aux-button Ok, so it can be configured. But FSO reacts on the power button by default and o-p-p reacts by default. Something should be changed to stop confusing the users (i.e. me ;) ). May be you can add an oeventsd disabler (just for the buttons) to the post-inst script or something if you insist on enabling "buttons" by default. Moreover, your suspend action is wrong/inaccurate anyway -- apm was deprecated ages ago. You integrate with FSO anyway, so i suppose you'd better use its suspend method. in actual svn this has been addressed some time ago .. i am working on more flexibility / configurability for the future but as i (and also sebastian) don't do this as a full-time-job, it needs some time .. ;) Thank you very much for doing it! :) you also could edit the frameworkd-rules-file and disable the action for power-button (i did it this way as i want to have more options than suspending on pressing the powerbutton) Yes, but to do that one needs to find out about that events configuration file, etc. It should be written somewhere on the wiki, but i have no idea where... Moreover, if i needed a menu, i'd prefer writing a small xdialog script and have more flexible control over quantity of possible options, menu hierarchy, etc. this would be a future config-option to choose whether you would like to open the menu brought by panel-plugin or launch something different .. ciao christian (morlac) adams - -- - -BEGIN CONTACT BLOCK- eMail:[EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] - --END CONTACT BLOCK-- - -BEGIN GEEK CODE BLOCK- Version: 3.1 GCS$/IT;d-;s:;a?;C++(+++)>;UL;P++(+++)>; L++(+++);E---;W++;N(+);o?;K?;!w;!O;!M+>;!V;PS(+);PE; Y+;PGP++;t+(++);5(+)>++;X(+);R*;tv->+;b++(+++);DI++; D++(+++)>;G(+)>++;e+>+++;h-()>++;r++;y++; - --END GEEK CODE BLOCK-- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iD8DBQFJKWkPr81gVylJyzERAgjiAKCNG6MEcOORFLwT8I+RKw2BCfm7+wCfaLtm AByg887nnmdWnMxOGcXPBmM= =m/Jb -END PGP SIGNATURE- ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Re: [Debian/FSO] openmoko-panel-plugin: inflexibility in events processing
Christian Adams wrote: > if you don't want panel-plugin to react on the hardware-buttons, you > could edit /etc/panel-plugin.conf and remove the entry 'buttons' from > the 'plugins'-line in '[main]' > same with the keyboard-launcher or simply do the same via the > config-panels .. I use the current panel-plugin version but i don't have any /etc/panel-plugin.conf file. Do i have to create it by hand or should it be in the openmoko-panel-plugin package? Ciao, Rainer ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Re: [Debian/FSO] openmoko-panel-plugin: inflexibility in events processing
Hi, On Sun, 2008-11-23 at 17:40 +0100, Fox Mulder wrote: > I use the current panel-plugin version but i don't have any > /etc/panel-plugin.conf file. Do i have to create it by hand or should it > be in the openmoko-panel-plugin package? that depends on what you wanne do. if you want to do a systemwide configuration, you should create the file by hand. if you want a user only configuration, you can use the config menu and you will find the config in ~/.panelpluginrc (hope i spelled it right). You also can create your config and then copy it to /etc, so you don't need you editor. cu sebastian ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Re: [Debian/FSO] openmoko-panel-plugin: inflexibility in events processing
Hi, On Sun, 2008-11-23 at 14:40 +0100, Christian Adams wrote: > > What do you think about it? > first: if you don't like it, just don't use it .. ;) second: everyone who want's to used the software should do it! And we are always open for suggestions or patches to improve it! (the "first" sounded so hard) > i am working on more flexibility / configurability for the future but > as i (and also sebastian) don't do this as a full-time-job, it needs > some time .. ;) the next version of the panel will contain a plugin system to reduce the needed memory. but it can also be used to remove features(i.e. the buttons handling). the discussions on button handling is always the same. everyone wants to use them. an if someone uses them someone comes and says: i want to do a diffetent thing with it. i, for my case, are happy with the handling as it is. i don't understand you problem with the keyboard in your mail. can you explain it a little bit in a concrete usecase? maybe we find a solution to fit all our needs. greetings sebastian ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Re: [Debian/FSO] openmoko-panel-plugin: inflexibility in events processing
Hi, On Sun, 2008-11-23 at 20:31 +0300, Paul Fertser wrote: > Hi, > > Sebastian Ohl <[EMAIL PROTECTED]> writes: > >> first: if you don't like it, just don't use it .. ;) > > second: everyone who want's to used the software should do it! And we > > are always open for suggestions or patches to improve it! (the "first" > > sounded so hard) > > So, my suggestion is: if you don't like the default FSO rules file > (i.e. buttons handling and brightness handling) you should disable it > on installation or (imo better) you should ask the user whether he > prefers handling by oeventsd or by o-p-p. > > [snip] > > it is. i don't understand you problem with the keyboard in your > > mail. > > I wanted to type some russian so i had to start another instance of > matchbox-keyboard with ru layout. So i did. But then pressing the > keyboard button killed the keyboard instead of opening another one > with english layout. It seems it can be useful to sometimes have two > keyboards opened at once. So, it wasn't a real problem, but rather an > illustration to why i think that panel-plugin shouldn't be a launcher. yes i see your problem. calling the keyboard via a shell is not the best solution. when i wrote this code, i was very new to python, so it was the easiest thing to do. the right one is to do a fork and then an exec. so we would only kill the binary that has been started by the panel. i hope i'll find time to alter this piece of code. but our first concern is the conversion to a plugin architecture. btw: please respond to the list not to me in person(i quoted your complete message to inform the others). regards sebastian ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Re: [Debian/FSO] openmoko-panel-plugin: inflexibility in events processing
Hi, Sebastian Ohl <[EMAIL PROTECTED]> writes: [snip] > hope i'll find time to alter this piece of code. but our first concern > is the conversion to a plugin architecture. And btw, i have seen some stability problem: after some time idling or after suspending or whatever (couldn't reproduce it reliably, sorry) o-p-p silently quits. No traceback, no coredump, nothing. I tried to add a tracing but i couldn't trigger the bug yet. Is it also a known problem fixed in SVN? ;) > btw: please respond to the list not to me in person(i quoted your > complete message to inform the others). Yes, i understood i made the wrong move right after my sendmail successfully cleared the queue. I'm new to Gnus, sorry ;) -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:[EMAIL PROTECTED] ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Re: [Debian/FSO] openmoko-panel-plugin: inflexibility in events processing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sebastian Ohl wrote: > Hi, > On Sun, 2008-11-23 at 14:40 +0100, Christian Adams wrote: >>> What do you think about it? >> first: if you don't like it, just don't use it .. ;) > second: everyone who want's to used the software should do it! And we > are always open for suggestions or patches to improve it! (the "first" > sounded so hard) > >> i am working on more flexibility / configurability for the future but >> as i (and also sebastian) don't do this as a full-time-job, it needs >> some time .. ;) > the next version of the panel will contain a plugin system to reduce the > needed memory. but it can also be used to remove features(i.e. the > buttons handling). > > the discussions on button handling is always the same. everyone wants to > use them. an if someone uses them someone comes and says: i want to do a > diffetent thing with it. i, for my case, are happy with the handling as > it is. i don't understand you problem with the keyboard in your mail. > can you explain it a little bit in a concrete usecase? maybe we find a > solution to fit all our needs. > The fact that things are totally configurable is great for the geek user, but I think if this is ever going to be of use to the wider public, and the grannies out there, we need a good default solution. I'm using ms4 and if I was a granny and hit a power button I'd think I just switched off the phone, not suspend. If I hit it again I'd think that I'd powered it on again, not resume. imho the power button should always do the same thing on a device and in the case of a phone it should bring up a menu of things power related by default. Switch off, Suspend, Switch off screen. I don't like the idea that the power button should can be reconfigured by applications. It's great that it can be done but I don't think the average user would expect to find what their looking for under the power button. I'd certainly never hit the power button on any other device and expect anything other then power related options. Having said that I'd a Nokia phone that used to allow you to select profiles under the power button. That's a short cut that I'm happy enough with as it was always in the same place and a nice short cut. Still it was consistent. Anyhow just my humble opinion. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJLGcWXlbjSJ5n4BARAqydAJ4jyxw/p5TmZRXctJ4EkF4/BxKP/gCg0Iju HWMCMIdHcSZ0zhkcTdbPp3I= =5/WO -END PGP SIGNATURE- ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Re: [Debian/FSO] openmoko-panel-plugin: inflexibility in events processing
using ms4 and if I was a granny and hit a power button I'd think I just switched off the phone, not suspend. If I hit it again I'd think that I'd powered it on again, not resume. a "grannie" would be able to kill herself with a spoon ... everything above a kitchen knive requires understanding how the device works, which means reading soem kind of documentation before use -- if the device does not work as expected, it's usually a matter of pebkac. especially for a device with so limited a number of physical input elements it should be perfectly clear to any user that the two buttons have more than a simple on/off function but a broad number depending upon the situation. it might be an option (as usual) to make the behaviour of the pwr button configurable: a) do only on/off b) do suspend/resume and on/off c) expose a menu to select the desired action a) would be for what you call "grannies" b) for those preferring fast and minmal inavise action c) for the rest focusing solely on the (imho hardly likely) group of "grannies" would ostracize the number of users willing to use and looking for a more advanced device not tied up in the conventional paradigms of user interaction. building smartphones for "grannies" is a task a lot of companies aspire -- and i doupt openmoko would be able to survive! have a look at palm: they basically abandoned palmos in favour of wince -- and their phones a re to expansive and too bad to cope with stuff from htc or so, they left their niche and found no other ... ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Re: [Debian/FSO] openmoko-panel-plugin: inflexibility in events processing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 arne anka wrote: >> using ms4 and if I was a granny and hit a power button I'd think I just >> switched off the phone, not suspend. If I hit it again I'd think that >> I'd powered it on again, not resume. > > a "grannie" would be able to kill herself with a spoon ... > everything above a kitchen knive requires understanding how the device > works, which means reading soem kind of documentation before use -- if > the device does not work as expected, it's usually a matter of pebkac. > especially for a device with so limited a number of physical input > elements it should be perfectly clear to any user that the two buttons > have more than a simple on/off function but a broad number depending > upon the situation. > > it might be an option (as usual) to make the behaviour of the pwr button > configurable: > a) do only on/off > b) do suspend/resume and on/off > c) expose a menu to select the desired action > > a) would be for what you call "grannies" > b) for those preferring fast and minmal inavise action > c) for the rest > > focusing solely on the (imho hardly likely) group of "grannies" would > ostracize the number of users willing to use and looking for a more > advanced device not tied up in the conventional paradigms of user > interaction. > building smartphones for "grannies" is a task a lot of companies aspire > -- and i doupt openmoko would be able to survive! > have a look at palm: they basically abandoned palmos in favour of wince > -- and their phones a re to expansive and too bad to cope with stuff > from htc or so, they left their niche and found no other ... > Cheers for that you made me laugh with the grannies with spoons comment ;-) I sort of disagree with you. People do not read the manual when they get a device. They try to use it and if they have to resort to the manual the designer has failed. I can't remember the last time I read the manual for a phone, camera, DVD player. Devices performing everyday things like a mobile phone in the 21t century should be as close to intuitive as makes no difference. No offence to anybody on this list but like a lot of you I'm happy enough with the command line for a lot of stuff and that's maybe why we're not that good at usability. I'm not suggesting that we get "tied up the conventional paradigms of user interactions" but just a bit of usability. I think even a granny given an iPod for the first time would have a fairly good stab at playing some music. Obviously getting music into it would be a stretch. I also don't think that OpenMoko should even attempt to give use smart phones for grannies. They should give us a hardware platform and let us, the community, do the rest. Look at the xBox media centre for the original xBox built by a community, as far as I know, and a really good usable piece of Software IMHO. At the end of the day I'm still amazed that I've got an open platform. When my capable laptop for programming arrives and I get some time I'm going to have a menu on the power button ;-) Thanks again for the laugh. Grannies with spoons -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJLb++XlbjSJ5n4BARAnw3AJ9+4rcX4UZPK4e9CoMaGCnUhkS/zgCdFqEZ na7pfezQmbfeQ1Up2yKrIFg= =bW5x -END PGP SIGNATURE- ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Re: [Debian/FSO] openmoko-panel-plugin: inflexibility in events processing
Hi, Arigead <[EMAIL PROTECTED]> writes: > I think even a granny given an iPod for the first time would > have a fairly good stab at playing some music. Last time i had an iPod in my hands, i found the interface rather unintuitive, limiting and confusing. I can't imagine how that can be good for anybody. What i'd like for an interface is just some consistency on default installation and an ability to change anything later. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:[EMAIL PROTECTED] ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Re: [Debian/FSO] openmoko-panel-plugin: inflexibility in events processing
I sort of disagree with you. People do not read the manual when they get a device. They try to use it and if they have to resort to the manual the designer has failed. with so complex a device the freerunner is, it is bound to require some studying before being able to use it fully. things like a mobile phone in the 21t century should be as close to intuitive as makes no difference. and that's, i think, is the core problem: the freerunner is no mobile phone! it does not simply do calls and sms. it's a full fledged computer which allows even for phone functionality. and for intuitivity: why has mcdonalds in the us of a to print "caution! hot!" on it's coffee cups? who expects cold coffee in a newly purchased coffee mug? why has a microwave to say "don't put pets in here!"? intuitive means basically nothing else than: meet the user's expectations -- and those users are trained by other paradigms already. the "start" button of windows 95 needed user training (who'd guess "start" means shutdown?) and still there's a popup on hover telling you, what's the meaning of so integral a part of the windows gui -- after about 12 years! ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
