Portable/Non-Admin Version
Anachron opened this issue · 27 comments
I liked AppJS because it was possible to use it on PC without admin rights. Is it possible to make the shell integration optional and allow the executable to open a program by dragging the desk file into?
You could create a separate script to install/uninstall filetype associations.
I like the idea to be able to run on a PC without admin rights.
I actually already install into %LOCALAPPDATA% (C:\Users\AppData\Local\Deskshell-apps) so that admin rights are not required to install or update. The things that require admin rights in the current installer are creating the start menu folder / program links and then the file associations.
I have made changes to the current runtime installer and removed the admin rights from it. Can you uninstall all versions of deskshell that you have and then try installing: http://deskshell.org/downloads/Deskshell-Runtime-install-noadmin.exe and see if that works on your machine. I have tested on windows 8 and it appeared to work for me, even creating the file associations, but no start menu options.
If you are willing to test then we can try to come up with an installer for none admin rights PCs. A separate problem would be a "portable" version of deskshell. I also like this idea. One solution to that may be to use the exe compiler. When doing that it currently looks for deskshell installation on the machine and asks for permission to download and run it if missing. Maybe I could add in an additional test to check if deskshell is available in a nearby directory and if it is then it could launch from that relative directory enabling running from usb stick for example. Let me know if the above installer worked and I can think some more about a portable installer.
p.s. I just tested and drag and drop of a .desk file onto the deskshell executable will launch it.
First of, thanks for your quick answer!
About the Non-Admin-Installer: It worked! It's installed to C:\Users%USER%\AppData\Local\Deskshell
Could you rather install it into the currenct folder & make it portable like that? (Use relative file paths).
I have now updated the "Runtime" installer to use a none-admin setup by default. The Runtime installer will still create file associations since it will always end up in the same end location.
I have created an experimental portable installer and run it to create an example portable setup. You can download this from: http://deskshell.org/downloads/portable-test.zip What this does is have a folder called "deskshell" with a portable installation in it. Then it has an example application "portable-hello-world" which is packaged as a windows exe. The exe will look in a number of different locations (..\deskshell\deskshell.exe) and then launch itself using the deskshell application. The simple source code for the application is in the "src/" directory.
It would be possible to rename the deskshell folder to "my-app" and then replace the "sys-apps/demo-docs" application with your application. This would encompass everything under a single folder. However since deskshell includes chromium and that is relatively heavy (60 Meg+) this would mean 10 example apps would take up 600 Meg+. Therefore a setup like in this example where you can have a number of different apps that all share the same runtime is ideal.
If the exe does not find a portable deskshell or any deskshell runtime then it will ask the user if they want to install the runtime.
I like the idea of portable applications so I will include this new portable edition in the main deskshell project. We will need to test and find all the things that need to be fixed, for example currently the updater will download and install the runtime rather than updating the portable deskshell install, however we can work through these issues and fix them all.
Thanks for the suggestion and ideas. Let me know if it works for you.
Awesome, I will test it later and let you know!
Thank you so much for taking over the project, I loved AppJS but I didn't use it because of the lack of development / response.
Well about 25 installs later I have now released an "official" portable edition of deskshell. If you go to the homepage http://deskshell.org/ and click on windows portable you get a zip download with everything including a very basic hello world app. I have worked with the updater so if you run it or if deskshell detects an update it is able to update the portable installation. I have fixed all of the issues that I discovered.
I am closing this issue since the functionality is developed and released now but create new issues if you find any problems.
Thumbs up for your work!
I tested it out at private & work PC, couldn't find any problems so far.
This really is ground breaking, now we need to spread the word.
Great good to know it is working. Deskshell being built in javascript has lead to an order of magnitude faster development and it is starting to get really slick and usable now :-) Thanks for your input!
Oh one more thing, the executeable of the portable app won't work if you move Deskshell.
But I guess there is no way to make it work? The .desk file works (I used "Coffee" as association creater, it will open any files by that extension with an exe-file I provide)
The portable-hello-world.desk does not create any problems.
If you open portable-hello-world/src/app.nsi then that is the source code for the exe launcher, it is unique for each application. If you want to move deskshell somewhere else then you can edit the source code to change where it looks. Currently it looks:
- ../deskshell\deskshell.exe
- ../../deskshell\deskshell.exe
- $DeskshellInstall
I commented out the associations for the portable edition, obviously the exe does not need them but developing using .desk files or launching the package files (.appfs) would need them. However I am assuming then the user is a developer and can install deskshell or the runtime on their machine.
We could include a .reg file for creating the associations but I am not sure if that is a great idea (if you then remove the usb stick or similar) so currently I am leaning towards you needing to install runtime or sdk if you want to have file associations. It would be possible to include a little exe (100k) that is able to download and install the runtime (basically the current updater). At the moment the solution is the best I can come up with but maybe if we play around and experiment more we can come up with an even better layout / setup.
I was thinking about two things:
- Create a little environment variable providing an optional path to set (relative) as launcher.
- Optionally read environment variable (DESKSHELL_INSTALL) or something like that
Storing things in the registry is always bad for a portable app (imho).
Yes we could use environment variables, but at the same time if it is going to point to a portable location then you will still get the same problem: if you remove the location / disk you then leave a broken setup where the link no longer works.
I kind of copied chrome and just installed directly to a known location for the SDK and runtime so finding the install location is not time consuming or difficult. I think this addition of the ability to have a relative location is also very good, if running from a portable device then you can "install" there and then place your applications relative to it.
Again we could include the runtime directly as part of the application but I have checked the space on disk and it is actually 125 meg so is a little heavy to do that for small apps.
Woops, actually I was not talking about environment variables in the first idea.
What I meant is a little config-file inside the portable-app that is called "environment.config" or something like that which can have a value for things like paths, debug settings and such stuff.
Yes we could do that. We already have a json file that is read: app.desk. The exe could check for a json property "deskshellPath" or something similar and use that if it is set. What do you think about that solution?
I didn't found out about "app.desk" being a JSON-File yet. That's smart. (I just started to play around with what you already created) Would totally love to have that option! Should be good to go.
Ok slight change of plan during implementation. I have just packaged the portable application with no runtime:-
http://deskshell.org/downloads/portable-hello-world.zip
What the exe now does is it looks for a file in the same directory that it is run from called "app.ini" this is not yet a real .ini file but should instead contain the full or relative path to deskshell. It should all be on one line, if it finds that ini file then it will launch the location in the file.
To test this I was able to point it at deskshell_debug.exe and then it opened the console debug window and launched the application. I just added this as the highest priority place to look so it will fallback to the previous locations.
It maybe requires a little more work and cleanup but it does let you specify any location that you want to run deskshell from. A thought I just had was that it could ask you to select the deskshell exe if it was not found, maybe that is another solution, once you select deskshell it can then save the .ini file for you.
Good idea, but it should always do that if
- The file (app.ini) does not exist or
- The path to DeskShell is not valid (overwrite ini)
Else you end up moving you DeskShell and it wont ask for the correct directory and it would be single-use only.
Well at the moment if it does not find deskshell then it asks the user if they want to download and install it, the app developer decides if they want to install as a portable app or install the runtime. I just thought that it could ask you if you want to download it or if you want to select its location using a file picker.
Oh okay, that's even better!
Did you update the download yet?
So I can try it out.
I have not done the file picker change. I am working on adding a native file picker for deskshell so once that is done I can re-use the code, but the zip I linked to includes everything but the file picker.
Perhaps the project should follow the portable apps specifications
http://portableapps.com/development/portableapps.com_format
On Tue, Nov 12, 2013 at 8:46 AM, sihorton notifications@github.com wrote:
I have not done the file picker change. I am working on adding a native
file picker for deskshell so once that is done I can re-use the code, but
the zip I linked to includes everything but the file picker.—
Reply to this email directly or view it on GitHubhttps://github.com//issues/24#issuecomment-28247921
.
Mr Sholto Maud
M.Eng. (Sys Eng)
P.Grad. Dip. (Phil)
Adv. Dip. (Comp Sci)
Bach.Arts. (Env. Sci)
Thats a good idea - I had not thought of that. Perhaps the portable edition should be re-arranged to line up with the portable apps format. I am already using NSIS which is the installer that they use so that might be a good idea. I guess it would also make the project visible to more users.
I can re-open the issue so I remember to re-package along portableapps.com_format.
Any other great ideas?
I have created the portableapps_com layout as stated in their standard. This breaks everything since the current code assumes certain relationships between the various pieces. I will have to refactor the current implementation step by step to remove these dependancies and to read in the expected layout from the deskshell-env.js file. I already have moved a lot of the path logic into this file but the portableapps_com layout requires more changes.
I think it is a good move, and improves the quality of the code as it will allow it to operate with multiple file layout and structures. I do not know when the refactor will be complete, I will need to take it step by step and make sure I don't break any of the existing code. For now the existing portable edition of deskshell can be used and tested to find if it breaks anything.
FYI, the Mac OS version is already portable - it just needs updates for now. But it’s portable. :)
Am 12.11.2013 um 15:50 schrieb sihorton notifications@github.com:
I have created the portableapps_com layout as stated in their standard. This breaks everything since the current code assumes certain relationships between the various pieces. I will have to refactor the current implementation step by step to remove these dependancies and to read in the expected layout from the deskshell-env.js file. I already have moved a lot of the path logic into this file but the portableapps_com layout requires more changes.
I think it is a good move, and improves the quality of the code as it will allow it to operate with multiple file layout and structures. I do not know when the refactor will be complete, I will need to take it step by step and make sure I don't break any of the existing code. For now the existing portable edition of deskshell can be used and tested to find if it breaks anything.
—
Reply to this email directly or view it on GitHub.
You will be happy to know that I have now created a portableapps_com edition of deskshell now available for download. I have worked through most of the problems that came up and hopefully it will work for you. I noticed the application icon is missing in the launcher but that is the only known issue at this time.
Please download and test out the new edition of deskshell and report any problems that you find.
Found out the missing icon in the launcher was caused by a missing file size in the application icon. I have updated the icon graphic and now it appears correctly in the launcher. No other known issues at this time.