On 7 January 2014 23:52, Alex Merry <kde@randomguy3.me.uk> wrote:

> If these additions are something that applications would need to be
> aware of, I see no issue with creating a wrapper class or some such
> as-and-when we find a use for one.
>
> If they are something that would be hidden to applications, would you
> consider having platform integration hooks in QPrinter for that sort of
> thing?

The idea is to add things without the app needing to know or worry
about, and without having to go through every app and re-code to use a
new wrapper (I did that for 4.0 and 4.2, never again!).  On the other
hand, without knowing what those requirements might be it's a bit much
to assume that the current wrapper will meet those needs.  Platform
hooks are possible, we have a QPA plugin for printing, but would need
to be done in a cross-platform way, and until those needs arise we
don't know what shape it would need to take.

For color management, the idea was an extra tab would be automatically
added to the dialog if color management was configured, which would
then query the config for the colorspace to use and do some magic to
apply it.  However the proposal we discussed at the Color Management
hack-fest does rely on an obscure build-time dependency and a PDF
based workflow using Ghostscript that I'm really not keen on.  It's
also requires a decision to support Oyranos and/or colord in the core
that I don't think we're ready to make yet, or indeed have the
abstraction classes to do so.  I think for now it's better if the
Oyranos and colord camps provide their own tab widgets that apps can
choose to use to configure things, and then the app takes care of
deciding on color management support and workflow.  I'll look again at
adding the color OutputIntent to Qt's PDF support, but I'd have to do
that using a QString for the ICC Profile name, when I'd rather wait
until we have a proper QIccProfile class to use.  Sigh, so may tasks,
so little time...

Anyway, far too much detail for here, I think I'm convincing myself
that it's less useful to keep the empty wrapper around for now, it may
be better moved to KDE4Support, along with KPrintPreview, leaving an
empty repo.

John.
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel