I am trying to solve a problem on a software. I have two windows created with Motif library.
The first window contains 5 buttons (Font 1, 2, 3, 4, Exit), choosing a font affects the text of the other window ("Unacknowledged Updates").
When the second window text is in font 1, and we click on the font 4 or font 3 button, the result consists in displaying a text label cut on the second window.
I have written a prototype to reproduce the bug using the same way of coding and initializing widgets. However, I can not reproduce the bug yet. The thing is, the way of how callbacks are managed in my prototype is far more simple than in the original code which uses Xevent sent to X server.
You can find two screenshots displaying the problem following the link:
---Screenshots---
You will find the prototype code following this link : ---here---
The line to compile : gcc mmm_window.c -lX11 -lXm -lXt -o mmm_window
Solved by forcing redraw of 3 XmForm.
It seems like the problem would come from the size of my label (width, height) which does not adapt when changing fonts. I have tried to set XmNrecomputeSize to true on the concerned widget but it did not help. I keep on searching...
Related
Trying to add a tray menu to a GTK+ (2.24) application on Windows 10, in C. Code is exactly as in this example, except the icon. The result is as follows, menu is not visible and there are up and down arrows instead:
In this example (French forum, code works when an image is provided), only down arrow appears and it is possible sometimes (1 over 10) to actually display the menu entry by right-clicking long time on the arrow.
Question is: is this a GTK+ bug, as stated in several forums, or is there a way to create a menu from a tray icon using GTK+ without implementing a custom-drawn one?
Edit: replaced wrong GTK2 tag by GTK.
So my problem is as follows - I need to create buttons in my GTK/C program that are simple clickable, colored tiles. I found this thread GTK Modifying Background Color of GtkButton and a few other resources that supply a very similar answer, but no matter what I do the set_fg function does nothing and set_bg function either sets a thin frame around the button/widget - which itself stays gray - or also does nothing. Can anyone please help me solve this problem or give me a reasonable alternative to creating a set of colored tiles that can be clicked on and that can dynamically change color?
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.
Ive been googling this alot but can't find any working solution. Im using Shell Integration Library to cerate custom Window Chrome and I also need drop shadows for this window. Some say setting GlassFrameThickness to -1 do the trick but its not working for me. And Jeremiah Morrill suggested using DwmExtendFrameIntoClientArea. Ive tried that and it works, sort of. The shadows looks ok but when the window is shown it is first shown as a glass-frame and then a second later the real content is superimposed. This causes to much flickering for me. Is there any way to get rid of this flickering or is there any better way using only Shell Integration Library?
I had a similar problem where it wouldn't display any shadow when using a custom chrome. It worked fine when using the glass.
I got a shadow by setting GlassFrameThickness="0,0,0,1". The glass didn't show and I got the shadow.
Be warned, the shadow is a simple RECT to Windows, so if you have a funky chrome with transparencies it may look funny.
Also if you support the maximized state be aware the you'll need to set a margin on your top-level panel element of "8,8,8,8" when in maximized mode. All other modes should be "0,0,0,0".
To alimbada, the WindowStyle defaults to None on custom chrome.
The Shell Integration Library uses DwmExtendFrameIntoClientArea, plus handling of several Window messages to get the effects. If you're using the full window rect (i.e. no rounded corners) then setting it to (0,0,0,1) as suggested will give you the drop shadows as you want. If you want to simulate the rounded corners of Aero, then setting it to (8,8,8,8) will extend the glass frame enough that the corners also stay rounded, and then you're responsible for not drawing over the corners of the rectangle. The shape of the drop shadow doesn't change regardless of the glass frame thickness.
The flashing you're seeing when setting the thickness to -1 still exists even when not fully extending the glass frame. What's happening is the window is getting shown while the content is still compositing. What you can do is simplify the default UI so it displays quicker (or you can stage it, bringing in a simnple background first and then replacing it with something usable), or you can create and show the window off-screen, and then move it to the desired start location once the content has been rendered. The easy way to detect when it's probably ready is to invoke a DispatchTimer with Priority=Loaded. That should only get invoked once the basic first layout has been completed.
I am trying to smooth text rendering using anti-aliasing.
But it's not anti-aliased.
First line is a png image created using pango and cairo.
Second line is just an html <span> tag. It's in firefox, Ubuntu with Gnome DE.
The difference can be better understood if you compare "W" and "v"
between two lines.
The code responsible to draw text can be found on http://pastie.org/1073683
Font options are set on lines 17 and 20 like so:
// setting up antialiasing
cairo_font_options_set_antialias(cfo, CAIRO_ANTIALIAS_GRAY);
// set the font options to cairo
cairo_set_font_options(this->cro, cfo);
Could anyone please tell me how can I make those two lines look the same?
cairo_font_options_set_antialias(cfo, CAIRO_ANTIALIAS_GRAY);
You asked for it, you got it. To get a match you'd need CAIRO_ANTIALIAS_SUBPIXEL. This is however not appropriate when you draw text to an image that might be displayed on another machine. There's no guarantee that the monitor on that machine is an LCD panel with the RGB stripes in a predictable order. Or that it in landscape orientation. Or that it is displayed with the exact original size. When there's a mismatch, the text will look quite poor.