Is there a way to scale applications at scale?

[dredknight]

Hello everyone,

Recently I was asked if it is possible to enable the user to resize my skillwheel application as texts are read hardly on 1920x1200 resolution.

I am aware how scaling goes regarding flows and stacks. You just change width and heights between 0.0 and 1.0 values.

But what about the pictures?
Lets say I have a slot 50x50 with a picture inside. if the slot size increases how can I force the picture inside to increase as well?

What about texts?
As the scale increases the text size remains the same so subjectively it gets smaller compared to slots.

[ccoupe]

I'm not aware of a zoom capability in the underlying gtk/cocoa and if there is one it may pixelate poorly.
I believe Images do scale to fit the given space in certain situation - you can test it. Will they look pretty? - not always. SVG's will scale but you'd have to create them which may not be easy. Para and Textblock friends can specify the font size and weight as you already know. Native widget's like buttons and edit_lines do not allow font changes - there is an existing issue for that - I think it can be done cross platform but probably not as fast as your user wants.

The tricky part is rewriting your application to be so dynamically resized - I expect you'll find many moments of grief and a few more shoes bugs. Currently, you can set full screen like a game might do and calculate things based on what it reports for width/height. Manual ->Advanced->app methods

[IanTrudel]

I concur this assessment. You will have to recalculate everything dynamically for best flexibility or something precalculated. Either way, svg would be the easiest approach but your skill wheel contains lot of bitmaps for which you will have to provide different sizes for each resolution.

Shoes is lacking in this area and it has never been a necessity so far. It would sure be a nice feature. For now, you still have the luxury of relative placement which should at least ensure each Shoes component is about the place it should be. They will certainly need to be resized accordingly.

Relative placement, resizing according to window size, generate image sets for various resolutions.

[ccoupe]

Shoes is lacking in this area and it has never been a necessity so far. It would sure be a nice feature.

In Tk and Java/awt and Gtk and Cocoa the there is a very flexible relative layout engines. GridBagLayout in Tk and it's the way Gtk3 and Cocoa believe you should do layout instead of the pixel counting that Shoes depends on. How to do that in Shoes with backwards compatibility ? Expert terror-it-tory.

[IanTrudel]

In Tk and Java/awt and Gtk and Cocoa the there is a very flexible relative layout engines. GridBagLayout in Tk and it's the way Gtk3 and Cocoa believe you should do layout instead of the pixel counting that Shoes depends on. How to do that in Shoes with backwards compatibility ? Expert terror-it-tory.

This is something we should ponder about, re: issue #369 and the future of Shoes. There are probably ways around it considering GTK3 isn't out of thin air, it does have some GTK2 compatibility. Speaking of which... it would be amazing to have Glade support in the future.

[ccoupe]

it would be amazing to have Glade support in the future.

I think ruby-gtk is the proper project for that. I don't see Shoes scaling up to that. If you need that level of control, then you've outgrown Shoes. Here is an interesting starting point for ruby-gtk3 - it even shows connecting the xml defined widgets. Once you outgrow Shoes you have choices with trade-offs - ruby-qt, ruby-wx .

It's not an easy jump from 'download and install shoes' and write `Shoes.app {button "hello world" do para "Hello World" end} because you have to install C compilers and Ruby and Gtk/Qt/ and all the other developer things. Here's an example - the layouts in gtk3. Which one does Shoes use - GtkFixed. It's been on deprecation watch for years - As we discovered with freebsd and Gtk 3.20.

Implementing Grid in Shoes would be tricky - different co-ordinates but if is there is cocoa equivalent there might by a way to tell Shoes (per top level window) to use something other than GtkFixed. Needs some pondering.

[ccoupe]

Consider Shoes.app width: 800, height: 600, layout: :grid do ..... end The default would be :grid :fixed (normal shoes). Event's in non-fixed layout windows would not be sent to shoes_place_decide() but to the toolkits manager (via a shoes cross platform wrapper). I'm warming up to exploring this possibility - a lot of work but it doesn't break backwards compatibility. Assuming it can be done per window.

[IanTrudel]

@ccoupe I like your ideas. It might work. The grid itself would get to be sent to shoes_place_decide() but whatever goes inside would be tied in the grid.

