Multiple Monitor Support (sending windows to other screens)

[reggi]

Multiple Monitor Support.
The senario is that you have dual monitors [ 1 ][ 2 ]. You have a window on 1 you move this window to the left [ |X][ | ]. You move it left again and it goes to 2 [ | ] [X| ]. And again and again [ | ] [ |X] & [X| ] [ | ]. So you can go in a loop in both directions left and right. This is what win 7 has.

Good work with restoring the project, love the icon.

[chriscrowe]

I just implemented a feature on my fork that reduces the window size in 5% increments when you repeat the same hotkey over and over (at the request of another user). If Filip decides to pull my code and use the 5% reduce feature then this particular setup would not be compatible.

I think it might be nice to have a single hotkey that just swaps a window back and forth between 2 screens.

[reggi]

I like it, however I think that functionality should be customizable to be able to declare what you want for double right and double left.

I found it frustrating when I'd go left and then wanted to make it bigger so I would click right and it would swap sides. It doesn't make sense that you can only make a window smaller with the left and to make it bigger you have to click "W" all the way on the other side of the keyboard. I'd say you should have it work natively with the plus and minus keys and reserve double left and double right for screen swapping. (or allow supreme customization.)

[chriscrowe]

That's not a bad thought... Let me see if I can make a version that exhibits this behavior and we'll see how it feels.

[masch82]

I have already implemented this and submitted a patch for the old ShiftIt before Filip took over the project.
You can find it here : http://code.google.com/p/shiftit/issues/detail?id=32

However after useful code cleanup and refactoring Filip did, this patch will obviously not apply - so I have to rework it.
I'm in touch with Filip about this.

[fikovnik]

Following is the copy of the discussion with Marco about how to proceed (just to have everything in one thread):

On Thu, Jan 6, 2011 at 12:15 PM, MaSch wrote:
Hello Filip

1. modify the WindowSizer to become a bit more like a library with a
   set of primitive functions that does the window operations - move,
   resize, switch monitor, switch workspace, focus change, ...

That sound's reasonable.

I dug a bit to the code, and just tried refactoring a bit to seperate to
the suggested actions,
and I was wondering if taking switch monitor in this category makes sense.

move, resize, switch workspace and focus changes all fall into a
category of "atomic" actions that just do one thing (call AXUI... or
something to modifiy one parameter - size, position, space etc).

while switch monitor is more of a compound action. It involves finding
the right monitor to switch to, calculate the correct position -
position the window, calculate the correct size - size the window, and
take dock and menubar into account.

on the other hand I thought about implementing switch monitor in
"DefaultShiftItActions" but that does not seem right either, because as
decribed above it is more like a compound action that calculates and
then calls size / position and as such is a bit more complex than the
other default actions.

I like to know what you think about it - where should the switch monitor
stuff go ?

You are right, I guess it depends how do we want to approach the API.
More specifically how do we organize coordinate system. Do we count
absolutely - similarly to the NSScreen - making an union of all
screens' rectangles or relatively to each screen - still a window can
be on a screen just partially. To be honest I'm not sure which
approach is better right now, but I tend to be more in favor for the
relative one as I guess it is reasonable to think that one window
should span only over one screen (sure it can still be over more than
one, but from the ShiftIt perspective I guess we want to position
window relatively to only one screen). In that case switch screen
should be an atomic action and there should be also helper functions
that gives you a screen that windows occupy the most, etc.

1. modify the API for the ShiftIt functions, that it gets a complete
   context about the state of the windows (at the beginning just the
   active window) and state of the screens and workspaces and it returns
   the required changes - probably as a stack of commands for the
   WindowSizer to execute.

I like that approach, for my testing I implemented a "Screens" class,
which in fact is a singelton class that provides all the context info
about the screens we could need to calculate position.
It also listens for Screen change notifications and updates itself, so
the Screen list doesn't have to be rebuild on every shift.

Cool!

