Reply
Thread Tools
brontide's Avatar
Posts: 868 | Thanked: 474 times | Joined on Oct 2007 @ Capital District, NY, USA
#51
Originally Posted by johnkzin View Post
2a) it'd be nice if RTCOMM had some visibility into, and integration with, the power management stuff. Don't power down if you're signed in. Don't fully shut off the screen if you're not AWAY (partially dim the screen: yes, fully blank the screen: no). Settings/options like that.
4) I can have chat logs that automatically get stored on the data device of my choice (removable card, internal card, somewhere under /home/user).

If those are do-able now, then great. Let me know, and I'll switch. But, from what I've heard whenever I've looked into switching, these are ways in which RTCOMM is not yet fully baked.
2a) You can already have the nokia not dim the screen when plugged in. not turning off the display when on battery would not be recommended as the battery would drain quickly. That said, I believe there is a gconf hack to add longer display timeouts

4) the problem is those other locations are unsafe to use for logs as they can dissapear at any time. A simple script could move/copy the logs when you want the on the external card.
 
johnkzin's Avatar
Posts: 1,878 | Thanked: 646 times | Joined on Sep 2007 @ San Jose, CA
#52
Originally Posted by brontide View Post
2a) You can already have the nokia not dim the screen when plugged in. not turning off the display when on battery would not be recommended as the battery would drain quickly. That said, I believe there is a gconf hack to add longer display timeouts
I'm aware of both of those, and neither is acceptable for what I was expressing. I'm not talking about only having the screen stay lit when I'm plugged in (and that feature is kind of odd anyway -- seems like some apps think the screen IS dim, like the status bar cpu/clock applet that stops showing the current time when it thinks the screen would be dim). I'm talking about not dimming the screen when I am signed in to a chat service (which is also not what the gconf hack does). As it is now, I have to keep tapping the screen to see if the other half of a conversation replied, and that ends up defeating any battery savings.

Further, I end up constantly tapping the screen anyway, so I'm not seeing any battery lifetime savings the way things are now. What I am seeing is: the annoyance of having to tap the screen in order to get instant feedback on the state of my chats. If the other side of the chat is semi-slow in responses, then I end up having to force the NIT to stay awake. No battery savings (and the lifetime is just fine; I do in fact see the battery indicators stated battery life of up to 7 hours when I start with a full charge)

I'm not saying that this should be set-in-stone. I'm saying this should be a selectable feature. RTCOMM is integrated into Maemo, so give it options that really leverage this fact. Maybe a "wake the screen when I receive an IM" or something. Just give me options that make the experience less annoying, and requires fewer pointless gestures just to keep my use of the device the way I want it.

To me, that means the following _OPTIONS_:

(signed in meaning "I'm on-line with at least one RTCOMM chat service")

- don't fully blank the screen if I'm signed in
- alert me (ask to confirm) if I try to shut down while signed in
- don't dim the screen if I'm signed in, and neither Away nor Idle
- un-dim/un-blank the screen if I receive a message, and the screen isn't locked

None of those having any dependency on whether or not I'm plugged in. Or maybe have options that vary with both "being signed in" and "being plugged in".

4) the problem is those other locations are unsafe to use for logs as they can dissapear at any time.
A well written application will deal with such unexpected events gracefully. Either by ranking the 3 storage locations, warning you that there's a problem, or falling back to a default location (or some amount of all 3).

A simple script could move/copy the logs when you want the on the external card.
I shouldn't have to work around/against a well written application. :-) Nor should I have to resort to hiding shell scripts behind the GUI for my GUI oriented apps.

Worst case, the app should do that for me:

- I tell it where I want the logs to end up.
- It dynamically writes them to the default location.
- It periodically copies them (without my having to initiate it) to the storage location I specified.
- Optionally, I can initiate that copy process, but that's not instead of the automated copy, that's just for when I want to force such an event.

Last edited by johnkzin; 2008-04-08 at 16:02.
 
sachin007's Avatar
Posts: 2,041 | Thanked: 1,066 times | Joined on Mar 2006 @ Houston
#53
Guys please please vote for contacts not responding bug... 3072.

https://bugs.maemo.org/show_bug.cgi?id=3072
 
brontide's Avatar
Posts: 868 | Thanked: 474 times | Joined on Oct 2007 @ Capital District, NY, USA
#54
Code:
gconftool-2 -s -t list --list-type=int /system/osso/dsm/display/possible_display_blank_timeouts "[30,60,120,300,xxxx]"
gconftool-2 -s -t list --list-type=int /system/osso/dsm/display/possible_display_dim_timeouts "[10,30,60,120,yyyy]"
As user change xxxx and yyyy and run. Display options will now contain additional dimming and off settings ( values are in seconds ). You can set this to be anything you choose. You can make it so your display, effectively, never turns off if you wish.
 
johnkzin's Avatar
Posts: 1,878 | Thanked: 646 times | Joined on Sep 2007 @ San Jose, CA
#55
Originally Posted by brontide View Post
Code:
gconftool-2 -s -t list --list-type=int /system/osso/dsm/display/possible_display_blank_timeouts "[30,60,120,300,xxxx]"
gconftool-2 -s -t list --list-type=int /system/osso/dsm/display/possible_display_dim_timeouts "[10,30,60,120,yyyy]"
As user change xxxx and yyyy and run. Display options will now contain additional dimming and off settings ( values are in seconds ). You can set this to be anything you choose. You can make it so your display, effectively, never turns off if you wish.

No offense, but ... can you read? If so, you should go back and RE-read what I wrote... because I'm pretty sure you didn't understand what I wrote even a slight little bit.

I already know how to make it so that it effectively NEVER dims/blanks. I even said I already know about that hack. That hack is NOT EVEN CLOSE to the feature I described.

What I have described is a desire for the application to inform the tablet about when is a good time to intelligently dim/blank or not. What you're talking about is almost entirely unrelated to that. It's not even a good hack for what I'm describing.
 
brontide's Avatar
Posts: 868 | Thanked: 474 times | Joined on Oct 2007 @ Capital District, NY, USA
#56
Don't get snippy at me, I didn't write it and Nokia hasn't seen fit to open it to developers.

Then I guess it's time to break out the compiler and take over the pidgin project. It shouldn't be too difficult to keep the display from blanking using a few dbus calls.

Have fun while you are at it.
 
johnkzin's Avatar
Posts: 1,878 | Thanked: 646 times | Joined on Sep 2007 @ San Jose, CA
#57
Originally Posted by brontide View Post
Don't get snippy at me, I didn't write it and Nokia hasn't seen fit to open it to developers.

Then I guess it's time to break out the compiler and take over the pidgin project. It shouldn't be too difficult to keep the display from blanking using a few dbus calls.

Have fun while you are at it.

Sorry, bad day here. But, you really did seem to ignore everything I said.
 

The Following User Says Thank You to johnkzin For This Useful Post:
brontide's Avatar
Posts: 868 | Thanked: 474 times | Joined on Oct 2007 @ Capital District, NY, USA
#58
Originally Posted by johnkzin View Post
Sorry, bad day here. But, you really did seem to ignore everything I said.
Reading on the small screen I sometimes miss items. I figured with you online all the time it would be a viable fix until something better could be developed.
 
Reply

Thread Tools

 
Forum Jump


All times are GMT. The time now is 09:54.