gnuccess-design — Design of GNUccess application

[GNUccess-design] FASD project: Online survey launched

[<ben...@id...>]

Dear Open Source developer

I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate.
You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it.

With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development.


With many thanks for your participation,
Benno Luthiger


PS:
The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/.
We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list.

_______________________________________________________________________

Benno Luthiger
Swiss Federal Institute of Technology Zurich
8092 Zurich

Mail: benno.luthiger(at)id.ethz.ch
_______________________________________________________________________

[GNUccess-design] Installer

[Bartek W. <ba...@re...>]

Hi, 

I've found my latest version of setup.py file. It's far from done so I didn't
check it into cvs, but you can see how it works by putting it into the python
directory.

You can use it by 

python2 setup.py bdist (create distribution - tar.gz file)

In the archive there will  be a setup.py file and you can then use python2
setup.py install to install it using distutils. I don't have windows at home,
but i've read that on windows you can use something like python setup.py
bdist_win32 (i don't remember the exact parameter) to create a executable
installer for windows.

If someone feels like maintaining this file - that's great - just put it into
the cvs.


-- 
regards
   Bartek Wilczyñski

Re: [GNUccess-design] ToC

[Bartek W. <ba...@re...>]

Quoting Kuba Wroniecki <ku...@st...>:

> 
> To Alessandro:
> I think that from now on we should exchange project-related stuff through 
> the gnuccess-design mailing list, and the web page.

I'm all for it
> 
> To Bartek:
> Plz, change the file permisions in the gnuccess htdocs directory to g+w, 
> so we all can upload files, and do other administrative things. 

I'm sorry - I've changed what I could :)
> 
> To All:
> I had a brief look at the User's guide ToC, and it seems ok to me. One 
> thing that I think is missing is some info on Datasources (what they are, 
> how to use them etc.).
> The All-objects tab is there for debugging purposes only, and will be 
> available to advanced users who specifically request it to be shown.

I'm not sure if it should be hidden. I think that it's no harm to see it and I
hope there will be lot's of CONTRIB GcObjects to be seen there (it may be
renamed to "other objects")

> About installation tools: I think RPMs, .tar.gz, and an installation 
> wizard should all be available. A nice installation program is (IMHO) 
> especially crucial for Windoze users, who get multiple heart attacks every 
> time they see a console.

I've already started to prepare a setup.py script (If you don't know what it is
- take a look at the distutils docs). It's very easy to create and makes a
wizard for windows (when run on windows) and a easy enough installer for
linux/unix systems. I didn't make any changes in it to reflect the new directory
structure - so it's not working now - but that's the way it should be done (I
think we shouldn't care for rpm's and deb's so far).
>
 
> PS. I think I'll be up to my neck in work till the end of the week.
> 

I know what you mean :) Me too.

Re: [GNUccess-design] ToC

[Alessandro B. <ale...@li...>]

Alle 14:16, gioved=EC 27 marzo 2003, Kuba Wroniecki ha scritto:
> To Alessandro:
> I think that from now on we should exchange project-related stuff throu=
gh
> the gnuccess-design mailing list, and the web page.

OK.

> To All:
> I had a brief look at the User's guide ToC, and it seems ok to me. One
> thing that I think is missing is some info on Datasources (what they ar=
e,
> how to use them etc.).

OK, I'm going to add an item to my ToC for this. I will need some info on=
 this=20
topic at the moment of writing.

> About installation tools: I think RPMs, .tar.gz, and an installation
> wizard should all be available. A nice installation program is (IMHO)
> especially crucial for Windoze users, who get multiple heart attacks ev=
ery
> time they see a console.

I'm going to open a topic on the web site about the installer.

See you on the web.

---------------------
Alessandro Bottoni

[GNUccess-design] ToC

[Kuba W. <ku...@st...>]

To Alessandro:
I think that from now on we should exchange project-related stuff through 
the gnuccess-design mailing list, and the web page.

To Bartek:
Plz, change the file permisions in the gnuccess htdocs directory to g+w, 
so we all can upload files, and do other administrative things. 

