[Konsole-devel] Re: konsole to kdelibs ?

[Harri Porten]

On Wed, 19 Jun 2002, Dominique Devriese wrote:

> So, i've been working on a solution, and here is my proposal:
> 1 We move a large part of konsole into kdelibs:
> TEPty, TEWidget, TEmulation and related classes.  Not TESession, since
> it's too much geared towards the Konsole program.  This will involve
> some license changes, but that shouldn't be a large problem...

I understand you have some experience with this topic now ;)

> 2 because those classes aren't particularly handy to use, and there are
> quite some gotcha's involved ( i've hit some crash situations and such
> because of resizeEvents not being handled in time, and the fonts used to
> look terrible because I used a wrong font etc. ), we add a class:
> KonsoleWidget.  I have the source code for this attached here, it's
> meant to provide a nice, clean, easy-to-use, well-documented interface
> to the library, and abstract the difficulties of dealing with TEWidget
> and such directly, away.

I suggest passing the string parameters as const references. Can the 
"TEPty.h" inclusion be removed from the header ?

All in all, it looks to me as if this class is a rather thin wrapper
around TEWidget. The work you have done might possible be invested better
in polishing the existing class (followed by a possible rename if it
becomes public API).

> Another advantage here is that now Konsole and KonsolePart currently
> both statically link with all the TE* classes.  This is a waste of disk
> space, and could be solved with the new library...

On the downside it probably won't make loading of the konsole application
exactly faster ...

> I'd like to hear your opinions on this, i think this would be usable in
> quite a few places (kpackage (currently uses a KTextView, i think... ),
> kdevelop (currently has code copied from konsole, iirc... ), some of my
> own future plans :), someone recently asked on kde-devel if there was an
> easy way to do this etc...)

As a general rule code in kdelibs should be used by at least two (or
three?) apps. That would mean that either kpackage or one of the fork
specialists from the kdevelop project should make use of it. To test it's
general usability and justify the additional kdelibs bloat.

Harri.