I created a main window win:
win = Curses::Window.new(Curses.lines / 2, Curses.cols, 0, 0)
Then I sometimes need to create a message window, that covers the main one. After I close the message window, I refreshed win:
win.refresh
But unless I change anything in the main window using something like:
win.addstr("asd")
refresh doesn't redraw the window.
Is there a way to force redrawing the window?
It depends.
That's done using touchwin (or whatever name a Ruby binding may happen to use for the C function).
In ruby 2.0.0, the standard curses binding for Ruby lacked touchwin and touchline. Oddly enough, it included bindings for several of the ncurses extensions (resizeterm, the mouse interface, default-colors), but lacks many of the standard features (see X/Open Curses for reference).
In 2.4.1, curses is not a standard Ruby module, but the site for the module does have touchwin.
There is a method Curses::Window#touch which marks window as changed and to be redrawn by next refresh. There is also method Curses::Window#redraw which simply redraw the window.
Additional problem is getch method, which in my program is little bit unpredictable if I use Curses.getch - sometimes it causes that the window wont refresh, sometimes it causes whole screen to disappear... Using getch on window object solves the problem e.g. win.getch
Related
So I wanna make my window not moveable and resizable, is there anyway to do it? Below is my current window creation code.
testbwidgetptr->basewin = XCreateWindow(BOTIFDisplay,
tmp->drawarea,
testbwidgetptr->bwidgetx,
testbwidgetptr->bwidgety,
testbwidgetptr->bwidgetwidth,
testbwidgetptr->bwidgetheight,
0, CopyFromParent, InputOutput,
CopyFromParent, valuemask, &winatt);
XSetWindowBackground(BOTIFDisplay, testbwidgetptr->basewin, WhiteDot);
I wanna make my window not moveable and resizable
In X11 window management, the client doesn't get to define what they want. They can ask the window manager to do this or that (or not to do that), but in the end it is always up to the window manager. In fact, the specifications state clearly that the client application must deal with any size the window manager assigns to it – so the answer is: no, you cannot do that if you want your window to be managed.
As pointed out in a comment, you can set override_redirect on your window. This tells the window manager not to manage your window, which means that the window manager will not interfere with it. However, in theory any client could still resize your window (though this is extremely unlikely to happen).
However, you should be careful about this. Bypassing the window manager also means that you lose a lot of things: window decorations, focus handling and the like will all be gone. In particular, focus handling must be done by you.
To summarize, you should really consider whether override_redirect is actually what you want to use. In most cases, you should instead just build a client that can deal with arbitrary window sizes and positions.
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"
I need to display a tooltip over a window. I'm creating a second window with the tool tip and using SDL_RaiseWindow() to bring it to the top. However, doing that causes the tooltip to steal focus which is not what I want. Is there a way to bring a window to the top without changing focus?
Also, is there a way to set focus (mouse and/or keyboard) without changing the Z order of the windows?
The answer offered by Neil will only work under X11 as SDL_SetWindowInputFocus() is only implemented for that environment. In essence, the desired behaviour is otherwise not achievable. I have seen that there is a feature request in the SDL forums for an overload of the SDL_RaiseWindow() function to include an optional bool parameter to indicate if the raised window should also receive the input focus, or not. I hope they do implement that.
In any case, the support for multiple windows under SDL 2.x is a little weak. There is no built in support for the Z-order of different windows, and trying to build one based on the "painter's method" works, but leaves one no control over the input focus.
Old question, but this came up during my own search. You could try SDL_RaiseWindow() to bring your tooltip to the top, then use SDL_SetWindowInputFocus() on the main window to switch focus back to it.
I got this working sufficiently for my tooltips on mac by using SDL_WINDOW_ALWAYS_ON_TOP flag with SDL2:
SDL_CreateWindow(tooltip_window->name, x, y, w, h,
SDL_WINDOW_OPENGL | SDL_WINDOW_BORDERLESS |
SDL_WINDOW_ALWAYS_ON_TOP);
SDL_RaiseWindow(windowThatShouldHaveFocus);
// ...render what you want on that tooltip (SDL_RenderClear, SDL_RenderCopy, SDL_RenderPresent) & hide it with SDL_HideWindow
And when showing the tooltip:
SDL_ShowWindow(tooltipWindow);
SDL_RaiseWindow(windowThatShouldHaveFocus);
I'm building an application to generate an array of colors based on a color chosen by the user.
The default on Mac OS X for color selection is to open a NSColorPanel containing multiple NSColorPickers. But, as the color selection process is the main interaction the user will have with the app, it'd be better to avoid the extra clicks and panel-popping in favor of a more straightforward way.
So, is there any way to add a NSColorPicker object to a window?
I know this is an older question, but check out NSColorWell. From the docs:
NSColorWell is an NSControl for selecting and displaying a single color value.
Interresting Question.
I strongly doubt it (but would love to be proven wrong). NSColorPickers are not NSControls (nor NSCells) so there's no clean wrapper to insert into a window.
Even if you were to instanciate an NSColorPanel and get a reference to its contentView and copy it (with all that defines the color picking controls) to your own window... there's no obvious way of obtaining the color value. NSColorPickers are plug-ins so you can't forsee the controls of a colorPicker.
The only other way I can see (and that's a stretch) would be to manually load the NSColorPickers plug-ins directly. I don't know how successfull this would be.
File a bug report and request the feature?
Is it possible to create an invisible X window? For initialization of an OpenGL ES 2.0 context, one has to create a X window manually, but I can't find a way to make it invisible. Since I'm only doing GPGPU I don't need an output window. In fact, it is rather annoying in my case.
I'm aware of a solution from an earlier question, where it has been pointed out to use InputOnly in XCreateWindow(). This, however, leads to the X error GLXBadDrawable. Probably because EGL requires the window to respond to graphics request. Is there another way? Maybe create it minimized? But I can't find anything on that either. Also setting the window's size really small doesn't help, since it always occupies the whole screen on my device (Nokia N9).
When you create an X window, it is created unmapped, so what about creating an InputOutput window and leaving it unmapped? Another option would be (if the window must stay mapped), to move it out of the screen.