Motif-based window managers (Mwm, Dtwm, 4Dwm, 5Dwm) allow custom menu items (with the corresponding callbacks) to be added to the application's window menu (see the screenshot, gist available here). The application itself is also required to link with -lXm (at least for XmAddProtocols() and XmAddProtocolCallback() to be available).
From the X Window perspective, this is achieved via a couple of extra Atoms set by the client:
_MOTIF_WM_MESSAGES(ATOM) = _MOTIF_WM_OFFSET, CUSTOM_MENU_ACTION_A, CUSTOM_MENU_ACTION_B
WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, _MOTIF_WM_MESSAGES
_MOTIF_WM_MENU(STRING) = "no-label f.separator\n
Custom\ Menu\ Title f.title\n
XTerm f.exec \"xterm &\"\n
Custom\ Menu\ Action\ A Shift Alt<Key>F1 f.send_msg 393\n
Custom\ Menu\ Action\ B Shift Alt<Key>F2 f.send_msg 394\n"
Apparently, this behavior is not supported by any of the modern EWMH-compliant window managers. Additionally, EWMH specification doesn't seem to provide any alternative.
Is there any non-Motif cross-WM way to manipulate the window menu (GTK, Qt or Xlib)?
Related
I'm running on Windows 10, but using Delphi 7 (yes, I know it's quite old).
I want to use the system icons in Windows and have gone about this by defining a TImageList called SystemIcons which I initialize as follows:
var
fileInfo: TSHFileInfo;
begin
SystemIcons.Handle := ShGetFileInfo('', 0, fileInfo, SizeOf(fileInfo),
SHGFI_ICON or SHGFI_SMALLICON or SHGFI_SYSICONINDEX);
...
I have SystemIcons properties set statically as a TImageList component with width and height set to 16.
Elsewhere, I wish to retrieve an icon from this image list given a valid shell object's image index. Because these are "small system icons", I expect them to be 16x16. The result of calling GetSystemMetrics(SM_CYSMICON) yields 16. Oddly, the dimensions depend upon whether I retrieve them as a bitmap or an icon.
...
var
icon: TIcon;
bm: TBitmap;
begin
...
icon := TIcon.Create;
SystemIcons.GetIcon(imgIndex, icon);
bm := TBitmap.Create;
SystemIcons.GetBitmap(imgIndex, bm);
The imgIndex is correct and the same in both cases. The image retrieved is the same in each case, as expected. The dimensions of the bitmap (bm.Width and bm.Height) are also as expected: 16x16. However, the dimensions of the icon (icon.Width and icon.Height) are not. They are 32x32.
When I paint the icon on a canvas it appears as 16x16. So it's only its Height and Width values that appear incorrect. Very odd.
Why are these different?
The images are likely actually 32x32 to begin with.
Internally, TImageList.GetIcon() simply retrieves an HICON for the chosen image directly from the underlying Win32 ImageList API, using ImageList_GetIcon(), and assigns that to the TIcon.Handle property.
TImageList.GetBitmap(), on the other hand, is a bit different. It sizes the TBitmap to the dimensions of the TImageList (16x16), and then stretch draws the chosen image onto the TBitmap.Canvas using TImageList.Draw(), which in turn uses ImageList_DrawEx().
I have installed vim-mode-plus package and added the following keymap bindings in the keymap.cson file.
'atom-text-editor.vim-mode-plus.normal-mode':
'ctrl-j': 'focus-pane-or-panel:focus-below'
'ctrl-k': 'focus-pane-or-panel:focus-above'
'ctrl-h': 'focus-pane-or-panel:focus-on-left'
however I am not able to switch between the panes ( I am on Windows)
I am able to switch if I use a built-in keybinding as below:
ctrl-w ctrl-j window:focus-pane-below Vim Mode Plus atom-text-editor.vim-mode-plus:not(.insert-mode)
Above is copied from the Keybindings search results in atom
I don't think you are using the right command names. If you open the Command Palette (CtrlShiftP), you can search "focus" and find the various commands available for what you're trying to do.
Window: Focus Pane Above
Window: Focus Pane Below
Window: Focus Pane On Left
Window: Focus Pane On Right
To turn these into keybind command names, apply this formula:
Lowercase everything
Remove the space after :
Replace remaining spaces with hyphens
This gives the keybind command names:
window:focus-pane-above
window:focus-pane-below
window:focus-pane-on-left
window:focus-pane-on-right
Also notice the working example you point to uses a different selector than you are using. It uses atom-text-editor.vim-mode-plus:not(.insert-mode) rather than atom-text-editor.vim-mode-plus.normal-mode. That may be a better option, so your key bindings would work in modes other than normal mode (such as visual select mode).
I think what you need is:
'atom-text-editor.vim-mode-plus:not(.insert-mode)':
'ctrl-j': 'window:focus-pane-below'
'ctrl-k': 'window:focus-pane-above'
'ctrl-h': 'window:focus-pane-on-left'
And I'm not sure if you also wanted CtrlL to work, e.g.
'ctrl-l': 'window:focus-pane-on-right'
I just switched from Sublime Text to Atom in order to turn completely open source.
I have trouble with something very very simple: I want Atom to use always (!) and under any circumstances tab width 2 and replace tab with spaces. This setting is so simple in gedit or Sublime Text, but no matter what I am trying: When I start a new file, tab size is 2 (good!). When I use an existing file, tab size is sometimes 4. I find that a bit annoying.
My current setting in Editor are seen in the screenshot:
There is more than one tab setting
Each package (such as python-language) has its own tab setting(s). Whether the language uses the global default or its own default is up to whoever created the package, but you can generally override it.
In your screenshot, you have set the "Tab Type" to "soft". That will take care of using spaces rather than tabs. You have left the default tab width of 2. That is your global setting.
Now, if you look under "Packages" and search for "python" you will find a package named "language-python". Click on its settings button and you will find a number of syntax-specific settings.
Python Grammar
Python Console Grammar
Python Traceback Grammar
Regular Expressions (Python) Grammar
Each of those grammars has its own Tab Length setting. You can set them explicitly to 2 here to override the package's default. (You probably mostly care about the first one, Python Grammar.)
Python is different
In the case of Python, the package is explicitly configured to default to 4 spaces, probably because Python is very opinionated about whitespace, and PEP 8 recommends 4-space indents. You can see the default package setting here in the package's source:
https://github.com/atom/language-python/blob/master/settings/language-python.cson
'autoIndentOnPaste': false
'softTabs': true
'tabLength': 4
This overrides the global default. That's why Python Grammar does not honor the global tab width, the way that most packages do.
Sometimes there are package overrides
Additionally, certain packages will override your settings for syntax reasons. For example, language-make will override and use real tabs instead of spaces, because that is required by make.
In the case of Python, there is an override to use spaces. The language-python settings page offers a spot for you to change the indentation level, but it does not offer a way to switch to using tab characters. (That's probably justifiable, as tab characters and mixed indentation in Python are a very common cause of difficult-to-debug syntax errors.)
You might need to reload
Lastly, sometimes settings don't take effect completely until you reload the Atom window. You can use the Window: Reload command to do so. Or using the keyboard:
Mac: CtrlOptCmdL
Windows/Linux: CtrlAltR
This is what worked for me.
Disable all non-default packages
Open ~/.atom/config.cson, and append this (same level than the "*" element)
:
".python.source":
editor:
autoIndent: true
tabLength: 2
Re-enable all packages.
I got this help from someone else. Not my own discovery. However, for confidentiality, I cannot cite the source.
Based on soham's answer, I found that setting all tabLength: fields in ~/.atom/config.cson (assuming osx) to your desired length solved the problem.
I'm having trouble updating graphical elements in R and I can't figure it out. I'd appreciate a little push.
I'm trying to make a simple GUI which is prepopulated with some options, but when a button is pressed the database is queried (the query is modified by the GUI), and the result needs to change what's available in the gcomboboxes and gtables. I'm frankly amazed at how simple it is to create such an excellent environment in R.
I don't believe I can modify the body of gcomboboxes or gtables once they're on screen (if I can, that's probably my preferred solution). I also don't believe I can destroy individual elements of a glayout, only the entire glayout. But how do I get it back in the right order?
# Small example for GUI element creation and destruction
if(!require("RGtk2")) {library("RGtk2")}
if(!require("digest")) {library("digest")}
if(!require("cairoDevice")) {library("cairoDevice")}
if(!require("gWidgets")) {library("gWidgets")}
if(!require("gWidgetsRGtk2")) {library("gWidgetsRGtk2")}
nw<-gwindow("Test",toolkit=guiToolkit("RGtk2"))
g<-ggroup(horizontal=FALSE,cont=nw)
t1<-glayout(container=g) # Header
t2<-glayout(container=g) # Dynamic middle
t3<-glayout(container=g) # Footer
t1[1,1]<-gcombobox(c("foo","bar"))
t1[1,2]<-gbutton("Update")
t2[1,1]<-gframe("",container=t2)
t2[2,1]<-gcombobox(c("violin","metal"))
t2[3,1]<-gtable(c("YoYoMa","Metallica"))
t3[1,1]<-glabel("Filler text",container=t3)
delete(g,t2) # Unable to delete t2[2,1] and t2[3,1]
t2<-glayout(container=g)
#t2[2,1]<-gcombobox(c("violin","metal","pop")) ### Nope...
#t2[3,1]<-gtable(c("YoYoMa","Metallica","UB40"))
#add(t2,gcombobox(c("violin","metal","pop"))) ### Nope...
#add(t2,gtable(c("YoYoMa","Metallica","UB40")))
All my added elements go below my footer text. How do I straighten it out so they go between the header and footer?
If I don't delete the glayout, it looks like I can modify the contents of the gcombobox, but the UI doesn't really reflect it. I can see new text when I click the arrow, but the selection no longer appears to change.
...
t2[2,1]<-gcombobox(c("text to remove","violin","metal"))
t2[3,1]<-gtable(c("YoYoMa","Metallica"))
t3[1,1]<-glabel("Filler text",container=t3)
t2[2,1]<-gcombobox(c("violin","metal","pop")) # "text to remove" remains selected regardless of user input
t2[3,1]<-gtable(c("YoYoMa","Metallica","UB40"))
It was a little frustrating, but this is working well for me. I'll leave this solution here in case anybody else has trouble.
# Small example for GUI element creation and destruction
if(!require("RGtk2")) {library("RGtk2")}
if(!require("digest")) {library("digest")}
if(!require("cairoDevice")) {library("cairoDevice")}
if(!require("gWidgets")) {library("gWidgets")}
if(!require("gWidgetsRGtk2")) {library("gWidgetsRGtk2")}
nw<-gwindow("Test",toolkit=guiToolkit("RGtk2"))
g<-ggroup(horizontal=FALSE,cont=nw)
t1<-glayout(container=g) # Header
t2<-glayout(container=g) # Dynamic middle
t3<-glayout(container=g) # Footer
t1[1,1]<-gcombobox(c("foo","bar"))
t1[1,2]<-gbutton("Update")
t2[1,1]<-gframe("",container=t2)
t2[2,1]<-gcombobox(c("text to remove","violin","metal"))
t2[3,1]<-gtable(c("YoYoMa","Metallica"))
t2[3,1]<-gtable(BandList)
t3[1,1]<-glabel("Filler text",container=t3)
t2[2,1][]<-c("violin","metal","pop")
svalue(t2[2,1])<-"pop" #otherwise it's confused about defaults
t2[3,1][]<-c("YoYoMa","Metallica","UB40")
I found a way to edit the contents already on screen without needing to delete the screen elements.
# Small example for GUI element creation and destruction
if(!require("RGtk2")) {library("RGtk2")}
if(!require("digest")) {library("digest")}
if(!require("cairoDevice")) {library("cairoDevice")}
if(!require("gWidgets")) {library("gWidgets")}
if(!require("gWidgetsRGtk2")) {library("gWidgetsRGtk2")}
nw<-gwindow("Test",toolkit=guiToolkit("RGtk2"))
g<-ggroup(horizontal=FALSE,cont=nw)
t1<-glayout(container=g) # Header
t2<-glayout(container=g) # Dynamic middle
t3<-glayout(container=g) # Footer
t1[1,1]<-gcombobox(c("foo","bar"))
t1[1,2]<-gbutton("Update")
t2[1,1]<-gframe("",container=t2)
t2[2,1]<-gcombobox(c("text to remove","violin","metal"))
t2[3,1]<-gtable(c("YoYoMa","Metallica"))
t2[3,1]<-gtable(BandList)
t3[1,1]<-glabel("Filler text",container=t3)
t2[2,1][]<-c("violin","metal","pop")
svalue(t2[2,1])<-"pop" #otherwise it's confused about defaults
t2[3,1][]<-c("YoYoMa","Metallica","UB40")
I'm a new Atom user and I want to override the Atom command palette (shift-ctrl-p) scrolling key bindings to something more vi friendly like
ctrl-n and ctrl-p instead of the annoying arrow keys (which force me to take my hands off the home row).
Just to be clear, I don't want to change the key binding that brings up the command palette, but the key bindings you use to scroll through the list once it's up:
I can only find a binding to override the command palette toggle:
As you can see in the following config file, I was able to override the autocomplete scrolling, and I hope to do the same with the command palette. I've tried 'command-palette:up' ,'command-palette:down' and 'command-palette:move-up' etc. to no avail.
Here's is my keymap.cson.
# Atom Flight Manual:
# https://atom.io/docs/latest/using-atom-basic-customization#cson
#vt add
'body atom-text-editor.autocomplete-active':
'ctrl-p': 'autocomplete-plus:move-up'
'ctrl-n': 'autocomplete-plus:move-down'
'alt-p': 'autocomplete-plus:page-up'
'alt-n': 'autocomplete-plus:page-down'
'home': 'autocomplete-plus:move-to-top'
'end': 'autocomplete-plus:move-to-bottom'
# vim-plus ex mode 2016-04-18
'atom-text-editor.vim-mode-plus.normal-mode':
':': 'vim-mode-plus-ex-mode:open'
'!': 'vim-mode-plus-ex-mode:toggle-setting'
# add cmd palette key bindings --> These do not work.
'body .native-key-bindings':
'ctrl-p': 'command-palette:up'
'ctrl-n': 'command-palette:down'
#vt end
I've been really impressed with the key binding support in Atom thus far. I'd be really surprised if it couldn't handle this but, alas, I think this might be the case.
Does anyone know of a way to do this?
Atom 1.7.2, linux
I was able to get single line scroll to work, but not page scroll to work with the following in my keymap.cson:
'atom-workspace':
# these work
'ctrl-p' : 'core:move-up'
'ctrl-n' : 'core:move-down'
# these don't work
'alt-p' : 'core:page-up'
'alt-n' : 'core:page-down'
It would be nice to have page scroll as well, but I should be able to narrow down the list down by typing in text, so I don't foresee needing page-up, page-down all that often.
Now I'm happy.
To target keybindings for just the command palette, you can find an appropriate selector by looking in the command-palette repo keymaps: https://github.com/atom/command-palette/blob/v0.43.5/keymaps/command-palette.cson
This suggests the use of the .command-palette selector, which seems more appropriate then atom-workspace.
'.command-palette':
'ctrl-n': 'core:move-down'
'ctrl-p': 'core:move-up'
I was not able to find a mapping to scroll a page at a time within the command palette, though I'm sure someone else can figure it out. The keyboard page up/down keys have no effect so mapping to core:page-down etc. is not going to work.