mate-desktop / eom Goto Github PK

If you open a SVG image and zoom in, the image appears blurry, like zooming into a bitmap image. Vector images should not look pixelated in any resolution.

Hi,

When using eom to visualise the image output of a program that I re-run quite often,
I would like eom to automatically refresh that image when it has changed (even when not given focus)
rather than proposing me to click or hit alt-R every time.

If other people prefer the current behaviour, adding a switch button in the preferences would be good enough. Although I think auto-refresh is now the current default behavior in eog.

• View -> Side Pane menu item is always greyed out, its shortcut (Ctrl-F9) is disabled;
• if I enable sidebar key in org.mate.eom.ui schema, eom disables it on the next run;
• there are functions to add/remove sidebar "pages" (wtf is that?) in eom-sidebar.c - but they're never ever ever called anywhere.

Tested in eom 1.8 and 1.10.

Eye of Gnome has that functionality enabled but there are no relevant commits that we could cherry-pick.

http://anonscm.debian.org/gitweb/?p=pkg-mate/eom.git;a=blob;f=debian/patches/1001_change-application-name-to-eom.patch

Watch out for the change in configure.ac, it will break your tarball generation for the 1.6 release series (mate-image-viewer.tar.gz -> eom.tar.gz). If I am not mistaken...

Hallo

I recently switched from mint 12 to mint 15. I always used eog, now I want to use eom. I was never very happy that I had to go to the slide show mode for shuffle. But without that feature eom is a lot less attractive for me. I would be very happy about a plugin for shuffle.

FYI, I am using this repository: http://wiki.mate-desktop.org/archlinux_custom_repo#gtk3

claire ~ % pacman -Q eom                                           :(
eom 1.9.0.20140502.37bba55-1
claire ~ % eom

(eom:25577): Gtk-ERROR **: GTK+ 2.x symbols detected. Using GTK+ 2.x and GTK+ 3 in the same process is not supported
[1]    25577 trace trap (core dumped)  eom

claire ~ % journalctl -b | grep eom
May 03 20:39:04 claire kernel: traps: eom[24665] trap int3 ip:7f193d4f3993 sp:7fff35ab3bc0 error:0
May 03 20:39:04 claire systemd-coredump[24670]: Process 24665 (eom) dumped core.
May 03 20:39:17 claire kernel: traps: eom[25020] trap int3 ip:7f1798866993 sp:7fff9a08c320 error:0
May 03 20:39:17 claire systemd-coredump[25021]: Process 25020 (eom) dumped core.
May 03 20:39:25 claire kernel: traps: eom[25247] trap int3 ip:7f38a5aa0993 sp:7fffd5b75e90 error:0
May 03 20:39:25 claire systemd-coredump[25248]: Process 25247 (eom) dumped core.
May 03 20:39:39 claire kernel: traps: eom[25577] trap int3 ip:7f1d91fcc993 sp:7ffff86ce650 error:0
May 03 20:39:39 claire systemd-coredump[25584]: Process 25577 (eom) dumped core.

Icons are install in /usr/share/mate-image-viewer/icons/ by mate-image-wiewer (version 1.6.1 ) instead of /usr/share/icons/ . Please fix it.

• compiling with gtk2 is successful, but the @GTK_API_VERSION@ not replaced with 2.0 in eom.pc.
• compiling with gtk3 failed:

eom-scroll-view.c: In function 'paint_rectangle':
eom-scroll-view.c:879:3: warning: implicit declaration of function 'gdk_draw_rgb_image_dithalign'
eom-scroll-view.c:880:145: error: 'GtkStyle' has no member named 'black_gc'
eom-scroll-view.c:883:12: error: 'GDK_RGB_DITHER_MAX' undeclared (first use in this function)
eom-scroll-view.c:883:12: note: each undeclared identifier is reported only once for each function it appears in
eom-scroll-view.c:917:47: error: 'GtkStyle' has no member named 'black_gc'

I tried to execute Eye of MATE, but nothing happened. Here's the output from the Terminal what it caused:

[jigs@dell-latitude-d630 Desktop]$ eom

(eom:2847): Gtk-ERROR **: GTK+ 2.x symbols detected. Using GTK+ 2.x and GTK+ 3 in the same process is not supported
Trace/breakpoint trap (core dumped)

Eom's gsettings keys are wrong translated with 1.10.

Building eom from git master from 2014-06-29 fails. GTK+ version is 3.10

eom-scroll-view.c:884:12: warning: 'gtk_widget_get_style' is deprecated (declared at /usr/include/gtk-3.0/gtk/deprecated/gtkstyle.h:672): Use 'gtk_widget_get_style_context' instead [-Wdeprecated-declarations]
            gtk_widget_get_style (GTK_WIDGET (priv->display))->black_gc,
            ^
eom-scroll-view.c:884:61: error: 'GtkStyle' has no member named 'black_gc'
            gtk_widget_get_style (GTK_WIDGET (priv->display))->black_gc,
                                                             ^
eom-scroll-view.c:887:12: error: 'GDK_RGB_DITHER_MAX' undeclared (first use in this function)
            GDK_RGB_DITHER_MAX,
            ^
eom-scroll-view.c:887:12: note: each undeclared identifier is reported only once for each function it appears in
eom-scroll-view.c:921:11: warning: 'gtk_widget_get_style' is deprecated (declared at /usr/include/gtk-3.0/gtk/deprecated/gtkstyle.h:672): Use 'gtk_widget_get_style_context' instead [-Wdeprecated-declarations]
           gtk_widget_get_style (priv->display)->black_gc,
           ^
eom-scroll-view.c:921:47: error: 'GtkStyle' has no member named 'black_gc'
           gtk_widget_get_style (priv->display)->black_gc,
                                               ^
<snip>
make[3]: *** [libeom_la-eom-scroll-view.lo] Fehler 1
make[3]: Leaving directory `/media/nfs/Programme/Linux/Mate-Desktop/git-version/github-matedesktop/eom-dist/src'
make[2]: *** [all] Fehler 2
make[2]: Leaving directory `/media/nfs/Programme/Linux/Mate-Desktop/git-version/github-matedesktop/eom-dist/src'
make[1]: *** [all-recursive] Fehler 1

full build log:
https://dl.dropboxusercontent.com/u/49862637/Mate-desktop/Bugs/eom-1.9

Hello,

I would like to report a bug concerning EOM version 1.8.0

When trying to open a large PNG file 27.000px x 27.000px) EOM crashes.

