I need to draw a few small undecorated windows on top of another app's window. Each of these windows contains just a short label. It works fine but the windows are too big for my purpose. It seems as if Windows doesn't allow smaller than 104 x 27 toplevel windows, I might be wrong. I haven't tested on another backends. I'd like to shrink them to just the size needed to display the label. Is there a way to accomplish this?
Trying out things, I figured that setting the type hint with gtk_window_set_type_hint to GDK_WINDOW_TYPE_HINT_UTILITY allows the window to shrink horizontally but not vertically. I'm not sure what other implications this has. But it didn't solve the problem anyway.
I'm looking for a portable solution but platform-dependand answers are welcome too. Any help appreciated.
Edit: As usual, the solution is trivial. I had completely forgotten the GTK_WINDOW_POPUP window type.
Edit: Making the window GTK_WINDOW_POPUP has some unfortunate side effects which make it unusable for my purpose. I eventually got GTK_WINDOW_TOPLEVEL to work as expected. The key was to do gtk_window_set_resizable(window, FALSE) after the the window has been exposed.
Use gtk_window_set_resizable, this affects user resizes, which apparently includes resizes requested by the window manager. Setting it to FALSE therefore makes the programmatic value stick.
Related
A child Gtk::Window or Gtk::Dialog may be moved around by dragging on the title bar. Being top level windows this activity requires support from the window manager. What is the mechanism by which Gtk requests the window manager to move the position of the window?
Background
I have a Gtk application running on a custom Linux distribution (based on Yocto running Waland/Weston). The application is developed on Ubuntu 20 which has both X11 backend and Wayland backend. The child dialogs or windows that are spawned by the main window are perfectly centered on the main window (in Ubuntu on both backends). However on the target (with Weston) the dialogs or windows appear at random position. Now I understand that this is reported in several forums (like this one in stackoverflow itself).
Different Approach?
With what ever little I know I tried Gtk::Window::move, Gdk::Window::move and even dared to play with Wayland surfaces (gdk_wayland_window_set_transient_for_exported ) but with no avail.
That left me wondering how the user is able to move such child windows by grabbing the header bar (or title bar as Gtk::Window calls it) even under Weston. If I get to know how this works then perhaps I can emulate a grab-drag to position the window where ever I want.
I tried sifting through gtkwindow.c to find out what happens when one sets the title bar using the function gtk_window_set_titlebar but the rabbit hole went a little too deep.
It would be great if someone can point me in the right direction, at least quote some functions whose implementation I can study to get this working....
Your question consists of multiple smaller ones, so I'll try to give a shot at answering each and one of them.
The general idea is that Wayland is quite minimal, so to make it suitable for desktop use cases, you need a protocol extension. This extension is called XDG Shell.
A child Gtk::Window or Gtk::Dialog may be moved around by dragging on the title bar. Being top level windows this activity requires support from the window manager. What is the mechanism by which Gtk requests the window manager to move the position of the window?
This first part is described in the Wayland book, but the idea is that you forward an input event (usually a drag) back to the compositor, who will know what do with it. That might mean moving the window (or not moving it, if you've reached the edge of the screen.
However on the target (with Weston) the dialogs or windows appear at random position. Now I understand that this is reported in several forums (like this one in stackoverflow itself).
Note that your confusing 2 questions here: one is where to put a child window, compared to a parent window, while the second sentence here talks about position any toplevel window. There is also a section in the Wayland book on popups (part of XDG shell also) which also describe something similar.
So whether you can arbitrarily move windows: the answer is no.
The most important question then becomes: what can you do to solve your problems with Weston? It's hard to say without any kind of code. You might want to make sure you set the GtkDialog parent when constructing it (also known as the transient_for property. You might want to play around with the modal flag also. There might be other options too, but it's a bit of a blind guess.
Usually when an editor is empty, the editor hides the scroll bar, but when there are just two lines in V.S. Code, the scrollbar is visible. Is there a way to configure V.S. Code so that the scrollbar remains hidden until the number of lines-of-code exceeds the amount of lines that are visible in the editor?
V.S. Code Scroll-bar
Your not going to be able to get exactly what your looking for, but I will clarify, what you are able to do, and you can decide the best option that works for you. I will attempt to outline the answer to cover the topic in a way that it is useful to anyone else who is looking for the same topic via stack overflow search-queries.
The setting that affects the visibility of the scrollbar is editor.scrollbar.vertical, and it is the only one, however; there is also editor.scrollbar.verticalScrollbarSize which changes the size of the scroll-bar (I guess, as a technicality it can affect its visibility as well, since setting it to 0 hides the scroll-bar).
editor.scrollbar.vertical has 3 settings, and they are as follows.
Auto – "Assigning the value auto will hide the scrollbar whenever the editor is not in focus."
Visible – "A better name perhaps, would be "Always Visible", since assigning the value visible always makes the scrollbar visible, even when working in the workbench, or terminal."
Hidden – "I think we can all take a pretty good guess at what assigning hidden does. It hides the scrollbar.... I guess I should point out that this too is a case of "always", as it always hides the scrollbar."
V.S. Code is a highly configurable editor, and I personally love it for that reason, but to be fair; V.S. Code lacks in configurable scrollbar settings, there isn't a lot that can be done to customize it, and this has lead to several issues and suggestions created in the V.S. Code Repository. Perhaps the most appealing aspect to V.S. Code, is there team. The VSC team listens to suggestions, as they deliver when a suggestion is popular, perhaps try creating a suggestion — just remember to make sure no one else has already suggested it.
Check this setting:
Editor > Scrollbar: Vertical
the default is auto, is yours changed to visible? Which would be always shown.
I have recently upgraded from Delphi7 to Delphi XE5 and one of the differences that first jumped out at me is that by default, the IDE sets a forms default position to be in the top left corner of the screen instead of the center of the desktop like it was in D7 and I have looked all around in the options menu and have yet to find a way to set it so that when a new project is created, all forms default to be positioned in the center of the desktop and was hoping I was overlooked the option to do this or to confirm if it was not possible to set this option to be default.
I know there is the little box at the bottom right hand side of the form designer pane which allows you to move the form around so it is placed anywhere on the screen and of course you can set it to be in the center of the screen using the object inspector, but if I could set it to default to this position by "setting and forgetting" an option in the IDE, than that would be one less thing I need to bother with when starting a new project.
Anyway, any help would be appreciated and thanks in advance for any and all replies.
I figured it out myself in a roundabout way. It does not answer the question to the exact specifications that it was asked in but it works out close enough for my needs. The trick was to set the (now hidden) "Embedded Menu Designer" option to FALSE in the registry which causes the form to float independent of the rest of the IDE like it used to in Delphi 7.
Why this option was hidden from the options panel in Delphi XE3 and above is beyond me, but at least there is a way to get it back to the classic look I was after.
Source: http://theroadtodelphi.wordpress.com/2012/09/04/disabling-the-embedded-designer-in-rad-studio-xe3/
Note: The article talks about XE3, but the same technique applies to other Delphi versions as well. All that needs to be changed is the version number in the registry branch needs to match the version of Delphi that is being using. Everything else remains the same.
Isn't poDesktopCenter (TForm.Position property) enough? You set it in design time and forget about this.
I don't know what will happen if you have 1500x1200 form and the screen resolition is 800x600 - try it youself :)
I have a fixed shell sized (800x600) application developed in SWT. The issue is, if I change the display settings of Windows ( from smaller - to medium/larger ) few parts of the application are being truncated.
So is there any way I can give dynamic size based on the selection of display settings ?
A fixed shell size is very seldom the right way to go. Instead, use the layout to set the constraints and let SWT figure out the size. That will make it more likely that dpi changes will work correctly and more likely that the app will look correct on other operating systems or different versions of Windows.
Recently I have got a new 22" monitor. Finally it's possible to keep all needed windows in Eclipse open while having the main editor window wide enough to display all 120 columns. Problem now is when I wide up or narrow down windows on the left or right side of the editor. Editor's width narrows down or wides up. I'd like to set its width fixed to some value and let the other windows 'breathe' in width.
Take a look at the illustration.
You should rather use detached views, that way your main editor is not affected by the other windows resize operations.
(source: eclipse.org)
Either that, or use fast views, which minimises the views down to an icon that can be conveniently popped up when you need to use them. This is especially handy for things like the JUnit test view, as suggested by the JUnit Eclipse documentation
http://help.eclipse.org/help32/topic/org.eclipse.jdt.doc.user/gettingStarted/qs-junit.htm