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

["Dan Stowell" <danstowell@xxxxxxxxx>]

2008/12/27 nescivi <nescivi@xxxxxxxxx>:
> Hiho,
>
> 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...)
>
> Hmm..
>
> 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).

OK, yes.

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

Hmm, well here's what I don't really like about that approach: the OS
is represented using a lovely class-inheritance structure (*Platform)
with an API etc, but the IDE is represented simply as an entry in an
array of "features" (the \emacs feature). In reality, the OS and the
IDE are almost-independent variables both of which have almost-equal
ontological significance to the supercollider user, in terms of
providing/preventing functionality etc. It feels very odd that we
should relegate one to being junior to the other.

Would it be so bad to have an IDE class? Seems like there's already
quite a bundle of IDE-issh stuff which might be better placed there
rather than in Document or Platform.

Dan

_______________________________________________
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/