ImageJ development involvement/contributions

[David Webster]

All,

1. Why is it so important to convert from AWT to Swing?

2. Will the conversion help, hinder, or not affect users vs. developers.  If
it affects users negatively, maybe it's not worth it.

3. I've notice from these comments that Swing portability seems to be an
issue. From my experience, I find that the portabilty of ImageJ and Java is
a big plus. If you've ever tried to get openCV compile and link you know
what I mean.

4. I've had experiences with JFrames where they appear to have some
threading problems. That is sometimes they would get displayed before my
program was done add'ing components to them. This is very undesirable.

End of Diatribe

David Webster

On Sat, Dec 5, 2009 at 7:51 AM, Raymond Martin <[hidden email]> wrote:

> Hi,
>
> > > In running that plugin I have discovered a typical problem that occurs
> > > in Java GUI applications, that of the GUI blocking during long running
> > > processes. I have solved this in other GUI applications I work on by
> > > using a specific threading library, Foxtrot(BSD license), that enables
> > > the use of both synchronous and asynchronous threads in flexible ways.
> > > SwingWorker can also be used to prevent the GUI freeze, but is not as
> > > flexible (license?).
> > >
> > > Would adding this dependency be acceptable for the problem it solves?
> >
> > We usually prefer just to use threads.
>
> You can, but using one of these solutions amounts to the same thing without
> the work. These libraries just wrap threading code you would end up having
> to
> write anyway, and then some. So why bother trying to manage threads when
> someone else has done specific (high-quality) work to handle it properly?
>
> > > Other than that, I have not run into any serious problems converting to
> > > Swing yet. Since the potential for problems is believed to rest with
> > > supporting plugins, would ask others to please point out, if they can,
> > > exactly which plugins gave problems in past efforts to do what I am
> > > attempting.
> >
> > Maybe you can provide your version so people can actually test out?  The
> > most problems are actually with closed-source cannot-give-away plugins,
> > after all.
>
> Where can I post it for general access?
>
> Regards,
>
> Raymond
>

[Raymond Martin-2]

Hi David,

Firstly, I think people are getting ahead of themselves a little with this AWT
versus Swing thing, with all due respect to justified concerns.

Secondly, I can assure you that I would not even bother to try to get a
Swing-based version out if it does not work to at least some minimally
acceptable level.

And even if it does work to some minimum requirements, this does not
mean that it is automatically going to supercede the present stable version
at all. Wayne may decide not to use any of it, it is too soon to tell.

Once I have done a little more work on it an unstable/test/development
version will made available for those who are interested and it will continue
from there in some form.

Thank you for your patience and please just hold on until there is a result
you can try out.

Regards,

Raymond



On December 5, 2009 11:48:37 am David Webster wrote:

> All,
>
> 1. Why is it so important to convert from AWT to Swing?
>
> 2. Will the conversion help, hinder, or not affect users vs. developers.
>  If it affects users negatively, maybe it's not worth it.
>
> 3. I've notice from these comments that Swing portability seems to be an
> issue. From my experience, I find that the portabilty of ImageJ and Java is
> a big plus. If you've ever tried to get openCV compile and link you know
> what I mean.
>
> 4. I've had experiences with JFrames where they appear to have some
> threading problems. That is sometimes they would get displayed before my
> program was done add'ing components to them. This is very undesirable.
>
> End of Diatribe
>
> David Webster

[Colin Poczatek]

For what it's worth (and if I'm remembering correctly) the SwingWorker
class is part of Java 1.6, and there's a Sun backport to Java 1.5.
They're not compatible though.  We use the 1.6 version in our plugin.

Collin

> I have solved this in other GUI applications I work on by using a specific
> threading library, Foxtrot(BSD license), that enables the use of both
> synchronous and asynchronous threads in flexible ways. SwingWorker can also be
> used to prevent the GUI freeze, but is not as flexible (license?).
>  



The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.

[Albert Cardona-2]

On Fri, Dec 4, 2009 at 7:53 AM, Johannes Schindelin
<[hidden email]> wrote:
>>
>> If we're still talking about Swing vs AWT then none of the core data
>> structures (ImagePlus, ImageProcessor etc) need change at all.
>
> This is not true, as both have references to AWT components in them
> (e.g. ImagePlus points to its ImageWindow, ImageProcessor points to the
> Roi which points to the ImageCanvas, etc).


I second that. In TrakEM2, which uses Swing, I had to literally create
fake extended ImagePlus. ImageCanvas and ImageWindow classes just to
redirect calls, mostly for ROIs. The alterantive was to rewrite
ImageCanvas, which slowly over time I did to a surprising degree.

Making ImageJ depend on Swing would just repeat the same mistake.
Making ImageJ be GUI-independent would help a lot: then any GUI (AWT,
Swing, GWT, QT) could be bolted on top.


>> I've made an ImagePanel derivative of ImageCanvas for some of our
>> applications and there are only about 10 lines of code which need to be
>> changed to make the switch.
>
> For the SIOX plugin, Ignacio and me tried to decouple the ImagePlus from
> the ImageCanvas, and use JImagePanel, but we failed to decouple the ROIs
> enough: if the ImageProcessor is not attached to an ImageCanvas, then
> there is currently no clean way to let ImageJ handle the ROIs but display
> them as overlays of the JImagePanel.


Precisely.

Albert

[Grant Harris]

ImageJ'ers -

I agree entirely with Albert.  As some of you know, I've been working on a
refactoring of ImageJ that doesn't force you to choose between Swing and
AWT, but rather decouples the GUI components from the rest of the
application.  I believe that this can be done in a way that requires only
trivial changes to existing plugins while opening up many new possibilities.
 In addition to accommodating AWT, Swing, GWT, and QT, as Albert mentioned,
I'm also considering how to make it possible to strap ImageJ functionality
into a rich cient platform, e.g. Eclipse RCP or NetBeans Platform.  For
instance, here is a big list of NetBeans Platform applications:
http://platform.netbeans.org/screenshots.html

And here are a few imaging-related ones:
http://bluemarine.tidalwave.it/
http://www.kiyut.com/products/ekspos/index.html
https://imagine.dev.java.net/

(Disclosure: I have been using NetBeans for Java and JNI (C/C++) programming
and debugging for 5 years, so I have at least a familiarity-bias towards it.)

If anyone is interested in collaborating on exploring this aspect with me,
let me know.

With the NIH funding through LOCI (see Curtis' announcement from yesterday),
I will be working full time on this effort and I am looking forward to
helping to support and grow ImageJ and the community.  As Curtis mentioned,
we will be posting lots of material to the imagedev.org site in the coming
weeks.

Cheers.

-- Grant B. Harris
-----------------------------------------------
Scientific Informatics Analyst
Marine Biological Laboratory, Woods Hole, Mass.
[hidden email]


 

[Raymond Martin-2]

Hi Grant,

> I agree entirely with Albert.  As some of you know, I've been working on a
> refactoring of ImageJ that doesn't force you to choose between Swing and
> AWT, but rather decouples the GUI components from the rest of the
> application.

I would like to see some of that before I get along too far in going from AWT
to Swing. Right now I am merely replacing functionality in a very simple
manner. Which is more of a proof-of-concept that it can be done without
severe drawbacks. After which I was intending to look into separating the
GUI from the engine part. I would be interested to see if we can work together
on this part.

In going from AWT to Swing I think perhaps it is not realized that it is not
as serious a transition as some seem to think. The screenshots I linked to in
an earlier post show this. It may have been seen as more serious in the past
where certain functionality was broken on some platforms. As things move
forward Java has improved on all the major platforms, so these problems are in
most cases a thing of the past. Where there are issues others have created
solutions or it can be solved.

It is much more of a smooth transition than a drastic level shift.

> I believe that this can be done in a way that requires only
> trivial changes to existing plugins while opening up many new
>  possibilities.

So far I have not had to make any changes to plugins to get them to work
with my AWT2Swing version. The changes are only occurring in the main
application. As far as I can tell, issues that occur are on the side of the
plugins alone. That is, those plugins are doing things that do not work with
ImageJ 100% and not the other way around.

>  In addition to accommodating AWT, Swing, GWT, and QT, as
>  Albert mentioned, I'm also considering how to make it possible to strap
>  ImageJ functionality into a rich cient platform, e.g. Eclipse RCP or
>  NetBeans Platform.  For instance, here is a big list of NetBeans Platform
>  applications:

For a somewhat smaller application like ImageJ the addition of large extra
libraries or code that is not portable between different development
environments is a disadvantage. This is what will happen if development is
done with platforms like Eclipse or NetBeans. And it sort of vacates the idea
of keeping things separated more, like in the case of the GUI, core
processing, plugins, etc.

With a simple Ant build file and reasonable sized external libraries, where
needed, development can be done with a simple editor and command line, or
opened in Eclipse, NetBeans, JDeveloper, and so forth. To go with one of those
IDE for core development will be vendor lock-in (a software engineering anti-
pattern) for developers, which is a severe red flag to me in regards to free
software development.

It might be okay for a proprietary application, with a captive in-house team,
to settle on one environment, but it is largely inappropriate for an
application that has distributed development. There is no one-size-fits-all in
this case and it would be near impossible to force everyone to use one
environment besides the most basic core tools like a JDK and Ant. If certain
developers want to use those tools they should be free to use them, as long as
it does not prevent others from using the tools they want to use also.

I have tried NetBeans when it was at a few different versions. Not impressed.
I used Eclipse for more than a year. Okay, but bloat and other things started
to annoy me. I dabbled with JDeveloper. More of the same. I even used
KDevelop, which actually was not too bad (acts basically as an advanced editor
and runs the Ant build file). Now I mostly stick with a good editor and a
shell. It is the only way to keep really detailed control over the whole
process and nothing beats grep for searching in the code base.

Regards,

Raymond

[Daniel James White]

Hi Grant,

Begin forwarded message:

>
> Date:    Wed, 9 Dec 2009 16:54:37 -0500
> From:    Grant Harris <[hidden email]>
> Subject: Re: ImageJ development involvement/contributions
>
> ImageJ'ers -
>
> I agree entirely with Albert.  As some of you know, I've been  
> working on =
> a
> refactoring of ImageJ that doesn't force you to choose between Swing  
> and
> AWT, but rather decouples the GUI components from the rest of the
> application.  I believe that this can be done in a way that requires  
> only=
>
> trivial changes to existing plugins while opening up many new  
> possibiliti=
> es.

... only trivial changes, are still changes...
and if someone relies on a plugin they didn't write and dont know a  
friend who can fix it,
if we break that plugin and don't fix it for that person, that person  
is then screwed.

Thats an easy way to push users away from imageJ as a platform.
We dont want to do that. We want  to keep them, while making things  
better under the hood.

We must keep backwards compatibility  for plugins that are not  
actively developed....
(so long as they are not totally messed up anyway and dont even work  
properly to begin with
or were broken by recent imageJ fixes because they were badly written  
in the first place)

or else, we must collect every single plugin and make these "trivial"  
changes ourselves
(we being core imageJ develoers of the future)

> In addition to accommodating AWT, Swing, GWT, and QT, as Albert  
> mentione=
> d,
> I'm also considering how to make it possible to strap ImageJ  
> functionalit=
> y
> into a rich cient platform, e.g. Eclipse RCP or NetBeans Platform.  
> For
> instance, here is a big list of NetBeans Platform applications:
> http://platform.netbeans.org/screenshots.html
>
> And here are a few imaging-related ones:
> http://bluemarine.tidalwave.it/
> http://www.kiyut.com/products/ekspos/index.html
> https://imagine.dev.java.net/
>
> (Disclosure: I have been using NetBeans for Java and JNI (C/C++)  
> programm=
> ing
> and debugging for 5 years, so I have at least a familiarity-bias  
> towards =
> it.)
>
> If anyone is interested in collaborating on exploring this aspect  
> with me=
> ,
> let me know.

I suspect many of the Fiji guys will be interested.... as am I
(but I'm more on the user testing and than the dev end)


cheers

Dan

>
> With the NIH funding through LOCI (see Curtis' announcement from  
> yesterda=
> y),
> I will be working full time on this effort and I am looking forward to
> helping to support and grow ImageJ and the community.  As Curtis  
> mentione=
> d,
> we will be posting lots of material to the imagedev.org site in the  
> comin=
> g
> weeks.
>
> Cheers.
>
> -- Grant B. Harris
> -----------------------------------------------
> Scientific Informatics Analyst
> Marine Biological Laboratory, Woods Hole, Mass.
> [hidden email]

Dr. Daniel James White BSc. (Hons.) PhD
Senior Microscopist / Image Visualisation, Processing and Analysis
Light Microscopy and Image Processing Facilities
Max Planck Institute of Molecular Cell Biology and Genetics
Pfotenhauerstrasse 108
01307 DRESDEN
Germany

[phone] (German Mobile)
[phone] (Work phone at MPI-CBG)
[phone] (Fax MPI-CBG LMF)

http://www.bioimagexd.net  BioImageXD
http://pacific.mpi-cbg.de                Fiji -  is just ImageJ (Batteries Included)
http://www.chalkie.org.uk                Dan's Homepages
https://ifn.mpi-cbg.de  Dresden Imaging Facility Network
dan (at) chalkie.org.uk
( white (at) mpi-cbg.de )

[dscho]

Dear Grant,

On Wed, 9 Dec 2009, Grant Harris wrote:

> I'm also considering how to make it possible to strap ImageJ functionality
> into a rich cient platform, e.g. Eclipse RCP or NetBeans Platform.

You might be interested in having a look at Bio7 then:

http://www.uni-bielefeld.de/biologie/Oekosystembiologie/bio7app/index.html

Ciao,
Johannes

[Grant Harris]

Raymond -

What I am suggesting is to make it possible to use ImageJ functionality from
within an application built on a rich client platform, or in an SDI or MDI
or tabbed/docking environment.  This would in no way make ImageJ dependent
on the RCP or another library.

This is separate from the issue of the development tools.  I use an IDE
because I do not have the patience or the brainpower to manage the 1000+
files in the projects/modules that I work on.  I have to disagree with your
suggesting that "nothing beats grep for searching in the code base."
NetBeans is stable, robust, polyglotic, extensible and open source with a
large and vibrant community (the same can be said for Eclipse).  There are
also utilities for converting projects between the different IDEs and the
IDEs interact with SVN, Git, Maven, etc.  While there are some benefits of
having a group of developers use the same tools, there is nothing that locks
anyone into it.
- Grant Harris

[Raymond Martin-2]

Grant,

> What I am suggesting is to make it possible to use ImageJ functionality
>  from within an application built on a rich client platform, or in an SDI
>  or MDI or tabbed/docking environment.  This would in no way make ImageJ
>  dependent on the RCP or another library.

Sure, that can happen once the core is separated from the GUI and so forth.
Once that is separate anybody will be able to make whatever client or fork
they want no matter how much extra effort it will take.

> This is separate from the issue of the development tools.  I use an IDE
> because I do not have the patience or the brainpower to manage the 1000+
> files in the projects/modules that I work on.  I have to disagree with your
> suggesting that "nothing beats grep for searching in the code base."

grep is know to have the most efficient search algorithm in it. That is why
nothing beats it. I can easily search those 1000+ files with it or whole file
systems if need be.

> NetBeans is stable, robust, polyglotic, extensible and open source with a
> large and vibrant community (the same can be said for Eclipse).  There are
> also utilities for converting projects between the different IDEs and the
> IDEs interact with SVN, Git, Maven, etc.

Those utilities will not convert 100% in all cases. Try round-tripping a
project between a few of those tools and see if it works in all cases.

You cannot directly open a NetBeans project in Eclipse, last time I checked.
Using another utility to achieve it might work, but it is just one more tool
dependency pushed onto developers.

> While there are some benefits of having a group of developers use the same
> tools, there is nothing that locks anyone into it.

One place where you can clearly see my point is when you use NetBeans to
create GUI components. It uses XML forms and when the code is generated it has
all kinds of garbage comments in it indicating not to edit the code. If I
cannot edit the code then I am having my ability to use whatever tools I want
impeded. Now if that is not invasive vendor lock-in nothing is.

At that point I just rip out the comments, throw away the XML form, and do a
better job by hand coding than the typically inefficient code generated by
NetBeans.

What do you think ImageJ users will want, a program developed so that
the developers had an easier time doing it using comfortable tools or
that they created the best program they could doing whatever is necessary
to achieve it?

You need people that really know their stuff, which means knowing when
these IDEs really are and are not useful. There are a few things I will
eventually use Eclipse for, but only in the latter stages of testing, cleanup,
and so forth. Other than that I'm a good enough programmer to do the
majority of coding without an IDE.

Raymond

[dscho]

Hi,

On Fri, 11 Dec 2009, Raymond Martin wrote:

> Grant,
>
> > What I am suggesting is to make it possible to use ImageJ
> > functionality from within an application built on a rich client
> > platform, or in an SDI or MDI or tabbed/docking environment.  This
> > would in no way make ImageJ dependent on the RCP or another library.
>
> Sure, that can happen once the core is separated from the GUI and so
> forth. Once that is separate anybody will be able to make whatever
> client or fork they want no matter how much extra effort it will take.

This is all nice theory.  I am still waiting to see the code.

Ciao,
Johannes

[Raymond Martin-2]

On December 12, 2009 08:15:30 am you wrote:

> Hi,
>
> On Fri, 11 Dec 2009, Raymond Martin wrote:
> > Grant,
> >
> > > What I am suggesting is to make it possible to use ImageJ
> > > functionality from within an application built on a rich client
> > > platform, or in an SDI or MDI or tabbed/docking environment.  This
> > > would in no way make ImageJ dependent on the RCP or another library.
> >
> > Sure, that can happen once the core is separated from the GUI and so
> > forth. Once that is separate anybody will be able to make whatever
> > client or fork they want no matter how much extra effort it will take.
>
> This is all nice theory.  I am still waiting to see the code.

Aren't you involved in coding also?

I never indicated that I would solely be doing this separation of GUI from
core, did I. I have only just begun with AWT to Swing stuff. As I am doing that
I am seeing other things that also need work to make the application better
in various respects.

You will be waiting a long time to see the GUI/core separation if you rely on
me alone (I thought there was a funded team of developers coming together to
work on this application), there are many things that need fixing as well as
that.

All things can be done, but it will take time. Plus you do realize I am doing
this work for free, I am not benefiting personally in any way from these
contributions, I do not use the application in my work directly or indirectly.
So I am sure you can understand that in doing so I am free to contribute
what I want and at a place that suits me.

Regards,

Raymond

[Grant Harris]

Raymond –

Do you really mean to suggest that I don't understand what IDE's are or are
not good for, and that I am not a "good enough programmer" because I use an IDE?

- Grant

[Grant Harris]

Raymond --

I'm confident that Johannes is aware that you are not getting paid for this.
 Up until now almost everyone, aside from Wayne Rasband, has not been paid
for their many  efforts in relation to ImageJ.  I think that the ImageJDev
project is the first grant funding directed specifically at ImageJ.

In my experience, contributors to this list are experienced people who are
trying to be collaborative and helpful; I met many of them in Luxembourg
last year at the ImageJ conference.  Your contributions are most welcome but
honestly, several of the posts you have made here strike me as unnecessarily
aggressive and/or defensive.

Additionally, you appear to to be uninformed with respect to the history of
ImageJ.  Over the years there have been many discussions concerning the
issues you have been raising.  If you haven't, you might review the mailing
list archives here, some of the project at Fiji, as well as the dicussions
at http://groups.google.com/group/imagejx; the goals of the ImageJDev
project have grown out of these.  The project has hired three programmers
and they, with Curtis Reuden and myself, will be working full-time on this
for two years.  You, like anyone in the community with interest, is welcome
to contribute to our effort as well as to the ImageJ community generally.

-- Grant

[Grant Harris]

Dan,
I appreciate your concerns and share them.  If ImageJ does not evolve in a
way which  the community of developers and users follows, it will fail.  As
you likely know, these concerns have been debated at length both in this
mailing list and on the Google ImageJX discussion group
(http://groups.google.com/group/imagejx).
I've been working on how to refactor ImageJ for extensibility while
maintaining backward compatibility for several years now.  The best I have
been able to do thus far still requires minor changes to plug-ins; minor
meaning that they could be accomplished with several find-and-replace
operations in most cases.  I expect that the authors of most of the plug-ins
would make these changes as necessary. And if not, I expect that a user of
some obscure plug-in could find someone to make the change for them.  
From my experience and reading, software that succeeds in being used by a
significant number of people eventually reaches a point where many of the
initial design assumptions no longer hold and it becomes necessary to make
some incompatible changes in order to evolve the software further.  My sense
is that ImageJ is at that point.  If anyone can find a way to, for instance,
decouple the GUI in a way that doesn't require any changes to plugins, I'm
all ears.
- Grant

[David Webster]

Grant,

Can you give us some examples of how plugins might have to change?

I have run across a few instances where plugins are availabe from the ImgaeJ
plugins page, but the authors no longer seem to be around.

David Webster
On Sat, Dec 12, 2009 at 2:51 PM, Grant Harris <[hidden email]> wrote:

> Dan,
> I appreciate your concerns and share them.  If ImageJ does not evolve in a
> way which  the community of developers and users follows, it will fail.  As
> you likely know, these concerns have been debated at length both in this
> mailing list and on the Google ImageJX discussion group
> (http://groups.google.com/group/imagejx).
> I've been working on how to refactor ImageJ for extensibility while
> maintaining backward compatibility for several years now.  The best I have
> been able to do thus far still requires minor changes to plug-ins; minor
> meaning that they could be accomplished with several find-and-replace
> operations in most cases.  I expect that the authors of most of the
> plug-ins
> would make these changes as necessary. And if not, I expect that a user of
> some obscure plug-in could find someone to make the change for them.
> From my experience and reading, software that succeeds in being used by a
> significant number of people eventually reaches a point where many of the
> initial design assumptions no longer hold and it becomes necessary to make
> some incompatible changes in order to evolve the software further.  My
> sense
> is that ImageJ is at that point.  If anyone can find a way to, for
> instance,
> decouple the GUI in a way that doesn't require any changes to plugins, I'm
> all ears.
> - Grant
>

[Raymond Martin-2]

Grant,

> I appreciate your concerns and share them.  If ImageJ does not evolve in a
> way which  the community of developers and users follows, it will fail.  As
> you likely know, these concerns have been debated at length both in this
> mailing list and on the Google ImageJX discussion group
> (http://groups.google.com/group/imagejx).

I do not think it will fail because of those reasons. It would have failed
already if known limitations were so important for users to continue using it.

> I've been working on how to refactor ImageJ for extensibility while
> maintaining backward compatibility for several years now.  The best I have
> been able to do thus far still requires minor changes to plug-ins; minor
> meaning that they could be accomplished with several find-and-replace
> operations in most cases.

If that is the best that can be done my conclusion at this point is not to
bother trying to make extensibility a feature for plugins in their present
form. Add extensibility only for new plugins or upgraded ones, along with
continuing support for old plugins.

> I expect that the authors of most of the plug-ins would make these changes
> as necessary. And if not, I expect that a user of some obscure plug-in could
> find someone to make the change for  them.

This is what should happen, as the assumption to maintain near 100%
backward compatibility along with extending functionality for old plugins
is not going to work in all cases. And it may become a case of diminishing
returns, where too much effort is expended to attempt to provide support
past a certain point.

There seems to be the assumption that once a plugin has been made that it
should work indefinitely through all new versions of the program and have all
the new features also, without maintenance to keep it up-to-date. That is not
reasonable (a cake and eat it scenario) since so many of the underlying
factors will change that are necessary to facilitate that in the long run.

Reality shows that hardly anybody is running software from say 20 years ago
with extra functionality that was added on to it, it either does not exist
anymore, it changed drastically, the operating system it worked on upgraded
numbers of times adding/removing functionality in the process, and so on.
Real-world computing requires periodic maintenance/upgrade of all combined
parts.

> From my experience and reading, software that succeeds in being used
>  by a significant number of people eventually reaches a point where many of
>  the initial design assumptions no longer hold and it becomes necessary to
>  make some incompatible changes in order to evolve the software further.
>  My sense is that ImageJ is at that point.

So some of the motivations that are supposed to drive the funded development
of ImageJ on imagejdev.org cannot really hold.

Maintaining near 100% backwards compatibility is one of those things.

Another is the idea of "no forks". An impossible ideas for a project that is
free software, and public domain on top of that. I really wonder why this same
though this not occurred to anyone working on that side of things. The only
way to have no forks is to have no free software, no ImageJ. Am I seeing
proprietary thinking trying to mix itself in with free software?

>  If anyone can find a way to, for instance, decouple the GUI in a way that
>  doesn't require any changes to plugins, I'm all ears.

I think I just mentioned it above. Provide support for old plugins, but
extensibility only for new ones.

Raymond

[Raymond Martin-2]

Hi,

A few open questions to ImageJ users who have it or want to install it on
Linux/UNIX systems.

Would having an RPM, .deb, or other package for installation be of interest?

That is, is system-wide installation of ImageJ in the expected manner as for
other Linux/UNIX application packages desirable for you and others that use it
on your systems?

Do you want to be able to control the installation and upgrade of ImageJ by
only allowing a user with root privileges (superuser/system administrator) to
do it?

Also, I would like to know how many actually use the upgrade feature in
ImageJ to do anything besides upgrading between a current version and a new
one?

Even for that, this kind of feature will not work on Linux/UNIX when ImageJ is
installed system-wide, as opposed to somewhere in a users home directory. What
is often seen in this case is just an ability to be notified of an upgrade,
take you to a web page, and let you choose the method of upgrade that is
suitable to your system instead.

I can easily make an RPM, but certain changes need to be made to ImageJ
for it to function as expected in a normal Linux/UNIX installed way. Fiji
seems to have a .deb so I wonder what changes they made for it to work,
must have seen the same issues?

Regards,

Raymond

[Wolfgang Schechinger]

Hi Raymond,

I am using IJ under OpenSuse 11.1 on several stand-alone systems (notebooks). I do not require a system-wide installation, but having an rpm and this feature would be good, I think: If I were using different accounts for different projects or at work/at home it would become easier to manage system wide updates.

Ideal would be to give the user the option to either install it locally or system-wide. For updates, IJ / the system just would need to ask for the root password as it is currently done within the update function of OpenSuse.

Best regards,

Wolfgang


-------- Original-Nachricht --------
> Datum: Sun, 13 Dec 2009 00:58:26 -0500
> Von: Raymond Martin <[hidden email]>
> An: [hidden email]
> Betreff: Linux/UNIX users and installation

> Hi,
>
> A few open questions to ImageJ users who have it or want to install it on
> Linux/UNIX systems.
>
> Would having an RPM, .deb, or other package for installation be of
> interest?
>
> That is, is system-wide installation of ImageJ in the expected manner as
> for
> other Linux/UNIX application packages desirable for you and others that
> use it
> on your systems?
>
> Do you want to be able to control the installation and upgrade of ImageJ
> by
> only allowing a user with root privileges (superuser/system administrator)
> to
> do it?
>
> Also, I would like to know how many actually use the upgrade feature in
> ImageJ to do anything besides upgrading between a current version and a
> new
> one?
>
> Even for that, this kind of feature will not work on Linux/UNIX when
> ImageJ is
> installed system-wide, as opposed to somewhere in a users home directory.
> What
> is often seen in this case is just an ability to be notified of an
> upgrade,
> take you to a web page, and let you choose the method of upgrade that is
> suitable to your system instead.
>
> I can easily make an RPM, but certain changes need to be made to ImageJ
> for it to function as expected in a normal Linux/UNIX installed way. Fiji
> seems to have a .deb so I wonder what changes they made for it to work,
> must have seen the same issues?
>
> Regards,
>
> Raymond

--
Preisknaller: GMX DSL Flatrate für nur 16,99 Euro/mtl.!
http://portal.gmx.net/de/go/dsl02

[Albert Cardona-2]

Raymond,

ImageJ has been distributed as a debian package for years.
It is even in Ubuntu, package 1.43b-1ubuntu1 in my Ubuntu 9.10

As for Fiji's debian package, see Fiji's source code and debian scripts:

http://pacific.mpi-cbg.de/cgi-bin/gitweb.cgi?p=fiji.git;a=tree;f=debian;hb=HEAD

Albert
--
http://albert.rierol.net