gedit crowdfunding

Hi, There is now a crowdfunding for gedit! See my blog post: https://swilmet.be/blog/2020-10-13-gedit.html The link to Liberapay: https://liberapay.com/gedit/ I plan to write blog posts more frequently about gedit, and around gedit (the work that I do in related libraries). - I've posted

Re: Wrong links in the gnome developer documentation

Hi, On Mon, Mar 23, 2020 at 09:59:12PM +0100, Uwe Scholz wrote: > where can I ask for correction of wrong links in the gnome developer > documentation? > > In particular, I wanted to report that various links on > https://developer.gnome.org/gtk3/stable/GtkFileChooserButton.html are > pointing

Re: GtkSourceView 4.0 released

On Mon, May 07, 2018 at 09:03:22AM +0200, Jens Georg wrote: > > GtkSourceView 4.0 has been released with GNOME 3.28 in March. It still > > depends on GTK+ 3. The port is trivial (it's mostly just getting rid of > > deprecated APIs): > >

GtkSourceView 4.0 released

Hi, GtkSourceView 4.0 has been released with GNOME 3.28 in March. It still depends on GTK+ 3. The port is trivial (it's mostly just getting rid of deprecated APIs): https://developer.gnome.org/gtksourceview/stable/porting-guide-3-to-4.html In gnome-build-meta I see the following modules still

Re: Create high-level UI widget library

On Tue, Apr 24, 2018 at 06:38:36PM +, Victor Malov wrote: > I think there is need for some high-level UI library, based on GTK, which > will provide ready-to-use widgets for Gnome Desktop and applications > willing tightly integrate into Gnome. It depends on what you need, but there are

Re: GitLab, moving non-GNOME projects currently hosted on git.gnome.org

On Thu, Feb 15, 2018 at 11:57:07AM -0600, Michael Catanzaro wrote: > On Thu, Feb 15, 2018 at 10:23 AM, Sébastien Wilmet <swil...@gnome.org> > wrote: > > Isn't there a better solution? What do you recommend? > > FWIW, the GNOME group already contains a *lot* of modules

GitLab, moving non-GNOME projects currently hosted on git.gnome.org

Hi, I would like to move all the projects I maintain to gitlab.gnome.org. Currently those projects are hosted on git.gnome.org, but not all of them are officially part of GNOME. When looking at: https://gitlab.gnome.org/explore/groups the best group that fits is "Incubator", but I'll probably

Re: Let's kill gnome-common!

On Mon, Feb 12, 2018 at 07:08:34PM -0600, mcatanz...@gnome.org wrote: > I want to remove gnome-common from our BuildStream projects, but a few > modules are still depending on it: gcr, gnome-autoar, libnotify, > adwaita-icon-theme, gnome-menus, and gsettings-desktop-schemas. The list is not

Re: [GitLab] Projects moved, tips of the week and question of the week

On Fri, Jan 26, 2018 at 12:17:56PM +0100, Niels De Graef wrote: > Yes, it is already on version 10.4. > > You can check the current version on https://gitlab.gnome.org/help > (also available by clicking your avatar on the upper-right corner and > clicking "Help"). Ah great. When we are not

Re: [GitLab] Projects moved, tips of the week and question of the week

Hi, Is gitlab.gnome.org already using GitLab 10.4 with the rebase + fast-forward? https://about.gitlab.com/2018/01/22/gitlab-10-4-released/#rebase-and-fast-forward-in-ce On gitlab.gnome.org I don't know where or if we can see which GitLab version is used. Thanks, Sébastien

Re: Release team now using gnome-build-meta repository, not JHBuild

On Wed, Jan 24, 2018 at 02:28:26AM +0200, Alberts Muktupāvels wrote: > Sorry if that already is posted somewhere, but is there at least some kind > of migration guide/tutorial? See the first e-mail of this thread. -- Sébastien ___ desktop-devel-list

Re: Transmitter - GUI for transmission-daemon and transmission-remote

On Sat, Dec 30, 2017 at 06:46:38PM -0500, Patrick Griffis via desktop-devel-list wrote: > and you already get the free infrastructure with the GNOME gitlab now I think that gitlab.gnome.org alone is not sufficient to host a project, for example is there a way to upload tarballs? I think that

Spell-checking, porting modules to Enchant 2

Hi, Enchant has a new maintainer (Reuben) and the project is again under development. Enchant 2 is available since several months (the last version, Enchant 1.6, was released in 2010). I've ported gspell to Enchant 2, this didn't require any code change at all. In most cases porting to Enchant 2

Re: Meson feedback as a user - AX_COMPILER_FLAGS

On Sun, Jul 02, 2017 at 05:29:21PM +0200, Sébastien Wilmet wrote: > The same for compiler flags, with the Autotools there is the > AX_COMPILER_FLAGS macro. With meson it seems that the flags are listed > in each GNOME module. I've opened this issue to have the equivalent of AX_COMPI

Re: GNOME Modulesets migrating to BuildStream - clang completion in text editor

On Fri, Nov 24, 2017 at 03:16:09PM +0900, Tristan Van Berkom wrote: > Had not considered this use case yet, thanks ! > > I'm an emacs user but have never used any kind of symbol completion > feature myself. > > For this, one could use `bst checkout` to get a full checkout of the > build outputs

Re: GNOME Modulesets migrating to BuildStream - clang completion in text editor

Hi, I've tried a little BuildStream, but I think I'll hit a problem if I don't use jhbuild anymore: have clang completion in my preferred text editor, it needs all the *.h files of dependent libraries. Currently those *.h files are either installed by Linux distro packages, or by jhbuild in the

Re: Include GNOME Usage in the future releases

On Wed, Oct 18, 2017 at 12:11:02PM +0200, Felipe Borges wrote: > On Wed, Oct 18, 2017 at 11:57 AM, Sébastien Wilmet <swil...@gnome.org> wrote: > > Is it really a chicken-egg dilemma? Are the crashes and bugs specific to > > some hardware or underlying software configura

Re: Include GNOME Usage in the future releases

On Mon, Oct 16, 2017 at 05:47:29PM +0200, Felipe Borges wrote: > On Mon, Oct 16, 2017 at 5:19 PM, Adrien Plazas > wrote: > > During my quick test I encountered many crashes. The application would > > benefit from broader testing and including it as a demo version in a

Re: Proposal to deploy GitLab on gnome.org

On Mon, Sep 25, 2017 at 09:03:00PM +0200, Tobias Mueller wrote: > On Mi, 2017-05-17 at 14:21 +, Zbigniew Jędrzejewski-Szmek wrote: > > On Wed, May 17, 2017 at 01:49:21PM +0200, Sébastien Wilmet wrote: > > > By attaching a patch to a bugtracker ticket, we loo

Re: Build and run gnome-shell in a Docker container

Hello Reto, On Sat, Sep 23, 2017 at 10:40:04PM +, Reto Kaiser wrote: > I'm new to gnome, and it took me quite some time to build and run > "gnome-shell" with "jhbuild", but I finally made it. > > For having a reproducible environment that can be thrown away and recreated > if needed, I

Iterative API design (Was: Re: Matrix as a replacement for Telepathy)

On Fri, Aug 25, 2017 at 10:21:07AM -0500, Gary Kramlich wrote: > > Release 3.0? :) > > I know, need more hours in the day :-/ I'll spend some time this > putting together a 3.0 checklist, but it's not going to be pretty.. > > > Seriously, all that nice GObjectification cleanup does make it a

Re: Matrix as a replacement for Telepathy

On Fri, Aug 25, 2017 at 11:28:34AM -0500, Michael Catanzaro wrote: > I think what's clear right now is that Telepathy has no future and should be > immediately removed from our stack. We should have done that years ago when > maintenance ceased. Maybe Telepathy and Empathy have

Re: Updating GNOME Goals?

On Thu, Aug 24, 2017 at 09:45:18AM +0200, Daniel Mustieles García wrote: > Great, one less step. > > Then, it's ok to move this goal to the Deprecated Section? We could include > the link in the goal comments RemoveMarkupInMessages should not be moved to the Deprecated section, it should simply

Re: Updating GNOME Goals?

On Thu, Aug 24, 2017 at 09:20:45AM +0200, Daniel Mustieles García wrote: > have doubts about AddCodeCoverage, DistCheck. - Meson instructions should be added for AddCodeCoverage. - DistCheck is specific to Autotools. ___ desktop-devel-list mailing list

Re: Updating GNOME Goals?

On Tue, Aug 22, 2017 at 11:57:27AM -0500, Michael Catanzaro wrote: > On Tue, Aug 22, 2017 at 4:46 AM, Sriram Ramkrishna > wrote: > > Has anybody looked at the GNOME Goals[1] lately? Is this still > > something that is active? I only ask as I know at least some that seem > >

Re: GitLab migration status and roadmap

On Fri, Aug 11, 2017 at 08:48:34PM +0200, Carlos Soriano wrote: > Bugs can be migrated with https://gitlab.com/aruiz/gitlab-gnome-tools, is > up to the maintainer what to do with them. OK, and when the full migration will be done for all GNOME modules, do you already know if that script will be

Re: GitLab migration status and roadmap

On Fri, Aug 11, 2017 at 02:37:41PM +0200, Carlos Soriano wrote: > As usual, feel free to ask any questions in this thread or personally to > Alberto Ruiz or me, we are happy to answer. Are all the bugs on bugzilla also migrated when a module moves to GitLab? How is that handled currently? --

Re: developer.gnome.org and meson

On Wed, Aug 09, 2017 at 09:03:36PM +0100, Emmanuele Bassi wrote: > > (and it would be painfully slow, it takes several > > hours on my machine to generate the GTK+ docs). > > Distributions typically use something slightly more beefy than a > typical PC hardware for their builds. They have also

Re: developer.gnome.org and meson and devhelp

On Wed, Aug 09, 2017 at 08:33:09AM -0500, mcatanz...@gnome.org wrote: > developer.gnome.org is going to have some problems because for meson modules > 'ninja dist' does not include generated gtk-doc files in the tarball. At > least one maintainer is working around this by manually generating

Re: developer.gnome.org and meson

On Wed, Aug 09, 2017 at 03:20:38PM +0100, Emmanuele Bassi wrote: > After all, Linux > distributions rebuild the documentation when building the binary > packages anyway I see that in the gspell-doc package on Fedora 26, some html pages have links to /home/seb/jhbuild/... (a problem with the

Re: Meson feedback as a user

On Thu, Jul 06, 2017 at 05:41:11PM +0200, Mattias Bengtsson wrote: > On Sun, 2017-07-02 at 17:39 +0200, Sébastien Wilmet wrote: > > My main point of my email was that the Meson documentation should be > > split in two or three IMHO: > > - Simple user doc, how to build a pr

Re: Meson feedback as a user

On Sun, Jul 02, 2017 at 04:10:45PM +0200, Iñigo Martínez wrote: > You can also use mesonconf, which will show you all the available options, > even those present in the meson_options.txt file along with their possible > values. > > To activate those options, you can use either meson or

Re: Meson feedback as a user

On Sun, Jul 02, 2017 at 03:21:51PM +0100, Sam Thursfield wrote: > On Sun, Jul 2, 2017 at 1:27 PM, Sébastien Wilmet <swil...@gnome.org> wrote: > > Out of curiosity, let's look at other GNOME-related modules that use > > gtk-doc. What is the name of the option that enables

Meson feedback as a user

Hi, I don't want to learn Meson yet as a maintainer. Just as a user to build some GNOME modules that now require Meson. It seems that the Meson docs are now more focused for maintainers, not users. What was great with the Autotools is that it was easy to use, as a user: INSTALL file with all the

Re: Renaming a project

On Sun, Jun 11, 2017 at 09:22:56AM -0400, Jeremy Bicha wrote: > On Sun, Jun 11, 2017 at 7:15 AM, Sébastien Wilmet <swil...@gnome.org> wrote: > > - What to do about the git repo? Creating a new repo with the new name > > and placing the old one in the deprecated section? &

Renaming a project

Hi, I would like to rename Gtef (GTK+ text editor framework) to Tepl (Text editor product line). I don't really like the name Gtef. https://wiki.gnome.org/Projects/Gtef - The wiki page can easily be renamed, with a redirection for the old page. - What to do about the git repo? Creating a new

Re: Proposal to deploy GitLab on gnome.org

On Wed, May 17, 2017 at 02:21:55PM +, Zbigniew Jędrzejewski-Szmek wrote: > On Wed, May 17, 2017 at 01:49:21PM +0200, Sébastien Wilmet wrote: > > By attaching a patch to a bugtracker ticket, we loose the information of > > the parent commit: where the commit has been in

Re: Relicensing Nautilus to GPLv3+

On Sun, May 28, 2017 at 03:20:49PM +0200, Bastien Nocera wrote: > On Thu, 2017-05-25 at 12:08 +0200, Sébastien Wilmet wrote: > > For LGPL -> GPL, you need the explicit approval of all copyright > > holders. > > No, you don't. It says right in the license that you can u

Re: Relicensing Nautilus to GPLv3+

On Thu, May 25, 2017 at 06:10:56AM -0400, Carlos Soriano wrote: > I still get different opinions from different people on that. But that > makes sense to me. Probably makes sense to relicense the files too at > some point, but that would be a later decision. > Do you know any advantage of

Re: Relicensing Nautilus to GPLv3+

On Thu, May 25, 2017 at 05:59:02AM -0400, Carlos Soriano wrote: > For now we won't relicense the files, since that would require > copyright holders to agree (iiuc). Instead is the project that will > become GPL3+, since the combination of GPL2+ + GPL3+ files results in > a project that is GPL3+.

Re: Relicensing Nautilus to GPLv3+

Hi, Just to mention that I've written two scripts that ease changing license headers: - gcu-multi-line-substitution - gcu-smart-c-comment-substitution available at: https://github.com/swilmet/gnome-c-utils Cheers, Sébastien ___ desktop-devel-list

Re: Proposal to deploy GitLab on gnome.org

On Wed, May 17, 2017 at 11:45:26AM +0200, Bastien Nocera wrote: > On Wed, 2017-05-17 at 11:33 +0200, Sébastien Wilmet wrote: > > > > > Most developers are more familiar with the GitHub workflow, I think > > it's > > an easier workflow than attaching a patch to

Re: Proposal to deploy GitLab on gnome.org

On Tue, May 16, 2017 at 11:15:51PM +0900, Tristan Van Berkom wrote: > I don't share your optimism about gitlab bug tracking, nor do I share > in the mentioned frustration with bugzilla. Me too, I like bugzilla (but not for doing code reviews). What would be the pain points if GitLab is used

Re: Proposal to deploy GitLab on gnome.org

On Wed, May 17, 2017 at 01:42:15AM +0200, Jehan Pagès wrote: > Github/gitlab wants to force you to fork the project into a public > repository on your private account so that you can make a pull > request. This is seriously stupid IMO and very poor workflow. That's > the reason why github/gitlab

Hosting Paperwork on gnome.org

On Mon, May 01, 2017 at 02:51:42PM +0200, Jerome Flesch wrote: > Assuming this is actually a good fit for Gnome, I'm not sure where to > start either. Any indications would be welcome. Paperwork is at least a good fit for hosting it on gnome.org. Some projects are hosted on gnome.org without

Re: GNOME Build situation and BuildStream

On Thu, Apr 27, 2017 at 11:21:37PM +0900, Tristan Van Berkom wrote: > On Thu, 2017-04-27 at 14:41 +0200, Sébastien Wilmet wrote: > [...] > > With jhbuild, when we enter into a jhbuild shell we are still in the > > same directory, usually inside the git repository. With builddi

Re: GNOME Build situation and BuildStream

Hi Tristan, For application or library developers (libraries used by applications), I'm a bit struggling to see what the workflow will look like with BuildStream. I've described two examples of my current workflow in this mail:

Re: GNOME goal candidates

On Wed, Mar 01, 2017 at 10:31:24AM +, Philip Withnall wrote: > On Tue, 2017-02-28 at 17:12 -0600, Michael Catanzaro wrote: > > GtkBuilder validation looks like more gook to add to our Automake > > files, when we really want less gook there. Even if it's only a small > > amount of code, I'd

Re: Develop of gnomeradio

Hi George, You were apparently not subscribed to the mailing list, your email has appeared on the mailing list only today. On Thu, Feb 16, 2017 at 02:31:22PM +0200, George Pojar wrote: > I took gnomeradio from archive in GNOME git [ > https://git.gnome.org//browse/archive/gnomeradio ] and

Re: gtk-doc goes python

On Thu, Mar 30, 2017 at 09:51:27PM +0200, Stefan Sauer wrote: > as a heads up - Jussi Pakkanen and I are rewriting gtkdoc to python. The > shell scripts are already gone (so running gtkdoc won't need a shell > anymore). At the same time we're modernizing it a bit and adding more > and proper

Re: GNOME 3.25/3.26 Schedule available

On Wed, Apr 05, 2017 at 12:18:44PM +0200, Andre Klapper wrote: > On Wed, 2017-04-05 at 11:13 +0200, Sébastien Wilmet wrote: > > Is it intentional that the development cycle lasts 25 weeks instead > > of 26? > > > > 365.25 / 7 = 52.18 weeks/year in average. So 26 or 2

Re: GNOME 3.25/3.26 Schedule available

Hi, On Wed, Mar 29, 2017 at 05:05:14PM +0200, Andre Klapper wrote: > the release schedule for GNOME 3.25/3.26 is out: > >    https://wiki.gnome.org/ThreePointTwentyfive Is it intentional that the development cycle lasts 25 weeks instead of 26? 365.25 / 7 = 52.18 weeks/year in average. So 26 or

Re: Do not use -Werror by default in your modules without joining #testable

On Sun, Apr 02, 2017 at 06:22:07PM +0100, Emmanuele Bassi wrote: > On 2 April 2017 at 18:16, Michael Catanzaro wrote: > > On Sun, 2017-04-02 at 15:59 +0100, Emmanuele Bassi wrote: > >> Adding: > >> > >> disable_Werror = False > >> > >> to your jhbuildrc should do the

Re: Do not use -Werror by default in your modules without joining #testable

On Sun, Apr 02, 2017 at 07:21:38PM +0200, Sébastien Wilmet wrote: > 1) This warning: comparison between signed and unsigned integer. After a bit more thoughts, I see one flaw in my reasoning, because GCC triggers the above warning depending on the architecture it is building for. When the ARM

Re: Do not use -Werror by default in your modules without joining #testable

On Sun, Apr 02, 2017 at 09:53:41AM -0500, Michael Catanzaro wrote: > Simplest solution would be for Continuous to just pass --disable-Werror > to configure. OTOH I'm willing to change the Epiphany behavior if you > don't agree, but it's baked into use of AX_IS_RELEASE([git-directory]) > and

Re: Do not use -Werror by default in your modules without joining #testable

On Sun, Apr 02, 2017 at 04:52:49PM +0100, Emmanuele Bassi wrote: > You seem to misunderstand what a continuous delivery/continuous > integration pipeline is for. I think I understand what a CI server is for, I simply disagree with you. Let's compare two scenarios: 1) This warning: comparison

Re: Do not use -Werror by default in your modules without joining #testable

On Sun, Apr 02, 2017 at 03:59:39PM +0100, Emmanuele Bassi wrote: > The point of my email was, though, that people should be keeping an > eye on their modules on the CD pipeline. It's easier to keep an eye on our local compilation output, and rebuild from time to time the dependencies in jhbuild.

Re: Hosting Gtef on gnome.org

On Fri, Mar 10, 2017 at 08:42:23AM -0600, Michael Catanzaro wrote: > Seems like a perfect candidate for git.gnome.org. Be sure to update > JHBuild and Continuous. > > https://openclipart.org/image/800px/svg_to_png/195669/Traffic-light.png Thanks! The git repo is now created, I'll go through the

Re: Improving the way we build nightly apps

On Tue, Feb 28, 2017 at 05:18:55PM -0600, Michael Catanzaro wrote: > On Tue, 2017-02-28 at 11:44 -0500, Matthias Clasen wrote: > > So far, we have this gnome-nightly-apps repository which contains > > copies of the flatpak manifests for a bunch of gnome apps. That is > > redundant and suboptimal.

Re: GNOME goal candidates

On Thu, Mar 02, 2017 at 08:58:26AM -0600, Michael Catanzaro wrote: > On Thu, 2017-03-02 at 12:36 +0100, Sébastien Wilmet wrote: > > I can take ownership of: > > https://wiki.gnome.org/Initiatives/GnomeGoals/AddCodeCoverage > > > > I will update the description.

Re: GNOME 3.23.91

On Thu, Mar 02, 2017 at 07:37:12AM -0500, Matthias Clasen wrote: > The release notes that describe the changes between 3.21.90 and 3.21.91 > are available. Go read them to learn what's new in this release: > > core - https://download.gnome.org/core/3.21/3.23.91/NEWS > apps -

Re: GNOME goal candidates

On Wed, Mar 01, 2017 at 03:12:17PM -0600, Michael Catanzaro wrote: > On Wed, 2017-03-01 at 14:22 -0500, Carlos Soriano via desktop-devel- > list wrote: > > I think installed test etc it's not going to happen or be maintained > > if we don't enable coverage with it too. I think that's the actual >

Re: GNOME goal candidates

On Wed, Mar 01, 2017 at 08:31:24AM -0600, Michael Catanzaro wrote: > OK, you all have changed my mind. I guess installed tests should be a > goal. > > Do we want to do this for coverage as well...? https://wiki.gnome.org/Initiatives/GnomeGoals/AddCodeCoverage The page needs to be updated for

Re: GNOME goal candidates

On Wed, Mar 01, 2017 at 07:26:19AM -0600, Michael Catanzaro wrote: > This is the other thing. The goals should be achievable, something we > can look at in a year or two and say "all apps meet the goal" and close > it, not a longstanding epic that stays open forever. The installed > tests and

Re: Hello && About Maintainership of Gtranslator

On Wed, Feb 15, 2017 at 11:27:25PM +0300, Muhammet Kara wrote: > I have been using gtranslator for years, and I love it. Lack of updates on > gtranslator has been bugging me for quite some time, and I have decided to > take action after seeing it on the Unmaintained list.[0] > > I would like to

Re: Equivalent of recursive make with meson/ninja?

On Sat, Feb 11, 2017 at 03:58:54PM +, Tim-Philipp Müller wrote: > Dunno, for me the fact that gtk-doc is so slow is extremely annoying in > my normal dev workflow, especially when it rebuilds the docs just > because I or someone else touched a source file somewhere (i.e. pretty > much

Re: Equivalent of recursive make with meson/ninja?

On Sat, Feb 11, 2017 at 07:03:01PM +0530, Nirbheek Chauhan wrote: > On 11-Feb-2017 18:32, "Sébastien Wilmet" <swil...@gnome.org> wrote: > > It'll also relink all the tests and rebuild the docs (GTK-Doc is very > > slow). > > Fwiw, it won't rebuild the do

Re: Equivalent of recursive make with meson/ninja?

On Sat, Feb 11, 2017 at 11:54:40AM +, Tim-Philipp Müller wrote: > With meson/ninja, everything will end up in one single build.ninja file > (the equivalent to a Makefile). > > You'd just do > > touch foo.c > ninja In two different terminal tabs though. > and it will only recompile/relink

Equivalent of recursive make with meson/ninja?

Hi, With the Autotools, recursive make is very convenient to re-build only the stuff present in a sub-directory. And with builddir == srcdir, it's convenient to do things like: $ cd src/ $ make $ touch file-that-i-modified.c $ make To see the warnings only for the file that I modified. (see

Re: Documentation for build system setup

On Thu, Feb 09, 2017 at 04:14:13PM +0100, Sebastian Geiger (Lanoxx) wrote: > I have just updated the wiki, please let me know if something I changed > is not right: > > https://wiki.gnome.org/Projects/GnomeCommon/Migration This is probably bikeshedding, but it's easier to remove lines than

Re: GNOME 3.23.3 released

On Thu, Dec 15, 2016 at 03:34:40PM -0600, Michael Catanzaro wrote: > On Thu, 2016-12-15 at 21:08 +0100, Sébastien Wilmet wrote: > >  - gspell (1.2.1 => 1.3.1) (*) > > (*) No summarized news available > > > > There is a bug in the code that extracts the news, because

Re: GNOME 3.23.3 released

On Tue, Dec 13, 2016 at 12:27:08PM -0600, Michael Catanzaro wrote: > The lists of updated modules and changes are available here: >   core   -  https://download.gnome.org/core/3.23/3.23.3/NEWS >   apps   -  https://download.gnome.org/apps/3.23/3.23.3/NEWS - gspell (1.2.1 => 1.3.1) (*) (*) No

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

On Sun, Nov 20, 2016 at 11:44:41AM +0100, Lasse Schuirmann wrote: > Shouldn't this be like totally easy with GNU Indent or so? You'll have > to give it the right CLI args. (We have a wrapper for that in coala if > you're interested in doing loads of other stuff but indent is usually > already

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

On Tue, Nov 22, 2016 at 07:03:02PM +0100, Daiki Ueno wrote: > For what it's worth, I wrote such elisp some time ago: > http://elpa.gnu.org/packages/gnome-c-style.html Cool, added to: https://wiki.gnome.org/Newcomers/Tools-C-language > If anyone is trying to implement the feature somewhere, I

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

On Mon, Nov 21, 2016 at 03:49:09PM +, Ikey Doherty wrote: > You could use clang-format and an appropriately configured > .clang-format file to enforce coding convention within a source > tree. > > I'd recommend checking: https://clangformat.com/ as a simple way > to build your .clang-format >

Script to format the functions in a C header?

Hi, Is there a script to format the function prototypes in a C header, with the GNOME conventions? I.e. aligning the function names on the same column, aligning the parameters, etc. Thanks, Sébastien ___ desktop-devel-list mailing list

GtkSourceView changes in jhbuild

Hi, GtkSourceView 3.24 has branched, master is now open for GtkSourceView 4 development, which breaks backward-compatibility with GtkSourceView 3. The jhbuild modulesets have been modified exactly as for GTK+: 1. Rename the gtksourceview module to gtksourceview-3 2. For gtksourceview-3, set the

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

On Tue, Oct 25, 2016 at 11:13:04AM +0200, Sébastien Wilmet wrote: > On Mon, Oct 24, 2016 at 03:20:08PM -0500, Michael Catanzaro wrote: > > So it sounds like it can just wait until March, right? You could do > > GtkSourceView 3.24 and 3.90 at the same time in March? > >

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

On Mon, Oct 24, 2016 at 03:20:08PM -0500, Michael Catanzaro wrote: > On Mon, 2016-10-24 at 22:00 +0200, Sébastien Wilmet wrote: > > It is primarily new APIs replacing old ones. In one case, the new API > > is > > more powerful than the previous one, so it can be seen as a ne

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

On Mon, Oct 24, 2016 at 11:50:01AM -0700, Christian Hergert wrote: > 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

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

On Mon, Oct 24, 2016 at 01:28:49PM -0500, Michael Catanzaro wrote: > On Mon, 2016-10-24 at 20:22 +0200, Sébastien Wilmet wrote: > > And, the master branch is now ready for GtkSourceView 3.24. The > > question > > is: when to release it? Do we do a period of freeze? There

Ok to release GtkSourceView 3.24 in a few weeks?

Hi, The plan for GtkSourceView is to follow GTK+. So GtkSourceView 3.90 released at the same time as GTK+ 3.90, if everything goes well. But last cycle (before the freeze) we didn't know that GTK+ 3.22 would be the last GTK+ 3 version. And there was some more things that I wanted to do in

Re: Switching from Autotools to CMake for core evolution products

On Mon, Oct 10, 2016 at 12:45:50PM -0500, Michael Catanzaro wrote: > On Mon, 2016-10-10 at 12:57 -0400, Owen Taylor wrote: > > Can you propose what the necessary change would be to: > > > >  https://people.gnome.org/~walters/build-api/build-api.md > > Well that document is Autotools-specific.

Re: Looking for a GNOME Calculator maintainer

On Mon, Sep 05, 2016 at 04:43:02PM +0100, Alberto Ruiz wrote: > I'm looking for someone to inherit GNOME Calculator. > > I've been trying to cope with maintenance tasks but there are more bugs > that I can handle atm and I thought I should prolly look for another > maintainer or at least a

Re: builddir != srcdir in jhbuild breaks my workflow

On Fri, Sep 09, 2016 at 11:43:51AM -0400, Owen Taylor wrote: > On Tue, 2016-08-30 at 19:23 +0200, Sébastien Wilmet wrote: > >  > > 1) Once a project is fully built, to re-build something I always do > > something along those lines: > > > > To compile only what

Re: builddir != srcdir in jhbuild breaks my workflow

On Tue, Aug 30, 2016 at 09:25:20PM +, philip.chime...@gmail.com wrote: > I've been thinking about the exact same thing recently; how about a > 'jhbuild jump' command that will take you from a location under srcdir to > the corresponding location under builddir and vice versa? And perhaps have

Re: builddir != srcdir in jhbuild breaks my workflow

On Tue, Aug 30, 2016 at 07:05:49PM +0100, Emmanuele Bassi wrote: > > To compile only what I need: > > > > $ jhbuild shell > > [jhbuild] $ cd src/ > > [jhbuild] $ make > > > > To re-build only a certain *.c file, to see if there are any warnings: > > [jhbuild] $ touch file.c > > [jhbuild] $ make >

Re: builddir != srcdir in jhbuild breaks my workflow

On Tue, Aug 30, 2016 at 07:05:49PM +0100, Emmanuele Bassi wrote: > On 30 August 2016 at 18:23, Sébastien Wilmet <swil...@gnome.org> wrote: > > I've put the following in my jhbuildrc: > > > > checkoutroot = os.path.expanduser('~/gnome') > > buildroot = os.path.expan

builddir != srcdir in jhbuild breaks my workflow

Hi, With the new jhbuild default configuration, it builds the module with scrdir != builddir. I wanted to explain why I don't like it, and why I've put the following in my jhbuildrc: checkoutroot = os.path.expanduser('~/gnome') buildroot = os.path.expanduser('~/gnome') (to have again builddir

Re: SVG rendering - Librsvg and Lasem

On Tue, Jun 21, 2016 at 03:41:48PM +0200, Emmanuel Pacaud wrote: > This is a message I intended to write for some times, but the Toronto > hackfest notes gives me incentives to actually send it. > > In these notes, there is a paragraph saying Benjamin seems not too happy > with librsvg. > So I

Re: [ Revised Proposal ] Continuous Builds in GNOME

On Sat, Jun 18, 2016 at 08:15:19AM +0100, Emmanuele Bassi wrote: > So, I want to stop this thread on my side because not only is making > me not want to contribute anything ever again, but it also is > absolutely pointless busy work that relies on two people architecture > astronauting without the

Re: Continuous Builds in GNOME

On Mon, Jun 06, 2016 at 10:10:58PM +0200, Sébastien Wilmet wrote: > There is a solution: bump the major version of Camel or EDS each time an > API or ABI break is unavoidable, making the new major version > parallel-installable with the previous ones. And that, every 6 months if > ne

Re: GNOME Games source name

On Fri, Jun 03, 2016 at 10:50:04AM -0500, Michael Catanzaro wrote: > I talked with Adrien and he doesn't want to change the name... so GNOME > Games it will continue to be. So there's probably not much point to > continued discussion here. > > I realize this is inconvenient for Debian and other

Re: GNOME Games source name

On Thu, Jun 02, 2016 at 03:10:59PM +0200, Bastien Nocera wrote: > Yet this is what you're doing. If you want an application to be > renamed, you'd better make sure that you can actually come up with a > good name, and argue why it is an insurmountable problem to call the > package

Re: GNOME Games source name

On Thu, Jun 02, 2016 at 03:10:59PM +0200, Bastien Nocera wrote: > If you want an application to be > renamed, you'd better make sure that you can actually come up with a > good name, and argue why it is an insurmountable problem to call the > package "gnome-games-app" or similar in your

Re: Enabling builddir != srcdir by default in jhbuild

On Wed, Jun 01, 2016 at 01:12:08PM +0100, Emmanuele Bassi wrote: > The same thing will happen if you have a master/master-stable split, > because now people will commit to master, break it anyway, and nobody > will look at 'master-stable' because it's a completely different > workflow than what

Re: Enabling builddir != srcdir by default in jhbuild

On Wed, Jun 01, 2016 at 11:33:41AM +0200, Sébastien Wilmet wrote: > With master/master-stable, developers, translators etc continue to work > exactly as before. But GContinuous would automatically sets > master-stable to commits that work (from the GContinuous point of view). > And j

Re: Enabling builddir != srcdir by default in jhbuild

On Tue, May 31, 2016 at 05:01:23PM +0200, Sébastien Wilmet wrote: > There could be a master-next branch that GNOME Continuous test and > rebase/merge on top of master automatically if the build and tests > succeed. Or instead of master-next/master, having master/master-stable. O

Re: Enabling builddir != srcdir by default in jhbuild

On Mon, May 30, 2016 at 11:44:48PM +0100, Emmanuele Bassi wrote: > So, it seems that the discussion died on these shores. > > In the meantime, GVfs is but the latest module that broke because > people don't test under builddir != srcdir; I really, *really* don't > want to deal with this kind of

List of unmaintained modules

Hi, To follow what the GNU project does: http://www.gnu.org/server/takeaction.html#unmaint I've created a wiki page to list the unmaintained applications: https://wiki.gnome.org/Apps/Unmaintained With a link at the top of: https://wiki.gnome.org/Apps (as a reminder, every wiki page should be

  1   2   >