How to size windowing element internal spaces?

[Steam Ranger]

It's hard to describe what I'm asking in a title, so I'll elaborate.

When creating a window/screen, the size you give it is used by Intuition to draw a window/screen. The problem for my use case is that that width/height includes the window borders/gadgets or screen title bar.

How do I make a screen or window while providing the size of the internal space (screen - titlebar, window - borders), rather than the size of the element as a whole.

[meynaf]

You normally need to find these values somewhere and add them yourself.
You will find them in the Screen structure (WBorLeft & similar values).
To get to this structure you'll probably have to LockPubScreen(NULL).
You may have to take screen's font size into account for title bars.

Alternatively, you can use OpenWindowTagList and provide InnerWidth/InnerHeight tags instead of Width/Height.

[Steam Ranger]

Originally Posted by meynaf

Alternatively, you can use OpenWindowTagList and provide InnerWidth/InnerHeight tags instead of Width/Height.

I'm presuming that's only compatible with V36 and above?

Originally Posted by meynaf

You will find them in the Screen structure (WBorLeft & similar values).
To get to this structure you'll probably have to LockPubScreen(NULL).
You may have to take screen's font size into account for title bars.

LockPubScreen()

is only usable in V36 and above right? Is there a way I can do this procedure below V36?

[meynaf]

Originally Posted by Steam Ranger

I'm presuming that's only compatible with V36 and above?

Yes. If you need to run under pre-V36, your situation has become a little bit more complicated...

Originally Posted by Steam Ranger

LockPubScreen()

is only usable in V36 and above right? Is there a way I can do this procedure below V36?

You may wish to use

GetScreenData()

instead.

[Steam Ranger]

Originally Posted by meynaf

You may wish to use

GetScreenData()

instead.

Right.
And yes I do need to maintain Pre-V36 compatibillity, I'm making a graphics interface and want it to be usable on people who haven't upgraded their ROMs, I'm sure that's noone in 2023 but still.

[meynaf]

Originally Posted by Steam Ranger

And yes I do need to maintain Pre-V36 compatibillity, I'm making a graphics interface and want it to be usable on people who haven't upgraded their ROMs, I'm sure that's noone in 2023 but still.

Good luck if you want to make menus. Without gadtools they're a real horror to do.

[Thomas Richter]

Originally Posted by Steam Ranger

How do I make a screen or window while providing the size of the internal space (screen - titlebar, window - borders), rather than the size of the element as a whole.

Read intuition/intuition.h:

#define WA_InnerWidth           (WA_Dummy + 0x13)
#define WA_InnerHeight          (WA_Dummy + 0x14)
                        /* You can specify the dimensions of the interior
                         * region of your window, independent of what
                         * the border widths will be.  You probably want
                         * to also specify WA_AutoAdjust to allow
                         * Intuition to move your window or even
                         * shrink it so that it is completely on screen.
                         */

[Steam Ranger]

Originally Posted by meynaf

Good luck if you want to make menus. Without gadtools they're a real horror to do.

This may sound a bit uneducated but... What's gadtools? I've seen it in the autofocus but never used it.

[Krashan]

Originally Posted by Steam Ranger

What's gadtools? I've seen it in the autofocus but never used it.

Gadtools is a helper library for creating standarized Intuition menus and gadgets.

[meynaf]

Originally Posted by Thomas Richter

Read intuition/intuition.h:

#define WA_InnerWidth           (WA_Dummy + 0x13)
#define WA_InnerHeight          (WA_Dummy + 0x14)
                        /* You can specify the dimensions of the interior
                         * region of your window, independent of what
                         * the border widths will be.  You probably want
                         * to also specify WA_AutoAdjust to allow
                         * Intuition to move your window or even
                         * shrink it so that it is completely on screen.
                         */

There are a number of issues that can make this useless.
First, this needs V36+. The OP wants it to work under older versions.
Second, it only affects window opening. There is no way to do the same for specifying window size when clicking the zoom gadget, nor there is a way to do it for minimum/maximum window size values.
Third, you still need the border sizes as coordinates inside your window aren't exactly inside your window. You may wish to use GZZ for this, but it can fail in a number of ways.

[Thomas Richter]

Originally Posted by meynaf

There are a number of issues that can make this useless.
First, this needs V36+.

