New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SuperCollider Projects #311

Open
miguel-negrao opened this Issue May 7, 2012 · 8 comments

Comments

Projects
None yet
3 participants
@miguel-negrao
Member

miguel-negrao commented May 7, 2012

A project is a folder containing:

  1. All the sclang code and classes for that project.
  2. A language config yaml file with ".scproj" extension.
  3. Quarks in a "downloaded-quarks" folder.
  4. Possibly a startup file ?

I think this would require:

  1. Relative paths in the lang file are resolved relative to the location of the lang file. Possibly tags could be used to allow resolving to other paths such as %user_app_library%, etc.
  2. Quarks install to the "downloaded-quarks" folder in the project folder. Paths are added relative to the project folder ("downloaded-quarks/rd_dot").
  3. The ide could be in non-project mode or in project mode. This isindicated visually in the title like : "myNiceProject.scproj: session name: file1.scd (dir1/dir2) - SuperCollider IDE"
    1. New ide-menu options: File->open project File->close project, File->new and File->save as. Closing a project would return to non-project mode.
    2. default search paths can be disabled in the lang file ("disableDefaultPaths: true"). This takes the place of current -a switch of sclang.
  4. Regarding SCCLassLibrary, it is tied with the sclang build. For OSX, users could also keep a version of SC around that worked with that project (since SCClassLibrary is inside the app bundle). For linux, users would take note of the commit of sc used for that project and if needed rebuild sc when going back to that project if needed, or take note of the package version used if sc was installed from a package manager. It is also possible to make an "scide" binary pick up an "sclang" binary archived in the project folder by prepending the project folder to the PATH env variable before running program, although this is a bit hacky. A new IDE config option could be added to select the sclang binary. Using an scsynth/supernova archived in the project folder is possible since a new primitive is available which returns the parent folder of the lang file.
  5. Disabling the default startup file and then either:
    1. have a startup file in the project folder with a default filename (e.g. startup.scd).
    2. use a class method to call Startup.add, have this class be part of the project.
    3. Being able to chose the startup file in the project (relative path to the project root again).

[edit] to clarify, in non-project mode, the ide and sclang would behave exactly the same as now, so this would be orthogonal to the current state.

@miguel-negrao miguel-negrao added this to the 3.8 milestone Mar 29, 2015

@miguel-negrao

This comment has been minimized.

Show comment
Hide comment
@miguel-negrao

miguel-negrao Mar 29, 2015

Member

With the new Quaks system we are basically there already with the exception of the startup file. If the startup file could be overridden from the language config, I think this would become a reality. Just save a language config yaml for each project and change it in the interpreter options.

Also, for the custom sc class library path we would need a language config option for disabling the default path.

Member

miguel-negrao commented Mar 29, 2015

With the new Quaks system we are basically there already with the exception of the startup file. If the startup file could be overridden from the language config, I think this would become a reality. Just save a language config yaml for each project and change it in the interpreter options.

Also, for the custom sc class library path we would need a language config option for disabling the default path.

@miguel-negrao

This comment has been minimized.

Show comment
Hide comment
@miguel-negrao

miguel-negrao Apr 16, 2015

Member

Actually, this is pretty much already possible by having an empty startup.scd and having a file with a class like below for each project on a different folder and including that folder in the lang config file for the project:

StartUpForProject1 {

    *initClass {

        StartUp.defer{
               ...
                }
        }
}

Works very nice !

The option of being able to set the startup file would still be worth it to have, though.

Member

miguel-negrao commented Apr 16, 2015

Actually, this is pretty much already possible by having an empty startup.scd and having a file with a class like below for each project on a different folder and including that folder in the lang config file for the project:

StartUpForProject1 {

    *initClass {

        StartUp.defer{
               ...
                }
        }
}

Works very nice !

The option of being able to set the startup file would still be worth it to have, though.

@miguel-negrao

This comment has been minimized.

Show comment
Hide comment
@miguel-negrao

miguel-negrao Feb 15, 2016

Member

I would like to revive this feature. Thinking about the recent standalone discussion, actually for myself, and probably more people, what I really want is not to distribute an application to other people (hard to do in linux anyway), but to keep a perfect working copy of a project that will "always" work in the future. I think of this similarly to xcode and qtcreator projects.

So a project would be a folder containing:

  1. all the sclang code and classes for that project.
  2. quarks
  3. any other libraries you need
  4. language config yaml file
  5. possibly a startup file ?

I think this would require:

  1. lang file is saved in the project folder with .scproj extension.
  2. relative paths in the lang file are resolved relative to the location of the lang file.
  3. Quarks install to "downloaded-quarks" folder in the project folder. Paths are added relative to the project folder.
  4. The ide could be in non-project mode or in project mode. This isindicated visually in the title like : "myNiceProject.scproj: session name: file1.scd (dir1/dir2) - SuperCollider IDE"
    1. New ide-menu options: File->open project File->close project. Closing a project would return to non-project mode.
    2. default paths can be disabled in the lang file ("disableDefaultPaths: true")
  5. Regarding SCCLassLibrary, it is tied with the sclang build, so I guess the default system SCClassLibrary would still be used. For OSX, users could also keep a version of SC around that worked with that project (since SCClassLibrary is inside the app bundle). For linux, users would take note of the commit of sc used for that project and if needed rebuild sc when going back to that project if needed, or take note of the package version used if sc was installed from a package manager.
  6. Disabling the default startup file and then either:
    1. have a startup file in the project folder with a default filename (e.g. startup.scd).
    2. use a class method to call Startup.add, have this class be part of the project.
    3. Being able to chose the startup file in the project (relative path to the project root again). (Option 0 seems the simplest).

[edit] to clarify, in non-project mode, the ide and sclang would behave exactly the same as now, so this would be orthogonal to the current state.

I would like to get feedback on this proposal.

Member

miguel-negrao commented Feb 15, 2016

I would like to revive this feature. Thinking about the recent standalone discussion, actually for myself, and probably more people, what I really want is not to distribute an application to other people (hard to do in linux anyway), but to keep a perfect working copy of a project that will "always" work in the future. I think of this similarly to xcode and qtcreator projects.

So a project would be a folder containing:

  1. all the sclang code and classes for that project.
  2. quarks
  3. any other libraries you need
  4. language config yaml file
  5. possibly a startup file ?

I think this would require:

  1. lang file is saved in the project folder with .scproj extension.
  2. relative paths in the lang file are resolved relative to the location of the lang file.
  3. Quarks install to "downloaded-quarks" folder in the project folder. Paths are added relative to the project folder.
  4. The ide could be in non-project mode or in project mode. This isindicated visually in the title like : "myNiceProject.scproj: session name: file1.scd (dir1/dir2) - SuperCollider IDE"
    1. New ide-menu options: File->open project File->close project. Closing a project would return to non-project mode.
    2. default paths can be disabled in the lang file ("disableDefaultPaths: true")
  5. Regarding SCCLassLibrary, it is tied with the sclang build, so I guess the default system SCClassLibrary would still be used. For OSX, users could also keep a version of SC around that worked with that project (since SCClassLibrary is inside the app bundle). For linux, users would take note of the commit of sc used for that project and if needed rebuild sc when going back to that project if needed, or take note of the package version used if sc was installed from a package manager.
  6. Disabling the default startup file and then either:
    1. have a startup file in the project folder with a default filename (e.g. startup.scd).
    2. use a class method to call Startup.add, have this class be part of the project.
    3. Being able to chose the startup file in the project (relative path to the project root again). (Option 0 seems the simplest).

[edit] to clarify, in non-project mode, the ide and sclang would behave exactly the same as now, so this would be orthogonal to the current state.

I would like to get feedback on this proposal.

@crucialfelix

This comment has been minimized.

Show comment
Hide comment
@crucialfelix

crucialfelix Feb 16, 2016

Member

The goal is good. I only glanced at this a bit (for now, quite busy)

general principles: Try to make sure that it isn't tied to the IDE and that its nice and portable. Keep state and settings where people can see them, understand them and fix them.

Member

crucialfelix commented Feb 16, 2016

The goal is good. I only glanced at this a bit (for now, quite busy)

general principles: Try to make sure that it isn't tied to the IDE and that its nice and portable. Keep state and settings where people can see them, understand them and fix them.

@miguel-negrao

This comment has been minimized.

Show comment
Hide comment
@miguel-negrao

miguel-negrao Feb 16, 2016

Member

In order to keep this separated from sc-ide, most of the functionality could be in sclang such that a project could opened in sclang like

sclang -p /path/to/project/root

And it would run the default startup file. Some ide related settings would still be part of a project spec, but would be ignored by sclang.

Member

miguel-negrao commented Feb 16, 2016

In order to keep this separated from sc-ide, most of the functionality could be in sclang such that a project could opened in sclang like

sclang -p /path/to/project/root

And it would run the default startup file. Some ide related settings would still be part of a project spec, but would be ignored by sclang.

@muellmusik

This comment has been minimized.

Show comment
Hide comment
@muellmusik

muellmusik Aug 30, 2018

Contributor

@miguel-negrao is this issue still live, and are you still pursuing it?

Contributor

muellmusik commented Aug 30, 2018

@miguel-negrao is this issue still live, and are you still pursuing it?

@miguel-negrao

This comment has been minimized.

Show comment
Hide comment
@miguel-negrao

miguel-negrao Sep 1, 2018

Member

@muellmusik Yes. Pull-request #3278 is awaiting for #3733 to be merged. After that is done I have to refactor it and then have another review. I will possibly be quite busy in the next 5 months, might only have to work on this again after February.

Member

miguel-negrao commented Sep 1, 2018

@muellmusik Yes. Pull-request #3278 is awaiting for #3733 to be merged. After that is done I have to refactor it and then have another review. I will possibly be quite busy in the next 5 months, might only have to work on this again after February.

@muellmusik

This comment has been minimized.

Show comment
Hide comment
@muellmusik

muellmusik Sep 1, 2018

Contributor

Okay, great!

Contributor

muellmusik commented Sep 1, 2018

Okay, great!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment