Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

[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