Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Refactor Document #2718

Closed
wants to merge 5 commits into from
Closed

Refactor Document #2718

Changes from 1 commit
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
8a6a7f0
Migrate document class out of ScIDE.sc
Feb 18, 2017
b89a6cf
Document.sc: add a linkedIDE member with description and TODOs
Feb 18, 2017
bdeb6b6
Document.sc: repl refs to ScIDE class w linkedIDE
Feb 18, 2017
22aa27b
Document.sc: add list of funcs that ref ScIDE
Feb 18, 2017
01f0949
Add empty IDE.sc file
Feb 25, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
27 changes: 27 additions & 0 deletions SCClassLibrary/Common/Core/Document.sc
View file
Open in desktop
Expand Up @@ -3,6 +3,33 @@ Document {
classvar <globalKeyDownAction, <globalKeyUpAction, <>initAction;
classvar <>autoRun = true;
classvar <asyncActions;

classvar <linkedIDE;
/* the IDE that will instantiate documents. It is that IDE's responsibility to implement
methods that may be invoked on it from the Document class:
getQUuid
newDocument
setCurrentDocumentByQUuid
open
close
setDocumentKeyDownEnabled
setDocumentKeyUpEnabled
setDocumentMouseDownEnabled
setDocumentMouseUpEnabled
setDocumentTextChangedEnabled
setDocumentGlobalKeyDownEnabled
setDocumentGlobalKeyUpEnabled
setDocumentTitle
setSelectionByQUuid
setEditablebyQUuid
setPromptsToSavebyQUuid
removeDocUndoByQUuid

TODO: Add code to actually link `linkedIDE`
TODO: Replace all references to ScIDE with linkedIDE
*/

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should there be a superclass for IDEs which settles an IDE-independent API? It would be good to be able to still open a document programmatically.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I'd be totally open to that! Am I correct that in thinking that the advantage there is leaving the possibility open for alternate editors to link into that functionality, at the slight cost of additional work for this PR? I suppose Document should not really be in charge of choosing its linked IDE...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, it would make it easier for developers of editors to know what is expected. Some things that are now in Document, esp. allDocuments and currentDocument are really quite important for the minimal set of programmatic functionality and should be required.

I am not completely sure if it might be better to keep the above two methods in Document, but I see your point.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great! Yeah, I see now how I've already implied that architecture by leaving a comment about "IDEs should implement these methods"—it plainly calls for a "subclass responsibility" stub.


var <quuid, <title, <isEdited = false, <path;
var <keyDownAction, <keyUpAction, <mouseUpAction, <mouseDownAction;
var <>toFrontAction, <>endFrontAction, <>onClose, <textChangedAction;
Expand Down