To All:
I had a brief look at the User's guide ToC, and it seems ok to me. One 
thing that I think is missing is some info on Datasources (what they are, 
how to use them etc.).
The All-objects tab is there for debugging purposes only, and will be 
available to advanced users who specifically request it to be shown.
About installation tools: I think RPMs, .tar.gz, and an installation 
wizard should all be available. A nice installation program is (IMHO) 
especially crucial for Windoze users, who get multiple heart attacks every 
time they see a console.


-- 
Pozdrawiam,
Kuba Wroniecki

PS. I think I'll be up to my neck in work till the end of the week.

[GNUccess-design] Re: GNUccess on Mandrake 9.0 with wxPython 2.4.0 = OK

[Bartek W. <ba...@re...>]

Thanks for your notice - I would recommend you to contact reqc and mdeek. They
are now working on Database access modules and query editor. I do not have any
time right now (and for the next 3 weeks), so I will be unable to help you  with
the manual. 

In case you haven't decided which documentation standard you will use for it I
would suggest the python documentation standard - look for the "documenting
python" tutorial on www.python.org. 

I'm sorry, but I can't do anything to help you further, I'll be "back on track"
in something like 3 weeks. 

-- 
regards
   Bartek Wilczyñski


Quoting Alessandro Bottoni <ale...@li...>:

> I just downloaded and installed on my Mandrake 9.0 the release 2.4.0 of 
> wxPython for Python 2.2. I can confirm that GNUccess works fine on this 
> configuration (even if it does not do very much, at the moment ;-). I just 
> thought you was happy to know it...:-)
> 
> Maybe, during the weekend I will try to write down an "embryo" of user's
> guide 
> (largely based on my intuition about the intended use of the program).
> 
> See you soon.
>  
> ---------------------
> Alessandro Bottoni
> 
> ------------------------------
> Scanned for viruses by MKS_Vir
> Last update: 
> ------------------------------
> 

[GNUccess-design] Here I am

[Alessandro B. <ale...@in...>]

As suggested by Bartek, I just subscribed the mailing list.

I want to take this opportunity for applaud the GNUccess project and to thank 
all the developers involved in it.

GNUccess is a long waited project for the open source community and I do hope 
it will produce a good alternative to proprietary tools like MS Access, 
PowerBuilder, theKompany "Rekall" and so on. The people who creates 
data-centric applications on the Linux platform and/or using "pure" RDBMS 
like MySQL, PostgreSQL and Firebird are in strong need of a GUI Building/GUI 
Engine tool like GNUccess.

I'm happy to have the opportunity to give my very small contribution to this 
project. Feel free to contact me for every needs (web pages, small pieces of 
code, site maintenance, etc...).

PS: As I told to Bartek, I'm not a real programmer (just a little bit of 
Python, PHP, HTML and so on) so, please, be tolerant with me... :-)

---------------------
Alessandro Bottoni
ale...@in... (this sender address)
ale...@li...

[GNUccess-design] Re: Presentation page

[Bartek W. <ba...@re...>]

Hello everybody,

Alessandro has sent me the overall GNUccess documentation that he had created. I
thought that maybe our link to wakka isn't really interesting enough, so i
decided to move our whole site to wiki. 

I think it's not a bad idea - but I'm open for discussion.

Anyway I've added most of the text that Alessandro has prepared (mostly in small
chunks fitting better to a wiki site). I don't consider it even close to
complete, but it's a good start. 

There's a lot of things happening - Kuba has changed the directory structure -
so please checkout the newest version. 

-- 
   Bartek Wilczyñski
BTW. Alessandro - please subscribe to our mailing list
http://lists.sourceforge.net/lists/listinfo/gnuccess-design 

and after that you will be able to post directly to all developers (and i will
not have to forward those messages there 8P )
__GREAT__ thanks for your help.

Quoting Alessandro Bottoni <ale...@li...>:

> I will have a look at the WakkaWiki web site ASAP (during the next weekend,
> as 
> usual) and I will try to insert some basic documentation. You will be able to
> 
> change it "on place" accordingly to your judgement.
> 
> The page I sent you was intented as a possible replacement home page for the
> 
> GNUccess web site at SF. This because the existing home page hardly explains
> 
> what GNUccess is and this makes unlikely that the visitor will switch to 
> WakkaWiki for a description of the project... :-)
> 
> See you later.
> ---------------------
> Alessandro Bottoni
> 
> 
> 
> ------------------------------
> Scanned for viruses by MKS_Vir
> Last update: 
> ------------------------------
> 

[GNUccess-design] Fwd: Presentation page

[Bartek W. <ba...@re...>]

I'm sorry - i didn't attach Alessandro's page at first - Here it is now

Bartek
----- Forwarded message from Alessandro Bottoni <ale...@li...> -----
    Date: Tue, 18 Mar 2003 10:27:04 +0100
    From: Alessandro Bottoni <ale...@li...>
Reply-To: Alessandro Bottoni <ale...@li...>
 Subject: Presentation page
      To: Bartek Wilczynski <ba...@re...>

Here attached you will find a HTML page with a presentation of the GNUccess
project. Let me know what you think of it and, in particular:
- Do you think this page is too long/too verbose?
- Do you think it is too dummy-oriented?
- Should I insert a few JPEG? Which ones?
- Do I have written only "correct" things (I do not know neither GNUccess and
its project very well at the moment).
- How about the section "what you can do for GNUccess"? Do you want to publish
any specific announce for programmers/testers/etc...?

waiting to hear from you soon

---------------------
Alessandro Bottoni
----- End forwarded message -----

Re: [GNUccess-design] Directories

[Kuba W. <ku...@st...>]

Here is the file, that is not downloadable from wakka :(.


-- 
Kuba Wroniecki

"I love deadlines. I especially like the whooshing sound they make as they 
go flying by." (Dilbert's School of Thoughts)

Re: [GNUccess-design] Directories

[Kuba W. <ku...@st...>]

> > Second, I'd like to propose we work a little on the directory structure,
> > before we add more files and it all starts getting messy. Here is my 
> > proposal:
> > 
> > ROOT/
> >   GNUccess/core
> >     All GcObjects
> >   GNUccess/gui
> >     GUI related stuff (like MainNotebook etc.)
> >   GNUccess/DBdrivers
> >     GcDataSource, GcRecordset subclasses in seperate directories:
> >     Postgres/
> >     MySQL/
> >     ....
> > + other things I forgot.
> > 
> > This means we will have a nice python-package structure, so we can do 
> > stuff like:
> > 	import GNUccess.gui.blabla
> > 	import GNUccess.DBdrivers.*

I changed the directory structure, but before 
uploading it to the CVS, you all should have a look, and change what you 
don't like (don't even think about it :))) ).

Have a look at:

http://gnuccess.sourceforge.net/wakka/wakka.php?wakka=CodeDirStructure

it's all there.
Oh, and by the way - IT WORKS :D

-- 
Kuba Wroniecki

"I love deadlines. I especially like the whooshing sound they make as they 
go flying by." (Dilbert's School of Thoughts)

Re: [GNUccess-design] Directories

[Bartek W. <ba...@re...>]

Quoting Kuba Wroniecki <ku...@st...>:

> Hi all.
> 
> First of all I just downloaded the latest version from the CVS, and it's 
> not working (at least not under Windoze). Haven't had time to at it yet.

I tried it out on my windows machine, and it works (slower than i would expect
but it does). Maybe You can try to contact me directly i'm sure we can figure it
out (Error messages and stuff could help)

> 
> Second, I'd like to propose we work a little on the directory structure,
> before we add more files and it all starts getting messy. Here is my 
> proposal:
> 
> ROOT/
>   GNUccess/core
>     All GcObjects
>   GNUccess/gui
>     GUI related stuff (like MainNotebook etc.)
>   GNUccess/DBdrivers
>     GcDataSource, GcRecordset subclasses in seperate directories:
>     Postgres/
>     MySQL/
>     ....
> + other things I forgot.
> 
> This means we will have a nice python-package structure, so we can do 
> stuff like:
> 	import GNUccess.gui.blabla
> 	import GNUccess.DBdrivers.*
> 
> Please, DO comment.
> 
Cool. I like your idea. Actually moving those files arround in CVS will not be
easy at all, so the sooner, the better :)

> Also - does anyone know how to REMOVE directories from CVS??
>  

