I'm trying to make a simple autocompletion tool for my program, and i would it look like as this picture : https://github-camo.global.ssl.fastly.net/ac6492f955c9d8027b6f691e1e3df6052fa16599/687474703a2f2f6e6f736d696c65666163652e72752f696d616765732f63636f6465322e706e67
There are termcaps who can help me to make this ? As a little "te" "ti" capabilities ?
Thank you.
Generally, you cannot get the screen contents, because some people view the notion of an escape sequence which can return the screen contents as a security problem.
The xterm ti/te termcap capabilities do not return the information on the screen. Instead, they tell xterm to switch between the normal and alternate screen buffers. But those cover the entire screen -- not a portion of it as your example suggests. Also, these sequences are sent by any conventional application at the beginning and end of "full-screen" mode -- so your application is likely already using the alternate screen.
Instead, your application has to keep track of what it puts on the screen, so that it can repaint after the popup window goes away. That is something that ncurses, for example, is designed to do.
Related
This question is related to this other one (Android). A sample test case was also provided here
Basically, I can get past the "glitch" of losing the bottom screen under the keyboard that occurs sometimes when a single line TextField is focused by setting the TextField's bottom padding and making it a layer
But when the same glitch occurs to a multi-line TextField, each time the cursor is moved to a different line the keyboard follows the current line and hides everything underneath. I've been looking at TextArea and Component but I can't see anything there that stops this behavior. My "trick" of making the TextField a layer with bottom padding doesn't work in multi-line mode. I'm out of options, could this be enabled or alternatively is there some magic method somewhere I am missing?
Also, I've checked that calling getComponentForm().getInvisibleAreaUnderVKB() returns 0 when the glitch occurs
I think you need to re-open the applicable issue. This code is very platform specific as the virtual keyboard behavior is handled 100% within the Android port.
Android doesn't implement getInvisibleAreaUnderVKB() since the VKB doesn't work that way in Android. It resizes the screen instead to provide the additional space. It will generally try to get the top area where your cursor is. That's the chief goal.
When the screen is empty that might look problematic but when your screen is full of data we'd rather see the data than have the full text component in view. Unfortunately, the native editing code has no way to distinguish between the two cases. We might be able to come up with a workaround but with these things there are often issues/regressions.
Solution to prevent this consists in setting the Form's setFormBottomPaddingEditingMode(true);. Easy fix! 👍
I'm building an app where I would like to redraw the image on screen around a user's finger touch. System.Windows.Media.Imaging.WriteableBitmap has a method AddDirtyRect(Int32Rect dirtyRect) to indicate to indicate changes my code has made to the back buffer so that the whole image needn't be redrawn. Its Windows Runtime equivalent, the Windows.UI.Xaml.Media.Imaging.WriteableBitmap class, does not.
Can I tell the system which part of the screen to redraw as the result of code changing a Windows.UI.Xaml.Media.Imaging.WriteableBitmap?
No, this API isn't there. You could use a secondary patch bitmap to update only a portion of the rendered output. If you need more control over what gets pushed out to the buffers you'd need to use a SwapChainPanel and DirectX.
I am developing a custom shell like bash (in C).
I am working right now on the events triggered by the arrows and the tab key. However, those special keys should be handled correctly.
What I want is to capture those keys and not let the CLI draw them on screen. What happens is that when the up arrow is pressed, for example, it draws the following symbol: '^[[A'
How can I stop it from happening? And what is the best way to read and map those keys?
It's kind of old, but some shells use terminal capabilities (termcaps) to block output and move the cursor.
You can also use the lib ncurses that is a cool wrapper for termcaps.
I am trying to implement a text box where a user can type, use arrow keys, backspace, delete, etc. I would like to be able to know what is in this text box without the user needing to submit anything. I suppose I could catch keypress events, find a way to display a cursor, and basically build a min-text-editor by hand--but maybe that would be reinventing the wheel?
What I am after is rather scrabble-like. You have several letters in the top part of a window and a text box in the bottom. Each time you type a letter it disappears from the top pane so that you know when you've used them all up. I want to be able to edit that text with the arrow keys, 'cause rather than the 7 letters scrabble would give me I hope to be doing this with paragraphs.
I have the window displaying, and the source file processed and displayed as a list of allowable letters... I just want to update the list of allowable letters while the user types in their sentence. Can Xlib do this? Is there something else that might be more suitable? Thanks!
Can Xlib do this?Why yes, Xlib can do a lot of things. What you describe seems simple enough by using X's event processing and drawing functions.
Xlib is pretty crufty, though, and IMO you should only use it if you need closeness to the X protocol. (Even then there are newer replacements like XCB. But I digress.)
You might find it easier to work with a modern toolkit, like GTK+ or Qt.
For example, this might be expressed as a GtkEntry with a "key-press-event" handler.
Using gdk_screen_get_monitor_geometry, I can get the total area in pixels and the relative position of each monitor, even when there are two or more used as a single screen.
However, I want to get the usable area (that is, excluding panels) of each monitor. The only thing I have found is _NET_WORKAREA, but that is one giant area stretching across all monitors. Depending on the resolution and arrangement, there may be panels inside this area.
How can I get the actual usable area of each monitor? Ideally, using only Gtk/Gdk, nothing X11-specific.
The following approach is a bit convoluted, but it is what I'd use. It should be robust even when there is complex interaction between the window manager and GTK+ when a window is mapped -- for example, when some of the panels are automatically hidden.
The basic idea is to create a transparent decorationless maximized window for each screen, obtain its geometry (size and position) when it gets mapped (for example, using a map-event callback), and immediately destroy them. That gets you the usable area within each screen. You can then use your existing gdk_screen_get_monitor_geometry() approach to determine how the usable area is split between monitors, if any.
In detail:
Use gdk_display_get_default() to get the default display, then gdk_display_get_n_screens() to find out how many screens it has.
Create a new window for each screen using gtk_window_new(), moving the windows to their respective screens using gtk_window_set_screen(). Undecorate the windows using gtk_window_set_decorated(,FALSE), maximuze them using gtk_window_maximize(,TRUE), and make them transparent using gtk_window_set_opacity(,0.0). Connect the map-event signal to a callback handler (using g_signal_connect()). Show the window using gtk_widget_show().
The signal handler needs to call gtk_window_get_position() and/or gtk_window_get_size() to get the position and/or size of the newly-mapped window, and then destroy the window using gtk_widget_destroy().
Note that in practice, you only need one window. I would personally use a simple loop. I suspect that due to window manager oddities/bugs, it is much more robust to create a new window for each screen, rather than just move the same window between screens. It turns out it is easier, too, as you can use a single simple callback function to obtain the usable area for each screen.
Like I said, this is quite convoluted. On the other hand, a standard application should not care about the screen sizes; it should simply do what the user or window manager asks. Because of that, I would not be surprised if there are no better facilities to find out this information. Screen size may change at any point, for example if the user rotates their display, or changes the display resolution.
in the end I ended up using xlib directly, various "tricks" like the one suggested above ended up eventually failing in the long run often with odd corner cases and never followed the KISS principle.
The solution I used is in the X-Tile code base.