Thanks!

The current organization is$medium/$package/...where$mediumcan be graphics , audio , video , etc., and$packageis the Devuan package name.

What would you suggest instead?

I think we could have atemplatesdirectory ingraphicswith block models for the zones free of text for different packages. We should start with listing what needs to be done (package name, size, format, resolution), so we can keep track of them.

Note that we also have some web graphics there (e.g., the avatars for talk.devuan.org and such)

Removed awaiting feedback label

@hellekin Drop the $package subdir. We can use branches matching each suite and master can be a template to base new suites from.

The templates sounds good. If we can stick to svg or other vector formats for the base images, we can build conversion scripts to be used during packaging to produce the bitmap images from them.

Just be careful about the size of the video's. Anything larger then a few meg will cause git some problems.

Avatars are fine to just keep them in their own application specific space. I imagine they will change over time, so packaging them too might be handy in the longer term.

One of my main aims is to make it easier for derivatives to quickly bootstrap their own branding/image by forking this package and swapping in their own art.

Cheers,

Note I intend that we will build packages like devuan-syslinux-splash, devuan-grub-splash etc and have them provide syslinux-splash grub-splash where possible to make them drop in replacements for the debian artwork either directly or by fixing things so our art is installed instead or as well (depending on what the case may be).

I agree on branches for suites: there's already a jessie branch.

Why drop the package directories? My idea was to have all the SVG in one directory, and the generated PNGs and instructions for each package in their respective directories.

I tried working with command-lineinkscapeandconvertbut working with inkscape layers from the command-line doesn't seem to work so well (layer selection seems odd: at best ignored). I'll put up a branch with experimental stuff. The main issue is that if you can't select layers from the command-line, then you have to create one "final image" for each layer combination, or a script exports the bitmaps from the inkscape directly which is suboptimal.

Regarding the videos, I was thinking ofgit-annexreally. The idea of thedevuan-artrepository is too provide a single-stop place for all Devuan artwork, "for derivatives to quickly bootstrap their own branding/image". :)

Regarding how packages get their own Devuan art, I was thinking of "build scripts" that describe where to find the specific elements from thedevuan-artrepo (branch, path, commit) and the transformations to apply (mostly copying). I tried first with having SVG only in devuan-art repo but with the automation issue mentioned above, I opted for dumping the final bitmap in the package directory instead: it enables an easy pattern for people working on specific packages to find their way in the main repo.

hmmm .... try rsvg-convert from librsvg2-bin for the conversions. I think we should standardize on tools like that for generating png and other bitmap typ formats from svg.

Also, can I suggest we spin video and audio out to separate git projects? At best they'll only be tangentially related to devuan-art - aka not a lot of commonality.

Yes, definitely video and audio separate from devuan-art. The complexity of putting this together is mind-boggling to me. Sorry I can' t be more help. So very grateful for your monumental contributions.

I agree to keep video and audio separate also to avoid git complications and a single point of failure.

For the rest I think hellekin has a good plan and will see what I can do to integrate some scripting into the SDK.

What bugs me about that approach is may work well for the SDK, but it'd be painfully stupid for Devuan packages that need to be use that art work. At a minimum we'd end up with multiple copies of images spread across multiple packages maintained my multiple people. We won't get the consistent look and feel across the distrobution (one of Debians problems) and it will be so much harder to maintain. It also will make it equally hard for deriviatives to go through the same pain as we will have to because Debians art is spread across so many packages.

I've waited for consensus on the art work and was hoping that we could structure this project to be the source package from which we build all the necessary deb packages for delivering the art/branding so that we can fix all those other random places in packages that provides the various art images to make it easy to maintain.

That's the idea @CenturionDan , but each package has its quirks. The backgrounds, for example, can be consistent, but a grub one has different constraints than a 4x3 desktop or a 16x9 one. It seems to me that having all the sources (SVG) in a single repo, and only the final products (images) in each package's repo will allow for more consistency and flexibility. But still, mentioning each package in this repository will help packagers to find their way, and maybe document those quirks.

The problem with the approach of spreading the art out over separate source/build packages is the syncing needed to take place between this project and those packages, so we end up with at a minimum discrepencies because some packages will be rebuilt with newer versions of the art then others and also their is the risk of maintainers of those packages deciding to apply their own changes to the art. Finally it doesn't solve the fundamental problem of art/branding ending up mixed in with packages that have other primary purposes.

If all the art/branding is provided by packages built directly from this source package we can avoid the issues of duplication and versioning, editorial control etc, and at the same time make Devuan a more attractive distribution to build derivatives from because the whole branding and themes can be changed out by changing one package.

I'm thinking of going so far as to use virtual packages to make it even easier - where packages depend on "release-art-<usage>" which matches a Provides in the packages this package builds, where<usage>means grub-splash, installer-splash, desktop-backgrounds, login-splash, gtk-theme etc.

I'm sorry but I don't understand what's different between my approach and your approach.

I'll be traveling from tomorrow on... See you at camp...

CU at CCC safe travels

Daniel: to me it sounds cool and we all agree with it. As you like please go forward and commit your changes we do want to make life easier for downstream (us included)

Jaromil: I'll create the branch suites/jessie with the changes and initial packaging work.

Potential change of plan. I've discovered that all the desktop related artwork resides in desktop-base - all except for the installer-splash.

There are 2 approaches we could take - merge desktop-base into this package or move the relevant artwork into desktop-base.

Regardless of the approach we'd take, we'd need to produce the relevant desktop-base package to keep things compatable with debian.

I'll investigate further and decide what approach seems to suit best.

Lets copy the relevant artwork in desktop-base and keep this repository around still for staging artworks before inclusion? here we may also archive old versions

@jaromil @hellekin - sounds good to me to just copy what we need across.

Now nearly all the stuff here in devuan-art, but I think we'd be better off with svg - or svgz (compressed using gzip). What do you think?

All the SVGs are in the repository!

Milestone changed to 1.0.0-beta2

Bumping this. Not sure how to proceed for beta2. There's still no release for this "package".

mentioned in issue #14