Re: Scripting update - News flash

On Sunday 21 July 2002 01:45, 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.
>
> I'm not sure I really likes this a whole lot.
>
> The most important thing is consistency. Naming/location of methods needs
> be as close to intuitive as possible!
Yes, but the new naming is at least unique and shows to which document/view the interface
belongs, the current interface nummer must not mach the corresponding view/document number.


>
> If you read the sample perl script I posted, I use a function to decide on
> an interface based on a document number, which I get from the main window.
>
> This will not make it easier to find the correct interface, I'd still need
> a function to do that, I'd just get to use longer strings...
>
> Actually, I don't think there is a way around having some querying/string
> concatenation going on considering how dcop works. The best we could do
> would be to hide those many interfaces somehow, or as you suggested put
> them in the document/view classes instead.
>
> When I look at the scripts I wrote so far, I get a lot of lines grabbing
> interfaces, where from a scripter's point of view, I'd prefer to have only
> one for e.g. a document.
>
> Apart from saving calls, it would spare me from trying to understand why I
> need a SelectionInterface, an EditInterface and a
> SelectionInterfaceExtension just for doing a very simple operation, as well
> as from filling docs with excutions;o!
>
> This is what it takes to lowercase the selection (apart from standard
> stuff):
>
> my $mw = $client->createObject( $app, "KateMainWindow0" );
> my ($docNumber) = $mw->currentDocumentIfaceNumber();
> my $selIf = interface( "SelectionInterface", $docNumber );
>
> my ($b) = $selIf->hasSelection(); # stupid DCOP module
>
> if ( $b ) {
>     my $editIf = interface( "EditInterface", $docNumber );
>     my $selExtIf = interface( "SelectionInterfaceExt", $docNumber);
>
>     my ($line) = $selExtIf->selStartLine();
>     my ($col) = $selExtIf->selStartCol();
>
>     # Replace the text with a lowercase version
>     my ($t) = $selIf->selection();
>     $selIf->removeSelectedText(); # do we still support not overwriting?
>     $editIf->insertText( $line, $col, lc $t );
>     # Restore selection
>     my @lines = split "\n", $t; ## NOTE any system uses a \n, right?? or
> ..? my ($endl, $endc, $cnt);
>     if ( ($cnt = scalar( @lines )) > 1 ) {
>         $endl = $line + $cnt - 1;
>         $endc = length pop @lines;
>     }
>     else {
>         $endl = $line;
>         $endc = $col + length $t;
>     }
>     # FIXME Restore cursor position - when we get methods...
> ##    print STDERR "Attempting to set selection: $line, $col, $endl,
> $endc\n"; $selIf->setSelection( $line, $col, $endl, $endc );
> }
>
> I actually think that is not badly hard to read (or even write) but it
> *would* look so much cleaner if I could use just one ("document") object
> for all calls.
>
> -anders
>
> _______________________________________________
> kde-kant mailing list
> kde-kant@
> http://mail.kde.org/mailman/listinfo/kde-kant

-- 
Christoph Cullmann
Kate/KDE developer
[email protected]
http://kate.kde.org