Community
Participate
Working Groups
F1 Suse 8.0, KDE 3.0, GTK 2 Having flat tool bar buttons in the view pane title bar would really improve the overall look of the GTK port.
Agreed. We've got more serious issues for R2.0, but we'll take a look at this if we have time.
This used to be in the gtk1x version, and the code was explicitly removed. The API for setting the "flat" toolbar style, was *removed* (not just deprecated) from GTK2. The "Incompatible changes from GTK1 to GTK2" document explains that it is wrong for the application to change the toolbar appearance when the user has customized them to his/her taste. Therefore, the flag was moved from the instance side to the class side. To fight this, would be overly aggressive against the GTK UI guidelines.
The problem is we are "faking" other aspects of the toolbar area. For example, we are faking the chevron support in CoolBars (the border around the chevron itself looks very poor). We should discuss this again, but I'd like to argue that the current appearance is poor, even if it is just a side-effect of the way the eclipse UI is driving GTK. I want to revisit this post R2.0. Re-opening PR.
This is fixed in F3.
If I understand the original report correctly, this isn't fixed in 20020723.
Created attachment 1739 [details] eclipse.png - A screenshot of the GTK2 build
Could post here which theme you are using?
Crux, which is included with most major Linux distros. The screenshot above is from the Mandrake 9.0 Beta 1 which comes with Gnome2 and GTK2 by default (oooh... aahh).
Created attachment 2091 [details] redhat.png - A screenshot of Eclipse on RedHat 8.0
The above screenshot shows what Eclipse looks like by default on RedHat 8.0. The "Default Theme" hack worked on most systems which didn't ship with Gnome 2.0. However, now that distros are shipping Gnome 2.0, the "GTK-Default" theme is being overridden by vendors, so the user doesn't get the "GTK-Default" theme by default. The distros are choosing default themes that look better, which makes Eclipse look terrible (because of this bug).
The question that comes to mind immediately: does Bluecurve use any alpha transparencies? (I haven't had time to install 8.0 yet). If the answer is yes, then we are screwed in a major way.
We just played around on Mandrake 9.0 and the problem occurs with every theme except the Default theme. Taking a close look at how the Eclipse toolbars compare to other GTK+2 applications (like Nautilus in Gnome 2), I see what's happening. The 3D etching is actually the correct behavior. It matches the etching that is drawn on other toolbars. The difference is that it looks like the native toolbar (the correctly etched one) is being drawn inside the emulated toolbar and a few pixels of the emulated toolbar are visible all around the native bar. A simple hack to make this look better might be to increase the width and height of the native toolbar to match the size of the containing emulated toolbar. This won't completely solve the problem, because you'll still see the hard left edge of the (right-justified) native toolbar in the toolbar of views, but it should go a long way to improving the appearance.
*** Bug 26444 has been marked as a duplicate of this bug. ***
Has anyone tried the fix I suggested?
Ok Jared, We just try your hack idea in the another way around, instead of increasing the height of the native toolbar we decreased the height of emulated coolitem. More precisely we got rid of the margins space (at botton and top) on the coolitems. fix > 20021115
Created attachment 2629 [details] 20021127-crux.png - A screenshot of build 20021127 The toolbar looks a little better in the last build, but there is still a discernable margin surrounding the native toolbar. Notice that you can see an etched border above the native toolbar, and the left and right of the emulated still hang out. Also, there seems to be a bug in the far right bar in the "CoolBar". Notice that it is drawn much smaller than the other toolbars. A few suggestions: 1. Use native widgets - GTK supports movable sub-toolbars natively. I don't think we need the emulated widgets at all. 2. Shrink the emulated widget to a better fit - The emulated widget is still noticably larger than the native widget and the effect is still very unappealing. 3. Make the "CoolBars" an option that can be turned off - There may be a use case where the CoolBars are important, but I've never seen anyone use them. It would be nice if people who don't use this feature would be able to get rid of the ugly side effects. Personally, I just want a simple, native toolbar.
Created attachment 8643 [details] Patch for supporting flat toolbars This patch fixes Toolbar to support SWT.FLAT. It uses the Gtk+ RC API to define a style specific for swt flat toolbars, and uses it to set the shadow-type property. Without SWT.FLAT, toolbars use whatever is default for your current theme. I think this is the correct behavior. Using this patch significantly improves how coolbars look. While this patch is a real improvement, I think the ideal but more complicated solution would be for the coolbar to read the style properties set in the current style for GtkToolbar and try to honour them at the top level (for example, honouring shadow-type on the coolbar as a whole). This patch adds a new native method but doesn't include the metadata since I'm still not down with that scene.
I have released the patch.
