Re: Scripting update - News flash

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!

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