Menu
▾
▴
pythoncard-users
|
From: John M. <jm...@um...> - 2004-10-15 15:29:46
|
I'm glad you brought up this thread again because I had been wanting to mention DABO: http://dabodev.com/ This aims to be an open source Filemaker/FoxPro visual IDE replacement. From their site: """ Dabo is a 3-tier, cross-platform application development framework, written in Python atop the wxPython GUI toolkit. Dabo's authors, Ed Leafe and Paul McNett, have strong backgrounds in database application development using the awesome and underrated Microsoft Visual FoxPro development environment. While Visual FoxPro shines at developing data-centric applications, it has one limitation that cannot be ignored: it only runs on Microsoft Windows, and Ed and Paul both have clients that want their applications to run on Linux and Macintosh. We are sure we are not alone in this regard: it is a multi-platform world with more diverse needs than one vendor can fulfill. """ I'm wondering if there could be any useful cross-pollination between DABO and PythonCard? John Miller On Oct 14, 2004, nor...@on... wrote: > I make an apology first. After an initial burst of activity, I haven't > been doing much in actually using PythonCard. This doesn't mean my > interest has not been fired. However, my initial interest was my quest > to see if a Filemaker replacement might be possible. > > What I have been doing is looking around in the open source community > for the various components that might contribute to such an enterprise. > > Database engine: > I have messed around with Firebird and it seems OK. Then I noticed that > sqlite - that I had been avoiding - is not too fussy about storage > types > and requires no pre-definition of data size. This would appear to offer > a potential fit to the way Filemaker operates on data. The problem with > sqlite - at least I think it is a problem - is that it is does not > follow the client/server model. However, for the smallish companies > that > dominate the Filemaker client base, sqlite may service requests rapidly > enough for this not to be a problem. > > What may be being worked on is a front end queuing mechanism that will > serve requests to sqlite. It appears that sqlite might evolve towards a > client/server model. > > Sqlite is moving to version 3. This gives a choice of specifying data > types or not which makes it an even better match for how Filemaker > represents data. > > A reporting tool: > Kevin Altiss found the excellent discussion on Filemaker replacement on > slashdot. One comment in this thread made me realise how important an > area Filemaker's reporting is. That thread also led me to DataVision > (http://datavision.sourceforge.net/) which I haven't tried but looks a > very promising report tool that would be much more powerful and > flexible > than that of Filemaker. > > Extracting/converting data from Filemaker: > pyFilemaker seems to extract as much as FM is willing to give. An > interesting project in PythonCard would be to attempt to generate a > default database front end from this information. This would only be > bare bones compared with how the Filemaker front end would look, but > often, having a place to start is enough to get one going. > > Well, this is not an exhaustive list of what would need to be done but > I > thought it worth giving this report as the initial discussion seemed to > generate interest. > > > I must add in conclusion that I am enjoying learning Python and have > produced a tool I use every day in relation to Filemaker. It is called > 'xpdfBatch.py' (or xpdfBatch.exe) and produces this output when invoked > from the command line with the '-h' option: > > xpdBatch.py - extracts text from pdf files in current folder. > Depends on pdftotext from Glyph & Cog, LLC: > http://www.foolabs.com/xpdf/ > > Usage: with no arguments processes pdf files not already done > If argument is: > a pdf file: (must be quoted if containing spaces) process > that file > 'all': (without the quotes) process all pdf files. Any > '.txt' > files > existing will be overwritten. > -h: show this help > > I use it as Filemaker prints scripts only as pdf. > Haven't tested it on the Mac yet but will. > > I have been very impressed by the patience and helpfulness of this > community, > > Norman |
|
From: Kevin A. <al...@se...> - 2004-10-17 17:03:29
|
beware, middle posting below... ;-) On Oct 15, 2004, at 8:29 AM, John Miller wrote: > I'm glad you brought up this thread again because I had been wanting > to mention DABO: > > http://dabodev.com/ > > This aims to be an open source Filemaker/FoxPro visual IDE > replacement. From their site: > > """ > Dabo is a 3-tier, cross-platform application development framework, > written in Python atop the wxPython GUI toolkit. > > Dabo's authors, Ed Leafe and Paul McNett, have strong backgrounds in > database application development using the awesome and underrated > Microsoft Visual FoxPro development environment. > > While Visual FoxPro shines at developing data-centric applications, it > has one limitation that cannot be ignored: it only runs on Microsoft > Windows, and Ed and Paul both have clients that want their > applications to run on Linux and Macintosh. We are sure we are not > alone in this regard: it is a multi-platform world with more diverse > needs than one vendor can fulfill. > """ > > I'm wondering if there could be any useful cross-pollination between > DABO and PythonCard? > > John Miller Almost certainly. I've exchanged some email with Paul and talked to him at OSCON. However, I told him that until they change their license to something other than the GPL I won't even look at the code or think about incorporating it into parts of PythonCard since I have no intention of having PythonCard succumb to the GPL. http://dabodev.com/licensing I'll be happy to take a look and collaborate once the license is changed. Paul is of course welcome to contribute to this discussion and PythonCard as long as GPL code doesn't get rolled into the project. ka > On Oct 14, 2004, nor...@on... wrote: > >> I make an apology first. After an initial burst of activity, I >> haven't >> been doing much in actually using PythonCard. This doesn't mean my >> interest has not been fired. However, my initial interest was my quest >> to see if a Filemaker replacement might be possible. >> >> What I have been doing is looking around in the open source community >> for the various components that might contribute to such an >> enterprise. >> >> Database engine: >> I have messed around with Firebird and it seems OK. Then I noticed >> that >> sqlite - that I had been avoiding - is not too fussy about storage >> types >> and requires no pre-definition of data size. This would appear to >> offer >> a potential fit to the way Filemaker operates on data. The problem >> with >> sqlite - at least I think it is a problem - is that it is does not >> follow the client/server model. However, for the smallish companies >> that >> dominate the Filemaker client base, sqlite may service requests >> rapidly >> enough for this not to be a problem. >> >> What may be being worked on is a front end queuing mechanism that will >> serve requests to sqlite. It appears that sqlite might evolve towards >> a >> client/server model. >> >> Sqlite is moving to version 3. This gives a choice of specifying data >> types or not which makes it an even better match for how Filemaker >> represents data. >> >> A reporting tool: >> Kevin Altiss found the excellent discussion on Filemaker replacement >> on >> slashdot. One comment in this thread made me realise how important an >> area Filemaker's reporting is. That thread also led me to DataVision >> (http://datavision.sourceforge.net/) which I haven't tried but looks a >> very promising report tool that would be much more powerful and >> flexible >> than that of Filemaker. >> >> Extracting/converting data from Filemaker: >> pyFilemaker seems to extract as much as FM is willing to give. An >> interesting project in PythonCard would be to attempt to generate a >> default database front end from this information. This would only be >> bare bones compared with how the Filemaker front end would look, but >> often, having a place to start is enough to get one going. >> >> Well, this is not an exhaustive list of what would need to be done >> but I >> thought it worth giving this report as the initial discussion seemed >> to >> generate interest. >> >> >> I must add in conclusion that I am enjoying learning Python and have >> produced a tool I use every day in relation to Filemaker. It is called >> 'xpdfBatch.py' (or xpdfBatch.exe) and produces this output when >> invoked >> from the command line with the '-h' option: >> >> xpdBatch.py - extracts text from pdf files in current folder. >> Depends on pdftotext from Glyph & Cog, LLC: >> http://www.foolabs.com/xpdf/ >> >> Usage: with no arguments processes pdf files not already done >> If argument is: >> a pdf file: (must be quoted if containing spaces) process >> that file >> 'all': (without the quotes) process all pdf files. Any >> '.txt' >> files >> existing will be overwritten. >> -h: show this help >> >> I use it as Filemaker prints scripts only as pdf. >> Haven't tested it on the Mac yet but will. >> >> I have been very impressed by the patience and helpfulness of this >> community, >> >> Norman |
|
From: Andy T. <an...@ha...> - 2004-11-21 12:05:46
|
Kevin Altis wrote: > beware, middle posting below... ;-) > > On Oct 15, 2004, at 8:29 AM, John Miller wrote: > >> I'm glad you brought up this thread again because I had been wanting >> to mention DABO: >> >> http://dabodev.com/ >> >> This aims to be an open source Filemaker/FoxPro visual IDE >> replacement. From their site: >> >> """ >> Dabo is a 3-tier, cross-platform application development framework, >> written in Python atop the wxPython GUI toolkit. >> >> Dabo's authors, Ed Leafe and Paul McNett, have strong backgrounds in >> database application development using the awesome and underrated >> Microsoft Visual FoxPro development environment. >> >> While Visual FoxPro shines at developing data-centric applications, it >> has one limitation that cannot be ignored: it only runs on Microsoft >> Windows, and Ed and Paul both have clients that want their >> applications to run on Linux and Macintosh. We are sure we are not >> alone in this regard: it is a multi-platform world with more diverse >> needs than one vendor can fulfill. >> """ >> >> I'm wondering if there could be any useful cross-pollination between >> DABO and PythonCard? >> >> John Miller > > > Almost certainly. I've exchanged some email with Paul and talked to him > at OSCON. However, I told him that until they change their license to > something other than the GPL I won't even look at the code or think > about incorporating it into parts of PythonCard since I have no > intention of having PythonCard succumb to the GPL. > > http://dabodev.com/licensing > > I'll be happy to take a look and collaborate once the license is > changed. Paul is of course welcome to contribute to this discussion and > PythonCard as long as GPL code doesn't get rolled into the project. > > ka > [snip] > According to the web site they changed to the MIT license at the beginning of November. Which is the same license as PythonCard. Regards, Andy -- ----------------------------------------------------------------------- From the desk of Andrew J Todd esq. "So I curtailed my Walpoling activities, sallied forth and infiltrated your place of purveyance to negotiate the vending of some cheesy comestibles." - Monty Python. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X