Environment:
Debian 8.1 x64
EOM 1.8.0

I've been able to catch a backtrace using gdb:

Program received signal SIGSEGV, Segmentation fault.                                                                                                                                                               
[Switching to Thread 0x7fd046086700 (LWP 57178)]                                                                                                                                                       >0x00007fd04fc042f0 in mate_desktop_thumbnail_scale_down_pixbuf () from /usr/lib/x86_64-linux-gnu/libmate-desktop-2.so.17                                                                                           
(gdb) bt
#0  0x00007fd04fc042f0 in mate_desktop_thumbnail_scale_down_pixbuf () from /usr/lib/x86_64-linux-gnu/libmate-desktop-2.so.17
#1  0x0000000000440375 in eom_thumbnail_load ()
#2  0x0000000000441481 in ?? ()
#3  0x00000000004405b1 in ?? ()
#4  0x00007fd04ca51935 in g_thread_proxy (data=0xbf2850) at /tmp/buildd/glib2.0-2.42.1/./glib/gthread.c:764
#5  0x00007fd04b69a0a4 in start_thread (arg=0x7fd046086700) at pthread_create.c:309
#6  0x00007fd04b3cf04d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Please let me know if you need the test file.

Best regards

Orginal report at fedora bugzilla.
https://bugzilla.redhat.com/show_bug.cgi?id=927150

Description of problem:
First of all, ignore the core dump file because it is made artificially by sending kill -SIGSEGV to eom.
I'm sorry, but I did this to launch bug report master with the right assign and product fields.

The problem is this - eom (mate-image-viewer) not open the large svg file, whereas gwenview, for example - opens.

Version-Release number of selected component:
mate-image-viewer-1.5.0-2.fc18

Additional info:
backtrace_rating: 4
cmdline: eom handlers.svg
core_backtrace:
executable: /usr/bin/eom
kernel: 3.8.4-202.fc18.x86_64
uid: 1000
var_log_messages: Mar 25 12:26:56 localhost abrt[3696]: Saved core dump of pid 3586 (/usr/bin/eom) to /var/spool/abrt/ccpp-2013-03-25-12:26:55-3586 (63848448 bytes)

Confirmed with current mate-image-viewer-1.6.0-1.fc18.x86_64

The Free Software Foundation address in this file seems to be outdated or
misspelled. Ask upstream to update the address, or if this is a license file,
possibly the entire file with a new copy available from the FSF.

File: COPYING

If i zoom 100% on an image the scrollbars are shown inside the image area hiding the extreme borders, they should be shown outside the image area.

For example i've made an image that has three A letters near the upper right corner. If i zoom 100% (pressing 1) and i scroll in order to see the upper right corner i don't see them fully, but only the left part of the letters.

I attach the file.

Thank you in advance.

I am using Linux Mint 17.2 64 bit mate version and EOM seems to have a problem with vertical scroll. The issue can be repeated by doing this...

(1) Open any image with the height greater than the width.
(2) Move the sides of the window out so the window width is more than the height or maximize the window.
(3) Zoom in till a vertical scroll bar appears, it will be inoperable and the slider button will be small at the top.
(4) Keep zooming in till a horizontal scroll bar appears, at that moment the vertical scroll slider will change shape and the vertical scroll bar will commence to operate almost normally - it has an incorrect vertical size and will let you scroll down past the bottom of the image, the space is filled with repeats of the last row of pixels from the image..
(5) Zoom back out till the horizontal scroll disappears and the vertical scroll will keep working.
(6) Use the 'Next ' or 'Previous' buttons to select another image and the vertical scroll will keep working.
(7) You need to close and re-open the program to repeat the bug.

regards CB

I upgraded from Linux Mint x64 17.1 -> 17.2 (eom versions 1.8.1-0+rebecca -> 1.10.0-1+rafaela) and the new EOM fails to render a certain PNG image that was no problem before. The image appears as transparent. (see Screen1) After this failure, all other bitmaps show up the same way until eom is restarted. Also, menu items disappear after mouseover and toolbar buttons are left lighter after mouseover (see Screen2). When rescaling the image in GIMP, I found out that 9743x13775 resolution works fine, but 9744x13776 and larger causes the problem. When exporting to JPG, I get grey area instead of transparency.

For testing purposes, I am enclosing the image here: https://copy.com/cDBURchdea1yWvNo

Icons are installed in
/usr/share/eom/icons/hicolor
AND in /usr/share/icons/hicolor

The pixmap is installed in /usr/share/eom/pixmaps

/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/../../../../lib64/libcairo.so: undefined reference to symbol 'XUnlockDisplay'
/usr/lib64/libX11.so.6: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
Makefile:751: recipe for target 'eom' failed
make[3]: *** [eom] Error 1
make[3]: Leaving directory '/var/calculate/tmp/portage/media-gfx/eom-1.10.0/work/eom-1.10.0/src'
Makefile:652: recipe for target 'all' failed
make[2]: *** [all] Error 2
make[2]: Leaving directory '/var/calculate/tmp/portage/media-gfx/eom-1.10.0/work/eom-1.10.0/src'
Makefile:534: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/var/calculate/tmp/portage/media-gfx/eom-1.10.0/work/eom-1.10.0'
Makefile:465: recipe for target 'all' failed
make: *** [all] Error 2

