Yet another window layout workflow

[untoldwind]

Well, I don't have Maverick yet, so I can just do some guessing

 

I suppose it might be related to the stricter UI-Scripting/Accsibility rules introduced with 10.9.

Maybe this will help: http://www.tekrevue.com/2013/06/25/how-to-enable-access-for-assistive-devices-in-os-x-mavericks/

 

Not sure though if it's possible to apply this so easily. Technically speaking its not Alfred doing the layout, its a ruby-script invoked by Alfred. Most likely it will require some experiments ...

[Martin]

untoldwind,

 

I'm using 10.9 GM, and I've dragged the Alfred app to Accessibility in System Preferences.

 

It still doesn't work. I tried to run the script from the command line and I get this error - hope you can fix it

/usr/bin/ruby /Users/martin/Dropbox/Alfred_v2/Alfred.alfredpreferences/workflows/user.workflow.B7E8557E-7A05-4688-8B40-2580B7B55DB5/layout.rb center
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:45:in `require': cannot load such file -- osx/cocoa (LoadError)
from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:45:in `require'
from /Users/martin/Dropbox/Alfred_v2/Alfred.alfredpreferences/workflows/user.workflow.B7E8557E-7A05-4688-8B40-2580B7B55DB5/layout.rb:3:in `<main>'

Thanks

[untoldwind]

Yikes ... looks like they updated ruby from 1.8.7 to 2.0.0 on the way and forgot about the the cocoa binding (or its called differently now).

 

Not sure if this a Beta issue (I googled a bit, and this does not seem to be the only ruby-issue people have encountered). Maybe you can take a look in the /System/Library/Frameworks if there still is a RubyCocoa.framework present. It is very well possible that they have dropped it in favor for MacRuby.

... or Apple has just decided to (silently) drop ruby-cocoa support altogether.

 

Anyhow, the only way to be certain is to see whats coming with the official release, if the rumors are true it'll be announced next week ...

 

This just reminds me of the words of wisdom from ancient times: Never touch a running system

Edited October 17, 2013 by untoldwind

[Martin]

Yikes ... looks like they updated ruby from 1.8.7 to 2.0.0 on the way and forgot about the the cocoa binding (or its called differently now).

 

Not sure if this a Beta issue (I googled a bit, and this does not seem to be the only ruby-issue people have encountered). Maybe you can take a look in the /System/Library/Frameworks if there still is a RubyCocoa.framework present. It is very well possible that they have dropped it in favor for MacRuby.

... or Apple has just decided to (silently) drop ruby-cocoa support altogether.

 

Anyhow, the only way to be certain is to see whats coming with the official release, if the rumors are true it'll be announced next week ...

 

This just reminds me of the words of wisdom from ancient times: Never touch a running system

Thanks for the reply.

 

RubyCocoa is still present in /System/Library/Frameworks, I just checked.

 

I don't think it will change for the retail release I'm afraid.

 

I have a developer account and I'm running the GM build (which historically is always the same as the retail release).

 

Hopefully it's possible to get it working with Ruby 2.0.0.

[Martin]

untoldwind,

 

Another workflow developer fixed his workflow so it works with ruby in Mavericks.

 

Maybe you can use his fix?

 

http://www.alfredforum.com/topic/1207-alfred2-workflow-for-google-search-suggestion-instant-search-and-current-site-search/page-2

[untoldwind]

Ok, finally I got my hands on Mavericks too (had some download problems yesterday):

 

Short story: A fixed (though slighly experimental) version for Mavericks is available here:

https://github.com/untoldwind/alfred2-layout/raw/mavericks/Layout.alfredworkflow

(Can't say anything about multi-screen support yet)

 

As stated before it is now required to explicitly allow "Alfred 2" UI-Scripting access, which is discussed in more detail here: http://www.tekrevue.com/2013/06/25/how-to-enable-access-for-assistive-devices-in-os-x-mavericks/

 

Long story:

Oh dear ...

I did not found a way to get RubyCocoa running with the new ruby 2.0, luckily there is still a ruby 1.8 around, big thanks to the author of this little gist: https://gist.github.com/nsforge/6861400

(I'm not sure if this actually means that RubyCocoa support is now dropped by Apple, replaced by something else or whatever ... let's give Mavericks some time to settle down a bit)

But obviously the did some changes to it, e.g. there is no longer a "setProperties:" method on the windows objects, "bounds" and "setBounds:" still do not seem to work ... the only way I've found was by using the SBObject at it's lowest level like this:

windowPosition = window.propertyWithCode_(0x706f736e) # this is "posn" in hexcode
windowPosition.setTo_([x, y])
windowSize = window.propertyWithCode_(0x7074737a) # this is "ptsz" in hexcode
windowSize.setTo_([width, height])

... and yes, this what I call "experimental information technology", its not like you actually know what you are doing, its more about poking it with a stick and see what happens

Edited October 24, 2013 by untoldwind

[Martin]

Thanks it works in Mavericks now

 

Is there a way to center a window, without it being resized?

[untoldwind]

Is there a way to center a window, without it being resized?

 

Just added some new keywords:

• movecenter
• movetopleft
• movetopright
• movebottomleft
• movebottomright

... that just move the current window without a resize.

 

I have not forgot about the "nudge" feature, I just don't have a version I feel comfortable with yet.

[untoldwind]

As an experiment I now also added the following keywords:

• grow
• shrink

which resize the window by 1/6 of the available screen size, whereas the edges of the screen are sticky.

Just tell me if this fits your needs.

[raguay.customct]

That works, but I want to grow/shrink one side. Like: grow Left will increase on the left side of the window. Also, it would be nice to be able to specify the increase/decrease amount.

[glortho]

Great workflow! One question: I often split my secondary monitor screen according to a 2 row x 3 column grid, where one window takes up all of the first 2 columns and then in the last column there is 1 window in each row. Is there an easy way to add this?

[Martin]

Thanks for the 'move to center' keyword

 

How do I set up a hotkey in Alfred for the 'move to center' command?

[untoldwind]

That works, but I want to grow/shrink one side. Like: grow Left will increase on the left side of the window. Also, it would be nice to be able to specify the increase/decrease amount.

 

Not sure if this is really what you want, but the current version now also has:

• growleft, growright, growtop, growbottom
• shrinkleft, shrinkright, shrinktop, shrinkbottom

The amount is still "hardcoded", but can be easily adjusted (e.g. look at the link below)

 

Thanks for the 'move to center' keyword

 

How do I set up a hotkey in Alfred for the 'move to center' command?

 

I've added an example (unbound) hotkey for this in the current workflow (the one with "move:0.5,0.5").

All you have to do is defining your own key-combination you feel comfortable with.

 

Great workflow! One question: I often split my secondary monitor screen according to a 2 row x 3 column grid, where one window takes up all of the first 2 columns and then in the last column there is 1 window in each row. Is there an easy way to add this?

 

So far I have not considered anything outside a 2x2 and a 3x3 grid. Of course the layouter itself is flexible enough to handle any possible grid, its just that I'm running out of keywords already - i.e. I don't want to make things even more confusing.

But if you want experiment a little I wrote a wiki-page with more detailed instructions how to tweak the scripts according to your needs: https://github.com/untoldwind/alfred2-layout/wiki/Hacking-the-Mavericks-version

 

In your case the following parameters seem to be relevant:

• set:0,0,0.333,0.5 = Top, first third
• set:0.333,0,0.667,0.5 = Top, second third
• set:0.667,0,1,0.5 = Top last third
• set:0,0.5,0.333,1 = Bottom, first third
• set:0.333,0.5,0.667,1 = Bottom, second third
• set:0.667,0.5,1,1 = Bottom last third

[Subject22]

Oooh, this looks neat Could I be impolite enough to make a feature request? I've always wanted to be able to specify a monitor when opening/focussing an app with Alfred. I'd love to be able to type "lay Messages 2" or something to have Messages opened on my second display, regardless of where it started (I stick pretty much exclusively to full screen mode with my apps, so I'm not sure how I imagine this working with windowed mode). Again, very cool workflow.

[raguay.customct]

Perfect! I will play around with the numbers to get a small just. Thanks so much. Good bye Spectacles!

[untoldwind]

Oooh, this looks neat Could I be impolite enough to make a feature request? I've always wanted to be able to specify a monitor when opening/focussing an app with Alfred. I'd love to be able to type "lay Messages 2" or something to have Messages opened on my second display, regardless of where it started (I stick pretty much exclusively to full screen mode with my apps, so I'm not sure how I imagine this working with windowed mode). Again, very cool workflow.

 

Eventually I'm back at my workplace with a multi-screen too. Good news is: The new "Mavericks" workflow works quite well with multi-screen.

I don't know if "Open app on screen X" is possible at all, but "Move window to other screen" is certainly possible and is actually already on my todo-list since I would like to have this feature as well.

Just give me some time to figure this out cause right now I have to do ... uh ... work

 

Edit: I'll correct myself. The current version only works correctly if the main screen does not have a full-screen app. If there is a full-screen app on the main screen the windows on the secondary screen are not positioned correctly. I'll try to fix that as soon as possible

Edited October 28, 2013 by untoldwind

[rice.shawn]

Oooh, this looks neat Could I be impolite enough to make a feature request? I've always wanted to be able to specify a monitor when opening/focussing an app with Alfred. I'd love to be able to type "lay Messages 2" or something to have Messages opened on my second display, regardless of where it started (I stick pretty much exclusively to full screen mode with my apps, so I'm not sure how I imagine this working with windowed mode).

 

In order to avoid bloat, it seems like it would be better to write a different workflow to open a window on another desktop / display. This workflow is perfect for moving windows once they're opened, but what you're asking for seems to be a completely different feature, albeit one that would complement this one well.

 

Subject22, maybe you could take a shot at writing it up for all of us?

[Subject22]

In order to avoid bloat, it seems like it would be better to write a different workflow to open a window on another desktop / display. This workflow is perfect for moving windows once they're opened, but what you're asking for seems to be a completely different feature, albeit one that would complement this one well.

 

Subject22, maybe you could take a shot at writing it up for all of us?

 

I go on (effective) holiday in a couple of weeks so I may well do just that, though I do have a few other personal projects queued up

[untoldwind]

In the current version contains the fix for the multiscreen issue, i.e. it now works if main screen has a fullscreen app - I really like this new feature of Mavericks BTW.

 

As for the "Move to Screen":

Actually there already is a workflow for this: http://www.alfredforum.com/topic/2204-monitorjumper-move-the-top-most-window-between-your-monitors/

Nevertheless it would be nice to have a way to say "Move the window to topbottom of second screen" with a single Alfred command. Let's see if there is a way without "bloating everything up"

[untoldwind]

After some back and forth I settled down to the most simplest solution.

The "lay" keyword remains unchanged and should work as before.

 

The current version now also contains a "layother" master-keyword, that works almost like "lay", just that the window is move to the other screen.

 

E.g.

"lay center" : Resizes the window to center of current screen

"layother center" : Resizes the window to center of the other/next screen

 

If there is just one screen "layother" should just work like "lay"

 

It should even work with more than two screen ... though I wasn't able to test this in the lack of additional  monitors

[manjaro]

Awesome... Cool...

[manjaro]

Hello,

 

Im trying to set a hotkey for "lay full". When I link the hotkey to the script directly and pass the text as "Full", it still doesnt act similar to "lay Full" from Alfred. How exactly can I set the hotkey for this.

 

Thanks

[rice.shawn]

Here's how to do it with the Mavericks version; I'm not perfectly sure that the previous version is the same.

 

If you open the Workflow, then you'll see that the two hotkeys that are already defined use  a "set:#,#,#,#" or so argument. If you open the "layout_select.py" file in the workflow folder, then you'll see the full list of what the arguments translate to. The argument for "full" is 

set:0,0,1,1

So, open the workflow editor in Alfred, then add a new hotkey, then add an argument (type: text), make the argument "set:0,0,1,1" without the quotation marks, and connect it to the /bin/bash script. That will make it work.

[manjaro]

Perfect Shawn. It works. Thanks. It would be nice for new users if that is given as a default hot trigger.

[manjaro]

Hello,

 

I want to add a hot trigger for "layoutother full", so that using a shortcut key I can move my application between monitors.

 

Any pointers on how to get that done.

 

Thanks

Joe