![]() ![]() However, I am trying to be pretty strict about making my Chocolatey packages be system (i.e. I am not a developer by training (nor terribly knowledable of developer-y things), but I would be happy to continue toward both ImageJ2 and Fiji Chocolatey packages. □ I have been playing with Chocolatey and (attempting) making packages for software I am asked to include in a classroom/lab (hence all the science-y stuff). ![]() I don't mean to be the guy that asks for difficult/impossible things without knowing what I am doing, but I guess I have here.Īctually, I am here posting issues (and questions on the forum) because I was investigating creating a Chocolatey package. I can't suggest it one way or another because I know nothing about it, sorry. ![]() How would you suggest we run a Java-based Windows service? In my experience, almost no software offers this, so I don't expect ImageJ to end up there either. Everything the admin pushed would update at the admin's discretion, and the user would update their pieces when they choose. In my idealized world, system admins would be able to deploy an application and define the "required" plugins, the "default" plugins (that user's could disable), and then allow each user the ability to include their own library of plugins. deployment) and allowing users to pick and upgrade their plugins on their schedule. ![]() Thus there was no real means of a machine installation and occasional "managed" upgrades by admins (i.e. My understanding (based on trying to find what version I would be downloading) is/was that ImageJ/Fiji was so much a collection of smaller pieces that there was no base program to "versionize". since it looks like you are a Windows/Chocolatey enthusiast: any interest in helping with ? I would love to update/expand it to include ImageJ2, but have no bandwidth currently!ĭoes that sound like an OK plan to you, I didn't know this was an option. I am very reticent to invest lots of effort into Windows-specific (or macOS-specific, or Linux-specific) layers of ImageJ, unless doing so creates a huge boost in usability somehow. How would you suggest we run a Java-based Windows service? The Java Service Wrapper? Have you used it? My explicit goal for the future of ImageJ is no native code I do not want to ship anything platform-specific or native, because the maintenance and testing burden is too high. for thumb drives which migrate across machines, when the user does own the ImageJ installation folder.ĭoes that sound like an OK plan to you, wrote:Ĭreate a service that will update ImageJ/Fiji as the SYSTEM account. And only if you configure ImageJ to be a "portable app" does it try to manage its plugins within its own installation prefix. So, I think the best solution will be for ImageJ to be more flexible: by default, plugins should be installed into user space in standard locations-or failing that, at least something relatively platform-neutral like $HOME/.imagej. Right now, you at least get a warning about being unable to update from a "protected location", but no real guidance is given to users about how to fix this. As long as users keep unpacking ImageJ and dumping it into C:\Program Files, we need to be as friendly/nice as possible. Windows users sometimes complain about how weird/unintuitive it is that ImageJ cannot function properly out of Program Files like "normal" applications do-and I am inclined to agree. And if the Updater does not see that stub file, it refuses to try to update an installation in Program Files. To do that, we can have the installer write a stub file into the installation directory, which is not present in the ImageJ/Fiji cross-platform zip distribution. One wrinkle is that we still want to give a helpful error message if ImageJ/Fiji was manually unpacked into Program Files without using the installer. Having a Windows installer will be good anyway because Windows users are most comfortable with them (just like OS X users are comfortable with DMG images which they mount and then copy the. However, there is a potential solution: distribute the Windows version of ImageJ using an installer such as NSIS or Inno Setup, and have the installer flag the entire ImageJ/Fiji directory as globally writable by all users.įor details, see this SO answer and this Inno Setup FAQ entry. It is in general very difficult to detect programmatically whether things will work they might seem to work temporarily until the computer is rebooted, for example. This is due to the Windows security model. Right now, Fiji and ImageJ2 have the problem that if unpacked into the Program Files directory on Windows, the ImageJ Updater does not have full, unimpeded read/write access to its own directory. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |