ahmad sayed <[EMAIL PROTECTED]> writes: > Sorry for the delay, I was out of home for 3 days:).
No worries. we all have our delays. :) >>> (As Derek asked:) are these window x,y coordinates, or logical widget > locations? > >>> Based on the command above I'd ASSUME it's logical widget locations.. > ?? But I'm wondering how it deals with invisible widgets. > yes it is logical, Okay, so you have a path down the widget tree and say something like 1 -> 3 -> 2 -> 1 -> 5 -> 3 to walk the list of widgets? Or is it really an x-y coordinate? > yes i could not deal with invisible widget, but please could you give me a > solid example for this invisible widget, I use a mix of mouse coordinate and "this" invisible widget? Which one? There are a number of times when for example a widget is hidden in order to change the way a dialog looks based on the dynamic state of the context. For example, the Transfer dialog hides certain widgets based on whether it's instantiated as a full transfer or as an exchange-rate dialog. In another example, the Search window changes the button names based on whether it's a Select or Find. I'm afraid I dont know enough about the register to point you to the "register" hidden widget(s). > keyboard hot-keys, you could look at the code on the dogtail branch > in GnuCash.py (Class Register), I will add more comments to make it more > clear. My python fu is low, so I could look at it but I doubt I'll really understand all of it. > dogtail could expand a tree from other application, i tried it with at-spi > browser (an application bundeled with dogtail), but with gnucash i could > only collapse the treetable?!!, i am going to find out other options, I'm also > going to dogtail mailing list to find out what does this mean. Okay, so how is our tree different than their tree? > Derek said: >> I'd suggest that instead of this you work on all the other dialogs and >> try to get as much coverage as you can without spending too much time >> purely on the register. > > I'm with Derek, I expect more issues while writing more testcases. Right, and that's fine and good. I'd rather see more coverage for the rest of the application because the register is being worked on now, so once the rewrite finishes all your existing test cases will need to get rewritten to the new register interface. -derek PS: I realize it might be easier now to have all your classes in a single "Gnucash.py", but eventually I think it might be better to separate the various classes into separate files, like Register.py, AccountTree.py, NewAccountDialog.py, PriceDialog.py, etc. But this doesn't have to happen right away. -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH [EMAIL PROTECTED] PGP key available _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel