From trash.paradise at protonmail.com Fri Jul 16 11:52:37 2021 From: trash.paradise at protonmail.com (=?utf-8?Q?Ga=C3=ABl_Bonithon?=) Date: Fri, 16 Jul 2021 09:52:37 +0000 Subject: Notification switch grayed out on Gitlab Message-ID: Hi, For some time, it is no longer possible to change the notification preferences at the issue / MR level on Xfce's Gitlab. The switch is grayed out, either on or off depending on its last position, as shown in this thread: https://forum.gitlab.com/t/can-t-disable-notifications/52858 It seems that this only affects simple users, who do not have special rights on a project. For example, in my case, I am not impacted on Mousepad or Ristretto where I am a maintainer, but on all other projects. So I guess that the "owners" and "reporters" couldn't see it. I observed the same phenomenon recently on Gnome's Gitlab, but the problem disappeared "by itself" after a few days. So I report it here in case there is something to do. Cheers, Gaël -------------- next part -------------- An HTML attachment was scrubbed... URL: From skunnyk at alteroot.org Sun Jul 25 19:28:19 2021 From: skunnyk at alteroot.org (Romain Bouvier) Date: Sun, 25 Jul 2021 17:28:19 +0000 Subject: Xfce 4.18 dependencies versions Message-ID: <1dd2fc7dc12b4f085aa0f5aa0c1358c5@alteroot.org> Hi :) 4.18 development cycle is already started (https://wiki.xfce.org/releng/4.18/roadmap), we've seen tons of commits in thunar and some core components (GSoC 2021 effect), but we haven't discussed yet the lib/dependencies requirements. One question is : do we want to be able to compile Xfce 4.18 (which is far from being released) on Ubuntu 20.04 (LTS) and CentOS/RockyLinux 8 (this one might be problematic because it only have gtk 3.22 and glib2 2.56). My opinion is : we can ignore them. What I propose, if we are ok to not "support" Ubuntu 20.04 / CentoS 8 (by the time we release 4.18, maybe Ubuntu 22.04 (next lts) will be already released btw). - gtk >= 3.24, so we can ditch tons of "#if GTK_CHECK_VERSION" macros in core - glib-2.0 >= 2.66 (note: ubuntu 20.04 (lts) only have 2.64) Same version for gmodule-2.0, gobject-2.0, gthread-2.0, gio-2.0 and gdbus - libcairo >= 1.16 - gdk-pixbuf-2.0 >= 2.40 Romain, From acs82 at gmx.de Thu Jul 29 00:24:37 2021 From: acs82 at gmx.de (Alex) Date: Thu, 29 Jul 2021 00:24:37 +0200 Subject: Xfce 4.18 dependencies versions In-Reply-To: <1dd2fc7dc12b4f085aa0f5aa0c1358c5@alteroot.org> References: <1dd2fc7dc12b4f085aa0f5aa0c1358c5@alteroot.org> Message-ID: <2b859284-c5e2-ec7e-9b5b-0f01d9854e7c@gmx.de> Hi Romain, thanks for bringing this up ! +1 for gtk >= 3.24 / glib >= 2.66  from my side. (Even though currently I dont have a usecase) Cheers, Alex Am 25.07.21 um 19:28 schrieb Romain Bouvier: > Hi :) > > 4.18 development cycle is already started (https://wiki.xfce.org/releng/4.18/roadmap), we've seen tons of commits in thunar and some core components (GSoC 2021 effect), but we haven't discussed yet the lib/dependencies requirements. > > One question is : do we want to be able to compile Xfce 4.18 (which is far from being released) on Ubuntu 20.04 (LTS) and CentOS/RockyLinux 8 (this one might be problematic because it only have gtk 3.22 and glib2 2.56). My opinion is : we can ignore them. > > What I propose, if we are ok to not "support" Ubuntu 20.04 / CentoS 8 (by the time we release 4.18, maybe Ubuntu 22.04 (next lts) will be already released btw). > > - gtk >= 3.24, so we can ditch tons of "#if GTK_CHECK_VERSION" macros in core > - glib-2.0 >= 2.66 (note: ubuntu 20.04 (lts) only have 2.64) > Same version for gmodule-2.0, gobject-2.0, gthread-2.0, gio-2.0 and gdbus > - libcairo >= 1.16 > - gdk-pixbuf-2.0 >= 2.40 > > > Romain, > _______________________________________________ > Xfce4-dev mailing list > Xfce4-dev at xfce.org > https://mail.xfce.org/mailman/listinfo/xfce4-dev From andre at andreldm.com Fri Jul 30 19:45:05 2021 From: andre at andreldm.com (andre at andreldm.com) Date: Fri, 30 Jul 2021 19:45:05 +0200 (CEST) Subject: Xfce 4.18 dependencies versions In-Reply-To: <2b859284-c5e2-ec7e-9b5b-0f01d9854e7c@gmx.de> References: <1dd2fc7dc12b4f085aa0f5aa0c1358c5@alteroot.org> <2b859284-c5e2-ec7e-9b5b-0f01d9854e7c@gmx.de> Message-ID: Hi Romain, I agree with you and Alex, current "stable" distros should stick to 4.16, their next versions should target 4.18 if we don't delay it too much. I can't stress this enough: who wants bleeding edge packages, should use a bleeding edge distro, simple like that. Cheers, Andre Miranda Jul 28, 2021, 19:24 by acs82 at gmx.de: > Hi Romain, > > thanks for bringing this up ! > > +1 for gtk >= 3.24 / glib >= 2.66  from my side. (Even though currently > I dont have a usecase) > > Cheers, > > Alex > > > Am 25.07.21 um 19:28 schrieb Romain Bouvier: > >> Hi :) >> >> 4.18 development cycle is already started (https://wiki.xfce.org/releng/4.18/roadmap), we've seen tons of commits in thunar and some core components (GSoC 2021 effect), but we haven't discussed yet the lib/dependencies requirements. >> >> One question is : do we want to be able to compile Xfce 4.18 (which is far from being released) on Ubuntu 20.04 (LTS) and CentOS/RockyLinux 8 (this one might be problematic because it only have gtk 3.22 and glib2 2.56). My opinion is : we can ignore them. >> >> What I propose, if we are ok to not "support" Ubuntu 20.04 / CentoS 8 (by the time we release 4.18, maybe Ubuntu 22.04 (next lts) will be already released btw). >> >> - gtk >= 3.24, so we can ditch tons of "#if GTK_CHECK_VERSION" macros in core >> - glib-2.0 >= 2.66 (note: ubuntu 20.04 (lts) only have 2.64) >> Same version for gmodule-2.0, gobject-2.0, gthread-2.0, gio-2.0 and gdbus >> - libcairo >= 1.16 >> - gdk-pixbuf-2.0 >= 2.40 >> >> >> Romain, >> _______________________________________________ >> Xfce4-dev mailing list >> Xfce4-dev at xfce.org >> https://mail.xfce.org/mailman/listinfo/xfce4-dev >> > > > _______________________________________________ > Xfce4-dev mailing list > Xfce4-dev at xfce.org > https://mail.xfce.org/mailman/listinfo/xfce4-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.j.buxton at gmail.com Sat Jul 31 05:27:57 2021 From: a.j.buxton at gmail.com (Alistair Buxton) Date: Sat, 31 Jul 2021 04:27:57 +0100 Subject: Xfce 4.18 dependencies versions In-Reply-To: References: <1dd2fc7dc12b4f085aa0f5aa0c1358c5@alteroot.org> <2b859284-c5e2-ec7e-9b5b-0f01d9854e7c@gmx.de> Message-ID: I use Ubuntu LTS so this will effectively exclude me from contributing any patches until 2022, unless you want untested code. On Fri, 30 Jul 2021 at 18:45, wrote: > Hi Romain, > I agree with you and Alex, current "stable" distros should stick to 4.16, > their next versions should target 4.18 if we don't delay it too much. I > can't stress this enough: who wants bleeding edge packages, should use a > bleeding edge distro, simple like that. > > Cheers, > Andre Miranda > > Jul 28, 2021, 19:24 by acs82 at gmx.de: > > Hi Romain, > > thanks for bringing this up ! > > +1 for gtk >= 3.24 / glib >= 2.66 from my side. (Even though currently > I dont have a usecase) > > Cheers, > > Alex > > > Am 25.07.21 um 19:28 schrieb Romain Bouvier: > > Hi :) > > 4.18 development cycle is already started ( > https://wiki.xfce.org/releng/4.18/roadmap), we've seen tons of commits in > thunar and some core components (GSoC 2021 effect), but we haven't > discussed yet the lib/dependencies requirements. > > One question is : do we want to be able to compile Xfce 4.18 (which is far > from being released) on Ubuntu 20.04 (LTS) and CentOS/RockyLinux 8 (this > one might be problematic because it only have gtk 3.22 and glib2 2.56). My > opinion is : we can ignore them. > > What I propose, if we are ok to not "support" Ubuntu 20.04 / CentoS 8 (by > the time we release 4.18, maybe Ubuntu 22.04 (next lts) will be already > released btw). > > - gtk >= 3.24, so we can ditch tons of "#if GTK_CHECK_VERSION" macros in > core > - glib-2.0 >= 2.66 (note: ubuntu 20.04 (lts) only have 2.64) > Same version for gmodule-2.0, gobject-2.0, gthread-2.0, gio-2.0 and gdbus > - libcairo >= 1.16 > - gdk-pixbuf-2.0 >= 2.40 > > > Romain, > _______________________________________________ > Xfce4-dev mailing list > Xfce4-dev at xfce.org > https://mail.xfce.org/mailman/listinfo/xfce4-dev > > > > _______________________________________________ > Xfce4-dev mailing list > Xfce4-dev at xfce.org > https://mail.xfce.org/mailman/listinfo/xfce4-dev > > > _______________________________________________ > Xfce4-dev mailing list > Xfce4-dev at xfce.org > https://mail.xfce.org/mailman/listinfo/xfce4-dev -- Alistair Buxton a.j.buxton at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From trash.paradise at protonmail.com Sat Jul 31 12:51:09 2021 From: trash.paradise at protonmail.com (=?utf-8?Q?Ga=C3=ABl_Bonithon?=) Date: Sat, 31 Jul 2021 10:51:09 +0000 Subject: Notification switch grayed out on Gitlab In-Reply-To: References: Message-ID: A workaround: you can add a smiley, which activates notifications without notifying other users, unlike messages. Removing the smiley disables notifications. It is probably best not to use +/- thumbs, so as not to distract from their original meaning of supporting or not supporting the proposal in question. I will personally use :bell:, like here: https://gitlab.xfce.org/panel-plugins/xfce4-mpc-plugin/-/issues/7 Cheers, Gaël ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, July 16th, 2021 at 9:52 AM, Gaël Bonithon wrote: > Hi, > > For some time, it is no longer possible to change the notification preferences at the issue / MR level on Xfce's Gitlab. The switch is grayed out, either on or off depending on its last position, as shown in this thread: https://forum.gitlab.com/t/can-t-disable-notifications/52858 > > It seems that this only affects simple users, who do not have special rights on a project. For example, in my case, I am not impacted on Mousepad or Ristretto where I am a maintainer, but on all other projects. So I guess that the "owners" and "reporters" couldn't see it. > > I observed the same phenomenon recently on Gnome's Gitlab, but the problem disappeared "by itself" after a few days. So I report it here in case there is something to do. > > Cheers, > Gaël -------------- next part -------------- An HTML attachment was scrubbed... URL: