A few basic issues concerning the replacement of SCApp by SCIDE #511
Comments
ghost
assigned 
|
assigning this issue to you. please implement your ideas and send a pull request |
|
Please do not assign issues to anyone which are explicitly not intended for assignment. This request for "enhancement" was a polite reminder (I do think so, at least) for future improvements, and it seems you have misunderstood why they are here. It is certainly not here to mitigate your great work so far. |
|
Tim, I see this enhancement request as a process of "requirements-gathering." Surely it is legitimate for users to note use cases that they do not themselves have the expertise to implement? One problem on the github tracker is that it's hard to distinguish issue priorities or expected time frames. These feature requests are not critical for ide 1.0 but they are worth considering. |
|
please use separate issues for separate features. the better and more precise these features are described, the more likely it is to be implemented. as stated more than once, we do not plan to re-implement scapp. things like the wiki mode will most likely die with the scapp. but if someone feels the need to have it in the ide, the way to go is to implement a prototype and send a pull request so that jakob and me can review the code. |
|
OK, I'll see if I can boil them down further - it'll be a lot of little issues then, I fear! The point of this entry is a different one. It is obviously not here to request a reimplementation of SCApp, but as a reminder about some of its important use cases that resulted from its simplicity and generality. SCIDE is currently very specialised on the standard expectations of code editing, and this issue tries to maintain the generality of what the IDE is intended to replace. I keep trying to understand the code, but I don't know QT and how to implement it. This is the downside I mentioned above. However, please do remember that you posit a replacement, not an addition, which is something fundamentally different. |
|
also, please consult the issue tracker for duplicates. e.g. #346 is a duplicate of your 4th point. |
|
I want to see both/all sides of the discussion. Certainly there seems to be some disconnect, where sc-ide is proposed to replace sc.app but without accounting for some of sc's use cases. At the same time, some use cases are "more equal than others" with apologies to Orwell and, by not prioritizing them, it may leave the impression that the ide needs to be all things to all people. My opinion is that the biggest loss in the ide is document manipulation from the language. ixilang is brilliant but it's dead without more document functionality than the ide supports today. Practical considerations aside: if future users of sc are not able to conceive of genius interfaces like ixilang because it's out of the editor's scope, it is a loss, and nothing can make it not a loss. It's troubling that the response had been dismissive so far. Admittedly it's a non-trivial requirement but the benefits are massive. Menu items would also be really nice to have. Wiki... meh. Not a peep on the lists about that in years. Either Document wiki functionality is so great that nobody has an problem with it, or (more likely) nobody is using it. Presentations... I still think it's better to lay out the presentation in HTML and load it in a web view instead of forcing the ide to take on yet another demand. Dunno if any of this adds light or just heat. |
|
On 18.09.2012, at 15:25, jamshark70 notifications@github.com wrote:
Yes, and it is a generic need without specification, as you don't know what will be done with it. Good to discuss these issues openly, yes! I guess many users and developers of scapp don't go into the pain of discussing these things here or even read the discussions. It is not necessarily a pleasant thing to do so, because there is so much room for (sometimes needless, sometimes necessary) conflict.
At least much existing code, typically of whole systems for third parties, depends on them.
I know at least three people who seem to use it all the time and who are intense users and developers of SC. But: once the IDE is a little better integrated and has rich text, we can simply implement it in sclang. I agree that this is a core issue.
Well, that you can already do with LaTeX, it is the model of static presentations. SCApp is just very useful to make presentations that are a little more open to modification - you can interact with them: show and modify sound examples, if someone has a suggestion, you just add it in, you can wikilink the pages, or even make a new one, drop weblinks on them, and so on. It actually could look much better, but it works really well. Even though a side effect of the programmability of SCApp, this wasn't possible with any other system I know of.
the former! |
|
On 18 Sep 2012, at 15:59, Julian Rohrhuber wrote:
Maybe we could just agree on the one hand, that saying a feature is desirable should not be understood as a demand that anyone in particular (Tim, Jakob, Julian, whoever) implement it, and on the other that it would be more helpful to discuss features on their merits, rather than lumping things under 'not reimplementing SC.app', which doesn't really add anything useful to the discussion. I'm sure everyone is aware that there's a balance that must be met between meeting the community's needs and desires, and people's limited time and varied priorities and skill sets. Some things may never be implemented because of the latter, but that doesn't mean they're not worth raising, and raising them should not be understood as taking anything away from the amazing work that has already been done on the IDE. I think everyone agrees that it is a very good thing indeed, and that Tim and Jakob should be commended for taking the lead in this. Fair enough? S. |
Asside from the contents of this discussion, I just think that GitHub issues are not the best format for such extensive and (relatively) vague proposals. I suggest that we create a wiki page for writing down a collective vision of SC IDE that we desire - a list of features, and what's implemented and what not + comments... Actually this could also serve to present the complete architecture of the IDE as of this moment - useful for anyone that wants to get into development. Than the new features could be inserted into this architectural scheme at appropriate places. |
|
On 18.09.2012, at 20:08, Jakob Leben notifications@github.com wrote:
Yes, this is a good idea - It may really help to understand both how it is implemented and how we envision its future. |
This presupposes that the SuperCollider wiki at sourceforge is repaired, or another location is found. (Or, use the old wiki.) I haven't been able to edit pages at the sourceforge wiki in probably more than a year. |
|
what about using the github wiki? |
|
2012/9/19 jamshark70 notifications@github.com
I'm sorry. I tried once to fix it, got nowhere. Partly the problem is spam Github wiki is fine by me, would be nice if possible to migrate the old
|
|
On 19.09.2012, at 10:26, jamshark70 notifications@github.com wrote:
The old wiki should work fine. Password and user is the most obvious abbreviation. |
|
closing as this is not a bug and this discussion should go to a wiki |
|
On 20.09.2012, at 09:53, Tim Blechmann notifications@github.com wrote:
Just for reference: I suppose that not all issues are bugs - this was labeled an "enhancement". Would you personally prefer feature proposals to go elsewhere? Then the label "enhancement" should be removed. |
|
On 20.09.2012, at 09:53, Tim Blechmann notifications@github.com wrote:
One more thing: if you want to use the github wiki for discussing this instead, please post a link here first. |
|
My interpretation is that Tim is using the issue list as a list of things that need to be ticked off and closed, because he wants to tick off all pertinent issues before the next release. All open issues must be fixed and closed, or notfixed and closed. That's a good way to manage a large to-do list over which you don't have complete control, so it's very understandable, and it's a motivation for closing this item. However, I agree that "Closed as this is not a bug" is not a very constructive reply, since (a) the issue tracker is not just about bugs and (b) the reply has a dismissive tone. We should discuss on-list where to go with the wiki and then move the discussion there, since Julian's original post would work well as a wiki page. |
|
#513 for example is a well written enhancement request. |
In that case, I think it would be useful to have a "postponed" status (perhaps a milestone?) for issues that are valid and relevant but which are not going to be implemented in this release. Valid issues should not be closed-and-notfixed. (I'm not including this issue, as there already seems to be consensus to move the discussion of future requirements elsewhere.) In fairness to Tim and Jakob, who are working their butts off to give us an excellent new tool: the funding from Cyberpipe is not unlimited and will end after a period of time. It's reasonable to draw the line somewhere -- that is, take the position, "Given the amount and duration of funding, we can take the IDE so far but not much further." At least, if I were in their position and receiving feature requests that would significantly extend the scope of the project beyond what is realistic to do within those constraints, I would be tempted to say things like "We are not going to reimplement sc.app" and to summarily close issues. Unfortunately, this is coming across as if it's a bit callous toward users' needs, but I don't think that's the best explanation. Realistically, some much-desired features are going to be implemented only if some developers other than Tim and Jakob roll up their sleeves and muck about in c++/qt. That's not quite as frightening as it might sound. I've only looked at a little bit of the editor code, and it's generally clean and readable. I don't think it would take huge amounts of written documentation on their part to make it approachable. |
|
there are issues, which are open forever (e.g. #52) but won't be fixed as nobody is working on them. this ticket is different, because it is not a single enhancement request, but mentions a number of points, of which some are duplicates, some are simply buzzwords or possible use cases, but without suggesting a solution. btw, if we'd limited the development of the ide to the funding from kiberpipa, we would have already stopped the development and would reject every bug report or enhancement request. that was also the reason why i mentioned that the best way to suggest a feature is to implement a prototype. qt is using an easy to use subset of c++ and we are constantly refactoring the code in order to make it readable by people who want to contribute. |
A while ago, I had posted those issues on the mailing list. Some of this may have been solved already in the meantime, or postponed because of a lack of time. Lest they get lost, I add them here as an issue with slight modifications - certainly not one that can easily be closed, but just as a reference.
All of the below are types of use cases of SCApp which may need consideration if by a replacement of it with SCIDE, I would find it a shame if they get silently pushed to the side.
Currently (i.e. in scapp), the position within a document of a piece of source code can be derived. While not always reliable, this is used to trace back from objects to source code. Also, cursor position and window properties are known in sclang, and can be interactively controlled from sclang. The text window is simply a GUI element, as a "user" of a subsystem of sc is often writing code to interact with it (see 3 and 4).
SuperCollider is often used as a way to get around PowerPoint or similar applications. Also, the a wiki system implemented in Document is combined with presentation or just used as documentation. I don't think this is a misuse or anything like it, but part and parcel of the literate programming approach. This is mainly about minimalism in the interface actually (and the notorious rich text).
Often, Document is treated like any other GUI element, both for display and for editing. It is used as a small editor window that opens when more complex parameters need to be edited. Also, it is used as a way to dynamically rewrite code from sclang [1].
Currently, Document and CocoaMenuItem provide a simple interface to use the SuperCollider language itself to modify (just in a very basic way) how the application looks. Standalones can thus provide a modified text interface. One can change the language interface with the same language. [2]
[1] E.g. in applications like ixilang (http://www.youtube.com/watch?v=nmqEciI_O4U) or code art like Fredrik's work. I built an editor where you can click on numbers in the code of a running synth and change them by moving the cursor up and down.
What is a bit strange now with scide that the GUI opens in another application again (so we have three now); Perhaps you should just use two sclang instances communication? I don't know...
[2] As a side remark: mainstream conventions aside, IDEs have very different ways to do this, think of the languages that inspired SC, such as Smalltalk (or Squeak, for that matter, http://squeakbyexample.org//SBE.pdf), where you always save all current state in one block, or Racket (formerly Dr. Scheme http://docs.racket-lang.org/quick/index.html), displaying images and code together, or emacs for lisp, where you use the same language to configure your editor. But we may not need anything that fancy at all.
The text was updated successfully, but these errors were encountered: