Bug#826605: geeqie: thumbnails disappear after deleting an image
Package: geeqie
Version: 1:1.3-1
Followup-For: Bug #826605
In the previous patch I accidentally left a few unused variable
declarations. This patch removes them.
Michael
diff --git a/src/collect-table.c b/src/collect-table.c
index b45633b..d33bf85 100644
--- a/src/collect-table.c
+++ b/src/collect-table.c
@@ -1006,10 +1006,6 @@ static void collection_table_set_focus(CollectTable *ct,
CollectInfo *info)
if (collection_table_find_iter(ct, ct->focus_info, , NULL))
{
- GtkTreePath *tpath;
- GtkTreeViewColumn *column;
- GtkTreeModel *store;
-
tree_view_row_make_visible(GTK_TREE_VIEW(ct->listview), ,
FALSE);
}
}
diff --git a/src/view_file_icon.c b/src/view_file_icon.c
index 45cb6a9..581f72c 100644
--- a/src/view_file_icon.c
+++ b/src/view_file_icon.c
@@ -1195,10 +1195,6 @@ static void vficon_set_focus(ViewFile *vf, IconData *id)
if (vficon_find_iter(vf, VFICON(vf)->focus_id, , NULL))
{
- GtkTreePath *tpath;
- GtkTreeViewColumn *column;
- GtkTreeModel *store;
-
tree_view_row_make_visible(GTK_TREE_VIEW(vf->listview), ,
FALSE);
}
}
Bug#826605: geeqie: thumbnails disappear after deleting an image
Package: geeqie Version: 1:1.3-1 Followup-For: Bug #826605 Hi. For fun I thought I'd have a go at fixing this bug. It seems to be an old bug going back to at least Geeqie 1.0. It's hardly a serious issue, but I've noticed it on many occasions. It seems to be triggered by a call to gtk_tree_view_set_cursor in the function vficon_set_focus in view_file_icon.c. I found that removing that call makes the problem go away. But what is the call there for? The comment above the call says the following: /* focus is set to an extra column with 0 width to hide focus */ However, try as I might, I cannot see any visual difference if I remove the call. So maybe it's not needed? I've included a patch that removes this call (and the similar one in collect-table.c). This fixes the bug for me, but I have only tested the patch on GTK2. It is untested on GTK3. Maybe a GTK wizard can weigh in on correctness here. At the very least it might act as a starting point for a more correct fix, if there is one. Kind regards, Michael diff --git a/src/collect-table.c b/src/collect-table.c index 2695640..b45633b 100644 --- a/src/collect-table.c +++ b/src/collect-table.c @@ -1011,13 +1011,6 @@ static void collection_table_set_focus(CollectTable *ct, CollectInfo *info) GtkTreeModel *store; tree_view_row_make_visible(GTK_TREE_VIEW(ct->listview), , FALSE); - - store = gtk_tree_view_get_model(GTK_TREE_VIEW(ct->listview)); - tpath = gtk_tree_model_get_path(store, ); - /* focus is set to an extra column with 0 width to hide focus, we draw it ourself */ - column = gtk_tree_view_get_column(GTK_TREE_VIEW(ct->listview), COLLECT_TABLE_MAX_COLUMNS); - gtk_tree_view_set_cursor(GTK_TREE_VIEW(ct->listview), tpath, column, FALSE); - gtk_tree_path_free(tpath); } } diff --git a/src/view_file_icon.c b/src/view_file_icon.c index 1457f81..45cb6a9 100644 --- a/src/view_file_icon.c +++ b/src/view_file_icon.c @@ -1200,13 +1200,6 @@ static void vficon_set_focus(ViewFile *vf, IconData *id) GtkTreeModel *store; tree_view_row_make_visible(GTK_TREE_VIEW(vf->listview), , FALSE); - - store = gtk_tree_view_get_model(GTK_TREE_VIEW(vf->listview)); - tpath = gtk_tree_model_get_path(store, ); - /* focus is set to an extra column with 0 width to hide focus, we draw it ourself */ - column = gtk_tree_view_get_column(GTK_TREE_VIEW(vf->listview), VFICON_MAX_COLUMNS); - gtk_tree_view_set_cursor(GTK_TREE_VIEW(vf->listview), tpath, column, FALSE); - gtk_tree_path_free(tpath); } }
Bug#763406: geeqie: Float window uses image window dimensions
Package: geeqie Version: 1:1.3-1 Followup-For: Bug #763406 Hi. The bug exists on my system too. I made a small patch. Kind regards, Michael diff --git a/src/layout.c b/src/layout.c index 4921b1a..cc29107 100644 --- a/src/layout.c +++ b/src/layout.c @@ -1174,7 +1174,7 @@ gboolean layout_geometry_get_tools(LayoutWindow *lw, gint *x, gint *y, gint *w, return FALSE; } - window = gtk_widget_get_window(lw->window); + window = gtk_widget_get_window(lw->tools); gdk_window_get_root_origin(window, x, y); *w = gdk_window_get_width(window); *h = gdk_window_get_height(window);
Bug#779427: geeqie: in "Really continue?" copy confirmation dialog leads to crash
Package: geeqie
Version: 1:1.3-1
Followup-For: Bug #779427
Hi. The bug exists on my system too. I made a small patch for the
maintainer to check over.
When escape key is pressed, the "Really continue?" dialog is now
closed, and it is interpreted as cancel as expected.
Kind regards,
Michael
diff --git a/src/ui_utildlg.c b/src/ui_utildlg.c
index 9548a8a..5937875 100644
--- a/src/ui_utildlg.c
+++ b/src/ui_utildlg.c
@@ -99,8 +99,15 @@ static gboolean generic_dialog_key_press_cb(GtkWidget
*widget, GdkEventKey *even
if (event->keyval == GDK_KEY_Escape)
{
- if (gd->cancel_cb) gd->cancel_cb(gd, gd->data);
- else if (auto_close) generic_dialog_click_cb(widget, data);
+ if (gd->cancel_cb)
+ {
+ gd->cancel_cb(gd, gd->data);
+ if (auto_close) generic_dialog_close(gd);
+ }
+ else
+ {
+ if (auto_close) generic_dialog_click_cb(widget, data);
+ }
return TRUE;
}
return FALSE;
Bug#783262: geeqie: Memory leak
Package: geeqie Version: 1:1.2-3+b2 Followup-For: Bug #783262 Thank you Klaus. Although OK for Debian, I now think my patch may be incorrect for GTK3 builds. I have addressed that with an upstream pull request. Michael
Bug#783262: geeqie: Memory leak
Package: geeqie
Version: 1:1.2-3
Followup-For: Bug #783262
Hi.
Firstly, thank you for maintaining geeqie in Debian. It is appreciated.
I also suffer from what I believe is this bug. It was not present in
geeqie 1.0 and was simple for me to reproduce in 1.2+. I open a
directory containing a few thousand jpg files of around 100k each and
just keep hitting the key for "Next Image". After around a minute my
computer will freeze.
Given this reproducibility, I ran git bisect and found the commit that
introduced the behaviour for me was the following
commit b4c4a924121c3aa6b2f1eb7570dd3f419d2f4d83
Author: Vladimir Nadvornik <nadvor...@suse.cz>
Date: Thu Aug 2 00:15:16 2012 +0200
use cairo for drawing
I then noticed what I think is a missing cairo_destroy call in
cellrenderericon.c . The following patch solves the problem completely
for me as far as I can tell:
diff -Nru geeqie-1.2.old/src/cellrenderericon.c
geeqie-1.2/src/cellrenderericon.c
--- geeqie-1.2.old/src/cellrenderericon.c 2014-07-20 14:16:02.0
+0100
+++ geeqie-1.2/src/cellrenderericon.c 2016-08-19 03:40:27.387539295 +0100
@@ -663,7 +663,10 @@
pixbuf = cellicon->pixbuf;
text = cellicon->text;
- if (!pixbuf && !text) return;
+ if (!pixbuf && !text) {
+ cairo_destroy(cr);
+ return;
+ }
gtk_cell_renderer_get_padding(cell, , );
Please let me know if you agree with my conclusions. If so it would be
nice to have this patch included.
Kind regards,
Michael Cross
-- System Information:
Debian Release: 8.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages geeqie depends on:
ii geeqie-common1:1.2-3
ii libatk1.0-0 2.14.0-1
ii libc62.19-18+deb8u4
ii libcairo21.14.0-2.1+deb8u1
ii libexiv2-13 0.24-4.1
ii libfontconfig1 2.11.0-6.3+deb8u1
ii libfreetype6 2.5.2-3+deb8u1
ii libgcc1 1:4.9.2-10
ii libgdk-pixbuf2.0-0 2.31.1-2+deb8u5
ii libglib2.0-0 2.42.1-1+b1
ii libgtk2.0-0 2.24.25-3+deb8u1
ii libjpeg62-turbo 1:1.3.1-12
ii liblcms2-2 2.6-3+b3
ii liblircclient0 0.9.0~pre1-1.2
ii liblua5.1-0 5.1.5-7.1
ii libpango-1.0-0 1.36.8-3
ii libpangocairo-1.0-0 1.36.8-3
ii libpangoft2-1.0-01.36.8-3
ii libstdc++6 4.9.2-10
ii libtiff5 4.0.3-12.3+deb8u1
Versions of packages geeqie recommends:
pn exiftran
pn exiv2
ii imagemagick 8:6.8.9.9-5+deb8u3
ii librsvg2-common 2.40.5-1+deb8u2
pn lpr
pn ufraw-batch
pn zenity
Versions of packages geeqie suggests:
pn geeqie-dbg
pn gimp
pn libjpeg-progs
pn ufraw
pn xpaint
-- no debconf information
