dogtail test suite status

2007-07-15 Thread ahmad sayed
Hi Josh,

Waiting your comments :), I committed the code to the dogtail branch i created 
a new dir under src called src/test-dogtail  it contains my  up to date code.

Best regards,
Ahmed Sayed

- Original Message 
From: ahmad sayed [EMAIL PROTECTED]
To: Josh Sled [EMAIL PROTECTED]
Cc: gnucash-devel@gnucash.org
Sent: Saturday, July 7, 2007 1:46:59 PM
Subject: dogtail test suite test harness

Hi Josh,

Sorry for my long silence i got some issues with my PC lately, I solved it at 
last,

currently i have a mix of good news and bad news.
the good news is:

1 - Currently we have wrapper to most of dialogs, our wrapper module reach more 
than 1000 LOC.
2 - I'm able to test the register and i compelete a smplified version of 
tutorial 1  and 2.

the bad news is:
1 - In order to be  able to access some components, I use some raw inputs,  
according to dogtail  the raw input is to do mouse click using the coordinate,  
Like 
rawClick(wiget.position[0], widget.position[1])

2 - I got a problem with expanding the tree in the account pages so i only 
could create an account like
Expenses:Taxs
only parent and child more account like
 Expense:Taxs:Insurance currently no luck with them

also to access the register I use some tricks and work around Like 

===
def set_cell_text(self, text):
relative_pos = self.column_val - self.prev_col_val
print relative_pos
if relative_pos  0 :
for i in range(relative_pos):
self.keyCombo(Tab)
else:
for i in range(abs(relative_pos)):
   
 self.keyCombo(ShiftISO_Left_Tab)

self.typeText(text)


in this code i save my previos position in if it is after my current position 
press tab for n times else press shit-tab for n times, something like this.

ofcourse i was expecting more from dogtail unlike other Testing tool, i used or 
read about but the register needs some work to make it play nice with 
dogtail(make it accessible), 

BTW: i tried to play with gnucash register code, and atk but i make a very 
slight progress, like making dogtail read the  register as table but it will 
require a lot of time the register code is too big.

3 - i have a problem with my svn account I contacted Derek to help me solving 
it.

The news ends here, :)

Back to testplan running:
you suggested some approach like Junit,  I tried pyunit and it looks nice to 
me,  do you have
 any issues regarding using it to organize our test cases.

Best regards,
Ahmed Sayed




  Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, 
news, photos  more. 





  

Park yourself in front of a world of choices in alternative vehicles. Visit the 
Yahoo! Auto Green Center.
http://autos.yahoo.com/green_center/ 
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: dogtail test suite status

2007-07-15 Thread Josh Sled
ahmad sayed [EMAIL PROTECTED] writes:
 Waiting your comments :), I committed the code to the dogtail branch i 
 created a new dir under src called src/test-dogtail  it contains my  up to 
 date code.

Sorry for the delay; I was out of town last week... I'm planning on reviewing
progress later today.

Unfortunately, I don't see any commits to the dogtail branch in svn.  Do you
get any errors when you do an `svn commit`?  Did you `svn add` the
src/test-dogtail directory?  What does `svn status` say?

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]


pgpEz3ZvNXENa.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: Licensing clarification, updates

2007-07-15 Thread Josh Sled
Christian Stimming [EMAIL PROTECTED] writes:
 * In addition to this, contributions by the following devs are licensed under 
 GNU GPL, Version 2, or (at your option) any later version: cstim, ..., and 
 all source code files that contain this clause.

I prefer the license to be attached to the file; at least as a level of
indirection.  E.g., the file could just say Licensed under GPLv2, OpenSSL
exception (see LICENSE).  I don't think it's as good to have an indexing
license file that described all the individual source files, or tried to
create classes by contributor.


 Also (or alternatively), couldn't we also say All contributions before [some 
 date in the past] are licensed under GPLv2 or any later version? When 
 thinking about the license on a per-contribution basis, I think the most 
 precise wording could include the fact that you used to contribute code under 
 GPLv2 or later, but then changed your mind at [some date in the past] and 
 everything since then is GPLv2-only? 

