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.
Related
I would happily provide a screenshot of this, however the problem is the captured image, is much larger than my actual desktop.
I am completely frustrated with this as I have tried using BitBlt with the desktop hdc AND the new "Graphics" commands.
My actual desktop resolution is 1920x1080 - 1080p .
BitBlt and "Graphics" both return that my resolution is 1536x864 # 96 DPI.
A form (WinForm), Maximized, borderless, and irrelevant of scaling mode the form is set to, also shows 1536x864 # 96 DPI.
Now the image that is captured, is like it is being done from 1920x1080, but clipping the region 1536x864 as the screenshot.
If I do PrintScreen directly using Prtscn button, I get the entire image, but still it is about 1.5-2x larger than what I actually see.
What I am looking for -- is a resolution for how I can take a picture of what is on my screen in the scale/dpi/whatever is going on here that it visually looks like. I have written a screen capture program, and using a few different examples for the RubberBand form (overlay form to select a region of the screen by drawing a box), and as you can imagine, this scaling crap is causing those box captures to be offset, and the contents are zoomed.
This is very annoying -- even to explain, however I am positive that most of you are familiar with the terms I use, and also know what to expect from taking a screenshot, so my explanation above should be pretty clear as to what my problem is.
Example/Consideration
Imagine, taking a picture of a window that is 300x300, and getting the top left 150x150 of that zoomed to 300x300 completely skipping the remainder of the window. Resulting image is still 300x300, but it's not what you selected.
Now imagine, you grab a picture of your screen by the only dimensions you can get programmatically, and then put the image into a picturebox. Even though both your screen and the picturebox claim to be the same dimensions and dpi, the image in the picturebox requires scrolling even if the picturebox is maximized to fullscreen on a borderless with no borders / etc. -- again, the picture is zoomed, but how is it still reporting that it's the same size as the form XD (comparing Graphics or BitBlt dimensions with the actual form. also tried comparing picturebox contents, and still same effect)
This, is EXACTLY what the effect is that is happening. When I try to capture a region or segment of the screen. I am not sure why windows api/crl is lying about this seemingly trivial stuff, however there must be a way to accurately obtain screenshots/capture regions without this faux zoom effect -- across all resolutions.
Thank you Hans Passant for pointing me in the right direction.
To add "true" dpi scaling support to a winforms application, you can make it so by adding the following block to your manifest :
Project > Add New Item > Visual C# Items > Application Manifest File
One the file has been added, open it up and look for a line like
</asmv1:assembly>
Whatever the "asmv" number is, (in the example above it is 1), use that to format the code:
<asmv1:application>
<asmv1:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
<dpiAware>true</dpiAware>
</asmv1:windowsSettings>
</asmv1:application>
Paste the above code (changing the asmv1 to whatever version the manifest is), just above the final closing line for the ""
Also, make sure your forms are set to AutoScale to dpi (and all sub-elements).
I observed that in IE7, the select box's drop down looks incomplete (see image 1).
But when you hover it, the drop down box show-up completely (see image 2).
How can i make it look like image 2 as default. Also, if i increase the size of select box (height: 25px) and the text size is only 9px, how can i ensure that the text is in the middle? I've tried adjusting the padding and margin of the select box with no avail.
Thank you.
That's what drop-down boxes look like when you have the Windows Aero theme enabled. It's totally normal and standard. In fact, it's what Windows users expect to see. I don't recommend changing it just because you think it looks weird. Your users won't think so. All the other webpages they look at, as well as all of the apps on their computer, work exactly the same way.
And no, you can't trivially change the appearance. You'll have to write custom styling for the entire drop-down box control. And that's pretty difficult to do in Internet Explorer compared to other browsers, if it's even possible to get it to work correctly at all.
As for your second question: why would you be increasing the height of the drop-down box? The default height is the one you want. It automatically sizes itself to fit the size of the text it displays. It doesn't need to be any bigger than that, and if you force it to be bigger, it'll look ugly like you said.
Read more this issue fixing click here,
and yet more examples demo page
I'm using Clutter to compose an interactive/animate UI.
I'm using two box containers (ClutterBox) with an integrated FixedLayout, and I want to be able to rearrange those boxes onto screen using an hard-coded layout during (gtk-)window resizing. Searching in some gtk3 examples, I find out this can be achieved connecting the signal "size-allocate" of the GtkWindow. What I still unable to accomplish is to get width and height of the Embed ClutterStage.
I used gtk_widget_get_preferred_size passing the ClutterStage widget, but it gives back to me only the preferred size, and not the current, resized value.
Does anyone have a clue?
calling clutter_actor_get_size() on the stage returned by a GtkClutterEmbed widget is enough to get the size of the stage: the GtkClutterEmbed widget that owns the embedded stage resizes the stage every time GTK+ negotiates the geometry of the widgets of a window.
you can also use a ClutterBindConstraint object to bind the size of an actor to the size of the stage, or a ClutterSnapConstraint or a ClutterAlignConstraint objects to resize or align actors to the stage.
Try gtk_widget_get_allocation().
I am trying to remove the border of my WPF window in the design view/tab in Visual Studio. Please don't mistake this as a request to create a border less WPF window. I did that and it is working fine. What bothers me is that even if you have set WindowStyle = None, ResizeMode = NoResize, the design view/tab still shows a border around your window in the preview.
Is there a way to remove said border and have a 1:1 preview of the border less window as in Windows Forms?
Every question I have found in regards to this only asks how to remove the border of the actual application. I would like to remove it in the preview.
Any help would be very much appreciated :)
here is a screenshot of my problem:
This cannot be done as this is just how Visual Studio renders a window in design view (I think the frame is probably there so that you can distinguish when you are editing a Window rather than a UserControl).
Rather than try and find a solution to this I would ask myself if this is something I need to be spending time figuring out - after all you say that your program works correctly when being run. I think your time will be better spent writing code for your program rather than trying to play with the design time environment.
Update: In response to you comment, consider that the window frame will be different on every users machine depending on their operating system version (XP vs. Win7) or the theme the user has installed.
My computer has XP installed so the side borders are a lot thinner than those shown in design time so any content will be smaller (but only my a few pixels - 4 in my case; does your user interface design really depend on 4 pixels?).
When using a technology such as WPF you should not be designing your UI to fit to exact pixel sizes; you should be designing with min / max values or using layout containers that adjust to the size of the window as set by the user. Any regions in your UI (E.G. sidebar and main content) should be expressed as a ratio or percentage of one another; instead of saying "The side bar is 150 pixels wide and the main content area is 350 pixels wide" you should be saying "The side bar takes up a third of the window width and the main content takes two thirds".
Although the question is very old and have already been answered (kind of), I just realized: if you set WindowStyle="None", your undesired border is gone.
Given a WPF Application running full screen, a fair amount of controls some of which will animate from off screen to center. I was wondering if there are any special ways to save on the amount of time required to optimize an application for different screen resolutions?
For example, using Blend I've setup some text, which is originally off screen to scroll into view. Now in design mode the start positions are static. If resolution changes the start positions will obviously not be correct.
So I guess to correct this, during app startup. I need to
Check resolution
Move the text box to the desired start location
Adjust the storyboard as required, so the frames all have correct co-ordinates depending on the res of the screen.
I don't mind doing all of this, but if there is an easier way please share!
Thanks
In WPF layout of controls should be made in such way, that when size of window or content changes, controls automaticaly resize/reposition themselves to reflect this change.
This is highly affected how your layout is made, especialy by using specific panels, that do layout of their child elements.
This is also made obvious by using device-independent units for sizes, margins and sometimes positions of controls. And also allows different kind of zooming and scaling of whole UI without any need to redesign the whole thing.
If you are trying to position your controls absolutely, either by using Canvas panel or margins, your are doing it totaly wrong.
In WPF, scene is measured in abstract units, not pixels, and controls are freely scaled. There should be no problems to center something, or what?