Community
Participate
Working Groups
Window manager is KDE's window manager; KDE 3.1 (Debian Testing) When the remote VM creates its windows, they are not successfully hidden off-screen, but rather clutter the current screen. Idea: If we're going to use a separate virtual console to hide the SWT windows, maybe this would be the best way to handle JFC on X-Windows rather than trying to deal with all the permutations of window managers out there.
BTW, this is still true in M2.
Created attachment 14849 [details] Screenshot of remote vm windows on OS X. This is also a significant issue on OS X. The remote vm windows show up on screen in the top left, and cannot be completely dragged off screen. Also each remote vm, including the beaninfo vm, shows up on the Dock (the taskbar) On the bottom of the screenshot there's three white papers with Java cups on them. The first is the runtime environment, but the other two are the beaninfo vm and the editor's vm.
Just to summarize - Unfortunately placement of windows in X is completely upto the Window Manager that X uses. So GTK, KDE, Fvwm, Twm, and so on... all can completely override any set locations one does on a Window. Twm is the most extreme - by default it asks the user to manually drop-size any created window, and this includes those created on the remote vm. ------------------------- tweaking window managers: Unfortunately SWT doesnt offer any gateways to the Window Manager. They are not to be blamed as I think this is a generic problem with X based apps themselves. If we wanted to code something specific to a window manager, we would have to dive into native code to talk to the Window Manager. --------------- hidden X server: We did implement this solution in the beginning where would start in the background : (1)Xvfb server (2)Xnest server inside the Xvfb of (1) [SWT applications were crashing for some reason in Xvfb directly] (3)twm/fvwm/fvwm2/.. window manager (whichever was found first) Then the remote VMs would be launched with the inner Xnest as the target. This however had some issues - Swing property editors and bean customizers lived on the remote VM, and becuase they come from beaninfo which is launched on the remote VM, there is no way of telling a Swing Window to open on display so and so. Hence the property editors open up in the hidden X server. Also starting an X server needs to be done carefully - authentication must be done correctly so that others dont get access to the content being developed. Also with so many flavors of unix/linux, there is no standard way of figuring out the X server, window manager etc.
Another idea is to use the new feature of SWT: Shell's alpha.
(In reply to comment #4) > Another idea is to use the new feature of SWT: Shell's alpha. It seems it doesn't work on all linux.
A solution of using alpha is committed.
