BeautyLine icons for Elive

Get Involved Dev
1

Overall I think that the BeautyLine icons are nicer than candy-icons like, among others:
The network icon is a tad more recognizable compared to the pile of spaghetti that candy-icons uses.

  • Beauty icons needs a few shortcuts for Elive ..... I can add those in a forked version I'll put up on gitlab today. DONE! :smiley14:
  • I'll also add an icon for 'yad' which it doesn't seem to have.
  • Any more suggestions?
3

IMPORTANT: I have created this thread but I have set it hidden in order to just develop this thing and then delete it because is useless to keep I think :thinking:

Ok I'm pretty confused with this project, on the GIT you forked there's many directories with "versions" of this icon theme, V1, V2, V3, default (bigger size), and "custom"... what???

On the other hand I found that the original project comes from here (so this should be the "upstream" imho): https://store.kde.org/p/1425426 which was updated 2 months ago

Its clear that we want to use the project that will receive the most updates (and so, improvements & fixes), but which one is?

Looking in more details, the V3 seems to be the most updated :thinking:, the one from the previous link includes much more elements

@triantares some notes about the git workflow for Elive:

  • when forking a git repo, is always good to keep the full history of changes, for that just add a remote (yours) and then push the repo to it, also maintain the original remote labeled "upstream", this way if the original repo made changes, they can be imported in the fork
  • if there's not a git repo of the original sources (like our actual case now), we can untar the sources in a branch called upstream, then create a new branch from it called "master" (or main) on which we can do the work, if there's new changes on the original sources, they needs to be imported in the "upstream" one and then merge them on our changes, this will keep an updated fork

In short, let's remake the git again:

  1. can you create a (new) git based on these sources? https://store.kde.org/p/1425426 (the second file, v1.6 , I cannot add the link here) - better if the repo name is like before, "beautyline-icons" sounds simpler
  2. create and switch to "upstream" branch
  3. create a set of subdirs called: tree/usr/share/icons/BeautyLine/ and put the unpacked files there
  4. set a tag to define the version of the original ones: v1.6-20230128
  5. push the branch & with tags: gp ; gpt
  6. switch to master branch
  7. in this master (ours) branch, you can now do the modifications needed for Elive (the ones you did in the previous repo), this is the branch to work into
  8. then I can make a package it with :slight_smile:

note: when the package will ready for elive, if you commit changes to it, a new package will be automatically rebuild & uploaded in the next days, this keeps the theme always updated and with fixes for everybody (lets have a pretty good one for EliveRetro! :rainbowyay::rainbowyay:

4

I'll do a more thorough check but actually I'm working with the V3 folder.
The 'gitlab' instance I made is a non-public one for the first workflow to add Elive specific links and maybe alter some icons.

  • It's not meant as a public repo quite yet, only for a selected group.

Once done I'll put it up as 'public' under a different name like 'BeautyLine-Elive' or such...but there's still some work to be done there. Some input might be helpful there i.e more eyeballs. :face_with_diagonal_mouth:

As to the links to kde.store: They seem to be down. They're up again. :smiley14:
What I gather from the README is that the original creator is named 'Sajjad Abdollahzadeh' but I cannot find him or any repos either in Gitlab or Github and kde.store doesn't seem to have any sources.

Not fully in the clear there and the set is very KDE/plasma oriented ...... hence me going for a Gnome/NixOs oriented one and adding/repairing for the Elive peculiarities.
I'll restart from the set downloaded from kde.store and use those for now. The small number of additions and tweaks I've done allready will allow that, without too much pain.
After that I'll only be working on the GitLab Elive version.

5

The Elive-E16 icon repo is 'public' now:

Albeit still a work in progress....So changes may be due.

Considering that there's 2 options to install icons:

  1. System wide in '/usr/share/icons/' ... where they'll need to be for 'cairo-dock' to find them through the GUI appearance tab.

or

  1. in '$HOME/.local/share/icons/' Where 'lxappearance' (in 'preferences ->Customize look and feel' menu) puts them when importing.

That is something to be reckoned with.

6

If im not wrong, the one from the kde link is the same as the V3 but with much more references (links to other images), this means that a ton more of icons are included / compatible

So... what's the actual state of this new repo? is the one from KDE or V3? they includes your changes? I don't see any commit in the history only a single one, there's also no tags or descriptions of where is upstream from

Do I have access?

7

This is the one from KDE, including my changes.

No, do you need to?

Albeit the eilive-e16 is publicly accessible if that's what you mean.

8

yes, to create make possible modifications for the icon package for elive
also the repo must be public for that

but, we missed the points from 2 to 6 in order to have the good package for elive ^ :thinking:

9

This is a totally new public repo, did you look or are you still in the (cached) old one?

10

Ah I see now 6 commits, but there's no "upstream" branch, mmmh... I wonder how it can be created now :thinking:

11

Exactly, that was mentioned in the former repository by 'gvolpe' ..... there's no source nowhere, other than a promise to put it on github at a later date. :face_with_diagonal_mouth:

This is as upstream as it will get, for now.

12

For a public repo, I prefer 'clone&merge' .

Will be getting some stuff done as ......I've got spare time until Tuesday .... after that I'll be hiking for a week on one of the Dutch islands near the German border (Schiermonnikoog).

  • Looking into more icon sets.
13

If the one from KDE is much updated and V3 references it, I assume that one is the upstream, we will use that one instead of the git one

Don't worry, I think I can create the upstream branch from there, i will do it :thinking:

By the way make sure your system is updated (just now), I have commited many fixes for icons (especially un-needed ones), remember that the menus from cairo-dock are the good ones to use as reference (new E will use the same system)

yeah but as said, the git project doesn't seems to be so updated like the files on KDE, so we should not use the git sources unless we see something interesting to add (manually), in any case its not a problem to do that from the files itself using a simple technique I already used since some time now

14

update: no, I can't create the upstream branch with its sources :thinking:, the first commit should be the import of the sources and also the upstream branch, but what I can see in the history is:

  • f6241d6 - (8 hours ago) Triantares — edited AUTHORS (HEAD -> main, origin/main, origin/HEAD, upstream)
  • 552e03b - (8 hours ago) Triantares — added tree directories
  • 5d28713 - (8 hours ago) Triantares — added robot icon
  • cda9bf8 - (9 hours ago) Triantares — added new yad icon
  • 5c9cb1b - (10 hours ago) Triantares — updated from private repo
  • 20bc149 - (10 hours ago) Triantares — Initial commit

where:

  • the files are imported
  • modifications are done
  • then they are moved (renamed) to the tree branch

in order to make it working and being able to have it updated correctly, we need to:

  • from upstream branch, put all the source files in the tree/ structure
  • create a new branch (main) for us to do modifications since this point
  • do these modifications

I don't know if we can fix that now... I think a rewrite in the git is needed :thinking:

15

@triantares

remote: ERROR: You are not allowed to push code to this project.

16

What do you mean by that? All the source files are in the tree structure and this the most upstream branch. :thinking:

Go ahead. :smiley14:

Correct ..... Only me. :innocent:

17

maybe is hard to explain from here but in order to be able to correctly do changes (or more exactly, to correctly import future updates from the original project), it needs to be do this way:

  • upstream branch -> import all the files already in the tree/ structure
  • switch to a (ours) working branch (main, or master), do whatever changes we want, we will use this branch for us
  • if there's new changes in the original project, we can easily do this way
    • switch back to upstream
    • import new changes and mark the imported version (in commit and/or tags)
    • commit & push to this upstream branch
    • switch to main or master, ours working branch
    • merge the changes, so our modified version will include the changes now
    • that's all, all working :slight_smile:

instead, in the actual mode it is, if there's new changes, they cannot be imported because there's not a place where to put them (all files has been renamed/moved after to receive modifications, so importing them will conflict everywhere)

mmh, so how i can fix it if i can't access? :thinking:

18

Ok let me try to do it more simple...

19

I've just moored my ship a 10 minutes ago. I can do a lot while sailing but mucking about in gitlab isn't a thing there. :madness:

  • access granted.
20

wait, im recreating everything in an "Elive organization" on gitlab, it will be much better to keep the things we are officially going to use in Elive from there, also the history was in a bad state which I don't think it could have been possible to use (I have added instructions to the Readme too), almost finished, I will give you access to it so you can import your modifications directly :slight_smile: