Wimp window border size calculations
4 posts, 3 voices
Andrew Hodgkinson (6)
465 posts
|
This topic has been imported from the old forum. Due to its use of fixed format text, you may need to make your browser view wider in order to see posts with the correct layout. |
Steve Revill (20)
1361 posts
|
Here's a thought: I tried creating a set of toolsprites where the scroll bars are very thin (e.g. a handful of pixels wide). This doesn't work because you still need a wide set of title bar sprites so that you can read the window title. So I think the Wimp just looks at the dimensions of one tool sprite (the close icon maybe) in order to determine the window border dimensions. I reckon it should take the title bar, vert scroll and horiz scroll separately, e.g. Title: height is the tallest of the back, close, toggle (or scroll up if no toggle size icon) icon sprites. Vert scroll: width is the widest of the toggle, up, down or adjust size icons. Horiz scroll: height is the tallest of the left, right or adjust size icons. Or something roughly like that (there's more to it than that but you get the idea). The net result is you can then create very small arrow and resize icons, a thin toggle size icon and thin scroll bars. If you use a desktop extension like Mauser, you'll almost never use window scroll bars so it'd be nice to free up some desktop real estate by making them "low profile". |
Chris Wraight (60)
1 post
|
Steve Revill (20) wrote: > Here's a thought: I tried creating a set of toolsprites where the scroll > bars are very thin (e.g. a handful of pixels wide). This doesn't work > because you still need a wide set of title bar sprites so that you can > read the window title. [snip] > The net result is you can then create very small arrow and resize icons, > a thin toggle size icon and thin scroll bars. If you use a desktop > extension like Mauser, you'll almost never use window scroll bars so > it'd be nice to free up some desktop real estate by making them "low > profile". I might not have understood this correctly, but is this not already possible? I've not tried it myself, but this screenshot seems to indicate it can be done: http://www.vigay.com/software/screenshots/rotunes.gif In any case, although I can see the usefulness of this, my great hope for Window Manager changes is that the simple changes needed for comprehensive skinning are made. These are: 1. Allow 'highlight' sprites to replace the usual set when a window has the input focus; 2. Draw icons with Rx borders using global colours defined by the user rather than hard-wired values; 3. Allow the colour used by the Wimp to draw window outlines to be set to a global value, and ensure that it's drawn over the sprites (rather than under them, as at present); 4. Add a theme manager to Configure to handle skins in a simple way. I'd be very happy to develop (4) on this list, once RO Open is up and running. But (1-3) would need someone capable of delving into the Window Manager code. |
|
Steve Revill (20)
1361 posts
|
Chris Wraight (60) wrote: > I might not have understood this correctly, but is this not already > possible? I've not tried it myself, but this screenshot seems to > indicate it can be done: > http://www.vigay.com/software/screenshots/rotunes.gif That looks to me like a special case where the application manages its own scroll bars so they can be a non-standard size. In the general case, your scroll bar dimensions are determined by the dimensions of a) the window and b) one of the toolsprites. |