RE: ruby-gtk3
It's just plain gtk where you don't get to use nice visual effects Shoes can. Shoes is also easier for prototyping.

RE: Glade
Actually, I attempted to do a GUI builder in Shoes but issue #329 was one of the major obstacle. It is possible to bind a Shoes element with the mouse and drag'n'drop, got a working proof-of-concept. There might (or might not) also need some things to do on C side for a full Shoes UI builder.

[ccoupe]

I picked grid because it is sufficiently powerful for just about anything - GtkBox layout is more like Shoes flow/stacks. After some code examination it would be a huge task to remove/hide GtkFixed layout . The cocoa autolayout is even more than complicated. My thought-goal is not to fit shoes widgets into Gtk3 Grid layout, not to make an new GtkFixed thing to be managed by shoes_place_decide(). Either way, there are issues about the canvas behind a Shoes slot so it looks like a complete rewrite/duplication of Shoes internals. Interesting thought experiment but low on the TODO list

re: ruby-gtk3
A precursor to Shoes 4 was @ashbb's green-shoes (ruby and gtk2) so it is possible to put some Shoes dsl love over Gtk. Green shoes didn't have packaging - but that's kind of worthless now days because of code signing.

[dredknight]

Alright I have few questions.

If I pick up this GTK thing and try to implement it is it going to be of any help to Shoes? If it is not it will be a put off.

I just started a few tests with the slot ratio and I got into a huge party crasher thing.
Whenever my popup is activated all ratio block are jiggled and app.height increases with every popup activated. I think you know what I mean (app grows and a hight slider appears on the right side).

[dredknight]

hm... I got another idea. Is there a way to resize the application window ?
For example if the window specs are width: 1000, height: 700 can I do something like this:

button "resize" do
    app.width = 1500
    app.height = 1200
end

This code does not work as intended but is it possible?

[ccoupe]

Is there a way to resize the application window ?

Not that I know of - but I don't now everything. Do you have resizeable: true in your Shoes.app call?

Your app could read a .yaml settings file before the call to Shoes.app so the user could specify the size they want. Pain in the behind.

[IanTrudel]

Assignments to Shoes.App are always problematic. The way Shoes is built underneath makes it difficult to track variable changes. That's why we get something weird like set_window_title (method) instead of just doing app.title = "Go bigger, go home".

Have you tried self.width = 1500 and such?

[dredknight]

Thank you @ccoupe and @backorder but it seems you are right shoes has issues with the main window itself. self.width = is the same as app.width = and it says undefined method for both.

Basically what I do when in doubt of what can be possible is debug(self.methods) so I can see all that is possible. There is self.width but no width=.

Making everything dynamic failed due to too many issues that come along with it:

• Popup makes other slots that are adjusted dynamically to jiggle around when it appears and disappears - background image cannot be resized/scaled properly;
• Using image instead of background fixes the above problem but makes shoes to accept the image not as background but as slot so it jiggles all dynamic slots around the image and not on top.

I refurbished the application manually for a larger size and this close the issue.
A few other ideas came to my mind to throw in more Shoes functionality inside but I will open another discussion for that.

Unless you have anything else to add I will close this thread in a day or so :).

[IanTrudel]

It would be possible to implement width= and height=. The question is whether you really need it or not. Normally, applications define the window size before they open it. So why do you need to do it at runtime?

Additional references:

• Styles will not allow to position a window Styles will not allow to position a window #28
• Window manipulation methods Window manipulation methods #64

[dredknight]

My first idea was to make it resizeable so users can adjust them as they want but after some tries I saw that slots jiggle not that way I wanted. Then I decided to do a couple of size presets like the games video menus you can choose resolution (800x600, 1024x768 etc) but this had to happen after the application was initialized because the settings menu was part of the app.

At the end I ditched this idea as well because if anyone is running 800x600 monitor I doubt he will be able to play Heroes V so he wont need the manual anyways. And then I just had another thought that 800x600 is considered so prehistorically old that I do not have to bother about it so I just did a higher resolution version of the app and ditched all other efforts.

[IanTrudel]

I agree with your assessment. The good news is that explaining to me gives me an idea: you should support fullscreen. Shoes already support fullscreen/fullscreen=. Everything should be relative to the height and width and use appropriate icons according to the resolution. It should deliver what you are hoping for without flickering caused by the dynamic resizing and such.

