Great write up, and I pretty much agree with all of your comments.
For the look and feel issue, the problem is no longer a problem. I've
adjusted the look and feel plugin to use the jEdit look and feel
property as you suggested, so the look and feel selected by the user
in the look and feel plugin is loaded and applied when the plugin is
loaded. There is still a minor issue with using that property in that
on the next start of jEdit, jEdit attempts to load that look and feel,
but it's not available yet because the look and feel plugin isn't
loaded yet, so exceptions are written to the activity log and/or
console.
Dale
On Thu, Dec 1, 2011 at 6:49 PM, Vampire <Vampire@...> wrote:
> Hi all,
>
> finally I was able to spend some time to read through this thread and I also
> want to comment on some of the things mentioned in it.
>
> New GUI Toolkit: I know this discussion is more or less over for now
> already, but I still want to share my view. I really like jEdit being 100%
> pure Java and I'm strictliy against changing this. Of course I don't speak
> about installers, launchers or plugins that incorporate 3rd party tools and
> libraries. I speak about the core, and that should stay 100% pure Java.
> I'm really against using Qt, which needs native libraries and thus is bound
> to the systems where it is available.
> I don't see Swing as being dead. It is mature and proven. Many tools use it
> and I think we should continue using it.
> If we want to replace it, then the replacement should be something that
> still is 100% pure Java. Some library that is good and not too heavyweight,
> I don't want to use a toolkit where we have to bundle a library that is 10
> times the size of jEdit itself.
> JavaFX could be a good replacement for Swing.
> But NOT yet.
> JavaFX 1 was a failure.
> With JavaFX 2 Oracle tried to tidy up the mess and make it better to be used
> widespread.
> But this is too young and with uncertain future to really embrace it yet.
> Though it will be a very good choice as you mix Swing and JavaFX as far as I
> know.
> As soon as Oracle stuffed JavaFX into the OpenJDK project and JavaFX is
> shipped with the JRE and we depend as minimum on a version that ships it, I
> think that could be a point in time to think about using it for the core
> step by step.
> In the meantime plugins could use it already if they want.
> And about learning a new GUI toolkit and having to learn Swing.
> Swing is the de-facto standard for Java GUI development currently. So anyone
> who made Java GUI development before should be able to do Swing development.
> You cannot compare this to having all devs learn Qt or SWT or whatever.
>
>
> File Open Callbacks: I like the idea and had it before too, that a plugin
> can intercept the display and/or editing of a file. I would even drive it
> further. I'd suggest that a plugin is able to provide a custom EditPane for
> certain file types, determined through file ending, but also file content,
> at least first X bytes. But I wouldn't allow a plugin to take over the
> control completely, because sometimes I want to view a JPEG file as text to
> quickly see embedded text without using a hex editor or specialized program.
> There could also be multiple plugins that support a certain file type. Think
> of a hex editor or hex dump plugin e. g. I'd suggest showing multiple tabs,
> one for each EditPane instead of the normal EditPane, if there is at least
> one plugin supporting the file type. For an image there could then e. g. be
> a "Text", an "Image" and a "Hex Editor" EditPane tab. You could even split
> your TextArea and show one EditPane tab in the one split and another one in
> the other split, editing in one and seeing the effect immediately in the
> other.
>
> Modularization of jEdit: I'm basically pro this suggestions as it would
> improve architecture, stability and maintainability of jEdit. It will be
> quite some work to do though. Related, but maybe a separate idea is, to move
> the packages from org.gjt.sp.jedit.* to org.jedit.*. I think this would be a
> good point in time to do it as the modularization would break many things
> anyway and it would be a good point in time to align this also.
>
> Keymaps: Good idea and already implemented as far as I have seen. :-)
>
> Change of policy so that plugins are allowed to change shortcuts, menus,
> toolbars and so on: I personally almost always like our policy. In other
> programs like IntelliJ IDEA I install a plugin ... and then I wonder what it
> did and where I find its functionality as there can be a hundred places,
> menus, shortcuts, context popups, ... where the plugin can add itself and
> most don't state what they add where. In jEdit I know, if I add a plugin, it
> may add entries to its submenu in the Plugins menu, to the Plugins menu of
> FSB and to the context popup in FSB and that's it more or less. No
> unexpected or hard to find stuff, no automatic keyboard shortcuts that
> conflict with what I have customized or with other plugins and so on.
> IF we change policy here, then I'd like this to be done in a "suggestion"
> way, so that the plugin can say "I want to add this and that entry in this
> menu and I want to assign this and that shortcut to those actions of
> myself", but no automatic stuff that might break user customizations. From
> this dialog with suggestions, the user should be able to selectively allow
> or forbid fine granular what he allows and what not, with which existing
> actions the suggested shortcuts collide and maybe even the possibility to
> accept the suggestion, but modified, like another shortcut to be assigned.
> There should then maybe also be two options, one that says "always accept
> suggestions automatically and probably break my customizations or
> suggestions from other plugins" (including the breakage warning) and "never
> accept any suggestions" which both would cause the suggestion dialog to not
> show anymore until the setting is changed.
>
> Context sensitive help: I'd really like to see context sensitive help, so
> that the right part of the User's Guide is showing up, according to the
> context where I press F1. I like this idea.
>
> "java -classpath jEdit.jar:textarea.jar:vfs-browser.jar
> org.gjt.sp.jedit.jEdit" after modularization: You could also simply do "java
> -jar jEdit.jar" like now. In the MANIFEST of jEdit.jar you can define
> textarea.jar and vfs-browser.jar as JAR classpath just as you define the
> Main-Class.
>
> Usage metrics: I've already thought about this before too. I also did some
> research about good solutions. But unfortunately I didn't really find one
> that suited me well. There are Metrics providers, even ones that provide
> free service to Open Source projects to a certain degree. But I think I'd
> prefer one that is open source, where we can operate the serverside and have
> the data ourselves and do not depend on that provider keeping up its service
> and the free offering for FOSS projects. And with this criterion I didn't
> find a suitable solution that could be used. I also thought about
> implementing a solution from scratch. But this, as many things I'd like to
> develop, needs much more dedicated time than I could spend.
>
> Local History: Actually I already requested a simpler version of it long ago
> at
> https://sourceforge.net/tracker/index.php?func=detail&aid=1593408&group_id=588&atid=997936
> which was now transformed to a plugin feature request where it probably fits
> better as also stated by me in that artifact. The philosophy of jEdit is -
> and in my opinion should stay - that functionality that can be made
> available as plugin should be made available as plugin and not implemented
> in core, or even moved out of core into a plugin. This way jEdit stays more
> stable, maintainable and especially customizable which is one of the main
> strenghts of jEdit.
> This feature, a full Local History with diffs and so on, should clearly be
> made available through a plugin, also because it could make use of other
> plugins like a Version Control Plugin of the VCS it wants to use or the
> JDiff plugin.
> And I don't think we should make a poll here. It is not the competence of
> the users to decide where something should be implemented. At most whether
> it should be implemented or rather whether it should be shipped with the
> core, which doesn't contradict with implementing this as a plugin. But even
> this is maybe not a good thing for a user poll, as you most probably will
> only get the pro-voters voting for this and the con-voters are not
> interested and don't even look at it, but maybe complain later if you ship
> it. You could say, so what, they had their chance, but I don't think this
> would be the right attitude.
>
> Application Classpath Manipulation: What should this be needed for? I think
> if the problem are libraries that are requesting the system classloader
> instead of the context classloader, then a bug should be filed against that
> library so that it uses the context classloader instead and everything will
> be fine.
> Someone mentioned he thinks there is one JARClassloader per plugin, this is
> not the case. There is one JARClassloader in the main thread and one in each
> IO Thread. But those instances are not anyhow plugin specific. MAYBE this
> should be changed though, so that different plugins could come bundled with
> different versions of the same library. Currently the solution is to have
> one delegate plugin that only has the library in it and the other plugins
> depend on that, but that requires that all dependent plugins always work
> with the same version and if the version is upgraded, all plugins have
> probably to be touched also.
> @Dale: What exactly is your problem with the L&F plugin here? jEdit finally
> is able to switch the L&F on-the-fly again without restarting needed since I
> fixed some bug in BufferTabs and worked around a JRE Bug that prevented
> proper on-the-fly L&F change. Can't you just switch the L&F to the plugin
> provided one as soon as it is loaded?
>
> Notifications: Could maybe be a good idea, but depends on what and how
> exactly will be done here.
>
> Regards
> Vampire
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> --
> -----------------------------------------------
> jEdit Developers' List
> jEdit-devel@...
> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>
|
