Re: Regarding behaviour of Gnome and Fedora members

> On Jun 12, 2020, at 7:53 AM, Ty Young via desktop-devel-list > wrote: > > "also, I'd recommend getting anger management classes, because you're one > step away from throwing bricks into and looting independently owned > small-businesses, staging an insurrection, declaring an autonomous

Re: Changes to GitLab runners configuration

On 3/21/20 12:09 PM, Philip Chimento via desktop-devel-list wrote: > > I'd really appreciate if we could find a way to have the unprivileged > runners have CAP_SYS_PTRACE added to them. Those words sound incompatible to me in the same way that if you have access to Linux's perf, you can sniff

Re: Matrix IRC bridge considered harmful

On 2/12/20 4:15 PM, Britt Yazel wrote: > > If I remember correctly our conversation last month, you said you didn't > want a web browser open as it provided tabs to distractions. At which > point I mentioned the electron Flatpak (which contains no such tabs), > but you weren't having it. I share

Re: Matrix IRC bridge considered harmful

On 2/12/20 3:32 PM, Britt Yazel wrote: > Can you explain to me what the big issue with web clients are? I keep > hearing over and over again that developers don't want to use web > clients, either in browser or with Electron, but I don't recall ever > hearing a "why" in there. I'll repeat what I

Re: GJS Docs now Hosted on gnome.org

On 7/11/19 11:27 AM, Philip Chimento via desktop-devel-list wrote: Unfortunately not possible right now! IIRC, the GNOME Builder team has been looking for someone to volunteer to work on a language server to get autocomplete support for JS. I don't know the bug number but the gnome-builder

Re: Please check your module is not using deprecated python2, gnome-common, intltool

On 04/07/2019 04:42 AM, Bastien Nocera wrote: That's going to be a tough ask given the discussion in: https://gitlab.gnome.org/GNOME/libpeas/merge_requests/5 TL;DR: The maintainer is AWOL but doesn't want help. Would be interesting for the release team to step in. This is not true. There are

Re: GitLab postmortem

On 12/11/18 5:22 AM, Carlos Soriano wrote: > > Please keep the mail chain one way from you towards the world, so we > don't get trapped on specifics, we can address stuff raised here > individually out of list. Personally, I'll ping you on IRC or so if I > can do something to help. We have issue

Re: Retiring app menus - planning for 3.32.0

On 09/21/2018 12:08 PM, Tomasz Torcz wrote: > Going extra mile to “find” shortcut is never gonna fly. Years ago, we > had a perfect solution for discovering shortcuts – relevant letters > were underlined in the menus. In some cases underlining appeared only > after Alt was pressed, which was

Re: Retiring app menus - planning for 3.32.0

On 09/21/2018 11:43 AM, Shaun McCance wrote: > Can you elaborate on this? One of the goals of Mallard is to allow > plugin docs to integrate into the main app docs. Is there something we > could be doing better? Advertise the feature? :) Does it work when they are installed into different

Re: Retiring app menus - planning for 3.32.0

On 09/21/2018 04:24 AM, Allan Day wrote: > This would reduce > the number of menu items, allows cross-linking, and so on. This doesn't work well for situations where plugins are in play because those don't integrate cleanly into the documentation. However, the keyboard shortcuts window can handle

Re: Retiring app menus - planning for 3.32.0

On 09/20/2018 02:19 AM, Allan Day wrote: > I've written some updated guidelines for the initiative > , > and I'd appreciate it if people could check them over. >From the link: > "There is no need for the Quit menu item and the

Re: Desktop miniconf @ Linux Plumbers Conference

On 05/09/2018 02:59 PM, Sriram Ramkrishna wrote: > So If there is sufficient interest, I will volunteer my time to run the > miniconf this year.  Those of you who have items worth discussing can > think of talks we can present to a diversified audience. Some avenues of discussion/talks that come

Re: g_object_ref() now propagates types

On 12/08/2017 03:26 AM, Philip Withnall wrote: child_type = CHILD_TYPE (g_object_ref (parent_type)); Or my personal preference: g_object_ref (CHILD_TYPE (parent_type)) I was skeptical that this would catch many issues, but it actually caught a copy pasta for me a couple of days ago with