[dredknight]

The problem with fulscreen is that app resolution depends on screen resolution so if the screen is bigger than the app this happens :

This means I have to make the app dynamic which brings me back to the issues above.

[IanTrudel]

I haven't set up everything required to build Shoes on FreeBSD yet. Perhaps @ccoupe can take a look at implementing width= and height= ? Multiple resolution is not Shoes' strong side.

[IanTrudel]

How about resize width, height instead of (or in addition of) width= and height= ? It could also include named parameters to allow default values if anyone wants to change only width or height. The reason behind resize is that it makes sense to resize the window immediately while width/height may mean resize one parameter or both.

[dredknight]

What sorcery is this I do not see anything in the manual that regards "resize" command.
How does the syntax go as whatever I try says undefined command?

[IanTrudel]

What sorcery is this I do not see anything in the manual that regards "resize" command.
How does the syntax go as whatever I try says undefined command?

Haha! I am suggesting a new Shoes API to fulfill your dreams. :P

It's relatively easy to implement.

[dredknight]

As far as it works as intended I like it :D

[IanTrudel]

@ccoupe if you could take a look at the latest commit. It is working except when one wants to resize smaller than the initial window size.

Right now it does not implement named parameters.

[ccoupe]

How did those commits end up at shoes:/shoes instead of shoes3/shoes3? Small enough to copy by hand once I figure out the osx side.

[IanTrudel]

Isn't it a problem with your mailer again? Seems in order here and on github web interface.

So the problem is that it won't resize down and below the initial window size. By the way, there is a commented out shoes_native_app_resized but I wasn't sure whether it should be used or not ¬ may need to be removed entirely or use new function code in shoes_native_app_resize_window.

[IanTrudel]

Here is a little test program.

MAXWIDTH = 1600
MAXHEIGHT = 900

Shoes.app(width: 300, height: 100) do
    @width, @height = app.width, app.height
    stack margin: 10 do
        flow do
            slider fraction: (@width / MAXWIDTH.to_f) do |s|
                @width = (s.fraction * MAXWIDTH)
            end
            para "width", margin_left: 10
        end
        flow do
            slider fraction: (@height / MAXHEIGHT.to_f) do |s|
                @height = (s.fraction * MAXHEIGHT)
            end
            para "height", margin_left: 10
        end
    end

    animate(24) do
        if ((app.width != @width) or (app.height != @height))
            app.resize @width, @height
        end
    end
end

[dredknight]

Looks great :)

[ccoupe]

My browser git view must be different than yours. I don't see any pull requests on shoes3/shoes3 - the repo way up top of the us page. That's not an email issue. I suspect we have different git origin definitions

I was just looking at shoes_native_app_resized in cocoa..m - It should work. Is this something we deleted the ruby glue to or just another have finished, undocumented surprise?

[IanTrudel]

It might be the mix of relational and fixed causing this issue. Not so easy to get it right. One sample that gets it right is Shoes Console.

Shoes doesn't seem to provide a way to disable scrollbar on Shoes.app.

[ccoupe]

Also a weird issue I noticed is that you can't have two parallel shoes running but this is probably because of the beta.

Probably not the beta. Many of the OS's handle duplicates badly.

[dredknight]

Alright I managed to go around the hover issue but another one arose that I think will stop me from doing the resize thing. The problem is that it is not a flow but shoes functionality that is not desired.

I do not want the user to be able to resize the window manually except with the resize button/listbox I will create. This one is not possible because to be able to resize the app it should have the option resizable: true which also allows the user to do whatever he wants.

@ccoupe I have never had issues with this on any versions. Probably I have not removed the old version properly. I will test and let you know.

[IanTrudel]

Here is a small code to confirm @dredknight statement that Shoes app needs to be resizable to be resized programmatically.

Shoes.app(width: 250, height: 100, resizable: false) do
     button("resize") do
         app.resize 800, 800
     end
 end

One solution would be to implement resizable and resizable= that would allow to enable resizing for the moment you resize programmatically and reenable it afterwards.

[IanTrudel]

The latest commit fixes this issue. @dredknight you can continue your work with resizable as true until you get a new beta.

