untoldwind

Believe it or not, but this was actually helpful and let me to an ugly little error. Instead of if ( !$window ) { ... one actually has to write if ( !$$window ) { ... Just the little wonders of perl that are really (really really) hard to get Anyhow, I just updated the workflow with that fix: https://github.com/untoldwind/alfred2-layout/raw/master/Layout.alfredworkflow Not sure if that actually fixes your problem, so I've updated the "tester.pl" as well. Maybe you can try it again if VLC still refuses to move.

Ok, lets see if there is a way to figure this out. I hacked a little test script that should explicitly move the the current window of VLC: https://dl.dropboxusercontent.com/u/3815280/tester.pl (in its core that's what the workflow is doing via the scripting bridge.) To run it you need to have an open VLC window somewhere (obviously) and open a terminal: cd <where-ever you downloaded the script above> /usr/bin/perl tester.pl Please note, you have to temporarily grant UI-Scripting rights to the Terminal.app (or iTerm) for this to work: http://www.tekrevue.com/2013/06/25/how-to-enable-access-for-assistive-devices-in-os-x-mavericks/ The output should look like this: └──➤ perl tester.pl Found process Name: VLC ID: org.videolan.vlc Active window: VLC media player Position: 1083, 425 Size: 1365, 950 Alternative: Alternative Position: 1083, 425 Alternative Size: 1365, 950 Try set position to 0,0 ... ... and the current VLC window should be moved to the top-left corner.

Hmm ... what version of VLC are you using. I just tested the most recent 2.1.1 and was able to resize the playlist window and the player itself quite nicely. Uh ... just for clarification: We are talking about the VideoLan player, right?

I know you will hate me for this, but since I was kind of unhappy with the recent developments of Ruby's and Python's Cocoa-binding I just remembered this old comic: http://xkcd.com/224/ ... so in short: I redid everything with Perl, which is so low level that Apple will not mess with it (hopefully). On the plus side, it is also the fastest binding. An experimental version is available here: https://github.com/untoldwind/alfred2-layout/raw/master/Layout.alfredworkflow New feature: With "lay_config" you should now be able to edit your own configuration file (format described below)Hopefully this will open the "TextEdit" if there are no other editors available (that's hard to test for me, since I have so many editors on my system) If the editor does not open you can also use "lay_config" with Cmd-Enter/Cmd-Click, which should open the configuration directory in Finder. If it all fails: The configuration file should be this one: ~/Library/Application Support/Alfred 2/Workflow Data/de.leanovate.alfred.layout/layout.yaml Of course there is a default-version in the workflow itself (i.e. to reset the workflow to default, just remove the file above) Note: The keywords are NOT merged, i.e. if you do not like some keywords, you are actually able to remove them The configuration file itself is YAML, which should be easily understandable: - { name: "togglefullscreen", display: "Toggle full screen mode", forOtherScreen: No, command: "fullscreen:toggle" } - { name: "full", display: "Full", forOtherScreen: Yes, command: "set:0,0,1,1" } - { name: "left", display: "Left", forOtherScreen: Yes, command: "set:0,0,0.5,1" } name: is the keyword (and also the name of the icon) display: the display text/title that appears in Alfred forOtherScreen: Yes/No toggle if the keyword should also appear in "layother" command: the actual command for the layouter (as described here: https://github.com/untoldwind/alfred2-layout/wiki/Hacking-the-Mavericks-version#parameters-of-the-layouter ... well lets see if it all works as intended. PS: If this is too spooky for you (or simply not working), the previous release is still available here: https://github.com/untoldwind/alfred2-layout/raw/1.1_Mavericks/Layout.alfredworkflow (in case I forgot to update links in the previous posts)

Actually you can do that by yourself - more or less - easily. Just open the layout_select.py with the text editor of your choice and tweak the following lines: layouts = [ .... Layout("full", "Full", True, "set:0,0,1,1"), .... Layout("center", "Center", True, "set:0.1,0.1,0.9,0.9"), In your case to layouts = [ .... Layout("full", "Full", True, "set:0.01,0.01,0.99,0.99"), .... Layout("center", "Center", True, "set:0.15,0.15,0.85,0.85"), (I translated the "20px" border to 1% border since the layouter just works with relative numbers at the moment. The drawback is that these changes would be overwritten with the next "release". May I should add some kind of configuration (nothing fancy) were people can set their own preferences.

Just pushed a new version that should fix the problem. On a side note: in the Apple developer documentation ruby-cocoa and python PyObjC have both moved to legacy with a hint that Object-C is the preferred language for Cocoa applications: https://developer.apple.com/legacy/library/documentation/Cocoa/Conceptual/RubyPythonCocoa/Introduction/Introduction.html#//apple_ref/doc/uid/TP40005422-SW1 For the time being there should not be a problem ... but ... well ... um ...

Sorry, I was quite busy the last week and kind of lost track of this thread. Thanks for the feedback, I just forgot to update the "documentation". You can now find the details of this little ":+1" here: https://github.com/untoldwind/alfred2-layout/wiki/Hacking-the-Mavericks-version I also found an issue: For some reason the new Activity Monitor of Mavericks does not react to the layout events (i.e. it just won't move). I'll have to investigate a bit if there is a way to fix this.

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

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"

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

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) 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. 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

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.

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.

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

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