I am learning C and I would like to change the terminal properties in a given code of mine. I know that to change the dimensions I can easily use system("mode con:cols=80 lines=30");, for example.
But if, when the code is executed, the user wants to change the size of the window he can just go to the edges and do that, my doubt: is there a way for me to make these dimensions static? without being able to increase or decrease the size of the window.
Related
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.
I'm coding in raw C, using win32.
I want to change at runtime the position of a control (a button) to properly keep its relative position inside the parent dialog, which is resizable.
I defined both the dialog and the button via a resource script, where dimensions are in dialog base units.
To change the size at runtime I have to deal with the SetWindowPos function, which accepts values in pixels so, to maintain the original proportions, I need to convert in pixels the original distance (in dialog base units).
I've tried to use the value returned from the GetDialogBaseUnits funcion and follow the "conversion procedure" (which is, substantially, a multiplication and a division) reported in the reference page, using the MulDiv function but what I get is a wrong value...
In particular I obtain: LOWORD(GetDialogBaseUnits()) = 8 and HIWORD(GetDialogBaseUnits()) = 16 which, used in MulDiv, produce sizes in dialog base units which are exactly the half of the pixel ones (and this is wrong, in my system).
How I can properly perform this conversion?
Not with GetDialogBaseUnits().
If you have a dialog box, you can do this easily: use the MapDialogRect() function.
If you have a regular window, you'll have to do the calculations manually. I've asked a question related to it here and wrote a tool for testing possible calculations. The different calculations are close enough to be equally visually useful; don't stress too hard.
In my application I have an area in the main window that at any time can contain one of several different controls.
This controls are generated at runtime and their contents can vary depending on underlying data, so I do not know beforehand how much space they'll take up.
What I want to know is: is there a way to determine at runtime how much space a control needs in order not to be "cut off" or need a scroll? ie: how much space does it need to be COMPLETELY visible?
I tried the "DesiredSize" property and it kinda works, but not always: if the control has been used already (it has already a size) it returns it's last used size rather than the correct one, even if I call "InvalidateMeasure()".
Any ideas??
Call Measure on the control. Give it infinite space as the available size for the calculation. Then check the DesiredSize to get the needed width (and/or height).
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.
Hey, I'm working on a map editor for my game, and I'm trying to convert the mouse position to a position in the game world, the view is set up using gluPerspective
A good place to start would be the function gluUnProject, which takes mouse coordinates and calculates object space coordinates. Take a look at http://nehe.gamedev.net/data/articles/article.asp?article=13 for a basic tutorial.
UPDATE:
You must enable depth buffering for the code in that article to work. The Z value for mouse coordinates is determined based on the value in the depth buffer at that point.
In your initialization code, make sure you do the following:
glEnable(GL_DEPTH);
A point on the screen represents an entire line (an infinite set of points) in 3D space.
Most people with questions similar to yours are really trying to select an object by clicking on it. If that's what you're after, OpenGL offers a selection mode that's generally more effective than trying to convert the screen coordinate into real-world coordinates.
Using selection mode is (usually) pretty simple: you start with gluPickMatrix, which you use to specify a small box around the click point. You then draw your scene in selection mode. When you're done, instead of actually drawing anything, it gives you back records of what would have been drawn in the box you specified. If memory serves, those are arranged in Z order, so the first one in the list is what would have displayed front-most (i.e., the one you usually want).