I am new to Xlib (in C) and am having two issues when calling the XMoveResizeWindow function.
ex.
XMoveResizeWindow(display, window_id, move_x, move_y, resize_x, resize_y);
1) After the call, the window I move will reposition itself correctly, however, if I select the window with the pointer after the move, it will instantly revert back to the position it held prior to the move. I assume I have to somehow 'update' the X11 server after it's moved with the windows new position?
2) Secondly, in regards to the resize of the window. My window is essentially being truncated by the x and y values entered, instead of resized. In other words, instead of the entire window shrinking down, the right and bottom sides of the window are cut off from view. Is there a way to instead resize the entire window?
--I am sorry I am unable to submit my complete code, however, I believe my issues are due solely to my lack of understanding of Xlib and this particular function's operations. As such, I am not neccessarily looking for specific code as a solution, merely an explination or suggestion on how I should go about implementing a solution.
Thank you.
I believe there is something wrong with your code, since that code is not available i'll point to an example.
Examples are given at readme itself.
Related
I am on an Ubuntu 19.10 64 bit system
Source files:
https://drive.google.com/open?id=1I4ejOHNXqbAOkTbIyJR0lvldsAwiPPqI
Problem:
I am working on a simple drawing program using gtk and glade with c. Right now I am stuck into implementing undoing behavior. I have two problems. There are cases for when I press the undo button.
1)
When I have one stroke or one dot on the canvas, it works perfect as I experienced. Canvas clears itself.
2)
When I have two strokes or two dots on the canvas, if I click undo once, canvas does not redraw itself, unless I draw again; if I click twice, it works perfect like in the first case, canvas clears.
3)
When I have more than two strokes or two dots on the canvas, if I click undo twice, the program stops working waiting me to force quit.
I am a beginner at using glade, gtk3, and cairo libraries. I have been searching about the issue for days. However, the resources are scarce compared to trending frameworks and libraries. Furthermore, I couldn't match the problem I need. I appreciate any help.
EDIT I forgot to add that the halting problem occurs after the function , on_undo_clicked exits the second time (twice undo click).
I solved the problem.
In the function, addPoint I forgot that the next struct pointer's pre pointer may be a dangling pointer. It creates the problem.
During the development of my program I came across one drawing glitch that I was unable to solve. I am using GtkRevealer to show and hide a GtkInfoBar above another box holding a scrolled window with a GtkTextView (actually GtkSourceView) a lot like it is in gedit.
The whole thing is packed in a GtkPaned.
When I hide the infobar through the revealer, a black area in the text view appears and it disappears when a redrawing of the widget must occur (for instance when I click on the text view to place the cursor)
Additionally, this glitch does not appear if I enlarge the default resolution of the window, which for compatibility reasons is 640x480.
I understand that this may be hard to reproduce, but I am unaware who encountered the same problem. He maybe knows a workaround to this issue.
Also any idea is welcome.
I will draw exactly how the glitch looks on gedit (although it doesn't happen in gedit or it does but I cannot hit the correct resolution).
I tried to force a redrawing with gtk_widget_queue_draw() but nothing happens and it won't, because it has nothing to redraw.
I will try now to place the cursor automatically. It may work, but it is not functionally adequate.
EDIT:
Surprisingly it did not work. Grabbing the focus and placing the cursor
had no effect on the glitched visual behavior. I had to even make a new line
to fix it this time.
The fact that I have to resize the window with a value more than a specific point, may mean that the glitch may be due to alignment miscaulculations, but this doesn't explain why adding new line or a text mark in the gutter that colorizes the entire line also removes the black field.
Currently this bug has been encountered in another programs with a text view as well, but hasn't been reported as a bug yet.
Perhaps this has something to do with the fact that it is hard to reproduce.
I found that hiding the gtk text view with gtk_widget_hide() and then showing it with gtk_widget_show() works. The flicker of this visual glitch is not noticeable, perhaps due to GTK+ being event-based and waiting for the function to return to process changes.
I'm currently getting back to some Windows Programming using Petzold's book (5th edition).
I compiled the following example using BitBlt and it doesn't work as it is supposed to.
It should copy the Window's icon of (CxSource, CySource) size and replicate it on the whole window's surface.
What happens, in reality, using Windows 7 is that the bitmap below the window gets sourced and copied into the drawing surface i.e. hdcClient.
I don't understand why it behaves like this knowing that it's clear the DC passed to BitBlt is hdcWindow, which refers to a device context obtained via a GetWindowDC(hwnd) of the current application.
I first thought it was due to the fact the transparency mode is enabled by default, but deactivating it doesn't change anything. BitBlt seems to always take the surface below the application Window!
I don't get it! :)
Anyone knows why it works that way and how to fix it?
Making screenshots with BitBlt() did not exactly get any easier since the addition of the DWM (Desktop Window Manager, aka Aero). Petzold's sample code suffers from a subtle timing issue, it is making the screenshot too soon. It does so while Aero is still busy animating the frame, fading it into view. So you see what is behind the window, possibly already partly faded depending on how quickly the first WM_PAINT message is generated.
You can easily fix it by disabling the effect:
#include <windows.h>
#include <dwmapi.h>
#pragma comment(lib, "dwmapi.lib")
And after the CreateWindow() call:
BOOL disabled = TRUE;
DwmSetWindowAttribute(hwnd, DWMWA_TRANSITIONS_FORCEDISABLED, &disabled, sizeof(disabled));
Another tricky detail is that the first BitBlt matters, the DWM returns a cached copy afterwards that is not correctly invalidated by the animation.
This gets grittier when you need a screenshot of a window that belongs to another process. But that was already an issue before Aero, you had to wait long enough to ensure that the window was fully painted. Notable perhaps is the perf of BitBlt(), it gets bogged-down noticeably by having to do job of composing the final image from the window back-buffers. Lots of questions about that at SO, without happy answers.
It is not supposed to copy the windows icon, it is supposed to copy the windows titlebar part where the icon is located.
There are some issues with this (now 20 year old code):
GetSystemMetrics values cannot be used for window related dimensions anymore since GetSystemMetrics returns the classic sizes, not the Visual Style sizes.
Depending on the Windows version, the DWM might define the window size as something larger than your window (where it draws the window shadow and other effects).
Your example works OK on XP:
(There is a small problem because the titlebar is not square (unlike Windows 98/2000 that this example was designed for) so you see a issue in the top left where it is just white. I also modified the example slightly so it varies the HDC source location)
On a modern version of Windows it seems like the DWM or something is not able to properly emulate a simple window DC and parts of the shadow/border/effects area is part of the DC:
I don't know how to fix this but the example is pretty useless anyway, if you want to draw the window icon you should draw the HICON with DrawIconEx. If you want to draw custom non-client area stuff then you need to find more recent examples, not something that only supports the classic theme.
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.
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.