The KDE Daemon global shortcuts allow to choose a shortcut for Take Rectangular Region Screenshot, it defaults to Meta+Shift+PrtScr.
However that takes a screenshot with the mouse pointer, how do I disable that?
When I open Spectacle, the includeMousePointer is not checked, so apparently that's a different setting.
Apparently this commit seems to say it's possible to do so but I don't know how.
If you press the hotkey, a D-Bus command is invoked. These commands accept arguments instead of looking at configuration files for maximum flexibility.
The actual D-Bus command that you would need to invoke is:
qdbus org.kde.Spectacle / org.kde.Spectacle.RectangularRegion false
The argument for this RectangularRegion method indicates the value for includeMousePointer. The commit you referenced indeed makes the default hotkey action call this with a true argument instead of false.
If you want to change the default, edit spectacle.khotkeys file in your system. Locate the [Data_1_4Actions0] section, and change Arguments=true to Arguments=false. The result should look like this:
[Data_1_4Actions0]
Arguments=false
Call=RectangularRegion
RemoteApp=org.kde.Spectacle
RemoteObj=/
Type=DBUS
It might be required to restart your session after changing this.
Related
By default Terminal.app has a keybinding for ⌘+↑ that scrolls the screen back to (and briefly highlights) the previous command prompt. (This seems to be independent of shell although I've only tried a couple. I'm using bash.)
I'm trying to get similar behavior in iTerm2, but I haven't found a mapping that does that. None of the search terms I've tried in iTerm2's list of key mappings suggest anything like this function. The iTerm2 mapping preset called Terminal.app Compatibility causes ⌘+↑ to scroll through previous commands, the same way ↑ does, rather than the window scrolling back to the lines on which previous commands were input.
Based on this answer to a similar question, I looked through the output of bind -p and see entries "\e[A": previous-history and "\e[B": next-history, but these seem to be describing the scrolling through previously-entered commands rather than scrolling through the entire terminal window output to the prompt at which the command was input. These are the only bind -p entries that refer to up or down arrows (if my assumption is correct that [A refers to the up arrow, which I determined with xxd -psd as suggested in this answer.
Is this behavior in Terminal.app the result of a key binding? Or, how would I determine whether it is or not? And is there a way to get iTerm2 to duplicate this behavior?
Have you tried
fn + CMD + UpArrow ?
Only an ersatz for Terminal.app "going up one prompt at a time” behavior, but maybe helpful as it makes iTerm2 do a Full Page Up consistently across my custom profiles and various key map preferences.
With shell integration installed, iTerm2 creates a "mark" at each prompt, and the default shortcut for moving to the previous mark is ⌘+⇧+↑.
Is there a way to tell Intellij IDEA 14 to always show the parameter tooltip that appears when you start writing a function? The problem is that the "bubble" disappears when you exit the parentheses and doesn't show up again when you re-enter.
As far as I know there is no configuration option to always display the parameter tooltip. However you can invoke it manually when you reenter the method using CTRL+P (or ⌘+P on Mac).
References
IntelliJ Help: Viewing Method Parameter Information
I think JetBrains should change this default behavior, or at least add an option for it.
For now, here are some workarounds:
Use CTRLP or make a custom key binding such as CTRL;.
Settings / Keymaps / Parameter Info / Add Mouse Shortcut.
Delete and then retype the opening parenthesis.
When I type :e, MacVim automatically expands this to :Edit. The problem with this is that I can't discard my current buffer with :Edit!, because I get an error message saying that "!" isn't allowed.
I have two questions:
Why does :edit! work and not :Edit!
Is there a way to disable this auto-expand feature in MacVim, or perhaps switch it to expand to :edit! and not :Edit! ?
Thanks!
If the expansion happens immediately after typing the e, it might be due to a command-mode mapping (i.e. :map!, :cmap or :lmap). If it is only expanded after typing e followed by a space (or enter), then it might be an abbreviation (i.e. :abbreviate or :cabbrev).
You can temporarily avoid a mapping-based expansion by typing Control‑V or Control‑Q before e. Another workaround is to type Control‑F while entering a command-line command (i.e. you are at the : prompt; or type q: instead of : when starting a command). This will bring up the command-line window so that you can edit your command via normal/insert modes (this avoids all command-line mode mappings).
Once you have a way to enter e into a command-line again, you can use :verbose to find the source of the mapping:
:verbose cmap e
(You must either use the command-line window to type this literally, or enter it at the command-line by typing a Control‑V or Control‑Q before each e.)
This will show you the definition of the mapping. Additionally, if it came from a plugin, then the source will be identified with a second line like Last set from /path/to/some/file.
Checking for an abbreviation is a bit tricker since there are two chances for expansion (while typing and when the command line is being parsed):
:verbose cab ^Ve
The ^V needs to be an actual Control‑V. Usually you accomplish this by typing Control‑V twice (or Control‑Q, then Control‑V).
As for the Edit command itself, it is not a built-in command, so something plugin must be defining it. Very few built-in commands start with an uppercase letter, and all “user defined” commands must start with one; see :help E183.
You can use :verbose again to find where :Edit was defined:
:verbose command Edit
I suspect the mapping/abbreviation and the command probably come from the same place.
You can manually disable a mapping-based expansion with :cunmap and an abbreviation-based expansion with :cunabbrev:
:cunmap e
:cunabbrev ^Ve
Again, you may need type Control‑V or Control‑Q before each e, and the ^V must be a literal Control‑V (type Control‑V twice to enter it).
Unfortunately, you can not just put these in your ~/.vimrc if the definitions are coming from a plugin because plugins are loaded after ~/.vimrc. You should investigate the plugin to see if it offers a option to disable the intrusive mapping. Sometimes plugins check a :let variable to see if they should enable some feature. Maybe your problematic plugin has a “knob” that will let you tell it not to install its e -> Edit expansion. If not, you might be able to report a bug about :Edit! not working properly and ask for a way to disable the expansion too.
Do you use TextExpander, Typinator or some text expansion utility? If yes, those might be the culprit. As far as I know, MacVim does not expand text like that.
I come from a .Net world so I'm used to just hovering over a variable while debugging and seeing what its value is.
In Objective-C I am incredibly confused on how to do that.
If I hover over it, I get a small popup with lots of information...that doesn't help me at all.
For example, I have an object called "myServer" and it is an instance of a "Server" that I have created through CoreData. One of its properties is "root" which is a simple NSString.
I cannot for the LIFE of me figure out how to view what the value of [myServer root] is.
Can some please give me some advice on this?
In the gdb console, type
po [myServer root]
I like to use GDB from the command line. Open a terminal and type
gdb
attach <your process name>
(be sure your program was built with debugging symbols). Then, when your variable name is in scope (e.g. when you break somewhere relevant) type
po variableName
to view its contents.
Another nice way to deal with this is to log directly from a breakpoint.
To do this, create a breakpoint after the value you want to see has been set, then edit it. Add a breakpoint action of 'log', and put the expression you want logged within a pair of # symbols. Check the box to the right, ensuring that the breakpoint doesn't actually cause a stop. The value will be output to the debugger console on doing a run & debug.
Doing it this way you (a) don't clutter your source, (b) can dis/enable the breakpoint at will according to your immediate needs, and (c) don't need to stop execution.
This and other very handy xcode tips can be culled from Joar Wingfors' 'Debugging with Xcode' talk.
I have an msi (authored with WIX) that has a check box bound to a custom property (call it MY_PROPERTY). I would like to run this msi from the command line, specifying 0 (unchecked) or 1 (checked) for this property. My script will determine the appropriate value (based on the environment) and inject that value into the msiexec command line. My command line looks something like this:
msiexec /i my_installer.msi MY_PROPERTY=$value
Where $value is 1 or 0, depending on the environment. The problem is that no matter what value I supply for MY_PROPERTY at the command line, the check box is always checked (and the property will always be set to 1). The only way to make the checkbox unchecked is to not specify the property (leave it undefined). It should be noted that this behavior occurs regardless of whether or not the UI is showing (adding "/quiet" to the above command line doesn't change this behavior).
This msdn post seems to indicate that this is a known "bug" in windows installer (or more accurately, whatever authoring system wrote the msi). A post-build msi hack is proposed as the solution. I'm wondering if anyone has encountered this issue and come up with a better workaround/solution. Thanks!
Update
I see three solutions to this problem:
From #Damien, have the wrapper script not pass the property to msiexec when its value is 0. This makes the script more complex and would probably prevent me from being able to override the value of a check box that defaults to "checked".
From #Michael Urman, add a custom action that clears the property if its value is zero. This makes the msi more complex, and I would have to add such a custom action for every check box in the UI.
Another idea is to simply disallow the use of check boxes in our msi installers, and use radio boxes or drop-downs for "true/false" questions instead. While this restricts the UI options for our installers, it woudl allow the wrapper scripts to remain simple, and does not require custom actions to "hack" the properties.
I'm currently leaning towards option 3, although option 1 is probably the best answer to my original question. Any thoughts?
This is how it is "supposed" to work - basically, the property doesn't exist until a user checks the checkbox, then it is "set" (exists). So if you want to do a custom action when a checkbox is checked, you test for the existence of the property as a condition for running the custom action, instead of checking for the value that the custom prop is set to.
I think the best way to handle this from the command line is what you have already mentioned: if you want the checkbox to be selected, specifiy the custom prop on the command line, otherwise, don't and the checkbox will not be selected.
As you've discovered, checkboxes are true (checked) when the property is defined (non-blank) and false (unchecked) when the property is undefined (blank). It sounds like you need to convert an environment 1 or 0 string to a checkbox true/false, where the 1 or 0 is passed in at the command line. Try using a set-property custom action that sets your property to {} (blank) with a condition of when the property is already "0". Schedule it early in both the Install UI and Install Execute sequences.
Late Update: Regarding the need for multiple custom actions to handle this for multiple checkboxes, you have a choice. You can either create multiple set-property actions (benefit: easy to tell what they're doing; cost: many of them), or you can create a single code-based custom action which walks the Checkbox table for a list of properties to convert from 0 to blank (benefit: one action; cost: poorly documented, custom code). A secondary advantage to the latter approach is that you can handle unusual Value settings, such a check box that should set the property to 0 when checked.