GTK makes a clear distinction between a user resizing and code resizing a window. I had initially used gtk_window_resize which is equivalent to a user resizing a window. GTK3 manual stipulates that using gtk_widget_set_size_request doesn't have the geometry constraints.

Additional references:
https://developer.gnome.org/gtk3/stable/GtkWindow.html#gtk-window-resize

[ccoupe]

Hoisted from the #372 commit comments.

What is your test scenario?

Linux, cmd line - any script or -c, -m - any window opening. Dependent on Gtk versions?

[IanTrudel]

FreeBSD, gtk3-3.22.15_1

$ ./shoes -c

(<unknown>:63980): Gtk-WARNING **: Allocating size to GtkLabel 0x80f69e430 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?

(<unknown>:63980): Gtk-WARNING **: Allocating size to GtkLabel 0x80f69e5d0 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?

(<unknown>:63980): Gtk-WARNING **: Allocating size to GtkLabel 0x80f69e770 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?

(<unknown>:63980): Gtk-WARNING **: Allocating size to GtkLabel 0x80f69e910 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?

(<unknown>:63980): Gtk-WARNING **: Allocating size to GtkLabel 0x80f69eab0 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?

(<unknown>:63980): Gtk-WARNING **: Allocating size to GtkLabel 0x80f69ec50 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?

(<unknown>:63980): Gtk-WARNING **: Allocating size to GtkLabel 0x80f69edf0 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?

(<unknown>:63980): Gtk-WARNING **: Allocating size to GtkLabel 0x80f69ef90 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?

(<unknown>:63980): Gtk-WARNING **: Allocating size to GtkLabel 0x8145b0230 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?

(<unknown>:63980): Gtk-WARNING **: Allocating size to GtkLabel 0x8145b03d0 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?

(<unknown>:63980): Gtk-WARNING **: Allocating size to GtkLabel 0x8145b0570 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?

[ccoupe]

our gtk3 code needs lots of version checks (#if #else #endif) to deal with my older version, you're newer and windows medium age. Their are preprocessor macros for the versions. We will also have to find/write the equivalent parts. Only going to get worse.

[IanTrudel]

And so much GTK2 legacy code. It seems gtk_window_set_geometry_hints has some parameters set to NULL since 3.20.

[ccoupe]

Not a lot of gtk2 left unless you mean the layout we use - that would be a much different issue. If I read correctly, us older gtk3's will have to supply the geometry_widget arg or go back to the code you used before.

[IanTrudel]

Actually, it says that geometry_widget is always NULL since 3.20.

[ccoupe]

And my system warning message specifically states things don't match. So I need it to match or otherwise tweek what works for you.

Also, Cocoa appears amenable to resize requests but I haven't done the work yet. PS - Hackingtosh is pretty unsatisfactory for any serious Mac work. I have one my Mac for the 10.9 dependencies. Painful. On PC's the different keyboards really becomes an issue. Not worth the effort IMO.
We should open a separate issue for getting git working for everyone.

[IanTrudel]

And my system warning message specifically states things don't match. So I need it to match or otherwise tweek what works for you.

You surely did this already but perhaps a rake clean might help. The warning doesn't make much sense.

Cocoa appears amenable to resize requests

It is a fairly standard amongst Windowing APIs.

Hackingtosh is pretty unsatisfactory for any serious Mac work. I have one my Mac for the 10.9 dependencies. Painful. On PC's the different keyboards really becomes an issue. Not worth the effort IMO.

Not much choice here. Mac mini isn't particularly expensive but need to keep my budget under control, so many other priorities. I will eventually set up a vm and see what kind of contributions I can do on macOS.

We should open a separate issue for getting git working for everyone.

Good idea. Absolutely.

[IanTrudel]

@dredknight how is it going so far?

[dredknight]

It works great. I did the hardest part with the actual wheel because skills/perks dispersion is done with formula and not manually but after that I lost patience to edit lefts, tops, widths and heights of the other stuff so switched to working on another backend for another app (I will show it when ready).

Here is some screenshots. Do not mind that dummy resize button that is used for testing.

This is old looks:

This is new looks:

For reference here are the dimensions that are used:
app.resize 1200, 800
app.resize 1400, 1000

[IanTrudel]

You are doing really good. I'm glad we found a solution suitable for you. 😃

[dredknight]

haha glad you like it! It would never happen without your effort ;)