Wishes for XOTclIDE
Implemented wishes will be removed from the list.
Comments and Discussions about Wishes
Artur Trzewik as ATK 06.09.2004
Michael Heca = MH
ad 3 - This functionality is available from Classview (Create Instance)
MH: These objects are not saved in db/source code.
ATK: In traditional languages (even OO Languages) it is quite easy to distinguish between source code objects (structures) and run time objects (structures). In XOTcl it is not clear. Running programs can create new classes and methods. In C++, Java, C#, classes are typically source code objects and they are templates for objects, which are runtime objects. We have, in XOTcl, also metaclasses and objects without class (derived from xotcl::Object), which delegates and mixins we can use XOTcl even as prototype based language like Self. For XOTclIDE, it is important to know what is runtime and what is template (source code) also which should be put into version control. So currently Classes, Metaclasses and instances of xotcl::Object can be recognized by XOTclIDE and managed in version control. Instances of Classes are runtime objects and can not be managed. I think there are quite little benefits for making it possible for this IDE. (Anyway XOTclIDE does not make persistent the class variables but only procs and instprocs). On the other hand, XOTclIDE would be then a database for any XOTcl objects.
ad 5 - I thought registry was a better way for windows (more chic). Perhaps import and export function for preferences.
MH: I am developing on Linux and more version of Windows, with one home dir on net. It's hard to synchronize registry. And sometimes after a crash the registry is lost. I believe in files. If is ~/.xotlide in home dir, I prefer use it, otherwise registry.
ATK: OK. planned for next release - Up from 0.71 there are preferences importing/exporting function to file
ad 6 - XOTclIDE has one plugin that (like GNOME Babelfish) helps find and translate msgcat::mc expressions. But I do not plan to make it for XOTclIDE before version 2.0 ;-). Most Tcl programmers can use English. I myself use English programs for years even when my English is quite poor (and I do not like this queer language). I think most XOTclIDE potential users have no problems with English. For localization of XOTclIDE, one must find all language strings and replace each with [msgcat::mc "english"] expression; after that, man can use the plugin to produce suitable message catalogs. Anyway I would prefer esperanto as main XOTclIDE language but can not change the world.
ad 8 - almost every browser in XOTclIDE can have multiple instances. So how to preserve position of so many windows which have no fixed identity. Possible to remember preferred window's size for every browser type.
ad 13 - I thought about adapting Visual Tcl as Plug-In for it. But the main problem is not to build a Tk GUI but offer OO GUI framework. Good were something like Swing or .NET window forms widget set, which have also design time support.
ad 16 - We must wait for drag & drop support in Tk.
ad 23 - Yes. My dream is a public (internet accessible) version control database for XOTclIDE components. Currently XOTclIDE can not work with distributed version control instances, which will be needed for such things. Another one can by components saved which all needed version control information (possibly as XML). Not easy is to implement not full copy but compute only needed differences for update. So local version control system will update only needed methods (or another elements).
daapp Using Visual Tcl for GUI building is a bad idea; VTcl produces very bad source code; TkBuilder produces much better source code. My wish is something like Path browser from Python IDLE, e.g. browser for directories and folding for files in it.