I'm not sure to what end.  The VC history contains this information, to some
degree, as well.


 Also, I think I'd be interested to license my contributions under (brand-new) 
 GPLv3 in addition to the common GPLv2 license. I think this could be added in 
 the LICENSE file by stating something like In addition to this, 
 contributions by ..., cstim, ... are licensed under GPLv3 as well. Should 
 something like this rather be avoided, or would that be fine? What do the 
 others plan so far?

I think that sounds fine; I'd still modify the text of the files
individually, as I said above.

I've not had time to review the GPLv3 myself, yet.

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]


pgpqbhQnn4Xv3.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Release Manager needed

2007-07-15 Thread Chris Lyttle
Hi all,

With the release now of GnuCash 2.2.0 I am announcing that I will be 
stepping down as Release Manager. I have enjoyed immensely working with 
you all but due to work time commitments I can no longer participate in 
GnuCash on this kind of level. I will still be about and obviously, 
whoever steps up to become release manager I will be more than happy to 
help train so that they can ease into the process. Hopefully in the 
future, if I have more time, I can once again become more active within 
the GnuCash community.

This email is simultaneously a call to anyone who feels they can make 
the commitment to GnuCash to become involved in the development by 
becoming the Release Manager. I wish you well and will be available to 
answer any questions you have.

Chris
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: Release Manager needed

2007-07-15 Thread Andrew Sackville-West
On Sun, Jul 15, 2007 at 02:37:17PM -0600, Chris Lyttle wrote:
 Hi all,

[... snip resignation ...]
 
 This email is simultaneously a call to anyone who feels they can make 
 the commitment to GnuCash to become involved in the development by 
 becoming the Release Manager. I wish you well and will be available to 
 answer any questions you have.


what, praytell, does the release manager do? 

A


signature.asc
Description: Digital signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


CSV Import Update

2007-07-15 Thread Benjamin Sperisen
Hi Josh and Christian,

I thought I'd just write a summary of the status of the CSV import
code, and what still needs to be done.

What can the importer do now?
1. It can handle different encodings.
2. It can handle different separators and various date formats.
3. It is date-separator agnostic. (This is using the regex recommended
by Derek : 
https://lists.gnucash.org/pipermail/gnucash-devel/2007-July/020948.html)
4. It can handle three different column types: Amount, Date, and
Description. The columns can be in any order.
5. If there is an error with any of the rows, it will interpret the
rows that do not have errors, and then let the user try changing the
configuration to parse the remaining rows.

What shortcomings does the importer have?
1. When errors do occur, the user is not informed of what they are,
just which rows have them.
2. There is not yet any support for fixed-width files.
3. The column type selection interface is somewhat clumsy. You have to
click on the column to select the row, and then click, hold and move
to select a new type. I don't think this is particularly obvious, but
this is the best I can think of with stock GTK+ widgets.
4. It has not undergone extensive testing.
5. This is not necessarily a CSV import issue, but the date parsing
function does not yet take into account the issue raised by Thomas
(https://lists.gnucash.org/pipermail/gnucash-devel/2007-July/020954.html).
(It is also hiding as a static function in one of my source files, but
it could easily be moved.)

Problems 1 and 2 are just a matter of coding, and I know at least
roughly how to attack them.

Problem 3 is a bit trickier. I'm thinking it could be slightly
improved by automatically selecting the treeview row when the dialog
is shown, but I'm wondering if there is a more elegant interface for
this sort of thing. I did a lot of experimentation with an hbox of
comboboxes that would resize automatically by doing size requests (to
align themselves with the treeview below), but that didn't work very
well, since when I expanded the window, I couldn't shrink back.

Problem 4 will largely take time, but if anyone has any CSV files that
they'd like to try this with, feel free -- the code should be stable
enough that it's not totally unusable at this point. As long as you
don't try to use a fixed-width file, you should be able to import your
CSV file (and if it doesn't work, any feedback on that is definitely
welcome!). I've also committed an example file in my branch at
gnucash/src/import-export/csv/example-file.csv.

Finally, I'm thinking I can solve problem 5 by maybe adding a boolean
argument to the function to specify that the string should be parsed
as QIF date string (to take into account apostrophes). I feel fairly
safe ignoring apostrophes in CSV land, just because I've never
encountered that before (though I could be wrong). I'll also have to
learn some about regular expressions, as I know next to nothing about
them, to add the functionality.

Anyway, that's where the code is and where it still needs to go. As
always, let me know if you have any comments or suggestions!

Regards,
Benny
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel