(*** This bug was imported into bugs.kde.org ***) Package: khtml Version: 3.0 (KDE 1.94 >= 20000911) Severity: wishlist $subj
Applications using new KDE print system in KDE 2.2 - Konqueror Kate do not allow print the selection which would be nice to have. As opposite to kedit which uses old printing dialog with "lpr/Other command" and "All/Selection" options but have some glitches in non-latin selection printing. Andriy __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com
*** Bug 37633 has been marked as a duplicate of this bug. ***
*** Bug 71686 has been marked as a duplicate of this bug. ***
Still valid with 3.2.3.
Still valid with kde 3.3.0 RC2
*** Bug 91332 has been marked as a duplicate of this bug. ***
This one is not just a "nice to have" feature, it is a must if you need to print something from e.g. in the middle of an article. Copying the text and pictures to a separate document to print instead of just making a selection is REALLY much more difficult.
Created attachment 9905 [details] Patch to print selection Attached a patch to show how one could easily enable printing of only the selection, through the use of a second KHTMLPart. Probably not most efficient methodology, but would be simple to do.
Patches are good. But I rely soley on a released binaries as this is the families' SUSE 9.1 PC. KDE is a spectacular GUI. But misses (arguably) vital but not-so-glamourous user features like this. Michael
*** Bug 101545 has been marked as a duplicate of this bug. ***
So, is the patch ok? Or.. ?
What is the story? Does this patch work what does "show how one could easily enable printing of only the selection" mean - so the patch does not actually do this? But just shows how it could?? Please clarify. Thanks.
*** Bug 113095 has been marked as a duplicate of this bug. ***
This feature request is still valid in kde-3.4.92 (beta2)! This is a really important and needed feature! So *PLEASE* implement this into the KDE Print system (at least for konqueror to print webpages)
I agree, but no one has written the code for it. Maybe for KDE 4.0 we'll get a chance.
Thiago said: > I agree, but no one has written the code for it There is a patch in comment #8 (though I haven't tried it... yet).
*** Bug 122975 has been marked as a duplicate of this bug. ***
Created attachment 16448 [details] khtml-print-selection.patch > --- written by Thiago Macieira 2005-10-30 01:37 > I agree, but no one has written the code for it. Maybe for KDE 4.0 > we'll get a chance. Okay, girls'n'guys... I've just created a new patch for kdelibs-3.5.3 to add this print-selection thingy to khtml. This patch definitly works and it should also apply to further versions. Maybe it could be possible to add this to the official release now, because you don't need to write the code anymore? *g* Sincerely Alex
The attached patch works fine for me, thanks dma147. Can we get this into the kde sources, please?
The patch is fine for me too (so far!). But I think it would be better in the end if it is the default to print selection only, when there is a selection. This would also be like kmail, where having text selected causes a "reply" action to contain only the selection. In any case, please do get this functionality included soon in the main sources! And thanks to its provider.
I'm running 3.5.4 and this functionality isn't there...?
there were so much changes and fixes in khtml with kde-3.5.5, but this still isn't there. very sad...
funny, developers want patches, now when patches are provided, they are not included... No wonder KDE 4 will be a vista killer... "print selection" is a must if you have a printer...
Could someone _please_ include that patch now? Can't be that difficult, can it?
From the usability point of view the patch doesn't meet the requirements. Look where that option is located most times, it's where "page-selection" is placed in the dialogs. Perhaps that is the problem...
Very old wish... I hope after more than five year anybody has the time to solve this.
I've given up this hope... Firefox does this job now... and Firefox does it very good.
And how your comments help making Konqueror better? By making developers angry -- this is your help? There tons of wishes for Konqueror (or any KDE app) and believe me each developer has only 24h a day. If you cannot be productive -- stop complaining. Better such "help" that annoying comments. [ sorry everybody, but I am already sick of such "wisdom" thoughts as above ]
Regarding comment #28: if you actually look at the rest of the comments about this bug, you'll see the author _has_ been productive and has provided an adequate patch, with positive results from several users. But in half a year, nothing's been done with it. This feature is so simple and useful and in-demand as this, I'd be interested to know what things developers are doing that's got a higher value/hour rating than just getting this patch included! This is so very useful a feature that it's more important to have it than to worry about whether the placement of the checkbox is in the best place possible (comment #25). I initially read #27 as a provocation. But it's actually quite useful too, as it's good for us to know that another program we're likely to have can do this task if we want to print a few pages of a long long webpage without either editing the html or having to patch and recompile KDE! It's also unsurprising that someone would be annoyed after writing a patch and having nothing done about it even though it's so much in demand. What more "productive" work is expected?
Well, I don't agree with just placing a new option "somewhere" only because it was requested long time/often. It is very important for the success of kde and the whole open source community and its applications that there is a consistent easy to follow interface. Maybe we could say "that doesn't matter, the essence is, that we have that option", but then we could also say "this systems are for cool hackers not for the everyday users". I tried the patch and I had difficulties finding the option. I am sure some non-coder/"just user" would have gone crazy searching for it. So, I think usability DOES matter!
usability-wise having a hard to find option is better then having no option at all (the former can be used, the latter cannot). Yes having the option in the best carefully considered place would be even better, but that's an incremental improvement that can be done in a future second step with no problems at all
First, thanks to Nathaniel Taylor for defending me and my comment #27. I'm absolutly with you and you've seen my comment in the correct way. About comment #30 I have to say, your generally right, but isn't it better to have this feature somewhere then having it not at all? Well I'm not really very good in programming in C/C++. Or, to say it more exactly, I don't know c++ at all, I only know a little bit of C. But I was totally frustrated about the incapability of the kde-developers to add this feature, so I've tried to create this feature by myself and to provide a patch for this, so that others can take advantages of it. As I said, I don't know C++ at all. So I was not able to really *control* where this checkbox appears. So everyone can see programming such a feature or providing such a patch isn't very difficult. The thing is, to find out how to get this checkbox on the right place. Everybody who can one or more programming languages or scripting languages can also provide such a little patch in C++. You only have to sit down and to really try it. Well... sorry about my bad english, I'm german and my school-days, where I've learned to speak in english are long, long time ago. *g* I only wanted to point out, that it isn't very difficult. There must be someone with a greater skill in C++ who should be able to add a patch which creates this feature and the checkbox on the right place... ^^
What I meant is that when we have that option built in the wrong place it could easily be forgotten and makes the overall usability of kde worse (in combination with alike "misplaced" features). So it should be placed in the right place the first time it is implemented. I don't mean that this patch is bad, it just needs some more tweaking :) btw, what about kde4? Perhaps there is already a solution to this matter, anybody tried the snapshot, is there an option to print selections?
Am Donnerstag, 4. Januar 2007 12:38 schrieb geroxp@web.de: > btw, what about kde4? Perhaps there is already a solution to this matter, > anybody tried the snapshot, is there an option to print selections? Erm, as this wishlist request is pretty old (and I am asked about this "missing feature" by newly-converted Linux users on a regular basis), the outlook that this *might* be in kde4, a version whose release schedule is not yet even decided about, seems like a cynical "Durchhalteparole". We do have a patch, which basically does what it should. We really should add this to kde3.5.6, no matter where exactly the checkbox is.
Ok, we all know Alexander did a good job, but that's it, it has to be better. And I don't understand what you are saying -- Martin, Nathaniel, Alexander -- "put the checkbox somewhere and let somebody fix it later". Guys, this report is not the only one, so multiply it by 10000 -- then read "put some ten thousand widgets in some random places, then be prepared for 10 thousand new reports about awkward GUI than fix those ten thousand bugs". Who has time for this? What do you want to do? Kill developers? The will is not a problem, TIME is a problem. I am not even KDE developer and I hardly can find time to post all my wishes and believe, sending reports is much easier. Currently you have no moral right to complain -- because somebody has to do extra work and if I am correct, slave times passed long ago. My suggestion -- could we all just sit and wait for volunteer with skills, time and will to polish the patch. Complaining does not help at all. I hope this is the last non-technical post.
I will see what I can do to get a feature like this in KDE4. Though I think I would put is as a context option on selected text (the same way you can select text to reply to in KMail).
Am Donnerstag, 4. Januar 2007 13:44 schrieb Maciej Pilichowski: > Guys, this report is not the only one, so multiply it by 10000 -- then read > "put some ten thousand widgets in some random places, then be prepared for > 10 thousand new reports about awkward GUI than fix those ten thousand > bugs". Who has time for this? What do you want to do? Kill developers? My understanding was the "votes" system in bugzilla was to give developers a hint what problems are most urgent and should be done with priority. There are "wishes", and there are "showstoppers", e.g. a bug or missing functionality that is essential to a modern Desktop enviroment and is or will be used by thousands of users on a regular basis. Unfortunately, those are are not handled as such in the KDE community. This clearly is a "showstopper". Unfortunately, a there seems to be a consensus on how to handle problems like this, which goes something like Step1: "We don't care/don't have time for this, but feel free to submit a patch" (aka: Learn C++, parasite sucker) Step2: "Thanks for submitting a patch. It is unusable." (aka: this does not run conform our esoteric coding practices, bad luck, sucker) Step3: "Maybe this will be included in KDE7... so don't give up your hopes..." (aka. The saviour will come) Alternate Step3: "Maybe if you'd pledge to pay for it, I might consider thinking about this problem" (aka. the "we are not motivated enough"-approach). I am a commiting member of KDE, as I actually report bugs, and try to be as helpful as I can be without knowing about C++. I am quite aware that time is not endless. I am also aware that I don't have a "legal right" for bugfixes. However, it pisses me off to see work (coding, bugreporting, suggesting, ...) being ignored because of threadbare reasoning. KDE imho would be better of with less "this is not 100% perfect" and more "this is frequently requested and works 95%". Sorry for the rant, but 1) it somehow belongs to Maciej's ignorant post, and 2) as a mere "user" I am in no position of writing to a more appropriate platform (like planet KDE)
---- in Comment #36 Allan Sandfeld wrote: > I will see what I can do to get a feature like this in KDE4. Though I think I > would put is as a context option on selected text (the same way you can select > text to reply to in KMail). Well, that's a word! ;) I'm sitting like on very, very hot coals, as we say in german. *g* Which means, that I can't wait anymore for kde4!!!111oneeleven ;)
The patch provided may not meet/comply with whatever standard KDE has hence it's exclusion. I for one don't care. If it's a small hackish step forward, take it. A less hackish feature may come along once the issue has more visibility. May I suggest promoting the patch to package maintainers for distros? The enhanced visibility will do no harm.
You can also try and convince the distros. They all have their own bugzilla databases and equivalent.
@ Allan: When you work on a "context option for selected text", maybe you can consider these points: (a) don't limit it to text, include images (and other stuff) as well (b) include a "View selection source" (like Firefox does, and which is the reason why I have to use FF instead of Konqui on some occasions) @ Martin Fabian: Your definition of "showstopper bug" is not quite on spot. See http://en.wikipedia.org/wiki/Showstopper for a "bug which prevents a project from going forward, as opposed to a minor bug which can be documented and coped with". This one certainly isn't a showstopper, and every single KDE user has coped with it so far. I personally print a *lot*. I personally have now added my votes to this bug too (I would *love* to see this functionality), but I still do not regard it as a "showstopper".
I think, too, that this feature is not an important, basic feature, without them nothig works, but it is a big we-want-it-really-feature.
Brief thoughts: Good to hear it might get in to the not-too-far-in-the-future KDE4. I do think the inclusion of an option in the print menu in the current place or the "page selection" would be good as well as a right-click menu option. People have such different ways of finding things, and I watch some who love right-click menus, others who always look for options in dialogue boxes. Agreed, though a "showstopper" for someone wanting to print a selection, certainly it's not a showstopper for konqueror or KDE. The definition of what's a good place to put such an option varies of course between people. I don't actually think the current place at all bad -- it's quite relevant to ink-saving and so on -- but the "page selection" area is probably better. Since the addition of this one extra option can hardly hurt any user who doesn't find it, but would delight us all, I agree wholly with all those who take the "better than nothing" line. This view would of course be wrong if the proposed change could plausibly cause adverse effects to the usability of other features of KDE. Presumably it is this distinction between changes that cause added confusion and those that don't that resulted in the foolish suggestions that the slightest inideality is justification for not changing anything. My main point is about the process of selection of what bugs to choose to deal with, and of how people reason things on this sort of discussion list. This is not of further direct use here since we now believe that the change _will_ be made, and have an idea of _when_. But I think it's important to try to promote discussion with substantiation given when reasonable, rather than the ridiculous comment about arbitrarily assuming that adding one feature with a possible small bad-point implies introducing about 10000 similar small problems... - A bug with a high benefit/cost ratio (perceived overall advantage to users, versus expected time taken to make the change) is the obvious one to choose to work on, and it's hard to see what other bug could be so high on this scale as one that so many people are asking for, that has such obvious usefulness, and whose only required work is to include an already provided patch possibly after moving one check-box to an allegedly better place. - I can well believe that time is very very limited (and I thank developers very much for their time). But, any time that a claim is made that there are so many other things to be done, or that "if they introduce this, then they'd have to introdue 10000 other little changes and their problems too", it's a little like hearing politicians, or newspaper reports of "research": there's no mention of any details by which we can substantiate the claim that there are so many other similarly important things to be done. I'd be quite impressed if even just one thing, let alone many, with a higher benefit/cost ratio can be found in khtml requests! Of course, this "benefit" depends on the person, since some might have fallen for example for the notion that making everything "translucent" and 3D is the most important possible thing for usability, perhaps connected with the egregious subject of the paper http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt). Anyway, I've found it improbable that a more useful few-minute piece of work currently exists, but I'm willing to be convinced otherwise. Thanks Alexander for the patch I'm using, and Allan for the offer of an inclusion.
I've just tried a recent version of konqueror (3.97.1 (KDE 4.0 >= 20071206)). In the "print dialog" there is a disabled option labelled: "selection". Is this feature planned?
On Tuesday 11 December 2007, FiNeX wrote: > ------- Additional Comments From finex finex org 2007-12-11 15:15 ------- > I've just tried a recent version of konqueror (3.97.1 (KDE 4.0 >= > 20071206)). In the "print dialog" there is a disabled option labelled: > "selection". Is this feature planned? This is because in kde4 the qt printing system is used instead of the kde one, and the porter of konqueror probably forgot to turn that option off.
So, basically, all hope is futile? ;) So, basically, all hope is futile? ;)<br>
On Thursday 13 December 2007, Martin Fabian Hohenberg wrote: [bugs.kde.org quoted mail] No, not that I know of.
*** Bug 11823 has been marked as a duplicate of this bug. ***
*** Bug 37702 has been marked as a duplicate of this bug. ***
wow, what a bug odyssey. And still there is no print selection option in KDE4.1, which is really sad, as the number of use cases is huge. (but it's not different with FireFox, just search for "resolve IP address behind proxy" for some really old bug that is still being largely ignored) In the old frame-days, I could work around this and just print the current frame and get 99% (or rather 120%) of what I needed. Now, in CSS-times (which is a good thing but not in this case;), web pages are cluttered with links, related stories, advertisements, and a rats tail of comments. So usually when printing a blog entry or article, you end up with a lot more than you want, therefore being able to *select* the actual article text and print only that is pivotal. Many sites still do not provide adequate "print" functionality (print CSS or similar), so this feature is now more important than ever. Please, Konqueror folks, do this fine browser and its fan base a favor and supply a little patch that adds this functionality. Heck, even IBrowse1.0 on Amiga could do that I think;) (sorry couldn't resist;)
Wow, a saga indeed, when it all could have been so much simpler. The patch above goes about this the wrong way by adding a 'Print Selection' tick-box to the HTML Settings tab on the KDE3 print dialog. Print Selection is in fact a standard feature of the KDE3 print dialog, and of the Qt print dialog used in KDE4. So the solution goes something like: 1) When Print action is triggered, detect if a section of the rendered page is selected by the user. If so, when creating the print dialog, set the print option PrintSelection to on and pre-select the radio box to be on. The dialog will then appear with the standard Selection radio button displayed and enabled by default, allowing the user to simply press enter to print the selection. 2) On return from the print dialog, check if the PrintRange is set to Selection, and if so then just print the selected part of the page using the standard KHTMLPart functions for returning the selected part of the page. You can probably do all this in less than 10 lines of code. The only slight difficulty is do you want to print just the plain text, or just the HTML formatted text, or do you try print it as full HTML with images and everything? That could be a user selectable option. So, if people can give me some feedback on the behavior they expect vis a vis what actually gets printed, I'll be happy to implement this in 4.3.
John, thanks for taking this bug. I would prefer the third option: print selected text with html formatting including images. This is the way a user would expect how it will work. Also, I think this is the way it works in other browsers like ff, opera, chrome etc.
> 1) When Print action is triggered, detect if a section of the > rendered page is selected by the user. If so, ... 1.a) if no -- disable this radio button > The only slight difficulty is do you want to print just the plain > text, or just the HTML formatted text, or do you try print it as > full HTML with images and everything? That could be a user > selectable option. Print exactly what is visible (in scope of page, not window) because: a) of common sense b) of other reports -- they will be fixed sooner or later and then if you put such options you would have to rebuild the print feature again, so it is better to do it right for once and focus on the reports about limiting visible objects (i.e. turning off images, for example, like opera) c) WYSIWYG ad.b) so if images are turned off, print the page without images, if they are on, print them too, etc., so user should get copy of the page on paper, this is what printing means
I don't see a Print Selection QT4.4 in KDE 4.2.1, so I think this issue is still valid (In reply to comment #51) > Wow, a saga indeed, when it all could have been so much simpler. The patch > above goes about this the wrong way by adding a 'Print Selection' tick-box to > the HTML Settings tab on the KDE3 print dialog. Print Selection is in fact a > standard feature of the KDE3 print dialog, and of the Qt print dialog used in > KDE4. > > So the solution goes something like: > > 1) When Print action is triggered, detect if a section of the rendered page is > selected by the user. If so, when creating the print dialog, set the print > option PrintSelection to on and pre-select the radio box to be on. The dialog > will then appear with the standard Selection radio button displayed and enabled > by default, allowing the user to simply press enter to print the selection. > > 2) On return from the print dialog, check if the PrintRange is set to > Selection, and if so then just print the selected part of the page using the > standard KHTMLPart functions for returning the selected part of the page. > > You can probably do all this in less than 10 lines of code. > > The only slight difficulty is do you want to print just the plain text, or just > the HTML formatted text, or do you try print it as full HTML with images and > everything? That could be a user selectable option. > > So, if people can give me some feedback on the behavior they expect vis a vis > what actually gets printed, I'll be happy to implement this in 4.3.
*** Bug 205907 has been marked as a duplicate of this bug. ***
9 years.... 9 fscking years and nothing being done for something as simple as this... pathetic. How can i remove myself from this useless thread?
It would be less "pathetic" if you could provide a patch. Useless is your comment.
I'm not a/the programmer/developer here. I'm one of the people who actually put in effort in finding this issue and reporting it. Please direct your comment to the actual developers or programmers. In the mean time, if there's a way to remove me from this thread please tell me, as it's going no where and i've long switched from this silly "browser"
> I'm not a/the programmer/developer here. Then who do you think it is? Who did you pay to be "a/the programmer/developer" for you? > I'm one of the people who actually put in effort in finding this issue and reporting it. Oh yes, finding and reporting bugs in software is hard work. Much harder than developing it. Right. > if there's a way to remove me from this thread please tell me Just log in, go to the bug page, select your address in the CC list, check the box Remove selected CCs and press Commit.
Hey guys! I'm currently testing (and translating as well) KDE 4.5 and still no possibility to print selection. No news since sep 2009 so I'm refreshing memories just in case. This function should be very usefull (particularly with modern website where there's many publicity, frames, etc. that you don't want). Some peoples on KDE IRC channel are saying that it should not be to hard to develop. I hope they're right! The option to print the selection as simple text when no graphic is selected is an other interesting idea along with this feature request. I'm not CPP dev so sorry can't do nothing more than that :)
Well, I did investigate as promised, and adding the framework to choose Print Selection was easy, as was making it print a Text version of the selection. However there was no similarly easy selectionAsHtml() method to use, and building one would require an in-depth knowledge of khtml and the dom that I don't have the time to achieve. The consensus was a text only feature would not be desirable, so I had to put it aside. For the record, the interesting methods in KHTMLPart are: bool hasSelection() const; virtual QString selectedText() const; QString selectedTextAsHTML() const; DOM::Range selection() const; void selection(DOM::Node &startNode, long &startOffset, DOM::Node &endNode, long &endOffset) const; What is needed is a way to take that DOM::Range and transform it into a form that can be passed to the standard KHTMLView::paint() code to have it renevered onto a QPainter. However khtml is such a complex code base I wouldn't even know where to start.
Well, the starting point would be defining what such a feature would be supposed to do in the first place --- think of cases like selecting of a single column in a complicated webpage, or of a selection starting from the middle of a line, etc.
omg i lost a lots of time to print a selection ... -.- why this isn't fixed downloaded firefox... and printed rekonq konqueror chrome = no way