Wishes for XOTclIDE

Implemented wishes will be removed from the list.

  1. Warn if editor context is modified before switching to other method.
  2. Optionally show comment above code without switching.
  3. Create object of other type than Object.
  4. Custom key binding.
  5. Option to store preferences in file on Windows, not in registry.
  6. Localization support ?
  7. Rewrite all dialogs to panedwindow if supported in Tk - working on it Michael Heca
  8. Preserve windows' positions.
  9. Toolbars and buttons (Above method list: new | override | delete | split edit | invoke)
  10. Global search text in system menu, not only from method menu.
  11. Popup menu for multiselect list: select all | unselect all | invert selection
  12. Better deployment of tclkits. Including additional libraries from for example kitten or another binary files.
  13. Zoom function by view panels (double click enlarge the panel).
  14. GUI Builder.
  15. Another Plugin architecture. Not plugins-list with component references but plugins directories with self-described files. (suggested by Michael Heca).
  16. Drag and Drop support (class/variable to tracker, ...) - MH
  17. Move split edit command to editor, not only in method menu on component browser - MH
  18. Extreme Programming project manager like XPWeb http://xpweb.sourceforge.net/ - MH
  19. Split edit synchronization like text::sync - MH
  20. Collapse/expand block in editor - MH
  21. Preload component from command line - patch send MH
  22. Send mail with all modifications in IDE - MH ;-)
  23. Auto update like StarKit - MH
  24. Class/object command that will be merged in all appropriate list/menu command. - MH
  25. Tcl/Tk help integration to source editor. - MH
  26. List all todo lines (or glob/regexp defined) from whole sources and comments. - MH
  27. Icon for XOTclIde - MH
  28. Support for class/object popup menu extensions. - MH
  29. Introspection from method tracker window. - MH
  30. Modified list element which allow working with customized labels (example. show method arguments ...) - MH
  31. Redefine class in edit window. - MH

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.