Everybody:
I've been planning this thing for many, many moons, but I finally sat down
and officially started work today on "Amadeus," a FREE Win32 Professional
IDE for Mozart-Oz. I'm in the process of setting up a site for it (not far
away from the Mozart-DLL site I started yesterday).
The GUI will be done in Delphi, because I'm really good at designing elegant
GUIs in it and for really no other reason, using a commercial package for
syntax highlighting memo from Dream Company (www.dream-com.com). I will
still be supplying all my project code for free, including all custom
components I develop for use in the IDE, but developers wanting to
change/modify Amadeus will have to have purchased both Delphi 5 or higher
and the related Dream controls version 4.1 or higher. I know that sucks, but
I'm sorry - it's my commercial development background. I will statically
link to the Visual Component Library (VCL) so there will be no need to
distribute Borland ".bpl" files with Amadeus, nor any requirement that users
already have VCL libraries, at least not strictly for the GUI.
I am contemplating a strictly Windows GUI toolkit extension of Oz to the
VCL, which would require then that these libraries be present in some form
on the user machine, just like one must have Tcl/Tk DLLs to use that
extension, but the licensing issues from Borland vis a vis distributing
these libraries are unclear to me at this time.
If anybody strenuously objects to Object Pascal, I can do it in Borland's
C++ Builder as well, it's just the same to me. Both use the same core Object
Pascal VCL. I just think Delphi's a bit more stable as an environment than
C++ Builder overall, having done lots of development in both. Some very
funky bugs in large C++ Builder projects...
I don't yet have Visual Studio.NET or I'd seriously consider that as an
alternative. I may port the whole thing to .NET later anyway, but for now I
want to build the GUI in something I know and can whip out fairly quickly.
The key features of the v1.0 environment will be:
* Project Management, allowing for structured development of:
- Standalone Functors
- Packages of Functors
- Native Functors
- Oz Library Extensions
- Oz Language Extensions
- Distributed Agent Solutions
* Automated build/compilation via complete integration with Ozmake
and the underlying Mozart-Oz tools (compiler, debugger, etc.)
- will generate and regenerate the Makefile.oz file for
each project.
- will also generate makefiles and templates for C/C++
extensions and native functors by integrating with GNU Make
and GCC on Cygwin. These operations will be transparent to the
developer using Amadeus. Options will be GUI driven.
* Will still be able to call up the various Tk-GUI based tools,
like the Browser, Panel, Inspector, etc., just like in
current OPI.
* Will have a separate Oz Console for interactive coding, i.e.,
so that folks can experiment with Oz while reading Peter's and
Seif's excellent book. :)
* Visual navigation of the project via both a "files" view and a
"functors" tree view.
* Syntax highlighting and customizable templates and code
sytle management facilities.
* Remote CVS check-in/check-out for collaborative development
* Decent help system
I'd really like to be able to implement an IntelliSense feature that can
even tag standard modules, but I suspect that should be a v2.0 feature,
unless folks are willing to wait until I retire in 35-40 years to get v1.0.
;)
If I ever do integrate Oz with the VCL, I'd be able, using the Dream
conrols, to add a GUI building environment not unlike Delphi's itself. But
that's waaaaaaay down the line...
I would also like to develop a COM component for Oz, but I think that effort
should await the results of the whole Mozart-DLL intiative. For now I can
integrate using standard windows piping and other tried-and-true tricks of
the trade. Tighter coupling via COM would be nice, but it isn't a
showstopper from getting a GUI put together that will work well with the
existing toolset.
My plan is to make Amadeus dependent on an existing installation of
Mozart-Oz, rather than attempt to bundle them together. It will add both the
IDE and any dependent *.ozf's I add to make it work with the existing
toolsets, as well as a COM interface, so the IDE can be automated with
scripting, for what it's worth. I'll use InstallShield installation, so
maybe I can make the IDE an installation "object" that can be included with
the core Mozart-Oz installer?
BTW, as an alternative to InstallShield, I might use Nullsoft's freeware
Windows installation script engine, NSIS. But since Mozart-Oz doesn't use
it, I'll probably just go ahead and use InstallShield.
I guess the big questions I have for those of you who would use this on
Windows are:
1. What features do you think are "must haves" and
which are "would be nice but not necessary" for v.1?
2. Would you be willing to beta test it when its ready
for that?
The goal of the GUI is to get Windows Developers to try Oz out. Emacs is of
course very cool, but most Windows developers aren't that, uh, used to the
Emacs paradigm, unless they come from a Unix background.
Any thoughts, suggestions, words of advice (particularly where integrating
with the existing toolset is concerned), etc., welcome.
Sincerely,
Bob Calco
-
Please send submissions to hackers@mozart-oz.org
and administriva mail to hackers-request@mozart-oz.org.
The Mozart Oz web site is at http://www.mozart-oz.org/.