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

List:       kfm-devel
Subject:    Re: KIconContainer
From:       Torben Weis <weis () troll ! no>
Date:       1999-03-26 2:07:29
[Download RAW message or body]

Hi,

On Fri, 26 Mar 1999, Michael Reiher wrote:

> 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.

A single click in the menu and everything is sorted again.

> 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?

As every feature: Just turn it off :-)

> > 
> > 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..."?!

What you described is a).
b) makes coding konqueror easier, but I think a) is better.

> > 
> > 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
 
> > 
> > Bye
> > Torben
> 
> Michael
> 
> 

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