Thursday, June 16, 2011

Oxygen-gtk 1.1 is out



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-demo


This 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.

32 comments:

  1. 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.

    ReplyDelete
  2. Awesome as always.

    If 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.

    ReplyDelete
  3. As always, very nice work, kudos :)

    ReplyDelete
  4. I 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:
    http://kde-look.org/content/show.php/?content=117962

    ReplyDelete
  5. @supert0nes
    To 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).

    ReplyDelete
  6. @teho

    - 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)

    ReplyDelete
  7. @Ianjo
    Thanks for the support ! Most appreciated !

    ReplyDelete
  8. @Daniel André
    yes, 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).

    ReplyDelete
  9. >As for the 1.0 series, we (Ruslan, Cédric and I)

    I was not very active for 1.1 branch but will contribute as soon i find a bug: oxygen-gtk is quite perfect ;)

    ReplyDelete
  10. I love to see this. oxygen-gtk really improves greatly gtk-apps in KDE.

    It'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?

    ReplyDelete
  11. @id:
    to 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 ?

    ReplyDelete
  12. @Hugo
    > 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 ...

    ReplyDelete
  13. 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.

    Awesome job so far! I use it for pidgin and like the native integration of it :)

    ReplyDelete
  14. Is it possible to use different icon theme for gtk with this engine? (namely KFaenza for KDE and Faenza for gtk)

    I tried adding 'gtk-icon-theme-name="Faenza"' to /usr/share/themes/oxygen-gtk/gtk-2.0/gtkrc without luck.

    ReplyDelete
  15. @Tomi

    the 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

    ReplyDelete
  16. I compiled successfully the oxygen-gtk 1.1 and in
    "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?

    ReplyDelete
  17. @Pergi
    Skype 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.

    ReplyDelete
  18. @Hugo
    Yes, 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)

    ReplyDelete
  19. yes. Obviously, oxygen-gtk is actually not used, though installed.
    Concerning 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).

    ReplyDelete
  20. I have KDE 4.6.5.
    In 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 :)

    ReplyDelete
  21. @Pergi
    A 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).

    ReplyDelete
  22. 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.
    Thanks for your help anyway.

    ReplyDelete
  23. Hello Hugo,
    Gtk2 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.

    ReplyDelete
  24. @Matias
    Thanks ! done. Hopefully it works now.

    ReplyDelete
  25. D'Oh!.
    Sorry. 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.

    ReplyDelete
  26. Adding a "if( _KDESession )" (on gtk2 and gtk3) fix everything. It works for KDE (alternative order) and also xfce (Common Order)

    Now I'm installing kde to test properly.

    Regards!.

    ReplyDelete
  27. @Mattias
    First, 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 ?

    ReplyDelete
  28. 1.. Yes.. Sorry. Last comment here.
    2. 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.

    ReplyDelete
  29. Not sure I understand all the details above, but my point is:

    if 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 ...

    ReplyDelete
  30. .. as for Next|Close|Prev
    its 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 ...

    ReplyDelete
  31. D'Oh!.
    Qt4 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.

    ReplyDelete
  32. I promise. Last comment!-)

    On 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.

    ReplyDelete

Followers