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

List:       kde-core-devel
Subject:    Re: KEditcl and KTextEdit
From:       ian reinhart geiser <geiseri () yahoo ! com>
Date:       2001-11-13 12:58:36
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 13 November 2001 01:33 am, Waldo Bastian wrote about Re: KEditcl 
and KTextEdit:
> It would break source compatibility. Currently applications expect KEdit to
> inherit from QMultiLineEdit including the functionality that QMLE provides.
>
> You could add a factory like:
>   TextEditor *KEdit::createEditor(QWidget *parent)
>
> that would either return "new KEdit(parent)" (default) or that dynamically
> loads another editor that implements the TextEditor interface if the user
> has configured it so.
>
> Then we can rewrite the applications against the TextEditor interface,
> which would be a good test to see if the TextEditor interface is
> functionally complete.

Hmmm, i think we are thinking mostly along the same lines.  The issue where 
we disagree is with the "that would either return "new KEdit(parent)" 
(default) or that dynamically loads another editor that implements the 
TextEditor interface if the user has configured it so."

The problem I see is that  I fail to understand how you would implement 
KTextEdit without a) becoming a KTextEdit service or b) without using the 
KTextEdit service.  I can make it do both and still maintain source 
compatibility with any application that uses KEdit.

Basicly I fail to see how KEditcl would benefit from using KTextEdit unless 
it loaded KTextEdit services or became a KTextEdit service.  If we are 
interested in source compatibility( /me raises his hand) the I would be a fan 
of making KEditcl use KTextEdit for its work and using the existing code in 
KEditcl to make a KSimpleEdit service for KTextEdit.  This way if the user 
only has kdelibs installed they would get KSimpleEdit and if they have 
kdebase installed then they would get KTextEdit.  

The cool thing here is that we would standardize things like Search and 
Replace dialogs, Cut/Copy and Paste and Text Selection.

I dunno, after Michael gets done revamping Search and Replace in KEditcl then 
I will look at it again.  The current code there is needed, but it lacks the 
ability to use other services if they are present.   

The biggest problem with interfaces is that kdelibs should only contain 
interfaces, and the implementations should reside else where.   This is not 
an issue if kdebase and kdelibs are installed, so is this a moot point?

If so, then conversion of KEditcl to KTextEdit could be  a weekend task.   We 
would then lose all of Michael's hard work though.

Cullmann you have experiance with implementing these things, what is your 
opinion?

- -ian reinhart geiser


- -- 
:-- Ian Reinhart Geiser --:
GPG Key: D6A6 7E16 13A9 B5A7 9E18 D1A7 3F2E B64D 19BC 76F8
===========================================================
[It is] best to confuse only one issue at a time.
		-- K&R
===========================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE78Rj8Py62TRm8dvgRAnyBAJ4oyQ2DPPsGP/aysOfsO7SnjRpOGACgpAbc
smCj/RCtueDqLAZJxOKDC2E=
=nnG9
-----END PGP SIGNATURE-----

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