Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 382967 - Successor of 377971: Gtk2 support needed in gnome-mplayer >=1.04 because mplayer2 not supported in <1.0.4
Summary: Successor of 377971: Gtk2 support needed in gnome-mplayer >=1.04 because mpla...
Status: RESOLVED DUPLICATE of bug 374057
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Linux bug wranglers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-09-14 15:26 UTC by Klaus Kusche
Modified: 2011-09-16 09:21 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Klaus Kusche 2011-09-14 15:26:59 UTC
See 377971:
As mplayer2 support will not be enabled on gnome-mplayer 1.0.3,
please support gtk2 in gnome-mplayer 1.0.4
to have a gtk2 version of gnome-mplayer which supports mplayer2.

This combination is supported upstream, so it should be no problem.

This is on a non-gnome system (XFCE), 
and XFCE will not support gtk3 any time soon,
nor will any other piece of software used here.
Hence, gtk3 just for gnome-mplayer is no option.

Gnome-mplayer is plain gtk+ software (see their homepage!),
neither related to nor bound to Gnome or the Gnome project in any way,
so there is no reason to force it to gtk3
just because Gnome moved to gtk3:
gnome-mplayer is expected to work with any gtk+ environment: xfce, lxde, ...

If the Gentoo Gnome community refuses to support gnome-mplayer on gtk2,
please move it to a different maintainer.
Comment 1 Samuli Suominen (RETIRED) gentoo-dev 2011-09-14 15:30:56 UTC

