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

List:       kfm-devel
Subject:    Re: konqueror
From:       Simon Hausmann <shaus () uermel ! Med ! Uni-Magdeburg ! DE>
Date:       1999-09-06 13:16:28
[Download RAW message or body]



On Mon, 6 Sep 1999, Dirk A. Mueller wrote:

> Simon Hausmann <shaus@neuro2.med.uni-magdeburg.de> wrote:
> 
> > All in all I'm more or less happy with Konqueror - it is fairly stable
> > for file management, and it can finally sort files :-)))
> 
> Well, the main problem I see is the lack of speed. Most people find kfm
> too slow. But Konqueror is currently under the same setup 2-3x slower
> than kfm. In my opinion the current situation is absolutely
> unaccepable.
> 
> I currently don't understand much about KOM/OP/MICO, so I don't know
> where's the problem. But anything that will improve performance should
> have high priority.

I agree that Konqueror tends to lack performance, however I don't think
that this is only CORBA's fault.

I guess that one of the reasons for the lack of speed is the extremly
flexible io sub-system we use. There are lots of layers between listing a
directory or getting a file and the actual response in the GUI.

One example is when listing a directory. Another one is the mime detection
when opening an URL. Both are very complex actions and I think with the
current implementation we *avoid* a lot of code duplication (just think of
the usage of KDirLister) and gain big flexibility. This results in a great
design IMHO, but probably with the price of performance.

One thing I could think of is to possibly hack KDirLister to avoid using
kio_file for local files and use direct access instead.

That's just my humble opinion/impression, I might be wrong :)

> Is it right that OpenParts is a "Qt GUI binding" for mico?

Yes, that's quite true :)

> [kded]
> > that beast seems to work, but more and more people report problems
> > and I admit that I frequently delete my
> > ~/.kde/share/config/kregistry, too
> >: (
> 
> right, we need more error-recovery as well as bugfixing.
> 
> >   ..structure . What do you think about discussion such a
> > re-organisation?  Or should we stay with the current treeview?
> 
> I don't know if it is possible with the current tree-view, but it would
> be great to add permanent and temporary nodes like "FTP connection to
> xyz.org" and browse in it as if it would be a local filesystem. should
> be easy to implement with the current ioslave-feature.

I 100% agree with you, and I'd really like to see this feature.

> i.e. whenever we're accesssing something non-local, it should be
> possible to see the thing we're downloading in the treeview. and if it
> is downloaded, the user still has the ability to copy it to somewhere
> else.

Yes, that's another point we still have to improve IMHO. The visual
feedback is still far from being perfect, although I admit that I'm quite
happy with the progress bar stuff.

Ciao,
 Simon

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