On 5/23/10, Visti Andresen <[email protected]> wrote: > On Sun, 23 May 2010 10:55:46 +0200 (CEST) > David Kozub <[email protected]> wrote: > >> On Sun, 23 May 2010, Sybren A. Stüvel wrote: >> >> > One nag about the message: it doesn't tell you how to solve the >> > issue. So a regular user may just as well not see anything, as this >> > will tell them very little. I believe there is a DBUS call that can >> > re-enable the GSM, maybe offer to call that? Or suggest a reboot? >> >> You're right. But my patch is not about this specific feature, it's >> about adding a message box (inwin in fact) for error replies from >> (mostly) the FSO and it's used in more places throughout the >> liphone-ui-shr. It's supposed to be an improvement over "nothing >> happens" (as perceived by the user) to "at least an error is >> displayed". >> >> Remedying the situation or offering relevant tips would have to be >> per-case and while it would be cool, it sounds quite complex. > > And if the system knows the fix, then why not just fix the problem > instead? > Ok reboots may be somewhat extreme... > > The watchdog system in my Nokia 770 did restart the tablet from time > to time, until they got rid of some bugs and/or I added some swap > space(low mem also tripped it). > I believe the rationale were "We would rather have an extra reboot than > a stuck end-user" > > But any way, messages that informs me that things has broken down are > preferred to no information at all. > >> >> Regards, >> >> David > _______________________________________________ > Shr-devel mailing list > [email protected] > http://lists.shr-project.org/mailman/listinfo/shr-devel >
But I would rather have stucked me than extra reboot :P Let's make everything stable first, and such messages as from screen are perfect for that (I've implemented the same thing in opimd-utils ages ago and suggested this way of error handling i n SHR, so i'm happy someone did implement it :) We don't need more complex error handling yet, and we definitely don't want automatic error solving at this stage. -- Sebastian Krzyszkowiak dos _______________________________________________ Shr-devel mailing list [email protected] http://lists.shr-project.org/mailman/listinfo/shr-devel
