Bug/window resize take 2

[tuttza]

Okay this time I've really fixed the issue resize issue. I've also added GTK macro type checks when calling the UI functions from the GTK API with widgets.

So according to the GTK docs:
Unlike gtk_widget_set_size_request(), which sets a size request for a widget and thus would keep users from shrinking the window, this function only sets the initial size, just as if the user had resized the window themselves. Users can still shrink the window again as they normally would. Setting a default size of -1 means to use the “natural” default size (the size request of the window).

there were two main issues I found:

1. sometimes the widget was null
2. I updated the width to be -1 value based on comment above in the gtk docs and sure enough all the nasty errors went away and window was resizing properly. also vertical bar issue was fixed by this as well.

again more clean up in gtk.c. Anyhow my goal currently is to get the master branch as stable as possible in its current state. I'm working on updating gtk to properly cast the correct types when calling ui functions, clean up errors in other source files. stay tuned!

[ccoupe]

Looking pretty good! Two new issues.

1. the scroll bars do move correctly as the window resizes but the thumb doesn't change position visually as the contents are scrolled.
2. I can resize the window smaller than the initial size. Some folks might like that but it's a change from how Shoes worked in the past.
3. Windows can't set the height smaller after a resize larger.

[tuttza]

REF: #430

Thanks @ccoupe

I noticed point number 1 as well. I will work on that next.

Regarding point number 2 I wasn't sure how that was supposed to work, I can mess with it to get it back to its original state, its funny it works that way when you disable menus(from startup.yaml) currently. just needs some more tweaking.

[ccoupe]

I should have told you to use the remote branch 'direwolf' which has some 3.3.8 restructuring stuff* in gtk.c . I've managed to merge master (plus your changes) into 'direwolf' and it seems to have the same issues/fixes so that's good plus the garbage at quit - that's got to be one of my induced bugs.

• stuff
  move dialogs out of gtk.c
  rename some functions to be 'native'
  ruby 2.4+ compatibility - I use 2.5.5

[tuttza]

so is master considered 3.3.8 now? or should my work be done on the direwolf branch?

[ccoupe]

direwolf would be better. Master always lags behind - sometime way behind. Ideally, master is 3.3.7 (current plus some fixes) and some other branch is the next one (direwolf/3.3.8). 3.3.8 is a big change internally - enough that I might call it 3.4, assuming it ever gets out.

[ccoupe]

I've push all the changes you made to master into direwolf so you can grab it and not have to deal with the merge mess - it will look a little different inside gtk.c

[ccoupe]

@tuttza I fixed a few compiler warnings and finished moving some code out of gtk.c. There's a few more I want to fix - nothing that will change what you're debugging but you may have to pull direwolf branch to get them.

[ccoupe]

Here is a groaner, @tuttza - On Raspbian Buster, your resize code works well (better than Mint 19.1) but has a slightly new error - some new windows are blank until a manual resize. I've seen this one too and its related. Odds are very high that Buster has a newer Gtk3 version than the linux we use.