[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 Ron -

I'm not clear on what these frameworks are. What is it about them,
that makes them "inherently IDE-specific"? If they're "buttons that
autogenerate bits of code" then they can simply use the GUI
abstraction for the buttons, and the Document abstraction to present
the generated code to the user.

Dan


2008/12/27 ronald kuivila <rkuivila@xxxxxxxxxxxx>:
> 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/
>



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