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

List:       kde-core-devel
Subject:    Re: Can we drop KWrite ?
From:       Bernd Gehrmann <bernd () physik ! hu-berlin ! de>
Date:       2001-03-14 10:27:14
[Download RAW message or body]

On Tue, 13 Mar 2001, Simon Hausmann wrote:
> I see your hidden point though :-) : We might want to provide a
> class in KParts which one can use out-of-the-box for multiple
> views, as reimplementing hitTest is not something really convenient.

Well, the 'hidden' point (to come back to the subject ;-)
was really that we don't have a usable text editor part 
currently. Your making the KTextEditor interface was a good 
and necessary idea, but at that time nobody using kwrite in his
application cared about making the interface useful, and now
it simply sucks. One of the problems is that it (together with
the part activation stuff) doesn't support multiple views/
document properly, other problems are that the embedding
application doesn't have enough control over it. In that
context, I don't see any point in creating another 'kant part'
which is based on the same interface and _still_ sucks. Heck,
even kant itself doesn't use the kant part!

I would tend to mark the old kwrite part as 'deprecated',
leave it as it is and make a new interface that generic
editors, html editors like quanta and ide's can use. But
this only makes sense if the interface to the editor is
rich and extensible enough. For example, I need to get
information from the view at which cursor position the
right mouse button has been clicked (in order to populate
the context menu with context-sensitive items). I also
need complete control over loading and saving, not just
some actions which are encapsulated and inaccessible for
the application (to be precise, in my new ide the user
can choose to get a line edit with KURLCompletion instead
of a classical file dialog, as I find that much more efficient).
I'm sure that the quanta people can come up with more
examples of stuff like this. 

Bernd.

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