Bug 9609

well adwaita seems a little broken too as it some function are not working in mageia, (cf diskdrake, packaging issue) maybe you should report this bug at oxygen upstream ?

(In reply to Manuel Hiebel from comment #1)
> well adwaita seems a little broken too as it some function are not working
> in mageia, (cf diskdrake, packaging issue) maybe you should report this bug
> at oxygen upstream ?

I'm not aware of any Adwaita bugs you mention, what are their bug ids?
In any case I think this isn't necessarily a bug in Oxygen but a question of proper defaults for the desktop environment used.

https://bugs.mageia.org/show_bug.cgi?id=7379

Adwaita is also suffering this bug reported to rhbz:
https://bugzilla.redhat.com/show_bug.cgi?id=828005

CC: (none) => jani.valimaa

(In reply to Jani Välimaa from comment #4)
> Adwaita is also suffering this bug reported to rhbz:
> https://bugzilla.redhat.com/show_bug.cgi?id=828005

That's about scroll arrows, a different issue entirely.

I think a reversed button order in a default install should be a release blocker.

Adding Hugo in cc.

CC: (none) => hugo

title of the bug is 'ill-named'. The order of the buttons is DE independant. 
It is toolkit dependent though: by default, Gtk applications and Qt applications have different button orders (crap).  

So in oxygen-gtk, for consistency between Qt applications and Gtk applications, we 'reversed' the order with respect to Gtk's default. 
This won't change, sorry.

One could argue: you could add an option. 
But then, why add an option that 'enforces' inconsistencies between applications ? 

One could also argue: why did you change the Gtk's default, and not the Qt's default. Well: because Oxygen@Qt came first.

So I would say: bug report is invalid. (but that is not me to decide)

Hugo

Side note: QtCurve was doing just the same.

(In reply to Hugo Pereira Da Costa from comment #7)

> So in oxygen-gtk, for consistency between Qt applications and Gtk
> applications, we 'reversed' the order with respect to Gtk's default. 
> This won't change, sorry.

Like I said already in my bug report, doing this for visual consistency _under KDE_ is fine with me. Great, even! Making this theme the default under Gnome and maintaining the incorrect button order, definitely is NOT.
 
> So I would say: bug report is invalid. (but that is not me to decide)

As long as the default button order under Gnome in Mageia is wrong, that will be a bad bug. If it is solved by changing the default theme under Gnome, or by changing oxygen-gtk's behavior in a Gnome session, is equal to me. But saying this bug is invalid is just turning a blind eye to the fact that the Gnome user experience is severely impaired in Mageia.

mmm. But then, what about Qt apps running in gnome. (and there are some, obviously). Is it ok with you that they are inconsistent with Gtk apps ?
Again: a theme should not have to know (and has no easy way to know) about the Desktop Environment the application it comes with is running on.

(In reply to Hugo Pereira Da Costa from comment #10)
> mmm. But then, what about Qt apps running in gnome. (and there are some,
> obviously). Is it ok with you that they are inconsistent with Gtk apps ?
> Again: a theme should not have to know (and has no easy way to know) about
> the Desktop Environment the application it comes with is running on.

Qt apps under Gnome would then have inconsistent button order, that is certainly true. For me that doesn't matter, and as a whole, I think it is less important than the other way around because Gnome isn't the default desktop in Mageia anyway. But it is something to be noted.

If a theme cannot easily figure out what desktop environment is being used, maybe this is something to configure at login time? How about: When a user chooses a certain session, a script would be run that copies the right settings.ini file to his ~/.config/gtk-3.0 ? (Assuming the button order can be specified there)

Oxygen-gtk is not used anymore, so bug can be closed.

Status: NEW => RESOLVED
Resolution: (none) => OLD