Fabricio Rocha - 10 May 2011 - I have been spending most of my spare time in this, for more than three or four years. Sometimes a light turns on in my head and I get really inspired. Sometimes the inspiration grounds, or I feel I'm losing my time, or that the whole idea is completely flawed. Anyway, I can't, never could and never wanted to do it all alone. So, before I run out of ideas (after restarting from scratch THREE times), I'd like to present some ideas I have for an open-source, free, Tcl/Tk-based RAD tool, and I'd be glad to receive some opinions and suggestions about it. I call it "TKtEasy".
In very few words, I've been disappointed for years about how programming became difficult when compared to the 8-bit BASIC era. If you got an easy toolset and language, it was not multiplatform. Discovering Tcl/Tk was amazing, but I really (still) miss a good, visual programming environment for it, and I am sure that there are lots of other hobbyist programmers like me (and some professional programmers as well) which are somewhat bored by programming like it was done back in the 70s and 80s.
Since I knew about HyperCard and similar tools, like HyperStudio and Amiga CanDo, I am fascinated about the idea of "creating programs without programming", or at least "writing no more than few lines". It is curious to know that Tcl/Tk itself was inspired by HyperCard but it's still so much text-based. Being so flexible, versatile and portable, Tcl/Tk could benefit a lot from a RAD tool which could attract programming newbies and newcomers.
Of course there are the professional tools, like the ActiveState ones, and there are some few free visual IDEs for Tcl/Tk, like TKProE and Visual Tcl. Maybe I don't know them so well, but I would like to see some different things in my still-hypothetical IDE (feel free to comment or suggest other ones):
1) Completely modular and extensible. Not only in the programming scope. Don't like the bundled GUI builder? You can use a third-party one, or write your own, or maybe SeS would adapt his tG² for the environment. Don't like the bundled editor? You could use a wrapper for vi, Geany or *Notepad. You could install a debugger. Maybe a packager module which could create starkits or DEB packages. An "images manager" module which could convert icon files to encoded images bundled on your scripts. Maybe you'd like to create procedures from diagrams, with a module more or less like Theo Verelst's bwise, and the IDE would add the generated procedure to a certain script file. If you are using the GUI editor of your choice, and you'd like to add a menu to a toplevel, clicking on the "Add menu..." button or menuitem would bring on the menu editor of your choice. Everything integrated, readily available. The extensibility might extend to the modules as well: for example, support for BLT or BWidget could be optionally added to the GUI builder.
2) The modularity would fit well a concept that applications are made of "elements" (or "resources", whatever), such as translation (msgcat) files, GUI dialogs, menus, toolbars, HTML help files or man pages, databases support, data files, icons and images (both in files or encoded), user-created procedures, library- or package-provided procedures, etc. Different softwares would require more or less elements than others, of course, and this concept would also allow the offer of different "software templates" for libraries, server apps, megawidgets, etc.
3) I like the idea of having "project managers", modules which would be responsible by organizing the application files, saving and loading an application, etc, working as "client" of the core, which in contrast would manage the installed or in-use modules, and each application's elements, metainformation, dependencies, etc. This could make the whole system different from the GUI-builder-centered interface we find in most visual IDEs. A certain project manager could be a "wizard-style" program which would set up project directories and files, create placeholders for some elements, etc. Another project manager could be workflow-based for group/network development, and include support for SVN. Another one could guide you through the creation of the different elements from an UML or similar flowchart. Another one could be outline-based, and so on.
4) Heavily documented for the sake of maintainance, extensibility and user-friendness. I saw some problems in this aspect with some IDEs...
5) The generated code should, as much as possible, look like "hand written code". I find it hard, for example, to understand the variables and arrays created by vTCL (plus it adds a lot of stuff to a simple "Hello, World" program, much of it due to the way vTCL loads an application into itself). I think that maybe a data-only file, with one or few more runtime scripts for creating objects like images and dialogs in runtime from this data file, could allow you to use "real" widget names in your code, for example; the "constructor" scripts/procedures would be used only in startup for creating the "real objects". It is more or less the same idea I saw in some pages here at the Wiki, like code is data, Basic GUI Builder and Serializing a widget.
6) In HyperCard and alikes, someone could define an "action" (to happen when a certain button was clicked) from a list of "common actions" such as copying the contents of a field, closing a window, exiting the program, running an external program, etc, or just running a user-created procedure. It looks relatively easy to have something like that in a Tcl/Tk RAD tool, specially for its GUI builders. A "library manager" could offer a set of procedures/scripts, each one having an "arguments panel": imagine choosing an action for a button, such as "Close window", then choosing from a combobox which of the application windows is the one to be closed. The user would not have to deal with real code or procedure calls: the library manager would keep control of the application's dependencies on external programs, libraries/packages and/or scripts; and this would even allow the environment to provide code and different versions of the library for different programming languages (Lua? Python?). Also, the library could be extended by user-created or freely distributed "actions packages" -- simple scripts along with data for runtime creation of the "arguments panel" for each procedure.
As I said previously, I have restarted the whole thing three times already. I really won't disagree if you say that the whole idea is way too complex for someone who still haven't had a lot of Tcl/Tk in his bag (even more if this someone is no more than a hobbyist programmer). Apart of flying high, reading a lot, writing and rewriting plans and losing hair on the way, this is what I was able to do until now:
Of course time is lacking and there is a lot of questions for which I still haven't found good solutions. Suggestions are welcome:
Well, maybe this is already a lot of information for the moment. If you think this is all nonsense, or unneeded, or something desireable, please say it. Any suggestions and opinions are welcome... even if they convince me that I should waste my time with something else.
SeS 1-6-2011 Fabricio, I think the way to go is indeed stepwise, the Proplist, the "properties list" megawidget is a good example. I started with the tcl/tk Gui Generator tG² as a pure script generator, then I discovered I need this, I need that, it has grown & evolved with time, also my knowledge in tcl/tk has evolved with time and hence opened new doors. I simply was not able to do the things I wanted or had in my mind, when I started developing tG². Basically, I needed an engineering solution asap at that time which I needed to use in my daily hobby & work, that's why I had no luxury to relax and think of the complete architecture of an IDE or communicate it with others in the tcl/tk community. And, by the time one has an agreement on how to tackle issues/problems, time is flowing away. I think, one risks having only building blocks and no practical solution, I wanted to prevent this from the start. I think, every medal has 2 sides, on the long run, I think your approuch is better: first all building blocks, then integration according a well thought architecture.
Anyway, I will keep your recommendations and hints in my mind and many thanks for your evaluation and sharing your thoughts!