[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

Hi guys,
I think it might be worth keeping IDE separate. Let me introduce the possibility of 'development frameworks' to explain why. (I am using the term in a way inspired by a look at how Processing insulates users from Java.
Node classes, NodeProxy, Patterns, Crucial, etc all encapsulate approaches that can be thought of as different dialects within SC3. This is fatastically expressive, but confusing for beginners. In classes, I have experimented with writing little frameworks that introduce a specific library. These are essentially a set of buttons that autogenerate bits of code (Patterns friendly SynthDefs, for example) or GUI's (for NodeProxy) or lists of options of various sorts.
Anyway, such frameworks are inherently IDE-specific but are also distinct from Document. Perhaps Document (combined with the application menus) comprises a default development framework. Perhaps contextual menus would be a way to improve these frameworks and allow user-defined menu items 
without chaos in the basic UI.

Anyway, all of that might suggest keeping the IDE separate

RJK
PS: A sidebar: Document should probably grow some additional formatting methods. Copying and pasting from elsewhere, Documents can suddenly have different line sizes, etc. 



@bham.ac.uk>:
This is interesting, but it seems to me that there may well be IDE related stuff that doesn't really have anything to do with Document. An IDE class or 
something like that might be more appropriate in that case.


OK: for example the Cocoa help menu thing is IDE-specific, it only
runs on SC.app, and we don't really think of it as being a documenty
feature. But the very nature of Document is tied to the IDE - the
document is a feature of the IDE, and can't be separated from it -
which is why I wonder if a separate class would actually be
superfluous.

Grateful for further thoughts on this.
I think we need to sit down and have a detailed look at what functionality belongs to Platform, to IDEs, and what might be shared, and then come up with a strategy which creates the fewest foreseeable maintenance hassles. I 
think Ron suggested doing this at the Symposium?


Yes, and it will be good to talk about these at the symposium. But it
would be helpful to get something in place for 3.3, in particular to
get psycollider working nicely!
A related issue is the question of to what extent we can or should take 
every available Platform + IDE combination into account when making
development decisions. Currently we tend to think of SC.app, scel, and PsyCollider, and not really worry about anything else. That may be the pragmatic choice in the current context, but that may change as time goes 
on. Worth considering...


Agreed. Although most people don't even think about scel or psyco ;)

I'd like to see sc-eclipse become a nice option even for
non-eclipse-heads. That requires a good slimmed-down eclipse bundle,
but also good handling of Document functionality etc.

Dan



On 26 Dec 2008, at 13:06, Dan Stowell wrote:


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

Dan
--
http://www.mcld.co.uk

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



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





--
http://www.mcld.co.uk

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




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