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

List:       kfm-devel
Subject:    Re: konqueror
From:       David Faure <faure () kde ! org>
Date:       1999-09-05 15:29:26
[Download RAW message or body]

On Sun, Sep 05, 1999 at 04:27:34PM +0200, Simon Hausmann wrote:
> Hi,
> 
> first of all: David - welcome back hacking :-)
Thanks !

> From: Simon Hausmann <shaus@uermel.med.Uni-Magdeburg.DE>
> Reply-To: Simon Hausmann <shaus@uermel.med.Uni-Magdeburg.DE> 
First of all, reply-to headers make replying to a mailing-list harder
and doesn't seem to be necessary in your case ;)

> All in all I'm more or less happy with Konqueror - it is fairly stable for
> file management, and it can finally sort files :-)))
Yes. On that matter, though : it can't sort files as kfm used to do :
directories first, alphabetically, then files, alphabetically as well...
It's something I miss, and users will probably do as well.

> The plugin stuff is also ok IMHO, at least the view embedding works ok for
> a first run and the KOM plugin stuff is under development (btw, what do
> you think of the search plugin? am I the only one finding it useful? ;)
Hmmm, to the dummy konqueror user that I'm now again, can you tell
how to use it ? I've understood it's a meta-search-engine, as it queries
search-engines listed in konq_searcherrc, but how do I start it ?
I enabled it, but that doesn't seem to do anything...

> However there are a few things that need to be fixed for 1.89 IMHO:
> 
> - the profile management. Michael did a great job! But the stuff still
>   needs fixes. For example we have to modify the management to put the
>   whole complete profile information into one single KConfig group, in
>   order to use it successfully with the session management.
That should be very straight forward : it's a matter of transforming
[<group>]
<key>=<value>
into
<group>_<key>=<value>

Isn't it ? I can do that if you want ;)

>   And it looks a little bit unstable, meaning it crashes pretty often when
>   dealing a lot with removing/splitting :-)
I fixed the crashes when reading old or empty konquerorrc files, but if there are
other crashes, we ought to fix them, sure ;)

> - more view plugins...
>   IMHO it'd be cool to have more view plugins :-)
>   I had a look at aktion (doubtlessly the best video app for kde) and it
>   should be really easy to make it embed itself for videos, because it
>   contains a xanim-wrapper class which makes playing videos the easiest
>   thing of the world ;-)
Yes, kanim rocks.

>   We could write a separate view plugin component (and put it in the
>   plugin subdir) using this class, or we go another way (which I
>   personally would prefer): We could ask the author of aktion for
>   permission to put aktion into kdegraphics and then add the Browser::View
>   plugin stuff to it. What do you think?
That requires kanim to link against mico, + kbrowser.idl
Once again we have the problem that when used standalone, the application
becomes slower because of this corba extension which is not used in this case...
This is the same with kview. But I didn't really test : is kview slower
since it has had this plugin extension, or is it hardly noticeable ?

>   In addition it'd be cool if kghostview and kdvi would have similar
>   capabilities.
Sure...

