Specified app window size is only used for modal apps. Why?

[ubacher]

Is it an oversight that non-modal apps ignore the window size specified in the app.json file?

I think it would be best if each app's size could be specified - or better still: if a size is specified then use it
else use the current behaviour (= size stays the same unless manually changed on screen)

Is there a way to change the size within the script? I seem to recall ways to read the current size only.
Changing the window size has probably a high overhead - still, it may be desirable.

[Mario]

Apps rendered in App panels use whatever size the App Panel is.
Apps must be designed to work in all App Panel sizes from 10 pixel to 8K. Apps need to be responsive.

The sizing of the App Panel is under the control of the user, and also in which app panel he runs the app.
He may also decide to run your non-modal app in a web browser!

You cannot change the size of App Panels from an app.

[ubacher]

Apps must be designed to work in all App Panel sizes from 10 pixel to 8K. Apps need to be responsive.

You are thinking of a universal app suitable for all users, screen sizes etc.
When I write an app to automate some function specific to me I need not worry about this.

As it is I can write an app but when I run it I have to manually adjust its window size to suit me best.
Takes away much of the benefit of automating things.

[Mario]

You will have to live with that. I cannot implement special cases just for one user.

[Carlo Didier]

I'm with ubacher here (taht makes us two!  ). But I'm a special user too, I know.
But I think that with time, more users will want purely functional scripts to really automate things. It's the big advantage of scripting to be able to do very custom stuff that isn't possible out of the box and currently IM2017 is very limited in that aspect.
I know, the audience you target isn't the geek community, but there are some geeks (or call them power users) who need/want those things we had in IM5.

[thrinn]

Please keep in mind that for non-modal apps specifying the size of the window size might not be enough. What about docked panels? What about auto hide panels? Even if it is floating, you need to specify also the position of the panel.
For me this sounds quite complicated.

[Mario]

In addition, if the App Panel is grouped (and it most likely is), resizing the App Panel would also forcefully resize all other panels in that group. This is a no-go.

If you for some reason don't make your App responsive and thus require a specific pixel-perfect browser window size, use a modal app window. Also keep in mind that a user may run different screen DPI settings and also use different scale settings for Apps, which of course causes problems when an app expects a certain window size or even makes assumptions about the width or height of fonts or controls.

And when you only write the app for yourself and don't care about all this, use a modal window with noresize and a fixed pixel size.

[ubacher]

....and don't care about all this, use a modal window with noresize and a fixed pixel size.

It's just that when using a modal app it freezes all else until the app is closed.

Now that I realize that the app window is just another panel in the list of Imatch panels I can see the need to have it as is.
Making it adjustable from within the script only for when the panel is floating is probably too messy.

[Mario]

It's just that when using a modal app it freezes all else until the app is closed.

That's exactly the purpose of a modal app. It must block the user interface until it is finished, to prevent the user from interfering with whatever your app does.
Modals are ideal for apps which process things, present a progress bar, don't want the user to do other things in IMatch while the app runs. Processing files and folders. Doing stuff with metadata. Importing or Exporting data.

Apps running in App Panels are for more interactive or visualization purposes.

And there will be other app types in the future...

For example, a new 'App' File Window Layout. If you switch to such a layout, the entire file window is replaced by an App window. And the app then controls how the files in the active scope are displayed.
This opens up awesome possibilities for visualization and interaction:

+ A 'real' light table where you can arrange the files in the scope via drag and drop (and IMatch remembers this).
+ Stacking files by touch.
+ Visualizing relations between files using 3D graphics.
+ Genealogy or species trees.
+ ...

IMatch 2017 is just the first step.

Next is IMatch 2017 and IMatch Anywhere in 64-bit to utilize all the memory and power available in modern computers. Almost there.

Then I will work on write-back support for IMatch Anywhere (changing metadata and other data via the web browser, from anywhere).
This step includes features like adding/updating/deleting files and folders via IMWS. And this will work in IMatch then too.

I've planned until January 2018 already.
IMatch and IMatch Anywhere are now so big, you would normally need an entire team to design, implement, test and support it...