I can see that whenever I minimize an SWT Shell, all other Shells in the Display get minimized along, independently of its modal behaviour (which is not what modal bits are about anyway!)
Is it possible to cut this kind of virtual bond that ties all shells with each other?
I am using Eclipse Neon on Linux.
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.
I'm running the latest academic distribution of the Canopy IDE on a Windows 7 machine. In the iPython console, if I ask for a docstring (for example, typing "linspace?"), the resulting text fills up the console and gets cut off at the top and bottom. Afterwards, there is no longer an "In [#]" prompt and I cannot type any further commands into the console. If I don't want to lose all of the variables I have defined during the session, I have found that I can open a new editor window (File/New Editor Window) and I will once again have an "In [last #]" prompt where I can enter commands. However, this is a rather a nuisance. I would like to be able to view docstrings without having to open a new window each time. Is there a way I can fix this?
For reference, I have Canopy version 1.0.1.1189.
Update: this only seems to happen when I use the question mark, not if I enter, for example, "help(linspace)." Maybe I should just stick to using help() instead of question marks?
This isn't specific to Canopy and should apply to IPython in general. When you print a long docstring (i.e. one longer than your screen), it prints the output to something call a "pager" which allows you to scroll through the text. I think IPython (more or less) uses less.
When you're in the pager, you can press the q key to exit (and return to the IPython prompt). (Also, space bar pages down, b pages up.)
just installed Emacs 24 on a ubuntu precise OS. The menu bar in the top panel is missing a number of options (e.g. using Auctex, all the Latex options).
I recall seeing on the web somewhere that it was possible to have the menu on top of the Emacs frame rather than the unity default of the top panel. There is an answer on SO for how to enable the global menubar in ubuntu. Can someone please point me to how to disable it in the global menu until it gets to the point where they play well together.
Thanks
Ubuntu has a hardcoded hack to disable the global menubar for applications matching certain filename patterns. emacs is among those, as is firefox, another popular program that suffers from the same sorts of problems of GTK detached menubars not updating in the usual way that X programs expect them to.
Try running update-alternatives to select emacs24 as your default Emacs, then use emacs to start it, rather than emacs24.
I was using the symlink method mentioned by #Bernhard Kausler, but found I couldn't pin the icon that resulted from staring emacs from the shell in this way without it reverting to using the global menu.
I got a working unity launcher shortcut with this .desktop file:
#!/usr/bin/env xdg-open
[Desktop Entry]
Version=1.0
Type=Application
Terminal=false
Icon[en_NZ]=emacs
Name[en_NZ]=Gnu Emacs 24
Exec=emacs
Name=Gnu Emacs 24
Icon=emacs
StartupWMClass=Emacs24
Now I can have emacs pinned to the launcher and it launches with its own menu bar.
You can just create a symbolic link to the emacs??? command you use to launch emacs, and if the symbolic link's name is exactly 'emacs', it will not use the global menu when launched.
This is a known bug with Emacs dynamic menus where changing major modes adds or removes entries from the menu.
https://bugs.launchpad.net/ubuntu/+source/appmenu-gtk/+bug/673302
It's unfortunate that the names of the blacklisted apps are hard coded into the appmenu-gtk package, and that there does not seem to be a way to add items without touching the source code.
I have a rather long perltk code in my hand and I would like to run the simulation in a batch mode (without using the GUI). e.g. I would like to run it with script like "myprog.pl -b" in stead of setting all the parameters in the GUI and click buttons.
My current method is using a separated XML file for config and the function "after" which means the GUI will pop-out and start the simulation then exit after sometime. It is now working, but I have a question: is there a better way solve this problem? Is that possible to have the GUI shown in the background (so we wont see it) in stead of pop-out?
Change the program so it is accessible from both a graphical and command-line interface. Factor out its real functionality into subroutines.
Run the program in an xvfb so that no window is shown on the main display.
Configure the window manager to always start instances of this program minimised and/or with a 0x0 size.
I'm involved in a project that is attempting to use the Eclipse RCP splash screen to gather user credentials, language, etc. If this screen loses focus, it is not available (under Windows at least) through the ALt-Tab functionality, and can only be found by minimizing all other windows and uncovering it. Any way of having this screen allow itself to be activated in this way? They're avoiding creating an intermediate screen, for reasons unknown at this point.
I think it might be time to examine those unknown reasons. Even eclipse doesn't use the splash screen in this way. If it needs to prompt for information, it opens a new dialog to ask for it.
Good luck.
[Edit] I stand corrected. This thread seems to have a solution to this. Good luck, I'm no SWT/RCP guru.
See this page. From one of the comments:
The splash screen window is created natively with the extended window style WS_EX_TOOLWINDOW which makes it not appear in the task bar. This corresponds to the SWT constant SWT.TOOL.
I don't know if it's possible to change the window style after it is created on Windows. You can always drop down to JNI if that's necessary.
Create your own implementation of AbstractSplashHandler.
When creating the shell, don't use the SWT.TOOL style.
The shell will be accessible through the windows task bar.