Hide Forgot
Description of problem: In the package explorer (and possibly other "tree" views) the items in the tree view appear to be "double spaced". this only happens in gnome. in xfce in the same account on the same machine it is fine, so it may have something to do with the gtk theme being applied. I have tried hacking the e4_default_gtk.css (line-height css property) and while I can change the font (font-size css property), I cannot change the spacing. Version-Release number of selected component (if applicable): eclipse-platform-4.2.2-0.1.git20121217.fc18.x86_64 How reproducible: always Steps to Reproduce: 1.open a project. 2. 3. Actual results: items in "package explorer" are double spaced compared to the way they should be Expected results: single spaced. Additional info: impact: half the information can be seen at a time.
Can you please attach screenshots? Is the spacing different in Eclipse than it is in other GTK apps? Say, gtk-demo (part of gtk2-devel)?
Created attachment 697416 [details] package explorer under MATE desktop - normal for eclipse over last 8 years
Created attachment 697417 [details] package explorer under GNOME desktop - large spacing
Eclipse seems to inherit the spacing from GTK (the spacing is the same in gtk-demo). Here is an example of a similar problem http://nostar.net/pics/gnome_vs_kde_treeview.png. Assigning to gtk.
Additionally, the two screenshots for this bug are both gtk, although one is gtk-2 (MATE desktop) and one is gtk-3 (GNOME).
In fact I see the bug was changed to gtk2 component, I think the bug is gtk3 component. I'm going to change it to gtk3 as it is fine in gtk2.
Eclipse on Fedora 18 uses the gtk2 library. The problem you see is most probably caused by the a change in gtk themes. Could you please verify whether changing the gtk theme changes the line spacing?
changing the description since eclipse is no longer referenced and "package explorer" is ambiguous.
After some researching and hacking, the following in ~/.gtkrc-2.0 is enough to restore sanity (btw this confirms what was said in comment#7 that this is gtk2 indeed). ------- style "tree" { GtkTreeView::vertical-separator = 0 font_name = "xxxxx 8" } class "GtkTreeView" style "tree" --------- I'm not sure what the font is if an "unknown" font is used, but the 8 seems to help as well. HTH.
Just a small correction: the .gtkrc-2.0 file states: # -- THEME AUTO-WRITTEN DO NOT EDIT The styling correction can be added to ~/.gtkrc.mine.
a small correction to your small correction ;-) The file .gtkrc-2.0 did not exist until I created it. Moving the contents to .gtkrc.mine did NOT override the theme in eclipse the way having it in .gtkrc-2.0 did.
For the purposes of googlers, here's my final solution, cobbled together from bits on the 'net. I still believe in my heart this is an eclipse (fedora) "bug", in that when a user chooses "classic theme" it should NOT be "distorted" by the gtk adwaita theme, but should look like it has for years (the very definition of classic), which is approximated by this gtkrc, however this comment does serve as a practical workaround, and this does seem to be an aesthetic issue. Save the belowe gtkrc snippet to /some/path/gtkrc.eclipse and launch eclipse like: GTK2_RC_FILES=/some/path/gtkrc.eclipse eclipse --------- cut ---------- style "gtkcompact" { GtkButton::default_border={0,0,0,0} GtkButton::default_outside_border={0,0,0,0} GtkButtonBox::child_min_width=0 GtkButtonBox::child_min_heigth=0 GtkButtonBox::child_internal_pad_x=0 GtkButtonBox::child_internal_pad_y=0 GtkMenu::vertical-padding=1 GtkMenuBar::internal_padding=0 GtkMenuItem::horizontal_padding=4 GtkToolbar::internal-padding=0 GtkToolbar::space-size=0 GtkOptionMenu::indicator_size=0 GtkOptionMenu::indicator_spacing=0 GtkPaned::handle_size=4 GtkRange::trough_border=0 GtkRange::stepper_spacing=0 GtkScale::value_spacing=0 GtkScrolledWindow::scrollbar_spacing=0 GtkTreeView::vertical-separator=0 GtkTreeView::horizontal-separator=0 GtkTreeView::fixed-height-mode=TRUE GtkWidget::focus_padding=0 font_name = "xxxxx 9" } class "GtkWidget" style "gtkcompact"
I hit this issue with the Geany IDE's treeview (gtk2) - default treeview spacing looks ugly. I'm using Adwaita GTK theme under KDE. Fixed with David's hint (short version): cat >>~/.gtkrc-2.0-kde4 <<_EOF style "compactTree" { GtkTreeView::vertical-separator=0 } class "GtkTreeView" style "compactTree" _EOF Thanks, David!
This is not a gtk3 bug. It is not even a gtk2 bug - if anything, you are complaining about the theme defaults. But if applications have very specific requirements, they should install and parse their own rc file.
I object to the closure of this bug on the following grounds: My basic claim (which may not yet be effectively stated as it took a while to understand the nature of the problem): The eclipse "classic" theme should look like it always has, which is the very definition of "classic". The eclipse "classic" theme should not be altered by the look+feel of the GTK/Gnome theme, that is what the eclipse "GTK" theme is for. To me this is an eclipse bug (which is where I had it originally), I think. The fact that the "GTK" theme becomes "ugly" or whatever is a completely different debate, and one that can never be resolved productively IMHO. Matthias, how do you feel about this?
> Matthias, how do you feel about this? No feelings at all. It is just not a gtk3 bug.
Re-opening as per comment#15 and comment#16. Re-assigning to eclipse. Not sure which subcomponent "owns" the themes so leaving it at "eclipse".
It is not gtk3 bug because Eclipse uses Gtk 2.x still. David, would you please test eclipse with gtk 3.x? On Fedora 19 just export SWT_GTK3=1 and launch eclipse from the same terminal.
Created attachment 756447 [details] summary of spacing in different platforms I have tried with GTK3 enable SWT in F19 (beta). Result is better but far from good. I have attached an image showing the different line spacing on different platforms. You can see from this image that the "classic" theme in linux under F19 is still being adversely affected by the desktop theme.
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.