[Nix-dev] Nix GUI

[Tony White]

On 12 April 2010 07:29, Anders F Björklund <afb at algonet.se> wrote:
> Tony White:
>
>>> To integrate "proper" with nix-env and the rest of it, would
>>> probably take C++ and a libnix.so and a real Qt interface ?
>>
>> Hi all,
>> Packagekit might be the way to go I believe :
>> http://www.packagekit.org/pk-intro.html
>> The ui can be left to the respective developers and user selection that
>> way.
>> There are both gtk and qt4 front ends for packagekit.
>> http://www.packagekit.org/gtk-doc/index.html
>
> Actually it has gnome and kde4 frontends, but whatever.
> (integrated upstream, as part of http://freedesktop.org)
>
>> libpackagekit is obviously written in C but I would like to think that
>> in their source repo, somewhere, there could be some method of using
>> perl to interact with libpackagekit (Or python or maybe ruby.)
>> Bindings of some sort or using dbus bindings, possibly.
>
> The urpmi backend uses perl and ports backend uses ruby,
> but only python has generic support in the PK library...
>
>> If you look at the back end matrix :
>> http://www.packagekit.org/pk-matrix.html
>> Not a single package type can perform the roll back feature, something
>> nix can do.
>
> True. So Nix might be a useful addition to PK that way.
> Hacking something out in Perl shouldn't take too long ?
> It could serve as a prototype for writing a real backend,
> as writing suck a "dispatched" backend goes much quicker.
>
>> I personally am not totally sold on packagekit but only because it is
>> not quite stable enough to be used in production. It was pushed onto
>> Fedora users a while ago, when it clearly wasn't ready. It still
>> isn't. That doesn't really apply to a distro like NixOS and it could
>> potentially provide an easy graphical tool for users of the nix
>> package manager on other distros.
>
> It's also a way to browse packages and updates, even if not
> using it for the actual installation ? And it allows source
> based distributions for backends, like e.g. Gentoo's portage.
> I wouldn't say it's a total interface replacement, though...
>
>> It should become good after a bit more development or at least provide
>> the basis for a workable fork in the future. With most of the other
>> distros having a back end for it now and the amount of work it saves
>> writing a package manager ui, why not give it a shot?
>> If not, I will have a go eventually, when I get round to learning a bit
>> more C.
>>
>> Writing a whole set of tools for graphical package management seems
>> like a lot of work, especially seeing how packagekit could take a
>> large amount of the grunt work out of it.
>> What do you think? Is packagekit workable?
>
> Sure. I've written a backend for FreeBSD's "ports" (using ruby)
> and Slackware's "slapt" (using C), so that is certainly doable.
> I think it should use C++ and talk directly with Nix, for speed.
> Might give it a shot later, when I get more familiar with NixOS.
>
> --anders
>
>

Hi Anders,
Yeah the gnome ui is written in gtk and the kde ui is written in qt4,
I don't quite see how that makes them exactly desktop specific other
than using a few bindings from either desktop, which could be stripped
out and replaced if need be. Both are open source projects and are
easily installed whatever the desktop.

packagekit is mostly for users that don't want to go anywhere near the
command line.
Yep, you can browse updates without installing any. It also runs as a
daemon and can perform automatic updates. I think it uses dbus too, to
workout if the machine is running on batteries, so as not to try to
update unless the machine is plugged into the mains.

One thing I'm a little unsure of is that I think that some hooks would
maybe need to be needed somewhere (Maybe to nix itself) To tell
packagekit something has happened, started, finished, etc?
I agree that C++ is a good idea but just a proof of concept using perl
or something might be a good starting point.

Thanks,
Tony