Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won

  1. 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.
  2. 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-e
  3. 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?
  4. 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)
  5. 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.
  6. 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 ...
  7. 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.
  8. 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
  9. 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"
  10. 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
  11. 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 pos
  12. 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.
  13. 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.
  14. 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 g
  15. 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 t
  • Create New...