I’ve made several posts previously about the difficulties I’ve had with Eclipse and Gnome’s Adwaita theme: menu elements that have too little contrast to read, poor color choices, etc. I even took a stab at creating my own GTK3 theme to deal with the problem.
I’m happy to report that my efforts are now obsolete. Eclipse Mars (now available in Fedora 22) has made significant improvements to the Dark theme (set under Preferences -> General -> Appearance). However, if you’re using Adwaita, the top menu bar is gray text on grey background. The simple fix is to change to the Adwaita Dark theme just for Eclipse. Here’s how:
/usr/share/applications/eclipse.desktop
in your text editor of choice.Exec
line to read
Exec=env GTK_THEME=Adwaita:dark eclipse
The one gotcha is that when you update the eclipse-platform package, it will destroy the changes you’ve made in the desktop file so you’ll have to redo them. But that’s a small price to pay in my opinion.
Dear Internet,
As I noted in an earlier post, Eclipse on Fedora 22 has some usability problems with the colors it uses. Eclipse uses GTK 3 for a lot of the theming of the interface. With the Gnome Adwaita theme, several of the drop-down dialogs (like Content Assist) have very little contrast between the background and foreground of a selected item. The result is the highlighted text is extremely difficult to read. Your only recourse is to mess with GTK settings.
I had managed to address an issue with the Content Assist drop-down only to run into another issue with the Quick Outline drop-down. Finally I gave up and said, “to heck with it, I’m going to redo the whole thing.” To check out the result I came up with, head over to the Eclipse Graphene repo.
Here’s an example:
When I write Java, I use Eclipse. It does what I need it to do, but there are a few things about it that bother me. One of them is that Eclipse allows very limited control over the color scheme. Most of the color settings are inherited from the desktop theme that you’re using. I recently upgraded to Fedora 22 and with the Adwaita theme under XFCE, this is what the Eclipse content assist dropdown looks like:
Notice how close the foreground and background colors are for the selected item. I find that intolerable. I’m not sure exactly why Eclipse is picking that color combination, because the content assist object is a GtkTreeView which has the selected item background color set to cerulean blue in Adwaita. In any case, to fix it create ~/.config/gtk-3.0/gtk.css
with the following contents:
GtkTreeView:selected {
background-color: @theme_selected_bg_color;
}
That snippet will override whatever weirdness is going on with the content assist dropdown and set the background color back to the theme’s default background color for selected items. You can also just set it to a hex value. Note that this setting will apply to any GTK3 application, but that should be all right since you’re just asking the theme to do what it is already doing.
Back in late 2013 I joined what was jokingly referred to as the Red Hat IT “DevOps” team. We didn’t like that name, so we changed it and there-after became officially known as Team Inception. From the time the team was formed, we all accepted that the team was to retire in 18-24 months. We were totally cool with that too! To us having a pure “DevOps” team in perpetuity just didn’t make sense.
Over the course of the team’s lifespan I feel like I experienced incredible growth, both personally and professionally. I’m proud to look back at all the cool things we accomplished as a team, and I’m even more thankful to have had the opportunity to be a member of that team. Here’s a taste of some things we did as a team publicly:
Two week ago (2015-06-20 → 2015-06-24) the DevNation and Red Hat Summit 2015 conferences were held in Boston, MA. Of the many excellent speakers and panel groups [S|D] that held sessions during the conferences, there’s one group I am especially fond of: My old team, Inception.
On Wednesday, July 24th we held a panel session called Bootstrapping a DevOps Movement in Red Hat IT. This was our final activity together as Team Inception. During this panel-style session Jen Krieger, our Product Owner/Scrum Master, facilitated a look back at some of our experiences during our 18 months as the Red Hat IT “DevOp Team”.
We began the initial round of questions with what our individual perceptions of “DevOps” were before the team had formed. We followed that with what ended up being a great Q&A with the audience (thank you everyone who participated!). We ended the panel with our closing thoughts on what “DevOps” means to each of us now.
Here’s a snippet from the official session description:
Topics will include
Panel
Panel facilitator
Between ourselves, we casually referred to this as our final team retrospective, an honest (and very public) look-back at lessons learned over the last year and a half.
Click play below to watch the full video now, or go directly to it on YouTube.
And before I forget. So much thanks to Andrew “Hoss” Butcher [GH] for recording, editing, and posting the recording for us. I (we) owe you many Tasty Beverages for that.
I wanted to use a Logitech R400 that a friend loaned my in a presentation, but I wanted to tweak the mappings for the buttons a bit. My presentation is done using Reveal.js and uses both left/right and up/down. The R400 has four buttons but two of them are mapped to “go to black screen” and “slideshow mode” neither of which is useful to me. Here is how I fixed it in Fedora 20.
/etc/udev/hwdb.d
/etc/udev/hwdb.d/99-logitech-r400.hwdb
# The lower left button actually emits two
# different scancodes depending on the state of
# the "presentation".
# E.g. one code to start and one to stop.
keyboard:usb:v046DpC538
KEYBOARD_KEY_70029=up
KEYBOARD_KEY_7003E=up
KEYBOARD_KEY_70037=down
KEYBOARD_KEY_7004B=left
KEYBOARD_KEY_7004E=right
This maps the left and right buttons to left and right, the both states of the slideshow button to up, and the blank screen button to down. The 046D
is the Logitech vendor code and the C538
is the model number. Those magic numbers after “KEYBOARD_KEY” are the scancodes associated with the button. Supposedly showkey --scancodes
will display them but I couldn’t get that to work and ended up taking them from another blog post.
# udevadm hwdb --update && udevadm trigger
# xev | grep -A2 --line-buffered '^KeyRelease' | sed -n '/keycode /s/^.*keycode \([0-9]*\).* (.*, \(.*\)).*$/\1 \2/p'
/etc/udev/rules.d/99-logitech-r400.rules
SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c538", IMPORT{builtin}="hwdb 'keyboard:usb:v046DpC538'", RUN{builtin}+="keyboard"
That will import our custom mapping when the USB receiver is plugged in.
Thanks to the following who helped me figure all this out: