Bug#991153: icewm: switching windows in taskbar order is broken
Package: icewm
Version: 2.1.2-1
Severity: normal
Tags: patch
Dear Maintainer,
A patch in upstream icewm 2.1.0 broke the behaviour of switching windows in the
order they appear on the taskbar. This can be done by scrolling the mouse
wheel over the taskbar or with configuring special shortcuts.
At first this works but as soon as buttons are moved (e.g. by dragging) the
order becomes chaotic.
The Debian testing/unstable version of icewm 2.1.2 includes this problem.
That's a regression since current stable.
I reported the problem upstream: https://github.com/bbidulock/icewm/issues/602
It has now been fixed upstream by commit c16c44e936856bcebf11c8fd36028119c021e0
The patch applies nicely to 2.1.2
Could you please include this patch in the Debian package?
Thank you!
-- System Information:
Debian Release: 10.9
APT prefers stable
APT policy: (990, 'stable'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-16-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
commit c16c44e936856bcebf11c8fd36028119c021e0cc
Author: Bert Gijsbers
Date: Thu Jul 15 21:36:20 2021 +0200
Rewrite task successor and task predecessor to properly take into account
the
separation of TaskBarApp and TaskButton as well as task grouping.
Resolves #602, resolves #604.
[rediffed against 2.1.2 by Jiri Bohac]
diff --git a/src/atasks.cc b/src/atasks.cc
index fe5405e9..b47fe05a 100644
--- a/src/atasks.cc
+++ b/src/atasks.cc
@@ -125,6 +125,38 @@ void TaskButton::remove(TaskBarApp* tapp) {
}
}
+TaskBarApp* TaskButton::getNextShown(TaskBarApp* tapp) const {
+if (grouping()) {
+int k = tapp ? find(fGroup, tapp) : -1;
+if (k >= 0 || tapp == nullptr) {
+while (++k < fGroup.getCount()) {
+if (fGroup[k]->getShown()) {
+return fGroup[k];
+}
+}
+}
+} else if (tapp == nullptr) {
+return fActive;
+}
+return nullptr;
+}
+
+TaskBarApp* TaskButton::getPrevShown(TaskBarApp* tapp) const {
+if (grouping()) {
+int k = tapp ? find(fGroup, tapp) : fGroup.getCount();
+if (k > 0) {
+while (--k >= 0) {
+if (fGroup[k]->getShown()) {
+return fGroup[k];
+}
+}
+}
+} else if (tapp == nullptr) {
+return fActive;
+}
+return nullptr;
+}
+
void TaskButton::setShown(TaskBarApp* tapp, bool ashow) {
if (tapp == fActive) {
if (ashow != visible())
@@ -562,28 +594,46 @@ void TaskPane::insert(TaskBarApp* tapp) {
}
TaskBarApp* TaskPane::predecessor(TaskBarApp* tapp) {
-const int count = fApps.getCount();
-const int found = find(fApps, tapp);
-if (found >= 0) {
-for (int i = count - 1; 1 <= i; --i) {
-int k = (found + i) % count;
-if (fApps[k]->getShown()) {
-return fApps[k];
-}
+TaskButton* button = tapp->button();
+TaskBarApp* prev = button->getPrevShown(tapp);
+if (prev && button->getShown()) {
+return prev;
+} else {
+int k = find(fTasks, button);
+if (k >= 0) {
+int i = k;
+do {
+i = (i - 1 + fTasks.getCount()) % fTasks.getCount();
+if (fTasks[i]->getShown()) {
+prev = fTasks[i]->getPrevShown(nullptr);
+if (prev && prev != tapp) {
+return prev;
+}
+}
+} while (i != k);
}
}
return nullptr;
}
TaskBarApp* TaskPane::successor(TaskBarApp* tapp) {
-const int count = fApps.getCount();
-const int found = find(fApps, tapp);
-if (found >= 0) {
-for (int i = 1; i < count; ++i) {
-int k = (found + i) % count;
-if (fApps[k]->getShown()) {
-return fApps[k];
-}
+TaskButton* button = tapp->button();
+TaskBarApp* next = button->getNextShown(tapp);
+if (next && button->getShown()) {
+return next;
+} else {
+int k = find(fTasks, button);
+if (k >= 0) {
+int i = k;
+do {
+i = (i + 1) % fTasks.getCount();
+if (fTasks[i]->getShown()) {
+next = fTasks[i]->getNextShown(nullptr);
+if (next && next != tapp) {
+return next;
+}
+}
+} while (i != k);
}
}
return nullptr;
diff --git a/src/atasks.h b/src/atasks.h
index 14553e7b..769d2f1d 100644
--- a/src/atasks.h
+++ b/src/atasks.h
@@ -61,6 +61,8 @@ public:
int getOrder() const;
int
Bug#988273: geeqie: stereo side-by-side mode broken by 0007-Fix-644-Images-fail-to-render-on-MacOS.patch
Package: geeqie Version: 1:1.6-8 Severity: important Dear Maintainer, stereo side-by-side is broken in geeqie; I found this is caused by 0007-Fix-644-Images-fail-to-render-on-MacOS.patch, which is a backport of a broken upstream commit. I reported the problem upstream: https://github.com/BestImageViewer/geeqie/issues/892 Steps to reproduce: go to Preferences -> Stereo -> Windowed stereo mode; choose "Side by side" go to View -> Stereo -> Side by side view any jpeg file; it is supposed to consider one half as the stereo left side and one half as the stereo right side; both sides should be shown next to each other, possibly with a dividing black strip between them. observe the left side - it shows nonsense; the right side is sometimes ok, sometimes shows the full picture and not just the righ half -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-6-amd64 (SMP w/2 CPU threads) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages geeqie depends on: ii geeqie-common1:1.6-8 ii libc62.31-11 ii libcairo21.16.0-5 ii libchamplain-0.12-0 0.12.20-1 ii libchamplain-gtk-0.12-0 0.12.20-1 ii libclutter-1.0-0 1.26.4+dfsg-2 ii libclutter-gtk-1.0-0 1.8.4-4 ii libcogl201.22.8-2 ii libdjvulibre21 3.5.28-1 ii libexiv2-27 0.27.3-3 ii libffmpegthumbnailer4v5 2.1.1-0.2+b1 ii libgcc-s110.2.1-6 ii libgdk-pixbuf-2.0-0 2.42.2+dfsg-1 ii libglib2.0-0 2.66.8-1 ii libgtk-3-0 3.24.24-3 ii libheif1 1.11.0-1 ii libjpeg62-turbo 1:2.0.6-4 ii liblcms2-2 2.12~rc1-2 ii liblirc-client0 0.10.1-6.3 ii liblua5.1-0 5.1.5-8.1+b3 ii libopenjp2-7 2.4.0-3 ii libpango-1.0-0 1.46.2-3 ii libpangocairo-1.0-0 1.46.2-3 ii libpoppler-glib8 20.09.0-3.1 ii libstdc++6 10.2.1-6 ii libtiff5 4.2.0-1 ii libwebp6 0.6.1-2+b1 ii sensible-utils 0.0.14 Versions of packages geeqie recommends: ii cups-bsd [lpr] 2.3.3op2-3 ii exiftran 2.10-4 ii exiv20.27.3-3 ii imagemagick 8:6.9.11.60+dfsg-1 ii imagemagick-6.q16 [imagemagick] 8:6.9.11.60+dfsg-1 ii librsvg2-common 2.50.3+dfsg-1 ii ufraw-batch 0.22-4 ii zenity 3.32.0-6 Versions of packages geeqie suggests: pn geeqie-dbg ii gimp 2.10.22-4 ii libjpeg-progs 1:9d-1 pn ufraw pn xpaint -- no debconf information
Bug#916756: geeqie: fullscreen spanning multiuple monitors does not work
On Wed, Mar 10, 2021 at 11:03:57PM +0100, Andreas Ronnquist wrote: > Hi! > > Is this still a problem for you with the version from unstable? > (1:1.6-8) No, I verified that geeqie from unstable works as expected. That is thanks to my patch _and_ geeqie now being compiled with GTK3. Thanks so much! This bug can be closed. -- Jiri Bohac e-mail/jabber: j...@boha.cz
Bug#904976: swicth to GTK3 before Buster?
Hi, any plans to try the switch again before the Buster freeze? Can I do anything to help? -- Jiri Bohac e-mail/jabber: j...@boha.cz
Bug#904976: fullscreen bug with gtk3-only fix
I now reported the above-mentioned fullscreen bug (where only a GTK3 fix is available so far): #916756 -- Jiri Bohac e-mail/jabber: j...@boha.cz
Bug#916756: geeqie: fullscreen spanning multiuple monitors does not work
Package: geeqie Version: 1:1.3-1+b1 Severity: important Tags: patch upstream Dear Maintainer, geeqie support for fullscreen spanning all monitors is broken since jessie. I reported the bug upstream and provided a patch. https://github.com/BestImageViewer/geeqie/issues/650 Trouble is the patch only works if geeqie is compiled with GTK3, so for Debian, either a GTK2 backport of the patch would be needed or geeqie would have to be switched to GTK3 (bug 904976). We use geeqie for stereoscopic projections with two projectors and without working multi-monitor fullscreen, geeqie is unusable. -- System Information: Debian Release: 9.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (x86_64) Foreign Architectures: amd64 Kernel: Linux 4.9.0-8-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US, LC_CTYPE=en_US.UTF8 (charmap=UTF-8), LANGUAGE=en_US (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.3-1 ii libatk1.0-0 2.22.0-1 ii libc62.24-11+deb9u3 ii libcairo21.14.8-1 ii libexiv2-14 0.25-3.1+deb9u1 ii libfontconfig1 2.11.0-6.7+b1 ii libfreetype6 2.6.3-3.2 ii libgcc1 1:6.3.0-18+deb9u1 ii libgdk-pixbuf2.0-0 2.36.5-2+deb9u2 ii libglib2.0-0 2.50.3-2 ii libgtk2.0-0 2.24.31-2 ii libjpeg62-turbo 1:1.5.1-2 ii liblcms2-2 2.8-4+deb9u1 ii liblirc-client0 0.9.4c-9 ii liblua5.1-0 5.1.5-8.1+b2 ii libpango-1.0-0 1.40.5-1 ii libpangocairo-1.0-0 1.40.5-1 ii libpangoft2-1.0-01.40.5-1 ii libstdc++6 6.3.0-18+deb9u1 ii libtiff5 4.0.8-2+deb9u4 Versions of packages geeqie recommends: ii cups-bsd [lpr] 2.2.1-8+deb9u2 ii exiftran 2.10-2+b3 ii exiv20.25-3.1+deb9u1 ii imagemagick 8:6.9.7.4+dfsg-11+deb9u6 ii imagemagick-6.q16 [imagemagick] 8:6.9.7.4+dfsg-11+deb9u6 ii librsvg2-common 2.40.16-1+b1 ii ufraw-batch 0.22-1.1 ii zenity 3.22.0-1+b1 Versions of packages geeqie suggests: pn geeqie-dbg ii gimp 2.8.18-1+deb9u1 ii libjpeg-turbo-progs [libjpeg-progs] 1:1.5.1-2 pn ufraw pn xpaint -- no debconf information
Bug#904976: what are the problems?
Andreas, you say "The GTK3 version contains too much problems". Do you have a list of these problems? Just now I found a problem in geeqie (fullscreen spanning multiple monitors is broken), which is very easy to fix for GTK3 and hard to fix for GTK2 (https://github.com/BestImageViewer/geeqie/pull/651) If we had a list of issues, I might have a look at some of them (just to get my fullscreen fix working in Debian). openSUSE has been compiling geeqie with GTK3 since April 2016, so it can't be all that bad. If you paper over the issues by sticking to GTK2, we might never get the chance to fix them. -- Jiri Bohac e-mail/jabber: j...@boha.cz
Bug#841915: texlive-extra-utils: missing dependencies: pdfjam needs pdfpages.sty from texlive-latex-recommended
Package: texlive-extra-utils Version: 2014.20141024-1 Severity: normal Dear Maintainer, the pdfjam program from the texlive-extra-utils needs pdfpages.sty from texlive-latex-recommended. This has already been reported in #691690. However, only a "Recommends:" dependecy has been added to texlive-extra-utils. I think this should be a hard "Depends:" dependency, since pdfjam is completely unusable without pdfpages.sty. $ pdfjam pdfjam: This is pdfjam version 2.08. pdfjam: Reading any site-wide or user-specific defaults... (none found) pdfjam: No arguments supplied; continuing anyway. (See 'pdfjam --help' for information on usage.) pdfjam: No PDF/JPG/PNG source specified: input is from stdin. pdfjam ERROR: LaTeX package pdfpages.sty is not installed ## minimal input file ## other files ## List of ls-R files -rw-r--r-- 1 root root 1175 Oct 24 14:15 /var/lib/texmf/ls-R lrwxrwxrwx 1 root root 29 Oct 21 2014 /usr/share/texmf/ls-R -> /var/lib/texmf/ls-R-TEXMFMAIN lrwxrwxrwx 1 root root 31 Dec 2 2014 /usr/share/texlive/texmf-dist/ls-R -> /var/lib/texmf/ls-R-TEXLIVEDIST lrwxrwxrwx 1 root root 31 Dec 2 2014 /usr/share/texlive/texmf-dist/ls-R -> /var/lib/texmf/ls-R-TEXLIVEDIST ## Config files -rw-r--r-- 1 root root 475 Mar 21 2016 /etc/texmf/web2c/texmf.cnf -rw-r--r-- 1 root root 3307 Oct 24 14:15 /var/lib/texmf/web2c/fmtutil.cnf lrwxrwxrwx 1 root root 32 Dec 2 2014 /usr/share/texmf/web2c/updmap.cfg -> /var/lib/texmf/updmap.cfg-DEBIAN -rw-r--r-- 1 root root 3245 Oct 24 14:15 /var/lib/texmf/tex/generic/config/language.dat ## Files in /etc/texmf/web2c/ total 8 -rw-r--r-- 1 root root 283 Jan 9 2013 mktex.cnf -rw-r--r-- 1 root root 475 Mar 21 2016 texmf.cnf ## md5sums of texmf.d ca40c66f144b4bafc3e59a2dd32ecb9c /etc/texmf/texmf.d/00debian.cnf -- System Information: Debian Release: 8.6 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages texlive-extra-utils depends on: ii dpkg1.17.27 ii python2.7 2.7.9-2+deb8u1 ii python3 3.4.2-2 ii tex-common 5.03 ii texlive-base2014.20141024-2 ii texlive-binaries2014.20140926.35254-6 ii texlive-latex-base 2014.20141024-2 Versions of packages texlive-extra-utils recommends: ii ghostscript9.06~dfsg-2+deb8u3 pn libfile-homedir-perl pn libyaml-tiny-perl pn ruby | ruby-interpreter ii texlive-latex-recommended 2014.20141024-2 Versions of packages texlive-extra-utils suggests: pn chktex pn dvidvi pn dvipng pn fragmaster pn lacheck pn latexdiff pn latexmk pn purifyeps pn xindy Versions of packages tex-common depends on: ii debconf [debconf-2.0] 1.5.56 ii dpkg 1.17.27 ii ucf3.0030 Versions of packages tex-common suggests: ii debhelper 9.20150101+deb8u2 Versions of packages texlive-extra-utils is related to: ii tex-common5.03 ii texlive-binaries 2014.20140926.35254-6 -- debconf information excluded
Bug#801384: cron boot order is wrong with systemd, cronatbs ignored because non-local users are not known
Package: cron Version: 3.0pl1-127+deb8u1 Severity: important cron needs to be started later then certain services providing non-local users. The init file (/etc/init.d/cron) has this LSB line in it: Should-Start: $network $named slapd autofs ypbind nscd nslcd winbind But the systemd service file (/lib/systemd/system/cron.service) has no corresponding After= line. When systemd is used, the service file gets precedence and the LSB init file is ignored, thus cron may be started before these services. E.g. on my system, I have local users in a locally-running LDAP server (slapd). When cron starts before slapd, crontabs containing non-local users are ignored: Oct 7 09:34:03 localhost cron[834]: Error: bad username; while reading /etc/crontab Oct 7 09:34:03 localhost cron[834]: (*system*) ERROR (Syntax error, this crontab file will be ignored) Fixed by adding "After=slapd.service" to the cron service file. This is a regression when upgrading from wheezy (as it did not use systemd). Other bug reports exist which are most likely caused by the same problem: #767016 [i| | ] [cron] cron does start before sssd and therefore authentication fails #783665 [i| | ] [cron] cron does not execute some non-root cron.d jobs when started before ypbind -- System Information: Debian Release: 8.2 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_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages cron depends on: ii adduser 3.113+nmu3 ii debianutils 4.4+b1 ii dpkg 1.17.25 ii init-system-helpers 1.22 ii libc62.19-18+deb8u1 ii libpam-runtime 1.1.8-3.1 ii libpam0g 1.1.8-3.1 ii libselinux1 2.3-2 ii lsb-base 4.1+Debian13+nmu1 Versions of packages cron recommends: ii postfix [mail-transport-agent] 2.11.3-1 Versions of packages cron suggests: pn anacron pn checksecurity ii logrotate 3.8.7-1+b1 Versions of packages cron is related to: ii libnss-ldap 265-3+b1 pn libnss-ldapd ii libpam-ldap 184-8.7+b1 pn libpam-mount pn nis pn nscd -- Configuration Files: /etc/crontab changed [not included] -- no debconf information
Bug#453050: also reproducible with 3.0.24-6etch6
Hi, just for the record, I also had this problem with 3.0.24-6etch6. Downdgrading to 3.0.24-6etch4 helped. I also had random garbage in the OS field reported by smbclient. I saw the problem with the truncated directories on Windows NT 4.0 WS and also on Windows XP. However, mounting the same share on linux worked well, without truncating the directories. Unfortunately, this is a production system, so I can't test .27 here, but I could test fixes for 3.0.24-6etch6. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
