'Re: My Interfaces changes planed for KDE 4.0'

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

List:       ktexteditor-devel
Subject:    Re: My Interfaces changes planed for KDE 4.0
From:       Mickael Marchand <marchand () kde ! org>
Date:       2005-06-04 12:31:08
Message-ID: 42A19F0C.1010005 () kde ! org
[Download RAW message or body]

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

Christoph Cullmann a écrit :
> On Friday 27 May 2005 11:57, Christoph Cullmann wrote:
> 
> > hi,
> > here my changes I would like to do in a while:
> > 
> > a) convert use of unsigned int to int, as QT has changed to use int in nearly all \
> > places, it atm is a hassle to convert back to int in all loops, length compares \
> > and lookups, should make code more readable I guess
> 
> Will start this in near future :)
> 
> 
> > b) add an interface for some kind of "editor factory" or how ever to call it
> > this will just a plain QObject which lets you create KTextEditor::Documents, it \
> > will avoid the current hassle in kate to have around one global object for ever \
> > and speed up document creation for apps using it, if the app devs still use the \
> > old way,  nothing will break, but this will give a faster way ;)
> 
> this is dropped, guess easier to keep as implementation detail, kate part does that \
> now via internal ref counting on the global object needed, no need to harm app devs \
> I guess 
> 
> > c) remove the DCOP interfaces from the lib, really, this should be done per part, \
> > the current overhead of 10000ths interfaces isn't worth the hassle, and it will \
> > save us from the need for dpointers in the interfaces and the duplicated ints all \
> > over, only the document and view itself should provide some number to the outside \
> > to make handling easier ;) btw., perhaps should the int method just be part of \
> > interface and the implementation part should take the effort to make it unique, \
> > in the mini implementation it would look like the current in ktexteditor, but I \
> > think the interfaces should really be without any implementation at all inside
> 
> dcop in the ktexteditor interface lib will die, will think about better replacement \
> before 4.0 later 
> 
> > d) some little conflict solving and removing:
> > - KTextEditor::Editor -> CU, this is the no view/doc seperation thing, it's just \
> > not needed any more, yzis/kate supports it, and it's not that nice as the static \
> > queryMethodes don't cover it and it's a hack, away :)
> 
> As seems that some people use it, will let it live, queryMethodes will be dropped \
> in favour of easier qobject_cast, which is the same typing in the end and more \
> consistent 
> 
> > - SessionConfigInterface and ConfigInterface overlap, the readSessionConfig... \
> > should be removed from ConfigInterface 
> > - CursorInterface: not sure, wasn't that usable in the current state, perhaps we \
> > should remove this now, and readd later a usable one, if we have all come up with \
> > one ;) 
> > - DynWordWrapInterface -> TRASH, not needed, this is part internal stuff, why \
> > should host app want to enforce that, bypassing the users config, it has no \
> > effect on text content, not like the static word wrap, which might be needed to \
> > enforce ;) 
> > - PrintInterface -> CU, user action, too
> > 
> > - UndoInterface -> CU, user action, too, + config stuff
> > 
> > - ViewStatusMsgInterface -> CU, this contains only one signal, and is not that \
> > usable at all, as nobody knows whats in this, if we really need this, we should \
> > note down in the KTextEditor::View which "non-interface" related signals parts \
> > should provide, just some comment would be sufficient, as this signal connection \
> > is nothing we do at compile time 
> > e) merge some of the interfaces, which will avoid the current blow up of them ;)
> > - EditInterface + Ext -> EditInterface, the editBegin()/editEnd() transaction \
> > methodes won't hurt to be in the basic editing interface, if the part doesn't \
> > support it, it should just do nothing there :) 
> > -  selection interface + ext + blockselection interface -> SelectionInterface
> > + this is FOR VIEW this time ;)
> > 
> > - Clipboard Interface -> SelectionInterface, as this is for VIEW, too, and \
> > selection is per view, makes sense to collect this selection related 2 methodes \
> > in the SelectionInterface, too, no need for seperate, each editor supporting \
> > selection should have no probs with copy/paste/cut and co, not even sure if \
> > anybody uses this, but hey, if this are just 3 methodes in a interface, this \
> > won't hurt, if it stays seperate, it will ;) 
> > - ConfigInterface + ConfigInterfaceExtension, simple merge, guess after the \
> > conversion to int, the configPages() counter should just return -1 if this part \
> > doesn't allow to emebed individual config pages ;) 
> > - MarkInterface + Extension -> MarkInterface
> > 
> > - ViewCursorInterface -> CursorInterface, makes no sense to prefix, this is for \
> > view just, and good ;) if ever a other cursor interface for editing purpose comes \
> > up, this should be EditCursor or CursorEdit or whatever
> 
> Will start with this soon, too
> 
> In addition, have added an interface for the "modified by external apps" stuff kate \
> part provides, to allow others to do so, too.
yzis should probably support that one
will give a look

> 
> This will lead way to pure KTextEditor based Kate app, too, now only the Commands \
> we support are missing, any ideas of yzis if such stuff might be usable for you, \
> too? This interface provides apps the possibility to embed commands for use in the \
> editor's visual command line to trigger app stuff, like in kate's external tools \
> and more

hmm, it's unclear for me what it allows to do ;)
kate does not have a "visual command line" afaik or do you mean the
konsolepart ?
if it's to run shell commands then yes, it would probably be usefull for
yzis.

Cheers,
Mik

> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Ktexteditor-devel mailing list
> Ktexteditor-devel@kde.org
> https://mail.kde.org/mailman/listinfo/ktexteditor-devel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCoZ8KyOYzc4nQ8j0RApETAJwI8GM7JwyIrADGaq8YD3pSXAJaRACgkN9O
YFWbHUjFY4ZE1FwuKgobqLM=
=rs2K
-----END PGP SIGNATURE-----
_______________________________________________
Ktexteditor-devel mailing list
Ktexteditor-devel@kde.org
https://mail.kde.org/mailman/listinfo/ktexteditor-devel

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