On Wednesday 20 February 2008, David Faure wrote: > On Wednesday 20 February 2008, Marc Mutz wrote: > > Hi, > > > > [please CC me on replies, if you want me to see them - thanks] > > > > Currently, the only reason kutils links against kparts and therefore kio > > is that it contains kprintpreview.cpp. All the rest is fine with just > > kdeui. > > This is very much like undoing the mistaken addition of kprintpreview > indeed, which should have been in its own lib. Another solution would be to > put it in kparts but I guess there might be more printing-related classes > coming up in the future so a separate lib seems to make sense -- > libkdeprint anyone? ;) There may be a new libkdeprint coming at some stage, I'm hacking on a branch, but I'm not sure on the final form or contents or destination, and no guarantees on timelines :-) KdePrint currently has the following in kdelibs: kdeui/dialogs/kdeprintdialog - In KdePrint namespace, built into kdeui kutil/kprintpreview - No namespace, built into kutils The question I'm thinking on is how much we will actually need of kdeprint in kdelibs vs in kdebase, and that comes down to what Qt4.4 doesn't provide. The new QPrintDialog is looking good (a lot like the KDE3 dialog in fact :-) and so we may not need to add much. If all we need kdeprint for is the *nix admin side of things then libkdeprint should end up in kdebase, and kdeprintdialog and kprintpreview sit where-ever in kdelibs. If however we need to add stuff that depends on talking to the backends (e.g file printing) or is more than a couple of extra classes in kdeui, then we would need a libkdeprint in kdelibs. I'm in no position yet to make a call either way. Future proofing I guess the safe option is a new libkdeprint in kdelibs, but a bit of overkill if it does end up with only 2 or 3 classes. I'll leave that choice to wiser heads. I have no clue on BC issues, so I'm neutral on that side of it... John. -- Send instant messages to your online friends http://au.messenger.yahoo.com