[Kde-print-devel] [Bug 134782] [KDE4] Make CUPS printer detection stoppable! Integrate progress indication with main window?

[Kurt Pfeifle]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=134782         




------- Additional Comments From pfeifle kde org  2007-01-10 21:04 -------
'Look at layout of the item -- Print preview is near Print (or could be).'
--------
Not sure what exactly you talk about. Konqueror doesn't have it (and you mentioned "html" in your first post). I assume you mean one of these applications which do provide an icon for "Print" and a separate icon for "Print preview" in their own main toolbar (like KWord)? These additional icons are not under KDEPrint's influence, it's a decision of the application developers.

Anyway, let's keep in mind that the problem is solved if you disable the CUPS print subsystem plugin by simply choosing a different one, right?  :-)


'I still do not agree. When I click "print" in "print dialog" -- yes. Or if 
 I click "direct printing" (or immediate printing)'
--------


'Second -- if I understand correctly, with each "print" click (in menu) the
 program scans the network? It means there is a waste if no printer is changed'
-------- 
No -- "scans the network" is wrong. Usually, a locally running CUPS daemon doesn't scan either -- it just listens to the printer announcements made by other CUPS servers in its neighbourhood, and adds their printers to the list of available ones. kprinter retrieves this list. Only when no this list is empty, kprinter might trigger a new query.

It's different with no locally running CUPS daemon (case of remote server only, where local CUPS clients ("lp", "lpr", "lpstat" and "lpoptions" commands) need to directly query the remote server (which's name-or-IP they'll look up in ~/.cupsrc and /etc/cups/client.conf). kprinter does the same if no local CUPS server is available.  *Then* it querys the remote server. But that's not a "network scan" either (albeit I sloppily called this feature "autodetection" above).


'I am still convinced that Kcontrol could do automatic scan, and print dialog
 only on demand scan (or run Kcontrol). right?'
-------- 
I'm not fully convinced. But we may look into that possibility. (Though "scan" is wrong, see above...)


'Ok, I simplify. Have you ever read an article on e-newspaper.'
-------- 
No, sorry. Do you have an URL for me?


'Full of ads, banners, flashing images, splitted into parts? Ugly, right?'
-------- 
I trust you on this.  :-)


'But there is easy way to READ user-friendly version -- by clicking on "print
 version". Pure, beautiful article. But there is a catch -- the print-page
 could call JS print dialog, and now I wanted to read a page but in the result
 I got print dialog with auto-detection window.' 
-------- 
May I invite you to directly participate in the development of the KDE4print modifications?

I do not no if you can code in any way (I personally can't -- I just happen to know a few things about CUPS and about printing), there is still lots of other jobs to do, even in preparation, before real coding starts. 

And you seem to be quite passionate about your ideas. So what about these options (of course, if you can code, Cristian and Michael will be quite pleased to get some help in this), which are non-C++/Qt:

 (1) clean up the KDEPrint bugzilla, sift through past bug reports and wishlist
     items (like I do right now). You can start help with that on the spot, if
     you like.
 (2) create mockups for new UI designs that could serve as a basis for 
     discussion + developement.
 (3) write documentation, help users solve problems on the kdeprint mailing
     list.
 (4) test new code before it is released, help find bugs and make improvements
     long before the release is due.

What do you think?


'I am bit scaried with this "KDE4" but...'
-------- 
Well, KDE 3.5.6 (due to be out end of month) possibly is the last release before we'll see a KDE 4.0 end-of-this/beginning-of-next year.

Most developers are currently already busy to port their applications to KDE4.

There is already a working kdelibs4/kdebase4 (which includes KDEPrint) to develop against, though these are expected to be heavily improved and expanded with new technology.

I've personally not yet looked at it (but will do so before February, hopefully) because I was lacking a Linux machine for this in the last 9 months.

It will be a first task to see if all the ported-from-kde3 KDEPrint stuff still fully works in the new environment (that porting work was done by core developers who do not know much about printing -- they just looked into the fact that it all compiles; and no-one has ever looked closely into the functionality of the code, let alone changed features, made improvements etc.)