[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-edu-devel
Subject:    Re: [kde-edu-devel] patch for fix of bug 59365 and other issue
From:       Scott Wheeler <wheeler () kde ! org>
Date:       2003-12-14 21:01:34
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 10 December 2003 1:38, Afonso Arantes wrote:
> This patch should fix bug #59365 "item changed with update card isn't sorted 
> right"
> 
> What is happening is that the KListView::setFront() and KListView::setBack() 
> methods (probably inherited from QListView)do not force a resort. So if, 
> example, I change the front of a card from "dinosaur" to "zebra" nothing is 
> resorted. That means that the card with front "zebra" is now in between 
> "anteater" and "elephant."
> 
> As soon as the user inserts a new card or chooses a new sort order 
> everything is resorted and the updated card ends up in its proper place.
> 
> What I did was add an explicit call to KListView::sort(), in the routine 
> DataWidget::update(). This forces the sort order to be updated.
> 
> This can have the unexpected side effect of causing the card to vanish from 
> the screen. Let's say that Bob has a huge card list. He changes the entry 
> "Argentina/Moscow" to "Russia/Moscow." The result will be that the correct 
> location for "Russia/Moscow" will be completely off the screen. This is, I 
> believe, the correct behavior. The alternative would be to follow
> the modified card to its new location, possibly causing all the other 
> surrounding cards to scroll off the edge of the screen.

There's QListView::ensureItemVisible() for that.

> I also changed two calls like this:
> 
> -  cardListView->setSorting(cardListView->columns() + 1);
> +  cardListView->setSorting(0);
> 
> When flashkard first started up there was no default sort order and cards 
> were completely unsorted. This happened because there is no such column as
> cardListView->columns() + 1. Perhaps this was deliberate? It did not appear 
> so. The QListView documentation specifies that an unsorted list should
> be specified using setSorting(-1).

- -1 says that you can't later manually sort by a column, columns() + 1 isn't 
sorted by default, but the user can still force a sort by clicking on the 
column header.  And yes, this is intentional.

> In any case now this will cause the default sort order on startup to be 
> descending by first column. This can be changed by the user.

With this patch it can be changed to be sorted another way by the user, but it 
can't be set to be in the same order that the user entered the entries in.

I'll apply a modified version shortly.  (Sorry I've been slow to reply -- 
things are crazy busy lately...)

- -Scott

- -- 
For a successful technology, reality must take precedence over public 
relations, for nature cannot be fooled. 
- --Richard Feynman
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE/3M+uQu0ByfY5QTkRArGFAKDJhM8SCe7Nlyf7z6NqkAYPejMLkACgpT3H
wAFMzBFLyv4jBj0JqhLvj04=
=z/1A
-----END PGP SIGNATURE-----
_______________________________________________
kde-edu-devel mailing list
kde-edu-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-edu-devel

[prev in list] [next in list] [prev in thread] [next in thread]