Re: Moving final mailman lists over to discourse

On Sun, 30 Oct 2022 at 18:45, Anastasios Lisgaras via desktop-devel-list < desktop-devel-list@gnome.org> wrote: > On 10/20/22 20:48, Andre Klapper via desktop-devel-list wrote: > > On Thu, 2022-09-29 at 16:48 +0100, Neil McGovern wrote: > > Are there plans to update the https://mail.gnome.org

Re: Is libgd still a thing?

Looking at the gnome-world moduleset, the following modules are still using libgd: - nautilus - evince - totem - gnome-photos - gedit Archiving libgd will likely have to wait, considering that all of these are core GNOME applications. Ciao, Emmanuele. On Mon, 14 Jun 2021 at 17:19, Andre

Re: Can we enforce beta release for the freeze

On Mon, 22 Feb 2021 at 00:20, Shaun McCance wrote: > What I want is a discussion on how we can ensure beta releases happen in > the future. For example, can we do more to automate releases? Or (again, > for example), could we have an automated script that emails this list with > modules missing

Re: Let's improve our communication: Discourse

On Tue, 29 Sep 2020 at 10:25, Milan Crha via desktop-devel-list < desktop-devel-list@gnome.org> wrote: > On Fri, 2020-09-25 at 14:33 -0500, Michael Catanzaro wrote: > > and make contributing to GNOME more attractive to newcomers. > > Hi, > do you think the newcomers do not know how the

New GNOME versioning scheme

Hi all; This email is cross-posted to Discourse: https://discourse.gnome.org/t/new-gnome-versioning-scheme/4235 Please, use Discourse to ask further questions or clarifications. After various off-line/in person talks, last year I started [a discussion][0] on Discourse about the existing

Re: Regarding behaviour of Gnome and Fedora members

On Fri, 12 Jun 2020 at 13:30, Ty Young via desktop-devel-list < desktop-devel-list@gnome.org> wrote: > ...sorry, just read the xkcd link. That, IMO, does indeed violates > GNOME's Code of Conduct. There sure are a lot of people violating their > own project's inclusion and community standards...

Re: Is any GNOME project using Mapbox legacy classic tiles with the GNOME API key?

Could it be caused by users of Maps on some long term support Linux distributions, like Ubuntu 16.04/18.04, or RHEL7/8? Ciao, Emmanuele. On Mon, 8 Jun 2020 at 22:00, Marcus Lundblad via desktop-devel-list < desktop-devel-list@gnome.org> wrote: > Hi! > > As Mapbox has deprecated the old classic

Re: How to detect a gtk desktop programmatically

On Thu, 30 Apr 2020 at 17:23, Michael Catanzaro wrote: > I would worry about the future, though. I'm skeptical that updating to > GTK 4 will ever be possible (due to the removal of the foreign drawing > API that allows non-GTK apps to render boxes and buttons and such using > the GTK theme). So

Moving gdk-pixbuf-xlib out of gdk-pixbuf

Hi all; tl;dr: the gdk-pixbuf-xlib deprecated shared library now lives in its own, archived repository available at: https://gitlab.gnome.org/Archive/gdk-pixbuf-xlib If you're explicitly enabling X11 support in gdk-pixbuf in your builds and/or packages and distributing the additional

Re: Maintainers should announce build-related changes in their modules

On Thu, 12 Sep 2019 at 22:40, Philip Withnall wrote: > On Thu, 2019-09-12 at 19:14 +0100, Emmanuele Bassi wrote: > > On Thu, 12 Sep, 2019 at 19:08, Philip Withnall > wrote: > > That sounds like something people are going to forget to do. Would it be > possible to use computers to automate this?

Re: Maintainers should announce build-related changes in their modules

On Thu, 12 Sep 2019 at 23:49, Michael Gratton wrote: > On Thu, 12 Sep, 2019 at 22:39, Philip Withnall > wrote: > > On Thu, 2019-09-12 at 19:14 +0100, Emmanuele Bassi wrote: > >> On Thu, 12 Sep, 2019 at 19:08, Philip Withnall > >> wrote: > >>> That sounds like something people are going to

Maintainers should announce build-related changes in their modules

Hi all; the 3.34 release is out of the door, but before we go into the 3.35 development cycle, the release team would like to kindly ask **all** GNOME maintainers to send an email to release-t...@gnome.org (and possibly Cc: distributor-l...@gnome.org

Re: Proposal: Replace all references to master/slave in GNOME modules

On Fri, 26 Apr 2019 at 17:12, wrote: > > I'm a little surprised that nobody has yet mentioned the elephant in > the room. The definition of "git" is not very inclusive: > What did I say, upthread, about falling into the "slippery slope" fallacy, and sticking to the topic of discussion? Do we

Re: Proposal: Replace all references to master/slave in GNOME modules

. >> >> Regards, >> Chris >> >> On Thu, Apr 25, 2019 at 10:12 AM, Pat Suwalski wrote: >> >> On 2019-04-25 9:58 a.m., Emmanuele Bassi via desktop-devel-list wrote: >> >> If you cannot maintain even a semblance of a civil discourse, the door is >&g

Re: Proposal: Replace all references to master/slave in GNOME modules

On Thu, 25 Apr 2019 at 14:54, Pat Suwalski wrote: > On 2019-04-25 6:43 a.m., Bastien Nocera wrote: > > It's non-gender neutral, which was mentioned earlier in the thread. > > > > See the master/maiden section of: > > >

Re: I believe we should reconsider our sys-tray removal

On Mon, 25 Mar 2019 at 18:27, Florian Müllner wrote: > On Mon, Mar 25, 2019 at 6:50 PM Emmanuele Bassi wrote: > > > > You cut the part where I said the appindicator implementation should be > changed. :-) > > I thought you were referring to the client library, not the underlying > spec :-) >

Re: I believe we should reconsider our sys-tray removal

On Mon, 25 Mar 2019 at 17:34, Florian Müllner wrote: > On Mon, Mar 25, 2019 at 5:36 PM Emmanuele Bassi via desktop-devel-list > wrote: > > > > If the answer to status icons is to adopt/adapt the appindicator API, > I'm also fine with that; > > I'm not. The Statu

Re: I believe we should reconsider our sys-tray removal

On Mon, 25 Mar 2019 at 16:29, Will Thompson wrote: > On the other hand: this API under its various names is already > widely-supported both by (non-GNOME) apps, and by widely-used desktop > environments – a virtuous cycle. In particular, several third-party, > non-free apps like Dropbox which

Re: I believe we should reconsider our sys-tray removal

On Mon, 25 Mar 2019 at 16:15, wrote: The dash seems like it might be a safer place to put things > than allowing applications to clutter the precious top bar. > Like every other solution for placing stuff into the overview, this fails to take into account menus created by status icons; the

Re: I believe we should reconsider our sys-tray removal

On Mon, 25 Mar 2019 at 14:29, Pat Suwalski wrote: > On 2019-03-25 7:19 a.m., Emmanuele Bassi via desktop-devel-list wrote: > > Which would achieve nothing except, once again, shoving icons and menus > > into one of the most important pieces of screen real estate we have just &

Re: I believe we should reconsider our sys-tray removal

On Mon, 25 Mar 2019 at 10:39, Daniel Mustieles García via desktop-devel-list wrote: > Can't GtkStatusIcon be modified to show icons in the top bar? > No. GtkStatusIcon encodes the XEMBED-based tray icon specification; this means that the application code is responsible for: - sending icon

Re: What is the status of developer.gnome.org and help.gnome.org?

On Wed, 20 Feb 2019 at 17:27, Petr Kovar wrote: > > There's also a group of people wanting to do something else for the > > developer site. I went to some of their meetings, but haven't had time > > to keep up. I don't know their status. > > Same here. I think if the developer site group

Re: What is the status of developer.gnome.org and help.gnome.org?

Hi Joanne; the switch to Meson for various libraries broke the expectations of library-web, which is used to populate developer.gnome.org. The scripts expect the HTML for the API reference to be in the release tarballs, but that’s not the case for Meson-generated dist archives. GTK and GLib use

Re: GNOME 3.32 milestone review

On Wed, 30 Jan 2019 at 09:20, Allan Day via desktop-devel-list < desktop-devel-list@gnome.org> wrote: > Carlos Soriano wrote: > ... > > gnome-screenshot, retire app menu - Part of the GNOME initiative to > remove app menus. There is a MR, needs some review. Deadline 4th February, > UI freeze. >

Re: GNOME Online Accounts 3.34 won't have documents support

On Mon, 28 Jan 2019 at 11:40, Debarshi Ray wrote: > On Sun, Jan 27, 2019 at 12:13:26PM +, Emmanuele Bassi wrote: > > Again, not a huge deal; sure, Documents is actually useful to navigate > > through the Google Drive contents???the Drive web UX has become > shockingly > > bad over the years,

Re: GNOME Online Accounts 3.34 won't have documents support

On Sun, 27 Jan 2019 at 10:27, Debarshi Ray wrote: > The tl;dr here is that a lot of people care about political arguments > but nobody shows up to bear the burden of dealing with the code. > "Political" in the sense that you're not maintaining a leaf node in the dependency graph, that can come

Re: GNOME Online Accounts 3.34 won't have documents support

On Sun, 27 Jan 2019 at 09:24, Debarshi Ray wrote: > On Thu, Jan 24, 2019 at 11:00:58AM +0100, Bastien Nocera wrote: > > I don't think that feature requests should be treated on the same level > > as existing, merged, features > > I can't change my theme, I can't change my fonts, no minimize

Re: GNOME Online Accounts 3.34 won't have documents support

On Wed, 23 Jan 2019 at 18:36, Debarshi Ray wrote: > On Wed, Jan 23, 2019 at 02:49:55PM +0000, Emmanuele Bassi via > desktop-devel-list wrote: > > On Wed, 23 Jan 2019 at 14:21, Allan Day wrote: > > > If apps could provide their own keys that would certainly change the &g

Re: GNOME Online Accounts 3.34 won't have documents support

On Wed, 23 Jan 2019 at 17:55, wrote: > On Wed, Jan 23, 2019 at 9:03 AM, Bastien Nocera > wrote: > > It is what is happening in GNOME Online Accounts in general. Pocket is > > disabled in Fedora 29, and there's a good chance that the mail > > configuration bits will be disabled in Fedora 30. > >

Re: GNOME Online Accounts 3.34 won't have documents support

On Wed, 23 Jan 2019 at 16:41, Allan Day wrote: > Emmanuele Bassi wrote: > ... > >> > This is because we never specified a way to get third party keys > stored inside GOA as part of a process to get third party modules to it. > >> > >> If apps could provide their own keys that would certainly

Re: GNOME Online Accounts 3.34 won't have documents support

On Wed, 23 Jan 2019 at 14:21, Allan Day wrote: > [Responding selectively, this thread is getting long.] > > Emmanuele Bassi wrote: > ... > >> The main factor has always been about how we handle identity. If we > >> give online accounts access to 3rd party apps, we're giving them > >> access to

Re: GNOME Online Accounts 3.34 won't have documents support

On Wed, 23 Jan 2019 at 12:26, Allan Day wrote: > Emmanuele Bassi wrote: > ... > >> This approach isn't new, and you can read more detail here: > >> https://wiki.gnome.org/Projects/GnomeOnlineAccounts/Goals > >> > > > > I know the rationale. I never particularly agreed with it, because it > felt

Re: GNOME Online Accounts 3.34 won't have documents support

On Mon, 21 Jan 2019 at 16:32, wrote: > We have a rule though: the account types exposed in > gnome-online-accounts must be used by at least one core application. > It's a good rule because it doesn't make sense to have settings in > control-center for apps that aren't installed by default. So

Re: Documents and core apps

On Thu, 17 Jan 2019 at 16:59, wrote: > Release and design teams also don't want redundant apps in core, and > there is interest in somewhat reducing the number of apps in core. We > had been planning for several years to remove eog (obsoleted by > gnome-photos and to remove evince with

Re: GNOME Mastodon Instance?

On Wed, 31 Oct 2018 at 10:27, Alexandre Franke wrote: > On Mon, Oct 15, 2018 at 3:20 PM Emmanuele Bassi via desktop-devel-list > wrote: > > Just to be clearer: once the GNOME Mastodon instance gets into a > federation, it'll need somebody to moderate > > the graph to bloc

Re: This video is dedicated to all of you

On Wed, 17 Oct 2018 at 18:30, Bastien Nocera wrote: > On Wed, 2018-10-17 at 19:24 +0200, Alberto Salvia Novella via desktop- > devel-list wrote: > > https://youtu.be/ > > How is this person still allowed to post on d-d-l? > Yes, can we please enable some moderation? Not only this stuff is

Re: GNOME Mastodon Instance?

Just to be clearer: once the GNOME Mastodon instance gets into a federation, it'll need somebody to moderate the graph to block instances and users from other instances in the fediverse. I'm not (overly) worried about people with an @gnome.org address on the GNOME instance, and for those we do

Re: GNOME Mastodon Instance?

Hi Richard; I wouldn't be opposed to have a mastodon.gnome.org instance for GNOME foundation members, but I'm not entirely sure about the security/moderation side of things: who's going to moderate the instance? We have people moderating mailing lists and a some level of moderation on IRC, but