> - I can't wait to see the new dom'ified khtml :-) Lars - when do you think
>   it is possible to switch?
> 
> - kded - *ouch*
>   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
>   :(
Ouch. I improved some error checkings there, but we should do more.
Next time it happens, can you send me your kregistry file ?

>   In addition we still have the problem of a recovery mechanism for a
>   crashed kded.
> 
>   I once worked on the recovery problem and I implemented two ways:
> 
>   - the first approach was pretty nice, but it didn't work as MICO refused
>     to free a CORBA::Object proxy which server object already died. I have
>     no idea why it crashed there, perhaps a MICO bug?
>     Hmm, Steffen, do you happen to know about a new mico release?
> 
>   - the other approach actually worked, but it slowed down the
>     kded<>client communication and it was *very* ugly (I re-connected to
>     the server upon every invokation :(
> 
>   Any ideas?
Not sure I have all the elements at hand ...
A simple thought is : kded should write its data in a file whenever
the data changes (doesn't happen so often, does it ? new corba app launched, ...)
and recover using this file. But this might be a bit simplistic ;)

> - the next point is very much related to my very personal taste ;)
>   I think we might consider doing a last big hack before 2.0 and discuss
>   about a possible redesign of the kded<->kregistry couple.
>   I *personally* am not that happy with it. Well, it works fine but the
>   API is somewhat strange IMHO, isn't it?
>   I mean: We tell other developers to use
>   KRegistry::self()->addFactory( new KServiceTypeFactory );
>   KRegistry::self()->load();
>   for mimetype/servicetype stuff and to use KTrader for KService data.
>   Hmmmm, isn't that inconsistent in some way?
I don't think so.

What we have is :

If you want servicetypes and services completely loaded in memory -> use kregistry and factories
(Needed for service-type recognition, like kdesktop and konqueror need, as well as kmail, ...)

If you want to query for a service -> KTrader

Different tools, different purposes.
It just turns out that most apps need servicetypes in memory and don't need
services in memory, they can query for them.

OTOH lots of apps need neither of those, do they ?

>   Wouldn't it be nice to have *one* API for both related issues?
>   I liked Torben's original approach of using one KRegistry for both,
>   services and servicetypes.
Not sure I remember... kregistry would query KTrader ? Seems to break
libs dependencies...

>   I mean: I wouldn't mind about keeping things as they are, but I fear
>   that other developers will start complaining about the fact that this
>   stuff is much too complicated and confusing (where to use kded? where to
>   use libkio?....
Perhaps we should write a better docu for this, explaining the difference a bit
like I did above.

> - request for opinions: what do you think about adding a
>   delete-selected-items button to the toolbar when the iconview/treeview
>   is visible?
Hmm ? Seems very one-feature-specific. Why delete and not "move to trash", then ?
BTW, I have been asked to make the delete key configurable in konqueror, in order
for paranoid/clumsy users to set it to "move to trash" instead of "delete".

> - cut&paste . I don't have regular access to a windows system, but I
>   recently saw the way how m$ implements cut&paste for file management,
>   and I think we might consider implementing this, too: when you cut items
>   from a iconview, the icons get greyed out. They do not disappear, but
>   they grey out. When pasting then, they get (of course) deleted.
>   What do you think about implementing this in Konqueror, too?
Would look neat. Does cut & paste work already (without this gray-icons feature) ?
Dawit, I suppose ?

>   Perhaps we should wait for this a little bit and go for the switch to
>   Reggie's QIconView first?
For the visual effect ? Yes, I think so. Wasted time otherwise.
Reggie, how is QIconView coming along ?

> - the treeview. I like Torben's widget very much, but I think we might
>   consider extending it a little bit. A pure file management treeview is
>   ok, but IMHO we should re-organize the tree structure a little bit. I
>   don't really want to copy that feature, but I actually always liked
>   something like the well-known
>   ...
>   My Computer
>   |
>   +--Root
>      |
>      +usr
>      +var
>      ......
>   +--Trash
>   |
>   +--My Documents
>   |
>   +-- Mail
>   ...
> 
>   ..structure . What do you think about discussion such a re-organisation?
Instead of hardcoding yet another list of items for the toplevel of the tree
view, why not make it completely configurable ?
People want to put there various dirs, FTP sites, (and if/when mail-reading
is implemented in konqy, mailboxes)... In one word : any URL that can be listed.
Of course, some default stuff has to be agreed upon, but I would think
of it a bit like kfm's one, not like Windows one (My Documents ??? Where did
you get that from ??? ;)

BTW, your mail comes at the perfect time. It allows me to have a better
picture of what needs to be done on konqueror ;)

-- 
David FAURE
david.faure@cramer.co.uk, david@mandrakesoft.com, faure@kde.org
http://www.insa-lyon.fr/People/AEDI/dfaure/index.html 
KDE, Making The Future of Computing Available Today

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