I: eom: hyphen-used-as-minus-sign usr/share/man/man1/eom.1.gz:46
N:
N: This manual page seems to contain a hyphen where a minus sign was
N: intended. By default, "-" chars are interpreted as hyphens (U+2010) by
N: groff, not as minus signs (U+002D). Since options to programs use minus
N: signs (U+002D), this means for example in UTF-8 locales that you cannot
N: cut and paste options, nor search for them easily. The Debian groff
N: package currently forces "-" to be interpreted as a minus sign due to
N: the number of manual pages with this problem, but this is a
N: Debian-specific modification and hopefully eventually can be removed.
N:
N: "-" must be escaped ("-") to be interpreted as minus. If you really
N: intend a hyphen (normally you don't), write it as "(hy" to emphasise
N: that fact. See groff(7) and especially groff_char(7) for details, and
N: also the thread starting with
N: http://lists.debian.org/debian-devel/2003/debian-devel-200303/msg01481.html
N:
N: If you use some tool that converts your documentation to groff format,
N: this tag may indicate a bug in the tool. Some tools convert dashes of
N: any kind to hyphens. The safe way of converting dashes is to convert
N: them to "-".
N:
N: Because this error can occur very often, Lintian shows only the first 10
N: occurrences for each man page and give the number of suppressed
N: occurrences. If you want to see all warnings, run Lintian with the
N: -d/--debug option.
N:
N: Refer to /usr/share/doc/groff-base/README.Debian and the groff_char(7)
N: manual page for details.
N:
N: Severity: wishlist, Certainty: possible
N:
N: Check: manpages, Type: binary
N:
I: eom: hyphen-used-as-minus-sign usr/share/man/man1/eom.1.gz:51

I cannot configure eom with libexif in a non-builtin location (a prefix other than /usr), even though it is correctly found by pkg-config.

From eom's configure.ac:

AC_ARG_WITH([libexif], AC_HELP_STRING([--without-libexif], [disable EXIF support]))
have_exif=no
if test x$with_libexif != xno; then
    PKG_CHECK_MODULES(EXIF, libexif >= $LIBEXIF_REQUIRED, have_exif=yes, have_exif=no)
    if test "x$have_exif" = "xyes"; then
        AC_CHECK_HEADER([libexif/exif-data.h],[],[have_exif=no])
    fi
fi
if test "x$have_exif" = "xyes"; then
  AC_DEFINE(HAVE_EXIF, 1, [EXIF Support.])
  EOM_MODULES="$EOM_MODULES libexif >= $LIBEXIF_REQUIRED"
fi

The problem is with the AC_CHECK_HEADER; this will try to find the exif-data.h header, but it does not employ the necessary "cflags" returned by pkg-config. So in my case, it will fail to find the header, even though it is available. If I disable the AC_CHECK_HEADER, I can correctly compile eom.

I want to launch eom from the command line, and make it fullscreen on my second monitor. Which of the two do I use?

1. eom -f ~/Pictures/YouWill/quote-0019.jpg --display=X
2. eom -f ~/Pictures/YouWill/quote-0019.jpg --screen=X

Running --help-all doesn't elaborate on which argument I should use, nor does it elaborate on what the value of either argument should be.

$ eom --version
Eye of MATE Image Viewer 1.5.0

"warty-final-ubuntu.png" can be found in "ubuntu-wallpapers" package of Ubuntu 12.10
http://packages.ubuntu.com/quantal/all/ubuntu-wallpapers/filelist

Eye of MATE simply cannot open this file and other image viewers, e.g., feh is OK.

Probably the same problem as described here, running eom 1.8.0

1. Open a .jpg photo
2. Rotate it
3. Exit eom and tell it to save it
   Expected outcome: When the photo is opened once again, it's rotated
   Actual outcome: The photo rotation doesn't change

Running Mint 17, latest as of 20140708

Hey,
i think it would be great if EOM would preload the next and previous images in the current folder. That would make the quick browsing thru images a lot faster. Specially if you browse thru images on a slow usb device puffering the next image would be speed up things and help reducing the "loading lag".

What do you think?
Greetings
Leo

In the current version of Eye of GNOME, it makes use of the dark theme due to high influential tribute for GTK 3, such as this one:

It would be nice if the GTK3 build of eom to have dark themes whenever the GTK theme has dark theme within GTK3.

incorrect-fsf-address

Since the upgrade from Mint 17.1 to 17.2., images are simply resized on zoom, not resampled. That issue already occurred some years ago (with eog on Ubuntu, I think).

I went through eog git and got Gtlk+3 eom working except a few little things like the below. I could not a commit for these so documenting them here.

• Segfault when adding items to the toolbar
• Sefgault when enabling "image collection"
• Toolbar editor scroll window needs an expand property set somewhere. // Fixed

Otherwise it runs quite nicely now under Gtk3. Thanks to eog devs for the commits 😄

The subject of this issue says it all...

;-)
Mike

the error message:
https://gist.github.com/rezso/b83eab47d9859913a98c

without gobject-introspection the build is successful.

http://anonscm.debian.org/gitweb/?p=pkg-mate/eom.git;a=blob;f=debian/patches/1002_add-keywords-to-eom-desktop-file.patch

no-manual-page-for-binary eom
Each executable in standard binary directories should have a man page.

I have some minor issue regarding how Eye of MATE deal with image format conversion; it does not set output file extension properly.

To reproduce,

• Open WBMP file sketch.wbmp (linked here) in Eye of MATE
• Go to Image > Save As
• Select save location to any folder other than the current one (but do not do anything with filename)
• Select target type (on the bottom) to "The PNG image format (*.png)"
• Click "Save"
• Eye of MATE will show an error:

File format is unknown or unsupported
Eye of MATE could not determine a supported writable
file format based on the filename.
Please try a different file extension like .png or .jpg.
[OK]

(Screenshot here)

But if I manually changed the file name extension to .png and clicked "Save" again, it would work fine.

The expected behavior is, as soon as "The PNG image format (*.png)" was selected,
Eye of MATE should change the file name (in top textbox) to sketch.png
and save the file in PNG format when user clicked "OK".

EOM: Eye of MATE 1.8.0 (from Debian Wheezy backports repository)
MATE: MATE 1.8.1 (from Debian Wheezy backports repository)
System: Debian GNU/Linux 7.0 Wheezy i386

I set: scroll-wheel-zoom false
expected behaviour: scrolling mouse wheel advances to the next or previous picture
actual behaviour: scrolling mouse wheel no longer zooms picture in/out. nothing else happens

If I rename png file to jpg and try to open, eom tells me "Not a JPEG" and ignore file type!

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Eye of MATE doesn't have basic crop feature in it. Implementation of cropping image would be great.

mate-image-viewer 1.6.2 localization does not appear to work. Menu is in English only.

This bug appears for anything but when View->Best Fit is selected ... if the user makes the window smaller, by dragging a corner inward or by restoring the window, the scrollbars are not adjusted and so the user can not scroll to see the whole image. If the user makes the window larger, by dragging a corner outward or by maximizing the window, the scrollbars are not adjusted and if the user scrolls past the image, the image repeats.

Please consider installing this AppData file: https://raw.githubusercontent.com/hughsie/fedora-appstream/master/appdata-extra/desktop/eom.appdata.xml

This is used in GNOME and KDE software installers to add the application description and some screenshots. We'd love to showcase more applications, but without the extra data file we can't. The AppData file needs to be installed to /usr/share/appdata/ on Linux and the basename needs to match the .desktop basename. It would also be great if you could integrate the file with your translation system (e.g. intltool) to make the descriptions translated.

See http://people.freedesktop.org/~hughsient/appdata/ for more details; thanks!

Richard

I believe the gnome pic viewer (under 2.3.2) used to follow sorts of images when viewing any one image, so that hitting next/previous would give you the next image depending on the sort of the caja window from which the viewer was launched.

Eye of Gnome forces alphabetical sort, regardless of the order I put in caja when launching the viewer.

I believe I could sort by MODIFIED in Nautilus and then launch the gnome image viewer and then hit next/previous arrow buttons and browse through the pics in the MODIFIED order I set the Nautilus file browser for that directory of pictures.

Instead, I get forced alphabetical order for my next/previous button presses for whatever picture I started viewing first, based on its filename.

Title is pretty much self explanatory. Also this plugin seems to conflict with "Automatic Orientation" option. If both are enabled then eom often (not always) fails to open an image entirely.

Steps to reproduce:

1. Enable "Date in Statusbar" plugin
2. Open an image and look at the status bar.
3. Enable Automatic orientation
4. Open image file again
5. If it opens nicely then close it and go to step 4, try again until it gets stuck at "Loading image..."

OS info:
Archlinux x64
eom version 1.8.1-1

In version 1.10.0, if I enlarge a picture beyond the screen, when I try to drag it to see the bottom, it goes to the top of the picture and doesn't move. In previous versions, I was able to drag it and see the bottom of the picture.

EOM does resizing window depending on loaded image size.
It would be nice to add function to fix window size, like a checkbox in settings or something other.

I created an SVG with dot from graphviz and eom wouldn't load it. It opened just fine in Firefox. The SVG and the original file I used to create it can be found at:
https://daveisfera.fedorapeople.org/bugs/eom_1.8.1/
The command I ran to generate the SVG was:
dot -Tsvg -O installed_f21_tred.dot

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Hi,

As discussed for stafano-k and other on IRC. What follows is a summary of our conversation.

lcms was last released in 2009 and many projects have already adopted lcms2. lcms2 is available on the following:

• Debian derivatives since Wheezy.
• Ubuntu derivatives since Precise.
• Fedora derivatives since FC18 and FCEL 5.
• All OpenSUSE versions that MATE is built for.
• Arch Linux.
• Gentoo.
• FreeBSD has had it for ~14 months.

Why is might be a good idea.

• http://littlecms2.blogspot.nl/2009/11/what-is-new-from-lcms-1x.html

This following seems to indicate that it could be as simple as replacing lcms.h with lcms2.h.

• http://littlecms2.blogspot.nl/2009/11/backwards-compatibility.html

"all what you need to do is to change the include file from lcms.h to lcms2.h and maybe to do some minor tweaks on your code."

I think that about covers it.

Regards, Martin.

Eye of MATE supporting the .CR2 format image file would be great. Would it be possible to add this feature in the next release?

After installing Linux Mint 17.2 MATE ("Rafaela"), I view JPG images in full-screen (F11), then Zoom-In (+), then it's impossible to scroll the images normally.
This issue do not appear in 'Eye of GNOME' on the same installation of Linux Mint - only appears with 'Eye of MATE'.