Window manipulation methods

[IanTrudel]

A list of desirable methods to manipulate Shoes windows:

• Borderless
• Always on top
• Bring to front, focus
• Remove titlebar (no controls)
• Hide and show window
• Elements Z order

Add your suggestions here.

[IanTrudel]

Who said Shoes cannot be cool? I have implemented window opacity and ability to remove window decoration. The feature also allows to be used in runtime.

Shoes.app(width: 200, height: 200, decorated: false) do
   para "no decoration"
end

Toggle decoration sample code:

Shoes.app do
   switch do
      self.decorated ^= true
      @p.text = self.decorated?
   end
   @p = para
end

Shoes.app do
   @b = banner "Opacity\n"

   slider fraction: 1.0 do |n|
      self.opacity = n.fraction
      @b.text = "Opacity %.2f\n" % n.fraction
   end
end

[ccoupe]

Does it . can it work in OSX?

[IanTrudel]

Setting opacity in MacOS X should be easy enough. The window decoration can be defined at creation time but it's unclear to me when it comes to runtime.

Either way, it may require subclassing NSWindow. http://stackoverflow.com/questions/33144721/transparent-nswindow-on-osx-el-capitan

[ccoupe]

Everything subclasses NSWindow.

[IanTrudel]

It is now possible to retrieve the current window position (x, y) and move a window to any position using coordinates. It works on both main window and child windows.

Shoes.app(width: 350, height: 200) do
    @x, @y = app.x, app.y
    @p = para
    stack do
        flow do
            tagline "set x: "
            @edx = edit_line
            @edx.text = @x
        end
        flow do
            tagline "set y: "
            @edy = edit_line
            @edy.text = @y
        end
        button("move") do
            @x, @y = @edx.text.to_i, @edy.text.to_i
            app.move @x, @y
        end
    end

    animate do
        @p.replace "Window at [#{@x}, #{@y}]"
    end
end

[ccoupe]

I've got cocoa code working for the sample (bug064.rb) - but gtk and cocoa have different definitions of the y-axis. Gtk thinks 0,0 is top left and osx thinks that is bottom left. I believe that Shoes assumes that increases in y moves things down the screen/window (like gtk does) so that's what cocoa should do.

[IanTrudel]

I believe that Shoes assumes that increases in y moves things down the screen/window (like gtk does) so that's what cocoa should do.

Agreed. Makes sense with Shoes and it ensures code portability.

[ccoupe]

on OSX I had to get the screen size to better compute the y value - it seems silly to have to call this every time when it could be done ioncen shoes_native_init() and stored in the global shoes_world which turns out to be one of our C/Ruby objects.

This led to the idea that we could support multiple monitors. I have no way to test it so that's going to be a problem

[IanTrudel]

GTK supports the same features, including multiple monitors. Read further on https://github.com/Shoes3/shoes3/issues/370#issuecomment-332101445

Do you have a multiple monitor settings at home? Normally it will just give you a monitor number and a resolution for the monitor currently displayed on. I do have multiple monitors on my FreeBSD workstation.

[ccoupe]

I don't have multiple monitors on any of my boxes so I can't test support for such a feature. Bad news for osx support because those machines are not where I want spend my money and there is plenty of osx bugs to deal with.

[IanTrudel]

Indeed. We should find a user that has the right setup to test. VirtualBox supports multiple monitors as far as vm goes. Besides, perhaps we could consider having the feature to return resolution but always for the current monitor in use (the one Shoes app is displayed on).

[ccoupe]

I want to note a couple of things - not really bugs? On osx you can not move or resize a window to cover the menubar or below the dock. - their rules. I also constrain the x axis so that it can't be move off screen. bugs/bug064.rb script displays the real value the window is at after moving on osx

On gtk based system including Windows, the theme controls some of that. Windows is the most permissive - once you move the window's title off screen you have a problem. The Shoes gtk code might be able to contrain movements too?

[ccoupe]

As for multiple monitor support, we need to think a bit about the Shoes api and the C/Obj code. First attempt: app.monitors returns a array of 'monitor' objects, [0] is the default - there's always one. From the Shoes POV the monitor object has methods for width and height.

From the C side, monitors is just an VALUE in shoes_world_t like apps is. At shoes_native_init time it builds the monitor objects and puts them in the monitors array. It also sets two more new C variables in in shoes_world_t, call them screen_width, screen_height with the default monitor settings.

The monitor object encapsulates the gtk/cocoa pointer (like a SHOES_CONTROL_REF does) with the int fields for width and height. Of course I have now idea how that would work for users - do they want to create a (new?) Shoes app/window in a different monitor? What does multi-monitor support really mean?

[IanTrudel]

You are right but common practices on Windows is without constraints. Any window can absolutely be out of reach. It is still possible to move the window back using the context menu on the app in the menu bar.

macOS does protect its menubar and dock. cairo-dock on FreeBSD/Linux does the same.

I think it's alright to let the system decide what it does. The result may slightly differ on different platforms but this is within expectations from any user on its respective system.

[IanTrudel]

app.monitors

I like it.

RE: monitors behaviour

This is an excellent good question. Users may want to do that. For example, video editing software tend to have dual monitors support where the main monitor has a window to do the editing and the second monitor will display the rendering in real time.

Another example is when one does programming. I have Shoes manual on one monitor but run my apps on another.

Also, I mentioned before that some users may want to be able to save windows positions. So they should be able to get their windows back where they were when they reload an app.

RE: issue #28

We should implement this while we are at it! Perhaps x and y should be renamed for left and top.

[ccoupe]

Yes, examples help me think about the feature. Financial/Trading apps do that. In Shoes terminology, the APPS array and app objects should contain a monitors index and all the ways to create a new App needs code to specify when monitor to put it on. I don't know if the gtk/cocoa api are common enough to do that but its a good place to investigate before doing any coding. The global variable `shoes_world' is a pointer to a singleton shoes_world_t.

Also, I mentioned before that some users may want to be able to save windows positions. So they should be able to get their windows back where they were when they reload an app.

With the new code, developers can now get that data and create a myapp.yaml (or xml or ..) and restore their layout. When closed properly . I'm not sure it is a Shoes task do that for them. How would we know which script deserves special handling.?

We should implement this while we are at it!

We should think long and hard because the devils are in the details.

Perhaps x and y should be renamed for left and top.

I have no opposition to changing the method names in ruby.c to left, top. See latest commit to master. If you want to work on the multiple monitors issue, create a branch 'monitors', modify something in that branch, commit and create a pull request then we can work together on that branch.

[IanTrudel]

If you want to work on the multiple monitors issue, create a branch 'monitors', modify something in that branch, commit and create a pull request then we can work together on that branch.

We may need few more clarifications first. APPS is not working too well as you might remember. Now each window would have to dynamically get its monitor and resolution, whenever invoked or necessary, because they may or may not be on the same monitor and users may move them around monitors.

RE: saving position

We only provide a way for users to set/get information. They can handle saving and restoring positions by themselves.

I have no opposition to changing the method names in ruby.c to left, top. See latest commit to master.

Great. We can also add left, top to Shoes.app parameters in shoes/apps.c to support Shoes.app(:title => "Window Positioning", :left => 0, :top => 0) {} as referred in issue #28.