[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [sc-dev] library config

On Wed, 17 Dec 2003 18:41:22 +0100, stefan kersten <steve@xxxxxxxxxx> wrote:

On Wed, Dec 17, 2003 at 04:03:08PM +0100, Arve Knudsen wrote:
Perhaps the LanguageClient is still a little too tied to console
semantics, like parseOptions and printUsage? I'm thinking it should rather
contain minimal functionality, common among clients (graphical, console,

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).
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.

It offers what I identified as basic services, such as interpreting
command lines. I don't know SuperCollider very well yet though, so I could
be 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 deriving
class' 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 ...
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.

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
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.

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.
But the base implementation could offer a utility function called by the "user"?

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 with
scripting 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 ;)
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.


Arve Knudsen