Brasero, or gnome without gnome

Brasero, or gnome without gnome

[Andreas Enge]

[-- Attachment #1: Type: text/plain, Size: 1094 bytes --]

Hi,

the attached patch is supposed to add the gnome cd burner brasero.
It compiles, but starting brasero fails on my debian kde desktop with
the following messages:

** (brasero:15560): WARNING **: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not provided by any .service files

(brasero:15560): GLib-GIO-ERROR **: Settings schema 'org.gnome.brasero.config' is not installed

Trace/breakpoint trap


Following
   http://forums.gentoo.org/viewtopic-p-7380668.html
   https://mail.gnome.org/archives/commits-list/2012-October/msg08466.html
the first one can be silenced by
   export NO_AT_BRIDGE=1

For the second one, I found
   http://forum.salixos.org/viewtopic.php?p=12697 that leads to
   http://forum.salixos.org/viewtopic.php?f=17&t=1852&start=10#p12011
or
   https://bugs.mageia.org/show_bug.cgi?id=3843


Does anyone know how to start a gtk+-3 application on a "foreign" desktop?
How can we get around running commands such as
   /usr/bin/glib-compile-schemas --allow-any-name /usr/share/glib-2.0/schemas/ ?

Andreas


[-- Attachment #2: brasero.diff --]
[-- Type: text/x-diff, Size: 2289 bytes --]

diff --git a/gnu/packages/cdrom.scm b/gnu/packages/cdrom.scm
index e207ae6..390b200 100644
--- a/gnu/packages/cdrom.scm
+++ b/gnu/packages/cdrom.scm
@@ -26,12 +26,18 @@
   #:use-module (gnu packages acl)
   #:use-module (gnu packages compression)
   #:use-module ((gnu packages gettext) #:renamer (symbol-prefix-proc 'gnu:))
+  #:use-module (gnu packages glib)
+  #:use-module (gnu packages gnome)
+  #:use-module (gnu packages gstreamer)
   #:use-module (gnu packages gtk)
+  #:use-module (gnu packages libcanberra)
   #:use-module (gnu packages readline)
   #:use-module (gnu packages ncurses)
   #:use-module (gnu packages help2man)
   #:use-module (gnu packages pkg-config)
-  #:use-module (gnu packages which))
+  #:use-module (gnu packages which)
+  #:use-module (gnu packages xml)
+  #:use-module (gnu packages xorg))
 
 (define-public libcddb
   (package
@@ -182,3 +188,36 @@ files.  Dvdisaster works at the image level so that the recovery does not
 depend on the file system of the medium.  The maximum error correction
 capacity is user-selectable.")
     (license gpl2+)))
+
+(define-public brasero
+  (package
+    (name "brasero")
+    (version "3.8.0")
+    (source (origin
+             (method url-fetch)
+             (uri (string-append "mirror://gnome/sources/brasero/3.8/brasero-"
+                                 version ".tar.xz"))
+             (sha256
+              (base32
+               "1r5wjsrm47amdaf862ymkdlwlb636c45wg14x20hdr99c653d2nr"))))
+    (build-system gnu-build-system)
+    (inputs
+     `(("glib" ,glib)
+       ("gnome-doc-utils" ,gnome-doc-utils)
+       ("gstreamer" ,gstreamer)
+       ("gst-plugins-base" ,gst-plugins-base)
+       ("gtk+" ,gtk+)
+       ("intltool" ,intltool)
+       ("itstool" ,itstool)
+       ("libcanberra" ,libcanberra)
+       ("libice" ,libice)
+       ("libnotify" ,libnotify)
+       ("libsm" ,libsm)
+       ("libxml2" ,libxml2)
+       ("pkg-config" ,pkg-config)))
+    (home-page "https://projects.gnome.org/brasero/")
+    (synopsis "CD/DVD burning tool for Gnome")
+    (description "Brasero is an application to burn CD/DVD for the Gnome
+Desktop.  It is designed to be as simple as possible and has some unique
+features to enable users to create their discs easily and quickly.")
+    (license gpl2+)))

Re: Brasero, or gnome without gnome

[Andreas Enge]

On Wed, Oct 02, 2013 at 02:41:46PM +0200, Andreas Enge wrote:
> How can we get around running commands such as
>    /usr/bin/glib-compile-schemas --allow-any-name /usr/share/glib-2.0/schemas/ ?

It appears that glib-compile-schemas is called during the build or installation
process of brasero.

Inside /nix/store/...brasero/share/glib-2.0/schemas,
there is a file org.gnome.brasero.gschema.xml, which has been compiled into
gschemas.compiled. So this gschemas.compiled is installed into the user
profile, and with the following line added to .bashrc:
   export XDG_DATA_DIRS=$HOME/.guix-profile/share
it is found and brasero starts up.

Of course, this works only as long as only one gnome program is installed,
since all the different gschemas.compiled step on each other's toe.

Andreas

Re: Brasero, or gnome without gnome

[Cyril Roelandt]

On 10/02/2013 02:41 PM, Andreas Enge wrote:
> Hi,
>
> the attached patch is supposed to add the gnome cd burner brasero.

Should this go in cdrom.scm or in gnome.scm ? How do we decide on where 
we define GNOME programs ?

Cyril.

Re: Brasero, or gnome without gnome

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> On Wed, Oct 02, 2013 at 02:41:46PM +0200, Andreas Enge wrote:
>> How can we get around running commands such as
>>    /usr/bin/glib-compile-schemas --allow-any-name /usr/share/glib-2.0/schemas/ ?
>
> It appears that glib-compile-schemas is called during the build or installation
> process of brasero.
>
> Inside /nix/store/...brasero/share/glib-2.0/schemas,
> there is a file org.gnome.brasero.gschema.xml, which has been compiled into
> gschemas.compiled. So this gschemas.compiled is installed into the user
> profile, and with the following line added to .bashrc:
>    export XDG_DATA_DIRS=$HOME/.guix-profile/share
> it is found and brasero starts up.

Oh, good that you found it.

Is there a more specific environment variable that could be put in
‘native-search-paths’ (so that ‘guix package --search-paths’ gives the
right hint)?

> Of course, this works only as long as only one gnome program is installed,
> since all the different gschemas.compiled step on each other's toe.

They’re all called ‘gschemas.compiled’?

If yes, then that’s another case for “profile hooks”–i.e., snippets to
run in the build process that produces the profile.

Thanks,
Ludo’.

Re: Brasero, or gnome without gnome

[Andreas Enge]

On Wed, Oct 02, 2013 at 09:26:08PM +0200, Cyril Roelandt wrote:
> Should this go in cdrom.scm or in gnome.scm ? How do we decide on
> where we define GNOME programs ?

We could decide that everything from mirror://gnome is a gnome program.
Then brasero should go into gnome.scm.

So far, there is also glib.scm and gtk.scm with bits and pieces from gnome.

On the other hand, I just put hicolor-icon-theme and icon-naming-utils
into gnome.scm, although they are not part of gnome (but the first one is
needed by brasero and supposedly most other gnome programs, and the second
one is needed to compile gnome-icon-theme).

A good scheme would be very welcome.

One possibility would be a purely syntactical one: regroup everything from
mirror://gnome into gnome.scm (which would become rather large, I suppose),
and everything from freedesktop.org into a newly created freedesktop.scm.

Andreas

Re: Brasero, or gnome without gnome

[Andreas Enge]

On Wed, Oct 02, 2013 at 09:32:23PM +0200, Ludovic Courtès wrote:
> Is there a more specific environment variable that could be put in
> ‘native-search-paths’ (so that ‘guix package --search-paths’ gives the
> right hint)?

No idea so far. But the next point speaks against it:

> > Of course, this works only as long as only one gnome program is installed,
> > since all the different gschemas.compiled step on each other's toe.
> They’re all called ‘gschemas.compiled’?

Yes.

> If yes, then that’s another case for “profile hooks”–i.e., snippets to
> run in the build process that produces the profile.

I thought so, but if possible, it would be nice to have a direct, functional
(by which I mean, depending only on the installed packet and not on which other
packets are also installed) solution.

Andreas

Re: Brasero, or gnome without gnome

[Andreas Enge]

[-- Attachment #1: Type: text/plain, Size: 684 bytes --]

The attached patch yields a "working" brasero in the sense that it starts, 
shows all icons, and allows, for instance, to drag and drop files from the
kde file browser into an image to be created. Apart from that, many helper
programs (mkisofs, cdrecord etc.) are missing, so the program is of little
practical use... But we can still use it to advance our understanding of
gnome packaging!

And not to start a flame war, but I see it as a real incentive to consider
kde packaging... As a first step, for qt, I think we might need to get the
cmake build system working. Cyril, would you be able to make it work on
x86_64, potentially by disabling the failing test in cmake?

Andreas


[-- Attachment #2: brasero.diff --]
[-- Type: text/x-diff, Size: 2431 bytes --]

diff --git a/gnu/packages/cdrom.scm b/gnu/packages/cdrom.scm
index e207ae6..c378d2f 100644
--- a/gnu/packages/cdrom.scm
+++ b/gnu/packages/cdrom.scm
@@ -26,12 +26,18 @@
   #:use-module (gnu packages acl)
   #:use-module (gnu packages compression)
   #:use-module ((gnu packages gettext) #:renamer (symbol-prefix-proc 'gnu:))
+  #:use-module (gnu packages glib)
+  #:use-module (gnu packages gnome)
+  #:use-module (gnu packages gstreamer)
   #:use-module (gnu packages gtk)
+  #:use-module (gnu packages libcanberra)
   #:use-module (gnu packages readline)
   #:use-module (gnu packages ncurses)
   #:use-module (gnu packages help2man)
   #:use-module (gnu packages pkg-config)
-  #:use-module (gnu packages which))
+  #:use-module (gnu packages which)
+  #:use-module (gnu packages xml)
+  #:use-module (gnu packages xorg))
 
 (define-public libcddb
   (package
@@ -182,3 +188,39 @@ files.  Dvdisaster works at the image level so that the recovery does not
 depend on the file system of the medium.  The maximum error correction
 capacity is user-selectable.")
     (license gpl2+)))
+
+(define-public brasero
+  (package
+    (name "brasero")
+    (version "3.8.0")
+    (source (origin
+             (method url-fetch)
+             (uri (string-append "mirror://gnome/sources/brasero/3.8/brasero-"
+                                 version ".tar.xz"))
+             (sha256
+              (base32
+               "1r5wjsrm47amdaf862ymkdlwlb636c45wg14x20hdr99c653d2nr"))))
+    (build-system gnu-build-system)
+    (propagated-inputs
+     `(("hicolor-icon-theme" ,hicolor-icon-theme)))
+    (inputs
+     `(("glib" ,glib)
+       ("gnome-doc-utils" ,gnome-doc-utils)
+       ("gsettings-desktop-schemas" ,gsettings-desktop-schemas)
+       ("gstreamer" ,gstreamer)
+       ("gst-plugins-base" ,gst-plugins-base)
+       ("gtk+" ,gtk+)
+       ("intltool" ,intltool)
+       ("itstool" ,itstool)
+       ("libcanberra" ,libcanberra)
+       ("libice" ,libice)
+       ("libnotify" ,libnotify)
+       ("libsm" ,libsm)
+       ("libxml2" ,libxml2)
+       ("pkg-config" ,pkg-config)))
+    (home-page "https://projects.gnome.org/brasero/")
+    (synopsis "CD/DVD burning tool for Gnome")
+    (description "Brasero is an application to burn CD/DVD for the Gnome
+Desktop.  It is designed to be as simple as possible and has some unique
+features to enable users to create their discs easily and quickly.")
+    (license gpl2+)))

Re: Brasero, or gnome without gnome

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> On Wed, Oct 02, 2013 at 09:26:08PM +0200, Cyril Roelandt wrote:
>> Should this go in cdrom.scm or in gnome.scm ? How do we decide on
>> where we define GNOME programs ?
>
> We could decide that everything from mirror://gnome is a gnome program.
> Then brasero should go into gnome.scm.
>
> So far, there is also glib.scm and gtk.scm with bits and pieces from gnome.
>
> On the other hand, I just put hicolor-icon-theme and icon-naming-utils
> into gnome.scm, although they are not part of gnome (but the first one is
> needed by brasero and supposedly most other gnome programs, and the second
> one is needed to compile gnome-icon-theme).
>
> A good scheme would be very welcome.
>
> One possibility would be a purely syntactical one: regroup everything from
> mirror://gnome into gnome.scm (which would become rather large, I suppose),
> and everything from freedesktop.org into a newly created freedesktop.scm.

This sounds like a simple approach, so probably a good one.

Thanks,
Ludo’.

Re: Brasero, or gnome without gnome

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> On Wed, Oct 02, 2013 at 09:32:23PM +0200, Ludovic Courtès wrote:

[...]

>> > Of course, this works only as long as only one gnome program is installed,
>> > since all the different gschemas.compiled step on each other's toe.
>> They’re all called ‘gschemas.compiled’?
>
> Yes.
>
>> If yes, then that’s another case for “profile hooks”–i.e., snippets to
>> run in the build process that produces the profile.
>
> I thought so, but if possible, it would be nice to have a direct, functional
> (by which I mean, depending only on the installed packet and not on which other
> packets are also installed) solution.

Do you mean a solution that does not require any action upon
installation?  That would at least require using different file names
than just ‘gschemas.compiled’, no?

What I had in mind is that upon installation in the user’s profile, the
glib-compile-foobar command would be run for all the schema-providing
packages to appear in the new profile.

WDYT?

Ludo’.

Re: Brasero, or gnome without gnome

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> The attached patch yields a "working" brasero in the sense that it starts, 
> shows all icons, and allows, for instance, to drag and drop files from the
> kde file browser into an image to be created. Apart from that, many helper
> programs (mkisofs, cdrecord etc.) are missing, so the program is of little
> practical use... But we can still use it to advance our understanding of
> gnome packaging!

:-)  Can’t it use GNU xorriso as the back-end?

> And not to start a flame war, but I see it as a real incentive to consider
> kde packaging...

I think you’d encounter similar patterns there.

Besides, while I have nothing against KDE (esp. if someone else does the
job ;-)), I think we should support GNOME as it is somewhat related to
GNU.

> As a first step, for qt, I think we might need to get the cmake build
> system working. Cyril, would you be able to make it work on x86_64,
> potentially by disabling the failing test in cmake?

Good news: the failing test no longer fails on x86_64!  That could be a
result of the ‘ldd’ fix in core-updates.

Ludo’.

Re: Brasero, or gnome without gnome

[Andreas Enge]

On Thu, Oct 03, 2013 at 12:17:39AM +0200, Ludovic Courtès wrote:
> Do you mean a solution that does not require any action upon
> installation?  That would at least require using different file names
> than just ‘gschemas.compiled’, no?

Yes. I also wondered if these were needed; one could imagine that this
compilation step would just be a caching mechanism, and that things still
work if the uncompiled original xml files are present. But this does not
seem to be the case as far as I can tell from my tests - brasero insists on
its xml file having been compiled into gschemas.compiled. And this is also
what happens in debian.

> What I had in mind is that upon installation in the user’s profile, the
> glib-compile-foobar command would be run for all the schema-providing
> packages to appear in the new profile.

This could even be done automatically without specifying it in the package
description whenever a package contains a file in share/glib-2.0/schemas/.
The glib-compile-schemas (there is also glib-compile-resources) is part of
the glib package, so should be available as an input to such a package.
But which glib version would we choose then when constructing the user
profile? Different installed packages could have different glibs as inputs,
for instance. The one that is "current" in the sense that it would be
installed by "guix package -i glib"?

Andreas

Re: Brasero, or gnome without gnome

[Andreas Enge]

On Thu, Oct 03, 2013 at 12:24:26AM +0200, Ludovic Courtès wrote:
> :-)  Can’t it use GNU xorriso as the back-end?

I do not think so.

> > And not to start a flame war, but I see it as a real incentive to consider
> > kde packaging...
> I think you’d encounter similar patterns there.

Definitely, I expect the same kinds of problems. But having seen both
k3b and brasero now, I know which one I prefer...

> Besides, while I have nothing against KDE (esp. if someone else does the
> job ;-)), I think we should support GNOME as it is somewhat related to
> GNU.

That is true. But I feel about GNOME as you feel about KDE, and am not overly
motivated to do more work on it, so it would be good if some volunteer
GNOME users stepped forward to take over.

Would it be okay to push the current moderately usable brasero package
so as not to lose the work?

> > As a first step, for qt, I think we might need to get the cmake build
> > system working. Cyril, would you be able to make it work on x86_64,
> > potentially by disabling the failing test in cmake?
> Good news: the failing test no longer fails on x86_64!  That could be a
> result of the ‘ldd’ fix in core-updates.

Excellent news indeed!

Andreas

Re: Brasero, or gnome without gnome

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> On Thu, Oct 03, 2013 at 12:24:26AM +0200, Ludovic Courtès wrote:

[...]

>> job ;-)), I think we should support GNOME as it is somewhat related to
>> GNU.
>
> That is true. But I feel about GNOME as you feel about KDE, and am not overly
> motivated to do more work on it, so it would be good if some volunteer
> GNOME users stepped forward to take over.

Yes, message received.

> Would it be okay to push the current moderately usable brasero package
> so as not to lose the work?

Definitely!

Ludo’.

Re: Brasero, or gnome without gnome

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> On Thu, Oct 03, 2013 at 12:17:39AM +0200, Ludovic Courtès wrote:

[...]

>> What I had in mind is that upon installation in the user’s profile, the
>> glib-compile-foobar command would be run for all the schema-providing
>> packages to appear in the new profile.
>
> This could even be done automatically without specifying it in the package
> description whenever a package contains a file in share/glib-2.0/schemas/.
> The glib-compile-schemas (there is also glib-compile-resources) is part of
> the glib package, so should be available as an input to such a package.
> But which glib version would we choose then when constructing the user
> profile? Different installed packages could have different glibs as inputs,
> for instance. The one that is "current" in the sense that it would be
> installed by "guix package -i glib"?

Assuming the format is stable, we could just use the current glib.

If that’s not the case, we can always come up with a more sophisticated
approach.

Ludo’.

Re: Brasero, or gnome without gnome

[Andreas Enge]

On Thu, Oct 03, 2013 at 01:21:14PM +0200, Ludovic Courtès wrote:
> Assuming the format is stable, we could just use the current glib.

This is probably the only viable approach. It feels less functional than
one would like: The user profile then depends not only on the installed
packages, but also (potentially) on the current glib version. Close to a
side effect, I would say.

Andreas

Re: Brasero, or gnome without gnome

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> On Thu, Oct 03, 2013 at 01:21:14PM +0200, Ludovic Courtès wrote:
>> Assuming the format is stable, we could just use the current glib.
>
> This is probably the only viable approach. It feels less functional than
> one would like: The user profile then depends not only on the installed
> packages, but also (potentially) on the current glib version. Close to a
> side effect, I would say.

I don’t think this matches the definition of a side effect.  ;-)

But yes, that means you possibly end up pulling an extra package just to
build the profile.

It’s actually already the case: the profile is built by running
‘guile-final’, so when you don’t have it in the store, it gets built
just to be able to build the profile (unless you passed --bootstrap).

Ludo’.

Re: Brasero, or gnome without gnome

[Aljosha Papsch]

[-- Attachment #1: Type: text/plain, Size: 763 bytes --]

Am Donnerstag, den 03.10.2013, 13:07 +0200 schrieb Andreas Enge:
> That is true. But I feel about GNOME as you feel about KDE, and am not
> overly
> motivated to do more work on it, so it would be good if some volunteer
> GNOME users stepped forward to take over.

I'm a GNOME user (and occasional contributor) and may start packaging
once I'm done with PHP (it already installs).

While it should be possible to provide a full GNOME experience (with gdm
and gnome-shell) at the moment, I guess it will be quite a bit of work,
also maintaining it, since GNOME assumes more and more systemd behavior:

http://blogs.gnome.org/ovitters/2013/09/25/gnome-and-logindsystemd-thoughts/

Best regards.

-- 
GPG: 4F20BC96
https://rpapsch.de/gpg.asc



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: Brasero, or gnome without gnome

[Ludovic Courtès]

Aljosha Papsch <lists@rpapsch.de> skribis:

> Am Donnerstag, den 03.10.2013, 13:07 +0200 schrieb Andreas Enge:
>> That is true. But I feel about GNOME as you feel about KDE, and am not
>> overly
>> motivated to do more work on it, so it would be good if some volunteer
>> GNOME users stepped forward to take over.
>
> I'm a GNOME user (and occasional contributor) and may start packaging
> once I'm done with PHP (it already installs).

Great!

> While it should be possible to provide a full GNOME experience (with gdm
> and gnome-shell) at the moment, I guess it will be quite a bit of work,
> also maintaining it, since GNOME assumes more and more systemd behavior:
>
> http://blogs.gnome.org/ovitters/2013/09/25/gnome-and-logindsystemd-thoughts/

Yeah, that is not encouraging, but we’ll see.

Adding features to dmd, such as satisfying the assumption “that an init
system will also clean up any processes it started”, may be doable,
though it seems unlikely that dmd will catch up on all of systemd’s
bells and whistles.

Yet, systemd’s Linux-only stance is a no-go for the GNU system, IMO.
It’s C-only approach is also a hindrance to extensibility.

I think we’re in a position to propose new ideas in terms of OS
integration and practical computing freedom enhancement, so let’s just
push them as far as we can.

Thanks,
Ludo’.

Re: Brasero, or gnome without gnome

[Andreas Enge]

On Thu, Oct 03, 2013 at 11:10:54PM +0200, Ludovic Courtès wrote:
> I don’t think this matches the definition of a side effect.  ;-)

Indeed, no, it it more the other way round: The environment has an impact
on the function value. Concretely, the user environment would depend
not only on the packages that are installed, but also on the glib
version that is current at the moment of installation. While this glib
can be seen as an additional input, so functionality is not disturbed,
I still think it is not really desirable, and I would prefer a solution
"local" to each packet. But here, I do not see any.

Andreas

Re: Brasero, or gnome without gnome

[Andreas Enge]

On Fri, Oct 04, 2013 at 06:50:48PM +0200, Aljosha Papsch wrote:
> I'm a GNOME user (and occasional contributor) and may start packaging
> once I'm done with PHP (it already installs).

This would be very nice indeed!

> While it should be possible to provide a full GNOME experience (with gdm
> and gnome-shell) at the moment, I guess it will be quite a bit of work,
> also maintaining it, since GNOME assumes more and more systemd behavior:

In any case, I assume one could start by packaging single gnome applications,
that would be usable without the full gnome desktop?

Andreas

Re: Brasero, or gnome without gnome

[Andreas Enge]

On Fri, Oct 04, 2013 at 06:50:48PM +0200, Aljosha Papsch wrote:
> http://blogs.gnome.org/ovitters/2013/09/25/gnome-and-logindsystemd-thoughts/

The replies by the blog author to the comments are quite interesting from
a gnu perspective:

"Don’t you realize that I am a GNOME foundation member and I am on the
GNOME release team?" (So this is not just a random opinion by a random
person.)

"Anyway, it seems eventually GNOME will head to be systemd and Linux-only."

This should imply that gnome would not be a gnu project anymore.
So maybe we would have to convince kde to apply as a gnu project...

Andreas

Re: Brasero, or gnome without gnome

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> On Fri, Oct 04, 2013 at 06:50:48PM +0200, Aljosha Papsch wrote:
>> http://blogs.gnome.org/ovitters/2013/09/25/gnome-and-logindsystemd-thoughts/
>
> The replies by the blog author to the comments are quite interesting from
> a gnu perspective:
>
> "Don’t you realize that I am a GNOME foundation member and I am on the
> GNOME release team?" (So this is not just a random opinion by a random
> person.)
>
> "Anyway, it seems eventually GNOME will head to be systemd and Linux-only."

That’s clearly a serious risk, something we’ll have to follow closely.

> This should imply that gnome would not be a gnu project anymore.

It wouldn’t be the first time there’s a technical inconsistency among
GNU projects.  But at any rate, GNOME lives its own life, essentially
independent of GNU.

Ludo’.

Re: Brasero, or gnome without gnome

[Aljosha Papsch]

[-- Attachment #1: Type: text/plain, Size: 918 bytes --]

Am Montag, den 07.10.2013, 21:53 +0200 schrieb Andreas Enge:
> In any case, I assume one could start by packaging single gnome
> applications,

The question is which gnome applications.  My personal priority list
would be:

* gnome-terminal
* rhythmbox
* seahorse
* transmission-gtk
* file-roller 

> that would be usable without the full gnome desktop?

Those are usable outside a gnome session.

I got the idea that Guix could offer XFCE as a replacement for GNOME:
instead of gnome-shell the XFCE stuff (xfdesktop, etc.).  Of course, one
could complain that no XFCE applications are provided.  That could be
fixed to package the basic XFCE programs as well (thunar, terminal,
etc.).  So, Guix would have three (two) desktop environments, KDE, XFCE
with XFCE apps, and XFCE with GNOME apps (referring only to core
applications).

WDYT?

-- 
GPG: 4F20BC96
https://rpapsch.de/gpg.asc



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: Brasero, or gnome without gnome

[Ludovic Courtès]

Aljosha Papsch <lists@rpapsch.de> skribis:

> Am Montag, den 07.10.2013, 21:53 +0200 schrieb Andreas Enge:
>> In any case, I assume one could start by packaging single gnome
>> applications,
>
> The question is which gnome applications.  My personal priority list
> would be:
>
> * gnome-terminal
> * rhythmbox
> * seahorse
> * transmission-gtk
> * file-roller 

Good.

> I got the idea that Guix could offer XFCE as a replacement for GNOME:
> instead of gnome-shell the XFCE stuff (xfdesktop, etc.).  Of course, one
> could complain that no XFCE applications are provided.  That could be
> fixed to package the basic XFCE programs as well (thunar, terminal,
> etc.).  So, Guix would have three (two) desktop environments, KDE, XFCE
> with XFCE apps, and XFCE with GNOME apps (referring only to core
> applications).

I think we can follow our personal preferences to start with (I got
Guile, Emacs, and Ratpoison because that’s pretty much all I need ;-)).
We do want to support some of these fancy desktops, but I don’t think
there’s much we can plan: if/when someone wants to add XFCE, KDE, or
Enlightenment, they’ll do it.

Work on adding GNUstep and GNOME is very welcome as these are the
preferred desktops in the GNU system.  Perhaps we should look for
hackers in these projects to give a hand.

WDYT?

Thanks,
Ludo’.

Re: Brasero, or gnome without gnome

[Aljosha Papsch]

[-- Attachment #1: Type: text/plain, Size: 1136 bytes --]

Am Mittwoch, den 09.10.2013, 22:22 +0200 schrieb Ludovic Courtès:
> I think we can follow our personal preferences to start with (I got
> Guile, Emacs, and Ratpoison because that’s pretty much all I
> need ;-)).
> We do want to support some of these fancy desktops, but I don’t think
> there’s much we can plan: if/when someone wants to add XFCE, KDE, or
> Enlightenment, they’ll do it.

I was trying to propose that Guix uses XFCE as the base for GNOME
(maybe: XFCE/GNOME) for the long term, assuming that non-systemd GNOME
installs won't be able to use gdm and some core functionality anymore in
the future.
I was not proposing to restrict Guix to KDE,XFCE,XFCE/GNOME, or not
trying to package GNOME as it is.

> Work on adding GNUstep and GNOME is very welcome as these are the
> preferred desktops in the GNU system.  Perhaps we should look for
> hackers in these projects to give a hand.

At the moment it should be doable to package GNOME as it is.  I was only
referring to the future.  Just trying to plan, at least a little :)

Best regards.

-- 
GPG: 4F20BC96
https://rpapsch.de/gpg.asc



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: Brasero, or gnome without gnome

[Ludovic Courtès]

Aljosha Papsch <lists@rpapsch.de> skribis:

> Am Mittwoch, den 09.10.2013, 22:22 +0200 schrieb Ludovic Courtès:
>> I think we can follow our personal preferences to start with (I got
>> Guile, Emacs, and Ratpoison because that’s pretty much all I
>> need ;-)).
>> We do want to support some of these fancy desktops, but I don’t think
>> there’s much we can plan: if/when someone wants to add XFCE, KDE, or
>> Enlightenment, they’ll do it.
>
> I was trying to propose that Guix uses XFCE as the base for GNOME
> (maybe: XFCE/GNOME) for the long term, assuming that non-systemd GNOME
> installs won't be able to use gdm and some core functionality anymore in
> the future.

Ah OK.  “As the base for GNOME” means that the desktop thing would be
XFCE, but the applications would be from GNOME, right?  That’s probably
a good workaround for the likely systemd-only future of GNOME.

>> Work on adding GNUstep and GNOME is very welcome as these are the
>> preferred desktops in the GNU system.  Perhaps we should look for
>> hackers in these projects to give a hand.
>
> At the moment it should be doable to package GNOME as it is.  I was only
> referring to the future.  Just trying to plan, at least a little :)

OK, understood.  :-)

Ludo’.

Re: Brasero, or gnome without gnome

[Andreas Enge]

On Wed, Oct 09, 2013 at 07:03:09PM +0200, Aljosha Papsch wrote:
> The question is which gnome applications.  My personal priority list
> would be:

I think this is exactly the way to go, package the applications you are
interested in (with the added bonus that they will be tested in a real
environment).

Andreas

LXDE, was: Brasero, or gnome without gnome

[Andreas Enge]

On the desktop front, I just came across this on my search for a simple
sample qt application to check my library with:
   http://www.zdnet.com/lxde-waves-goodbye-to-gtk-in-merge-with-razor-qt-7000018476/

Andreas