On Tue, Dec 15, 2009 at 11:58 AM, Arie Skliarouk <sklia...@gmail.com> wrote:
> Hi, > > I will try to answer in one letter both to Tom and Al, and would add couple > more items - see below: > > I am using > > uImage-2.6.29-oe11+gitr119861+b90406de472c1aa5371ab593a2bb79136d5de658-r6-om-gta02.bin > shr-full-eglibc-ipk--20091204-om-gta02.rootfs.jffs2 > > Not upgraded. BTW, I tried to ssh into the device with empty password but > it would simple would not let me in. Only when I manually run "passwd" in > terminal and put single letter as a password, it allowed me to login. > As /etc/ssh/sshd_config assumes "PermitEmptyPasswords no", it is mandatory > to set password for root. Not a big deal, but should be mentioned in the > documentation: http://wiki.openmoko.org/wiki/SHR_User_Manual > > IMHO, the welcome screen for the phone should either include link to the > manual on the internet or to have "README" in it. > It's not mentioned in the docs because it's rather new, but it is mentioned in the first boot wizard IIRC. anyhow, please add it to the manual. > > > Power also brings up the menu to let you suspend or shut down. >> > Aux toggles the screen lock. I find this very useful when pocketing the >> phone >> while still powered, as when recording gps tracklogs. >> > > On Android, pressing Power for a second suspends the phone as well. > Pressing for 3 seconds opens a menu allowing to shutdown the phone. > I agree with this behavior, actually, there's work being done to do something similar. > > "Screen locking while phone is suspended" is such a rare operation that it > looks unrational to use whole HW button just for that. The OS must allow > scenario when application can request continue running even if the user > "suspended" the phone. This is done nicely in android. > There is such a thing, it's in fso's request CPU resource. > I don't want to start POV fights, just want to note, that Google have > poured a lot of money into designing android look and feel, so it should not > be a shame to borrow from them an idea or two. > I agree, I just don't think you know enough about shr as you mention stuff that already exist. > > Most apps don't have one to invoke, or have it present all the time. More >> seriously we don't have any consistent application style rules. This is >> partly because many of the apps are generic linux apps that happen to be >> usable (just >> about) on a 480x640 screen. >> > > This is the point that one must admit that phone UI is different from > desktop UI. The fact that SHR does not have any UI guidelines speaks for > itself. > That is a problem, I don't know if I opened a ticket about it, but I definitely talked about it in both ML and IRC that we need UI guidelines. Our story is different than google's though, as you can run every linux app on SHR, even ones that were written before our (non existent yet) guidlines. That's both a power and a weakness. > > > * Default suspend time is very short - mere 15 seconds >>> >> You can change that in config, the default is *not* 15 seconds though. >> it's more like 60 (which is too long in my pov) you probably consider screen >> blanking as suspend. >> > > Could well be. > > >> * The AUX(Back) and Power(Menu) buttons are *very* intuitive on android. >>> They are almost not used in SHR: >>> >> That's what you get when you use specifically designed software, we use >> mostly regular linux apps, which means we don't have apps that respect >> special keys for menus. >> > > Exactly. See my list of recommendations for SHR at the end. > You suggest we should rewrite all the linux apps in the world? > > >> * numpty once locked up hard, so I could not kill it. Software power off >>> did not work either... Had to remove the battery. >>> >> kill -9 ? >> > > No, this answer is not acceptable. You can't ask users to do kill -9. SHR > must be smart enough to kill the application no matter what. Android does it > right by detecting unresponsive application automatically and offering to > kill it - without user intervention whatsoever! > Of course I don't expect the users to open a terminal, I just asked if that works, as you said you had to remove the battery. > > You are free to ignore that if you want the SHR to remain OS for the > ever-shrinking already-tiny market of FR phones. > Don't act like you know everything, listening or not listening to your advices will not change the fate of SHR. You might have good ideas (I'll respond to them in a sec) but that still doesn't mean your opinion is the only one that matters. To be frank and straightforward (since you acted the same, in a blunt way if I may add), I must say you didn't suggest anything new, yes we know that developing all the applications in the world from scratch to suit the screen size and hardware and to make them follow our guidelines is the correct thing to do (some may argue about that, but having a consistent UI is a good idea anyway), but unfortunately, we are not an army of 10k people, we are just ~3 active developers, and only 2 of us (1.75 actually) work on the UI. So although there are many things that are might be a good thing to add, you have to remember we are an open source software project, which means we have to do what we can with our *free time*. We can't do everything, and we can't make it perfect without help. Even Ubuntu which is a well financed project suffers from UI inconsistency even though they have strict guidelines and a bunch of developers and money, It's just not possible to rewrite firefox/openoffice/etc to conform to their guidelines, not having a fully consistent UI is a minor inconvenience comparing to the features we can (and do) produce in the time it would have taken us to do what you ask for. > > Before we continue with this thread, I would like to do a small poll: > Please write here what you see as advantages of SHR distro against android > system. > Without starting the flame war you are trying to start, and without enumerating the almost infinite advantages I have, I'll just sum it up in one sentence: "Free, open and Linux" That's the biggest advantage. > > -- > Arie > > Please try not to be a cocky ass in your next e-mail. Yours, -- Tom.
_______________________________________________ Shr-User mailing list Shr-User@lists.shr-project.org http://lists.shr-project.org/mailman/listinfo/shr-user
