I've long considered implementing a GUI for xmlsh.
I didnt do so from the start because I didnt want xmlsh to *be* the GUI (or require one). But now that the core is stable and mature, there are times when a GUI would be very useful.
Suggestions (and help!) welcome for this upcoming project.
Ideas I have
* optional. Core xmlsh not affected adversly
* portable. Probably (java) means using AWT or Swing ?
* atleast 1 mode that simulates a typical terminal with line editing
Onto things which might be really neat
* GUI view of variables
* debugger
* syntax sensitive source browser/editor
* multiple windows (one per thread ?)
* Eclipse plugin ?
A lot of things (and wasted time) could be put into this. I'd love feedback as if any of this seems useful to you.
You might want to consider the mysql 'client interface' as a model? The overall ideas are not dissimilar Dave? Two windows, script in the top, select one and results in the bottom? The 'connection' of mysql would be your input document selection?
ReplyDeleteDaveP
Dave (Lee) what kinds of things do you want the UI to do? An Eclipse PlugIn lets you use lots of neat features such as syntax coloring, marking bad statements, finding matching brackets, etc.
ReplyDeleteAll of the things I just listed are things I have wanted to do when working on XMLSH scripts. I worked on a project where we wrote an eclipse Plug-in for a complex (custom) ontology language. It can do the kinds of things you listed above.
Another Dave -
Dave Patterson
Great comments Dave(s). Good question which should drive the solution (providing I ever have enough time to implement it. What are the use cases. I have two in mind
ReplyDelete1) A slightly cleaner runtime/interactive experience that improves on the editing capibility of interactive use. The jline/readline is prety poor for unix use, and the DOS command history is prety poor. I dont really want to implement complex histor mechanisms and command editing in xmlsh itself as console GUI is very limited by the OS and by java itself. So having a GUI "terminal" enables things like cut/copy/paste, maybe syntax hilighting and seperation of input and output.
2) Debugging environment. This is a more ambitious goal (and hence less likely to be achieved quickly). I'd like a full debugging environment as you can do in eclipse with Java. An eclipse plugin might just be the ticket. But from my experience its a high learning curve to get started doing eclipse plugins.
An interesting observation is the two use cases overlap, if you add features to #1 it eventually becomes #2 so one thinks why not start at #2 first.
Final comment. Simple can be good. Going full eclipse might not be idea for simple use cases. Anyone ever use "bshui" (the builtin GUI for bsh aka BeanShell?) Simple, yet functional and starts up in a jiffy. Very low footprint.
Unfortunately it hardly does a thing.
Dave and Dave,
ReplyDeleteSome ideas on the UI topic.
1) It would not be too hard to write a Java Swing application as a graphic environment for XMLSH. I imagine it having a JTextArea for the input file, and one for the "console" output. Add in menu items to read the source file, save it and save the output file, and a workable application would be available. JTextAreas are editable by default.
2) If the solution is based on Eclipse, it can do a lot more. It is possible (but I've never done it myself) to do "syntax coloring" and on-the-fly parsing. (The ease of doing this is a function of how well the syntax of XMLSH can be described.)
You would also need to implement functions to find where a variable is defined. That is, to go from a statement containing a "$foo" and find the place where there is a "foo=" or a "for foo in ..." or "xread foo < ...".
3) With access to the XMLSH source, you can use the Java debugger, but that is down in the weeds for most of us. I have no idea how to do it, but it should be possible in Eclipse to build a debugger that would allow you to single step XMLSH statements (not Java statements). I expect this would be A LOT of work.
There is a lot of documentation that comes in Eclipse for the extensions provided with Eclipse, and the APIs to use them. There are a lot of tutorials, with some very good ones posted by Lars Vogel (www.vogella.de).
A very good book is "Eclipse Plug-ins" by Eric Clayberg and Dan Rubel (Third Edition). There is a 4th edition that is due in February 2012.
The other thing that helps in Eclipse is that it is possible to find examples of use of almost all features, since most were added in order to perform a needed activity.
Dave Patterson