Based on your feedback for a qt-less configuration. I think the following configuration option can be added to a future HPLIP release.
--disable-qt-build (default = no) This option would be used to build a no-gui (command line only) HPLIP configuration. With "qt-build=yes", no "qt-required" applications would be installed and "qt-optional" applications would default to no-gui. -dave > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Henrique de Moraes Holschuh > Sent: Tuesday, June 27, 2006 9:33 AM > To: dwelch91 > Cc: hplip-devel@lists.sourceforge.net > Subject: Re: [HPLIP-Devel] Packaging qt-dependent HPLIP parts > separately > > > On Tue, 27 Jun 2006, dwelch91 wrote: > > Tim, I think for the purposes of a "Qt-less" HPLIP, you > could create a > > RPM without: > > > > toolbox.py > > sendfax.py* > > fab.py* > > ui/ directory* > > plugins/ directory > > hpfax.py* > > HP-Fax-hplip.ppd* > > coverpages.py* > > The last time I tried this (it was the way I wanted the > Debian packages to work since day one), I think there were > issues with plugins/, and I think something in the way hpssd > worked made me give up on the whole deal. This was way back > in the 0.9.5-0.9.6 transition, and after it I decided I would > not revisit the issue until after 1.x. > > Now that Tim's has started the discussion on the issue... it > is time for me to get back into it as well, I think. > > David, could you consider making it a set design decision for > HPLIP (in a future version, of course. A period of transition > is expected, and it doesn't matter if we take a few releases > to get there) that hpiod, hpssd and the various backends that > would need to be run on a printer server do *not* use or link > *anything* from python-qt? > > I don't mean "optional linking to python-qt", this would mean > loss of functionality on printer-server environments, which > is NOT desireable, IMO. This also means that if plugins/ are > going to create extra hpssd/hpiod functionality, they would > have to be split into ui-plugins and non-ui plugins. > > I'd like to see this as a set design decision for HPLIP, so > that it doesn't go back to "needs GUI" later, I realise I am > asking a bit much, so please excuse me if I am overstepping > my bounds, but IMHO it would help to know any effort on > making HPLIP more printer-server friendly would not be wasted > later on. > > Note that this request is independent on which parts of HPLIP > 1.6.6 will work without Qt. I'm just asking for a commitment > for versions in the future (and it doesn't even need to be in > the close future). > > With the new "send it all over the socket in the first place" > approach hpiod, hpssd and the other components now take > (which is much easier on us trying to lock these things down, > let me thank you again for switching to this design even if > it is potentially a bit slower than passing around file > handles or filenames in a spool), it should not be too > difficult to even move hpiod and hpssd to true network > awareness, so that we could have the > tools talking to hpiod/hpssd on a remote server. This is > the ultimate goal > for a GUI-less HPLIP packaging, IMHO. > > > *Note: Except that I am working on a GUI-less version of faxing for > > the > > command line as it has been requested by some users. So, in > the next few > > releases, the fax stuff could be added back into a QT-less > > version/package of HPLIP. > > Which is very nice, I thank you for it! > > > The other issue with a QT-less RPM is that some of the commandline > > utilities (hp-print, hp-makecopies, hp-unload, etc) support > both a GUI > > mode and a console mode, but they default to GUI mode. I > could create an > > override in the .conf file to control the default, or you > could patch > > the files to change the default. The other option is to > have them enter > > console mode automatically when PyQt, Qt, or X is not > present/running. > > I prefer this last option as the default, it is much cleaner. > However, it is always a good thing to give the user the > capability to decide what the default should be for the > entire system (auto, no-gui), and *also* allow for overrides > on the command line when one doesn't want to follow the > system's default. > > -- > "One disk to rule them all, One disk to find them. One disk to bring > them all and in the darkness grind them. In the Land of Redmond > where the shadows lie." -- The Silicon Valley Tarot > Henrique Holschuh > > Using Tomcat but need to do more? Need to support web > services, security? Get stuff done quickly with > pre-integrated technology to make your job easier Download > IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057& dat=121642 _______________________________________________ HPLIP-Devel mailing list HPLIP-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hplip-devel Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ HPLIP-Devel mailing list HPLIP-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hplip-devel