KDEPrint on other *NIX platforms.

[Kurt Pfeifle]

Nick Bartolotti wrote:

 > Chris,
 >
 > Thanks for the information.  We are considering writing a front end and
 > filter chain for CUPS for a specialized printer

<curiosity>
    What sort of filter chain? What sort of specialized printer? (*)
</curiosity>
              (*) only answers requested which don't require a signing of an NDA...  ;-)

 > but I do not want to
 > force the user to use KDE for the utility if they are on HP-UX 11 or
 > Solaris 8/9.
 >
 > That is, if we write this front end using Qt/KED, how does the end-user
 > use the program from within CDE?

Just by calling it by name. Or by clicking on a desktop icon. Or by selecting
an item from a program menu....

If it is a GUI wrapper for a "print command": most programs allow for a
customized print command...

   * in Netscape just use "kprinter" instead of the pre-configured "lpr"
   * in StarOffice just setup the "Generic PostScript Printer" to print
     using "kprinter"
   * in "galeon" (the GNOME web browser) just use "kprinter" as a print
     command
   * in Acrobat Reader, just use "kprinter" as the print command
   * in Mozilla, just use "kprinter" as the print command.
   * a.s.o., a.s.f.

Just some ancient apps using a hard-wired built-in print command (mostly
"lpr") aren't as easy to configure. A little trick helps:

  * move the "lpr" print command to "lpr.orig": "mv `which lpr` `which lpr`.orig"
  * symlink "lpr" to the "kprinter" command:    "ln -s `which kprinter` `which lpr`"

If you can't imagine what I described above, just do a little smoke test:
try to get "gtklp". It should be easy to find a pre-compiled package for
Solaris (plus the required GNOME libs) -- it is less powerfull than
KDEPrint, as it is only the GUI to "lpr", but it is also smaller and
easier to find. Do with "gtklp" what I suggested for "kprinter" and
you'll see how it works. Then decide which way you go with your programming
effort...

 > My guess is that they can't without
 > first reconfiguring the system to use KDE instead of CDE.

Your guess is wrong.

(The most difficult part will be to re-compile the KDEPrint stuff on your
platforms if you don't find ready-made packages...)

 > If they do
 > this, what affect will this have with respect to all the other
 > already-installed GUI applications on the system?

None.

 > My guess is they will no longer work.

Wrong, because your assumption was wrong.

 > So what this boils down to is whether or not I have to develop and
 > maintain one or two sets of source code for the GUI (ignoring CPU

???

 > for
 > the moment).
 >
 > That is,
 >
 > Set 1:
 > GUI for CDE (assuming CDE is *really* common)

CDE will be replaced by Sun very soon by GNOME. However, I know (not just
one) customers using Solaris (large-scale, going into thousands of desktops)
who *won't* switch to GNOME, but will be using KDE by the end of the
year, because they like it much more...

 > for HP-UX 11 and Solaris
 > 8/9.  I expect to have to recompile on each system to get the
 > appropriate binaries.

If you don't find pre-compiled binaries: yes, any compilation needs to
be done for each platform separately.

 > I also expect minor differences that may require
 > conditional compilation.
 >
 > Set 2:
 > GUI for KDE on Redhat 8.0.

Huh? I may have missed s.th. --- but where now comes Redhat 8.0 into play?
(Anyway, it shouldn't be very difficult to find pre-compiled packages for
KDEPrint and complete KDE for any major Linux distro...)

 > What do you think?
 >
 > Thanks,
 > Nick.

Cheers,
Kurt