[al5] Setting the minimum and maximum window size?
jmasterx

In the game that I will be planning to make, it will use Layouts and a few other things and I would like to make it so that the window can be no smaller than 320x240.

Is it possible to do this?

By this I mean, when you drag a corner of a window to re-size it, the window will stop becoming smaller when it hits a certain threshold.

I'm aware of al_resize_display() but I was wondering if there was a way to prevent the window from resizing in the first place.

Thanks

Edgar Reynaldo

I would also like to see support for (at least) minimum and (maybe) maximum window size, without the window temporarily appearing smaller than the minimum or larger than the maximum. It would be a really nice feature.

Elias

I'd like it as well. I'll do the X11 version of it if someone makes the Windows version. Since we have al_set_new_window_position already, I guess a function similar to that would fit well into the API.

Evert

The OS X version does this internally anyway (otherwise you can resize the window to something that's smaller than the titlebar and weirdness happens).

Thomas Fjellstrom

I half expected you could implement this yourself by just not acknowledging resizes once it gets too small or large..

Evert

I half expected you could implement this yourself by just not acknowledging resizes once it gets too small or large..

That's not quite the same thing though, isn't it?
All that does is make the size of the drawing area not agree with the size of the window frame. The window frame itself is still resized. Or is that not the case in X11?

Matthew Leverton

I half expected you could implement this yourself by just not acknowledging resizes once it gets too small or large..

The window is still resized, even if you don't acknowledge it.

There needs to be a function al_set_window_constraints(display, minw, minh, maxw, maxh). It doesn't need to affect explicit resizes.

(Edit: maybe even an optional ratio parameter... Not sure what is easily supported by the underlying OS.)

Thomas Fjellstrom

Or maybe allegro shouldn't allow the resize if it isn't acknowledged. But either way works.

Matthew Leverton

Or maybe allegro shouldn't allow the resize if it isn't acknowledged. But either way works.

That doesn't really work very well with events.

Plus, you need to have the ability to clamp to the constraints. If the minimum width is 300, you wouldn't want an attempt to resize to 295 to be ignored completely... you'd want it to clamp to 300.

Evert

Or maybe allegro shouldn't allow the resize if it isn't acknowledged.

That would be nice, but unfortunately the way it works (at least on OS X) is that the Window is resized, we get a "window resized" message, which Allegro passes on to the user, who then calls a function to synchronise the size of the backbuffer with whatever size it should be.

jmasterx

Turns out this is dead easy in Windows:

In the message loop, just handle the:

WM_GETMINMAXINFO

message

and just fill out the MINMAXINFO structure.

http://msdn.microsoft.com/en-us/library/ms632626%28v=vs.85%29.aspx

Matthew Leverton

One of the comments says:

Quote:

It should be noted, that the values specified in the MINMAXINFO structure are the client plus non-client (including the caption and borders) size of the window. Most Windows programmers know this, but it isn't really noted here.

But that's not how Allegro should work if at all possible. The value specified should be the internal (buffer) size.

Thomas Fjellstrom
Evert said:

That would be nice, but unfortunately the way it works (at least on OS X) is that the Window is resized, we get a "window resized" message, which Allegro passes on to the user, who then calls a function to synchronise the size of the backbuffer with whatever size it should be.

That's odd. I expected it to give you a "Begin Resize" event that you can ignore, or call a function, or return a special variable to cancel the resize (or clamp it).

But that's not how Allegro should work if at all possible. The value specified should be the internal (buffer) size.

It's not that hard to do the math, just fetch the non-client border size, and combine it with the numbers specified by the user with the new function.

jmasterx

But can't you just use:

GetSystemMetrics(SM_CYBORDER); // get the border width
GetSystemMetrics (SM_CYCAPTION); //get title bar height

and then do the math so the struct is correct?

Evert

I expected it to give you a "Begin Resize" event that you can ignore, or call a function, or return a special variable to cancel the resize (or clamp it).

Well, ok, you do get viewWillStartLiveResize`/`viewDidEndLiveResize, but you can't cancel the resize.

jmasterx

For OSX can't you simply do:

[theWindow setMaxSize:windowMaxSize];
[theWindow setMinSize:windowMinSize];

Evert
jmasterx said:

[theWindow setMaxSize:windowMaxSize];
[theWindow setMinSize:windowMinSize];

Yes. I didn't mean to imply it'd be in any way difficult.

jmasterx

Okay great! Looks like the only one that would be left is Linux!

It would be nice if this feature could make it into 5.03 ; it feels like it should be part of 5 and not just >= 5.1 .

Thomas Fjellstrom

As long as it can be done without breaking Binary Compatibility, it could be added to 5.0.x

Arthur Kalliokoski
jmasterx said:

Looks like the only one that would be left is Linux!

xdisplay.c already has

      hints->min_width  = hints->max_width  = hints->base_width  = d->w;
      hints->min_height = hints->max_height = hints->base_height = d->h;

Thomas Fjellstrom

Yeah, it wouldn't be that hard to support.

jmasterx
Evert said:

Well, ok, you do get viewWillStartLiveResize`/`viewDidEndLiveResize, but you can't cancel the resize.

I think that Allegro should still integrate the resize begin and resize end though. Not for the min max size, but to add consistency when resizing. What I mean is, right now in OSX and I think Linux, the Window resizes in real time, but in Windows it just awkwardly stretches what was there until you let go of the mouse.

What this could allow is to blit a black rectangle before the resize begins so that while it is resizing the screen is black across all platforms.

Evert
jmasterx said:

I think that Allegro should still integrate the resize begin and resize end though.

What do you mean?
Allegro generates a "display resized" message when it receives a "resize done" message.

Quote:

What I mean is, right now in OSX and I think Linux, the Window resizes in real time, but in Windows it just awkwardly stretches what was there until you let go of the mouse.

On OS X, I think there's a flag that controls the behaviour of the window while it resizes. Not sure though, but it would make sense. Would then also make sense to have the same on other platforms.

jmasterx

What I mean is that, for example, in Windows, I can drag around the Window for 8 hours, but I will not get a single ALLEGRO_EVENT_DISPLAY_RESIZED event until I let go my mouse. So I have no way to blit that black rectangle.

My biggest issue is that in Windows the old contents is stretched while resizing which I find ugly, I'd rather have control of what I see when it is resizing and that I can make it consistent across all platforms.

Elias

In X11 it's up to the window manager how to resize. E.g. in compiz I can set it to only show a transparent rectangle while resizing then send a single resize message to the application when I let go, or I can set it to stretch, or to constantly send 100ds of messages to the application during the resize. The application itself doesn't know which way is being used (at least not by default, possibly there's a way to override it somehow).

Anyway, I agree that the Windows behavior should be changed and if we can have three events for resize_start, resize_in_progress and resize_done (or a flag in the ALLEGRO_EVENT_DISPLAY_RESIZED event indicating which of the three it is), all the better.

weapon_S
jmasterx said:

My biggest issue is that in Windows the old contents is stretched while resizing which I find ugly

::) Turn off 'show window contents while dragging'.

jmasterx

Where is this "show window contents while dragging" function you speak of?

If you mean for the OS, that's not what I mean, because that will not work for the end user.

Thomas Fjellstrom
jmasterx said:

If you mean for the OS, that's not what I mean, because that will not work for the end user

Thats exactly the point, the real end user of the game or app can have it set to what ever they want, so there is no way to enable/disable it properly from an app.

simast

+1 Would really love to see this implemented. I am currently restricting display window size using al_resize_display - but that feels more like a hack.

What if display constraints could be defined with display options? Like:

al_set_new_display_option(ALLEGRO_WINDOWED_MIN_WIDTH, 100, ALLEGRO_SUGGEST);
al_set_new_display_option(ALLEGRO_WINDOWED_MIN_HEIGHT, 100, ALLEGRO_SUGGEST);

And platforms that can't implement this functionality (iPhone or others?) will create or fail depending on display option importance parameter. I myself can't really see a scenario where someone will want to change display constraints after the display was created (thus a separate function like suggested al_set_window_constraints feels unnecessary).

Elias

The question then is why do we have al_set_new_window_position - you're even less likely to change the position than the size constraints.

But yes, my vote now is to use al_set_new_display_option and not add a new function.

jmasterx

Yea using the display options sounds good!
+1

Matthew Leverton

I don't like the display options for this at all. This is something that you may want to change after creating the window.

And just typing:

al_set_new_display_option(ALLEGRO_WINDOWED_MIN_WIDTH, 100, ALLEGRO_SUGGEST);
al_set_new_display_option(ALLEGRO_WINDOWED_MIN_HEIGHT, 100, ALLEGRO_SUGGEST);
al_set_new_display_option(ALLEGRO_WINDOWED_MAX_WIDTH, 200, ALLEGRO_SUGGEST);
al_set_new_display_option(ALLEGRO_WINDOWED_MAX_HEIGHT, 200, ALLEGRO_SUGGEST);

vs:

al_set_window_constraints(display, 100,100, 200, 200);

No contest. :P

Edit:

Oh, we also need: bool al_set_display_flags/options(display, ... ); to change things that can be changed at run time regardless of which method the current topic uses.

Thomas Fjellstrom

Yeah, it'd be nice to be able to change certain options (like this one) without having to re-create the display.

kazzmir
Elias said:

The question then is why do we have al_set_new_window_position - you're even less likely to change the position than the size constraints.

To spawn the application at the same place the user left it last time.

Elias
kazzmir said:

To spawn the application at the same place the user left it last time.

That could be done with display options as well. A function is only needed if you want to change it after the display was created.

Matthew Leverton
Elias said:

A function is only needed if you want to change it after the display was created.

I view it in the other way: a display option is only needed if you must set it before the display is created.

Evert
Elias said:

The question then is why do we have al_set_new_window_position - you're even less likely to change the position than the size constraints.

If I have a program with multiple windows (the interface to my chess program is what I'm thinking of), I want to arrange them on screen in a sensible way so they are neatly laid out. As opposed to letting the OS place each new window on top of the ones I already opened.

Matthew Leverton

And to answer the question of why you would want to do it after the display is created... you might want to optionally "lock" the windows in such a way that as the user moves the main window, the toolbar windows are moved with it. This is particularly useful perhaps with a frameless window.

I think it's silly to artificially restrict Allegro just because we cannot think of a reason today of why something would be useful. Sooner or later somebody will stop by with a reason to need to change the constraints on the fly (etc).

I don't have a problem with constraints being part of window display options, as long as it can be set after the window is created as well. We already have a al_toggle_display_flag()... we basically just need an al_set_display_option() function as well.

But that said, I'd rather it not be a display option because I don't see any reason for it to be. Unlike things like "frameless" or window positions, the user isn't going to notice if the display is created and then subsequently constrained to a certain size.

Thread #607117. Printed from Allegro.cc