Cursor should hide in handheld mode

[Eben]

The spec for handheld mode explicitly states that we don't want the cursor. It both removes the distraction (and prevents it from sitting in front of text if you didn't remember to move it out of the way before entering handheld mode, which is silly), and prevents it from implying that there is a way to move it in via the game keys. This should be a Sugar level override.

I assume this is a relatively easy thing to fix, and whatever the case, we should do this ASAP. This ticket is referenced by #2613 and #2770 as well.

[marco]

Hmmm doesn't feel like a trivial fix actually, at least at the Sugar level. Each window in X has is own cursor (or inherits the parent one). You make the cursor invisible by setting an empty one.

Random ideas:

• Use XGrabPointer to completely override the window cursors. (really worried about possible side effects).
• Create a completely invisible cursor theme and switch to it in handleheld mode.

[Eben]

This needs a bump. We haven't had time to implement handheld mode, but there are a few details we could get right to make the experience much better in the default case, and this is one of them.

There is no way (nor should there be, as it's not user friendly at all) to move the cursor via the handheld buttons. As such, there is no need for the cursor. Moreover, in most of the activities we want to highlight (Read, Browse) the cursor simply gets in the way of the content. Unless one remembers to "push it aside" before switching modes, it's stuck there.

Making the cursor hide automatically in this mode will both prevent the aforementioned in-the-way cursor, and it will also remove any temptation there may be to try to navigate via the cursor while in this mode. Can we get some hard feedback on how much work this would be?

[Eben]

This isn't an enhancement! This is an outright problem with the functionality of handheld mode. You can move the cursor. You can't see through the cursor. This is a bug which impedes usability.

[jg]

And we don't have handheld mode....

[Eben]

My argument here is that Browse and Read (particularly the latter) would both be nearly usable if we got rid of the toolbars, hid the cursor, and allowed screen rotation. Even without fancy controls, scrolling around in a nice fullscreen view could give us something that purports to be handheld mode until we have time to devote here.

From what I gather, hiding cursors and hiding toolboxes are both simple to do.

[mtd]

patch to hide cursor and toolbox when ebook switch is activated

[mtd]

I've attached a patch to do what I think was wanted for all activities. I started out just patching Read but it was trivial to do all activities. I tried a few like Terminal, Browse, EToys, Journal, and Record and the seemed either to do the right thing (most) or ignore the fullscreen request (EToys, Journal, Record).

Just wanted to scratch an itch with this, but if anyone sees this could be polished into something usable please let me know what should be done...

[marco]

I think this should really be handled at X level, so that activities will not have to bother about it. There is a little application which does this in Debian, looks like an evil hack but if it works it could be fine on the short time...

http://packages.debian.org/unstable/x11/unclutter

[marco]

Hrm unclutter is polling the mouse apparently... that's clearly not good enough.

[marco]

If we want to do this only for ebook mode, probably the input-only window approach of unclutter would work. i.e. create a 1x1 window in a screen corner and warp the pointer over it.

[tomeu]

This can be viewed as an improvement to the attached patch, right?

[mtd]

Sure, it'd be an easy enhancement, IIUC. You just want the additional two steps 1d) and 2d) below:

1a) normal mode; each activity connect()ed to ebook switch HAL signal 1b) ebook switch hal event happens 1c) active activity fullscreen()s itself 1d) set cursor to invisible xpm 1e) create 1x1 gtk.Window at xmax-2, ymax-2 1f) warp pointer to xmax-2, ymax-2

...time passes...

2a) ebook switch hal event happens 2b) active activity unfullscreen()s itself 2c) warp pointer to original location 2d) destroy 1x1 gtk.Window 2f) set cursor to original xpm

Do you think it's worth creating that 1x1 window at all? I can imagine it's good insurance against enter()/leave()ing any widgets in the activity, but I'm not sure what window hints I should declare on it, or what its parent should be, or anything. Any tips would be appreciated. I'll have a go tomorrow GMT morning.

Martin

PS - (yes, I know, I just wrote about 5x as many lines of text as lines of code your suggestion would probably take :)) PPS - re: unclutter: <shrug>. For the short term, my patch is available now, too :). Before I pared this patch down I had the whole hide-on-certain-keys (think PgUp, PgDn, etc.) and unhide-on-mouse/keyboard/etc. coded, with the only problem being it was about 1/3 more lines and I got lots of seemingly-spurious POINTER_MOVE events from Read's ScrolledWindow...so I omitted that code from the patch. 1/3 more lines, almost all isolated in cursor.py, not in the/each activity.py, and where original LOC =~ 200, seems a good tradeoff rather than another process and memory/packaging/security burden. Of course if the problem was totally solved in the way you wanted it, then sure (why should olpc maintain more code?). Anyway I'll stop talking and look forward to feedback and incorporating your suggestion. PPS - alright, I couldn't resist scanning unclutter.c before hitting the submit button. Boy, it's got a lot more to worry about than an activity does because it tries to disturb the current window & window manager. One low-level advantage my patch has is that as it's activity.py kicking all this off, it's easy (to add the ability) for each activity to disable/control this behavior if required, but the normal case (hide cursor) is handled most naturally. Another advantage I/we have is we don't have to tip-toe around any window manager bar matchbox :).

[mtd]

Sorry, it's step 1e) that's new, not 1d, and of course "tries to disturb" in my third-to-last sentence was meant to be "tries not to disturb".

[marco]

The 1x1 window idea was to avoid implementing it in each activity (consider that activity.py is something that only python activities will use). Note that I didn't think very deeply about it so there might be problems about that approach.

It would be great if you could join freenode #sugar tomorrow morning, we can discuss this and see what's the best solution.

[mtd]

Oh, of course. I see your point. There go all my advantages of doing it in python...will join #sugar.

[mtd]

Sorry for the delay in getting on #sugar. I've been lurking there and #olpc-devel and #olpc now, though, so it should be easy enough to reach me.

I'm wondering how we might get something quickly: at one point the immediate priority was just to hide the cursor in Read & Browse. My patch does this, and all python activities. I could also change the patch so that it *just* patched Read & Browse, if that was more desirable (though it'd dupe a few lines of code that now goes into their python activity superclass).

I'm interested in the (completely technically different) ways we could support this feature in non-python activites, though as far as my personal experience/skills it'd probably be more than a few hours of work.

[mtd]

Thought about this a tiny bit (perhaps not enough) more, and:

1) if we want Sugar to hide the cursor for all activities by default, the sugar shell/etc. could listen (small change to my patch, IIUC) for the ebook switch hal event rather than (each) activity, and we'd need to expose a way for activities to disable this behavior;

2) is 1) really desirable? Maybe I should just change my patch to patch Read and Browse with this behavior (very little duplicate code, all things considered).

I might submit a patch a la #2 if I don't remember to ask marco for his opinion on IRC next time I see him there.

xelapond, any thoughts?

[Eben]

I do think that (1) is truly desirable. The fact remains that, in order to use the cursor in handheld mode, an activity has to explicitly write code to handle that form of input. As such, I'd expect any activity that wishes to do so to also explicitly ask, in some fashion, to make the cursor visible.

I don't have input on whether or not this should be done in the shell or the activity class; whatever makes the API cleaner.

[mtd]

I guess so, but I just don't see too many activities jumping to use the functionality, and it'll take a lot longer to agree/implement the API changes (for disabling) than getting all python apps or Read & Browse working.

But maybe I can be proved wrong about that (how long it'll take).

[Eben]

Is it possible to get this into 8.2? I recall marco mentioning that the API changes might be too extreme, but from what I understand the only place the new API is used is within the activity base class, which activities would get for free anyway.