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.
Related
I have a full-screen window (winA) and another window (winB) which is always on top.
Now I need to let winB display above winA, while winA is still above any other windows.
How to do this in GTK+? Thanks. (Maybe this needs Xlib?)
PS1: I won't use POPUP windows because it will put all the windows under it. I just need put winB on winA but not all the others. For example, if I am watching videos in the fullscreen mode, I wouldn't like to see winB. But if winA it's here, winB is just above it.
PS2: winA & winB are in the same program. In this case, it may simplify the solution.
The main way to tell the window manager to keep winB above winA is through the "transient for" hint, set in GTK+ with gtk_window_set_transient_for().
If your window is not a dialog, the behavior may not come out quite how you'd like; you could try setting a semantic hint with gtk_window_set_type_hint() and see if that gets you anywhere.
But the behavior is basically going to vary with window manager (which is intended). So you kind of need to just live with that and assume people will use a WM that works how they want it to.
I had been using Eclipse 3.x for a few years and while I had a few issues w.r.t. its stability and performance, I never had any particular annoyance with the UI itself...
Now that the new and shiny Eclipse 4.2 is out of the oven, it feels more stable and somewhat snappier, but I instantly felt a dislike for some details of its UI:
I find the "curved" look of the main toolbar distracting and it seems to me that it does not mix well with any other element in my desktop. It could just be a color issue, but the toolbar is prevalent enough to merit a specific mention.
The default colors do not work well with the TFT/TN displays of the laptop and both desktop computers that I am using. The various gradients seem completely washed out, the tab separators are practically invisible and the toolbar curve looks totally weird.
It's also almost impossible to tell which view is active - Eclipse 3.x used a unique blue color for the active tab header. Juno uses a color-reversal in all inactive tabs, which probably sounds more visible, but in my opinion that effect is lost because the active tab is still in a shade of gray which is lost in the overall gray-ness of the new UI...
So, how do I get back to a more reasonable look and feel? Is there somewhere a theming option that would help?
PS.1: I use Eclipse/GTK on Linux...
PS.2: What happened to all the colors in Juno, anyway?
PS.3: Can we keep the new splash screen, though? That one, I like...
Apparently, the Eclipse developers were kind enough to leave us an easy way out:
From the Window menu, select Preferences.
Expand the General category in the Preferences dialog tree.
Click on the Appearance sub-category.
On the left side of the window, a Theme drop-down menu will appear - click on it.
Select Classic in the Theme drop-down menu.
Most important: you need to restart Eclipse after that, even though no hint to that effect appears.
This setting is mentioned in several blog posts, which for some reason I could not find until I started using terms such as "awful" and "ugly" in Google. It seems that I was not the only one to find the new theme unbearable...
There is another way documented here.
This goes a lot further than the switch to classic theme and makes it look like 3.x.
The problem with the Juno L & F is that its great on monitors with 1600x1050. But my work PC has 2 screens that are 1280x1-24. Not so great!
I found a way to make Juno look like Indigo: I know there are new fancy themes around but I'm not willing to spend time on it.
My solution is just to copy the Indigo css_prefs files into Juno directory
.metadata/.plugins/org.eclipse.core.runtime/.settings
The file you have to look for are
org.eclipse.e4.ui.css.swt.theme.prefs and org.eclipse.wst.css.ui.prefs
If you don't have them you can download from my blog http://www.venturin.net/2013/04/04/eclipse-juno-looks-ugly-in-linux-mint-14-nadia/
To restore traditional style tabs on more recent versions of Eclipse, edit e4_classic_winxp.css and change swt-simple: false; to swt-simple: true; (this assumes you are using the default Classic theme).
On Eclipse Kepler this file is located in:
eclipse\plugins\org.eclipse.platform_4.3.2.v20140221-1700\css
On Eclipse Mars this file is located in:
eclipse\plugins\org.eclipse.ui.themes_1.1.0.v20150511-0913\css
I've searched for solutions in many forums but they all tell me that usign the WindowPattern and checkign the topmost value should return true if the window is on top. However, this isn't the case for me. I am testing an application that is housed within a tab in outlok. A user can then click within the application and open a new window. I'd like to verify this window is in the foreground. Also.. this is a WPF application so I cant grab separate handles for new windows that open.
thanks
This might be a terminology problem: 'Topmost' has a special meaning in Win32 (See description of WS_EX_TOPMOST here), which basically means "floats above other ordinary windows" - it's typically used for things like tooltips, menu popups, notification balloons and the like, which float above all other windows on the screen. It's rarely by actual application windows.
An application can be the currently foreground window, above other windows, but not have this property.
An alternate approach to see if the window is in the foreground is to see if it is or contains the contains the current focus or active window.
So, I'm working on an Eclipse Plugin which includes a custom view based on analysis of source code. The majority of the time, it works great. However, if I quit Eclipse with that view open, when I reopen it, it runs into an error with either IWorkbenchWindow.getActivePage() or IWorkbenchPage.getEditorReferences() returning null. This inconsistency seems to be because the view has the focus when Eclipse quits and is the first thing that Eclipse tries to reconstruct on start up. the focus is on a non-window shell (I don't fully understand this, but that's what this said). Is there a workaround so that I can ensure that Eclipse fully loads its IWorkbenchWindow before my custom plugin regardless of what has the focus when Eclipse closes?
Thanks
You can consider using the site instead: getSite().getPage()...
Tonny Madsen pointed out in the comments that, from within a View, I can access the Active Page from getSite().getPage(), which solved the issues.
I am writing some automation scripts using Perl for testing a custom Windows application. The only way to exit the application is to automate a right click on a system tray icon (which the application creates) and clicking on exit on the menu that it shows. Is it possible to automate such clicks using Perl? I checked the Win32::GuiTest module but could not find much stuff on automating mouse clicks on system tray icons.
I don't know of a robust way to do what you are asking.
But it looks like you can make it work by first calling MouseMoveAbsPix to move to the right location, then SendMouse a RightClick. If you know the exact machine that you will be using, and know where the tray should be, you can click on the tray icon.
But be aware that this will be very, very dependent on what exactly is on the window. And this logic won't work at all if the screen is an any way different than you expect. (For instance there is an unexpected popup.)
Incidentally you might try seeing whether sending the application the key combination ALT+F4 will exit the application. There is a chance that this will work, and it should be much more reliable.
That distribution comes with examples. You first want to play around with spy.pl in order to find out the window name of the appropriate tray icon. Then in your real program you use that name to immediately address the icon, this is position independent.