On Jun 6, 2007, at 5:41 PM, Josh wrote:
> Aside from Java, there is one environment that I've used: Rekall.
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.
Neither Paul nor I set out originally to create something like Dabo.
We both thought that there already had to be something out there
already, and while there are several tools that sort of did what we
were looking for (Black Adder, QtDesigner, GNUe, etc.), all of them
lacked in some critical areas, and with the exception of GNUe, were
not open source, so we couldn't make them work the way we wanted.
Hence, Dabo.
> So, I wonder, how much more work is involved in making Dabo up to
> par with
> where Rekall was?
Unless I missed a large part of what Rekall could do, we're way past
that.
> What about if we add other Python-based components,
> such as Stani's Python Editor, and one of the visual wxPython-based
> GUI
> editors? If we do so, we make a giant leap in the right direction
> with
> regards to easy cross-platform RAD.
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.
I tried to adapt wxGlade to work with Dabo classes, and there are
simply too many places where it assumes that you are working with
wxPython, and it was almost impossible to get it do anything useful.
The sad truth is that while code re-use is great, there are times
when existing code is too specific to be adapted to more general
usage. This was the case here, which is why I wrote the Dabo Class
Designer from scratch.
> There is one side-note, however. Even if we have the best RAD,
> developing
> in Python may be a turn-off for commercial app developers because it's
> nary impossible to obfuscate Python code. But, it does open the
> door for
> open source developers to create cross-platform vertical apps.
I'm not concerned with the obfuscation question. If that's an issue,
they aren't going to be looking at Python anyways, whether it's Dabo
or PythonCard or anything else.
> But there's another twist. Suppose we were to add a pre-defined
> set of
> Business Objects to our RAD environment, such as Customers, Vendors,
> Items, Accounts, Invoices? And, suppose that those business
> objects just
> happened to come with a fully-featured accounting application, on-
> par with
> QuickBooks Enterprise as far as maturity, support, and featureset are
> concerned? And suppose it was all free?
That doesn't sound like something that would be a part of the Dabo
framework itself, but rather part of the eventual Dabo IDE that I
hope to be starting on soon. The Dabo IDE, like the Dabo Class
Designer, will be written in 100% Dabo code, so it will be easy for
others to create their own classes, form templates, etc., and make
them available for others to use.
> Imagine this. You're designing a new app for your vet's office.
> In your
> GUI editor, you start with the main window of a blank project. To
> create
> a "New Customer Entry Wizard", you simply drag a Customer object
> from the
> Business Object pallette onto the main window, and you're all set.
> You
> press the test button, and you can browse customers that are
> already in
> the accounting app's database with your new wizard.
That's assuming, of course, that your pre-made business object knows
the exact structure of the tables in the database, and also knows how
to connect to it. What I think is a more valuable approach is along
the lines of the Quick Layout Wizard, which I demo'd in these
screencasts:
http://leafe.com/screencasts/dataenvironment1.html
http://leafe.com/screencasts/dataenvironment2.html
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.
> I think we can get this functionality, it's just a question of how
> much
> work?
Lots and lots. Trust me; I thought that creating a wizard to grab
data environment information and create a live form would take me
about 2-3 days. It ended up taking me over a month. Yeah, the basic
stuff worked great after a couple of days, but there were so many
tangential issues that are involved in creating a generic tool for
mass consumption. I could have made it good enough for me to use
pretty quickly, but to make something that 95% of developers could
use for their needs is not trivial.
BTW, I've started a general discussion on ideas I have for the IDE.
It's really sketchy right now, as I've only had a little time to copy
some of my notes there, but feel free to add your ideas. The page is
http://dabodev.com/wiki/IDEDesignIdeas
-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com
_______________________________________________
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]