Re: GNOME Modulesets migrating to BuildStream

On 11/10/2017 12:46 AM, Tristan Van Berkom wrote: I'm sorry that out of the many things I have to juggle, I had never considered Builder compatibility to be a blocker for the GNOME release team to start maintaining GNOME builds in a new format, this does strike me as an unreasonable requirement.

Re: GNOME Modulesets migrating to BuildStream

On 11/09/2017 03:20 AM, Tristan Van Berkom wrote: . This cut off wont happen in 2017, but will happen before the release of GNOME 3.28 stable. From now on, we will be creating the development releases using BuildStream. I'm all for seeing the BuildStream conversion happen. But I do have some

Re: GNOME Build situation and BuildStream

On 04/25/2017 09:38 AM, Tristan Van Berkom wrote: > Any questions about what we have created so far and how it works ? Please > reply and ask about these ! I don't think this was mentioned, apologies if I missed it. One thing we want in Builder is a simulator. Being able to take a BuildStream

Re: GNOME goal candidates

On 02/28/2017 04:05 PM, Michael Catanzaro wrote: Regarding installed tests. The benefits of installed tests versus make check tests are not very clear to me. I don't think it should be necessary to install the tests in order to be able to run and test applications. That indicates a failure

Re: Improving the way we build nightly apps

On 02/28/2017 03:18 PM, Michael Catanzaro wrote: On the other hand, these manifests should hopefully be obsoleted soon by BuildStream. The goal of that effort is to remove the separate Continuous manifest, JHBuild moduleset, and flatpak nightlies repos. So if we implement this now, we'd be

Re: Librsvg 2.41.0 is released

On 01/12/2017 08:11 AM, Federico Mena Quintero wrote: > How does one get this to happen? > > Is it only a problem if two threads race to pass the same type_name to > g_type_register_*()? > > Or if a library defines a shitty foo_get_type() without the g_once > magic from G_DEFINE_TYPE(), and

Re: Librsvg 2.41.0 is released

On 01/11/2017 04:06 PM, Federico Mena Quintero wrote: > How would you write a correctness test for this? Or what specific set > of conditions would cause an error here? Not sure, its a runtime error you would see when a downstream would try to register an already registered GType. > Librsvg

Re: Librsvg 2.41.0 is released

On 01/05/2017 07:25 PM, Adrian Perez de Castro wrote: > Could you elaborate on what's the issue with gtk-rs? The way things work, the > code from it will be statically linked into librsvg, and if librsvg uses > actual {GTK+,GLib,cairo} functions, then librsvg links *dynamically* to >

Re: Script to format the functions in a C header?

On 11/23/2016 05:03 AM, Sébastien Wilmet wrote: Also, in the GNOME convention there is something that I don't like and that I would prefer not to do: aligning all the parameter names on the same column (the third column). I prefer aligning the parameter names for each function separately, IMHO

Re: Script to format the functions in a C header?

On 11/23/2016 05:38 AM, Leslie S Satenstein via desktop-devel-list wrote: Can someone tell me what is wrong with using the *indent* program? indent does not fully support our style, nor does it align groups of functions to add space so functions are aligned as a group.

Re: Script to format the functions in a C header?

On 11/21/2016 11:01 AM, Sébastien Wilmet wrote: Ok, thanks, I can look at clang-format if it supports the GNOME/GTK+ convention for formatting function prototypes in a header. Last I tried clang-format it couldn't format our reference alignment rules in function prototypes. Uncrustify could

Re: Ok to release GtkSourceView 3.24 in a few weeks?

On 10/24/2016 11:28 AM, Michael Catanzaro wrote: It might be less confusing to call it GtkSourceView 3.22.2, and just accept that it will have rather bigger changes than are typical for a stable release. I think this is a good idea as well. Especially if it's primarily deprecation warnings.

Re: UX features for 3.24

