-
Notifications
You must be signed in to change notification settings - Fork 7.6k
Conversation
Extension can also be disabled using `"disable": true` in the package.json. Details: - Rename getPackageJson to getMetadata. - Check for presence of .disabled file in the extension directory and add it to the metadata. - Do not load extension if it is disabled instead, reject with disabled status. - Add DISABLED extension state. - Extension is still gets on record and is enumerated with all its metadata, but it's not started.
3d92fdb
to
9784ba2
Compare
9784ba2
to
c8af09f
Compare
CC: @albertinad, you made me do it. now you have to review it. :) |
"MARKED_FOR_REMOVAL" : "Marked for removal", | ||
"UNDO_REMOVE" : "Undo", | ||
"MARKED_FOR_UPDATE" : "Marked for update", | ||
"UNDO_UPDATE" : "Undo", | ||
"MARKED_FOR_DISABLING" : "Marked for disabling", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not keen on this phrase. Perhaps Marked as disabled
would be more appropriate. It doesn't have to follow the semantics of removal and update.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't like it either, so we could probably come with something better. Marked as disabled
is not good because it implies a completed action. Marked to be disabled
, perhaps?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well it does. Since it is not disabled until the dialog closes, so is not true that it is "Marked as disabled".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are thinking that the user knows of the implementation. According to the UI, I hit the disable
button and now it is Marked as Disabled. This is further backed by the fact that there is an undo
link... meaning I am undoing the action of marking as disabled. The user has no idea (or should they) when the actual file gets written to disk.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@TomMalbran is right. User has to be aware anyways: after extension manager is dismissed, there will be a dialog asking for confirmation and if canceled all extensions marked will be unmarked (and left intact).
So what about Marked to be disabled
vs Marked for disabling
? With all the context, do we need to change it in the first place?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Neither one is English, so it doesn't matter.
You are focusing too much on the disabled
part. The action you are taking in the UI is marking
and once you click on disable
it is marked
.
... but choose whatever you want.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The label appears when the action of marking has been taken, so marked
is totally appropriate. OK, I will leave it as is for now.
Good stuff. As I mentioned on Slack, I think the Unless I am missing something, or maybe behaviour is different on Linux (Ubuntu 14.04 x64 here), but I don't see how you can enable a disabled extension. I was expecting an |
This sounds as a bug. Checked, it should be |
My disabled extensions show up in the list, but the buttons all say |
@mackenza, fixed it (slightly blushing). |
ExtensionLoader.loadExtension(FileUtils.getBaseName(path), { baseUrl: path }, "main") | ||
.done(result.resolve) | ||
.fail(result.reject); | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You forgot to return the promise
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you! Fixed.
You need to unmark all extensions that were marked to be disabled after this line (https://github.com/adobe/brackets/blob/kai/disable-enable-extensions/src/extensibility/ExtensionManagerDialog.js#L209). |
}) | ||
.fail(function (errorArray) { | ||
dlg.close(); | ||
ExtensionManager.cleanupUpdates(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't you still need line after if (removeErrors) {
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, I don't think so. Updates are done always (in parallel) with this change independently of how it went for removes. The only place it needs to be done is when the entire confirmation is cancelled.
question: will this work for default extensions? if so, can we add |
@zaggino, it will work on default extensions via manually creating and deleting @TomMalbran, thanks for the thorough review will fix these. |
removeExtensionsPromise = ExtensionManager.removeMarkedExtensions(); | ||
removeExtensionsPromise | ||
.fail(function (errorArray) { | ||
removeErrors = errorArray; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that the code might look better if you parsed the error array here and created the dialog, instead of doing it in the general fail.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's no need to create dialogs
at this scope. The error condition is processed in the .fail
of the consolidated promise (Async.waitForAll
).
@busykai great, can you add an |
@zaggino, you're right. Will add this file to |
It could be used to disable default extensions and must never be committed.
Async.waitForAll would not fail, unless failOnReject argument is true.
Did some more testing, focused on error handling. Seems to be fine now. |
@@ -34,3 +34,6 @@ Thumbs.db | |||
|
|||
# Files that can be automatically downloaded that we don't want to ship with our builds | |||
/src/extensibility/node/node_modules/request/tests/ | |||
|
|||
# .disabled should be ignored, it could be used to disable default extensions | |||
.disabled |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be more specific: src/extensions/default/*/.disabled
We may also use this file in unit tests for this feature, and in this case it should be included.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's an overkill. It clearly says default extensions there's nothing to misunderstand.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In installer builds, "src" is "www". Don't you want to handle both? (referring to line above, not this one)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why would we need a .gitignore
in installer builds? It's not like the www
is a git repo...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@marcelgerber, actually I misunderstood you, you were saying the rule itself should be more specific and I understood you were referring to the comment text. Will fix this.
@rroshan1 that works too! We shouldn't be getting more buttons in that area (fingers crossed) so let's go with that 👍 |
@rroshan1, simplicity is the best! :) I should have thought about this layout!.. |
I like the first one better. The second one seems a bit out of proportion to me. |
@busykai I think the first one looks better. The second one seems so cluttered. |
OK. FWIW, the second one is what close to what we used to have (buttons are close to each other). |
Added margin of 3px to any extension action button (more spread buttons).
398df58
to
03b1e44
Compare
@rroshan1, ready for re-review. did not address separate functions comment though. let me know if you feel it has to be addressed. |
@busykai agreed 1st screenshot is much better than 2. Even if 2 is what we have now. side note: why is |
@mackenza, it's in EDIT: I've pushed the first version, so more spacious design with this change. |
@busykai great, first screenshot is better but could we shave off 2px to the spacing between Disable and Remove buttons? |
@larz0, like this? |
Remove right margin entirely.
@busykai looks good here 👍 |
Thanks @busykai .. 👍 |
@rroshan1, now fully compliant to the comments. |
Thanks @busykai.. |
This PR provides a simple mechanism to disable and enable again an extension and complete support of the functionality in the Extension Manager.
Extension loader looks for
.disabled
file in the extension directory, if it's present the information is included and propagated to the entire extensibility subsystem. Extension Manager can disable and enable extensions using the same mechanism.