The first major release of Oxygen-gtk has been uploaded to kde ftp servers on Wednesday June 15 and is available for download here.
This release comes with many improvements over the 1.0 series, which include:
- animations (smooth glow on mouse-over and focus for virtually all widgets, similar with what exists for the Qt version), controlled using the same configuration options as the Qt version, via oxygen-settings;
- on-fly update of the applications when configuration options are changed, via interfacing of the style to dbus;
- improvement of the rendering of many widgets to have better consistency with the Qt version of oxygen, and remain in sync with latest design changes that will be shipped with KDE4.7. This affects notably scrollbars, sliders, groupboxes (Aka GtkFrames), etc;
- real inner shadows for lists, icon views and other text edition widgets (thanks to Ruslan for making this possible);
- better integration with oxygen's window decoration (effective only with kde 4.7), in the sense that the decoration will detect applications for which the window background gradient cannot be rendered (such as Firefox, Thunderbird, open-office, etc.), and consistently paint itself flat;
- support for KWin's new shadow system, that applies to menus, drop-down lists and tooltips;
- a dedicated demo application, called oxygen-gtk-demo, which is similar (though not identical) to its oxygen-demo Qt counterpart, as illustrated in the screenshot below.
oxygen-gtk-demoThis release is meant to be used with KDE SC 4.7, which should become available some time this summer, due to the redesign of some Qt widgets that will be shipped with it. In the meanwhile, users will experience some visual inconsistencies (nothing dramatic though), and might prefer to stick to the 1.0 version.
As for the 1.0 series, we (Ruslan, Cédric and I) will provide some monthly bugfix releases of the 1.1 version, based on bugs reported to us at bugs.kde.org. In parallel we will work on the next major release (1.2), focusing notably (and without any warranty) on the gtk3 port as well as on making oxygen-gtk a more standalone gtk widget style, that can also be used seamlessly outside of KDE.
A little off topic. I find dark themes to be under tested with gtk apps. It would be nice if KDE had 1 default dark theme that was tested against gtk apps with libraries like this.
ReplyDeleteAwesome as always.
ReplyDeleteIf oxygen-gtk works as standalone, could there be oxygen-qt standalone version as well? What about the scalable widgets, possible with gtk? Does oxygen-gtk yet support the new background pixmaps? A few questions that came to my mind >_>
Just about the only gtk app I use often is Chromium and it uses colors quite strangely, paintings the active tab bar in different color than the navigation bar. This looks unconsistent and there's even a "fix" for it at "code.google.com/p/chromium/issues/detail?id=16271". It would be nice if this could be included in Oxygen-gtk.
Thanks.
As always, very nice work, kudos :)
ReplyDeleteI hope it will be possible to turn off the feature to consistently render "flat" style titlebars in firefox, especially because of the wonderful oxygen kde firefox theme:
ReplyDeletehttp://kde-look.org/content/show.php/?content=117962
@supert0nes
ReplyDeleteTo my knowledge, dark themes are supported as well (or as badly) with oxygen-gtk as with oxygen-qt. (and I agree there is room for improvement in both cases, mostly due to our color calculations). Or do you have any specific examples in mind ? (if yes, feel free to post bugs + screenshots at bugs.kde.org, we'll work on it).
@teho
ReplyDelete- Better scaling for widgets is also on todo list, in fact for both Qt and Gtk. Its been left behind for quite some time and is becoming more important these days with the multiplication of devices x size x dpi. But this is a complicated issue ...
- yes oxygen-gtk does support background pixmaps consistently with oxygen-qt. But its a (non-advertise) secret, still (for both)
- standalone oxygen-qt: likely not. However, there is an effort to make kde libraries more modular. I'll pay special attention that "minimal" kde libraries needed for oxygen-qt will be made available through this modularization, so that building oxygen would become possible with a very tiny (and easy to build) part of kde (namely, something like kconfig, and kcolorutils).
- as for Chromium: I always thought the bad coloring of the tabbar was a Chromium issue (in the sense that all my attempts to fix it inside oxygen-gtk have failed so far). I'll take a look at the link you sent (from quick reading, looks promising, so I add to todo, for 1.1.1)
@Ianjo
ReplyDeleteThanks for the support ! Most appreciated !
@Daniel André
ReplyDeleteyes, you will still be able to disable the automatic hinting of the decoration, and force background (or flatness) to any window you want. In fact, the "exceptions" mechanism is still available, for one; and besides you'll still have the option to stick to the old behavior (from up to kde4.6).
>As for the 1.0 series, we (Ruslan, Cédric and I)
ReplyDeleteI was not very active for 1.1 branch but will contribute as soon i find a bug: oxygen-gtk is quite perfect ;)
I love to see this. oxygen-gtk really improves greatly gtk-apps in KDE.
ReplyDeleteIt's great to see that scalable widgets are on the long-term TODO list. (I like this, also because I had added a (more) resolution-independent KDE to the wishlist http://bugs.kde.org/show_bug.cgi?id=272266 and am doing some minor patches for this in other parts of KDE.) On what will the scale factor depend? Will it be determined on a per-widget basis? Or on the DPI size? (Xft.dpi is X11-only, as far as I know in Windows this isn't freely configurable, don't know what's about Mac). Or simply on the font size?
@id:
ReplyDeleteto be honest, I have no idea what I will base the scale factor on. My plan is to start setting a "global" scale factor in both styles (possibly setable on option), and make sure that all widgets render properly and consistently when this parameter is changed. (as a side effect, that would allow to make "high-definition" screenshots :) ) ... though I'm not entirely sure on the details.
Nevertheless, once this is in place, choosing what controls this unique scale factor should be rather easy. correct ?
@Hugo
ReplyDelete> Nevertheless, once this is in place, choosing what controls
> this unique scale factor should be rather easy. correct ?
It's your code ;-)
The background of my question is this one: I think it would be great to have a single option to "make KDE bigger", to zoom in. Only one option that affects the hole desktop.
Because of this, I think it would be a good idea to coordinate this, because such a feature would affect various aereas of KDE, and in parts also the underlying functions like fontconfig and XCursor. Such an option would have to affect various settings:
- Font sizes are in "point" and therefor it depends on the DPI setting at how many pixels renders a 9 pt font.
- With cursor themes that provide various sizes of the cursor, the size is choosen according to the DPI.
- KDEUI: For example the icons in the toolbar: The size can be changed manually in systemsettings, but it would be nice if this could be scaled automatically.
- Plasma Desktop Workspace: The control elements that appear when you hover with the mouse over an plasmoid have fixed pixel size. It would have to be scalable.
So, for a hole scalable desktop you have to change various options - at the moment manually. It would be great to unify all this ...
Just letting you know that (besides it being nearly perfect) the tooltips in for example chrome and firefox are still in the GTK color style. Not in the new black KDE style that you see in the System Settings.
ReplyDeleteAwesome job so far! I use it for pidgin and like the native integration of it :)
Is it possible to use different icon theme for gtk with this engine? (namely KFaenza for KDE and Faenza for gtk)
ReplyDeleteI tried adding 'gtk-icon-theme-name="Faenza"' to /usr/share/themes/oxygen-gtk/gtk-2.0/gtkrc without luck.
@Tomi
ReplyDeletethe icon theme that is used is read from kde options (for consistency). So
- if you have kde installed, change the theme in "system-settings"
- if you don't have kde installed,
change the icon theme name inside either
/usr/share/themes/oxygen-gtk/gtk-2.0/kdeglobals
or $HOME/.kde/share/config/kdeglobals
[Icons]
Theme=Fanzea
I compiled successfully the oxygen-gtk 1.1 and in
ReplyDelete"System Settings" under "GTK+ Appearance" i choose as "Widget style" the oxygen-gtk entry.
Nevertheless, GTK+ applications like Chromium and Skype have the same look. For example, in Chromium the drop down menu and right click menu are the same as before.
Do you know what i am missing?
@Pergi
ReplyDeleteSkype actually uses Qt, and not the oxygen-gtk theme.
You can change its appearance in options->general->choose style.
(use oxygen, if it is there).
For google chrome
select: preferences->personal stuff and select "use gtk+ theme here". That should do the trick also.
@Hugo
ReplyDeleteYes, Skype uses Qt but the drop down menu is a bit ugly, like it is a GTK+ application in KDE. In the menu of "Choose style" in Skype, there is not an entry with the name "Oxygen".
Unfortunately, the use of GTK+ Theme in Chromium didn't came with the desired results. I use the "Krome Oxygen" theme and it has a better look and feel.
Anyway, may i ask you something else. If oxygen-gtk is working properly in my system, the oxygen-gtk-demo should be like the image of oxygen-gtk-demo that you uploaded in this post, right?
Probably, all the problems derived from the fact that i got an ugly appearance of it. (http://goo.gl/t6tKh)
yes. Obviously, oxygen-gtk is actually not used, though installed.
ReplyDeleteConcerning your comments on skype, and the appearance of menus. Which Desktop Environment are you using ? KDE ? Gnome ? Anything else ?
The non appearance of oxygen in the skype theme means that you don't have oxygen (from kde) installed (or found).
I have KDE 4.6.5.
ReplyDeleteIn Skype there is an entry called "Desktop Settings" among the other styles, and this the default.
Well, about having oxygen, in System Settings -> Application Appearance -> Style, the "Widget style" is Oxygen.
Thanks for your quick replies :)
@Pergi
ReplyDeleteA blog is not a help forum. You could file a bug to bugs.kde.org and give detail here.
Notably, you could post screenshots about what exactly is wrong with skype (which, again, has nothing to do with oxygen-gtk anyway)
There is obviously smthing wrong with your install, from the fact that the oxygen-gtk style is not used by gtk applications (such as oxygen-gtk-demo).
See the last section of the README file for some example of gtkrc config file that should allow you to select the right gtk theme, though this is not guaranteed to work).
Also you could try ask questions on your distribution specific forums. You might get more help there. (I'm more competent with code base than with installtion details).
Yeah, you are right. I will check the last section of README and maybe ask somewhere else that is more appropriate for such an issue.
ReplyDeleteThanks for your help anyway.
Hello Hugo,
ReplyDeleteGtk2 branch does not respect "gtk-alternative-button-order" of gtkrc.
Use Oxygen (Last git) in xfce and is annoying. :S
mmm. in short, need to add this also in the gtk2 branch.
commits.kde.org/oxygen-gtk/c80616a9469098b9ffb668090844f33631f356e1
Thanks to all.
Regards.
@Matias
ReplyDeleteThanks ! done. Hopefully it works now.
D'Oh!.
ReplyDeleteSorry. Seems to be doing the opposite effect to what I expected.
I want to respect this configurations from the gtkrc. :(
I prefer gtk-alternative-button-order = 0, and modifying the rc does not work.
Apology. I'm the only disoriented that use oxygen with xfce. jajaja.
Adding a "if( _KDESession )" (on gtk2 and gtk3) fix everything. It works for KDE (alternative order) and also xfce (Common Order)
ReplyDeleteNow I'm installing kde to test properly.
Regards!.
@Mattias
ReplyDeleteFirst, this kind of issues are better reported on https://bugs.kde.org
Second: what matters is that Qt applications are consistent with Gtk applications.
What's the button order of your Qt/Kde apps on xfce ? Common or alternative ?
1.. Yes.. Sorry. Last comment here.
ReplyDelete2. Yes!. Also consistency between gtk2 and gtk3. Love it. :)
Qt regardless of kde: There are few dialogs that use more than one button. Mainly preferences (Acept|Close) or printing (Print|Close) and use alternative. HIG of kde assume.
Gtk apps in xfce/gnome hope: "gtk-alternative-button-order = 0". Is the same as not declaring it.
And result in "Close|Accept" on any preferences, and "Close|Preview|Print" on printing dialog. Also "Prev|Close|Next" in any search dialog like geany or leafpad.
If use "gtk-alternative-button-order = 1" result in "Accept|Close", "Print|Preview|Close" (Standard in any kde app, but not in gnome/xfce) and "Next|Close|Prev". (Inconsistent in any desktop).
Gtk in kde: Well. Is debatable, but "Next|Close|Prev", is incorrect in any desktop, and can not prevent it.
You surely know better the pros and cons because use "alternative = 1" in kde.
So.. Out of kde, I prefer "alternative=0". In kde it is debatable but acceptable.
Now I can confirm that adding the "if( _KDESession )" works in kde (with alternative = 1) and in xfce4 (With alternaive = 0 or, according to this in the gtkrc)
P.s.: Cmake no respect "-DLIB_SUFFIX=64" in gtk2.
Not sure I understand all the details above, but my point is:
ReplyDeleteif kde/Qt apps, when running under xfce, are of type "Acept|Close or printing Print|Close"; then I want gtk apps with oxygen-gtk to be just the same, because that is the point of oxygen-gtk (consistency across apps). Will therefore _not_ put an "if _kdeSession" in the code. Sorry. If it was working for you better before (whith gtk-alternative-button-order in gtkrc, manually edited by you), then I can revert the commit, but that's it ...
.. as for Next|Close|Prev
ReplyDeleteits a bug. Should be reported as such, and we should attend to fix it, provided that you give the details of which application exhibits this behavior so that we can reproduce ...
D'Oh!.
ReplyDeleteQt4 YES has integration with gtk !. The problem is backwards!!.
Apologies again!.
I had not tested well, a now rectify!.
Applications kde/qt in xfce, automatically sort the buttons. If change gtk-alternative-button-order, qt apps change, just like gtk aplicacions.
Tested with kate, krite, amarok, and clementine over a xfce 4.8 desktop. Need a screenshot?
Works fine, but you must add the "if", and so would respect the gnome HIG guidelines and also those of kde.
I promise. Last comment!-)
ReplyDeleteOn the previous comment. The tests made with qt4 configured to emulate gtk. That also replace the file open dialog for example. (Option by default).
If I select oxygen on qtconfig-qt4 (Not installed by default with kde), ignore any type of integration. But this is not the most normal.
Regards.
And sorry so many comments.