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

List:       kfm-devel
Subject:    Re: KIconContainer
From:       Michael Reiher <michael.reiher () gmx ! de>
Date:       1999-03-25 23:07:45
[Download RAW message or body]

Torben Weis wrote:
> 
> Hi,
> 
> I worked some hours on tghis nice widgets.
> 
> The good news first:
> 
> It can now handle icons at any position. That is useful if someone drops
> icons. They should appear where they were dropped instead of popping up
> somewhere in alphabetical order.
Iīm not sure if I like that. Because if youīre looking for a file, you
do it following the alphabetical order. But if you have many files in
this directory you wonīt find the file because it sits somwhere else,
where you dropped it. So one would have to do a manual reordering, e.g.
hitting Reload, each time.
And btw I always liked it that the desktop icons were automatically
pressed into the grid. In Win9x you always have to do that manually by
selecting "Align to grid"(or what ever it is called in english).
Or am I getting something wrong here?
> 
> During DnD you see a drag shadow. You know that from Win95. It draws a
> wire frame to show how much space icons would consume and where they
> woul appear. That even works when DnD stuff from Konqueror to kdesktop
> or the oter way round and in contrast to Windows we dont get
> clipping errors.
Thatīs cool!

> 
> The bad news:
> 
> When kiconcontainer gets a drop of icons then it wants to position them
> where dropped. If the icons where just moved in the same window then
> kiconcontainer handles that on its own.
> 
> if it is a drag from another windows then it will somehow emit some
> signal telling Konqueror that a set of URLs has been dropped and it will
> tell the icon positions for the URLs.
> 
> Konqueror will now start Copying/Moving whatever. As Konqueror updates its
> view it has to remember that the new files have to be displayed at certain
> positions.
> 
> We do have two ways here:
> a) Konqueror starts copying and displays the new icons as the files are
> copied. Then Konqueror has to remember where to show them ( the position I
> mean )
> b) We show all dropped icons at once and start copying then. If not all
> files could be copied ( IO failure ) we have to remove all icons which
> do not have a corresponding file due to the IO error.
> 
> What do you prefer ? What would the user like most ?
Wouldnīt it be possible to take care of the copying/moving in the target
view? I mean the target view has to get to know the possitions of the
icons anyway. It could then initiate the transfer itself. It paints the
icon for a URL as soon as itīs copying is finished. There would be no
need to push the possition information around, and it should
automatically also work if a view is embedded somewhere.
I just wonder if you already intended to do it the same way? But you
always talk about "Konqueror does..."?!
> 
> Depending on this decision I have to specify a API for kiconcontainer.
> 
> The other bad thing: KIconContainer does not perform too well with
> 5000 icons or more in it. YES: People have so many files in
> directories. I KNOW: It is stupid to do so :-)
> However, Warwick suggested to use the technology of the upcoming QCanvas
> and that is QwSpriteField. It is a highly optimized canvas already and I
> am going to use it. Unfortunately that will cost me some additional time
> but we will have the fastest icon view around. You could even start
> playing asteroids with the icons :-)
Well, I would actually call that Good News:)

> 
> Bye
> Torben

Michael

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