gnome3 improvements #247

Open
viric opened this Issue Jan 6, 2013 · 93 comments
@viric
Official Nix/Nixpkgs/NixOS member

Quick guide on gnome3 https://wiki.gnome.org/SysAdminGuide

List of issues to be fixed:

  • Documentation for GNOME 3 packaging
  • Seahorse crashes when clicking on a private key found from the gnome-shell search. Since 3.12, it does not even show in the applications.
  • Grilo upnp does not show in the totem sidebar
  • Other browsers installed from nix-env cannot be chosen as default application.
  • GNOME sometimes loses the background/lock settings
  • The default background cannot be chosen from the list of possible backgrounds.
  • Icons of user-installed applications via nix-env are missing from the gnome-shell activity
  • Cheese is able to show the webcam, but cannot take photos. Something is wrong with gst plugins or such... Maybe relevant: https://bugzilla.redhat.com/show_bug.cgi?id=1227010
  • Update gdm to 3.18, there's some wip code for 3.16. Now we're at 3.14.
  • Could not compile gtkmm 3.18 with new pangomm for weird c++11/libsigc++ errors.
  • Cannot update profile in gnome-control-center.
  • There's some bluetooth support, but somehow GNOME cannot find adapters/devices, nothing shows up.

Some journalctl warnings to cleanup:

  • org.gnome.Calculator.SearchProvider[12182]: Error: ErrorCode.UNKNOWN_VARIABLE
  • org.gnome.Characters.BackgroundService[4183]: (gjs:5031): Gjs-WARNING **: JS ERROR: Error: Requiring GjsPrivate, version none: Typelib file for namespace 'Gtk', version '3.0' not found

Missing core packages left to be packaged:

  • seed
  • mousetweaks
  • mm-common
  • gtkmm

List of apps to be packaged:

  • gnome-color-manager
  • gnome-initial-setup (not nixos friendly)
  • gnome-sound-recorder
  • nemiver
  • orca
  • rygel
  • gnome-tweak-tool
@vcunat
Official Nix/Nixpkgs/NixOS member

