Re: [JPP-Devel] [ jump-pilot-Bugs-3613274 ] Inconsistencies in plugin enablecheck
On 15.05.2013 16:04, Larry Becker wrote: This is this kind of thing. I'm not sure I fully understand your example though as I cannot see any reason to activate the menu with Attribute View 2 and to deactivate it with Attribute View 1 in SkyJUMP. Clicking the Attribute View belonging to the project and gives that project focus and enables menu items for that project's context. In this case, it is enabling and disabling based on the selection. hmm, actually the simple Attribute Table dialog does not and i think never did 'activate' a project. usually it merely serves as LayerManagerProxy and stuff, so it is a kind taskframe by itself in this regard, just for one layer only. we could of course implement this, not sure it is worth the effort. the problem i see here is, that working with multiple taskframes (projects) and several attribute windows open, it will be increasingly difficult for a user to identify to which taskframe an attribute window belongs to. so wrt to the quote below On 15.05.2013 00:34, Michaël Michaud wrote: On the other hand, when there is no ambiguity and the plugin can get all the information it needs from the dialog box (ex. one project only, and a layer selector in the plugin dialog box), I cannot see any reason to grey it out. i would not activate just because there is no ambiguity. this would be inconsistent, as it is not transparent to the user why a plugin is enabled when editing only one task, but disabled when using more than one. it's easier and more consistent to expect the user to activate the taskframe explicitly. it is important to understand that in the current OJ implementation main toolbar attribute button windows simply represent just one layer of some task, so only plugins that are meant to edit one layer should probably be activated. i'd hesitate to even enable drawing plugins as the user might not actually see the result immediately. but generally, yes of course enable checks often are inconsistent and need lot's of finetuning especially for multi taskframe scenarios, which seem to be sparsely tested to put it mildly. ..ede -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] [ jump-pilot-Bugs-3613274 ] Inconsistencies in plugin enablecheck
Le 15/05/2013 16:04, Larry Becker a écrit : This is this kind of thing. I'm not sure I fully understand your example though as I cannot see any reason to activate the menu with Attribute View 2 and to deactivate it with Attribute View 1 in SkyJUMP. Clicking the Attribute View belonging to the project and gives that project focus and enables menu items for that project's context. In this case, it is enabling and disabling based on the selection. Oh, I missed that you have selected a feature in one project and that Buffer (Multiple Ring) needs a selected feature. Agree that in this case, SkyJUMP has the behaviour I suggest and not OpenJUMP. Moreover, I notice that things would be more clear if the project name was included in the Attribute View title bar. Michaël On Tue, May 14, 2013 at 5:34 PM, Michaël Michaud michael.mich...@free.fr mailto:michael.mich...@free.fr wrote: Hi Larry, I'm going to stand with Michaël on this one. Here is why: In SkyJUMP (and probably JUMP) it behaves this way and it seems natural. I suspect this capability has been lost along the way since OJ has added more sophisticated support for window management and multiple views. Here is how I tested so we can see if I understood exactly what Michaël was going for: 1. I created two new projects, each with one rectangle in one layer. In project 2 I selected the rectangle. 2. I opened an Attribute View for project 1 and project 2 for the one layer in each. 3. With Attribute View 2 as the active window, I went to Tools-Analysis-Buffer (Multiple Ring) For SkyJUMP the menu was active and for OpenJUMP it was not. Make Attribute View 1 active and SkyJUMP greys out the menu - OJ does not change. @Michaël: is this what you meant? This is this kind of thing. I'm not sure I fully understand your example though as I cannot see any reason to activate the menu with Attribute View 2 and to deactivate it with Attribute View 1 in SkyJUMP. In the ticket, I probably mixed several small consistency problems, and to be honest, I noticed several of them on plugins I added. But as you see, the rule to determine when a plugin must be activated is not so obvious. My main point is that a plugin should be deactivated when it cannot get all the information it needs from the context. Ex. if there are two projects opened and none of them is active (ex. the active windows is the output window), there is no way to know in which project you want to work (no plugin except drivers has a combobox to choose the target project). So most plugin should be deactivated (currently, some plugins are still activated). On the other hand, when there is no ambiguity and the plugin can get all the information it needs from the dialog box (ex. one project only, and a layer selector in the plugin dialog box), I cannot see any reason to grey it out. I can see limits to this rule though : if a plugin needs selected features, making it work when the attribute table is active may be misleading as the plugin will work on features selected on the view, not with features selected on the table ! So I can admit that some plugins must be activated when one particular window is active and not the other and that layerview and attribute view must not always be considered as equivalent from the plugin perspective. Hope I could clarify (It has probably not been clear in my mind from the beginning ;-) Michaël regards, Larry On Tue, May 14, 2013 at 3:46 PM, Michaël Michaud michael.mich...@free.fr mailto:michael.mich...@free.fr wrote: Hi, On 14.05.2013 19:54, Michaël Michaud wrote: Le 14/05/2013 10:32, edgar.sol...@web.de mailto:edgar.sol...@web.de a écrit : On 14.05.2013 08:43, SourceForge.net wrote: == Should be activated if no layer is selected but a Attribute table is active Generate Create point layer I think plugins which have a layer chooser in their dialog box should be available every time a the active frame is related to a task including at least one layer. Selected layer, if any, should be proposed first. Don't you think so ? sorry, lost me here.. can you give steps? why should 'Create point layer' be active when an attribute window is active? OK, I realize that what I feeled like something obvious is not... I think that as a user, I have to know in which project I work (it is not the same to create a point in project 1 and to create it in project 2) But I generally don't want to bother about which window is active, if they belong to the same project. Just want to work
Re: [JPP-Devel] [ jump-pilot-Bugs-3613274 ] Inconsistencies in plugin enablecheck
On 15.05.2013 20:13, Michaël Michaud wrote: Moreover, I notice that things would be more clear if the project name was included in the Attribute View title bar. nice idea.. ede -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] [ jump-pilot-Bugs-3613274 ] Inconsistencies in plugin enablecheck
Hi, On 15.05.2013 16:04, Larry Becker wrote: This is this kind of thing. I'm not sure I fully understand your example though as I cannot see any reason to activate the menu with Attribute View 2 and to deactivate it with Attribute View 1 in SkyJUMP. Clicking the Attribute View belonging to the project and gives that project focus and enables menu items for that project's context. In this case, it is enabling and disabling based on the selection. hmm, actually the simple Attribute Table dialog does not and i think never did 'activate' a project. usually it merely serves as LayerManagerProxy and stuff, so it is a kind taskframe by itself in this regard, just for one layer only. we could of course implement this, not sure it is worth the effort. Don't know what 'activate' a project means exactly. I must see the code. I thing it is possible (easy?) to know what is the active frame, and from there, what is the active task if any. the problem i see here is, that working with multiple taskframes (projects) and several attribute windows open, it will be increasingly difficult for a user to identify to which taskframe an attribute window belongs to. so wrt to the quote below See my remark in the previous mail about prefixing attribute table title. Of course, it is not recommended to have many attribute windows belonging to multiple projects opened. On 15.05.2013 00:34, Michaël Michaud wrote: On the other hand, when there is no ambiguity and the plugin can get all the information it needs from the dialog box (ex. one project only, and a layer selector in the plugin dialog box), I cannot see any reason to grey it out. i would not activate just because there is no ambiguity. OK, I should have said I would activate plugins when there is no technical reason to prevent the user from doing what he wants to do (technical reason may be lack of information or ambiguity). this would be inconsistent, as it is not transparent to the user why a plugin is enabled when editing only one task, but disabled when using more than one. it's easier and more consistent to expect the user to activate the taskframe explicitly. It would be transparent as the plugin would be activated every time a window related to a project is active (either a view or a table) and disabled when NO window related to a project is active. it is important to understand that in the current OJ implementation main toolbar attribute button windows simply represent just one layer of some task, so only plugins that are meant to edit one layer should probably be activated. i'd hesitate to even enable drawing plugins as the user might not actually see the result immediately. Plugins may have results more visible in the attribute table (ex attribute calculator) or more visible in the view (ex. buffer), or both, or none of them (a plugin can just write a report). The important thing is the user must know which project/layer he is working on. I agree that the case of plugins working on selection may be ambiguous if available when the attribute table is active. but generally, yes of course enable checks often are inconsistent and need lot's of finetuning especially for multi taskframe scenarios, which seem to be sparsely tested to put it mildly. OK, let's start with plugins which have no reason to behave differently, but we'll have to decide in which direction to move. I'll try to make more specific proposals before changing. Michaël ..ede -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
[JPP-Devel] [ jump-pilot-Bugs-3613274 ] Inconsistencies in plugin enablecheck
Bugs item #3613274, was opened at 2013-05-13 23:43 Message generated for change (Tracker Item Submitted) made by michaudm You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=679906aid=3613274group_id=118054 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General / Other Group: None Status: Open Resolution: None Priority: 3 Private: No Submitted By: michael michaud (michaudm) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistencies in plugin enablecheck Initial Comment: There are many inconsistencies in the enablecheck parameter of plugins. Most of them appear if two projects or more are opened, and/or if an Attribute table is active. One current problem happens if layer B of project B is selected, and Attribute table of layer A of project A is the active frame : most plugins are initialized with layer B, not A. Some suggestions : Save view as... Copy to clipboard Printer == should be deactivated if no task window is active (if a attribute table is active) Analysis == some plugins are activated if no layer is selected and an attribute table is active (ex. buffer, offset) and others are not (union, polygon overlay) : as soon as the plugin offers a layer chooser, it should be active (and propose only layers of the task related to the active window, either a task window or a attribute table) Classify Calculate Layer attribute Layer statistics Feature statistics == Should be activated if no layer is selected but a Attribute table is active Generate Create point layer == Should be activated if a Attribute table is active Edit geometries == Planar graph activation is not similar to other plugins of the submenu Edit attribute == Some of them should be available if a Attribute table is active -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=679906aid=3613274group_id=118054 -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] [ jump-pilot-Bugs-3613274 ] Inconsistencies in plugin enablecheck
On 14.05.2013 08:43, SourceForge.net wrote: == Should be activated if no layer is selected but a Attribute table is active Generate Create point layer why? ..ede -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] [ jump-pilot-Bugs-3613274 ] Inconsistencies in plugin enablecheck
Le 14/05/2013 10:32, edgar.sol...@web.de a écrit : On 14.05.2013 08:43, SourceForge.net wrote: == Should be activated if no layer is selected but a Attribute table is active Generate Create point layer I think plugins which have a layer chooser in their dialog box should be available every time a the active frame is related to a task including at least one layer. Selected layer, if any, should be proposed first. Don't you think so ? Michaël why? ..ede -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] [ jump-pilot-Bugs-3613274 ] Inconsistencies in plugin enablecheck
On 14.05.2013 19:54, Michaël Michaud wrote: Le 14/05/2013 10:32, edgar.sol...@web.de a écrit : On 14.05.2013 08:43, SourceForge.net wrote: == Should be activated if no layer is selected but a Attribute table is active Generate Create point layer I think plugins which have a layer chooser in their dialog box should be available every time a the active frame is related to a task including at least one layer. Selected layer, if any, should be proposed first. Don't you think so ? sorry, lost me here.. can you give steps? why should 'Create point layer' be active when an attribute window is active? the plugin draws in the task frame, hence it should be active only then. ..eDe -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] [ jump-pilot-Bugs-3613274 ] Inconsistencies in plugin enablecheck
Hi, On 14.05.2013 19:54, Michaël Michaud wrote: Le 14/05/2013 10:32, edgar.sol...@web.de a écrit : On 14.05.2013 08:43, SourceForge.net wrote: == Should be activated if no layer is selected but a Attribute table is active Generate Create point layer I think plugins which have a layer chooser in their dialog box should be available every time a the active frame is related to a task including at least one layer. Selected layer, if any, should be proposed first. Don't you think so ? sorry, lost me here.. can you give steps? why should 'Create point layer' be active when an attribute window is active? OK, I realize that what I feeled like something obvious is not... I think that as a user, I have to know in which project I work (it is not the same to create a point in project 1 and to create it in project 2) But I generally don't want to bother about which window is active, if they belong to the same project. Just want to work on my project. The plugin may update the view, the table, both, create a report, etc. It is not related to a particular view of the project. In Create point layer case, my last operation was to check or to edit some coordinates in the attribute table. Now I want to create the points. Why should I have to explain OpenJUMP I don't want to create them in Attribute table but in the view. I just want to create them in my project. I don't want to bother which is the active frame and click the view just to have the menu available. Oh, this may not be a great example, but hope it makes my perspective more clear. the plugin draws in the task frame, hence it should be active only then. Maybe you point a technical issue I did not see. My point is that the user generally does not need to bother which frame is active. In some cases, the soft may need to know of course. Michaël ..eDe -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] [ jump-pilot-Bugs-3613274 ] Inconsistencies in plugin enablecheck
I'm going to stand with Michaël on this one. Here is why: In SkyJUMP (and probably JUMP) it behaves this way and it seems natural. I suspect this capability has been lost along the way since OJ has added more sophisticated support for window management and multiple views. Here is how I tested so we can see if I understood exactly what Michaël was going for: 1. I created two new projects, each with one rectangle in one layer. In project 2 I selected the rectangle. 2. I opened an Attribute View for project 1 and project 2 for the one layer in each. 3. With Attribute View 2 as the active window, I went to Tools-Analysis-Buffer (Multiple Ring) For SkyJUMP the menu was active and for OpenJUMP it was not. Make Attribute View 1 active and SkyJUMP greys out the menu - OJ does not change. @Michaël: is this what you meant? regards, Larry On Tue, May 14, 2013 at 3:46 PM, Michaël Michaud michael.mich...@free.frwrote: Hi, On 14.05.2013 19:54, Michaël Michaud wrote: Le 14/05/2013 10:32, edgar.sol...@web.de a écrit : On 14.05.2013 08:43, SourceForge.net wrote: == Should be activated if no layer is selected but a Attribute table is active Generate Create point layer I think plugins which have a layer chooser in their dialog box should be available every time a the active frame is related to a task including at least one layer. Selected layer, if any, should be proposed first. Don't you think so ? sorry, lost me here.. can you give steps? why should 'Create point layer' be active when an attribute window is active? OK, I realize that what I feeled like something obvious is not... I think that as a user, I have to know in which project I work (it is not the same to create a point in project 1 and to create it in project 2) But I generally don't want to bother about which window is active, if they belong to the same project. Just want to work on my project. The plugin may update the view, the table, both, create a report, etc. It is not related to a particular view of the project. In Create point layer case, my last operation was to check or to edit some coordinates in the attribute table. Now I want to create the points. Why should I have to explain OpenJUMP I don't want to create them in Attribute table but in the view. I just want to create them in my project. I don't want to bother which is the active frame and click the view just to have the menu available. Oh, this may not be a great example, but hope it makes my perspective more clear. the plugin draws in the task frame, hence it should be active only then. Maybe you point a technical issue I did not see. My point is that the user generally does not need to bother which frame is active. In some cases, the soft may need to know of course. Michaël ..eDe -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] [ jump-pilot-Bugs-3613274 ] Inconsistencies in plugin enablecheck
Hi Larry, I'm going to stand with Michaël on this one. Here is why: In SkyJUMP (and probably JUMP) it behaves this way and it seems natural. I suspect this capability has been lost along the way since OJ has added more sophisticated support for window management and multiple views. Here is how I tested so we can see if I understood exactly what Michaël was going for: 1. I created two new projects, each with one rectangle in one layer. In project 2 I selected the rectangle. 2. I opened an Attribute View for project 1 and project 2 for the one layer in each. 3. With Attribute View 2 as the active window, I went to Tools-Analysis-Buffer (Multiple Ring) For SkyJUMP the menu was active and for OpenJUMP it was not. Make Attribute View 1 active and SkyJUMP greys out the menu - OJ does not change. @Michaël: is this what you meant? This is this kind of thing. I'm not sure I fully understand your example though as I cannot see any reason to activate the menu with Attribute View 2 and to deactivate it with Attribute View 1 in SkyJUMP. In the ticket, I probably mixed several small consistency problems, and to be honest, I noticed several of them on plugins I added. But as you see, the rule to determine when a plugin must be activated is not so obvious. My main point is that a plugin should be deactivated when it cannot get all the information it needs from the context. Ex. if there are two projects opened and none of them is active (ex. the active windows is the output window), there is no way to know in which project you want to work (no plugin except drivers has a combobox to choose the target project). So most plugin should be deactivated (currently, some plugins are still activated). On the other hand, when there is no ambiguity and the plugin can get all the information it needs from the dialog box (ex. one project only, and a layer selector in the plugin dialog box), I cannot see any reason to grey it out. I can see limits to this rule though : if a plugin needs selected features, making it work when the attribute table is active may be misleading as the plugin will work on features selected on the view, not with features selected on the table ! So I can admit that some plugins must be activated when one particular window is active and not the other and that layerview and attribute view must not always be considered as equivalent from the plugin perspective. Hope I could clarify (It has probably not been clear in my mind from the beginning ;-) Michaël regards, Larry On Tue, May 14, 2013 at 3:46 PM, Michaël Michaud michael.mich...@free.fr mailto:michael.mich...@free.fr wrote: Hi, On 14.05.2013 19:54, Michaël Michaud wrote: Le 14/05/2013 10:32, edgar.sol...@web.de mailto:edgar.sol...@web.de a écrit : On 14.05.2013 08:43, SourceForge.net wrote: == Should be activated if no layer is selected but a Attribute table is active Generate Create point layer I think plugins which have a layer chooser in their dialog box should be available every time a the active frame is related to a task including at least one layer. Selected layer, if any, should be proposed first. Don't you think so ? sorry, lost me here.. can you give steps? why should 'Create point layer' be active when an attribute window is active? OK, I realize that what I feeled like something obvious is not... I think that as a user, I have to know in which project I work (it is not the same to create a point in project 1 and to create it in project 2) But I generally don't want to bother about which window is active, if they belong to the same project. Just want to work on my project. The plugin may update the view, the table, both, create a report, etc. It is not related to a particular view of the project. In Create point layer case, my last operation was to check or to edit some coordinates in the attribute table. Now I want to create the points. Why should I have to explain OpenJUMP I don't want to create them in Attribute table but in the view. I just want to create them in my project. I don't want to bother which is the active frame and click the view just to have the menu available. Oh, this may not be a great example, but hope it makes my perspective more clear. the plugin draws in the task frame, hence it should be active only then. Maybe you point a technical issue I did not see. My point is that the user generally does not need to bother which frame is active. In some cases, the soft may need to know of course. Michaël ..eDe -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential
