Respected Sir, I am currently working on openjump topological plugin. i would be thankful if you enlighten me by answering few doubts.:-
1. Why microsegments are removed, what if they are not removed from the data. 2. The following text is from the topology tutorial " The algorithm chooses those segment to be removed from the linestring or polygon if the deformation is minimum and will never removes the micro-segments if it is located on the geometry boundary and if both segments are strictly inside the linestring, But it removes the segment in case interior angle is the closest to flat angle (180°)." 3. How to handle if the vertex removed by algorithm is used by other geometry. i.e what can be enforced on to it. On Thu, Oct 16, 2014 at 1:06 AM, <edgar.sol...@web.de> wrote: > On 12.10.2014 12:31, Michael Michaud wrote: > > Hi Ede, > >> On 09.10.2014 22:33, Michael Michaud wrote: > >>> Hi, > >>>>>>> Macro recording an action on a selected layer : > >>>>>>> > >>>>>>> There is an interesting question about plugins executed on a > selected layer > >>>>>>> or category (some are dialogless like delete or copy/paste) > >>>>>>> User starts a macro, delete selected layer A and stop the macro. > >>>>>>> What is the expected behaviour when the macro is run again ? > >>>>>>> - should it delete the selected layer (whatever its name is) > >>>>>>> - or should it delete layer A, regardless of whether it is > selected or not. > >>>>>>> > >>>>>>> Use cases are welcome to try to define a behaviour both consistent > >>>>>>> and useful. > >>>>>> as the plugin works with selected layers i'd expect the recorded > plugin to work on a selected layer as well. this, of course, raises the > question how to control selection during macro playing. > >>>>> Just thinking aloud about this problem... > >>>>> A solution could be > >>>>> - record the layer name (more information in the layer name than in > >>>>> "selected layer" option > >>>>> - choose named layer or selected layer (interactive mode) at > execution > >>>>> time as a global option of the macro > >>>>> if interactive mode is chosen for each parameter named > "LayerName" > >>>>> (or any other convention) open a > >>>>> MultiInputDialog to make the user choose the layer > >>>> i work a lot with a music software professionally. this one and sound > editors in general usually have an interface for plugins and these plugins > have usually the possibility to save/load preferences of parameters you > want to reuse. > >>>> bearing this in mind, if you would now extend MultiInputDialog > >>>> - GUI with a save/load function for parameters > >>>> - a method call like we do for undoability > >>>> > context.getLayerManager().getUndoableEditReceiver().reportNothingToUndoYet(); > >>>> something along the lines of * > >>>> > context.getLayerManager().getMacroReceiver().saveProfile("mySettings"); > >>>> to save the used profile or none **. > >>>> and the plugins with > >>>> - a method e.g. "execute(String 'profile')" to run them > programmatically with a given profile > >>>> you could reuse this in your macro routines. another useful side > effect would be that users were able to rerun plugins and load saved > parameter sets sort of an half automation. in any way it has be up to the > plugin to save/restore parameters as our current API does not have the > capabilities to do that from outside the plugin. > >>>> > >>>> just an idea.. ede > >>> OK, I'm not sure I understand your proposition very well , but it does > >>> not seem to be too far from what I've started. > >>> Here after, I try to compare your ideas (what I understood) with what > >>> I've already done (did you have a look ?). > >>> > >>> One of the main point is to be able to serialize a set of parameters > >>> associated with a plugin. > >>> Seems that's what you call a 'profile' > >>> To make it as simple as possible, this is the role of my interface > >>> "Recordable" which has currently a unique > >>> setParameters(Map<String,Object> map) method. > >>> To serialize the map, I rely on java2xml (my idea is to reuse things > >>> like style serialization) > >> i don't like the interface pretty much. as the parameters are plugin > specific and can change between versions of the plugin i'd rather have the > plugin save/load them. as the plugin GUI can be anything, not all plugins > use MultiInputDialog, the essential code should be in the plugin to handle > this. > > My goal is to have a model where parameters are "less" specific ! > > what do you mean? they will always be very specific to the plugin that > needs them. > > > This way, the serialization/deserialization of parameters is made global > > (implemented in AbstractPlugIn > > only). It is absolutely independant from the use of MultiInputDialog. > > Note that in this model, the plugin > > save/load its parameters, but through a unified interface implemented in > > AbstractPlugIn only. > > i'd again say. the wrong place. an abstract class implements methods of > the implemented interface with a default behaviour for developers to lean > on and save effort this way. i don't see a default way to handle plugin > parameters. > > what i could imagine is that you define a serialization interface for gui > components to implement. if a plugin uses a gui component that implements > this you could then add an interface to the plugin that registers the main > gui component which can then be asked for it's values. > > > I cannot see the advantage of keeping serialization logic in each > > individual plugin. > > 1. the advantage being that you don't have to worry about values at all, > but only having the name of a profile to deal with. > 2. no backward compatibility problems e.g. pluginauthor changes the name > of a parameter internally > 3. added value of profiles that users can reuse apart from macro framework > > > Maybe I missed your point > >> agreed, java2xml is a perfect choice to save settings. > >> > >>> Now plugins must be able > >>> - to setParameters from a MultiInputDialog > >>> - to execute() from this map of parameters (your execute(String > >>> 'profile') ?) > >>> That's where a big refactoring is needed for all plugins. Do your > >>> proposition can avoid this refactoring in any way ? > >> i thought hard about this. but _No_, i see no way for interactive > plugins to achieve reusable parameters without a plugin API change. not a > very big deal, we can easily add an interface like the ones i already added > (see AbstractPlugIn implements PlugIn, ShortcutEnabled, EnableChecked, > Iconified). > >> > >> this "enhanced" plugin would then be treated differently than our old > plugins. > > The general idea does not seem much different from my AbstractPlugIn > > implementing new Recordable interface > > to make parameters (Map) serializable. > > Let me know what would be your interface... > > for a start the Recordable interface would need an additional > getParameters() method. this would allow to get the parameters when/after > running the plugin to save from outside. > > but instead of this current approach i'd rather have the plugin return a > ParameterSet object, which could be the GUI component enhanced by a > ParameterSet interface. from an object oriented standpoint the GUI is the > parameter set, initially empty or with default values, later on customized. > how this is implemented internally i leave aside for now in favor of the > bigger picture. > > >> > >>> Check the new BufferPlugIn and tell if you have ideas to avoid this big > >>> refactoring... > >>> After this refactoring, you can use plugins > >>> - interactively getDialog() {setParameters()} -> execute() or > >>> - in macro mode setParameters()/execute() > >> what exactly do you wnat me to check in BufferPlugIn ? > > Just an example to progress in a concrete way in the discussion. In this > > example, you can see > > how I used Recordable interface implemented in AbstractPlugIn to be abe > > to persist the state > > of the plugin in a macro. > > If you see better ways to make plugins recordable may be you can explain > > on this example so > > that I can understand clearly your objections. > > maybe later. how plugins deal with it internally can be organized after we > agreed a interface model. > > >>> I did not understand your example with getMacroReceiver, but maybe it's > >>> an alternative to my implementation > >> yes, but in a design that is already implemented and proven working. > undoability has the same issue of trying to add functionality that was > obviously not implemented in the plugin API during design stage. > > OK, I'm quite sure your point is interesting, but I don't understand yet > > fully how I can take advantage of it. > > Let me some time to study the code, or if you have a simple schema to > > illustrate how you would implement > > it... > > it's just a hint on how the original JUMP authors added an initially not > planned feature > > >> > >>> of StartMacro/StopMacro/RunMacroPlugIn : > >>> - I put 2 objects in the workben blackboard* : a "MacroStarted" flag > and > >>> a "Macro" (a List<Recordable>) > >>> - when a plugin is executed, before exiting, it checks if a macro is > >>> being recorded (flag is on). > >>> If the macro recorder is on, the plugin is added to the > List<Recordable> > >> ok, that's wrong: why would plugins register themselves? you'll have to > touch each and every plugin. > > Ya, you're probably right. I don't know why I thought that the macro > > recording should take before one exit > > the execute or the run method. I'll reconsider this point. > > actually i see that you would need a static (only one instance in OJ) > macro recorder plugin that holds the status it is in. no need for the > blackboard here. > > >> i can see you added it to AbstractPlugin and into some plugin's > execute() method. don't do that. > >> > >> more legacy compatible and elegant is a listener implemented in your > MacroPlugin that can be registered in all the various places where plugins > are started. > > OK. Why not in the same listener executing plugins and already > > implemented in AbstractPlugIn ? > > because AbstractPlugIn does not execute plugins. it is one or base for > lot's of them itself. it get's executed! > or what do you mean? > > >> > >>> * I think macro can be application wide (ex. create a new task...) > >> why not. > >> > >>>> * you will of course have to hack and register a MacroReceiver class > capable for this that detects that a recording is running and saves the > profile setting accordingly. > >>> Detecting that the macro is recording does not seem a big deal. Saving > >>> the profile is ! > >> nope, it's not just about "Detecting that the macro is recording".. a > clean reusable approach is needed here and i feel you went head on into > hacking without enough planning. i'd suggest we go back to a design stage > and come back with a better approach then. maybe we could implemet this > feature together. that'd be a first. > > I've no problem with that. I'm not in a hurry > > that's good :) > > >and I'm open to any > > suggestion to improve the esign. > > Just need to tell you a bit more about longer-term goal I have in mind > > (see the end of the mail). > > let's see.. > > >> > >>>> ** (none would signal that the gui has to be shown on every macro run > for the user to interactively input parameters, which would be legacy > compatible for our old plugins.) > >>> I see. Seems compatible with what I've started. I'll add the piece of > >>> code to run legacy plugin in interactive mode soon so that we can > >>> discuss this point more concretely as my implementation seems different > >>> from your line of code. > >> you added it to AbstractPlugin, where my contra arguments from above > apply plus.. not every plugin is extended from AbstractPlugin. it is simply > the wrong place to "record" plugin execution. > > OK, what would be the good place ? > > for one probably the wrapper that is used to make plugins into gui > elements. we could add a call to MacroRecorder there, which only adds if > execute() returns true. > > >> > >>>> for GUI-less plugins (e.g. Copy/Cut/Paste ...) this would mean that > we need to hack interactive versions of them and add a GUI to them which is > shown during macro recording. for example - a new > InteractiveCopySelectedItemsPlugIn replaces the old CopySelectedItemsPlugIn > but wraps it and shows a gui when macro recording is on for users to > specify a name or regex or just use the currently selected layers. > >>> In my schema, we have only one plugin, but 2 execution modes (with or > >>> without dialog). PlugIn is always recorded with the layername > parameter, > >>> but if executed in interactive mode, the layer or regex is asked to the > >>> user and replaces the recorded name on the fly. > >> you didn't implement that so far? or did i overlook that? > > No, just started on my loca machine, nothing committed. > > simply wrapping/extending the old plugin would allow to keep more of old, > proven working code. > > >> generally i agree, that's my idea to - for automation we would need a > new selection plugin that selects by given parameters, hence imitates what > a user does in the GUI programmatically. > >> but.. if it shows a dialog or works with a saved parameter set should > be up to the user, like with the other plugins. > >> > >>>> do you catch my drift?.. ede > >>> More or less. I'll go on with my implementation, and you'll tell me how > >>> compatible > >>> it is with you vision and how it can be improved. > >> as i wrote above, let's take a step back and review the design and > develop some proper workflows we want to realize. i see some major problems > here, which makes it especially important to plan strategically and design > healthy. > >> > >> major problems from my side (just a quick list): > >> 1. legacy compatibility (disable for old plugins or make it so they > magically work, is that even possible?) > > In the order, i'd love legacy plugins > > - magically work (don't think it is possible without refactoring) > > i am not sure all is lost on that front. i'd really like to reuse plugins > as they are. or in other words - if we cannot realize that, nobody will > rework all our plugins. that's not going to happen with the manpower we > currently have. and even if i would strongly oppose as this is a surefire > way to introduce bugs over bugs. > > > - work in interactive mode (as it works today) even when started from a > > macro (my second implementation after discusison with you - did not test > > much though) > > - be deactivated if started from a macro (my first implemenation) > > you mean be deactivated if recording is active, so they cannot even be > added to a macro? > > >> 2. legacy compatibility 2, how to design a possibility to load/save > parameters that > >> - is easily implementable by every plugin > >> - does not interrupt current functionality > >> - should this maybe go in a general PluginV2 interface development, > where we redesign the plugin framework even more generally wrt. a future > with a plugin manager that does download plugins from a repository. > > Let me understand clearly what this new interface could improve compared > > with the simple "Recordable" interface I currently added. > > I understood there is a flaw in my design about how the system should > > listen to plugin execution for macro recording. > > I did not understand yet why "Recordable" interface could not fit the > > need to persist any Recordable action (including plugin execution). > > dunno what you mean. mainly the point is about, we are touching plugin API > so we should just keep in mind not to build in obstructions for later. > > also let's not cling to fixed interfaces right now. let's assume we need > to make plugins recordable and let's design it from top to bottom, fro mthe > big into the small, object oriented ;) > > > > > PlugIn manager would be a great feature to add. We must just keep in > > mind that we have not much resources > > and that by starting several big features depending on each others, we > > take risks to achieve none of them. > > right! that's why i started "small" with moving plugins into the xml file > and creating a unified way to install them. one step towards > adding/removing them programmatically. > > >> 3. what about cursortools, data loading and such. can the design > include them properly? > > My design already includes dataloading (hence my fix in > > DataSourceFileLayerLoader). It is not very clean in the sense that > > I've to test if recordable are plugins or loader at execution time. > > yeah, my main objection again. not very clean. there _must_ be a clean > interface for automating plugins. so if we want to automate e.g. > OpenFilePlugin, we should use the same technique as for the other plugins! > > > Did not think about cursor tools yet :-( > > right ;).. let's put the aside and say we disable them. after all they are > a very special very interactive case, maybe it doesn't even make sense to > automate them? > > >> 4. should we really save macros to text file? why not simply keeping it > in OJ state for a start? > > I think it is important to be able to save macros in files. > > why? > > >We do not > > have to implement all the stuff right now, > > but I think that persistence is important to have in mind (I tried to > > persist SchemaViewer in a macro, and it > > was a difficult but interesting challenge) > > the only reason for external files i see would be to exchange them with > other OJ instances/users. but if you really wanna do so you will have to > make sure that they are compatible with each other, so you would have to go > the extra mile and version them etc. > i simply don't see the need for that. > > >> > >> as Stephan would say .. just my 2 cents ;).. ede > > Thanks, and here is a bit more context about what I've in mind with > > these new features : > > > > My first idea was to implement a modeler able to define a complex > > process made of > > inputs, processes and outputs organized in a graph (we already have one > > in Sextante). > > To start, the process definition could be defined in a xml file, then in > > a GUI. > > Then I realized that a macro recorder could be a first step with some > > differences : > > + take advantage of all the processes already defined through OpenJUMP UI > > - macro-recorder is GUI dependant > > When I started to think of a model for a process modeler, I get an > > interface with "input > > specification", "output specification" and "parameters", the later > > defined as a Map<String,Object>. > > For macro recording, I started from this point, considered that > > input/output specifications were > > not needed (already constrained by UI), and keep only the core concept : > > a parameters map. > > > > Maybe I'll come back to this idea of a modeler, so I keep in mind that > > for each plugin, ideally, > > I would like to have a low level gui-independant definition of the > > process. The plugin should > > call this process with parameters issued from the GUI. > > > > ok, i see where you come from. and i see the discrepancy here. plugins > simply are a mere way to add functionality to OJ GUI.. that's what they > were designed for. > > if you wanna model processes you will probably have to introduce something > below plugins. maybe an object called Process, that has some kind of > reflection, in a way, so that you can ask it for parameters it needs, can > serialize it and of course run it under the hood and it does whatever it is > designed to do. > > ..ede > > > ------------------------------------------------------------------------------ > Comprehensive Server Monitoring with Site24x7. > Monitor 10 servers for $9/Month. > Get alerted through email, SMS, voice calls or mobile push notifications. > Take corrective actions from your mobile device. > http://p.sf.net/sfu/Zoho > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > -- Er. Sukhjit Singh Sehra Assistant Professor Dept of Computer Science Engg. Guru Nanak Dev Engineering College, Ludhiana, Punjab Mobile No:- 09855959200 *In your free time kindly visit Sikh-relics.com - A Gallery of Blessed Relics of Sikh Guru Sahib
------------------------------------------------------------------------------
_______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel