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

[Shlomy R. <sre...@gm...>]

Hi,

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...).
About keymaps: I think plugins should be able to provide their own suggested
keymaps for their own actions. I don't like the fact that a plugin always
comes with no shortcuts and I have to define each shortcut manually.
In general, I think plugins should be able to contribute toolbars or toolbar
buttons and menus or menu items, like in most IDEs. I know that this is
currently also possible but it's currently against the jEdit plugin
development policy and not very trivial to do.

Callbacks when opening a file - can you explain further? Where would an
image open if you invoke "Open File" and select a .jpg file? And is it
limited to viewing or allow also editing (like eclipse)?

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.

Also, I think jEdit 2012 should include some things from the feature
requests like replacing the help index with lucene, and providing better
integration between the GUI and the help.

Thanks,
Shlomy



On Fri, Oct 21, 2011 at 11:22 AM, Matthieu Casanova
<cho...@gm...>wrote:

> Hi,
> here is the discussion about the next jEdit.
> I call it jEdit 2012 since we don't know it's version number yet.
>
> The idea here is only talk about major changes.
> First I copy some examples from another discussion
>
> Redesign the UI : I completely agree with that idea, but we have to decide
> what it means.
>
> Replace Swing with Java FX 2 : I don't know Java FX very well, but I had
> high hopes about Java FX, and finally I never heard about a major project
> using that framework, do you ?
> So it may be dangerous to switch to Java FX if in the end Oracle says that
> it has no future and stops that.
>
>
> About my ideas:
>
> Have keymaps to switch keymap schemes, and of course provide several
> schemes, so user from other editors may find jEdit easier. I don't know if
> it would be considered as major or minor.
>
> Another one is  about using callbacks when opening a file, of course
> pluggable. So  it would be possible to create a plugin that would open
> images, and instead of having the image file content in a buffer we would
> show the image.
>
> Another one, the biggest :
> make a major refactoring of jEdit to split it into small bundles that would
> be independant from each others.
> The bundles should communicate through interfaces. Each bundle would be
> compilable without help of all other bundles and dependencies between them
> are declared
> This would make jEdit's easier to understand for a new programmer, and it
> would be possible to replace a bundle by another one.
> For example we could have a bundle for VFS Browser, but since it
> communicates through interfaces, a plugin could replace the original VFS
> Browser with a new one.
> I think OSGI could be a good start to define our bundles (it's easy, there
> are only some metadatas to add to our jars).
> And it is not mandatory to run jEdit in an OSGI framework, but if for
> example the TextArea is an osgi bundle, it will be easier to use in another
> project.
> Doing that will make jEdit modular and it will be easy to replace one part
> of jEdit without breaking other parts.
> Most java IDE are now using OSGI, Eclipse and Netbeans for example.
>
> Matthieu
>
>
> ------------------------------------------------------------------------------
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn
> about Cisco certifications, training, and career opportunities.
> http://p.sf.net/sfu/cisco-dev2dev
> --
> -----------------------------------------------
> jEdit Developers' List
> jEd...@li...
> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>
>