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

List:       kfm-devel
Subject:    konqueror
From:       Simon Hausmann <shaus () uermel ! Med ! Uni-Magdeburg ! DE>
Date:       1999-09-05 14:27:34
[Download RAW message or body]

Hi,

first of all: David - welcome back hacking :-)


I just collected some thoughts about Konqueror, some food for discussion
:)

All in all I'm more or less happy with Konqueror - it is fairly stable for
file management, and it can finally sort files :-)))

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

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.
  And it looks a little bit unstable, meaning it crashes pretty often when
  dealing a lot with removing/splitting :-)

- 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 ;-)
  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?
  In addition it'd be cool if kghostview and kdvi would have similar
  capabilities.

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

- 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?
  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.
  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?....
  What do you think?

- request for opinions: what do you think about adding a
  delete-selected-items button to the toolbar when the iconview/treeview
  is visible?

- 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?
  Perhaps we should wait for this a little bit and go for the switch to
  Reggie's QIconView first?

- 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?
  Or should we stay with the current treeview?


That's it for now :)

Bye,
 Simon

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