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

Re: [sc-dev] Cross-platform IDE things: "Document" as the home of IDE awareness


On Friday 26 December 2008 16:06:37 Dan Stowell wrote:
> There's been some discussion about cross-platform-ness. Specifically,
> the primary home for crossplatform awareness is the Platform class
> (osx/windows/linux) but there's been some concern because now the
> choice of IDE (cocoa/emacs/vim/eclipse/psyco) is more and more
> independent of platform choice. Someone suggested we should create a
> new "IDE" class or some such, to encapsulate this knowledge.
> I just noticed that Document already is the home of IDE awareness.
> Document.implementationClass tells us if we're using CocoaDocument or
> ScelDocument. I've added a rudimentary PsycolliderDocument class. We
> could create an EclipseDocument class and a VimDocument class
> (eventually, these classes will do useful things).
> So we could make the Document class do similar things as the Platform
> class, e.g. the rather nice Platform:case functionality. At its most
> basic this would look like...
> 	*case { | ... cases |
> 		^implementationClass.name.switch(*cases)
> 	}
> ...and would give us a syntax like...
> Document.case(
>     \CocoaDocument, { "I like SuperCollider.app best".postln },
>     \ScelDocument, { "I like emacs best".postln }
> );
> ...but that syntax is a little graceless, so maybe better would be to
> add a class variable "ide" to each Document subclass with a nicer
> value such as \cocoa, \emacs, \psycollider, \eclipse. The syntax would
> look more like
> Document.case(
>     \cocoa, { "I like SuperCollider.app best".postln },
>     \emacs, { "I like emacs best".postln },
>     \eclipse, { "Real coders use eclipse".postln }
> );
> There are a couple of things in the class library that already need to
> account for choice of IDE. This would streamline that business IMHO.
> I propose to commit this added functionality to Document and subclasses.
> Let me know if there's something I haven't accounted for... (I bet there
> is...)


That may obscure things a bit though.

There is the document class, which should have access to different documents 
that are open in the current editor (scapp, scel, scvim, psyco, sced, etc.), 
but other things are also different per "ide", like help file access, gui 
access (embedded or external), additional menus, accessing extra 
functionality (e.g. sending lisp code to emacs).

Right now the central place for setting the Document class is in Platform; in 
the emacs case the class Emacs checks if the pipe with emacs is initialised 
succesfully, which sets the feature \emacs in Platform, which then during 
startup sets ScelDocument as the Document implementation class.

If we see the "ide" as a feature of the Platform on which we are running, this 
is a rather simple way, that doesn't need a new class to be made, as this 
functionality is already present, but not used a lot.
(only a proper primitive or whatever is needed for scapp which sets the 
feature on startup).

The only interesting new addition that could be interesting is to add an 
extension directory called Features which can contain dirs like

etc., for classes which only need to be compiled upon library compilation if 
certain features are present.
This may need some thought though.


sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: https://listarc.bham.ac.uk/marchives/sc-dev/
search: https://listarc.bham.ac.uk/lists/sc-dev/search/