Is your feature request related to a problem? Please describe.
For the next release I will create Ferdi in PortableApps format (Already done for Franz and I will do it for Ferdi too) and It will be very great If a switch could be added so the app will not rewriting by himself and maybe asking for admin write.
Describe the solution you'd like
Like adding a button/swith for desactivate update under accepting beta version so it is in the same area.
I just published 098c46e which _should_ implement this feature. Unfortunately, this is something I can't really test so we'll have to test it over the next updates.
@Makazzz From what I understand, the portable apps should not update at all, rather than have an option not-to-update, is that right? It should be possible to pass a special flag when building portable apps and then handle things differently in the app based on that build flag (instead of the usual update options, maybe a text that explains why in-app update is disabled and how-to update the portable app).
@kytwb normally when a portable apps is created we use a pre-created config file from the app (like settings/config.json) and change some value update: false so like that in the first run the user is not having an application that break himself by trying to update and/or asking admin right. OR we can block the update by renaming/changing some file so the app dosn't know where to find information about doing update. There is a few app that can be auto-updating without setup or admin right: JDownloader, Discord, etc... I will have to test if ferdi can be updated without a prompt for update or if Ferdi is pre-downloading the packaging in the Appdata folder (like Bitwarden do). And it is usual to desactivate the update option when bulding portableapps (with config file or a trick).
I see electron-builder support the portable target for Windows; we should give it a try and see how the auto-update behave then. Maybe something is already handled in the portable build regarding in-app updates?
@Makazzz you can find the portable version built by electron-builder in here (the executable without _Setup_ in the filename).
@kytwb thanks for this but I will use this .exe for extract the app-32.7z and portabilize without using temps files. And it is possible to create an environment variable like Bitwarden did (an electron app too writen in TypeScript) for helping the portableapps format to work? Because the launcher of portableapps can use environement variable for the user and use relative path for beign sure the data go to a folder choosen Like FerdiPortable/Data/Ferdi and the name of the variable could be FERDI_APPDATA_DIR.
Possible, on it 馃憤
Thank you
@vantezzen I guess if needed we can use PORTABLE_EXECUTABLE_DIR to define if it's a portable app and disable updates by default? Not sure if/how in-app works properly with portable apps.
Thanks a lot I will finish my repo of FerdiPortable and the build tomorrow. Thanks for your work.
@Makazzz Welcome!
@vantezzen In the doc they say we also have access to:
PORTABLE_EXECUTABLE_APP_FILENAME - sanitized app name to use in file paths.
Following the links on _paths_:
I want to toggle shortcut and startup, which will need dir and app name
Do we need to use PORTABLE_EXECUTABLE_APP_FILENAME somewhere for that purpose/to make things compatible with portable apps?
@kytwb @vantezzen I tested my Ferdi portable apps and with the FERDI_USERDATA_DIR variable and the config file for settings.json and proxy.json inside the config folder still stay in the appdata dir but all the rest of the data go to where I say so (so in a portable folder).
I used the Ferdi version of this commit ddb890d and this build
@Makazzz understood; I think I need to set app.setPath('appData', ...) instead of app.setPath('userData', ...). Will come up with a fix soon.
@Makazzz last commit should do the trick; please use FERDI_APPDATA_DIR instead of FERDI_USERDATA_DIR.
Thanks, I will wait to AppVeyor to increase your maximum storage and test the next builded Ferdi.
Alternatively, you could build the project locally on your Windows. You should get the .exe in the out folder as explained in the README. If you don't manage to, I will follow-up once AppVeyor has.
I will wait because at the moment I am not home but thanks for the info.
Finally I will wait because I have to many error (like cb() never called) with Node.js 10.16.3 and nothing work for building
@kytwb I have a problem... the FERDI_APPDATA_DIR don't do anything now and I don't know why.
@kytwb I have a problem... the FERDI_APPDATA_DIR don't do anything now and I don't know why.
@vantezzen Can you check about this please?
I think we need to roll back to using FERDI_USERDATA_DIR instead of FERDI_APPDATA_DIR. It looks like appData only gets used to generate the userData folder during dev builds.
I think we need to fix settings.json and proxy.json in another way. These are the only files that get updated through calls to the local API, so the problem needs to be in the way that the local API saves settings.
I'll look into this the next days or @kytwb may find the bug.
Ok thanks for the answer
It looks like appData only gets used to generate the userData folder during dev builds.
In our code yes, but I think it's also used by Electron's internals afterward.
What got me confused is:
the config file for settings.json and proxy.json inside the config folder still stay in the appdata dir but all the rest of the data go to where I say so
But the SETTINGS_PATH is set to:
export const SETTINGS_PATH = path.join(app.getPath('userData'), 'config');
So not sure how the settings.json inside the config folder was in the appdata dir instead of the set userdata dir.
Giving another try to FERDI_APPDATA_DIR with the next commit I'll push as I noticed userData wasn't explicitly set on that iteration (thought it would default on path.join(app.getPath('appData'), app.getName()) as per the doc, but might not be the case with a custom appData).
Still not working :/ . And now Ferdi is forcing me to have english has locale language.
What's happening now if you don't set FERDI_APPDATA_DIR? Does it fallback properly to PORTABLE_EXECUTABLE_DIR? If it's not working, I guess I'll revert the changes to FERDI_USERDATA_DIR and investigate why the two files you previously mentioned are not where they're expected to based on @vantezzen suggestion.
@kytwb If I remove the variable Ferdi just act like a normal install (use %AppData%)
@Makazzz roger that, I'll spend some more time checking over the weekend 馃檹
I found some source when doing research.
https://github.com/electron/electron/issues/1404#issuecomment-194391247
https://github.com/electron/electron/issues/2668
I don't know if it help.
@Makazzz Did you ever managed to build the project locally on your Windows? I'd be happy to pair with you to make it work, I think it would really help if we have a contributor that can test things that are Windows-specific to avoid back and forth as we experienced on this issue. WDYT?
I will push the snippet as it:
if (process.platform == "win32") {
app.setPath("appData", process.env.LOCALAPPDATA);
app.setPath("userData", path.join(process.env.LOCALAPPDATA, app.getName()));
}
But I don't understand why that would work and not the previous commits.
@kytwb I did not managed to make a working build but I want to do it and it will be really helpfull if we pair to make it work. And I was thinking to make an section in the wiki for windows build with steps etc.
@Makazzz awesome, let's do this! You can use this link to pick a date/time for our call!
@kytwb Sure but I am not so confident about doing a call/video but more feeling into text/messaging. And my english speaking is not the best (sorry in advance).
No worries, we can do what you're more comfortable with. Received your calendly invite, talk to you in the morning, signing off here!
PS: I speak French as well 馃槈
I think the last bit to be taken care of here is to disable in-app updates for Portable apps? Or is that not relevant anymore?
Normally vantezzen did it with this commit 098c46e.