iconview behaviour changing, possible or not?

[David Faure]

On Friday 10 December 2004 17:14, Unai Garro wrote:
> Hi there,
> 
> I'm trying to figure out a way to make konqui's iconview behave differently 
> (as a repository browser) on cvs/svn directories. Would that be possible?
> 
> I'm used to tortoise-svn at work (on winders, unfortunately), and I have to 
> admit it works impressively nicely. You get into a repository folder, and 
> immediately you're shown if a file is changed or not, rmb menu shows 
> commit/update options... 
> ( http://tortoisesvn.tigris.org/images/ExplorerView1.png )

Your mail subject and this screenshot don't describe the same thing at all.
I thought you wanted to reimplement konq_iconview, but in fact the iconview
is fine, it's *only* the popupmenu that you want to customize, right?

> Kparts are nice, but then I would need to duplicate the whole konqui iconview 
> behaviour completely. Maybe there's a way to inherit the current konqui kpart 
> and do some changes to it? 

If this is only about the popupmenu, you don't want to touch the iconview at all,
only the popupmenu - those things are unrelated in konqueror.
KonqPopupMenu accepts plugins - you can write a plugin for the popupmenu,
see e.g. kdeaddons/konq-plugins/arkplugin or akregator.

From a later mail:
> Konqui would need to dig into every directory, search for 
> <dirname>/.svn directories and check if any file has been changed since the 
> last update. Then an icon would show if the directory is up-to-date or needs 
> committing.
OK, the best way I see to do that would be
1) split konqueror/iconview into a library + a part (so that it's possible to link to KonqKfmIconView)
2) add a virtual method createFileIVI which simply calls new KFileIVI like done now
3) add a KFileIVI constructor which takes a pixmap (or icon name) instead of
requesting it from KFileItem::pixmap
Then in your KonqKfmIconView reimplementation you can create KFileIVIs with
a different pixmap than the default one.

I think that Kevin Ottens was also thinking about a KonqKfmIconView reimplementation
for another purpose (media:/) so this might be a good way to go indeed. Of course
we should also ensure that this class is ready to become public API - d pointer,
virtual hook, making member vars private instead of protected, etc.

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).