Re: Scripting update - News flash

ian reinhart geiser <[email protected]>
Newsgroups gmane.comp.kde.devel.kate
Message-ID <[email protected]>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 20 July 2002 05:33 pm, you wrote:
> On Sunday 21 July 2002 16:02, Anders Lund wrote:
> > > On Saturday 20 July 2002 00:07, Christoph Cullmann wrote:
> > > > Hi,
> > > > to identify the dcop interfaces for the different documents/views,
> > > > geiseri and I have come up with an new naming (which can even BC
> > > > introduced intro the current ktexteditor interfaces)
> > > >
> > > > Document#12-InterfaceName
> > > >
> > > > and
> > > >
> > > > View#4-13-InterfaceName
> > > >
> > > > View#4-13 means: Document number 4, View number 13
> > > >
> > > > What does we win:
> > > > Ah complete clear order of the interfaces to the belonging document
> > > > and view, and even a document -> <- view relation.
> > > >
> > > > How we does it:
> > > >
> > > > we introduce a new methode
> > > >
> > > > void set"InterfaceName"DCOPPrefix (const QCString &) to each
> > > > interface (a non virtual methode, needs no implementation in the
> > > > part)
> > > >
> > > > and the parts which implement the interface call it like
> > > >
> > > > setEditInterfaceDCOPPrefix (jsdfkldsjfkl)
> > > >
> > > > in their constructor of for example the document.
> > > >
> > > > That is perhaps not that nice, but one of the only BC ways to change
> > > > the naming to a useful pattern with the many interfaces and
> > > > multi-inheritance (the interfaces can't give themself the right name,
> > > > as they know nothing about the view/document they get.
> >
> > Actually, the more I look at this, the less I like it. All I see is a
> > waste of CPU cycles, first when a document is loaded, doing string
> > operations for each of a growing number of interfaces, next in case of
> > typeing a script/command that will take longer, and in case a script is
> > run, the routine to decide on an interface again needs extra string
> > operations.
> >
Ummm this is not the case, i have tested with up to 5k dcop interfaces with no 
slowdown in the system.

> > Changing the names of interfaces cannot change how dcop works.
Yes changeing the names make it easier to manage the interfaces for the 
reasons said below.

> >
> > Is there any reason at all to do this? I think no. Please remove it
> > again.
>
> Ian likes the new way of naming, as it shows the relation between the
> interfaces, too. And he doesn't like of dropping his automagically dcop
> interfaces stuff in ktexteditor. As DCOP works like C with global namespace
> without an real object tree, the new naming is one of the only ways to
> ensure:
> a) the names are unique
not only unique but all match up with eachother, so they are easier to manage.

> b) the names are useful (in respect of document (or view) -> <- interface
> relation
yes, they should also be easy to construct and desconsruct with text tools 
like perl, awk and python.

>
> The performance hit because of the string manipulations is really low.
>
Again ther should be no hit above what is there now... and that is in the ms 
range.

Really we have to remember this is here for automation and power for 
scripting, not for viewing pleasure.  What we really need are good docs on 
the interfaces so users know how to script them.

Just my 2c, but I hope so see cullmans nameing patch all over the text 
interface.

- -ian reinhart geiser
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9Od3dPy62TRm8dvgRAnLjAJ9ijhY3pdcLLYWUoA3O2RwfHVdA+QCgkfdW
kA5a5vS2BA1Z8uUg1VFsJc4=
=Csvo
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.