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

Reply via email to