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

List:       koffice-devel
Subject:    Re: Kword tables and DCOP scripting
From:       David Faure <dfaure () klaralvdalens-datakonsult ! se>
Date:       2003-05-22 9:35:53
[Download RAW message or body]

On Thursday 22 May 2003 11:04, Carl G Lewis wrote:
> Hi,
> 
> My removal of m_cells from KWTableFrameSet is going well, in fact I have a 
> patch that allows kword  to be compiled without it, but not all the 
> functionality has been converted.  The row operations work but have not been 
> tested much, and I have still to do column ops, split/join etc, but this is 
> not a lot of work.
> 
> My problem is that I need to write some testing scripts that will carry out 
> predefined sequences of table operations, there is just too much 
> functionality to get right to be able to do testing by hand.
> 
> I have been playing around with the DCOP python bindings and have written a 
> few scripts. I even found a (minor) bug and notified the maintainer (Julian 
> Rockey). But I'm not sure if the functionality exported via DCOP by kword is 
> adequate for my purposes. 
> 
> In a python script I can get all the actions via the view, but most of the 
> table-related actions pop up a dialog box, rather than actually completing 
> the operation directly, eg insert_table, delete row/col, split, etc. This is 
> alright as far as it goes, but not enough for automated testing.
> 
> I have played around with the dcop program as well, and can report that 
> executing a command similar to:
> 
> dcop kword-14036 "qt/kword-mainwindow#1/funky-splitter/unnamed1(KWView, 
> 0x8258508)/Insert Column Dialog/unnamed1(QWidget, 
> 0x818c720)/unnamed1(KDialogBaseButton, 0x83e55b0)" animateClick()
> 
> will activate the ok button on the dialog popped up when Table->InsertColumn
> is selected, thus inserting the column. 
> 
> This is unwieldy, but I suppose it would work for automated testing. The nice 
> thing is that the test is pretty much what the user does. I still don't know 
> how to select the table cells automatically though - I suppose the select* 
> functions should be added to  KWTableFrameSetIface ???

Feel free to do that.

> It would be nicer if you could get a DCOP reference to the currently opened 
> dialog from the kwview object ... ?
> 
> If traversing the qt object tree like this is an ok way to do testing, would 
> patches to koffice and/or kdelibs be accepted to add more names for the 
> objects?

Yes.

> (E.g. the fact that the dialog is called "Insert Column Dialog"  
> above is because I changed this in KWView::tableInsertCol(), normally it's 
> just unamed like the others.) Having the addresses printed out is a bit 
> annoying for scripting.
> 
> I have not been able to work out if it's possible to access the qt object tree 
> through python, but the perl dcop bindings can, or at least that is what the 
> manpage says. I haven't tried them so I don't know if the syntax is any 
> better than the cmd line client.
> 
> I thought about adding the table structure manipulation functions to 
> KWTableFrameSetIface as well, but its hard to see how this would fit in with 
> undo /redo, which is v. important to test.

Right, better have more high-level methods, like you suggest below.

> Another possibility is to add more functions to the KWordViewIface, or change 
> the signatures of the ones that are there - in addition to insertTable() 
> there would be insertTable(rows, cols, tabletemplate, height, width, inline) 
> which would insert a table at the current   cursor position without opening 
> the dialog. (and not waiting for a mouse click!)

Yes, this sounds good.
You don't only want to "test exactly what the user would do". You also
want a version of the functionality that doesn't involve popping up a dialog
at all, so that people can write scripts to automate operations in KWord,
without being bothered by a dialog.

> Or is there some other example in the code in which there is this kind of 
> automated functionality via DCOP, which is the "approved" solution? I read 
> the automation writeup and some of the DCOP chapter in the KDE programming 
> book, but they don't go into quite enough detail :-(
Hmm, I don't see what more there is to say. Add the missing methods to
the DCOP interfaces, and that's it, no?

-- 
David Faure -- faure@kde.org, dfaure@klaralvdalens-datakonsult.se
Qt/KDE/KOffice developer
Klarälvdalens Datakonsult AB, Platform-independent software solutions
_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]