feat: app.moveToApplicationsFolder conflict handling (#18916)
Resolves #18805. We want to keep default move conflict handling behavior in that it's still what most users would expect, but there exist edge cases in which users may not want to be forced into that behavior. This thus introduces an optional conflict handler that allows developers access to more granular move actions. They could now allow the user to choose whether to delete an existing app in favor of the current one being moved, or whether to quit the current app and focus on the existing one should it both exist and be running. I added a fair amount of new documentation outlining this behavior, but if there are things users may benefit from seeing examples of or nuances that should be added please leave feedback!
This commit is contained in:
parent
0db6789210
commit
f6a29707b6
4 changed files with 86 additions and 9 deletions
|
@ -11,6 +11,9 @@
|
|||
|
||||
namespace electron {
|
||||
|
||||
// Possible bundle movement conflicts
|
||||
enum class BundlerMoverConflictType { EXISTS, EXISTS_AND_RUNNING };
|
||||
|
||||
namespace ui {
|
||||
|
||||
namespace cocoa {
|
||||
|
@ -21,6 +24,8 @@ class AtomBundleMover {
|
|||
static bool IsCurrentAppInApplicationsFolder();
|
||||
|
||||
private:
|
||||
static bool ShouldContinueMove(BundlerMoverConflictType type,
|
||||
mate::Arguments* args);
|
||||
static bool IsInApplicationsFolder(NSString* bundlePath);
|
||||
static NSString* ContainingDiskImageDevice(NSString* bundlePath);
|
||||
static void Relaunch(NSString* destinationPath);
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue