ImageJX, alive, dead, or just crawling for now?

[laseray]

Hi,

So what is the situation with this potential extension of ImageJ?

Is anything going?

I just got the ImageJ code two days ago, hacked on it to put "some"
Swing upgrades in place and announced on the ImageJ list. To which I
was informed about the potential to break the AWT plugins and how
others had failed at this same thing previously. Okay.

Now I see from reading around a bit more that Wayne is dead set
against any kind of change like this, so I guess I won't be gong that
route after all. ImageJX seems to be where I might actually be able to
get something going.

Your comments.

Cheers,

Raymond Martin

[Dimiter Prodanov]

Hi,

I suggest that you/we focus on the separation of the logic from the
presentation, MVC or similar.
Then capping of a Swing GUI can be relatively easy.

Also the current plugin model is far from optimal. The main weakness
is that the plugins do not define standard inputs and outputs.


Dimiter

> --
>
> You received this message because you are subscribed to the Google Groups "ImageJX" group.
> To post to this group, send email to ima...@googlegroups.com.
> To unsubscribe from this group, send email to imagejx+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/imagejx?hl=en.
>
>
>

[Johannes Schindelin]

Hi,

On Thu, 3 Dec 2009, laseray wrote:

> Now I see from reading around a bit more that Wayne is dead set against
> any kind of change like this, so I guess I won't be gong that route
> after all. ImageJX seems to be where I might actually be able to get
> something going.

What makes you think so? Is this just a cheap way out of your claim that
it would be easy to switch ImageJ from AWT to Swing?

Ciao,
Dscho

[Raymond Martin]

> What makes you think so?

I wrote that before I had any contact with Wayne and I had read it somewhere,
maybe in docs on this group, not sure.

> Is this just a cheap way out of your claim that
> it would be easy to switch ImageJ from AWT to Swing?

I would appreciate it if you and others would refrain from jumping to
unjustified conclusions in future.

The inability of others to see the way through from AWT to Swing in no way
negates the possibility of it being done at all.

Raymond

[Raymond Martin]

Hi,

Actually, I was asking about the state of ImageJX.

Can you tell me anything about that?

> I suggest that you/we focus on the separation of the logic from the
> presentation, MVC or similar.
> Then capping of a Swing GUI can be relatively easy.

Maybe later, for now AWT to Swing where applicable.

Right now I have chosen to work on that as a starting point.

> Also the current plugin model is far from optimal. The main weakness
> is that the plugins do not define standard inputs and outputs.

Noted.

Raymond

[Dimiter Prodanov]

I will encourage your efforts. As long as you have anything stable
please share it with the community.
I think that many people would like to try it and see where it could
actually work/fail.
But please comment on my earlier posts.

Dimiter

[Johan Henriksson]

if you absolutely want to switch GUI library, maybe you want to have a
look one step further? there are better alternatives than swing which is
rather buggy and does not always look native. of course, swing might
make it easier to move from AWT.

* Qt-java (aka jambi), probably the best bet now that Qt has gone GPL.
looks native on all platforms.
BIG disadvantage: they brought the slot system over from C++

* GTK-java: just an option but GTK is not known to always look native

* SWT, native, obviously very java-ish since it is used by Eclipse

been considering changing library for Endrov for a long time (likely
won't happen before 5.x) but I'm waiting for either SWT or Qt to "win".
since SWT is java-only, I think it will be Qt.

/Johan

--
-----------------------------------------------------------
Johan Henriksson
PhD student, Karolinska Institutet
http://mahogny.areta.org  http://www.endrov.net

[Johannes Schindelin]

Hi Johan,

I tried to send the mail to Johan Henriksson <mah...@areta.org>, but the
server was not responding. So please accept my apologies for the poor
netiquette not to Cc: you.

On Tue, 8 Dec 2009, Johan Henriksson wrote:

> if you absolutely want to switch GUI library, maybe you want to have a
> look one step further? there are better alternatives than swing which is
> rather buggy and does not always look native. of course, swing might
> make it easier to move from AWT.
>
> * Qt-java (aka jambi), probably the best bet now that Qt has gone GPL.
> looks native on all platforms. BIG disadvantage: they brought the
> slot system over from C++
>
> * GTK-java: just an option but GTK is not known to always look native
>
> * SWT, native, obviously very java-ish since it is used by Eclipse
>
> been considering changing library for Endrov for a long time (likely
> won't happen before 5.x) but I'm waiting for either SWT or Qt to "win".
> since SWT is java-only, I think it will be Qt.

All of your suggestions share the rather dramatic shortcoming that you
need native support for every single one. Which means that you have to
have a C (or C++) compiler in addition to Java.

Oh, and new platforms might be a real problem (which cannot be said of
Java, which runs on pretty much everything except the iPhone).

Of course, this is no problem if you only try to support yourself as a
user.

Ciao,
Johannes

[Johannes Schindelin]

Hi,

On Tue, 8 Dec 2009, Raymond Martin wrote:

> > What makes you think so?
>
> I wrote that before I had any contact with Wayne and I had read it
> somewhere, maybe in docs on this group, not sure.

IMO this is a wrong impression. Wayne even added the JFileChooser, and
only when it was apparent that it did not have a native look-and-feel on
MacOSX (at that time, Java Versions >= 1.2 were supported by ImageJ, so
the option to make Swing's look-and-feel more native did not apply) did he
make it optional.

The recent update of the Command Launcher switched it from AWT to Swing,
and Wayne was very happy about it.

So I think that I have evidence that your impression is not correct.

> > Is this just a cheap way out of your claim that it would be easy to
> > switch ImageJ from AWT to Swing?
>
> I would appreciate it if you and others would refrain from jumping to
> unjustified conclusions in future.
>
> The inability of others to see the way through from AWT to Swing in no
> way negates the possibility of it being done at all.

First of all, it was no conclusion, but a question.

Second, you claimed that you have code, I offered to host it, wanted to
test it, but nothing happened so far.

So: let's see the code.

Ciao,
Johannes

[Raymond Martin]

Hi,

On December 8, 2009 04:07:00 am Dimiter Prodanov wrote:
> I will encourage your efforts. As long as you have anything stable
> please share it with the community.
> I think that many people would like to try it and see where it could
> actually work/fail.
> But please comment on my earlier posts.

Okay.

Separating GUI from core processing. I am not sure how complicated that will
be. My impression thus far is that it might not be as complicated as imagined.
I could be way off on that, but I will see as I work on other parts what the
interplay is between the GUI code, plugins, and related.

I am not familiar enough with the plugins yet to make a determination on
what is needed, but the few docs on the group about separation via interfaces
is a typical approach. Another would be to find a separate plugins framework.

Regards,

Raymond

[Dimiter Prodanov]

I don't say it will be programmatically complicated.
Simply you have to list all of the "messy" classes and the you/we can
see how to refactor each one of them.
The only constrain here is that as much as possible we need to keep
usability of a certain set of third party plugins.

br
Dimiter

[Johan Henriksson]

On Tue, Dec 8, 2009 at 11:14 AM, Johannes Schindelin <Johannes....@gmx.de> wrote:

Hi Johan,

I tried to send the mail to Johan Henriksson <mah...@areta.org>, but the
server was not responding.  So please accept my apologies for the poor
netiquette not to Cc: you.

my mail server deserves pain
 

On Tue, 8 Dec 2009, Johan Henriksson wrote:

> if you absolutely want to switch GUI library, maybe you want to have a
> look one step further? there are better alternatives than swing which is
> rather buggy and does not always look native. of course, swing might
> make it easier to move from AWT.
>
> * Qt-java (aka jambi), probably the best bet now that Qt has gone GPL.
>   looks native on all platforms.  BIG disadvantage: they brought the
>   slot system over from C++
>
> * GTK-java: just an option but GTK is not known to always look native
>
> * SWT, native, obviously very java-ish since it is used by Eclipse
>
> been considering changing library for Endrov for a long time (likely
> won't happen before 5.x) but I'm waiting for either SWT or Qt to "win".
> since SWT is java-only, I think it will be Qt.

All of your suggestions share the rather dramatic shortcoming that you
need native support for every single one.  Which means that you have to
have a C (or C++) compiler in addition to Java.

Oh, and new platforms might be a real problem (which cannot be said of
Java, which runs on pretty much everything except the iPhone).

Of course, this is no problem if you only try to support yourself as a
user.

I don't like any JNI-dependence but I don't consider it a big problem /if/ I don't have to maintain it myself. otherwise I expect the library developers to provide support for all platforms and I won't need to deal with shitty C/C++. this of course means that you should go for mainstream libraries so support won't become a problem

as for the iphone, there you run into other issues e.g. GUI taking too much space. portable devices tend to call for entire GUI-redesigns

the JNI problem creeps up from other places than the GUI though. we're currently making our opencl-java-wrapper usable on more operating systems. and opencl is truly useful for what we are doing; we have some prototypes that are just awesome.

speaking of JNI, santa, I wish for a good computational geometry library in pure java...

/Johan


 

Ciao,
Johannes

--

You received this message because you are subscribed to the Google Groups "ImageJX" group.
To post to this group, send email to ima...@googlegroups.com.
To unsubscribe from this group, send email to imagejx+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/imagejx?hl=en.

[Raymond Martin]

> On Tue, 8 Dec 2009, Johan Henriksson wrote:
> > if you absolutely want to switch GUI library, maybe you want to have a
> > look one step further? there are better alternatives than swing which is
> > rather buggy and does not always look native. of course, swing might
> > make it easier to move from AWT.
> >
> > * Qt-java (aka jambi), probably the best bet now that Qt has gone GPL.
> > looks native on all platforms. BIG disadvantage: they brought the
> > slot system over from C++
> >
> > * GTK-java: just an option but GTK is not known to always look native
> >
> > * SWT, native, obviously very java-ish since it is used by Eclipse
> >
> > been considering changing library for Endrov for a long time (likely
> > won't happen before 5.x) but I'm waiting for either SWT or Qt to "win".
> > since SWT is java-only, I think it will be Qt.
>
> All of your suggestions share the rather dramatic shortcoming that you
> need native support for every single one. Which means that you have to
> have a C (or C++) compiler in addition to Java.

Not completely correct. Distributions for QtJambi and SWT come with
pre-compiled native components for at least Linux, Mac OS X, and Windows.

> Oh, and new platforms might be a real problem (which cannot be said of
> Java, which runs on pretty much everything except the iPhone).

Java does not run on everything. It does not run on a number of different UNIX
operating systems, or versions that do exist are well out of date, difficult to
obtain, or must be purchased.

Raymond

[Raymond Martin]

On December 8, 2009 04:33:35 am Johan Henriksson wrote:
> if you absolutely want to switch GUI library, maybe you want to have a
> look one step further? there are better alternatives than swing which is
> rather buggy and does not always look native. of course, swing might
> make it easier to move from AWT.

It is the easiest step as a first effort. If the desire is to separate the GUI
from the core parts then Swing can just end up being one of a number
of potential client GUIs to the underlying functionality.

> * Qt-java (aka jambi), probably the best bet now that Qt has gone GPL.
> looks native on all platforms.
> BIG disadvantage: they brought the slot system over from C++

Qt and QtJambi are both LGPL now.

I find their slot/connection system to be much simpler and straightforward than
Java's built-in need for the Observer pattern (in the form of Listeners)
everywhere. The Observer pattern, when taken to extremes, hinders good
programming (i.e., an instance of an anti-pattern). The bringing over from Qt
of the slots system is actually one solution for Observer as an anti-pattern
in Java.

> * GTK-java: just an option but GTK is not known to always look native
>
> * SWT, native, obviously very java-ish since it is used by Eclipse
>
> been considering changing library for Endrov for a long time (likely
> won't happen before 5.x) but I'm waiting for either SWT or Qt to "win".
> since SWT is java-only, I think it will be Qt.
>

QtJambi is better, but is currently in transition since Nokia (the owners of
Qt now) dropped direct support for it and are turning it over to the FOSS
community. A 4.6 version is in progress, but won't be in sync with the Qt
version for a while. QtJambi 4.5.x is available with all needed pre-compiled
native components for Linux, Mac OS X and Windows.

Raymond