Design wise, I don't know if it makes sense to put command line parsing in a client base class, since it wouldnt necessarily be needed in a GUI client I think. Perhaps this could be delegated to a policy (template) class? That way the option parsing wouldn't be fixed either (could be used by clients with differing options). Which toolkit are you using with the GUI client? If you could use some help I'd be interested. I've done a little GUI (mostly Qt) before, but nothing major. I would love to see a proper Linux GUI for SuperCollider.On Wed, Dec 17, 2003 at 04:03:08PM +0100, Arve Knudsen wrote:Perhaps the LanguageClient is still a little too tied to consolesemantics, like parseOptions and printUsage? I'm thinking it should rathercontain minimal functionality, common among clients (graphical, console, whatever).command line parsing is optional, you can use the defaults or pass in an option struct. i'm working on a gui application that uses the language client base and does its own command line parsing in addition to options parsed by the base class (just like the terminal client).
You mean s_interpretCmdLine etc? I've kept these inside the SC_ClientBase class, and users of this class will use it's interface instead. If need be, I don't think it would be a problem to pass these pointers between objects.It offers what I identified as basic services, such as interpretingcommand lines. I don't know SuperCollider very well yet though, so I couldbe way off. I implemented it as a concrete class as well, because I dont_think_ it would be necessary to make these services part of the derivingclass' interface (the Liskov IS-A principle).i need the notifications from the library in my subclass to define primitives etc. without subclassing you'd have to pass function pointers, which may or may not be more tedious ...
Ok, like I said I'm only getting to know SuperCollider. I'm thinking it wouldn't make sense to define these free routines within the base implementation, although there could be static (utility) defaults within this class.I'm attaching my version of SC_TerminalClient.cpp and SC_ClientBase.cpp in case you care to comment (keep in mind the interface could probably use some work).the language 'user' needs to redefine behavior of two more aspects, depending on the particular application: in a gui application the post routines will write to some text output window.
But the base implementation could offer a utility function called by the "user"?the tick method needs to be called from the application main loop. i just realized that AppClock is _not_ supposed to run in a separate thread, so the terminal client needs to dispatch in its input loop to periodically trigger the AppClock driver.
Ok! I'll keep working on it, but I think I need some way to intercept standard out and display it within Vim. I'm not quite sure how I would go about this, but hopefully I'll come up with something.I don't really know how the integration is done with Emacs (there are some SC language files involved from what I can see), but I played around withscripting SC from within Vim (with Python), with an interface to SC_ClientBase generated by SWIG.emacs just reads from sclang's stdout, passes code to stdin and uses a fifo to get information back from the language.I'm currently able to evaluate blocks/lines of code at least. There isnt any existing Vim plugin for SC is there?none that i know of. i do know some vi freaks, however, who probably would be very interested in something like that ;)
Regards Arve Knudsen