Re: [ jEdit-devel ] What's in jEdit 2012

[Matthieu C. <cho...@gm...>]

2011/10/21 Brian Schlining <bsc...@gm...>

>
> About Java FX 2: I am also not familiar with it. What is the added value
>> over Swing? If we switch to another GUI toolkit, maybe it's time to examine
>> the alternatives (Qt being one of them...).
>>
>
> JavaFX Pros:
> - It's a pretty awesome little UI toolkit (Real scene graph, fast, real
> HTML renderer, Animations, very simple to do node transforms etc, etc, etc)
> - Oracle will not be doing much work on Swing, they are focusing on JavaFX
> as THE UI toolkit for Java going forward.
> - It is being open-sourced and will be included in Java 7 at some future
> date.
>
> JavaFX Cons:
> - Until javaFX is included in the JRE, deployment of JavaFX apps will suck
> (ala SWT and QT kit ... there's lot's of platform specific native libraries)
> - No one has much experience with it yet. It's very different than Swing.
> - There's still some functionality gaps.
> - It currently only has very limited platform support (Windows, Mac, ...
> linux is coming, other platforms ... who knows)
> - There's no scene graph layout tool (although one is in the works)
>

Thanks for that summary, so I think that JavaFX is too young for jEdit. But
maybe some plugins could use JavaFX if they need to.


>
>> Using OSGi bundles is a great idea, just a lot of work, and eventually we
>> should make sure it does not become as heavy as eclipse. One of the major
>> reasons I use jEdit is that it's relatively light, and responds fast.
>>
>
> I think modularizing jEdit is a great idea. Not sure if it needs to go the
> OSGI route ... what's wrong with good ol' Java interfaces?
>

It is not incompatible. In fact we would still use interfaces of course.
My idea is that jEdit would be composed of services described by interfaces.
For example an interface for a Buffer, an interface for a VFS Browser, an
interface for a file. And modules would implement those interfaces.
The benefit of OSGI is that it is already defined, documented and easy to
understand.
At least the packaging rules that we can follow.
A bundle says what package is exported, and also what package is needed to
run.
Only one bundle can export a package (there may not be two bundles that
export different classes in package org.gjt.sp.jedit.textarea for example).
If we have that, it is already a great step.
After that if we don't run in an OSGI engine, of course we don't use the
OSGI services, but at least we can declare imported and exported packages.
Our bundles will not be real osgi bundles but they will be close. And the
standalone textarea can be a real OSGI bundle so it will be easier to
include it in another project and has no impact on jEdit itself.

2011/10/21 Shlomy Reinstein <sre...@gm...>

> Matthieu:
> - I think mixing Swing with another toolkit is not a good idea. It can work
> fine when two light-weight toolkits are used, but mixing a heavy-weight
> toolkit like Swing with another is likely to have problems. And finally,
> what would the interface of the dockable window manager look like? Will it
> expect JComponent or some other library component?
> - About expecting developers to learn Qt - well, right now they are
> expected to learn Swing - and if we switch to Java FX - then we expect them
> to learn Java FX. I know several plugin developers (including myself) that
> learned Swing especially for the jEdit work. I don't think learning a new
> toolkit should be an issue. What do the other developers think?
>
>
But we have a lot of developpers that knows Swing and a lot less, maybe
nobody that knows Qt integration in java. And about other replacement for
Swing, I don't want to. For example I think a new VFS Browser would be
great, but I don't think anybody will write one, so can you imagine
rewriting jEdit entirely ?

Matthieu