Saturday, August 31, 2013

Some news from the oxygen world

oxygen-gtk

Last week we've released two feature versions of oxygen-gtk, namely 1.4.0 for oxygen-gtk2 and 1.2.0 for oxygen-gtk3.

Alongside with the usual amount of bug fixes, the main new feature of these releases is the ability to get them compiled and working on non-linux operating systems, and more precisely on windows (see screenshot).

The Gimp, running on Windows (tm) with oxygen-gtk

The process of compiling oxygen-gtk2 and oxygen-gtk3 on windows is somewhat complicated (requires cmake, MinGW, gtk2/gtk3). Forcing applications such as Gimp or Pidgin to use the style - once it is successfuly compiled - is even more complicated, since these applications are usually distributed with bundled versions of gtk and standalone configuration files. Describing this is beyond the scope of this post and daring users will have to resort to google to get it right.

For the gtk3 version, we also enabled support for non X11 backends, such as Broadway, which allows to run gtk applications in your browser, via HTML5.
Oxygen-gtk3-demo, embedded into a web browser, using the Broadway backend


oxygen-qt

For the kde/qt version, oxygen has been successfully ported to KDE-Frameworks 5. This allows to use oxygen together with Qt5 (see screenshot) and ensures that Oxygen will still be available for future releases of KDE.

Some text editor using oxygen-qt together with qt-5.0.2

There is some development foreseen for oxygen before it is released alongside with KDE Frameworks 5.0, in view of revisiting spacing and alignment between widgets, and making the whole style more DPI independent.

18 comments:

  1. "and making the whole style more DPI independent"

    Yay, looking forward to that :D

    ReplyDelete
  2. Thanks.

    It could use some work in Banshee. http://i.imgur.com/xgTsJGs.png

    ReplyDelete
  3. So as i understand with the transistion to qt5 oxygen project will not bring anything new and will look like kde4?

    ReplyDelete
  4. I had a problem with how list items are displayed by oxygen-gtk. After seeing this post, I filed a bug report. https://bugs.kde.org/show_bug.cgi?id=324337

    ReplyDelete
  5. @Sudhir
    unfortunately, we can't.
    Banshee uses its own set of custom widgets for which it is impossible for us to render our stuff properly.
    In fact, we did succeed at some point to make most of banshee widgets look reasonable, but then for the next release of banshee, it got all broken again.
    Reason behind is that banshee folks do some custom rendering without checking the margins etc. that the running widget style defines. So it will work for some styles, and not for others. Nothing we can do about it ...

    ReplyDelete
  6. Thats really good, the oxygen-gtk engine works great!
    Where can we get the oxygen-qt code??

    ReplyDelete
  7. So no refreshed Oxygen for next KDE installment?

    ReplyDelete
  8. @Dario
    on KDE's git repository
    (git clone git://anongit.kde.org/kde-workspace)

    But oxygen-qt does not exist. what exists is oxygen-kde. Oxygen is not standalone, and depends on some stuff in kdelibs.
    Also there is no standalone build either, you would need to build the whole kde-workspace.

    Oxygen-transparent on the other hand, although also depends on KDE, can be built standalone, but has not been ported (yet) to KF5 (will do when KF5 stabilizes)

    @Simas, @Yoda:
    refreshed, yes (see post about alignment, spacing and dpi independence)
    brand new design, no.
    Someone might stand up to design a brand new widget theme, and come with a nice name, but oxygen (tm) will remain largely unchanged.

    ReplyDelete
  9. Thank you very much, guys, for you work. Oxygen-transparent is fantastic! :)

    I have very important question - will oxygen-gtk have transparency mode, like oxygen-transparent? QtCurve is not good solution, because transparency doesn't work with all GTK-based apps (for example, firefox, libreoffice etc.).

    If it's possible to make transparency in oxygen-gtk like in oxygen-transparent, please, PLEASE, do it. I can donate for this development (and, I hope, another members of community too).

    ReplyDelete
  10. @Tapac,
    sadly, implementing transparency for oxygen-gtk is doable, but would work just as poorly as with QtCurve. For firefox, libreoffice, etc. there is simply no way (due to the way they use gtk, which is non standard).
    For 'native' gtk applications, (nautilus, gedit, etc.) this would not work either for many of them, because some parts do not support ARGB colormap and that would just make the application crash. So that you'd have to blacklist them, and the blacklist would be very long.
    So all in all, I don't think the 'limited' result is worth the effort, due to the state most gtk applications are in.
    Sorry ...
    (and I'm not even talking of gtk3 ...)

    ReplyDelete
  11. @Hugo
    It's really bad news, because Firefox looks ugly without transparent style :(. Maybe there are modifications of top browsers (like Chrome, Firefox, Opera) with Qt GUI? Reqonk works not so good and it's hasn't plugins engine.

    ReplyDelete
  12. @Hugo
    One more question. As I know, future release of Ubuntu Unity (Unity 8) will be based on Qt/QML. So, probably, many programs will be rewritten with this framework too. Will Qt/QML applications have transparent skin with oxygen-transparent theme?

    ReplyDelete
  13. @Tapac
    Last I remember, QML had no (or very little) support for Widget-based theming.
    (something along the line of what KDE-Plasma has right now).
    So that most likely, for those QML only applications, you might not even have oxygen (or oxygen-transparent) for these at all. Rather Unity own theme.
    For widget based applications, the situation should be the same as today though.
    (and also: things might change on the Qt side).
    Possibly someone will write an oxygen for QML style, but that will likely not be me ...

    ReplyDelete
  14. Regarding oxygen-kde,
    Are you planing to give visual-hint to default-buttons? I think this is an important matter from usability point of view.
    I suggest drawing default-button using a concave shading (as qtcurve-inverted does, for instance)

    ReplyDelete
  15. There is already a bug report about this on kde.
    This is a confirmed/acknowledged issue.
    Sadly, it has not been fixed yet, because we still lack a good design for it.
    It may get fixed at some point (has to, in fact), but no time estimate can be given.
    Sorry.

    ReplyDelete
    Replies
    1. Hugo, I've generated some rough mockups of choices that come up to my mind:

      http://pato101.blogspot.com.es/2013/11/suggestions-for-default-button-at.html

      Maybe you have considered all of these, but just in case...

      Delete
    2. @Pato
      Thanks, a lot !
      The mockups are really nice.
      I like the "tint background" option the best.
      Either blue, or modified standard color (lighter for instance) possibly with an option.
      Will need to experience with this, but this is really a nice idea.

      hugo

      Delete
    3. I've successfully implemented the tint effect using a QProxyStyle. Please see my page if you are interested.

      Delete

Followers