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

List:       kfm-devel
Subject:    Re: [patch] keditbookmarks listening to updates
From:       David Faure <david () mandrakesoft ! com>
Date:       2001-09-26 8:11:56
[Download RAW message or body]

On Mercredi 26 Septembre 2001 01:26, Alexander Kellett wrote:
> > Is that in order to tolerate the /321023810 (or so) address (for "append") ?
> > In that case, shouldn't that be in correctAddress() ?
> 
> No, i thought that maybe konqi should also get it rather than just
> hitting an assert? - also it reduces code a fair bit this way, i tried
> the other and it looked quite ugly.

Hmm, IIRC there's only a Q_ASSERT, which doesn't crash/exit the app, it only
prints a warning (unlike assert()). This is a "should NEVER happen" case,
so there's not much point in dealing with it there - if it happens we have to fix
the real cause for it.

> The /432493280 address is just an evil hack, i'd prefer a better
> interface to "end bookmark in root folder" but that was the simplest
> i could think of ;-)

What about /-1 ? Obviously we'd have to test for it at the right place ;)

> The patch to KBookmarkManager is more generic, and is just used to
> fall back on the parent folder if the current search fails, and
> numerous other things.

This sounds good, but for keditbookmarks in "adding something while the document
has been modified" mode. I prefer that, if someone makes a mistake with addresses
in keditbookmark's code (which is rather easy ;), he'll see the mistake at once, rather
than an automatic fallback happening behind his back (and possibly doing the
wrong thing). Only the merging needs fallback IMHO.

> (if needed then i could always make the correction stuff in kbookmarkmanager optional)

If that's simpler, in terms of code, than moving the code, you could do that
(i.e. a bool being passed to findByAddress, for instance),
 
> sorry yes, the other way around ;-)
> its not my normal way of commenting, 
> not sure why its like that in fact :)

Hehe ok, then ;)

David.

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