While using the amazing Python Jedi plugin from GVim, I have started noticing some odd behavior with function completion tips popup (not the autocomplete as far as I can tell).
Firstly, while the function argument helper popup is visible, GVim input becomes laggy, even for builtin functions and standard types. Once the popup is closed, lag disappears. Autocomplete seems to work just fine on all levels, this lag seems to only apply to the function helper.
Secondly, I recently had a case where a popup became frozen in the buffer, even after it should have closed, and actually replaced the contents of the buffer at that location in the file. I finished the function I was working on, and then used :/__init to jump cursor location. My window scrolled down, but apparently the original function popup didn't clear, and become a fixture in my text.
When I saved the file, that line was replaced with the popup contents (obviously threw an Exception when python tried to execute that line). Going back to that location in the file, reactivating that function help popup and then closing it again fixed the frozen popup text.
Are these problems related?
Is this an aggressive configuration setting that I should change. Honestly those popups are a bit too aggressive for my liking sometimes, so how do I disable/hotkey-bind them in the configuration?
I have only experienced this behavior in GVim. Maybe it happens in console vim, but I have not tried to reproduce the situation, so I don't know.
GVim circumstances:
7 tabs open
each tab usually has two vertical windows
each window is usually a separate python module
There's a multitude of issues about this on jedi-vim's issue tracker: https://github.com/davidhalter/jedi-vim/issues/217. The whole lag situation is slowly getting better.
One of the easiest solutions is to just disable call signatures:
g:jedi#show_call_signatures = "0"
As of now (I just merged that), there's another way of displaying call signatures:
The call signatures can be displayed as a pop-up in the buffer (set to
1, the default), which has the advantage of being easier to refer to,
or in Vim's command line aligned with the function call (set to 2),
which can improve the integrity of Vim's undo history.
You could try if you like this better (but you have to update jedi-vim):
g:jedi#show_call_signatures = "2"
Is there a command to reset all variables to 0 and clean all textfields?
Like, if you go in the iOS-Simulator, then iOS-Simulator up in the Menu -> Clear Preferences and Contents (or something like this... in german: Inhalte und Einstellungen zurücksetzen).
That would be much easier to reset all data instead of setting all variables manually to 0.
If I understand the context of your question correctly, NO there is no command to reset all the variables of your currently visible user interface in the simulator to zero and/or blank.
Think about it -- the simulator would need to know some intimate details about the guts of your application, details that are probably only available only at compile time.
If you want to clear our variables or text fields or whatever, it would be smarter to have a UIButton in your interface available temporarily (for debugging purposes only, if you want) that would do what you want to do while you are testing things out.
I am making a program called "BasicSys". It is a BASIC System simulator that uses a textbox for the console. So far I have everything working great but I need to have the text box act like a command prompt window. It needs to be able to ask for input and retreive the value without allowing the user to modify anything outside of the prompt space (the space where the user should only be able to type is after a ":" or a ">"). Some feilds are password feilds that require either no echoing or having the chartacters replaced by *'s. Is it possible to make a console out of a textbox?
P.S. I also want to know if there are any small BASIC v2 compilers for Win32 so BasicSys can compile and run BASIC programs.
Depending on how realistic you want it to be you can use the API to open a real console window and interact with it. There are many examples available that you can find by searching such as this one. My suggestion though would be to fake it with a multi-line textbox. It would not be very tricky. Set an index every time you draw the prompt, then as long as the cursor is positioned after the index the textbox is read / write. If the user scrolls backwards make the textbox read only. It should be fairly simple using the KeyDown event and setting the ReadOnly property True / False to get a passable "command" window.
I'm trying to figure out how to get the current space # from mission control. Source would be helpful, but more helpful would be info on how to figure this out myself. I've written a few applescripts, but more often than not it seems like any time I need to do something new (that I can't find dictionary documentation for) it falls under the category of "tell this specific app (e.g. "System Events") this very specific thing" and I've no clue how I would actually figure that out.
Specifically what I am trying to do:
I hate the new mission control in OSX 10.7. I want my spaces "grid" back since I used it all the time. I used to navigate between spaces using arrow keys (e.g. ALT+↑) every few seconds. Now I'm stuck with this clunky 1x9 array of spaces instead of an elegant 3x3 grid. I've re-mapped all my spaces to use the number pad, which partially takes care of the problem (since it is a 3x3 grid), but only when I have an external keyboard attached.
Basically, I want to be able to use ALT+↑ and ↓ again, but to do so I need to detect the current space # so that I can switch from space 5-->2, for example.
Dave's answer below, although far more detailed than I expected, requires writing an app to do this (plus it still doesn't fully answer the question). If it's at all possible, I'd rather just bind a few keys to an applescript.
I'm trying to figure this out myself. Not there yet, but in the right direction:
Each Mission Control "space" gets a uuid assigned to it...
...except for the very first one (AFAIK), and the Dashboard one.
You can read them here:
$ defaults read com.apple.spaces
$ defaults read com.apple.desktop
File locations:
~/Library/Preferences/com.apple.spaces.plist
~/Library/Preferences/com.apple.desktop.plist
Here's mine. I have four spaces enabled, and three entries show up:
$ defaults read com.apple.spaces
{
spaces = (
{
type = 0;
uuid = "9F552977-3DB0-43E5-8753-E45AC4C61973";
},
{
type = 0;
uuid = "44C8072A-7DC9-4E83-94DD-BDEAF333C924";
},
{
type = 0;
uuid = "6FADBDFE-4CE8-4FC9-B535-40D7CC3C4C58";
}
);
}
If you delete a space, that entry will get removed from the file. If you add a space, an entry will be added. Again, there's never an entry for Desktop 1 or Dashboard.
I'm not sure if there's a public API to figure out what space uuid is being displayed on a display. I'd assume that no uuid means Display 1, and the others' mean Display 1+n.
I took a quick glance through the AppleScript Editor Library (Window ---> Library) and didn't see any entries under System Events for spaces. This is probably something that can be done with Cocoa, perhaps via private API, but I'm not sure about AppleScript.
UPDATE - July 23, 2011
It looks like Dock controls Mission Control. You can grab its header files like so:
Go to: /System/Library/CoreServices/Dock
Right-Click and Show Package Contents
Navigate: /Contents/MacOS/
Copy and paste the Dock binary to your desktop.
Run: $class-dump ~/Desktop/Dock
That'll spit out all of its header files (it's long; almost 7,500 lines). You can see the spaceUUID strings appearing in there. There's a class called WVSpace which appears to represent a single Space in Mission Control, and a lot of other WV* classes.
I'll keep looking at it tomorrow; too tired now. :)
UPDATE - July 24, 2011
Inside Dock there's a class called WVSpaces. It has a number of attributes including:
WVSpace *currentSpace;
unsigned int currentWorkspace;
WVSpace *nextSpace; // Space on the right???
WVSpace *previousSpace; // Space on the left???
BOOL currentSpaceIsDashboard;
BOOL dashboardIsCurrent;
...lots more...
Each WVSpace class has an NSString *_uuid; attribute, which is likely its SpaceUUID. So theoretically you can get the current space number like so:
WVSpace *currentSpace = [[WVSpaces sharedInstance] currentSpace];
NSString *currentSpaceUUID = [currentSpace _uuid]; // Empty string if main space???
The trick is, how to get access to the private WVSpaces class buried inside of Dock? I'm assuming it's Singleton as it has an NSMutableArray *_spaces; attribute, probably with every space listed in it. Only one space gets displayed at a time (this holds true if you're using multiple monitors; the space spans across both of them), so it makes sense to only have one WVSpaces instance.
So it looks like it'll require some SIMBL hacking of Dock to gain access to WVSpaces.
I've been poking around, and I came up with this: https://gist.github.com/1129406
Spaces have a nonsequential ID and a sequential index (0-based). You can get the ID in two ways:
from public APIs (see get_space_id)
from the private CGS API CGSGetWorkspace
You can set the current space by index using public APIs (though the notifications themselves are not publicly documented): see set_space_by_index
You can set the current space by ID using private the CGS API CGSSetWorkspace.
You cannot get the current space index directly. However, if you're always using the same set of nine spaces, you can rotate through them once using set_space_by_index, collect their IDs, and build a mapping. Then you will be able to get the current index from the ID.
... also been working on this :)
You say that you "need to to detect the current space #". This is not strictly true: To move down one row, you just move 3 spaces right, so in principle you could just bind something like
tell application "System Events" to tell process "WindowServer"
key code {124, 124, 124} using control down
end tell
to Alt-down (with FastScripts, Alfred or some other fast method that avoids the overhead of Automator). This approach will fail if you ever hit down in the bottom row, of course -- but if you are truly hard-wired, you never do :)
You have to "Enable access for assistive devices" in the Universal Access preference pane for the key code approach to work.
Caveat: This doesn't work. When I launch the script above, I nicely jump three spaces. The problem is that afterwards my keyboard goes unresponsive: It seems that only the window manager is receiving events: I can close windows and switch space, but I cannot interact with any applications.
My theory is that this happens when the jump causes the current application to change during the execution of the script -- but I have no idea how to fix this.
A related observation: The Mission Control (i.e. /Applications/Mission Control.app/Contents/MacOS/Mission\ Control) seems to react to some command line arguments:
Mission\ Control: show mission control
Mission\ Control 1: show desktop
Mission\ Control 2: show current application windows
I tried putting in some of the UUID's from defaults read com.apple.spaces, but that didn't do much. So much for fumbling in the dark.
I wrote an app - does it work for you?
Change Space.app
The keys to make it work are control-shift and the arrow keys, although this may be fixable if you are stuck on ALT.
Make sure you have 9 spaces (desktops) set up before you start, and you'll need to change the default ctrl-up and ctrl-down key bindings in System Preferences to something else (in Keyboard -> Keyboard Shortcuts -> Mission Control : Mission Control and Show Desktop).
On the first run it it will cycle through your desktops to enumerate them when you first change space.
Then you should be able to change between desktops like in a 3x3 grid.
There may be a few wrinkles, but it's basically functional, at least for me.
http://switchstep.com/ReSpaceApp
This works, is free (right now) and is awesome.
Just be sure to manually create as many spaces as your layout (in preferences) is expecting.
I'm on Mountain Lion and this seems to work for me.
defaults read com.apple.spaces
Look for "Current Space". You'll notice that running this command with different active spaces doesn't change the current space BUT if you check and uncheck a checkbox button in "System Preferences" and run it again, you'll see it updated.
Hopefully this helps someone else!
EDIT: It's ugly, but I'm using this:
killall Dock && sleep 0.2 && defaults read com.apple.spaces | grep -A1 "Current Space" | tail -1 | awk '{print $NF }' | cut -f1 -d';'
on openNewSpace()
tell application "System Events"
—start mission control
do shell script "/Applications/Mission\\ Control.app/Contents/MacOS/Mission\\ Control"
tell process "Dock"
set countSpaces to count buttons of list 1 of group 1
--new space
click button 1 of group 1
--switch to new space
repeat until (count buttons of list 1 of group 1) = (countSpaces + 1)
end repeat
click button (countSpaces + 1) of list 1 of group 1
end tell
end tell
end openNewSpace
I have come up with a workaround for this for myself in macOS Catalina, though I expect this should work for multiple macOS versions. This solution solves my problems, namely:
The inability to identify which desktop contains which project, because desktops cannot be named. (I usually am splitting time on work on multiple projects at once and each desktop is dedicated to work on a different project [and they all use the same apps])
The inability to programmatically(/easily) determine which desktop I'm on at any one time
The lack of tools to track time spent on each desktop
I solved item 1 quite some time back using Stickies.app. I put the project name in a huge enough font that it's easily legible in the desktop thumbnails in Mission Control and I hide the stickie window behind my Dock, assigned specifically to the corresponding project's desktop. (I also duplicate the desktop name in small superscripted text that pokes out from under the left side of the dock so that I can identify the current desktop outside of mission control.)
I just solved item 2 via applescript just now. In the stickie, I add a tiny, unobtrustive font string that identifies the stickie as the desktop name, e.g. 'dtop'. E.g. "small_superscripted_name LARGE_NAME tiny_dtop_string" or "project1 PROJECT1 dtop". Note, this script assumes that the project name contains no spaces (i.e. it's just one word). You can split on a different charcter/string, if you wish. Here is the applescript that, when run, results in the desktop name:
tell application "System Events"
--obtain the stickie with the desktop name
set dstr to name of first item of (windows of application process "Stickies" of application "System Events" whose name contains "dtop")
--Parse the desktop name from the stickie
set astid to AppleScript's text item delimiters
set AppleScript's text item delimiters to " "
set dname to first item of (dstr's text items)
set AppleScript's text item delimiters to astid
--Show the result in a dialog window
display dialog "Desktop: " & dname
end tell
And as far as item 3 goes, I have yet to implement it, but I could easily poll via a cron job by calling the script using osascript. However, I may explore the possibility of mapping the desktop keyboard shortcuts I use to trigger the script, say, after a delay like 1 second after a control-right/left-arrow, 10 seconds after F3 or control-up-arrow. (It wouldn't catch window-drags that trigger desktop changes, but that hasn't worked anyway since I started using 2 monitors.)
Once I have that set up, I'll likely output the desktop name and a timestamp to a log so I can track time spent on each desktop.
UPDATE: I did eventually solve item 3 with an Applescript run once a minute in a cron job. I also wrote a perl script to generate a bar plot of both: how much time spent on each project (i.e. desktop) over a period of time (e.g. the past week), and a per day plot showing how much time I spent on what projects each day. Here's an example:
I have just spet the last few hours trying to find the flag to use in Terminal to launch an app with the colored outlines around the various view elements to show how they are nested. I know that Matt Gemmell covered it during the Cocoa Face Off session of NSConference 2009 (at about the 13minute mark in the video). Unfortunately I can't actually read what he types and he doesn't speak the exact command. I know it has to be in the Apple docs somewhere but the search system is currently not being of any use. It looks like her just adds -showAllViews YES to the end of the command to open TextEdit but that command has no effect in 10.6.6. I have also tried every other capitalization I can think of as well as using view instead of views. Every command opens TextEdit just fine but doesn't show the colored outlines.
Use -NSShowAllDrawing and -NSShowAllDrawingColor:
/Applications/TextEdit.app/Contents/MacOS/TextEdit -NSShowAllDrawing 200 -NSShowAllDrawingColor cycle
-NSShowAllDrawing sets the delay between drawing commands (allowing you enough time to see the drawing update)
-NSShowAllDrawingColor sets the fill colour for the regions with pending drawing operations (see class methods on for NSColor for valid values, or pass it "cycle" to loop through all available colours).