Dear Maintainer,

you currently have

merkaba:~> apt-cache show design-desktop-graphics | grep Depends
Depends: design-desktop, bookletimposer, compass-blueprint-plugin, compass-color-schemer-plugin, compass-fancy-buttons-plugin, compass-h5bp-plugin, compass-layoutgala-plugin, compass-normalize-plugin, compass-singularitygs-plugin, compass-slickmap-plugin, compass-susy-plugin, compass-toolkit-plugin, compass-yui-plugin, diffpdf, gimp, gimp-lensfun, gimp-plugin-registry, gtk-vector-screenshot, inkscape, libpdf-reuse-perl, libpodofo-utils, librsvg2-bin, mypaint, mypaint-data-extras, pdfposter, pdfshuffler, poppler-utils, python-cairosvg, python-scour, qpdf, ruby-compass, ruby-sass, scribus, shotwell

I think Krita would be a really nice addition to that.

https://krita.org/

The recent version (2.8.5) of it is packaged in Debian currently.

Or maybe do "gimp | krita" so people can choose? Or add Krita as recommends.

I think its a good idea to make people aware that Krita can be used as an
alternative. For the little work I do I mostly use Krita meanwhile as I find
it easier to work with.

I bet you do not want to overload the meta package with dependencies, but…
Krita is really a huge one to omit and you have mypaint in there as well.

Ciao,
Martin

Hi Martin,

Quoting Martin Steigerwald (2014-10-26 10:57:43)

(as a sidenote, the compass packages should be included only in the web
blend - that has since been corrected).

Yes, Krita is sure relevant to include.  Thanks for reporting that!

Its strong ties with KDE is a problem for some, however, both for its
size (it pulls in 3-400MB on an otherwise non-KDE system) and getting a
consistent user experience across applications gets more challenging.

Conversely some may want to mix design tools with the KDE desktop, and
currently they will get the XFCE desktop as unneeded "baggage".

At its current stage the Debian design blends are only targeted use with
Xfce.  I will postpone inclusion of Krita until we have redesigned (pun
intended) the packaging structure to better handle integration with
multiple desktop environments.


 - Jonas

Agreed.

gimp and krita serve different purposes, it should be "krita |
mypaint" (or the reverse) instead.

Quoting Jonas Smedegaard (2014-10-26 13:05:00)
https://anonscm.debian.org/cgit/design/blends.git/commit/?id=ed612dc


Thanks again for your suggestion!

 - Jonas

Am Sonntag, 26. Oktober 2014, 13:05:00 schrieb Jonas Smedegaard:
[…]

Yup. I thought about that as well.

But splitting blend package in KDE/qt and GNOME/XFCE/gtk variants… hmmm.

Am Sonntag, 26. Oktober 2014, 20:06:36 schrieb Paul Wise:

My priority would be krita | mypaint… but well I don´t know mypaint very well.
I just know Krita has gotten a lot of love of developers, also by usability
testing with artists, to make it really awesome for digital painting.

Sometimes it would be nice to have it like this:

apt-get install design-desktop-graphics

and then get a checkbox menu on which of the ones to install.

But then how to keep track which packages the meta package should keep
installed?

I also wonder about the visibility to meta packages like this. I am not aware
of a complete list of them. I am away of debian junior, debian med, recently
saw parl for parliamentary work… but how does the user discover these? Well
thats to a different forum to discuss probably, just wondered about it.

Quoting Jonas Smedegaard (2014-10-26 13:14:33)
https://anonscm.debian.org/cgit/boxer/boxer-data.git/commit/?id=a83511e

(posting these detailed steps as notes to ourselves on how to extend
boxer-based blends (this team, the boxer team and boxer itself are all
quite young and have not yet evolved some "best practices").

 - Jonas

Quoting Paul Wise (2014-10-26 13:06:36)
(broadly) cover same features and users are unlikely to use both?

I ask because for boxer I try to implement more strict handling than
your suggested dependency fallback, so that favored options can be
enforced (won't silently be ignored if a fallback happen to be
installed/pending).

Example: DebianParl for Wheezy depends on mplayer2, and DebianParl for
Jessie will depend on mpv and (when including the -strict addon)
conflict against mplayer2.


 - Jonas

They are both digital painting apps. They both use the same brush
system (originated in mypaint IIRC). Not sure but I think Krita has
more features and is more complex than mypaint. I've only used mypaint
though.

Quoting Martin Steigerwald (2014-10-26 13:46:12)
care less about consistency across applications or size, and more about
quality of each individual application.  We sure want to support those
users too (but not only those - and it is far easier to start with the
more constrained composition and optionally loosen the constraints.

Indeed that would be nice.  Current infrastructure in Debian do not
support "chained" package installs (install blend package containing
question → install other packages based on answer to the question).

What we will likely do for Debian Design in the foreseeable future is
allow you to do these (less elegant but doable within current Debian):

  a) apt-get install design-desktop-graphics-kde
  b) apt-get install kde-workspace design-graphics-kde
  c) apt-get install plasma-desktop design-graphics-kde
  d) apt-get install task-kde-desktop design-graphics-kde

Where a) would provide you the blend composed by the Debian Design team
including a composition of KDE, and b)-d) would provide you a "blend of
blends" mixing the Debian Design team's composition of packages suitable
for graphics designers with other teams' composition of KDE.

All of above would then pull in krita but also (through recommending
design-graphics) other non-heavy (i.e. non-KDE and non-GNOME) packages
suitable for graphics designers.

[Paul answered that by replying via relevant debian-blends list]

(...and thanks for noticing DebianParl!)


 - Jonas