Ed Leafe wrote:
With all the talk recently about modifying the Class Designer to
handle code separation, I realized that one of the main reasons for my
resisting this is because I feel like I have a ton of stuff on my plate,
and very little time to get it done. Adding another thing to test and
integrate, even if someone else wrote the code, when that wasn't moving
us closer to established goals, just seemed counter-productive.
I think everyone involved completely understands that sentiment.
Regarding established goals, perhaps it would be worth it to step back a
bit and actually specify what the established goals are. So far, I
believe our goals have been basically the same, but we've never actually
sat down together and fleshed them out on paper. If we ever succeed in
meeting up for a few days for a sprint or something, I'm inclined to
suggest that we leave the laptops behind, purchase some butcher paper
and crayons, and draw out interface designs and flowcharts, and then
publish those designs on the web for comment and modification as needed.
So I'd like to let you all know what I'm working on, and if you'd
like to help, please let me know.
• Localization: we need someone with solid localization experience with
whom to collaborate on the proper way to add localization to the
framework. We also need translators, as well as the tools to automate
this. The basic guts of the localized string extraction from the
framework code is complete and working; I plan on creating the tools,
but first we need to get the whole gettext() file requirements settled
so that the tools can put the files in the correct places.
• Preferences: I'm working on this now, and need feedback/input on the
implementation. Perhaps some examples of the sorts of preferences you
envision for your apps, as opposed to the internal framework stuff,
would be useful to make sure that the design is flexible enough to
handle all of them.
• Editor: we need better namespace resolution in Intellisense. It's
silly that typing 'self.Form.' brings up the atts of the Form property,
instead of the atts of the form itself. If anyone wants to look into
this, I'm willing to help any way I can. Also, we could use some ideas
on how to limit the list of atts/methods/properties to Dabo-specific
ones instead of everything, especially the wx-specific ones. I'm not
sure that a reliance on capitalization patterns is best, since I've
noticed that many Dabo users write code that looks more like wxPython
than Dabo, and their custom stuff should show up, too.
This is a big problem, because we are basically relying on introspection
of live objects, and introspection can hog a lot of resources, resulting
in an unresponsive editor. Also, anything goes with Python's dynamic
objects, so there may always be cases of infinite loops and unexpected
behavior. Perhaps something will come out of the pyxide's project that
we can plug into and contribute to.
The capitalization pattern recognition allows us to eliminate 95% of the
names in the namespace (all the wx.* cruft) right off the bat, which is
why I programmed it that way, but I agree it isn't optimal. It does
provide a little built-in coaching to convince people to conform to our
Dabo Style Guide. ;)
• Documentation: While I've made some progress, we need a ton more. I
believe that exhaustive documentation, in which every single aspect of
the framework is documented, is almost as bad as no docs at all. What
would really help is to explain what sort of help you were looking for
and couldn't find. Chances are that the documentation doesn't exist, or
exists in a place that isn't obvious. If you let me know what's
confusing, or what's lacking, that will be the place for me to focus on.
I really do intend to do The Dabo Book, which will read like 'wxPython
In Action' if I'm successful.
• Connectivity: I'd really like to get VFP connectivity done soon, if
only to be able to show Dabo working with Fox data when I speak at the
FoxForward conference in September. Since there are no VFP ODBC drivers
on platforms other than Windows, the only solutions I've found are ODBC
bridges that run a server ODBC on the machine containing the data (and
the VFP driver), and a client ODBC that talks to the server. All such
solutions I've found cost about $1000 to start, and contain strict
licensing. So if anyone knows of any other platform-independent way of
talking to Fox data, that would be great. I'd also like to get SQL
Server and Oracle implemented, but since no one is pushing for those
right now, it would be difficult to get any sort of testing done with them.
At the very least, we should get the pyodbc stuff working, and then
provide a vfp abstraction layer that uses odbc. This would allow a
Windows-based dabo application to talk to VFP data. I believe it would
also mean we could connect via Linux and Mac using Samba mounts as well.
I'll enter this as a tracker issue and assign it to me. I'm pretty sure
I had POC code that did just this, years ago.
• IDE: I've only started playing with PyAUI
(<http://xoomer.alice.it/infinity77/eng/PyAUI.html>), which seems like
what we would need for the interface. We need to spec out exactly what a
project consists of, and how to best manage these pieces. We need to
write the missing parts (bizobj editor, project manager, debugger) and
integrate the existing tools.
Yep, although hopefully we don't have to write our own debugger.
Paul, if you're working on anything, it might help to let everyone
know what that is, and where you could use some help.
Right now, I'm working on getting some paying work lined up for the
summer, and yes, I could certainly use some help with that! :)
--
Paul McNett
http://paulmcnett.com
http://dabodev.com
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev
