My application performs a 90 degree rotation on a drawing area, so the width and height of the drawing area need to be swapped.
How can I resize the drawing area with GTK in a way so that the new width and height are actually enforced, not just requested?
Width/height cannot be enforced by a widget, they are determined by its container only. Widget can only request given dimension and its container will allocate the requested area or more (or even less, but all standard containers won't do this).
So, the answer would completely depend on how the area is packed and into what container. If your window (as in GtkWindow) doesn't include anything expandable, setting it to be non-resizable mode will achieve what you want. Otherwise, please specify how the area is packed and/or what other widgets are in the toplevel.
Related
We have an application which has a window with a horizontal toolbar at the top. The windows-level handle we pass to Vulkan to create the surface ends up including the area behind the toolbar i.e. Vulkan is completely unaware of the toolbar and the surface includes the space "behind" it.
My question is, can a surface represent only a portion of this window? We obviously need not process data for the pixels that lie behind the toolbar, and so want to avoid creating a frame buffer, depth buffer etc. bigger than necessary.
I fully understand that I can accomplish this visually using a viewport which e.g. has an origin offset and height compensation, however to my understanding the frame buffer actually still contains information for pixels the full size of the surface (e.g. 800x600 for an 800x600 client-area window) even if I am only rendering to a portion of that window. The frame buffer then gets "mapped" and therefore squished to the viewport area.
All of this has sort of left me wondering what the purpose of a viewport is. If it simply defines a mapping from your image buffer to an area in the surface, is that not highly inefficient if your framebuffer contains considerably more pixels than the area it is being mapped to? Would it not make sense to rather section of portions in your application using e.g. different windows HWNDs FIRST, and then create different surfaces from then onwards?
How can I avoid rendering to an area bigger than necessary?
The way this gets handled for pretty much every application is that the client area of a window (ie: the stuff that isn't toolbars and the like) is a child window of the main frame window. When the frame is resized, you resize the client window to match the new client area (taking into account the new sizes of the toolbars/etc).
It is this client window which should have a Vulkan surface created for it.
I am currently coding in C for linux and I need a GUI, so I took the GTK library to do so . I now have a window with a label (to begin with) but I don't know how to move it (in (x,y) coordinates, not in zPosition) to put it at the top of the window.
Here is my GTK code in main()
//Label
pLabel=gtk_label_new(NULL);
sUtf8 = g_locale_to_utf8("<span font_desc=\"Times New Roman italic 12\" foreground=\"#0000FF\">Neural Network - XOR Example</span>\n"
,-1, NULL, NULL, NULL);
gtk_label_set_markup(GTK_LABEL(pLabel), sUtf8);
g_free(sUtf8);
gtk_label_set_justify(GTK_LABEL(pLabel), GTK_JUSTIFY_CENTER);
//Window
gtk_window_set_position(GTK_WINDOW(pWindow), GTK_WIN_POS_CENTER);
gtk_window_set_title(GTK_WINDOW(pWindow), "Neural Network");
gtk_window_set_default_size(GTK_WINDOW(pWindow), 900, 600);
gtk_container_add(GTK_CONTAINER(pWindow), pLabel);
g_signal_connect(G_OBJECT(pWindow), "destroy", G_CALLBACK(OnDestroy), NULL);
gtk_widget_show_all(pWindow);
gtk_main();
Has anybody an idea on how to move it ?
Thank you!
Here is what I got:
(source: hostingpics.net)
carl gave you part of the answer.
As to why you see what you have, there are two parts:
First, GtkLabel has an archaic alignment mechanism it inherits from the deprecated GtkMisc class. See GtkMisc's documentation for details: the xalign and yalign properties control the position of the text within the label's allocation, and it's set to centered by default. But remember that they are deprecated, so there's usually better alternatives.
Second, you can only have one control in a GtkWindow. This control gets allocated the entire space of the window.
Put these two facts together and you should see why you have what you have.
So what is correct instead?
You have to use a container, such as GtkBox or GtkGrid, to get more than one widget into a GtkWindow. Each widget carries with it four special properties: hexpand, halign, vexpand, and valign which control the position and size of each member of the container. These are properties of the widgets themselves.
hexpand and vexpand determine whether or not the container allocates whatever space is left over to this control in the X and Y directions, respectively. If multiple widgets have expand set, the space is divided evenly.
halign and valign determine the position of a widget in its allocation. GTK_ALIGN_START, GTK_ALIGN_CENTER, and GTK_ALIGN_END put the widget at the start, middle, and end of the given alignment side, respectively. GTK_ALIGN_FILL fills the widget to fit the allocation.
This page has more information.
If you're trying to do exact positioning of controls, you should first investigate if GtkGrid and GtkBox (applied recursively) provide what you want. An important thing about the default internal centering of GtkLabels is that a GtkLabel in a GtkGrid will already be vertically aligned to its neighbor's text; just set halign to start or end to get the label left-aligned or right-aligned (and set valign to start if its neighbor is something big like a table). There are also functions that provide margins and padding to make the UI look nice.
If you absolutely must position things yourself, however, keep everything in mind.
I am new to silver light and would like to understand a bit more from the pros. Let me tell you what I am trying to do. I am into photography and my goal is to create a web site that allows users to view their images and be able to rotate, zoom, crop, special effect etc. I have developed the web site that allows users to order pictures but now I want to start working on the actual picture/image manipulation. So for testing i put a canvas and a rectangle( with an image). Placed a slider and was able to link the slider to the rectangle. As i increase the slider the image gets larger. But I was kind of hoping as the image gets larger it does not surpass the boundries of the canvas. I assumed that is what it means by being a child of a canvas. Am i mistaken? If so how do you suggest me doing this? Remember I am very new to this and may be going about this very wrong.
Thanks!
Your are right. In Silverlight (like in WPF, WinForms etc.) gui-elements form a hierarchy of elements wherein controls can act either as parents or as children.
The reason why your rectangle surpasses the boundaries of it's container lies in the way controls are getting aligned. This depends on what kind of container you want to place your child into.
In a canvas for example you position the children with absolute measurements (left, top, height, width). In a self-organizing container like the StackPanel you choose an horizontal alignment (Left, HCenter, HStretch, Right) or a vertical alignment (Top, VCenter, VStretch, Bottom) which determines the childs behavior when you place it inside the parent. Furthermore you can specify the dimension of the child (Width, Height) and an optional margin which determines the gap between the Top, Right, Bottom and Left bound of your child to its enclosing parent.
But what ever container you choose it's inherent to it that you can let its children surpass its boundaries e.g. with a margin that is negative or greater than the container boundaries or simply by an child that is bigger in dimension that its container as you described the situation with your rectangle.
In your case I would consider working with the idea of clipping. Clipping simply means to
(1) define an geometrical area (in Silverlight and WPF it is a Path object) which lies over some graphical context (some section of your ui or your control etc).
(2) what lies inside the boundaries of this clipping area remains visible and everything else remains invisible.
So you can think of a clipping area as a window onto your screen which you use to look through.
When you are using Microsoft Blend this is easy to realize:
(1) Just use a geometrical shape like a Rectangle, a Circle or a custom Path.
(2) Place it somewhere upon your UI
(3) Right-click the shape, select "Path" and then "Make clipping Path"
(4) and voulà, you've just defined a clipping area which you can modify as you are used to modify controls.
Hope this gave you an idea how to deal with your problem.
cheers.
I work on gschem, a free software tool for editing electronics schematic diagrams. Recently we have encountered a problem using a GtkScrolledWindow containing a GtkTextView.
Context
Recent versions of Ubuntu use overlay scrollbars, which mean that GtkScrolledWindows no longer set a minimum height that provides enough room for a legacy scrollbar (in fact, they have a minimum height of 0). Likewise, a GtkTextView with no text to display requests a height of 0. This means that one of the scrollable GtkTextViews in gschem has been being displayed as one pixel in height, and this is obviously unusable.
In the dialog box on the right of the screenshot shown above, note the invisible widget between the "Value:" label and the "Add" button.
This has been reported independently by several users -- see also the bug report.
Question
Obviously, we could fix this by doing:
g_object_set (textview, "height-request", 100, NULL);
However, this is pretty inelegant, and will break for users who set very large font sizes in pixels (e.g. users with vision problems or who use high-DPI screens).
Ideally, therefore, we want to set the minimum size of the GtkTextView relative to the default font size, e.g. tell it to "show at least three lines of text".
Can anyone suggest a sensible/elegant approach for doing this?
Just disable the ubuntu overlay scrollbars in your application by doing:
putenv("LIBOVERLAY_SCROLLBAR=0");
Not ideal, but it's a quite good until you can find a more permanent solution. Alternatively just wait until Ubuntu disables overlay scrollbars...
I would add code to dig out the current/default style information, use that to figure out the font baseline height, and then compute some rough size allocation based on that, around three lines as you mention.
Does it have to be a textview ? If you can use an eventbox instead, then you can make a cairo surface from it, render the text with pango, and then use pango_layout_get_size() to get the text height.
Likewise, a GtkTextView with no text to display requests a height of 0.
Probably you can create GtkTextView with some text inside. Like several spaces, and set empty value after creation.
I'm trying to retrieve the entire rectangle of a scrollable window using the WIN32 API. I thought that GetClientRect would return what I need, but that function appears to return only the current viewport. Is there a specific function call that returns the entire scrollable region as a RECT or must I call GetScrollRange to calculate the region myself?
It doesn't work like that. As far as Windows is concerned, a scrollable window isn't a small viewport onto a larger region whose dimensions you can set or retrieve, it's just a rectangle with a scroll bar control at the edge. It's up to you to determine the appearance of the scroll bar by calculating the portion of the notional region that is visible within the viewport provided by the window, and to paint the window contents accordingly.
It sounds as if that particular window is using virtual scrolling. Even GetScrollRange doesn't necessarily tell you the dimensions, because there's no requirement that a delta of 1 on the scrollbar equals 1 pixel, in fact in many cases it is one record, one row, etc.
Another thing to try is to enumerate all the child windows, and find the minimum and maximum x and y coordinates (don't forget to include the width and height of each child window). Of course this won't help if the content is directly drawn and not a hierarchy of windows.