The new contribution workflow for Gnome | Hacker News Reader

The new contribution workflow for Gnome

csorianognome.wordpress.com

284 pointsbpierre71 comments

Flatpak, builder, Ubuntu contributing to Gnome. 2017 is a great year for Gnome. I think these improved devtools will really help adoption. There are tons of developers (like myself) who don't make apps for linux because its too much effort. The easier it is the less excuses I have.

Won't Ubuntu still use Snap though?

Probably but who knows. I'm sure there are plenty of ways Ubuntu can contribute upstream when they start tweaking for their own desktop release.

Ubuntu using GNOME is easily the biggest deal for Linux desktop in a long time.

The recent versions of GNOME in the last year or so have been rock solid. The designers have been tweaking it since 3 launched to make it pixel perfect. I like the style better than OSX and I'm a front-end dev. Especially in dark-mode, with the always black top bar, it blends perfectly with a terminal heavy workflow.

No semi-transparent background and grey chrome to distract from black terminals.

And splitting/floating windows is built-in with shortcuts so it's easy to have [terminal/dev tools][chrome] side by side without installing any 3rd party tools. I normally use a tiling WM (i3/BSPWM), usually combined with gnome 3 for window chrome/nautilus, but since the last reinstall I haven't felt the need as I like the new gnome desktop.

I hope their teams collaborate on a Gnome 4 release.

What do you think about the huge title bars? Probably the most annoying thing about Gnome imho. I know you can adjust it, but still. If you Google you need to find a good fix that is compatible with your version.

I used Gnome for quite some time, but now I am using Cinnamon.

I like them, assuming I'm using a higher-than-traditional but not "retina"/doubled dpi, such as a 1920×1080 on a 13″ screen.

Most annoyances from gnome shell can be fixed by using the proper addons. The bad news is that it's time consuming and really you shouldn't have to do that. The good news is that toggling an addon is a one-click operation.

E.G: disable huge title bars: https://extensions.gnome.org/extension/723/pixel-saver/

Funny thing about this, the behavior pixel-saver adds to GNOME shell was once standard - people didn't like it so it was reverted (I think I remember this back in the GNOME 3.8 days).

Pixel saver does not disable huge title bars.

It removes title bar for the maximized window. For a window that is not maximized, it does exactly nothing.

Cinnamon is the desktop I want. As far as I know it's the desktop everybody wants - I've never had trouble explaining it to people. Windows 7 basically solved the basic UI experience IMO and we've since wasted thousands of hours redesigning it rather then perfecting it.

The look is great but put any beginner in front of it and:

- they will lool for the desktop for ever, not understanding it's gone;

- will struggle with the dock, hidding, not opening new windows when expected, not showing when several windows are opened, etc;

