Bug 98092 - khelpcenter's Browse Info Pages>Alphabetically>(any initial) isn't sorted
Summary: khelpcenter's Browse Info Pages>Alphabetically>(any initial) isn't sorted
Status: RESOLVED FIXED
Alias: None
Product: khelpcenter
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: RedHat Enterprise Linux Linux
: NOR normal
Target Milestone: ---
Assignee: Cornelius Schumacher
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-01-28 18:33 UTC by Joe Christy
Modified: 2008-08-18 10:34 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Joe Christy 2005-01-28 18:33:13 UTC
Version:            (using KDE KDE 3.3.1)
Installed from:    RedHat RPMs
OS:                Linux

The problem occurs in a fully updated (as of 2005-01-28) Fedora Core 3 installation (the only systems I have running KDE). cf. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=146377

Description of problem:
Browsing Info Pages > Alphabetically > <some initial> displays a long,
unsorted list of entries

Version-Release number of selected component (if applicable):
3.3.1-4.3.FC3

How reproducible:
Every time.

Steps to Reproduce:
1.Launch Help within KDE
2.open "Browse Info Pages" sub-menu in "Contents" sidebar
3.open "Alphabetically" sub-menu
4.open any sub-menu for a particular initial, e.g. "B"
  
Actual results:
A nearly useless long, unsorted list of entries appears

Expected results:
A long, helpfully (alphabetically) sorted list of entries appears.

For example the Browse Info Pages>Alphabetically>B submenu appears as:
bzero
btowc
bsearch
brk
bindtextdomain
bind_textdomain_codeset
bind
bcopy
bcmp
basename
basename
backtrace_symbols_fd
backtrace_symbols
backtrace
BUFSIZE
BRKINT
BC_STRING_MAX
BC_SCALE_MAX
BC_DIM_MAX
BC_BASE_MAX
bison
bibtex
basename
bash
Binutils
Bfd

Upon further examination:
1) this doesn't seem to have anything to do with
http://bugs.kde.org/show_bug.cgi?id=43815 - the codebase has changed quite a bit since then, and that bug concerned merely an inverted sort order.
2) The sort (dis-)order is stable across invocations of khelpcenter. I haven't been able to reproduce the sort (dis-)order of the list of entries under D with any other tool.
Comment 1 Tim 2006-07-16 23:04:58 UTC
the following patch should fix the above issue, it now works fine for me. It would be great if we could have it in KDE-3.5.4.


--- kdebase-3.5.3/khelpcenter/infotree.cpp.orig 2006-07-16 22:39:40.000000000 +0200
+++ kdebase-3.5.3/khelpcenter/infotree.cpp   2006-07-16 22:57:50.000000000 +0200
@@ -174,8 +175,10 @@

         item = new InfoNodeItem( alphabSection, appName );
         item->entry()->setUrl( url );
+        alphabSection->sortChildItems( 0, true /* ascending */ );
       }
     }
+    catItem->sortChildItems( 0, true /* ascending */ );
   }
   infoDirFile.close();
 }
Comment 2 Joe Christy 2006-07-17 04:57:23 UTC
This patch does _not_ fix the issue for me ( I rebuilt & installed kdebase-3.5.3-0.4.hc5.src.rpm w/ the proposed patch [modulo reversing the '@' -> ' at ' transform] added to the spec).

The sort dis-order for Browse Info Pages>Alphabetically>B is exactly as before.

Could it be that khelpcenter is caching the index in some (sigh - undocumented - sigh) location? I've tried strace -ff'ing it, but the 10 minutes I devoted to grepping through the trace didn't reveal anything to my untrained eye. When exactly does the alphabetical index of info pages get built anyway?
Comment 3 Philip Rodrigues 2007-02-07 19:54:33 UTC
Confirmed on svn r628k
Comment 4 Joe Christy 2007-02-07 21:51:37 UTC
FWIW, the problem does not exist in FC6's kdebase-3.5.5-0.4.fc6. This may have been fixed in an earlier rev, but I simply stopped using "Browse Info Pages>Alphabetically" while it was hopelessly broken and never tried again.
Comment 5 Harald Sitter 2008-08-18 10:34:30 UTC
Yeah, fixed indeed.