I think that I've read on DF that it requires help from SF staff. In other words
- I'm not sure if it's worth it.
> 
> -- 
> Pozdrawiam,
> Kuba Wroniecki
> 
> "I love deadlines. I especially like the whooshing sound they make as they 
> go flying by." (Dilbert's School of Thoughts)
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Does your code think in ink? 
> You could win a Tablet PC. Get a free Tablet PC hat just for playing. 
> What are you waiting for?
> http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
> _______________________________________________
> Gnuccess-design mailing list
> Gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuccess-design
> 
> ------------------------------
> Scanned for viruses by MKS_Vir
> Last update: 
> ------------------------------
> 

[GNUccess-design] Directories

[Kuba W. <ku...@st...>]

Hi all.

First of all I just downloaded the latest version from the CVS, and it's 
not working (at least not under Windoze). Haven't had time to at it yet.

Second, I'd like to propose we work a little on the directory structure,
before we add more files and it all starts getting messy. Here is my 
proposal:

ROOT/
  GNUccess/core
    All GcObjects
  GNUccess/gui
    GUI related stuff (like MainNotebook etc.)
  GNUccess/DBdrivers
    GcDataSource, GcRecordset subclasses in seperate directories:
    Postgres/
    MySQL/
    ....
+ other things I forgot.

This means we will have a nice python-package structure, so we can do 
stuff like:
	import GNUccess.gui.blabla
	import GNUccess.DBdrivers.*

Please, DO comment.

Also - does anyone know how to REMOVE directories from CVS??
 

-- 
Pozdrawiam,
Kuba Wroniecki

"I love deadlines. I especially like the whooshing sound they make as they 
go flying by." (Dilbert's School of Thoughts)

[GNUccess-design] Some changes

[Bartek W. <ba...@re...>]

Hi,

As you can see in CVS, I've made some changes to GNUccess. 

I've implemented the GcTrigger class more/less according to the idea that I've
learned from Przemek (If you think i did it wrong then tell me please)

I also introduced the class GcException - I think that we would need it anyway
at some point.

One of the things that I'm not so sure concerns GcEnv. I've made it a subclass
of GcObject. It's a little bit tricky - it has a reference to itself in GcEnv. I
thought that it will be more consistent with the idea of keeping the object in
exception - when GcEnv raises the exception there's no problem with the
interface, however it introduces a lot of inapropriate like execute. I'm waiting
for your comments in that matter.

I've cleaned up the mess with GUI a little bit, but it's still a piece of crap.
Anyway some things started to work. You can even use drop-down menu (although it
refers to the object selected in objectsContainer so far ;)

I can see that nobody has written the summary of the second "meeting" so I'll
just say that I'm still thinking about GcScript Object - it should come along in
a few days - Przemek is working on a GcQuery and SQL parser and Kuba is involved
in DataSource stuff (I'm not sure if that's all true - but that's what I remember)

One more thing - maybe the most interesting. I've found a very nice project -
Gadfly -  it is a small RDBMS - written comp[letely in python and it's designed
to reside in memory during execution. I think it will be much easier to just add
the serialization layer to this library (it is currently using marshal, but i
guess it shouldn't be hard to write a nice XMLserializer for it). I'll try to
dig into it (actually Przemek could also be interested - it has some kind of sql
parser in python).

See you guys
   Bartek Wilczyñski

[GNUccess-design] Re: Presentation page

[Bartek W. <ba...@re...>]

As far as I'm concerned - Everything looks just fine. I would rather suggest to
insert the sections of your document into our WIki system (If you're not
familiar with Wiki - I've written a little howto
(http://gnuccess.sourceforge.net/wakka/wakka.php?wakka=HowTo) so you can get
acquainted with wakka :). 

What's even better about wiki - If anybody of the Developers will find anything
inappropriate he can modify it right away (i don't think that anybody will be so
picky ;)

Anyway - if you want to help us with documentation - You should start from WIKI
- it will save you a lot of effort with HTML and let all of us participate in it
as much as we can/want :)

BTW - we will probably soon make the default permissions to Wakka more
stringent, so please create your user account there 
 
-- 
regards
   Bartek Wilczyñski


Quoting Alessandro Bottoni <ale...@li...>:

> Here attached you will find a HTML page with a presentation of the GNUccess
> 
> project. Let me know what you think of it and, in particular:
> - Do you think this page is too long/too verbose?
> - Do you think it is too dummy-oriented?
> - Should I insert a few JPEG? Which ones?
> - Do I have written only "correct" things (I do not know neither GNUccess and
> 
> its project very well at the moment).
> - How about the section "what you can do for GNUccess"? Do you want to
> publish 
> any specific announce for programmers/testers/etc...?
> 
> waiting to hear from you soon
>  
> ---------------------
> Alessandro Bottoni

[GNUccess-design] Documentation

[Kuba W. <ku...@st...>]

Two ideas:
1. Use dia, or some other tool which allows creating class hierarchies. 
Then we can parse such diagrams to generate whatever (ex. DTD schemas)

2. Simply keep class structure in XML files, and write XSL stylsheets to 
convert them to readable formats / DTDs


What do you think?



-- 
Pozdrawiam,
Kuba Wroniecki

"I love deadlines. I especially like the whooshing sound they make as they 
go flying by." (Dilbert's School of Thoughts)

[GNUccess-design] After the "meeting"

[Bartek W. <ba...@re...>]

Hello !

So we are after our first "meeting" :)

It wasn't long enough to discuss everything, but here are some thoughts that
were brought up there:

1. Serialization. 

Looks like we aren't sure what we want to achieve here. We know we want to have
DTD, and we want to be strict about the data. Inheritance is a troubleMaker
here. I don't know if there is any nice way to do something with DTD. We had two
ideas:
-somehow encapsulate (for example in a <super> tag) xml compliant with a
superclass DTD
-force the implementer of the subclass to create DTD that is an "extended"
superclass DTD. by extended we mean that each XML document compliant with a base
DTD has to be compliant with the extended DTD.

Probably both of those approaches imply calling a superclass toXML method at
some point in the toXML method of a subclass.  

One thong that we agree on here is that the implementer should have some freedom
in implementation of the [to|from]XML methods (limited only by the DTD and
inheritance)

2. DAL

There's a lot of different issues so I'll split them into subpoints

2.0 GcRecordSet
We should add a new class to the GcObject Hierarchy. It should be abstract, and
we should use only subclasses implemented by DbDriver vendors. It's
implementation should be as lazy as possible, and off course FAST :)
 
2.1 GcQuery
We need two "types" of queries. Meta-query allowing to operate on tables from
different datasources, and giving the user some abstraction from different SQL
implementations peculiarities, and native (coming in one package with database
driver) that would allow the user to use his favourite features of his favourite
DB engine :) 

2.2 Database driver.
We agreed that the implementation of any database driver should include:
-GcDataSource subclass
-GcRecordset subclass
-possibly also native GcQuery (although it's not necessary)
Driver should be distributed as a separate package.

2.3 GcTable should be general, and rely heavily on the GcRecordset.

2.4 Our DAL will __R_O_C_K__Y_O_U__ :)

3. WIKI
We have wakka wiki installed, but nobody uses it. Sourceforge site is slow, but
it seems, that nobody wants to install wiki on his own machine. TikiWiki is
potentially better than wakka, but it is NOT working. I guess we should
reconsider the whole idea of WIKI ;)

That's pretty all that I remember.

I have also some ideas that have not appeared yesterday:

-Documentation - I've tried out happydoc. It's nicer in use, creates structured
HTML files (we can actually have index page for our docs:) and it even creates
dia file with class hierarchy. On the downside i like the files generated by
pydoc better. I guess it needs some discussion

-SQLite - it looks like a good thing to include (decent performance, bindings to
python), but I still hesitate to call it THE internal data format (lack of XML
support is what bugs me with it)

I had some more in my mind, but I can't remember now.

Comments are wellcome :)
-- 
bye
   Bartek Wilczyñski

[GNUccess-design] Some new thoughts to resurrect the discussion

[<ba...@re...>]

Hi,

I have some new thoughts for the design of GNUccess. I'll try to put them into a
list:

1) We really have to think about GcEnv interface. There are many things
happening on the border of GcEnv and GcMainFrame. I think that we should take
action now, because we can loose the independence of GcEnv. My idea is that
GcEnv should be independent from implementation of GUI and GUI has to depend on
some nicely defined GcEnv interface. The problem that bugs me now is that we
have problems with updating the GUI with the changes of GcEnv. We have several
classes now that are trying to concurrently display the state of GcEnv (namely
the Objects dictionary) and at the same time several ways of changing it. I
propose to clean this up by adding following methods to the GcEnv interface:
- GcEnv.RegisterObject(self,Object,class,name) - adding the object to the
Objects list
- GcEnv.RegisterUpdateHandler(self,function)- registering the function to be
called upon any change in the GcEnv. This will allow the GUI and other objects
to monitor the changes in the environment (i guess that for example  a GcReport
instance should be informed if the GcQuery instance that it relies on was
deleted). It should allow us to have a nice and clean separation of GcEnv from
the internals of other objects.
- GcEnv.Update() - this guy should execute all registered update handlers. 

2) We should switch from pydoc to happydoc - i think I'll take care of it during
the weekend

3) About SQLite and it's application as THE internal data storage - it is not
xml-based and needs a separate file. I think this would be really good to have
support for this in GNUccess, but I think we should have something like tiny
internal xml representation of the tables. During the execution this could
reside in memory (thus giving You good enough performance for _really_ small
databases) and could be serialized to the xml files with all the other
GcObjects. I think it could serve nicely as the way to store things like
parameters for applications and stuff.

4) We really need to have some DAL and I keep thinking of it. Please let me know
of the state of your thoughts in this area. I think we could arrange something
like a brainstorm during the weekend (on IRC ? could someone arrange something
like that for us ? You guys have servers with lots of stuff on them ?). Anyway
I'll try to post my ideas in a separate e-mail.

Looks like that's all for now.

I really look forward to your comments 
bartek 

-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/

Re: [GNUccess-design] Design plan

[Bartek W. <ba...@re...>]

Quoting Przemyslaw Krzysztof Rekucki <pr1...@st...>:

> 
> Currently we have following opened tasks:
> 
>  * GcEvn
>  * GcUtils
>  * GcObject Hierarchy
>  * GNUccess Application
> 
> Good names, but what this means ?
> 
> I will try to specify global architecture of planed system. 
> 
> .----------.
> | Modules  |
> `----------'
> 
> 1. Database Abstraction Layer (DAL)
> 

Just an interesting link (you probably all know it but i think it's quite nice)
http://www.python.org/topics/database/DatabaseAPI-2.0.html
There are lots of modules allready conforming to that standard - so we can think
of some kind of wrapper that would fit all of them - just a thought.

>   Posible features:
> 
>     - Visual Conection Constructor.

Here's the place for my problem. I really know that this is not very difficult
and there are thousands of ways to do it but I think that my idea is very nice
and elegant. 

So what's my problem ? I think that we will often have a situation like this -
user wants to create something in GUI. Let's say he wants a GcDataSource.
(somehow I prefer to call it Data source instead of Connection - i think that we
will have someday a nice XML internal datasource which is not "connected" to
anything :)

We could get all subclasses of GcDataSource from GcClasses and create a menu
position for each. But i think tere's a much more elegent way to do this. 

I we could change the interface - so that Create() returns the object it has
created. That would mean that our GcDataSource.Create() could have returned
something different then "self" (off course self would be the most common value)

Then we would have a very elegant way to create something. GcDataSource.Create()
-  would know what kind of subclasses it has and let you choose whhich you want.
Then it could invoke this class create method and return it's value. 

what do you think ? OK - i'll try not to digress so often :P
> 
>     - Datatype abstraction.
> 
>     - Query syntax abstraction. ( Created queries should work i every 
>       supported db engines)
> 
>     - Meta data access and modyfication support. (Adding column, 
>       deleting column, adding checks, itd. ) [TODO]
>   
>     - Python objects persistance
> 
Very nice. I like it - although we have to remember not to depart to far from
the efficiency.

> 2. Database Structure Editor/Creator 
> 
>   Posible features:
> 
>     - Adding Tables, Colums, Indexes, Constraints, itd..
> 
>     - ERD 

I think that fits into GcDataSOurce.edit()

> 
> 3. Simple data editor.
> 
>   Displays databse data in list and allows change, add or delete table 
>   row.
> 


> 4. RAD for Python
> 
>   - Forms creator
>   
>     - Properties editing
>  
>     - Layout editing
> 
>     - Some wizards
> 
>   - Componet Editor with Source code editing (shell is not enough)
> 
>   [TODO]

Looks like something to borrow from BOA.

> 
> 5. Components Core (GcObject) 
>   
>   my proposition:
> 
>   class GcObject:
> 	__editors__ = {
> 		'Name':	 Editors.Text,
> 		'Description': Editors.Text
> 	}
> 	__serializable__ = [ 'Name', 'Position' ]
> 	
> 	def toXML(self):
> 		xml = "<node class='"+self.__class__.__name__+"'...>"
> 		for var in self.__class__.__serializable__
> 			xml = xml +GNUccess.serialize(var, 
> 				     eval('self.'+var))
> 		...
> 
> 	def Icon():
> 		...
> 	
>   Filed __editors__ should declare inforamtion needed to generate 
> properties panel. 
> 
>   Other example:
> 
>   class GcButton(GcWidget):
> 	__editiors__ = {
> 		"Label": Editor.Text,
> 		"FrameColor": Editor.Color,
> 		"FrameStyle": WidgetEditor.FrameStyle
> 	}
> 	__serializable__ = GcWidget.__serializable__ + [ "Label", 
> "FrameColor", "FrameStyle" ]
> 	
> 	...

I'm not sure if I understand all this, but I'm not sure if one method
GNUccess.serialize will fit all the serializable properties. 
> 
> 
>   Ofcourse component <-> wx connection is missing. 
> 
Thats the thing. I meant GcDataSource as a generalized version of connection -
but i know that the usual name is connection.

> Other modules:
> [TODO]
> 

PS. Please post from the address that is subscribed (i guess it will be
sufficient to change from: header. Otherwise I have to accept your posts.
-- 
regards
   Bartek Wilczyński

[GNUccess-design] Design plan

[Przemyslaw K. R. <pr1...@st...>]

Currently we have following opened tasks:

 * GcEvn
 * GcUtils
 * GcObject Hierarchy
 * GNUccess Application

Good names, but what this means ?

I will try to specify global architecture of planed system. 

.----------.
| Modules  |
`----------'

1. Database Abstraction Layer (DAL)

  Posible features:

    - Visual Conection Constructor.

    - Datatype abstraction.

    - Query syntax abstraction. ( Created queries should work i every 
      supported db engines)

    - Meta data access and modyfication support. (Adding column, 
      deleting column, adding checks, itd. ) [TODO]
  
    - Python objects persistance

2. Database Structure Editor/Creator 

  Posible features:

    - Adding Tables, Colums, Indexes, Constraints, itd..

    - ERD 

3. Simple data editor.

  Displays databse data in list and allows change, add or delete table 
  row.

4. RAD for Python

  - Forms creator
  
    - Properties editing
 
    - Layout editing

    - Some wizards

  - Componet Editor with Source code editing (shell is not enough)

  [TODO]

5. Components Core (GcObject) 
  
  my proposition:

  class GcObject:
	__editors__ = {
		'Name':	 Editors.Text,
		'Description': Editors.Text
	}
	__serializable__ = [ 'Name', 'Position' ]
	
	def toXML(self):
		xml = "<node class='"+self.__class__.__name__+"'...>"
		for var in self.__class__.__serializable__
			xml = xml +GNUccess.serialize(var, 
				     eval('self.'+var))
		...

	def Icon():
		...
	
  Filed __editors__ should declare inforamtion needed to generate 
properties panel. 

  Other example:

  class GcButton(GcWidget):
	__editiors__ = {
		"Label": Editor.Text,
		"FrameColor": Editor.Color,
		"FrameStyle": WidgetEditor.FrameStyle
	}
	__serializable__ = GcWidget.__serializable__ + [ "Label", 
"FrameColor", "FrameStyle" ]
	
	...


  Ofcourse component <-> wx connection is missing. 

Other modules:
[TODO]

.---------------------------------.
| * Przemysław Krzysztof Rekucki .|
| P.R...@st... |
`---------------------------------'

[GNUccess-design] gnuccess-design list is working now

[Bartek W. <ba...@re...>]

Ok, Guys !

Looks like we have our mailing list. I'm not sure if we should post in polish or
english ? What do you think ?

-- 
regards
   Bartek Wilczyński