- will have a painful wifi setup (the list of SSID don't refresh unless you close it, then go 2 menus down to restart it)

- will have a painful bluetooth setup (the menu doesn't even appear if it's off)

- will be confused when trying to minimised two windows to put side by side now that the icon is gone;

- will try to look for the button to put the laptop to sleep and look at you with the eye of a sad puppy;

- will see a lot a spaces wasted compared to unity because of the windows bar being back and huge;

- will look for their app tray icons (now at the bottom left);

- will activate the hot corner by mistake.

I use myself 15 addons to make gnome-shell usable, and you can't expect the average user to do that.

Gnome shell is still experimental. Not from a technical point of view, but from an ergonomic point of view.

A beginner to what? If they've never used a computer before, what are they comparing it to? If they're a Windows user wouldn't they have to make some adjustments to use macOS or iOS? If they're a Unity user they will just do what Canonical tell them to.

The only problems from your list that I recognise are bluetooth, which is no longer a problem, and the hot corner.

The hot corner is bad interface design and needs fixing.

I would say a he meant a "beginner of gnome 3".

But I have given gnome 3 a fair chance and was quite happy with it for a while, but then I updated it and all my addons and themes were no longer usable. That annoyed me and I change the desktop.

So I would say that not only beginner of gnome 3 have problems with it. But also many people that already have expectations to a desktop environment.

I install Ubuntu on my mother's computer and my flatemate's. They don't know jack about computers. They start "the internet". Unity was easy to use for them. Gnome, really, really not.

I'm not trying to debate if those are a problem with you because there is not debate. I witnessed it. I know I'm right.

People loving gnome shell are all computer literate. But we are a minority.

Most people don't know how to use alt-tab. I repeat. Most people don't know how to use alt-tab. Get down from your ivory tower, computing is now main stream. And Ubuntu targets noobs. That's the whole point of it, make Linux usable for the many.

A Windows user has had to relearn their desktop UI every few years anyway since Windows 8, and whilst Windows 8 largely bombed, 8.1 and 10 have not.

Perhaps putting icons back in the desktop by default might be a good default setting tweak that distributions can do. I never quite understood the reasoning behind removing icons, seems to leave a it if unecessary empty space that can be used for something useful.

2, 4, 5, 6 apply to macos as well, don't they? I'm not saying that's a good thing, but they're certainly not a new concept or hard to learn.

One thing I've learned being a designer is that people under estimate people's ability to figure out interfaces.

Most intial problems are around the information architecture to figure out what something does and how they can do something. The UX and UI issues are generally competitive advantages.

I concur that GNOME doesn't have much more complications compared to MacOS. Strictly from a WM and chrome perspective.

The general questions around how to use the OS are more specific to linux. And obviously it's not the perfect OS for total newbs. But it's continually getting better for average OS users. Especially as hardware support is less of an issue, which has always been issue number 1 with Linux. Things should just work and hardware is first with any OS.

I got a couple of other frustrations I have with gnome 3:

- No categories in the 'menu'. Sometimes I don't know the name of the application or just want to explore what is installed.

- Wasted screen space everywhere. I have a laptop with a small display, I need auto hiding bars and small interface elements. Gnome seems to be designed for HiDPI or very big screens.

- You need plugins/addons for everything. Why can I not setup simple behavior with just some settings.

- No backward compatible to addons. Having to resetup the whole desktop experience just because gnome just updated is very annoying.

I don't currently use gnome 3 so some of those points might have changed.

I'm a teacher; 16/17 year olds will hop between interfaces with very different logics/metaphors with ease. For example, a desktop PC with Win7, an iPhone and an Android tablet.

I might try putting a recent Gnome on my test laptop and seeing what they can do with it as we go into revision for exams. As I use old X series Thinkpads, I'll need to bring a mouse. The trackpad is always the thing people find hardest!

Does anyone have references to any user testing of Gnome Shell as it was quite a fresh approach when it came out?

Large scale usability tests are pretty rare for open source software. Gnome is one of the few exceptions having some testing paid for by Sun Microsystems for Gnome 1 and then again by Novell for Gnome 2 around 2005.

From this they developed the Gnome HIG (human interface guidelines), which was used extensively in Gnome 2 and formed the basis for much of what they wanted to accomplish in Gnome 3.

Since the Novell test they had some ad-hoc usability testing, but nothing large or ran by professional usability testers.

Example:

https://renatagegaj.wordpress.com/2016/08/23/gnome-usability...

Yes.

Makes sense, considering that snap goes beyond Desktop. (E.g. cloud etc.)

Yes.

the builder folks said they would accept a snap plugin, so snaps will work fine with this setup.

The flatpak support is provided as a plugin. So assuming they do the same work and commit to maintaining it upstream, I'll accept it.

@christian - what do you personally think is the long term future of snap vs flatpack. Is it going to be another 30 years of 2 different packaging formats.

Not OP, but Flatpack I think Snaps will go the way of Mir in due time, Flatpack is integrated into GNOME.

The opportunity for Linux is now - unify the future packaging format. It doesnt matter to me which one wins, as long as there is one.

life will be infinitely easier for people who will package linux software.

They do have different scopes, however, as flatpaks are currently not designed to deliver system components.

@sandGorgon: Hard to say at this point. My personal opinion is that when it comes to building, shipping, and securing desktop applications, Flatpak is the better design. That is why I put my energy behind that project. I make my bets with code.

I should mention that this is just a way to simplify how you contribute to GNOME apps (and libraries/services for the adventurous). We are using technologies that were incubated in GNOME to simplify contributing to GNOME. This includes OSTree, Flatpak, and Builder currently. It's unlikely that jhbuild will disappear for things that require an entire session (shell, mutter, dbus, etc), at least in the short term.

This in no way affects users, or distributions that choose to use something other than Flatpak to ship applications. It's simply a shortcut for contributors to get started without building the dependency tree. No more build breakages in the dependency graph. No more compiling WebKit.

I know, I might try contributing something to gnome, the last time I looked into it, it was probably a hundred hour investment to get a code change in.

I'm so happy. The last time I tried setting up a GNOME dev environment I ran into two major issues.

Using jhbuild to download dependencies doesn't work if your network blocks git:// URLs. I had to hunt a lot to learn to tell jhbuild to use https:// or ssh:// URLs instead. It still broke when updating a dependency and only worked for toplevel explicit dependencies.

The second was the extremely long process of getting the dev environment set up compared to the ease with which Mozilla does it.

Both of those issues look fixed now and make the ecosystem all the more inviting for me to hack on. I even think you guys bested Mozilla on that second point.

I'll try it out and report back.

PS: Is this tied in some way to Ubuntu or can other systems get in on the fun as well? Arch Linux does have a gnome-unstable repo so I can grab the latest GNOME Builder.

Assuming this will be part of GNOME 3.24 it should be in Fedora 26 and Ubuntu 17.04. Other distributions will depend on when GNOME 3.24 packages land.

Cool. Arch's gnome-unstable repo ships git master builds for GNOME 3.24. I'm gonna go set it up now.

Also, for those wondering, 3.24 is coming in stable Arch repos after the rebuild-the-universe move to OpenSSL 1.1.0.

Source: r/arch, https://www.reddit.com/r/archlinux/comments/633jgj/whats_the... and https://www.reddit.com/r/archlinux/comments/640wl0/why_isnt_...

Unrelated to your jhbuild issues, you can often solve this class of issue in git by teaching git itself to search-replace the URL with "url.<base>.insteadOf". See the git-config manpage.

I tried that at first but the issue was that URLs didn't map perfectly. A url like git://freedesktop.org/harfbuzz.git mapped to https://git.freedesktop.org/projects/harfbuzz.git or something to that end.

It doesn't have to map perfectly as long as both end in the same suffix. Test with:

    git -c url.https://git.freedesktop.org/projects/.insteadOf=git://freedesktop.org/ clone git://freedesktop.org/harfbuzz.git 
    Cloning into 'harfbuzz'...
    fatal: unable to access 'https://git.freedesktop.org/projects/harfbuzz.git/': Failed to connect to git.freedesktop.org port 443: Connection refused

Then set it in your config:

    git config --global url.https://git.freedesktop.org/projects/.insteadOf git://freedesktop.org/

And now anything on your system cloning or fetching git://freedesktop.org/harfbuzz.git will use https://git.freedesktop.org/projects/harfbuzz.git instead.

Wow. Thanks. I guess it will work for all git commands (including the clone --recursive) ones?

EDIT: Yup. Works great. I'll check with jhbuild and add to the wiki if it works.

You can copy&paste config for freedesktop.org (and other popular git repos) from here:

https://github.com/jwilk/https-everygit/blob/master/gitconfi...

Didn't used to work with git submodules back when I tried. It's been quite a long time so I can't say if things have changed.

    There are no requirements to start development. 
    It's an advantage if you know a bit of object oriented programming and git.

Reading this sound so encouraging. I love open-source, but as junior dev, I feel like it's super hard to contribute and everyone expects that you already know all the advanced level stuff.

The GNOME project is a great group of people to develop your skill-set with. We can help find you projects to work on and there is pretty much everything you can imagine that needs doing. #newcomers on irc.gnome.org is a great place to start.

From 6 hours distro specific bootstrapping to a 5 minutes generic flow? That's just extremely impressive.

Even as a Fedora and Gnome user I've never even considered contributing to Gnome. I've just assumed (so far rightly) that it's just too big and heavy to work with.

Things like this may certainly change that. Great job!

I'm not quite sure what's going on with this website as it is flooded with ads.

http://i.imgur.com/R6ICEgA.png

I've been quite tolerant of ads myself without using an ad blocker for a long time but recently this kind of stuff with the whole page being clogged up by loading ads is getting out of hand.

wow, that's really terrible - i went and turned off my adblocker just to see how bad it is, and it appears to only be loading two ad units at the bottom of the article - as far as ads go, it's pretty unintrusive.

but somehow they manage to load those two ads in a way that completely throttles the CPU on my poor little chromebook.

Wait what? Is my blog full of ads?? I was not aware. How can I see them? Any alternative to Wordpress?

it's not full of ads, it's actually not that bad: http://imgur.com/a/JQp7r

but when i turn off my adblocker, it's just constantly making network requests for seemingly no reason: http://imgur.com/a/QCQSU

if it isn't something you've set up, it must be wordpress.com's ad network.

The most impressive fact about this is that it actually works as advertised, though it took a little longer to build nautilus, more like 15 minutes.

This is so cool that I'm actually tempted to use it for non-gnome apps.

If you have any issues (no doubt we still have bugs) feel free to ping us on irc.gnome.org in #gnome-builder. I'm usually around hacking on things.

Right, I should had clarify from where the 5 minutes come from and what kind of machine. I upgraded few months ago to a new machine (200MB/s internet, latest intel CPU + SSD, quite clearly not the most common set up)

Awesome work done by the community and the Flatpak/Builder guys

A minor nitpick to be sure, but it's odd that you must close down all other copies of your application before your development copy will launch. There is probably a way to work around this, but the limitation is hard enough to get around that it is mentioned in the Builder instructions.

This seems like an unnecessary limitation of the Gnome environment. It would be nice to be able to compare your existing release to your changed copy and run them side by side.

> This seems like an unnecessary limitation of the Gnome environment. It would be nice to be able to compare your existing release to your changed copy and run them side by side.

This is because GNOME applications have a hybrid of Windows and OS X behaviors now, due to the addition of D-Bus activation.

Applications still exit when you close the last window, but each application has a unique identifier (org.gnome.gedit, etc) and when the binary starts it will search for a running instance and tell it to activate if present.

The problem at hand is that applications are "single instance" by default. For Builder 3.26 we'll get something in place that starts a dbus-session to separate the built application from your host system.

Another option is to finish the simulator, but I have a debugger to finish first.

Thanks guys!! Specially to Alex and Christian.. Gnome project just got one more contributor ;)

All with an UI and integrated, no terminal required.

What if I just want to git clone something and run make (or similar) ? I don't see any documentation for that workflow at all. My usual development workflow is Emacs + git + commandline tools. Perhaps I'm simply not the target audience.

git clone $project_url

flatpak-builder builddir org.gnome.Foo.json

Builder does have support for building projects that use make without autotools, yes.

It's in the first sentence of https://wiki.gnome.org/Newcomers/BuildProject .

Is it possible to use this to contribute to Gnome Shell or GTK+? Or is "contribution" limited to applications?

I use it regularly to hack on GLib, Gtk+, Builder, Shell, Mutter, Sysprof, etc.

The primary issue is that for things that are libraries or system services, we don't have a way to install that and run some sort of test suite. We have a GSoC/Outreachy project for the unit testing integration, so that is not far off.

My eventual goal is to tie in GNOME continuous so that we can have all the base OS bits and just overlay the systems-level project (be it gtk, shell, boot services, etc). And then one keyboard shortcut to build/deploy/launch/debug. Should work for remote devices too.

The Flatpak version is not ready for that, no. That's why we link to JHBuild too, for the time being. Of course Christian is working on trying to make that work. In any case, most probably newcomers (the target audience of the initiative for now) won't probably hack on those anyway.

In the future we would like to have a generic guide for contribution, apart of just newcomers apps, but first we had to figure out the base. Now that it's done, we can move up and up in difficulty.

Hmmm... I wonder if I could get LibreOffice to build like that...

Actually, I wonder if anyone has ever tried to edit, compile and build LibreOffice in Builder? I know it can be done in KDevelop...

LibreOffice uses Flatpak too, so it should be as doable as any of the ones we have. But I didn't try myself :)

This is great. Every few years I've got it into my head I want to contribute, and each time getting everything working on Ubuntu has flummoxed me after a few hours.

I'm curious what is the trick in building the whole Nautilus in under 5 minutes? I mean how do this new build tool accomplish that?

Flatpak lets applications share a common set of libraries, called a runtime. So org.gnome.Platform has all the libraries like glib and gtk+ that pretty much all GNOME applications use, and all that's left to build are the ones that the application bundles that aren't in the runtime.

As audidude mentioned, but to add to it a little, is basically we have an SDK now. So you download (with delta update etc and sharing Sdk code) what's needed instead of compiling etc.

Reply on news.ycombinator.com