Also I like the idea of a stack for commands for the window sizer app,
although I would rather choose a queue, because I think it's more
intuitive to insert and work the actions FIFO.

Absolutely, just a plain old list is good.

This way in some distant future the user could mix together compound
actions with some UI control himself like (switch monitor -> size
TopLeft -> ...) and assign it to a shortcut.

Yeah, I had a similar idea, that you can compose commands together and
these composition organize into a group (one or more
commands/compositions) and assign them a shortcut which when pressed
will execute one command in the group keeping the counter at where it
is.

I already wanted to start implementing it, but got swamped at work
(and sick over the xmass :( ).

I hope you are back on track now.

Thanks! I have a deadline till saturday (unless there will be an
extension) so I hope I will be able to do something on sunday if
everything is ok. Perhaps you can create a branch where you keep the
stuff you did already and we can start working on these features
there?

If you want to discuss this design issues rather more publicly, I'll put
up another issue for this on github or something, just drop me a line
and I'll copy and paste it there for everyone to see.

I guess that would be good. I have to also do some stuff about
documenting the build process on 10.5 so I can put it together on
sunday.

Regards Marco

P.S. : I don't see Spaces support yet in the code
If there's need for code on that I recommend
http://code.google.com/p/shiftit/issues/detail?id=27
which is working very well in my patched version of the old ShiftIt

Great! Thanks for this I was not aware of it. This is kind of going
back to my comment earlier - I think we can hack all this fairly
quickly (at least for native windows), but the hard part is going to
be to present it to a user so he's not completely lost and can it is
still useful and productive. When I initially start thinking about
about hacking ShiftIt, I wanted to do some solution aka ION3 window
manager for X11 - having the actions together with a configuration
that are currently in the DefaultShiftItActions + NSUserDefaults in a
script - and using the WindowSizer API you can easily define more less
what you want. As this might be simpler to implement I guess it won't
be very useful to users. Do you have idea on how all this can be
represented in some user friendly way in the properties pane?

Btw: the WindowSize will have to become statefull in order to be able
to accomodate some global settings like how to handle Dock, etc -
https://github.com/fikovnik/ShiftIt/issues#issue/9 the last few
comments.

[fikovnik]

Hi guys,

Finally, I found a free afternoon and right now just pushed in a new branch ambitiously called shiftit20 :)

It's work in progress, but is shows already a draft of the new API and the responsibility change. I also sketched a bit of a support for workspaces. Unfortunately in order for it to be working I had to use the CG private API which is not good, but right now don't know about any other way.

Major part which is missing is the transactional support in WindowManager in order to be able to provide undo/redo. Right now it seems reasonable to use shared key using both [Window.ref_ ] and [Window wid_].

Just to progress more quickly I removed the X11 support.

[reggi]

I'm not really an expert at compiling apps or using patches. I would really like multiple monitor support from anyone how can I get this? It's been nearly a year and I've been used to not having it but I would really love it.

Update: Sorry, just realized I asked this question earlier this year on http://code.google.com/p/shiftit/issues/detail?id=32 just finished compiling it and it works pretty well, I can't wait to start using it...

[fikovnik]

This is really sad, that it eventually pushed you to use the old ShiftIt - I'm ashamed. Well besides the lack of time, I only have two monitors in the lab (where I also have a lot of work). But bit by bit I working on it so perhaps you will switch back later :)

[ghost]

unfortunately I've just done the same reggi: patched for multimonitor and built from the old shiftit.

[fikovnik]

It took quite a while..., but I just pushed into shiftit16 code for the screen shift. From user perspective, it adds one more action Next screen (Cmd+Alt+Ctrl+N) (I guess most of the users have at max two screens so having previous does not make sense although there is a support in the code for that :) ).
Please if you can give it a try. I only quickly test it as I don't have a regular access to a second screen now. It should work with both cocoa windows and X11.
If you find any problems, please open a new ticket.