On 10/18/2016 10:44 AM, Krzesimir Nowak wrote: Not sure how can this pan out - I guess that stable release is in bugfixes-only mode, so the widgets could land only in Gtk4. GNOME modules probably won't quickly switch to it, right? GNOME modules will likely be the first projects to move to

Re: Problems regarding jhbuild

On 10/10/2016 12:33 PM, Abishek Kumar wrote: *** Checking out vala *** [20/30] git remote set-url origin git://git.gnome.org/vala git remote update origin Fetching origin git rebase origin/0.34 Current branch 0.34 is up to date. *** Configuring vala *** [20/30]

Re: Multi DPI user interface

On 07/19/2016 07:40 PM, Jonas Ådahl wrote: > I think as far as API's go, we should use D-Bus API that provides a > screen record session where the actual video frames are passed using > pinos. That API shoulda definitely be per monitor to minimize any > processing done in the compositor process.

Re: Multi DPI user interface

On 07/19/2016 12:21 PM, Ray Strode wrote: > On Tue, Jul 19, 2016 at 11:04 AM Jonas Ådahl wrote: >> > 2) Represent each monitor separately, generating one file for each > This makes the most sense to me. Or even only do the active monitor. > > Of course for screen recording

Re: Continuous Builds in GNOME

On 06/06/2016 01:35 PM, Sriram Ramkrishna wrote: > I would think the docs team would be also interested. I wonder if we > could create coverage maps using this.. Generally the docs team doesn't write API documentation, but I certainly wouldn't turn anyone away that wants to write API docs for

Re: Continuous Builds in GNOME

On 06/06/2016 01:02 PM, Christian Hergert wrote: > A couple weeks ago I wrote a quick hack to parse Continuous build logs > and extract CFLAGS for the built files. It can use this to then go > perform static analysis on the module with clang and extract/resolve all > fu

Re: Continuous Builds in GNOME

On 06/06/2016 12:48 PM, Michael Catanzaro wrote: > I agree with you that when landing a big API change, if you don't want > to use side branches, then a revert is less preferable to tagging in > Continuous and branching in jhbuild. (In such cases, it'd be great if > you could handle that before

Re: upcoming "systemd --user" dependency in gnome-settings-daemon

On 05/12/2016 07:06 PM, Bastien Nocera wrote: > So, I intend to use systemd to launch each gnome-settings-daemon plugin > as a separate service, which would be tracked, and relaunched through > "systemd --user": We do a fair bit of subprocess launching/tracking in Builder with private DBus for

Re: GTK+ plans for 3.22

On 04/26/2016 12:44 PM, Adam Jackson wrote: > Who are the first consumers likely to be? One thing I'd like to consider is using it to revamp scrolling in textview. Right now our profiles are dominated by pixman (obviously) doing the pixelcache copies and it might be interesting to be able to do

Re: gettext

On 04/22/2016 10:08 AM, Sébastien Wilmet wrote: > On Fri, Apr 22, 2016 at 08:39:33AM -0500, Michael Catanzaro wrote: >> > We really need an intltool -> pure gettext transition guide, if anyone >> > feels up for taking that on, because it's not at all clear how this is >> > supposed to work. >

Re: GTK+ plans for 3.22

On 03/17/2016 08:56 AM, Michael Catanzaro wrote: > On Thu, 2016-03-17 at 09:17 -0400, Matthias Clasen wrote: >> > - A tab bar widget for GtkStack >> > >> > Another widget that Christian is prototyping for gnome-builder. We've >> > wanted such a thing in GTK+ for a while, to be able to fully

Re: GTK+ plans for 3.22

On 03/17/2016 01:16 PM, Ben wrote: > On Thu, 2016-03-17 at 09:17 -0400, Matthias Clasen wrote: >> > - A better paned widget >> > >> > Christian Hergert is prototyping a paned widget which can handle more >> > than 2 children for use in gnome-builder. It look

Builder 3.22 Planning

# Builder 3.22 Planning We have a pretty aggressive roadmap for 3.22, and so it's time to get involved if any of this interests you. ## Project and File Templates Now that the plumbing has landed for templates, it's time to propagate that into the UI for 3.22. We need to allow the users to