(Quoting from several replies:) > I used Rekall, and also its big brother, Black Adder. I found Rekall > to be *too much* like Access - it really felt like a toy. Black > Adder, though, felt more like a real development tool.
But if we're purusing the end goal of making app development easy, what does it matter? Over the past 10 years or so, I've used various environments, including: Glade+GTK+Sybase+Cpp, MS-Access, FoxPro, Visual Studio .NET, and Rekall. They all involved basically the same thing: design a GUI using drag and drop methods, and add callback code to the fields. There were two primary differences: the languages used, and the built-in functionality provided. With Glade, MSVS, and FoxPro, you had to do a lot of stuff manually. With Rekall and Access, a lot of that sort of thing was provided automatically, reducing dev time. Access either uses a flaky back-end, or needs more work to connect to more reliable databases. Rekall automatically gives you that connection and is based on a scaleable platform (C++/Python). (Of course, whether or not Rekall itself is scaleable, I don't know.) Rekall may "feel like" a toy but I believe it gets results faster. > That would work if our goal was to be a wxPython-only product. But > although we only support wxPython now, our goal is to be UI-toolkit- > agnostic. You'll notice that we've gone to great lengths to get rid > of wxPython-specific conventions and naming practices in favor of a > more universal-feeling API for dealing with UI elements. When we > eventually wrap Qt and Tkinter, those same APIs will have to be > translated to native Qt/Tk classes and methods, just as we've done > with wxPython. May I ask why you went to the extra work to make things so agnostic? There are a few benefits you may derive from doing so: 1. If Environment X is produced by a company who decides to make undesireable license changes, or unfavorable legal conditions like patent claims make Environment X undesireable, it's easy to switch to Environment Y; 2. If the group who produces Environment X abandons the project, or does not perform in correcting errors, it's easy to switch to Environment Y - though this may not be a 'hard' cost if the source is available; 3. If Environment Y has Uber-Cool new feature Z, it's easy to switch. Does the cost (in increased complexity [therefore higher bug count], lower performance) outweigh the benefit? There was a discussion on one of the Postgres mailing lists about the benefits of making something database agnostic (and having to comply with the 'lowest common denominator' and related overhead) over choosing to base a product on one database and making it perform much better due to the optimizations of that database. If I was starting a project such as Dabo, I'd choose one open-source (therefore no lockin) toolkit (wxWidgets) and database (PostgreSQL) because I value efficiency over all else. But that's just me. > The general idea I foresee for the IDE is to define a connection, > and then retrieve the database/table structures, which are stored > locally. These can then be used to define bizobjs as well as the data > entry structures used to display/edit the values. That's a good idea, and it's probably better than having pre-built business objects in the IDE itself. I was thinking of taking the accounting application and abstracting it as a database with pre-defined tables. So, when starting a project, you could choose between the databases "Oracle", "DB2", "Postgres", and "Accounting"; if you chose Accounting it would have a set of pre-defined tables such as "Invoices", "Customers", etc. and the driver would talk to the accounting app server instead of a database. (Or, it could talk to SP's and views in the database server, see below...) > Quasar (LinuxCanada) is written in C++, is all hand coded. Which means it > is not easy to make simple mods. So the work Brad has provided is not easy > to extend. Heh... C++ isn't that hard, you just have to wear body armor. :) I didn't envision adding new features to Quasar or modifying the core compnents in any way - just providing an external interface to the data. There are a couple of ways to do that. Either, you can take the Quasar source code and wrap those C++ classes in Python classes, or you can just talk to the database that Quasar's data is stored in. I have had luck in the past with talking to the database that Quasar itself uses, to get customer information and generate invoices. Cheers, -J _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users Searchable Archives: http://leafe.com/archives/search/dabo-users This message: http://leafe.com/archives/byMID/dabo-users/[EMAIL PROTECTED]