There were certainly some attempts. And there's a branch:
https://github.com/NixOS/nixpkgs/tree/gnome-3
(I haven't tried any of these, just remembered there was a branch.)

@vcunat
Official Nix/Nixpkgs/NixOS member

A few more gnome3 pieces are now in https://github.com/vcunat/nixpkgs/tree/vlada/gtk3 .

Most notably it seems that evince-3.6* works. I'm not yet sure what to do with the work. Maybe it won't break anything and can go to master, but x-updates might be more suitable.

@viric
Official Nix/Nixpkgs/NixOS member
@vcunat
Official Nix/Nixpkgs/NixOS member

@viric: I can only see the gtk-3 dependency http://packages.ubuntu.com/quantal/gnunet-gtk

... which was already there, in some older version.

@viric
Official Nix/Nixpkgs/NixOS member
@vcunat vcunat referenced this issue Feb 21, 2013
Merged

gnome 3 progress #331

@domenkozar
Official Nix/Nixpkgs/NixOS member

@bjornfor and me are interested, anyone else?

@domenkozar
Official Nix/Nixpkgs/NixOS member

I have started to package gnome3 3.10 packages, see http://hydra.nixos.org/eval/1052217

There are two issues currently:

  • glib schemas conflicts (see #1455). I have a prototype solution, still needs some tinkering
  • theme/icons are missing: this is driving me nuts
@vcunat
Official Nix/Nixpkgs/NixOS member

@iElectric:

  • Why 3.11 versions? These are unstable 3.12 branches.
  • Schemas, themes, icons: the biggest problem I see is that I know of no good way to find out what of these will be needed at run-time (multiple packages provide them), and always depending on everything seems bad to me.
@domenkozar
Official Nix/Nixpkgs/NixOS member

I see that two packages are 3.11: I'll downgrade.

For schemas: we'll need a setup hook to pass that around. It's still pure and less error prone.

@vcunat
Official Nix/Nixpkgs/NixOS member

@iElectric: you mean auto-wrapping all executables with run-time dependency on all build-time packages providing schemas?

@domenkozar
Official Nix/Nixpkgs/NixOS member

@vcunat for schemas you don't need that. I'd do a setup hook that:

  • adds a fixup phase that copies schema from $out/share/glib-2.0/schemas/gschemas.compiled to $out/share/glib2.0/schemas/${name}/gschemas.compiled
  • wrapps all executables with the env var to point there.

For icons/themes we might need to do run-time dependency on build-time packages that claim to provide icons or themes.

I'm happy to hear a better solution though :)

@Phreedom
Official Nix/Nixpkgs/NixOS member
@domenkozar
Official Nix/Nixpkgs/NixOS member

There is a var that you can tell it where to look, but you need to move the schemas so they don't conflict in profile environment

@domenkozar
Official Nix/Nixpkgs/NixOS member

Also, useful resource how to configure gtk at run-time: https://developer.gnome.org/gtk3/3.0/gtk-running.html

@domenkozar
Official Nix/Nixpkgs/NixOS member

@vcunat downgraded 3.11 packages to 3.10, thanks for notice.

@vcunat
Official Nix/Nixpkgs/NixOS member

Well, at least in cinnamon we needed to add schemas also from different packages. I don't know how it's about GNOME3...

@vcunat
Official Nix/Nixpkgs/NixOS member

@Phreedom: wrapping in nixos isn't enough IMO, as many packages make much sense to run even without the GNOME3 desktop (like eye of gnome, evince).

@domenkozar
Official Nix/Nixpkgs/NixOS member

For the record, jhbuild dependency files are helpful when packaging gnome3 stuff http://ftp.gnome.org/pub/GNOME/teams/releng/3.10.2/gnome-suites-core-3.10.2.modules

@domenkozar
Official Nix/Nixpkgs/NixOS member

I've packaged most of the remaining gnome3 core software, last bit missing is gnome-shell.

gnome-shell fails to compile GIR files (gobject introspection). Gnome developers are saying we are linking against different gtk3 version that headers are included from.

Error:

building Shell-0.1.gir
  GISCAN   Shell-0.1.gir

(lt-gnome-shell:5650): GLib-GObject-WARNING **: specified instance size for type 'ShellEmbeddedWindow' is smaller than the parent type's 'GtkWindow' instance size

(lt-gnome-shell:5650): GLib-CRITICAL **: g_once_init_leave: assertion 'result != 0' failed
Invalid GType function: 'shell_embedded_window_get_type'

** (lt-gnome-shell:5650): ERROR **: Failed to extract GType data: Function 'shell_embedded_window_get_type' returned G_TYPE_INVALID
Command '['./gnome-shell', '--introspect-dump=/tmp/nix-build-gnome-shell-3.10.2.1.drv-1/tmp-introspectaPbggB/functions.txt,/tmp/nix-build-gnome-shell-3.10.2.1.drv-1/tmp-introspectaPbggB/dump.xml']' returned non-zero exit status -5

To test it out, checkout gnome3/gnome-shell branch and run nix-build -A gnome3.gnome_shell

@domenkozar
Official Nix/Nixpkgs/NixOS member

Fixed in a7d0a53.

Above commit also removed a bunch of run-time dependency problems for gnome-shell. Following errors/warnings are left to be addressed before we see a working gnome-shell+mutter in action: http://bpaste.net/show/172250/

@vcunat
Official Nix/Nixpkgs/NixOS member

This looks rather like some problem in virtualbox OpenGL setup...
libGL error: failed to load driver: vboxvideo

@domenkozar
Official Nix/Nixpkgs/NixOS member

Among other things, indeed :)

@domenkozar
Official Nix/Nixpkgs/NixOS member

Just pushed very basic gnome3 support. Try it out:

      desktopManager.default = "gnome3";
      desktopManager.gnome3.enable = true;
@bjornfor

@iElectric: Cool! I will try!

@domenkozar
Official Nix/Nixpkgs/NixOS member

Next major milestone to fix is #1700

@domenkozar domenkozar self-assigned this Feb 8, 2014
@domenkozar
Official Nix/Nixpkgs/NixOS member

@bjornfor channels should have all the updates for gnome3.

@PkmX

Do we have any resolutions on how to handle loading GTK+ modules at run-time? I'm currently dealing with IM modules, which will be installed by IM packages to their $out/lib/gtk-3.0/3.0.0/immodules/. GTK+ applications also need the environment variable GTK_IM_MODULE_FILE point to a cache file generated by gtk-query-immodules-3.0 to find them. My current proposal is:

  • Every GTK+ 3 application needs to be wrapped to export GTK_IM_MODULE_FILE=$(x=($NIX_PROFILES) ; IFS=: ; echo "${x[*]/%//lib/gtk-3.0/3.0.0/immodules.cache}") individually. The current solution seems to be hard-coding everything into environment.profileVariables, but this seems less ideal and probably doesn't work in this case since GTK+ 2/3 applications need different caches.
  • "/lib/gtk-3.0/3.0.0/immodules" needs to be added to environment.pathsToLink.
  • After creating symlinks in the environment, we also need to run $out/bin/gtk-query-immodules-3.0 > $out/lib/gtk-3.0/3.0.0/immodules.cache to build the cache here. This is tricky because gtk-query-immodules-3.0 won't be symlink'ed into $out/bin unless pkgs.gnome3.gtk is in environment.systemPackages, but we need run it if any single application installed on the system depends on GTK.
  • The same needs to be done for GTK+ 2 applications as well.

Any thoughts?

@domenkozar
Official Nix/Nixpkgs/NixOS member

@PkmX I believe noone bothered with that yet. Seems to be similar to gschemas.compiled thing.

If I understand correctly apps need GTK_IM_MODULE_FILE at runtime set with a path to a cached file of all immodules? If so, we should probably have an activation script for nixos when gtk is installed that would collect files. I think @vcunat said he has on TODO to do something similar for themes/icons

@vcunat
Official Nix/Nixpkgs/NixOS member

Yes, this issue seems to be pushing up through my TODO fast this month, after being there for a year at least :-) I think nixos isn't enough, as we want user envs as well. Various re-generating could be plugged into my planned scheme, but beware of using these system/profile-wide paths -- e.g. because of gstreamer and gio modules on them I have crashes (not matching versions and bad/no check on loading them).

