I think you misinterpret Sony's warning. Ironically I was looking at precisely that documentation this afternoon because I want to add full-screen support (and forms) to pilot-db, which I feel is a bit neglected recently but -could- be quite a tool. Sony strongly suggests the users be able to get back out of the mode, especially for input (graffiti), but I don't see anywhere that they state it shouldn't survive cross-form. To quote them,The trouble right now is, it doesn't REMEMBER the state either. Try this:
Open up a document. Turn on full-screen no status bar. Go to the
library (shortcut-U). Status bar is back. Return to the same document;
still got a status bar.
Sony recommends that no-status-bar should be only a temporary state, and hence this behavior. I can change the behavior if people prefer.
Alex
Since when the application drawing area is maximized the status bar area is hidden,
applications must offer to the user a way to return the drawing area to its previous state.
(This from the SilkLibResizeDispWin section.)
However, there is no restriction against starting the application with the minimized silk
screen area.
(From the intro)
In fairness, Sony's SilkSample never hides the status area. But also in fairness, the vast majority of the apps shipping with the UX50, including obvious ones such as Audio Player, SMS, Calc, Decuma, ClieMemo (the graphic one), RemoteCam, SoundUtl, etc. don't even support the minimized form, much less the full-screen form. So Sony is hardly a reasonable metric.
Meanwhile, ZLauncher on my system always hides the status bar, while PicSel, which also ships with the UX, violates pretty much every other UI rule (though not that one.)
My read of the docs isn't that changing forms (Sony's term for screens) must unhide the silk-screen area, but rather than there must be a way to get it back. Making it temporary on the application instance would do this, as would adding it to menu on the Library. Or having the Library clear it when the user resizes from the Library.
For example...
1. User is in Library, status on side
2. User goes to document, /t u twice to banish status
3. User returns to library which STILL has status on side, simply because it always does. (I can't make it go away at any rate.)
4. User clicks blue arrow twice, exposing graffiti and hiding it. Library resets status-display variable.
5. User goes to document... status is there
Versus
1. User is in Library, status on side
2. User goes to document, /t u twice to banish status
3. User returns to library which STILL has status on side, simply because it always does. (I can't make it go away at any rate.)
5. User goes to document... status is gone.
That's my suggestion for meeting Sony's suggestions while making it more user-friendly, especially for those of us hardworking souls who view comics on it. <grin>
_______________________________________________
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
