unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: Prafulla Giri <pratheblackdiamond@gmail.com>
To: Hartmut Goebel <h.goebel@crazy-compilers.com>
Cc: 43198@debbugs.gnu.org
Subject: [bug#43198] Questions about "Add breeze icon assets"
Date: Tue, 27 Oct 2020 10:20:27 +0545	[thread overview]
Message-ID: <CAFw+=j24zUKvb9fTch5Em3QRjGttN1xn+QcMZmO-W0L-XRKrbA@mail.gmail.com> (raw)
In-Reply-To: <bae9c62d-5411-0d72-e472-5c15f17b960c@crazy-compilers.com>

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

Hello Mr. Goebel,

To be really honest, I do not know much about KDE and all. I am just some
random guy who knows a little bit of guix/guile/scheme/gnu/linux, and I
just wanted to use Kdenlive, and really wanted a dark theme. (
https://issues.guix.gnu.org/43200)

I looked for the breeze icon theme in guix and found that we only had the
breeze-icons package, and not the entire breeze theme, and adding that to
kdenlive's dependencies did not supply the breeze theme in it's entirety. I
looked around for a solution and bumped into this:
https://github.com/KDE/breeze-icons and this: https://github.com/KDE/breeze

Seeing these two repos led me to conclude that the breeze-icons package
merely supplied the icons, whereas the breeze repository held the entire
breeze theme: what I was looking for in order to make the theme available
in Kdenlive (this was the end goal).

So, I decided to package the contents of the breeze repo (
https://github.com/KDE/breeze) into a package, and (reluctantly) decided to
call it breeze-assets. The reason that I inherited breeze-icons for this
was because I thought that since they were both "basically the same" thing,
or rather, parts of the same theme, they must share their dependencies. And
I thought that since I don't know much about KDE, and setting up it's build
environment, I started my packaging with: `guix environment breeze-icons &&
cd breeze # the breeze repo clone` and then went on adding more and more
missing dependencies. Hence, the inheritance. So, it is not a well thought
out decision on my part, but rather just what I started the whole thing
with. I understand that this might be causing breeze-assets to have as
inputs things that it does not require at all.

Once that was done, I tried adding breeze-icons and breeze-assets as
dependencies for KdenLive but that was still not working correctly. At run
time, some parts of the breeze theme were missing because the icons that
should have been available in the Breeze Theme were not available as they
were in separate /gnu/store/xxx-package directories. In order to resolve
this issue, I had two choices: I could either declare breeze-assets and
breeze-icons as propagated-inputs of kdenlive, or I could declare a
union-build of breeze-assets and breeze-icons as a union build in the
inputs of kdenlive itself. Being a (wannabe)
guix/functional-package-management purist, I chose to go the second route.
But then, I thought that perhaps other packages would also benefit from
having the union of breeze-icons and breeze-assets readily available to
just include in their input list. Hence, I added the union package:
`breeze`. And with that added as an input for Kdenlive, and the runtime
variable XDG_DATA_DIRS pointing to /gnu/store/xxx-breeze/share during
runtime, kdenlive has the breeze theme available (Commit:
e33a1e546a52aa70ffe0c8389f29ff3288cc4510).

Now, I can see that my solution is inelegant. And I should have not mixed
two different things together. But because of my lack of knowledge
regarding the matter, and my end goal of getting kdenlive's breeze theme
working, it appears that I've implemented a kludge. Please do go ahead and
make the corrective changes.

I have one request, however: that you please retain the union build of
breeze-assets and breeze-icon as it makes it easier to get the entire theme
without creating union-builds in every single package's input list. If that
is acceptable to you (to keep the union build `breeze` package) - and
please do correct me if I am wrong - am I correct in thinking that this
must be a matter of only cleaning `breeze-assets` up (removing the
inheritance, perhaps moving the package to another file altogether
(kde-plasma.scm, perhaps) ?

If you do not have the time, and want me to clean this up, please do give
me the instructions and I will be happy to make the necessary changes.

Again, please forgive me for the inconvenience caused.

On Tue, Oct 27, 2020 at 12:52 AM Hartmut Goebel <
h.goebel@crazy-compilers.com> wrote:

> Hi Prafulla,
>
> sorry, I'm late for the show and this is already merged. I packages quite
> a lot KDE packages and also made several attempts to make plasma-desktop
> run on guix.
>
> I'm curious about breeze-artwork and breeze and have some questions:
>
>    1. What is the reason you broke up breeze into breeze-assets and
>    breeze? What is the use of having a package "breeze-assets"?
>
> I'm asking since in guix we typically do not split up packages this way,
> but are using different "outputs".
>
>
>    1. What is the reason you inherit breeze(-artwork) from breeze-icons?
>
> I'm asking since
>
> a) breeze-icons are part of KDE Frameworks, whereas breeze is part of KDE
> Plasma. So I expect these to be somewhat independent of each other, as one
> can see by quite different version numbers.
>
> b) While breeze-assets inherits breeze-icons, it overwrites all
> information inherited from except of the build-system and some inputs. Even
> the version is different.
>
>
>    1. What is the reason for breeze becoming unified with breeze-icons?
>
> I'm asking since, as explained above, I'd expect these to be somewhat
> independent of each other. (breeze of course requires breeze-icons).
>
>
> --
> Regards
> Hartmut Goebel
>
> | Hartmut Goebel          | h.goebel@crazy-compilers.com               |
> | www.crazy-compilers.com | compilers which you thought are impossible |
>
>

[-- Attachment #2: Type: text/html, Size: 6850 bytes --]

      reply	other threads:[~2020-10-27  4:36 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-04  8:22 [bug#43198] Add breeze icon assets Prafulla Giri
2020-09-04  9:29 ` Ludovic Courtès
     [not found]   ` <CAFw+=j2GyvfVWw-qsR1ju4+CEVAzhfP7p6hociAfF1YcBDOuSg@mail.gmail.com>
2020-09-04 11:00     ` [bug#43198] Fwd: " Prafulla Giri
2020-09-07  8:06     ` Ludovic Courtès
2020-09-08 11:11       ` Prafulla Giri
2020-09-08 11:25         ` [bug#43198] Fwd: " Prafulla Giri
2020-09-09  7:26         ` bug#43198: " Ludovic Courtès
2020-09-09  8:27           ` [bug#43198] " Prafulla Giri
2020-10-26 19:07 ` [bug#43198] Questions about "Add breeze icon assets" Hartmut Goebel
2020-10-27  4:35   ` Prafulla Giri [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAFw+=j24zUKvb9fTch5Em3QRjGttN1xn+QcMZmO-W0L-XRKrbA@mail.gmail.com' \
    --to=pratheblackdiamond@gmail.com \
    --cc=43198@debbugs.gnu.org \
    --cc=h.goebel@crazy-compilers.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).