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

List:       koffice-devel
Subject:    Kword tables and DCOP scripting
From:       Carl G Lewis <carll () optushome ! com ! au>
Date:       2003-05-22 9:04:28
[Download RAW message or body]

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 ???

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? (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.

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!)

So there are a few possibilities.  I am hoping that someone with more DCOP / 
kword knowledge can advise where I should add DCOP methods and 
what their signatures might be, or how I can go about this automated testing 
generally.

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 :-(

thanks, 

Carl.



_______________________________________________
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]