From: Dale A. <da...@ge...> - 2004-06-21 14:55:52
|
Hi Brian, This is more or less what ProjectViewer provides now. If your plugin sets a jEdit property like plugin.projectviewer.<my plugin class name>.pv-listeners=<my listener class> then ProjectViewer will read that property and send project events to your listener. ProjectViewer doesn't care if your plugin is loaded or not, it just sends messages to registered listeners, which gives the tight integration. My problem with this particular implementation is the listener must implement ProjectViewerListener, which means there is a compile-time dependency. If instead the listener were an ActionListener, then there would be no dependencies at all (loose coupling). I have only myself to blame, I helped implement the ProjectViewerListener stuff in ProjectViewer a couple of years ago... :( On the other hand, having a ProjectViewerListener means that my listener gets ProjectViewerEvents, which lets my plugin do closer interaction with ProjectViewer. If the Session plugin also read this property and sent appropriate messages, then we'd have the sort of interoperability you're suggesting. Personally, though, I'd rather use the EditBus for inter-plugin messaging. Like jEdit properties, it's a well established and currently existing system. I always worry about using property files for messaging, it seems like a clumsy way to do it. EditBus messages are all in-memory, and are sent to all registered plugins. So if ProjectViewer wants to tell other plugins that it has changed to a new project, it would send an EBMessage saying so, and interested plugins could respond. Dale Brian Hawkins wrote: > Loosely coupled and tightly integrated. I know that sounds like an > oxymoron but it is what should be obtained. You become tightly > integrated by having a well defined means of getting things done. You > are loosely coupled when you have a means of intercommunication that > does not create hard coded dependencies. A good example of being > loosely coupled is use of the edit bus. I can write a plugin that > response to another plugins event and if that other plugin never gets > installed it is not big deal to my plugin. > > Right now in jedit in order for some plugins (and jedit core) to get > things done they have to reach into other codes back pockets and link > into places that were never expected to be linked to. This makes the > code brittle. You change some functionality to enhance or fix and the > whole thing is a bust. > > The reason I keep wanting this as part of the core is so the core itself > can benefit from it. There are none plugin settings in jedit that I > would like to have on a per project basis. > > Dale, this work you have done on Antelope. What if I want Antelope to > integrate with the session plugin to do the same thing? > > Now what if Antelope used the JEdit set/getProperty api's to save what > build file it is using. And then it either calls those apis every time > it is asked to build or it refreshes its cached values when a EB event > occurs. Now when the project changes antelope is ready to go and it > doesn't even know it is project aware. Now it works with the session > plugin as well with no additional effort. Now these two plugins > (antelope and project viewer) are loosely coupled, but integrate nicely. > > See what a beautiful world this would be? > > Now let me reiterate, because this point seems to be missed. This > change would not affect normal jedit of a text file functionality, it > would be an option. It would also be light weight. > > Brian > > > Dale Anson wrote: > >> One thing that hasn't been mentioned on this thread is the >> ProjectViewer API itself. Any plugin can register a listener with the >> ProjectViewer plugin via jEdit properties. This means that any plugin >> can be aware of project changes in ProjectViewer and respond >> accordingly. I've actually been working to add this functionality to >> Antelope over the past couple of weeks so that if the ProjectViewer >> project contains a build file, Antelope will automatically open it. >> Having dug into the ProjectViewer code a bit, I'd like to propose a >> change to the ProjectViewer API so it supports a generic >> ActionListener rather than a ProjectViewerListener, which would >> eliminate compile-time dependencies. I'm putting together some diffs >> to send to Marcelo to see if he'll put those changes into >> ProjectViewer. I would need to check again, but I believe that >> ProjectViewer already responds to EditBus messages, so other plugins >> can get it to change projects as needed. >> >> Dale >> >> >> >> Lee Turner wrote: >> >>> Hi >>> >>> I can fully understand where you are coming from in wanting tighter >>> integration but you are always going to come up against the different >>> ways people work and the fact that some people want tighter >>> integration and others want to be able to install a plugin (like ftp >>> for example) without a whole raft of other plugins that they are >>> never going to use. I don't use ProjectViewer myself, and I already >>> have to have it installed if I want to use the SQL plugin which kind >>> of sucks. Because jEdit is such a good text editor, and you can >>> develop any one of the over 100 languages that it now supports, it is >>> very dangerous to try and create dependencies that don't fit with the >>> broad scope of how people develop. For example, your comment : >>> >>> <snip> >>> Now wouldn't it be great if someone came up with plugin that would >>> run autobuild or make on your code and the settings for that plugin >>> were saved on a per project/session basis? You switch sessions and >>> hit the compile shortcut and it knows what make to run because it is >>> session specific. >>> </snip> >>> >>> I develop in Java and use ant to build my projects. I have the >>> AntFarm and AntHelper plugins installed which gives me exactly what >>> you describe. This is just one example of one way of working which >>> is not in the slightest bit related to what you are describing. >>> >>> This whole topic has come up a few times in the past and people have >>> even written things to try and tackle the problem. Robert Fletcher >>> put together the JLib plugin (in CVS) which provided a delegation >>> mechanism to allow the user to select the plugin which would store >>> properties (ProjectViewer or Sessions for example). Is this pretty >>> much the change that you are asking for ? The JLib approach was a >>> good approach as it still provides the user with choice and reduces >>> the number of dependencies between plugins. However, the JLib plugin >>> went nowhere and got very little interest (unfortunately) so we are >>> still in the same position. >>> >>> Cheers >>> Lee >>> ----- Original Message ----- From: Brian Hawkins To: Mariusz >>> Lotko ; jed...@li... Sent: Thursday, June 17, >>> 2004 11:52 PM >>> Subject: Re: [ jEdit-devel ] jEdit plugin integration >>> >>> >>> Oh I understand what the j stands for. Almost 90% of the code I >>> write in jedit is C++ code. And I must say that using ProjectViewer >>> to change between projects (I have at least a dozen) and then using >>> fastopen to open a file in that project and jump to go to where I >>> want in that file ROCKS! Way to go plugin writers! >>> >>> But the addition I'm suggesting is very small. Like I said the >>> get/setProperty API's are already there. All it needs is a little >>> logic underneath to be able to put and get the settings from multiple >>> property files. Maybe a 100 lines of code including the gui stuff. >>> Ok the gui part could push it over 100 lines but not by much more. >>> >>> You talk about the session plugin, there it is again two plugins >>> (session and project viewer) that do a lot of the same thing. Both >>> keep track of a set of files you are working on and let you switch >>> between them. >>> >>> Now wouldn't it be great if someone came up with plugin that would >>> run autobuild or make on your code and the settings for that plugin >>> were saved on a per project/session basis? You switch sessions and >>> hit the compile shortcut and it knows what make to run because it is >>> session specific. >>> >>> Brian >>> >>> Mariusz Lotko wrote: >>> >>> On czw 17. czerwca 2004 23:07, Brian Hawkins wrote: >>> Don't get me wrong I do not want to force the "project" concept on to >>> jedit users who do not use it. It should always be an option. But I >>> think it needs to be a well oiled option that works well. >>> Nice "option" - which has to be install regardless you use it :-/ >>> Anyway - some of jEdit users seem to forget that "j" in the name >>> of this editor stands for language of implementation not the target >>> audience - Java programers. >>> >>> I use jEdit to code in C++ with CodeBrowser, Sessions and some other >>> plugins. ProjectViewer is completely against my way of working. I find >>> this plugin useless, but I don't say it's for everyone - it's just my >>> style >>> of work. >>> >>> Does jEdit has to become yet another IDE forcing certain way of >>> working under >>> project? >>> Or can it remain slim-in-the-beginning, extensible-like-you-want and >>> therefore extremely configurable editor like now? >>> >>> Greetings, >>> >>> ------------------------------------------------------- This SF.Net >>> email is sponsored by The 2004 JavaOne(SM) Conference Learn from the >>> experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, >>> June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER >>> AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- >>> ----------------------------------------------- jEdit Developers' >>> List jEd...@li... >>> https://lists.sourceforge.net/lists/listinfo/jedit-devel >> >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference >> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer >> Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA >> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference > Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer > Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA > REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND |