From koffice-devel Thu May 22 09:04:28 2003 From: Carl G Lewis Date: Thu, 22 May 2003 09:04:28 +0000 To: koffice-devel Subject: Kword tables and DCOP scripting X-MARC-Message: https://marc.info/?l=koffice-devel&m=105359513113064 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