That's not requested in the first post. However, if you want to find out the border sizes the window will get, provided no additional gadgets are placed in the border by the user itself, you can also check , in particular

      /* Bar sizes for this Screen and all Window's in this Screen */     /* Note that BarHeight is one less than the actual menu bar      * height.  We're going to keep this in V36 for compatibility,      * although V36 artwork might use that extra pixel      *      * Also, the title bar height of a window is calculated from the      * screen's WBorTop field, plus the font height, plus one.      */     BYTE BarHeight, BarVBorder, BarHBorder, MenuVBorder, MenuHBorder;     BYTE WBorTop, WBorLeft, WBorRight, WBorBottom;

this part of "struct Screen".

Originally Posted by meynaf

Second, it only affects window opening.

This is what was being requested as far as I read the original post.

Originally Posted by meynaf

There is no way to do the same for specifying window size when clicking the zoom gadget, nor there is a way to do it for minimum/maximum window size values.

It is typically less relevant there. If a window can be resized or zoomed, then it means that the layout process of the window needs to be somewhat flexible anyhow, and you better read the border sizes then from the window structure once you do the rendering.

Originally Posted by meynaf

Third, you still need the border sizes as coordinates inside your window aren't exactly inside your window. You may wish to use GZZ for this, but it can fail in a number of ways.

In which particular ways can GZZ fail?

[meynaf]

Originally Posted by Thomas Richter

That's not requested in the first post.

Hence my first reply, which suggested the same thing as you did. Perhaps you should read whole threads before posting.

Originally Posted by Thomas Richter

However, if you want to find out the border sizes the window will get, provided no additional gadgets are placed in the border by the user itself, you can also check , in particular
<snip>
this part of "struct Screen".

Sure. Provided there are no additional gadgets in the border. But what if there are ? Simple size gadget will make this fail.

Originally Posted by Thomas Richter

This is what was being requested as far as I read the original post.

This has been specified since. Read post #5.

Originally Posted by Thomas Richter

It is typically less relevant there. If a window can be resized or zoomed, then it means that the layout process of the window needs to be somewhat flexible anyhow, and you better read the border sizes then from the window structure once you do the rendering.

It means we have to reread that information to adjust the values. Easy, but more annoying than ought to be. OS should have provided that shortcut as well.

Originally Posted by Thomas Richter

In which particular ways can GZZ fail?

When you want to reduce a window to its title bar thru the use of zoom gadget. Delitracker for example does this. Very useful to "minimize" a window, however GZZ prevents it (zoom gadget not changing the size anymore).
Not to mention it is noted at several places it is more complicated than it should and not good for performance.

[Steam Ranger]

As a side note, incase anyone's wondering I'm developing an interface library meant to port simple functionallity between operating systems. Things like memory management, windowing interface, user input devices (Mouse, Keyboard) etc.

You can write the same C code and just compile it for a different platform and it will work.

Anyway, I'm going to the effort of porting it to the Amiga anyway, I figured why not support <V36, there's not much less it can do for a library.

[meynaf]

Originally Posted by Steam Ranger

As a side note, incase anyone's wondering I'm developing an interface library meant to port simple functionallity between operating systems. Things like memory management, windowing interface, user input devices (Mouse, Keyboard) etc.

How odd, i'm doing the same.

I already have text console, memory management, automatic error handling, resource tracking, file i/o, 2d graphics (including screen conversions), keyboard, mouse, joystick, audio, timers (interrupts), clipboard, dynamic strings/arrays, and a few misc utilities.
Having this kind of tools helps a lot when coding.

Now adding user interface (windows, menus, gadgets, this kind of things).

If it is that you want, perhaps we could somehow join efforts ?

Originally Posted by Steam Ranger

You can write the same C code and just compile it for a different platform and it will work.

Me, it's for my VM (no need to recompile anything) but it's the same API as for my native Amiga apps.
All my game ports use it, for example.

Originally Posted by Steam Ranger

Anyway, I'm going to the effort of porting it to the Amiga anyway, I figured why not support <V36, there's not much less it can do for a library.

Then you are in big trouble if you really want to support windowed UI.
How can the very same interface work on displays as different as baseline miggy with its 640x256 4-color, compared to peecees or whatever with (now as bare minimum) 1920x1080 true color ?
It will either be ugly on one side (or both), even in comparison to native ones, or not work at all on the smallest.