Version: (using KDE Devel) Installed from: Compiled sources Hi all, when one queries a manpage that exists multiple times on the system, the man:/ ioslave shows a list with all manpages found. Similarly when one simply queries "man:/" or man:(number) another list is generated. In that case it would be nice if the man:/ ioslave provided access keys in its html output. I'll attach a patch implementing this shortly.
Created attachment 9626 [details] provides access keys in html output for man:, man:(n) and man: with multiple hits This patch makes 1. the matching manpages list (for several equal named manpages), 2. the manpages sections list (i.e. 'man:') and 3. the section lists (e.g. 'man:(2)') more accessible by providing access keys for 1. all hits, 2. all section numbers and 3. all letters (with at least one manpage) when displaying a section, respectively. there is still a TODO item : I wasn't sure whether to put a new CSS class into kde-default.css (where kio_man takes other stuff from) or to create a seperate stylesheet (like kio_finger does). So I simply put a style-attribute directly into kio_man.cpp (where it shouldn't stay IMHO). Also there has been an #ifdef _USE_QSORT in the code which seems to allow, if commented out, a custom heap sort implementation to compile. I have also completed the code path for that case, but couldn't test it, since that code doesn't compile anyway. Well, I hope this is useful
Created attachment 9631 [details] same as above, but doesn't rename file this one doesn't rename kio_man.cpp
Too bad that the patch was never applied or even commented! From what I see, the access key is not the number of the man page section. Would it not be better? (Isn't it curious for example to type 1 for having a page in the 3th section? I do not know really know I have not tested it yet.) As for insensitive search, I really think that this is a trap. For example Qt's man pages exist in two versions, one with uppercase like the Qt class name and one fully in lower case. Have a nice day!
>From what I see, the access key is not the number of the man page section. But it should be. Otherwise it's a bug of my patch. However there are not only man page sections named with a single decimal digit (like "1" or "8"), but also special sections ("n", "3w" "3qt" or thelike). My algorithm tries to get a single character as an access key - it just takes the last letter of the section code ("1"->"1", "3w"->"w") This is indeed not very sophisticated (maybe it's completely bogus...), but it should at least get the trivial cases right. Maybe a good solution would be to only get the standard sections (i.e. 1..9) right and just forget about the others in case there were ambiguities otherwise. >As for insensitive search, I really think that this is a trap. So do I. But since Konqueror (khtml) isn't case sensitive in regard to access keys I was a bit stuck. Probably other browsers a similar. This is really a regression especially in your use case. How about sorting like this "AaBbCc..." instead of "ABCabc". This would be a bit trickier to implement (as you can see from the patch I just lazily replaced those "qstrncmp" with "qstrnicmp"), but it would be case sensitive at least. BTW, are the qt man pages really needed with lower case file names? I know that the uppercase ones are links to them, but anyway.
I have tried to play with accesskeys but Konqueror do not seem to work with them. Too bad! So this patch is going to sleep again. Have a nice day!
Hmmm. As I learnt from trying it, this patch doesn't apply cleanly to recent svn. Modifying it a bit so that it compiles I can see some misbehaviour, namely the listing of a section shows a few somehow bogus access keys. But otherwise it works. I'll try to eliminate the problem and will post an updated patch ASAP
Created attachment 11196 [details] this one works with current svn head I have looked into the problem with those bogus additional access keys appearing in section lists. As a rule every character that hasn't been assigned as an access key by my code appears as the access key of one of the first manpages listed. Digits included... The really strange thing is those access keys do *not* appear in the html code but khtml seems to add them. Just look at the page source. Nicolas, I have still not addressed your concern about case-insensitive manpage sorting but I will hopefully have time for this soon.
As I just learned from reporting my findings as another BR this seems to be a feature ...
See http://lists.kde.org/?l=kfm-devel&m=111296590628785&w=2 . There's a patch that assigns all characters not already used as access keys as (you guess it) access keys. It's already applied :-(
On Wednesday 25 May 2005 17:10, Andreas Leuner wrote: (...) > Nicolas, I have still not addressed your concern about case-insensitive > manpage sorting but I will hopefully have time for this soon. In the meanwhile, I am not sure anymore of what I said. So if you have a version that is case-insensitive, it would be a nice thing. I suppose that anything in a direction of an index is a positive thing (as an index can be done with "normal" HTML too, not only with accesskey.) Have a nice day!
>So if you have a version that is case-insensitive, it would be a nice thing. My modified kio_man produces output like this (from Bug #106280): http://bugs.kde.org/attachment.cgi?id=11197&action=view >anything in a direction of an index is a positive thing Wow, that's really true. Looks like I didn't really get through this thing ;-) Such an index would easily fit into the top and/or bottom of the page. I'll add this soon.
On Friday 27 May 2005 13:16, Andreas Leuner wrote: (...) > My modified kio_man produces output like this (from Bug #106280): > http://bugs.kde.org/attachment.cgi?id=11197&action=view That looks good. (I am just not sure about the horizontal line. If there are many letters with just an entry, it will probably not look so good.) (...) > > >anything in a direction of an index is a positive thing > > Wow, that's really true. Looks like I didn't really get through this thing > ;-) > > Such an index would easily fit into the top and/or bottom of the page. I'll > add this soon. Better at the top, I think, that is theplace where it is useful. (But perhaps a "go to top" link at the bottom. MfG
>(I am just not sure about the horizontal line. If there are >many letters with just an entry, it will probably not look so good.) At least I can make the output use a stylesheet (like e.g. kio_finger does) so there could be a sensible default look. I initially wanted to do this anyway. BTW I am not so sure about the line either - so feel free to change the soon-to-be-there stylesheet.
Created attachment 11233 [details] provides access keys for man:/ kioslave this version provides an alphabetical index at the top of the page of a section list. Access keys are assigned there, so their tooltips can be made immediately visible when the page was just loaded. Note that the stylesheet is needed for the index line to appear at the top of the page. Page style is handled by a new stylesheet to be placed under KDEDIR/share/apps/kio_man/. The makefile.am is modified accordingly by this patch. The stylesheet itself will follow (since I couldn't convince "svn diff" to include it in its output). There is still no "go to top" item - so there are no new strings to translate and thus this stuff could maybe go into kde 3.4.x. It could be added later, however.
Created attachment 11234 [details] Stylesheet for kio_man. Feel free to change class secidxnextletter to remove the table row's bottom border.
I am going to commit the patches. I have just found a problem: you have used QFile::encoded to put a file name to a stream, which is not good. (KHTML should get the name as UTF-8 and then decide itself to do what is needed.) (Otherwise there are some minor details, like a few more const and avoiding QString str = "" but I am going to correct it thereafter.) Have a nice day! PS.: as for the "go to top" button, it might be useful too after each letter section.
SVN commit 419137 by goutte: Add an index for the section list (with HTML access keys) (Patch by Andreas Leuner) CCBUG:99384 M +4 -0 Makefile.am M +87 -19 kio_man.cpp A kio_man.css
SVN commit 419149 by goutte: A few simplifications: - use "const" on a few QStrings - get the path for the kio_man.css file only one time at start - construct the <link> to kio_man.css on the fly when writing to the string - limit the i18n() to the real text (especially if the tags are unbalanced) - do not use QFile::encodeName when it has to be given as QString to the stream - make "static" the function sectionName - use const_iterator (as it seems more portable to Qt4) - use ++it instead of it++ for iterators (Partly follow-up of bug #99384) CCBUG:99384 M +38 -52 kio_man.cpp M +1 -0 kio_man.h
Hey that's quite a lesson in C++ :-) (regarding the const's) Thanks for committing. BTW I took the css loading stuff from kio_finger (except the "idea" to load it everytime) so maybe your corrections would also fit there. What happens if that i18n() gets fed with html markup ? Will the translators also have to put the markup in their stuff? or is it ignored? I could have looked ;-)
On Sunday 29 May 2005 17:03, Andreas Leuner wrote: [bugs.kde.org quoted mail] One advantage is that const helps the compiler, so that the compiler can know it is not changed and perhaps find a way to further optimize the code. > Thanks for committing. > > BTW I took the css loading stuff from kio_finger (except the "idea" to load > it everytime) so maybe your corrections would also fit there. The problem is that now kdebase is in branches/work/kde4 too. If I had know it already when commting, I would have not made the improvements, because now somebody has to port them to KDE4 (including the comitted patch). > > What happens if that i18n() gets fed with html markup ? Will the > translators also have to put the markup in their stuff? or is it ignored? I > could have looked ;-) The translators have to translate everything in i18n(). So if there is markup,they have to translate too. Aparently this has given problems in the past, so the prefered rule is to let only the raw text translatable. Have a nice day!
This has been implemented years ago as the comments show, time to close it.