Bug 134782

"accidentally choosing" *any* dialog can't be prevented by KDE, annoying as it might be.

"forced to, by JavaScript" is something you can stop or allow, depending on your own free decision in enabling or disabling JavaScript in your browser.

And sorry, the rest of your proposal I did not understand. I read it 5-10 times and gave up. 


Maciej,

you may want to try again (re-open this bug report, if you want), but explain a bit more detailed, and attach a few mockups about what you have in mind....

In short -- the problem is when you do not have printer. When you enter printer dialog the printer detection starts away -- not stoppable, as another window!

Now, I would suggest:
a) auto-detecting printer on demand
b) stoppable detecting
c) detecting progress intergrated with print dialog (not another window)
d) if no printer is detected do not show error, because it is no error

The current workaround is adding fake printer. Print dialog is less offensive then.

> "forced to, by JavaScript" is something you can stop or allow, depending on
> your own free decision in enabling or disabling JavaScript in your browser. 

Look, you suggest to disable JS for the entire Konqueror just because printer dialog is too aggresive?
 

Maciej,

 (a)  "auto-detecting printers" on demand is exactly what opening the print
      dialog does. I think it is a sane assumption to cope for "Oh, the user
      wants to print -- look, he clicked the print button. What?? No printers
      here? Let's see what the CUPS server does tell us about them..."

 (b) "stoppable detecting" is indeed something we might consider for
     implementing in KDE4

 (c) "detecting progress intergrated with print dialog (not another window)"
     may also be an option (not sure though)

 (d) "if no printer is detected do not show error, because it is no error"
     I don't agree. It *is* an "error", see (a)
 

"you suggest to disable JS for the entire Konqueror just because printer dialog is too aggresive?"

No, I suggest you do not click on the "Print" button if you do not want to print, and do not accidentally click on JavaScript-ed website links that start your print dialog. And no, the printer dialog is not "too aggressive" if it just opens up and tries to prepare to do its job when it is called (by whoever).

And as for disabling CUPS discovery, if you never print -- here is a very simple solution for you: 

 (*) In the "Print system currently used:" menu simply de-select CUPS
     and select any other system.

No need for a "workaround by adding fake printer".

You'll have to go through the pain of waiting for the printer discovery to finish once more, though. A last time. That I cannot spare you.     :-)

Ooops... I had wanted to make this a KDE4 wishlist item.


So here it is, to be considered for KDE4:

  (a) Make "CUPS printer detection upon kprinter startup" stoppable
  (b) Maybe "integrate detecting progress bar with print dialog (not
      a separate window)" 

(a) may have a use case for occasions where the detection takes much longer than expected (not so much the reason given by the reporter, "erraneous clicking")


(Previous $summary was: "print dialog redesign: make the printer detection easier for the user")

Now, I am lost in my own report :-)

a) nope. I didn't ask for auto-detect printer, I can make a mistake, I was choosing "print preview". I can teach somebody. I can have disabilities. Print dialog is too offensive.
ad.a) show "no printer". Just like that. 

d) wait, wait, so having no printer, is an error? If I cannot print (actually I could "print" to pdf) then disable the "print" item -- less confusion, and less irritation from users who do not have printer

e) (added) javascript -- wrong assumption, I could click at "go here" and print dialog could popup -> auto detection -> error

I still think there is lot of mis-design here. Not having a printer is normal situation, not an error or nobody's fault. If you are not disabling "print" item in case of no active printers, then allow user to move gently through printing or canceling printing.
Besides -- when I click "print" (on menu) it does not mean I actually print it. I can have second thought right? For example -- no time to print 200 pages, no enough paper, bad margines, typo spotted, etc. So this printer auto-detection is simply misplaced -> Kcontrol is the right way (or at least ask user "no printer configured yet, do you ...." -- however it is some kind weaker solution).

Ufff... :-)

Just for clarity, concerning d), the error is not that you don't have a printer, but the fact that kdeprint is configured to look for a CUPS server, but cannot connect to it (because it's not running, for instance). *This* is the actual error. One could think of keeping kdeprint silent in that case, but I'm pretty sure that we would get bug reports with "my CUPS server wasn't running and kdeprint didn't tell me anything".

Now, I agree that the detection mechanism should be stoppable. Another possibility would be to add a "No print system" plugin to kdeprint for situations where there aren't any print server running and the user just want to
use the pseudo-printers.

Maciej,

did you try my advice to switch your print subsystem plugin away from CUPS? This should effectively stop any autodiscovery mechanism of printers. Try it. It will solve your problem for now.

@ a) This is the first time you talked about "Print Preview". Which application
     was this? (Before you only mentioned "accidentally choosing print dialog"
     and "JavaScript".)
@ b) I didn't say it's an error if you have no printer. But if you click 
     "Print", it can be assumed that you also have a printer, and if then a
     printer is not found, it is an error.
     Also, you may not be aware: CUPS works in the network, it is not only for
     *personal*, locally attached printers. Clients are able to discover any
     new printers that might be added by the CUPS server admin; servers are
     able to promote their newly acquired queues within seconds to all clients
     which need no additional configuration steps; that's why there is what you
     call "autodiscovery" in kprinter. If you don't need CUPS, just disable it
     in the plugin selection -- simple as that. And yes, you can then still
     "print to PDF", because that is completely independent from CUPS.
@ e) Sorry, I didn't at all understand what you are trying to say.

I hope you noted that we accepted a few of your suggestions nevertheless. :-)

> did you try my advice to switch your print subsystem plugin away from CUPS?

No, but thank you for that, I will use it to help other people. Between the post (original) and our discussion here I bought a printer :-)

> @ a) This is the first time you talked about "Print Preview". 

Look at layout of the item -- Print preview is near Print (or could be). So, for somebody with hands disorder (movement) it is easy to "overclick".

> @ b) I didn't say it's an error if you have no printer. But if you click 
>      "Print", it can be assumed that you also have a printer, 

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

> Clients are able to discover any 
 >     new printers that might be added by the CUPS server admin; servers are 
>      able to promote their newly acquired queues within seconds to all
> clients       which need no additional configuration steps; that's why there
> is what you 
>       call "autodiscovery" in kprinter. 

First -- it should be only Kcontrol task.
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, right?

I am still convinced that Kcontrol could do automatic scan, and print dialog only on demand scan (or run Kcontrol).

> @ e) Sorry, I didn't at all understand what you are trying to say. 
 
Ok, I simplify. Have you ever read an article on e-newspaper. Full of ads, banners, flashing images, splitted into parts? Ugly, right? 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.

It is effect of not very good design -- too many, untrue, assumptions. KISS, right? :-D


> I hope you noted that we accepted a few of your suggestions 
> nevertheless. :-) 

Yes, yes :-)) Thank you for that. I am bit scaried with this "KDE4" but... :-)

'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.)

I'm not exactly sure what you're meaning with "scan on demand" in the print dialog, but I hope you're not suggesting that on print dialog popup, kdeprint should *not* connect to the CUPS server to know available printers, but the user should take some additional action to see the printer list. I don't think this is a very good design.

Concerning the example with the e-newspaper, I don't believe this is very relevant as (IMO) this is mis-using the print system. If you just want a clean readable version without the print dialog popping up, you should request the web site author to disable the JS print command, but you cannot put the fault on kdeprint, because it's just doing what the web page has requested: start the print process.

Michael,

> I'm not exactly sure what you're meaning with "scan
> on demand" in the print dialog, 

Search for new printer.

> but I hope you're not suggesting 
> that on print dialog popup, kdeprint should *not* connect to the
> CUPS server to know available printers, 

No. 

Maybe I say in other words -- you want to print, right? You click on "print" item in the menu. And now -- you should access to "close/cancel" button as fast regardless you have 10 printers connected or 0 printers.
Currently there is no such case -- it is immediate action if I have one printer (or more) and very long process if I don't have any printer. And this is just bad.

> because
> it's just doing what the web page has requested: start the print
> process.

If the page requested "start the print job" why the page is not printed? Rhetorical question, the page via JS requested "prepare to print". This and only this. There was no such thing as "hey, just look for any new printer, could you"?

Kurt,

> ------- '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).

The problem is general -- it concerns all KDE-apps.

> 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)?

Ok.

> These additional icons are not under KDEPrint's influence, 
> it's a decision of the application developers.

You mean -- layout? Of course. Ok, maybe I stop giving examples of apps and just stop at the statement about the time. There should be no time penalty for user who does not have printer. Period.

> 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?  :-)

Ok, I believe you :-) However CUPS is standard, isn't it? So the solution should be more elegant, not avoiding.

> No -- "scans the network" is wrong. 

Thank you for explanation.

> 'Ok, I simplify. Have you ever read an article on e-newspaper.'
> --------
> No, sorry. 

Riiiight ;-)))

> May I invite you to directly participate in the development of the
> KDE4print modifications?

Thank you! Well, I would like to help -- the only problems I can see, I don't know anything about automake and such thing (only make), and I don't have KDE4 installed (I wait for stable version).

>  (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?

Seems ok, I could do this only in my own pace (not too much spare time). Why I couldn't try? :-)

   'Seems ok, I could do this only in my own pace (not too much spare 
    time). Why I couldn't try? :-) '

Welcome then. Let's see if we can get the current KDEPrint bugzilla list a bit better organized.  :-)

It may be interesting for you to start with this (and links given there):

   http://bugs.kde.org/component-report.cgi?product=kdeprint

Right now it is most important to go thru the ones with "UNCO(NFIRMED)" in the "state" column. Check if they are valid (if possible on different systems), request more feedback from the reporter (if required), ask if it may be fixed in a more recent version (we have a few *very* old bug reports), and look for duplicate bug reports as well. (One trick: just type "bug ...." and fill in the dots with the number, and bugzilla will auto-create a link to that bug).

But even the ones tagged as NEW are vey often not-so new, and the same procedure applies here as well.
   

Thanks for the link -- for daily check I made such query:
http://bugs.kde.org/buglist.cgi?product=kdeprint&component=general&component=kdeprintfax&component=kjobviewer&changedin=3&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED
For now I see your responses everywhere :-D

I don't understand the trick -- where should I type it? In reports -- when I enter the link bugzilla adds <a href tags automatically.

KDEPrint is obsolete, unmaintained and will never be revived.  Closing all open bugs.