Re: Bug#1080151: meta-gnome3: make a decision between eog and loupe for new trixie installations

Phil Wyett <[email protected]> Wed, 25 Sep 2024 16:23:02 +0100
Newsgroups	gmane.linux.debian.devel.gtk-gnome
Message-ID	<[email protected]>
On Wed, 2024-09-25 at 10:57 -0400, Jeremy Bícha wrote:
> I believe we should swap eog to loupe in gnome-core now.
> 
> I tested Loupe 47 (currently in Unstable) and it felt approximately
> feature equivalent with eog.
> 
> - Screen reader support appeared to work as expected
> - Image format support is different than how most GNOME-ish worked
> before. Instead of gdk-pixbuf loaders, it uses glycin loaders.
> Here is the list of formats that is supposed to work with Loupe in its
> vendored state
> https://gitlab.gnome.org/sophie-h/glycin#supported-image-formats
> We ship it unvendored in Debian. Some differences: we haven't yet
> enabled JPEG XL but I think that will be done in time for Trixie.
> We don't support OpenEXR but that feels like a fairly obscure format
> to me. Every other format in that list should work for display (the
> other checkmarks are for specific features for those formats.
> 
> On Sat, Aug 31, 2024 at 12:51 AM Phil Wyett <[email protected]> wrote:
> > My only concern with replacing eog with loupe, is that you cannot tell what
> > zoom level you are at in loupe. This can get rather confusing unlike with eog
> > where it is visible in the UI and easily changed.
> 
> This appears to be fixed in main for Loupe 48. GNOME 48 will be too
> late for inclusion in Debian 13 given expected freeze dates.
> https://blogs.gnome.org/sophieh/2024/09/20/image-viewing-and-editing-in-gnome-47-and-beyond/
> 
> I am looking forward to Loupe 48 since that release might be the first
> to support cropping which eog never supported.
> 
> I think in general gnome-core should reflect what GNOME determines to
> be in GNOME Core unless we have a good reason to diverge and I don't
> think we do here now.
> 
> I intend to not provide an alternate dependency for eog. An alternate
> dependency would mean that upgraders would not get our new default.
> Until we have some kind of upgrade script, alternate dependencies for
> changed defaults seems unworkable.
> 
> Thank you,
> Jeremy Bícha

Hi Jeremy and all,

Looking at loupe 47, I agree that feature parity is there where argument
would be silly at this point. I also agree regarding swapping eog for loupe.
This will bring as you say Jeremy the new features loupe will bring in future
versions and having more users now will help to see and fix any issues that
arise and provide a great core application for future distro releases.

I haven't use OpenEXR format since back in the day when I was involved with
the Crystal Space 2D/3D SDK. Not a format your average user would likely be
wanting to view.

I am all for the change at this time.

Regards

Phil

-- 

"I play the game for the game’s own sake"

Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans

--

Buy Me A Coffee: https://buymeacoffee.com/kathenasorg

Internet Relay Chat (IRC): kathenas

Matrix: #kathenas:matrix.org

Website: https://kathenas.org

Instagram: https://instagram.com/kathenasorg/

Threads: https://www.threads.net/@kathenasorg

--
signature.asc (application/pgp-signature, 870 B)