Also, if we find a good way of auto-detecting similar run-time dependencies, it would be nice to have some advanced analogy of autoreconfHook, which would auto-wrap the affected executables some time around fixupPhase.

@lethalman
Official Nix/Nixpkgs/NixOS member

gnome-system-log and gnome-screenshot packaged

@lethalman
Official Nix/Nixpkgs/NixOS member

About "Control center is not opened when clicking the icon on settings", I'm able to open it when clicking on the Settings icon from the activity, and also from the icon in the logout menu on the top right.

@lethalman
Official Nix/Nixpkgs/NixOS member

gupnp and gupnp-igd are already packaged in nixpkgs

@domenkozar
Official Nix/Nixpkgs/NixOS member

Right, that's why I didn't add it at the first place.

@lethalman
Official Nix/Nixpkgs/NixOS member
  • gnome-terminal by default has broken text/background color which makes typed text unreadable. It's either an upstream bug, or a bad default configuration in gsettings to be overridden. Looking into debian might help.
  • Icons of user-installed applications are missing from the gnome-shell activity
  • Baobab has priority over nautilus for opening directories. The mimeinfo.cache decides the priority, however the file is created in system-path by update-desktop-database. See #2315
  • Seahorse crashes when clicking on a private key found from the gnome-shell search.
  • Grilo upnp does not show in the totem sidebar
@vcunat
Official Nix/Nixpkgs/NixOS member

I'm not sure where this is set, but I'm getting user+system-installed stuff in menus (perhaps xfce startup?).

echo $XDG_DATA_DIRS
$HOME/.nix-profile/share:/nix/var/nix/profiles/default/share:/run/current-system/sw/share
@lethalman
Official Nix/Nixpkgs/NixOS member

Right @vcunat . Though icons are not found for some reason, and applications are not found when gnome-shell is running, a restart is needed. Overall it's ok for now.

@vcunat
Official Nix/Nixpkgs/NixOS member

@lethalman: XDG spec for icons (and maybe others) requires to check the mtime of each top-level icon directory every five seconds as a way to detect of changes. Unfortunately, that's useless for us, as we use nix-store dirs, where the mtime values are always the same.

@lethalman
Official Nix/Nixpkgs/NixOS member

@vcunat yes, however also after restarting I don't see icons of user-installed applications.

@vcunat
Official Nix/Nixpkgs/NixOS member

Yes, I'm fairly sure that's because user-env doesn't regenerate the gtk icon cache (one from some random package gets typically in there instead). System env has a hard-coded hack to regenerate it.

@jagajaga
Official Nix/Nixpkgs/NixOS member

With cheese there is a problem of including gudev. Tried smth like https://gist.github.com/11142008 (unfinal due to gudev trouble) but no result.

@lethalman
Official Nix/Nixpkgs/NixOS member

@jagajaga $PKG_CONFIG is not set in the configure, and even setting it from the nix expr it's not picked up. The configure.ac or build-aux must be doing something weird with $PKG_CONFIG.

@lethalman
Official Nix/Nixpkgs/NixOS member

Proposal for gdk-pixbuf loaders and im modules @PkmX .
First note that GDK_PIXBUF_MODULE_FILE and GTK_IM_MODULE_FILE are not paths, but a single file.
I prefer wrapping programs instead of doing nixos activation for two reasons:

  1. Whenever it's possible, I prefer doing it in functional local-state rather than imperative global-state.
  2. Apps can be used outside of nixos if they are correctly wrapped with sane defaults.

The current approach to GDK_PIXBUF_MODULE_FILE has the following drawbacks:

  1. The same file with the same contents gets created for each package that has gdk_pixbuf build input.
  2. Even if the package does not rely on GDK_PIXBUF_MODULE_FILE, the loaders.cache file gets created.

This approach also has some advantages:

  1. $GDK_PIXBUF_MODULE_FILE is exported at build time, and it may be used for generating images from svg (gnome themes standard for example).
  2. The loaders.cache is filled in based on the build inputs of the package being built. This is not much of a feature, after all we always use gdk_pixbuf and librsvg as loaders.

Proposal: gdk-pixbuf-loaders

{ stdenv, gdk_pixbuf, librsvg }:

stdenv.mkDerivation {
  name = "gdk-pixbuf-loaders";

  builder = builtins.toFile "builder.sh" ''
    cat "${gdk_pixbuf}/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache" > $out
    cat "${librsvg}/lib/gdk-pixbuf/loaders.cache" >> $out
  '';
}

Then wrap with --set GDK_PIXBUF_MODULE_FILE "${gdk-pixbuf-loaders}".
By default loaders will be gdk_pixbuf and librsvg. If we ever need more loaders etc., I don't think that's a problem, we can fix / conditionate the derivation.

Disadvantage: $GDK_PIXBUF_MODULE_FILE is not known at build time for some packages needing it (which should be a few packages I hope), unless:

  1. gdk-pixbuf-loaders has a setup-hook and it's used as build input, which makes sense if the package needs loaders at build time.
  2. the derivation itself exports the needed variable.

Whether to choose between 1 or 2 depends on how many packages rely upon the $GDK_PIXBUF_MODULE_FILE variable being available at build time.

This applies to gtk im modules as well.

@lethalman
Official Nix/Nixpkgs/NixOS member

@jagajaga the problem is that cheese requires pkg-config 0.24, while nixpkgs has 0.23.

@jagajaga
Official Nix/Nixpkgs/NixOS member

@lethalman why don't we update it? :)

@lethalman
Official Nix/Nixpkgs/NixOS member

@jagajaga pkgconfig is basically used by all packages of nixpkgs, do you want the responsibility to break everything? :P I'd start with a pkgconfig_24 = ..../0.24.nix; first, and see that it works. There's no hurry in updating it for all the packages.

@vcunat
Official Nix/Nixpkgs/NixOS member

@jagajaga: It's not so easy. We probably want a patch that hasn't been ported to newer versions AFAIK (I tried to search months ago, but I haven't found a port). See #292 discussion.

@lethalman
Official Nix/Nixpkgs/NixOS member

@jagajaga now pkgconfig 0.28 is packaged, cheese can be packaged

@jagajaga
Official Nix/Nixpkgs/NixOS member

@lethalman thx. Gonna do it.

@lethalman
Official Nix/Nixpkgs/NixOS member

@edolstra @vcunat I'd apprecciate your comment about #247 (comment) :)

@vcunat
Official Nix/Nixpkgs/NixOS member

pixbuf loaders, state: (correct me if I'm wrong, please) It is another instance of the "plugin problem" we often encounter. However, this one is special, as typically apps only need the loaders distributed with the library itself (and no variable setting is needed to find them as long as we have GDK_PIXBUF_LIBDIR/gdk-pixbuf-2.0/2.10.0/loaders.cache on its place). The only other common loader I found is from librsvg which is used very much in gnome3 stuff. (I tried also searching for other loaders in Ubuntu http://packages.ubuntu.com/search?suite=trusty&arch=any&mode=filename&searchon=contents&keywords=libpixbufloader .)

When it's this simple, I think the best trigger is just having librsvg in build inputs. That could e.g. define that GDK_PIXBUF_MODULE_FILE variable via an env hook, so it's available both at build- and run-time. (No changes needed in expressions using this variable.) As you say, that extra loaders.cache in each build seems superfluous. We can have just one file, probably in librsvg output directly. We could again generalize that later if need be, but ATM splitting the loaders.cache generation would complicate its export via env hooks.

As for IM modules, I haven't really encountered those yet. I guess it will be different -- more like the usual "plugin problem" -- with a larger range of choice, different people (not packages) wanting different plugins...

@lethalman
Official Nix/Nixpkgs/NixOS member

For librsvg I'm not really convinced, but I think it's ok for now. Think that instead of having gdk-pixbuf + librsvg inputs, you may have gdk-pixbuf-loaders which propagates gdk-pixbuf and librsvg and has a build hook which sets the variable. I'd like to do this way but as said librsvg is fine too.

For IM modules as I understood it, you have a loaders list in a file, then you choose the IM with an env variable. Therefore a "meta package" with all the im modules in the loaders seems natural. The env variable is something the user can set in nixos or outside of nixos.

@vcunat
Official Nix/Nixpkgs/NixOS member

Yes, we could have such a meta-package instead (even a general function that creates the loader from a given list of packages and propagates the inputs). I'm relatively indifferent to that; it just seemed more natural to have it in librsvg directly when it's unlikely to be useful with different loaders anytime soon.

@vcunat
Official Nix/Nixpkgs/NixOS member

For IM modules the situation is more difficult. One would need to wrap every gtk package, or not? (Perhaps globally defining the variable could be the best solution ATM for people needing special IM.)

@lethalman
Official Nix/Nixpkgs/NixOS member
@domenkozar domenkozar changed the title from Package gnome3 to gnome3 improvements Aug 16, 2014
@vcunat
Official Nix/Nixpkgs/NixOS member

On staging, the default gtk3 theming is changed (probably due upstream changes in 3.12 -> 3.14), which looks better than before by default. However, whenever there's a tree shown, such as in evince index sidebar or liferea, the expand-boxes are invisible. @lethalman: any ideas what's going on? I currently have no other running distro with gtk-3.14 to test against it.

@lethalman
Official Nix/Nixpkgs/NixOS member

@vcunat gnome versions usually require strict major versions for this reason. Evidently gnome 3.12 stuff is not compatible (styling-wise) with the new gtk. Must be some incompatible change with the css and styling.
I don't think there's a nice solution besides having the older gtk for gnome 3.12.

@vcunat
Official Nix/Nixpkgs/NixOS member

Ah, so for the upcoming release, I guess we should choose gnome-3.12 and system-wide gtk-3.12, right? (They should supply maintenance releases long enough.)

@lethalman
Official Nix/Nixpkgs/NixOS member

@vcunat probably yes, but that would build twice the stuff including webkit. So maybe it's better to package gnome 3.14, test it and make it the default :)
The problem about gtk is that css is not subject to any kind of ABI/API compatibility. Developers cheat :P

@vcunat
Official Nix/Nixpkgs/NixOS member

I meant setting gtk3 = gtk3_12; for now. I don't think 3.14 features are really needed yet.

@lethalman
Official Nix/Nixpkgs/NixOS member

@vcunat that's ok

@vcunat vcunat added a commit to vcunat/nixpkgs that referenced this issue Nov 14, 2014
@vcunat vcunat gtk3: use 3.12 branch for now
This is for better CSS compatibility in the upcoming release.
We also plan to ship gnome-3.12 as the default in there. Details:
NixOS#247 (comment)
b9692d1
@vcunat vcunat added a commit that referenced this issue Nov 14, 2014
@vcunat vcunat gtk3: use 3.12 branch for now
This is for better CSS compatibility in the upcoming release.
We also plan to ship gnome-3.12 as the default in there. Details:
#247 (comment)
5ad9db0
@domenkozar
Official Nix/Nixpkgs/NixOS member

Document warnings "Using the 'memory' GSettings backend" as fixed in #5433

@lethalman
Official Nix/Nixpkgs/NixOS member

Also missing icons, especially on non-nixos. I'm sure we'll come up with a decent wrapper, but until then it's worth documenting the usual wrapping.

@domenkozar domenkozar removed their assignment Feb 15, 2015
@jgeerds
Official Nix/Nixpkgs/NixOS member

Missing application icons should be fixed with 1ce5c96

@lethalman
Official Nix/Nixpkgs/NixOS member

@geerds thanks. The issue I stated in the check-list however is about nix-env installed applications. I've clarified the issue.

@lethalman lethalman added the gnome3 label Jul 29, 2015
@jgeerds
Official Nix/Nixpkgs/NixOS member

Default background (and screensaver) fixed with 97dd0da

@lethalman
Official Nix/Nixpkgs/NixOS member

🍻 great!

@jgeerds
Official Nix/Nixpkgs/NixOS member

@lethalman 1ce5c96 should also fix missing icons for user installed applications (via nix-env). Did you test it?

I just installed dwb and midori in my environment. The first application ships an icon under $out/share/pixmaps and the latter one $out/share/icons/hicolor. Both are working for me. Don't forget to restart gnome shell

@vcunat
Official Nix/Nixpkgs/NixOS member

No, I don't think so, as other than system environments don't run the regenerators (still AFAIK).

@lethalman
Official Nix/Nixpkgs/NixOS member
@jgeerds
Official Nix/Nixpkgs/NixOS member

@lethalman I've fixed the gnome-tweak-tools issues in my branch: c10d0cb. What do you think? Should I push it?

(I'm going to fix this upstream but for now we should take these patches)

@lethalman
Official Nix/Nixpkgs/NixOS member

@geerds 👍 push if it works

@jgeerds
Official Nix/Nixpkgs/NixOS member

Now in nixpkgs:

[apps]

  • gnome-weather
  • gnome-maps
  • gnome-logs

[devel]

  • gnome-devel-docs

[games]

  • gnome-sudoku
  • aisleriot
  • hitori
  • five-or-more
  • four-in-a-row
  • gnome-chess
  • gnome-klotski
  • gnome-mahjongg
  • gnome-mines
  • gnome-nibbles
  • gnome-robots
  • gnome-tetravex
  • gnome-taquin

If you find any bugs just ping me

@lethalman
Official Nix/Nixpkgs/NixOS member

What an awesome work @geerds going to be the best gnome distro ever, step by step... Thanks!

@jgeerds
Official Nix/Nixpkgs/NixOS member

@lethalman thanks!

I've just added a few more:

  • gnome-characters
  • gnome-calendar
  • accerciser
  • gnome-nettool
  • gnome-devhelp
  • gnome-getting-started-docs

This issue is older than 2 years and constantly growing. Maybe we should close it and file separate issues for the outstanding things?

@lethalman
Official Nix/Nixpkgs/NixOS member

@geerds there are still some major things to be done so I prefer keeping this opened.

@clacke

I get only prefix search in gnome-shell, whereas on my Ubuntu Gnome I get a substring search. "inat" will find the "terminator" app. Do I add this here, or should it be a separate issue?

@lethalman
Official Nix/Nixpkgs/NixOS member

@clacke depends if it's a particular ubuntu gnome feature (like a patch) or not. We can discuss here the findings...

@jgeerds
Official Nix/Nixpkgs/NixOS member

@clacke Probably because we have no gnome-software in NixOS: https://bugzilla.gnome.org/show_bug.cgi?id=707594

@lethalman What do you think? Maybe we could bring gnome-software to NixOS (without the GUI application) and use the search provider

@lethalman
Official Nix/Nixpkgs/NixOS member

@geerds if by available app it means .desktop files, certainly we can...

@jgeerds
Official Nix/Nixpkgs/NixOS member

I guess it won't work because gnome-software depends on packagekit. There's no abstraction layer for nix, right? So gnome-software wouldn't return results for substring searches

@lethalman
Official Nix/Nixpkgs/NixOS member

Correct. Again, depends if the search provider only works with .desktop files instead of system-wide installed apps.

@lethalman
Official Nix/Nixpkgs/NixOS member

From a quick look at the code there's no plugin for looking into raw desktop files.

@lethalman lethalman referenced this issue Sep 4, 2015
Closed

GNOME 3.16 #7357

12 of 18 tasks complete
@lethalman
Official Nix/Nixpkgs/NixOS member

GNOME 3.18 now in staging. I've added a couple of new issues to the list.

@meteficha

It won't make it into 15.09, right?

@domenkozar domenkozar added this to the 16.03 milestone Sep 26, 2015
@domenkozar
Official Nix/Nixpkgs/NixOS member

Nope.

@domenkozar
Official Nix/Nixpkgs/NixOS member

GNOME 3.18 is now merged, removing milestone.

@domenkozar domenkozar removed this from the 16.03 milestone Feb 29, 2016
@vcunat
Official Nix/Nixpkgs/NixOS member

I checked a few things that were clearly done, some of them now in f412fb1.

@SShrike
SShrike commented Jun 13, 2016 edited

What is currently the status? Some of these bugs seem pretty serious and are blocking me from using NixOS as a daily driver.

@lethalman
Official Nix/Nixpkgs/NixOS member

@SShrike those issues are still there, we've been barely able to update to 3.20 during this week

@SShrike

@lethalman Ah okay :)

If you ever need help, I should be available on the weekends. I'm new to Nix/NixOS though, so you'd have to bear with some stupid mistakes probably.

@lethalman
Official Nix/Nixpkgs/NixOS member
lethalman commented Jun 13, 2016 edited

@SShrike of course, we need help for a lot of things. I'd say start from what you find inconvenient. That is, use the gnome desktop, do X because you need it, realize X is broken, work for fixing it. That is, fix what you find necessary for yourself.

@garbas

to all: i'm not personally using gnome, but you made it possible for few of my family members to use nixos :) thank you

@lethalman
Official Nix/Nixpkgs/NixOS member

@garbas ahah good to hear, and you should try it too... you know, it only takes a nixos config row :D

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment