untoldwind
-
Posts
26 -
Joined
-
Last visited
-
Days Won
1
Content Type
Blogs
Gallery
Downloads
Events
Profiles
Forums
Articles
Media Demo
Everything posted by 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
-
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 ...
-
@Benzi: Cool, thanks for that - I was wondering a bit by myself. Just merged it to the current version. Hurray for social coding @raguary: I fear, I have to take a closer look at Spectacles first, to fully understand this feature. What about this: If you use the keyword "left", the window is move to the left-half (obviously), butif the window already is in the left-half, it will be increased to 2/3-left same for "right" and maybe "top", "bottom" as well The only problem is that its not that easy to detect if a window is actually in the left-half. E.g. "iterm" sets its height always according to the font-size of the terminal, so it might be a little smaller than "left-half of available screen" ... I'll try to figure something out.
-
During a (quite loooong) train ride I found some time to dig more deeply into the ScriptingBridge again. I thing I found the biggest time-consumer: Finding the main window of the frontmost application. Sounds simple enough, but if you do it the naive way (like me) it can result in lots of events being fired. I just update the workflow once again with a variant that should minimize the overhead and works quite nicely (and fast) for me. Would be nice to know if this eventually fixes the performance issues. For interested coders out there: The magic is now done in the following 4 lines of ruby code: systemevents = OSX::SBApplication.applicationWithBundleIdentifier_("com.apple.systemevents") frontmostPredicate = OSX::NSPredicate.predicateWithFormat("frontmost == true") frontmost = systemevents.processes().filteredArrayUsingPredicate_(frontmostPredicate).first window = frontmost.attributes().objectWithName_("AXMainWindow").value().get()
-
Hmm... that's funny, obviously I misinterpreted the "Argument required"/"Argument optional" switch in the Alfreds Script-Filter. Now there should be a full list if you just type the keyword. There "Order by frequency" is tougher though. I was kind of hoping that Alfred would do that on itself, I think there is already a Feature-Request for this.
-
I just pushed a new version to github. The ruby-variant is now "official" (its still not really performant, but smoother than python) New keywords: center: Move a window to center of screen with 10% border (see previous post) togglefullscreen: Toggles full screen mode. Thanks for the little Apple-Script once again. I also added an example how to add hotkeys to the workflow. As for the performance issues: I somewhat gave up on atomac and kind of wait for 10.9 if there are any changes/improvements to the scripting bridge. To my understanding multi-screen support will change, so I'll most likely have to tweak the scripts anyway.
-
Sure another keyword is no biggy. My current version of the workflow is kind of messed up since I was experimenting a bit, which let me in the ugly depths of MacOS accessibility ... or hell, depending on the point of view Anyway, the list of keywords is in the "layout_select.py" file: layouts = [ Layout("full", "Full", "0,0,1,1"), Layout("left", "Left", "0,0,0.5,1"), Layout("top", "Top", "0,0,1,0.5"), Just add a line there, like: layouts = [ Layout("center", "Center", "0.1,0.1,0.9,0.9"), Layout("full", "Full", "0,0,1,1"), Layout("left", "Left", "0,0,0.5,1"), Layout("top", "Top", "0,0,1,0.5"), And it should to the trick. The format of the last part is "<left>,<top>,<right>,<bottom>" in relative coordinates, i.e. "0.1,0.1,0.9,0.9" means "center with 10% border", "0.2,0.2,0.8.0.8" would be 20% and so on. I'll include this in the next "release" sometime this week, once I've mopped up a bit.
-
Thanks for all the feedback. Lets focus on the most pressing issue first: I also noted this short flicker of the "python.app", I just did not realized that it might be *that* slow. This seems to related to PyObjC and/or the ScriptingBridge. As an experiment I reimplemented the main script in ruby, which seems to run much more smoothly (as I can tell). You can find this in a separate branch on github: https://github.com/untoldwind/alfred2-layout/raw/ruby/Layout.alfredworkflow (Hopefully this helps...) As for the full-screen mode: Thanks for the short script, I'll experiment with it and figure out how to integrate it into the workflow. And thanks for the hint to Spectacle, so far I was just aware for several Shareware (closed-source) applications in this regard. I did a short code-dive there, at its core Spectacle seems to use the ZeroKit, which is a small Objective-C wrapper around the Accessibility-API. This is quite informative, but I'm not sure if it is possible to do any of this from within a python,ruby,whatever-script ... without the use of some native wrapper like the already mentions atomac.
-
To my knowledge there is not generic way to toggle the full screen mode via scripting, at least I've found no such property/action so far. Of course it should be possible to trigger a menu-item event, which would be application-specific though and quite cumbersome to maintain. At the moment I'm taking a look at Atomac (https://pypi.python.org/pypi/atomac/1.1.0). Even though it is a testing framework, it circumvents some of the restrictions I've encountered with the scripting bridge. Not sure though if I can (or should) include this in an Alfred workflow
-
Ok, that one was/is more tricky ... In short: Adium should work now (I checked the 1.5.7 version) Longer story: As said before I try to move the window directly if the application supports scripting. Adium actually does support scripting, but - to my understanding - the "windows" array is supposed to be ordered by z-index (i.e. the top-most window should be at first position). For some reason Adium thinks differently and always reports the "Contacts" window first, regardless which window actually has focus. I'm a bit new to this MacOS-scripting business, so I'm not entirely sure if this is a bug in Adium or not. Anyway: I solved this by putting Adium on a blacklist, so that its windows are moved by SystemEvents as well, which seems to produce the correct results. Maybe there is a better solution ...
-
Well, that should be rather easy to fix. I just added a white (non-transparent) background to all icons in the current version.
