[ALLY] getting the screen-size Re:
[1/10] from: holger:rebol at: 15-Aug-2000 6:35
On Tue, Aug 15, 2000 at 04:18:38PM +1000, [allenk--powerup--com--au] wrote:
> Here is a little function that can return the screen size. This one will
> work on all OS's including BeOS, and those Linux systems that can't initiate
<<quoted lines omitted: 9>>
> system/view/screen-face/size
> ]
This is not really a good idea. First of all, the initial value is not likely
to remain 100x100. This is NOT a magic number, and chances are it will become
640x480 or 800x600 in future versions, probably platform-dependent.
Second, please consider that showing the first face can cause some overhead
on some systems (connecting to an X server or, on the Amiga, possibly opening
a file requester asking for a screen mode and size). Users may not want that
to happen until the window is actually displayed, not to mention that briefly
popping up a tiny window, with decorations and borders, seems ugly. On some
window managers (e.g. twm with default settings) the window manager will prompt
the user for the window position by showing a window outline, then once the
user clicks the mouse button the window will be displayed, then it will
disappear, and then the window manager will display another window outline
for the real window requiring another mouse click -- very, very ugly.
Third, on some systems that support different screens and screen sizes
(in particular Amiga) View tries to create a screen large enough to accomodate
the first window you open. This is necessary because a lot of View scripts
are written to require 640x480 plus window borders, but without graphics boards
most Amigas are limited to around 640x400, requiring special tricks (such as
virtual screens with autoscroll) to show larger windows. If you open a tiny
window first then you defeat this mechanism, and the screen size reported to
you will be unnecessarily small (probably 640x400 or even 640x200).
Finally, you really have no control over the size of borders, title bars
etc., so it is impossible to properly size and center your window anyway,
based on just the screen size. On some platforms (again, in particular AmigaOS
and X11) the size of decorations can vary a LOT, and even be different for
different windows on the same screen (e.g. some X window managers are by
default configured to remove window borders for any programs that have the
word "clock" in the program name).
Bottom line: this is really a chicken-egg issue. (On some systems) View needs
to know the initial window size in order to create a suitable screen, which
assumes that the screen size follows the window size. Yet on other systems the
screen size is fixed, so the window size has to follow the screen size.
For the moment I don't see any solution that works on all platforms. I don't
really like the idea of scripts getting fancy in the way they check the screen
size, trying to outsmart the View OS module, because this is likely to limit
cross-platform portability, and will restrict us at REBOL in providing future
enhancements.
Here is an idea how it COULD work in one of the next versions:
- Centering a window (with a known window size) is something View should be
able to do by itself. This seems like a good candidate for a language
extension.
- If your window needs to know (and I mean REALLY needs to know) the screen
size for other purposes, e.g. if the window has a complex layout and some
parts of it are resizable, then check system/view/screen-face/size. If it
is 100x100 or less then assume 640x400 to be the available screen size
(for compatibility with current versions of View). An idea we have been
tossing around is for system/view/screen-face/size to become a function
which, upon first access, asks the OS for "some" screen size and then
stores the value, in much the same way the various "password"s in
system/schemes work. "Asking the system" would be done in a non-destructive
way, i.e. without opening a screen or popping up a requester. Of course
this would mean that on some systems (like AmigaOS) that size is only a
guess, probably derived from the size of the Workbench screen. The final
size may be larger or smaller and would be stored in system/view/screen-face/size
after the first window has opened, possibly after putting up a requester.
On systems where the final size can be different from the guessed size it
would be View's job to ensure that the first window can be displayed if a
script used the guessed size to size the window.
- This leaves the problem on how to calculate window borders. No solution
to this yet, but the proper solution is likely to be similar (functions
which ask the system). For now please be VERY conservative, i.e. if you have
to dynamically size your window then assume that the borders and title bar
are quite large.
Jim, any comments ?
--
Holger Kruse
[holger--rebol--com]
[2/10] from: allenk:powerup:au at: 15-Aug-2000 16:18
Here is a little function that can return the screen size. This one will
work on all OS's including BeOS, and those Linux systems that can't initiate
the screen-face until after a face is shown. On some platforms, screen-face
returns a size of 100x100 until after face is shown (because the gui libs
have to be loaded).
Most of us want to the know the screen size before we show our main face,
(for window sizing or centering), and also want the script to run on all
platforms. Thanks to Bo for suggesting this idea.
screen-size: does [
if system/view/screen-face/size = 100x100 [view/new make face [1x1]
unview/all]
system/view/screen-face/size
]
Cheers,
Allen K
[3/10] from: agem:crosswinds at: 15-Aug-2000 20:12
how about a [preferred-screen-size [1024x768 640x480
320x240]] which returns a usable size? in combination
with color, and returns a list of resolutions, ordered
by systems preference? may return [ 320x240 [ 512x384]]
on antic mac or [1024x768 [1024x768 24-bit] 640x480
[1024x768 24-bit]], something like this?
how about a "stretch factor" when opening? there is
this "640x480 is real 750x345" - options somewhere.
if i could say max x/y -change is 1.1 and rebol chooses
max in x or y, whatever fits better? (can calculate
by hand, but more code..)
Volker
[4/10] from: allenk:powerup:au at: 16-Aug-2000 0:19
> Here is an idea how it COULD work in one of the next versions:
>
> - Centering a window (with a known window size) is something View should
be
> able to do by itself. This seems like a good candidate for a language
> extension.
Hi Holger,
I had suggested a centering option back around beta2. I was looking for a
current work around because I use the screen-size for rough centering, and
had
some complaints from BeOS users, because of the differences. This approach
worked for BeOS, but now I know that it will cause additional problems on
other platforms, I will drop it and look at your suggestions.
(Centering only needs to be roughly correct with the ability to tweek the
offset for taskbars, borders etc. Horizontal centering tends to be more
important visually than vertical centering)
Thanks for the insightful info on the cross-platform issues. I'm glad you
pointed out what could go wrong and why before anyone got hurt. :-)
Allen K
[5/10] from: holger:rebol at: 16-Aug-2000 5:25
On Wed, Aug 16, 2000 at 06:11:33PM +1200, [carl--cybercraft--co--nz] wrote:
> [big snip 2]
>
> With screen sizes, how about having a list of user-defined ones in
> user.r which scripts can check through and select from before opening
> a new screen?
That won't work in Unix, where you cannot open a new screen, and the
screen size is determined by the X server (and thus may vary depending
on which workstation you are redirecting the display to).
> This would require a system-specific settup routine of
> some description, but once done they could be left alone till the
> user felt the need to edit them. And perhaps the window
> border-widths and heights for each screen could also be worked out
> and stored at the same time as the screens?
Window border heights typically depend on the font size, i.e. they can
change at any time. They are not system-dependent constants.
--
Holger Kruse
[holger--rebol--com]
[6/10] from: agem:crosswinds at: 16-Aug-2000 17:08
how about "Virtual Coordinate Space" with automatic?
instead of
[layout/span/size face 4096x3072 341x25]
:
[view/fullscreen layout[stuff] ]
and the resize can be done pretty hidden..
there should be a simple wishing for resolution/colors
-preference for the scripter. header-option?
from /view - doc:
A virtual coordinate space makes it possible to develop a visual interface without needing
to know the actual display size.
This is to say, it makes it possible to use a virtual pixel space for aligning face objects.
So, the resolution of a user's display
does not need to be known before designing a visual interface. For instance, say you
want to create a visual interface that
will look the same between systems with a maximum resolution of 320x240 and systems with
resolutions of 1280x1024
and greater. This can be done with View's virtual coordinate space capabilities.
A window's virtual coordinates are defined in a window's top level face's span facet.
To set the span, use the /span and
/size refinements when using layout to display a new face. The /span will indicate the
virtual coordinate space while /size
specifies the actual pixel size of the window.
layout/span/size face 4096x3072 341x25
| |
Virtual Coordinate Space |
Window's Size (real pixel space)
--- [holger--rebol--com] wrote on 16-Aug-2000/5:25:53-7:00
> On Wed, Aug 16, 2000 at 06:11:33PM +1200, [carl--cybercraft--co--nz] wrote:
> >
<<quoted lines omitted: 16>>
> Holger Kruse
> [holger--rebol--com]
--
Volker
[7/10] from: alex:pini:mclink:it at: 16-Aug-2000 20:08
>- Open Your Mind -<
Quoting from [agem--crosswinds--net's] message (16-Aug-00 18:08:20).
a> how about "Virtual Coordinate Space" with automatic?
[...]
a> A virtual coordinate space makes it possible to develop a visual
A> interface without needing to know the actual display size.
a> This is to say, it makes it possible to use a virtual pixel space
a> for aligning face objects. So, the resolution of a user's display
a> does not need to be known before designing a visual interface.
That way you risk aspect-ratio distortions.
Tell me, Holger (the only one in RT I *know* knows what I'm talking about), are we going
MUI-like?
Alessandro Pini ([alex--pini--mclink--it])
You know what *is* a problem? No viewscreen! Who builds a bridge without a window?!
"The same people who build a ship without an infirmary!" (J. Dax & Bashir)
[8/10] from: carl:cybercraft at: 16-Aug-2000 18:11
On 16-Aug-00, [holger--rebol--com] wrote:
[big snip]
> Bottom line: this is really a chicken-egg issue. (On some systems)
> View needs to know the initial window size in order to create a
<<quoted lines omitted: 6>>
> because this is likely to limit cross-platform portability, and will
> restrict us at REBOL in providing future enhancements.
[big snip 2]
With screen sizes, how about having a list of user-defined ones in
user.r which scripts can check through and select from before opening
a new screen? This would require a system-specific settup routine of
some description, but once done they could be left alone till the
user felt the need to edit them. And perhaps the window
border-widths and heights for each screen could also be worked out
and stored at the same time as the screens?
Carl Read.
[9/10] from: carl:cybercraft at: 17-Aug-2000 10:22
On 17-Aug-00, [holger--rebol--com] wrote:
> On Wed, Aug 16, 2000 at 06:11:33PM +1200, [carl--cybercraft--co--nz]
> wrote:
<<quoted lines omitted: 3>>
>> opening a new screen?
> That won't work in Unix, where you cannot open a new screen,
In which case user.r should say there's only one screen available,
it's already open and it's so and so a size...
> and the
> screen size is determined by the X server (and thus may vary
> depending on which workstation you are redirecting the display to).
Hmm... Yes, difficult if the workstation screens change their size
often, which even if Unix ones don't, other multi-user systems might.
A user.r (or user-screens.r ?) for each workstation, perhap?
>> This would require a system-specific settup routine of
>> some description, but once done they could be left alone till the
<<quoted lines omitted: 3>>
> Window border heights typically depend on the font size, i.e. they
> can change at any time. They are not system-dependent constants.
Yes, but their sizes would either be determined for good when the
screen's first opened, (i.e. the same font would be used on all the
screen's windows), or for each window when it's opened, which in the
later case has to mean the program's (ie REBOL) deciding on the font
used. Either way, by allowing the user to create a list of available
screen sizes (and the fonts and other guff they use in their borders)
would get around the chicken and egg problem of not knowing
window-border sizes till the window's open, as when the user defines
their screen list (and font to use on the screen/windows) you could
open each screen once and a window on it to grab the window border
sizes to store in the screen list.
[10/10] from: agem:crosswinds at: 17-Aug-2000 15:57
--- [alex--pini--mclink--it] wrote on 16-Aug-2000/20:08:40+2:00
> >- Open Your Mind -<
> Quoting from [agem--crosswinds--net's] message (16-Aug-00 18:08:20).
<<quoted lines omitted: 8>>
> Tell me, Holger (the only one in RT I *know* knows what I'm talking about), are we
going MUI
> -like?
it can try to keep it, by maximizing to the side which will fit.
not full-screen then, but fullm size.
optionally there can be a factor which can be acceptet, like
view/aspect-ratio-xy .. 1.2
(guessed ok for text by rotating my monitor-buttons :)
>
> Alessandro Pini ([alex--pini--mclink--it])
>
> "You know what *is* a problem? No viewscreen! Who builds a bridge without a window?!"
"The s
> ame people who build a ship without an infirmary!" (J. Dax & Bashir)
>
Volker
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted