Background image install paths.

Horizon_Brave · 2016-03-24 11:56:06

xaos52 wrote:

Personally, I would remove the repetition, so
usr/lib/bunsen/common
usr/lib/bunsen/configs
usr/share/bunsen/docs
usr/share/bunsen/skel/.config

As per my previous post this is what I was thinking actually. But minis the .config directory at the end of skel. Where would you put the welcome script files in your layout? Seeing johnraff's point that they should be separate.
/usr/lib/bunsen/configs/welcome-scripts/<files> and then other directories like
/usr/lib/bunsen/configs/<other-configs>/<files> Would that setup work?

damo · 2016-03-24 12:40:41

Horizon_Brave wrote:

.... But minis the .config directory at the end of skel....

Then there would be no `~/.config` for a new user? My understanding is that whatever is in `/skel/*` is what goes into the new `/home/user` when it is created.

Horizon_Brave · 2016-03-24 15:20:01

damo wrote:

Horizon_Brave wrote:
.... But minis the .config directory at the end of skel....
Then there would be no `~/.config` for a new user? My understanding is that whatever is in `/skel/*` is what goes into the new `/home/user` when it is created.

hehe, totally forgot to do the ls -a on the usr/share/bunsen/skel/ directory. Didn't see the entire .config subdirectory stored there.

johnraff · 2016-03-25 01:50:04

xaos52 wrote:

Personally, I would remove the repetition, so
usr/lib/bunsen/common
usr/lib/bunsen/configs
usr/share/bunsen/docs
usr/share/bunsen/skel/.config

I kind of thought that's what you would recommend.
And with
usr/lib/bunsen/welcome
for the bl-welcome includes of course.

You understand this means editing a lot of scripts that use some of those libraries, and that upgrades of bunsen-images, bunsen-utilities, bunsen-pipemenus, bunsen-welcome and bunsen-configs would all have to be co-ordinated to avoid breakages.

As I said, I'm prepared to do this if you think it's important enough.

xaos52 · 2016-03-25 08:17:04

As I said, I'm prepared to do this if you think it's important enough.

I can live with the schema you suggested.
I suppose it is entirely up to you to judge if it is important enough to put all that work into it.

johnraff · 2016-03-26 00:38:37

^I'm away over the weekend and have a fever too...
But I'll have a think and maybe do it next week. Probably with find/grep/sed it can be automated.

johnraff · 2016-04-02 04:03:51

Last check

Before I start changing install paths all over the place, a final check that this scheme looks OK:

Images
/usr/share/images/bunsen/asciiart
/usr/share/images/bunsen/icon-avatar
/usr/share/images/bunsen/login
/usr/share/images/bunsen/grub
/usr/share/images/bunsen/wallpapers/<pack_name>/

Others
usr/share/bunsen/docs/<helpfiles>
(also, symlinks put in /usr/share/doc/bunsen-docs pointing to helpfiles above)

usr/share/bunsen/skel

usr/lib/bunsen/common
usr/lib/bunsen/configs
usr/lib/bunsen/welcome

I think those fit in with the greatest number of peoples' preferences.

Anyway, it would be nice not to have to change these again...

Last edited by johnraff (2016-04-02 06:14:07)

damo · 2016-04-02 06:27:34

johnraff wrote:

....
Anyway, it would be nice not to have to change these again...

Looks good to me. "Publish and be damned!"

xaos52 · 2016-04-02 08:46:17

Ay Ay skipper, go ahead

Head_on_a_Stick · 2016-04-02 10:53:34

Looks great, good work

Horizon_Brave · 2016-04-02 11:42:43

For whatever my opinion is worth, the path selection looks god to me. Straight forward, concise, readable, and clear for the most part as to what each directories purpose is.

johnraff · 2016-04-07 06:38:57

The new versions of bunsen-{common,configs,docs,images,images-extra,pipemenus,welcome} are now in newpaths branches on GitHub.

I've built test debs from them and installed the whole lot on a VM. I put in dependencies and maintscripts to try to prevent old and new versions from clashing, and the upgrade process now seems to go OK, with files installed where they should be as far as I can tell, and pipemenus etc seem to work.

As soon as everything's OK I'll merge the newpaths branches into master and they'll be ready for building.

Remaining Question: filenames.

I've tidied up directory names, removing suprefluous bl- prefixes and the like, but the names of files themselves are still unchanged, so for example /usr/share/images/bunsen/login/ contains:
bl-login-1920x1200.png bl-login-blue-text.png bl-login-grey.png
bl-login-background bl-login-green.png bl-login-grey-text.png
bl-login-blue.png bl-login-green-text.png

All those bl-login- prefixes could be taken off and it would look tidier, but if any file was copied out of that directory it would have to be renamed or its name would become meaningless. See what I mean? Which way to go? At this point it will be quite easy to change the filenames.

xaos52 · 2016-04-07 06:50:23

I say remove the prefixes.
When a user copies them out, she is responsible for them.
Pampering the user has its limits

Horizon_Brave · 2016-04-07 08:32:42

xaos52 wrote:

I say remove the prefixes.
When a user copies them out, she is responsible for them.
Pampering the user has its limits

Agreed. Plus, you could include a README perhaps in this directory stating that any removal of files will "break" the linking. You could even make the README generic so you can include it any any directory that has files that, if moved, may snap the usage of it elsewhere?

damo · 2016-04-07 11:39:36

I guess $USER backgrounds config files could now have the wrong paths eg saved BLOB themes, but it is still a testing release. Better to tidy the names get any pain over now I think.

johnraff · 2016-04-08 02:19:27

damo wrote:

I guess $USER backgrounds config files could now have the wrong paths eg saved BLOB themes...

Good point. Any user scripts etc that use image paths will be broken.

...the more you poke around in the details of something, the more odd things come up...

-------------

Another directory, /usr/share/images/bunsen/icon-avatar/

bl-flame-ellipses-blue.svg Bunsenlabs-flame.svg
BunsenLabs-by-ututo.svg bunsenlabs-text-flame-grey.png
Bunsenlabs-flame-256.svg bunsenlabs-text-flame.svg
Bunsenlabs-flame-gray-256.svg Bunsenlabs-text-flame_uppercase.svg
Bunsenlabs-flame.png hydrogen-text.svg

Quite a mixture of naming there! In this case, I was inclined just to leave it alone, but it could be rationalized I suppose...

--------------

Another question, there are a lot of grub background files in wallpapers/bgpack_ututo
ie bl_grub2{a,b,c,d,e,f,g,h}.png

Most, but not all (??) of these are also in grub/

bl_grub2b.png bl_grub2e.png bl_grub2g.png bl-grub-nebula.png
bl_grub2d.png bl_grub2f.png bl-grub-nebula-desat.png

Move bl_grub2{a,c,h}.png from bgpack_ututo/ to grub/ and delete the others?

--------------

Also, @damo, could you have a look at the README? The "Default Debian Artwork image sizes" section, is that still correct?

EDIT: changed README url to "newpaths" branch.

Last edited by johnraff (2016-04-09 02:40:51)

damo · 2016-04-08 02:33:24

^ I'll have a look after a sleep! Yes the README needs an edit - the "default" sizes and filetypes were taken from the Debian notes for contributors to Debian8 artwork, and posted as a guide for anyone who wanted to make sets for BL.

Regarding the image names: many are what the original creators used, and they were uploaded to github before we decided on a more rational naming scheme (after they were packaged!)

johnraff · 2016-04-09 02:41:51

@damo sorry I was careless above and linked to the "master" README not the relevant "newpaths" version. Now fixed.

johnraff · 2016-04-10 03:47:59

damo wrote:

I guess $USER backgrounds config files could now have the wrong paths eg saved BLOB themes, but it is still a testing release. Better to tidy the names get any pain over now I think.

Re BLOB - I've just noticed that restoring a theme it overwrites /etc/lightdm/lightdm-gtk-greeter.conf with the direct path to a login background. Now that we are using Debian alternatives to set the login background, the path needs to be left at
/usr/share/images/bunsen/login/bl-login-background or the alternatives will be broken after a BLOB restore, especially if the saved session was from before the impending paths upgrade.

I'm not quite sure what the cleanest way forward would be - maybe an automatic save of the installed settings on first run of BLOB (or on first bootup of the system?), so that it will be possible to get back?

damo · 2016-04-10 10:00:08

Hmmm, complicated

I can see a few ways to go...

1) A BLOB first-run warning about older saved lightdm settings.

2) Remove the lightdm option completely.

3) Don't try to save/restore lightdm config, but have a message to the user to re-run alternatives.

4) Automate the edit of alternatives. Possible?

#41 2016-03-24 11:56:06

Re: Background image install paths.

#42 2016-03-24 12:40:41

Re: Background image install paths.

#43 2016-03-24 15:20:01

Re: Background image install paths.

#44 2016-03-25 01:50:04

Re: Background image install paths.

#45 2016-03-25 08:17:04

Re: Background image install paths.

#46 2016-03-26 00:38:37

Re: Background image install paths.

#47 2016-04-02 04:03:51

Re: Background image install paths.

#48 2016-04-02 06:27:34

Re: Background image install paths.

#49 2016-04-02 08:46:17

Re: Background image install paths.

#50 2016-04-02 10:53:34

Re: Background image install paths.

#51 2016-04-02 11:42:43

Re: Background image install paths.

#52 2016-04-07 06:38:57

Re: Background image install paths.

#53 2016-04-07 06:50:23

Re: Background image install paths.

#54 2016-04-07 08:32:42

Re: Background image install paths.

#55 2016-04-07 11:39:36

Re: Background image install paths.

#56 2016-04-08 02:19:27

Re: Background image install paths.

#57 2016-04-08 02:33:24

Re: Background image install paths.

#58 2016-04-09 02:41:51

Re: Background image install paths.

#59 2016-04-10 03:47:59

Re: Background image install paths.

#60 2016-04-10 10:00:08

Re: Background image install paths.

Board footer