Tuesday, January 17, 2012

Oxygen-gtk3 1.0 is out


The first release of KDE's Oxygen widget theme, ported to GTK 3.X applications, has been uploaded to kde ftp servers on Tuesday January 17 2012 and is available for download here. It is called oxygen-gtk3.

This release is still experimental, notably due to the small amount of GTK 3 applications it has been tested on. Still, since snapshots of the running git repository were already being circulated around for some time, we deemed it appropriate to release the current code, if only because it would make book-keeping and bug tracking easier. Also, we expect rapid progress as bug reports are being filled by users.

The result is already quite satisfactory, as illustrated on the screenshot below.


All the features of the GTK 2.x version have successfully been ported to the GTK 3.x version, and a large fraction of the code base is actually shared between the two. This includes:
  • grabbing windows from empty areas;
  • smooth animations on mouse hover and focus change
  • on fly update of the style appearance when the configuration is changed (via KDE's system settings, or oxygen-settings)

Bug reports should preferentially be filled on KDE's bug tracker, here, rather than on this blog, or on the kde-look web site. This ensures easier interactions with the reporting users.

Like for the GTK 2.x version, there will be one minor bug-fix release every month, and one major feature release every 6 month, more or less in sync with newest KDE release.

The third major release (v1.2.0) of the GTK 2.x port has also been released on the same day and is available for download here. The package name has been changed to oxygen-gtk2, to avoid confusion with the GTK 3.x version. It includes all the bug fixes that were applied to the 1.1 series, together with visual improvements that match the Qt version shipped by KDE 4.8.

23 comments:

  1. Thank you very much for your work!

    ReplyDelete
  2. Amazing, it greatly improve a KDE user experience. Thank you!

    ReplyDelete
  3. It goes without saying that this is simply awesome.

    What's the current situation with background pixmaps? I think that it's one of the most interesting features in Oyxgen and it would be awesome if new "themes" could be downloaded with GHNS etc.

    What about "Oxygen-HD"? Good scalability is more important than ever now that 4K and 8K resolution television etc. have been announced in CES and it's expected for 2K resolution ultrabooks to ship this year. Also there has been some progress on GTK land if I'm not mistaken.

    Thanks :p

    ReplyDelete
  4. Is there a way to use this under Gnome?

    ReplyDelete
  5. I feel that "THANK YOU" is not enough for this.

    Oxygen-gtk[2|3] is truly awesome.
    Thanks a lot to all the developers. Great work!

    ReplyDelete
  6. @teho
    Concerning background pixmaps, it is supported for all versions (Qt, gtk2 and gtk3) although its still an under the hood option.

    [Common]
    BackgroundPixmap=/home/hpereira/Pictures/Wallpapers/Overlay/window-overlay-1.png
    Are the secret lines to add to your ~/.kde/share/config/oxygenrc.

    No. No plan for GHNS.

    For oxygen HD, no progress on that front. It requires quite some work for all version, and is even more complicated that none of the oxygen devs has high dpi nor high size screens.

    @Owl: yes. Oxygen comes with a "default" set of parameters, for it to run outside of kde. It will not try to fetch you gnome colors etc. though (because you can't have it look for both Gnome and KDE settings; and because I know nothing of gnome settings). So you would need to edit config files by hand. We "might" work on better intergration to gnome for future versions (but that would require that I install gnome first).

    @Others: well thanks for the support.

    ReplyDelete
  7. Congrats on the good work. I wonder, if it's possibly to replace the GTK dialogues with KDE's, because GTK's dialogues are really bad. D:

    ReplyDelete
  8. +1 for KDE dialogs over GTK's (if possible, in both Oxygen-GTK2 and 3)

    And where is Oxygen-GTK3's source hosted? I'm building KDE and Oxygen-GTK from KDE git (which I saw was the one that got renamed to gtk2 in CMakeLists) and would like to have it, too.

    Thank you a lot, guys, for the great work you do! Oxygen is the best theme I find anywhere!

    ReplyDelete
  9. @ComaWhite and Janz
    Can't happen. This is outside the scope of what a widget style can do.
    As for where the code is, it's explained on the kde-look page.
    Basically either

    git checkout gtk3

    from your existing repository clone;
    or

    git clone -b gtk3 ...

    At another location.

    ReplyDelete
  10. Sorry, failed to look there prior to ask here (got stuck with the announcement and did no research aside snooping kde git). Thank you.

    On the subject, please confirm me this: will o-gtk3 by itself cover both gtk2 and 3 apps or will we really need to have both of them? Thanks again, in advance.

    ReplyDelete
  11. Great to hear this :-)

    Just a proposal: What's about changing the version number system, adopting it to the KDE version it is designed for? Means: oxygen-gtk2 and oxygen-gtk3 in version 4.8.0 for KDE 4.8.0, in version 4.9.0 for KDE 4.9.0 ... Just to stay in track...

    ReplyDelete
  12. @Janz
    No. The Gtk3 version is for gtk3 applications only, and the gtk2 for Gtk2 applications (hopefully there will be more and more of the former, and less and less of the latter). You need both in the meanwhile. In fact they are not even installed the same way. (see README files for details).

    @Lukas. Version number is made to reflect the maturity of the code. Gtk3 version is far less mature than Gtk2. Hence 1.0.0 vs 1.2.0. Also, when the code matures, the release schedule might change and not be in sync with KDE's anymore. So I'd rather not jump to match 4.8.

    Basically, oxygen-gtk is not shipped with KDE, so has no reason to have the same version numbers, and trying to match them is bound to fail sooner or later anyway.

    (same applies to many KDE related apps, such as Dolphin, digikam, etc.)

    I leave it to linux distributions to pick the version they prefer.

    ReplyDelete
  13. @Hugo I know, that you can't do it, but it would have been nice, if we was able to have it. D:

    ReplyDelete
  14. Icons are nice, but that GTk file picker (seen in your screenshot) is still a headache to use. Please unify the file picker and print dialog backends, so that whichever desktop is running has it's file picker in use by all apps!

    The icons look great, congrats on the release!

    ReplyDelete
  15. @lefty (same as for ComaWhite and Janz). This is out of topic. A widget style is just a widget style. It has nothing to do with the underlying apps (and dialog layouts) that are called by applications when one action or another is performed.
    So basically this post is not the right place to make this type of request: you will not get any feedback. You should ask elsewhere.

    ReplyDelete
  16. @Hugo: Sorry for being offtopic, but what font and which font-hinting settings do you use?

    ReplyDelete
  17. @Thomas
    Helvetica, 8pt
    Anti-aliasing: "system settings" (in KDE system-settings).
    Ok. Does not help much, does it ?
    (not sure what system settings it is in fact)

    ReplyDelete
  18. Hi Hugo,
    I hope you see it in time.
    I just saw a commit in git: "Replaced g_timeout_add by thread-safe gdk_threads_add_timeout function."
    And I just wanted to comment you, that gdk_threads will be deprecated in next realease..
    https://mail.gnome.org/archives/gtk-devel-list/2012-July/msg00066.html

    Regards

    ReplyDelete
  19. I think that none exists a replacement.

    But perhaps here you will find the answer: http://developer.gnome.org/gtk-faq/stable/x499.html

    Basically if you not start gtk_threads, all the g_timeout/idles run on the main thread.
    So, you should only revert the change, and probably the bug is incorrect.

    Not know more details. Sorry.

    ReplyDelete
  20. @Matias
    Could you actually post these comments (and links) to the actual bug report rather than here ? I'm getting quite confused here. The reported crash do look like actual thread issues and the (deprecated) suggested change there did sound reasonable ...
    I'd like to have feedback from the reporter on this issue. Thanks !
    (besides, blog posts are not the right place for such discussions. Correct ?)

    ReplyDelete
  21. For the record: Link to the bug report:
    https://bugs.kde.org/show_bug.cgi?id=306671

    ReplyDelete

Followers