*** This bug has been marked as a duplicate of bug 374057 ***
Comment 2 Samuli Suominen (RETIRED) gentoo-dev 2011-09-14 15:32:21 UTC
As it happens, gnome-mplayer is maintained by member of the Gentoo Xfce Team (that would be me) and I have no issues whatesoever in running 1.0.4 with gtk+-3.0 in Xfce 4.8
Comment 3 Klaus Kusche 2011-09-14 15:58:19 UTC
I have issues here, many of them, gnome-mplayer 1.0.4 is unuseable for me.
(I didn't try lately, but I tried when 1.0.4 was released some months ago):

* Gnome mplayer 1.0.4 did not obey my global font settings,
and I found no way to change that
Any text in gnome mplayer was unreadably tiny
(I have a 17" 1920*1200 notebook and hence very large system-wide custom 
font setting because of the high resolution - default fonts are way too small).

* Gtk3 applications do not obey my theme settings and theme engine.
At least, gnome mplayer 1.0.4 didn't:
It came up with completely different colors,
using a completely different theme engine, ...
It looked completely alien and ugly.

* Gnome mplayer did not find some icons 
and partially used icons from the wrong ico theme
(I have a custom icon theme which perfectly supported all gtk2 applications
up to now).
Comment 4 Rafał Mużyło 2011-09-14 16:19:10 UTC
As your problems seem to be only related to theming the part of the answer might lie here: http://developer.gnome.org/gtk3/stable/ch25s02.html#gtk-migrating-GtkStyleContext - theming in gtk2 and gtk3 is separate, so a gtk3 app likely doesn't follow the theme, cause no theme is set up.
Comment 5 Klaus Kusche 2011-09-14 17:09:11 UTC
(In reply to comment #4)
> As your problems seem to be only related to theming the part of the answer
> might lie here:
> http://developer.gnome.org/gtk3/stable/ch25s02.html#gtk-migrating-GtkStyleContext
> - theming in gtk2 and gtk3 is separate, so a gtk3 app likely doesn't follow the
> theme, cause no theme is set up.

As far as I know, only item 2 in my comment #3 is related to the theme engine
and the theme settings. 

Icons themes, icon naming rules and XFCE's systemwide font settings are not
part of the theme mechanism I think, so your link does not apply?
(and I've no solution for them yet)

For the theme settings and theme engines, it is definitely true that
gtk3 apps do not obey my gtk2 theme settings and theme engine.
However, your link is relevant only for programmers who want to port
their applications to gtk3.

It does not tell me (as a plain user!) what to do to make gtk3 apps obey
my gtk2 theme settings *without* touching any code.

Besides, many theme engines have not been ported to gtk3 anyway, (the one I use
definitely didn't support gtk3 at all when I tested Gnome mplayer last time), 
so even if the gtk3 application applied the gtk2 theme settings,
it would fail because the code of the theme engine is missing in gtk3.

Hence, as long as
* the theme engines and font themes have not been ported to gtk3,
* and
  - either gtk3 sync's automatically to existing gtk2 theme, font and icon
  settings (which is not gonna happen),
  - or XFCE's "Appearance" system settings and the setting tool of the theme
  set both the gtk2 and the gtk3 settings (which is also not planned any time 
  soon)
gtk3 apps look ugly and alien at best and are unuseable at worst
in a heavily themed gtk2 environment.

(and gnome mplayer is the only pure gtk3 app which causes all the trouble)
Comment 6 Nikos Chantziaras 2011-09-14 18:08:38 UTC
Devs don't want to hear anything about it (see the other bug), so I now maintain my own ebuild of gnome-mplayer, which supports both Gtk2 and Gtk3.  You can find it here:

http://foss.aegean.gr/~realnc/mplayer/gnome-mplayer-1.0.4.ebuild

It has a "gtk3" USE flag.  If it's not set (by default it isn't), it will use Gtk2.
Comment 7 Klaus Kusche 2011-09-14 18:37:59 UTC
It's not a question of "wanting to hear about".

Icon themes are just "nice to have" as far as I know,
but obeying theme settings and fonts size settings is not a "nice to have",
but a strict requirement by accessibility guidelines and regulations:

Applications must obey systemwide font size settings,
and they must at least support systemwide "inverse" and "high contrast" settings,
otherwise they violate basic accessibility requirements.

If someone sets his desktop theme to "high contrast" and twice the font size,
any application not switching to high contrast and big fonts
is buggy and needs to be fixed.

And that's exactly the situation we have for gtk3 apps in gtk2 environments.
Of course there are cases which are hard to fix, but this one is trivial.
Comment 8 Rafał Mużyło 2011-09-14 19:27:04 UTC
As the page says, themes differ significantly between gtk2 and gtk3, so there's no "obeying the old theme". 

As for the other part, i.e.:
gtk-font-name="Sans 10"
gtk-fallback-icon-theme = "gnome" (though you probably want "gtk-icon-theme-name")

See also http://developer.gnome.org/gtk3/stable/GtkSettings.html.

So, you were saying...
Comment 9 Klaus Kusche 2011-09-14 19:57:17 UTC
(In reply to comment #8)
> As the page says, themes differ significantly between gtk2 and gtk3, so there's
> no "obeying the old theme". 
> 
> As for the other part, i.e.:
> gtk-font-name="Sans 10"
> gtk-fallback-icon-theme = "gnome" (though you probably want
> "gtk-icon-theme-name")

It's not my job (as a user) to adapt code or to manually copy or edit config files and settings. 

I've a perfectly working desktop environment which offers a system settings
dialog for appearance. 
All applications obey the settings I make there: Firefox & Thunderbird, Libre Office, Evince, and many others.
Except Gentoo gnome mplayer 1.0.4, which ignores them, has unreadable fonts, 
and looks ugly.
Gentoo gnome mplayer up to 1.0.3 was fine.
Upsteam gnome mplayer 1.0.4 still is fine.

Now, from a user's point of view (and the comments in this and bug 374057
show that I'm not the only one) and the facts above it is obviously
Gentoo gnome mplayer 1.0.4 which is broken.

Except for pure Gnome 3 environments, the time of gtk3 has not yet come
and will not come for at least a year (until Mozilla, XFCE, LibreOffice etc.
switch). As the gtk3 team decided to be settings incompatible with gtk2,
running both in parallel causes trouble and suboptimal user experience.

Hence, for good reasons, the developers of gnome mplayer (and some other 
applications) have decided that it is necessary to support both gtk2 and gtk3.
And the same good reasons apply to Gentoo and should lead to the same decision:
As gtk decided to keep them separated, we should not try to sync gtk2 and gtk3 
settings, but to provide applications for both worlds.
Comment 10 Rafał Mużyło 2011-09-14 20:55:55 UTC
:roll: technically, evince already is gtk3.
Also, you'd likely get similar results if you ran a qt4 app without tweaking the qt settings.

As for the "job" remark (and similar) - bitching won't get you anywhere.

Once again, an app can't follow settings that aren't there - "no gtk3 theme" == "defaults are used".
Comment 11 Klaus Kusche 2011-09-15 05:34:55 UTC
(In reply to comment #10)
> :roll: technically, evince already is gtk3.

But Gentoo still supports and actively maintains the latest evince2* ebuild
(like fixing dependencies),
whereas it does no longer support the latest gnome mplayer gtk2 ebuild.

> Also, you'd likely get similar results if you ran a qt4 app without tweaking
> the qt settings.

That's why there are well-maintained theme engines like qtcurve and/or 
code in qt which provide that functionality: Gtk apps will obey the kde settings
and vice versa if one installs the correct packages with the correct use flags,
without manual tweaking or copying and editing settings.

> Once again, an app can't follow settings that aren't there - "no gtk3 theme" 
> == "defaults are used".

That's what we are all saying all the time:
* Gnome mplayer is intended for and used in environments which do not support
  gtk3 settings yet (like xfce or lxde), only gtk2 settings.
* Hence, it must use gtk2 for satisfying user experience
  (which is trivial, it *does* support gtk2 upstream, only the ebuild does not).

If the maintainers don't want to support gtk2, it's their duty to provide
satisfying user experience in gtk2 environments in some other ways,
but that would be the much more complicated alternative and doesn't make sense.
Comment 12 Rafał Mużyło 2011-09-15 12:55:36 UTC
"it's their job", "it's their duty"...
Are you sending any paychecks ?

Seriously, though. If the app builds and works correctly, that's just about all a package maintainer should be asked for. Appearance is at most secondary, unless it's an app managing appearance.

Once again, if it's an gtk3 app, it should follow the set up gtk3 theme, if no gtk3 theme is set up, it should use its defaults - as it most likely does.

So it works as expected.

Your definition of "latest" is also amusing - gnome 3.2 is about to release, with new version of evince - that gtk2 version (about a year old now) is kept cause getting gtk3 into the tree is/was not a trivial task, but it's already here.


The most amusing part of this conversation is that I still don't have gtk3 here, but likely it will arrive once gtk 3.2 and evince 3.2 get released - evince is one of the very few gnome apps I use (I'll probably get ghex for gtk3 then - for the moment I'm using a cherry-picked tarball of git tree, with gtk3 patches dropped).

Also, I do agree with you that quality of the docs for gtk themes (or rather lack of any decent) is a bit aggravating.
Comment 13 Klaus Kusche 2011-09-15 13:53:16 UTC
(In reply to comment #12)
> "it's their job", "it's their duty"...
> Are you sending any paychecks ?

If someone accepts maintainance for some package,
he should be willing to support all major features of the package
(which is gtk2 *and* gtk3 in case of gnome mplayer),
especially if they are widely asked for by the community.

> Seriously, though. If the app builds and works correctly, that's just about all
> a package maintainer should be asked for. Appearance is at most secondary,
> unless it's an app managing appearance.

It doesn't work correctly. Fonts are to small to be read, and that can't 
be fixed from a plain user's point of view (without editing config files).

Also, as I noted in comment #7, following theme and font settings 
(as set in the appearance dialogs of the desktop environment) is not
a "nice to have", but a requirement to conform to accessibility regulations.
Gentoo gnome mplayer would not be allowed in public institutions here,
except when used within Gnome3 environments.

> Once again, if it's an gtk3 app, it should follow the set up gtk3 theme, if no
> gtk3 theme is set up, it should use its defaults - as it most likely does.

It isn't a gtk3 app. As defined upstream, it is a gtk2 *or* gtk3 app:
They support and maintain both gtk bindings, controlled by a configure option.
Upstream gave the user the choice to use what fits his environment better,
the gentoo maintainer took this choice away from gentoo users.
And gentoo is all about choices - otherwise, I could use suse or redhat.

> So it works as expected.

It doesn't: I expect it to run as a native gtk2 app, as provided by upstream.

> Your definition of "latest" is also amusing - gnome 3.2 is about to release,
> with new version of evince - that gtk2 version (about a year old now) is kept
> cause getting gtk3 into the tree is/was not a trivial task, but it's already
> here.

If you have read their homepage and their requirements, in spite of its name
gnome mplayer is not a gnome project. Also, evince can be used (and is widely
used) outside of gnome. Both do not depend on any gnome library
(or only optionally depend on gnome libraries).

gtk version decisions made by gnome do not automatically apply to gnome mplayer.

> The most amusing part of this conversation is that I still don't have gtk3
> here, but likely it will arrive once gtk 3.2 and evince 3.2 get released -
> evince is one of the very few gnome apps I use (I'll probably get ghex for gtk3
> then - for the moment I'm using a cherry-picked tarball of git tree, with gtk3
> patches dropped).

I tried to use both gtk2/3 in parallel, and the results were very unsatisfying.
As long as I can live with just one version, I will avoid the trouble
to configure both nicely, the time to emerge both and keep them up to date,
and the space which is wasted having both on disk and in memory.

For me, it's just evince (I'm happy with 2.*, no bugs here) and gnome mplayer.
Everything else (XFCE, Firefox & Thunderbird, LibreOffice, ...) is gtk2
and will be so for some time.

Porting to gtk3 needs much work for little benefits, and the very "mixed"
acceptance of gnome3 (horrible) by users isn't speeding gtk3 porting, either. 
I don't see anyone outside gnome3 rushing to gtk3...
Comment 14 Rafał Mużyło 2011-09-15 15:29:41 UTC
Let me spell it out (again) for you - the app follows the theme, as no (gtk3) theme is set up, it follows the default one - so no bug there, works *exactly* as it should (do  I need to remind you how ugly gtk2 is, if no theme is set up ?).
Themes are toolkit specific and gtk2!=gtk3.

The page I've mentioned in comment 8 at the very top says where the non-pure theme settings (as i.e. icon theme or font) should go.

Also, :roll: I've never said gnome-mplayer is a Gnome project. Neither I use Gnome - again, as I already said, evince is just one of a very short list of gnome apps I use.

Also, the examples you use are odd - as for Xfce, just look how long it took KDE to fully embrace qt4, mozilla apps - honestly, IIRC, firefox still carries around gnome-vfs module (besides the recently added gvfs one), long after Gnome declared gnome-vfs dead.
As for evince, "no bugs"...that you know of - that's not quite the same thing.
Comment 15 Klaus Kusche 2011-09-15 17:59:23 UTC
(In reply to comment #14)
> Let me spell it out (again) for you - the app follows the theme, as no (gtk3)
> theme is set up, it follows the default one - so no bug there, works *exactly*
> as it should (do  I need to remind you how ugly gtk2 is, if no theme is set up
> ?).
> Themes are toolkit specific and gtk2!=gtk3.

You misunderstand what I want / said.
The behaviour of the gtk3 gnome mplayer is perfectly fine, it behaves as it
is expected to behave, I'm not criticizing that, I don't want any changes
in the gtk3 gnome mplayer binary or installation.

I and all the others in bug #374057 are criticizing that the gentoo ebuild is
unconditionally building a gtk3 gnome mplayer, even in pure gtk2 environments
with the -gtk3 USE flag set (or can't be emerged at all if gtk3 is masked).

Please accept that in gtk2 environments no gtk3 settings are present
(and it is not the user's duty to set them manually). Hence gtk3 applications
result in suboptimal to inacceptable user experience, and native gtk2 applications should be provided if possible, because this solves all
these user interface issues.

And this is easily possible for gnome mplayer, because the upstream build
supports both building a native gtk2 and a native gtk3 gnome mplayer,
just by changing a single option of the configure script.

However, the ebuild has hardwired that option to gtk3 instead of setting it conditionally based on the gtk3 USE flag (like a dozen other ebuilds do), 
and *that* should be changed.
Comment 16 Rafał Mużyło 2011-09-15 19:50:03 UTC
In such case, bug 374057 comment 20 is the complete summary of the problem - rest of it is just bitching.

Again, as for xfce, it's quite a bit alike to KDE and qt4.
xfce 4.10 will still be gtk2, cause at the time it was decided, gtk3 was still not released - xfce has a longer release schedule than Gnome http://wiki.xfce.org/releng/4.10/roadmap.
But gtk+ 3.2 should be just around the corner and after xfce 4.10 release (planned in January), things might change for the next release.

I'd say it's a bit of chicken-egg - if there's no push to adopt gtk3, it will slow down things, if there is, things will eventually get moving.


Though I don't use xfce either, so it's not like I really care.
Comment 17 Klaus Kusche 2011-09-16 09:21:30 UTC
(In reply to comment #16)
> In such case, bug 374057 comment 20 is the complete summary of the problem -
> rest of it is just bitching.

Comment #20 is fundamentally wrong in 3 ways:

1.) Gentoo is not the internal toy of developers only.
It also is (or pretends to be) an end-user distribution.

For the end user, "Choice" in Gentoo is about setting USE flags, 
choosing a kernel, and so on.

Maintainers must *not* assume that the average Gentoo user is able (or willing)
to understand and/or modify ebuilds or to apply patches to them
(just like the maintainer may not assume that the user is able or willing
to manually create or modify config files): That's not among the abilities
an end user is expected to have, and it is also not among the duties of the
end user to express his choices by editing ebuilds.

It is the duty of the end user to set his USE flags correctly
(and gtk3 is among the USE flags gentoo provides),
and it is the duty of the ebuild to adapt accordingly.

2.) In the meantime we know that the transition to gtk3 (for non-gnome users)
will *not* be quick (as you described for xfce), it is likely to take >>1 year.

Hence, the need for intermediate solutions has considerably increased
since comment #20 was written, the assumption that the world will be gtk3 only
anyway within months was just plain wrong.

3.) It is correct that the developer decides what his software supports or
requires (and what he is not going to support). But the developer is upstream, 
the person who wrote the software, not the one who packaged the ebuild.

And in the case of gnome mplayer, the developer decided that it is necessary
to provide both gtk2 and gtk3 versions.

It is the duty of the package maintainer to make the features the developer
implemented available to the users of the distribution, and it is not
his job to question or overrule the decisions made by the original developer.

What would you do (as an end user) if gentoo ebuilds would randomly
drop features or choices provided upstream by LibreOffice, Samba or whatever?
You would open a bug, and that's what users did here.

> I'd say it's a bit of chicken-egg - if there's no push to adopt gtk3, it will
> slow down things, if there is, things will eventually get moving.

For the average (non-gnome) developer and for the end user,
there is no real advantage in moving to gtk3
(gnome mplayer won't play movies any better, will it?), 
that's why there is little push.

And the manpower of many projects (like xfce) is limited:
Even if there were more push, it wouldn't speed things:
Developers prefer to spend their valuable time on real improvements.