Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
Dear List,
A While back we heard of the Fiji Update Site concept from Johannes which would be great for us to distribute the few macros and plugins our users have come to enjoy using on our platform. After a few unsuccessful attempts, we've got it up and running no problem. I was just curious on whether the updater could add other files to the update site. For instance, we have an ActionBar that contains icons in .png format. We can upload the actionBar to the update site but the icons, if added as a dependency, are considered as an "obsolete/local-only dependency". Would there be a way to overcome this? Thanks! Oli -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
Wild guess, have you tried uploading a jar file into the plugins or jar
directory that contains only the png icons? I suspect this to work as for Java plugins, I bundle the required `external' files in the jar file. Best, Stephan On Thu, 2013-01-31 at 09:17 +0000, Burri Olivier wrote: > Dear List, > > A While back we heard of the Fiji Update Site concept from Johannes which would be great for us to distribute the few macros and plugins our users have come to enjoy using on our platform. > > After a few unsuccessful attempts, we've got it up and running no problem. > > I was just curious on whether the updater could add other files to the update site. For instance, we have an ActionBar that contains icons in .png format. We can upload the actionBar to the update site but the icons, if added as a dependency, are considered as an "obsolete/local-only dependency". > > Would there be a way to overcome this? > > Thanks! > > Oli > > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.html ... [show rest of quote] -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
Hello,
> I suspect this to work as for Java plugins, I bundle the required `external' files in the jar file. This indeed works for plugins, but as we're talking of an Action Bar, it's just some .ijm macro code, which the Fiji updater takes into account. The icons, to be accessible by the Action Bar, need to be in a folder within the "plugins/actionBar/icons" directory, which is why I wanted trying to upload them separately. Best, Oli Olivier Burri Engineer - Image Processing & Software Development EPFL - SV - PTECH - PTBIOP -----Original Message----- From: ImageJ Interest Group [mailto:[hidden email]] On Behalf Of Stephan Saalfeld Sent: jeudi 31 janvier 2013 12:08 To: [hidden email] Subject: Re: Fiji Update Site: Dependencies Wild guess, have you tried uploading a jar file into the plugins or jar directory that contains only the png icons? I suspect this to work as for Java plugins, I bundle the required `external' files in the jar file. Best, Stephan On Thu, 2013-01-31 at 09:17 +0000, Burri Olivier wrote: > Dear List, > > A While back we heard of the Fiji Update Site concept from Johannes which would be great for us to distribute the few macros and plugins our users have come to enjoy using on our platform. > > After a few unsuccessful attempts, we've got it up and running no problem. > > I was just curious on whether the updater could add other files to the update site. For instance, we have an ActionBar that contains icons in .png format. We can upload the actionBar to the update site but the icons, if added as a dependency, are considered as an "obsolete/local-only dependency". > > Would there be a way to overcome this? > > Thanks! > > Oli > > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.html ... [show rest of quote] -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
Sure. But my guess was that if you upload an additional jar file that
contains e.g. plugins/actionBar/icons/myIcon1.png plugins/actionBar/icons/myIcon2.png shouldn't that be accessible for the ActionBar then? May be not if it's enforcing loading them from the file system---but would be nice... Sorry for unqualified loud thinking :) Best, Stephan On Thu, 2013-01-31 at 11:35 +0000, Burri Olivier wrote: > plugins/actionBar/icons -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
In reply to this post by Olivier Burri
Hi Olivier,
On Thu, 31 Jan 2013, Burri Olivier wrote: > A While back we heard of the Fiji Update Site concept from Johannes > which would be great for us to distribute the few macros and plugins our > users have come to enjoy using on our platform. > > After a few unsuccessful attempts, we've got it up and running no > problem. > > I was just curious on whether the updater could add other files to the > update site. For instance, we have an ActionBar that contains icons in > .png format. We can upload the actionBar to the update site but the > icons, if added as a dependency, are considered as an > "obsolete/local-only dependency". > > Would there be a way to overcome this? I guess those icons live in plugins/? The problem with that is that really only plugins should live in that subdirectory. Any chance this can be changed to the images/ subdirectory? Ciao, Johannes -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
In reply to this post by Olivier Burri
Hi Olivier,
On 31 janv. 2013, at 10:17, Burri Olivier wrote: > Dear List, > > A While back we heard of the Fiji Update Site concept from Johannes which would be great for us to distribute the few macros and plugins our users have come to enjoy using on our platform. > > After a few unsuccessful attempts, we've got it up and running no problem. Sorry for not having followed the verge of that idea (I therefore cannot fully understand the technical discussion going on here), but what do you mean by Fiji Update Site concept ? Is it accessible somewhere I can have a look at ? How does it work ? Cheers Alexandre -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
Hi Alexandre,
On Thu, 31 Jan 2013, Alexandre Dufour wrote: > On 31 janv. 2013, at 10:17, Burri Olivier wrote: > > > A While back we heard of the Fiji Update Site concept from Johannes > > which would be great for us to distribute the few macros and plugins > > our users have come to enjoy using on our platform. > > > > After a few unsuccessful attempts, we've got it up and running no > > problem. > > Sorry for not having followed the verge of that idea (I therefore cannot > fully understand the technical discussion going on here), but what do > you mean by Fiji Update Site concept ? Is it accessible somewhere I can > have a look at ? How does it work ? Have a look here: http://fiji.sc/Update_Sites A slightly detailed technical overview can be found here: http://fiji.sc/Uploading_plugins#Internals If Icy is interested in using the Updater, I will be glad to make it work for you. Ciao, Johannes -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
In reply to this post by Alexandre Dufour
Hi Alexandre,
> what do you mean by Fiji Update Site concept ? Fiji supports the idea of "update sites," which make distribution and updates of plugins much easier. Plugin developers can create their own ("third-party") update site, which hosts their plugins [1]. Users can add these third-party update sites to their Fiji installation [2], so that all the plugins there get included and updated automatically. We moved the Updater into ImageJ2 core last year [3] -- but Fiji still uses it too, of course. See also the ImageJ2 2.0.0-beta1 blog post [4] for more about update sites. Personally, I think the Updater is Fiji's single most valuable addition to ImageJ, since it makes it so much easier to manage all your plugins, extend ImageJ with more plugins, etc. Regards, Curtis [1] http://fiji.sc/How_to_set_up_and_populate_an_update_site [2] http://fiji.sc/Update_Sites [3] http://developer.imagej.net/2012/09/11/imagej-v200-beta4 [4] http://developer.imagej.net/2012/04/09/imagej-v200-beta1 On Thu, Jan 31, 2013 at 9:26 AM, Alexandre Dufour <[hidden email]>wrote: > Hi Olivier, > > On 31 janv. 2013, at 10:17, Burri Olivier wrote: > > > Dear List, > > > > A While back we heard of the Fiji Update Site concept from Johannes > which would be great for us to distribute the few macros and plugins our > users have come to enjoy using on our platform. > > > > After a few unsuccessful attempts, we've got it up and running no > problem. > > Sorry for not having followed the verge of that idea (I therefore cannot > fully understand the technical discussion going on here), but what do you > mean by Fiji Update Site concept ? Is it accessible somewhere I can have a > look at ? How does it work ? > > Cheers > Alexandre > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.html > ... [show rest of quote] -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
In reply to this post by dscho
Hi Johannes, Curtis
On 31 janv. 2013, at 16:47, Johannes Schindelin wrote: > Have a look here: > > http://fiji.sc/Update_Sites > > A slightly detailed technical overview can be found here: > > http://fiji.sc/Uploading_plugins#Internals > > If Icy is interested in using the Updater, I will be glad to make it work > for you. Thanks for the pointers. in fact I realize I already knew about the updater, since Icy has had the exact same system from day 1 (we just subjectively borrowed the term "repository" from the linux world rather that the Eclipse-centric "update site"). I probably just got confused by the discussion about packing icons etc. in the right place/folder, wrongly assuming that the "update sites" actually led to full html pages online where the plugin icons would appear, like what we did with the Icy website (and I would have liked to see how it worked if that was the case). In our case, icons are submitted via the site's Content Management System (which feeds the "official" repository), separately from the jar, because it offered several advantages: 1) the web site automatically generates the plug-in web page online; 2) the various media and metadata published online alongside the jar can be displayed in-app either via the plugin browser, or via our new "spotlight"-like all-in-one search bar (inspired from IJ2's search bar which we extended to do live plugin browsing/dowloading/running from the keyboard). I guess we could also adapt the system if you guys want to use the same distribution system, and even make this work for plain ImageJ. Btw, seeing the screen captures on said pointers, does Fiji still need to be restarted when downloading/updating plugins? I thought I understood from a recent meeting this was solved (it took us hard effort to solve the problem and avoid restarting for every new plugin install/update). Alexandre -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
Hi Alexandre,
On Thu, 31 Jan 2013, Alexandre Dufour wrote: > On 31 janv. 2013, at 16:47, Johannes Schindelin wrote: > > > Have a look here: > > > > http://fiji.sc/Update_Sites > > > > A slightly detailed technical overview can be found here: > > > > http://fiji.sc/Uploading_plugins#Internals > > > > If Icy is interested in using the Updater, I will be glad to make it work > > for you. > > Thanks for the pointers. in fact I realize I already knew about the > updater, since Icy has had the exact same system from day 1 (we just > subjectively borrowed the term "repository" from the linux world rather > that the Eclipse-centric "update site"). ... [show rest of quote] Heh... you make it sound like Icy is the only software that had an updater from day one. In fact, I was a bit surprised when I learnt about Icy and that it re-invented the whole shebang. As to the term "update site": We had a quick (internal) survey when we had to decide what to call the beast in October 2010, when I started to work on third-party update sites. The outcome was that users understood what update sites are. > I probably just got confused by the discussion about packing icons etc. > in the right place/folder, wrongly assuming that the "update sites" > actually led to full html pages online where the plugin icons would > appear, like what we did with the Icy website (and I would have liked to > see how it worked if that was the case). Yes, the update sites supported by the Fiji/ImageJ updater are not primarily web sites. The idea was that we did not want to dictate how plugins are to be served. Indeed, since there is such a vast abundance of ImageJ plugins with there own websites -- which existed well before Fiji's first release in 2008 -- all such an enforced integration would have done is to upset developers. That is why the update sites are basically static files for consumption by the updater only. > In our case, icons are submitted via the site's Content Management > System (which feeds the "official" repository), separately from the jar, > because it offered several advantages: 1) the web site automatically > generates the plug-in web page online; 2) the various media and metadata > published online alongside the jar can be displayed in-app either via > the plugin browser, or via our new "spotlight"-like all-in-one search > bar Yes, having a tightly controlled environment is nice for such things. You can even change the complete graphical layout from one day to another, and it will trickle down to all the plugins' descriptions. Makes for nice bling. > (inspired from IJ2's search bar which we extended to do live plugin > browsing/dowloading/running from the keyboard). I guess we could also > adapt the system if you guys want to use the same distribution system, > and even make this work for plain ImageJ. Of course, I always welcome enhancements to the software I released as Open Source. The Command Finder is an excellent example for vivid collaboration: it was originally written by Mark Longair for Fiji, accepted into ImageJ 1.x by Wayne, later enhanced more by Mark, Curtis and me, then extended even more in ImageJ 2, a stripped-down version of which was accepted into ImageJ 1.x again. I will be glad to merge back every enhancement you want to contribute. > Btw, seeing the screen captures on said pointers, does Fiji still need > to be restarted when downloading/updating plugins? I thought I > understood from a recent meeting this was solved (it took us hard effort > to solve the problem and avoid restarting for every new plugin > install/update). Yes, Fiji still needs to be restarted in many circumstances. In general, it is not possible to change the .jar files underneath the JVM (sometimes it pretends that this is possible, but results in nasty crashes, or even the inability to close ImageJ normally). Even if you load everything into new class loaders: the images that have been opened before by classes running in old class loaders (and mixing objects of the same class loaded with different class loaders is not possible, for good reasons). After trying a lot of strategies (on and off, our main focus is scientific image analysis after all, and everything we do in Fiji is driven by concrete, scientific goals), we settled for the following procedure: after updating, the updater suggests to restart (which is the safe thing). But it is quite possible to finalize the update by starting the updater again -- it will warn the user about untoward things that might happen -- and simply refresing the menus afterwards. We found this to be an acceptable compromise between stability and flexibility. Ciao, Johannes -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Free forum by Nabble | Disable Popup Ads | Edit this page |