Re: [JPP-Devel] Design of File Load Dialog (was strings for pan synchronization options are gone
On 18.10.2011 00:31, Stefan Steiniger wrote: well.. in terms of priority. I installed a new MacOSX over the weekend and the Style dialog bug is gone now. However, one can still not save Datasets with Save Dataset As... without overwriting an existing file - since no new name can be written. ..sadly... i will take care of that some time soon... however i strongly feel if we tackle this we should streamline the open/save dialogs into one version, meaning: - merge load dataset into OpenFileWizard - rework save Dataset to reuse OpenFileWizards FileChooserPanel or better setup a SaveFileWizard? ..ede stefan On 17/10/2011 2:46 PM, Michaël Michaud wrote: Hi Ede, There are several strata of development : - The original open/save dialog from vivid with a clear separation between format and extension, as explained by Martin. - The addition of several datasource access plugins (wms, databases, images...) - The new Open Datasource framework which tried to uniformise datasource access I think that it has been a user choice to keep the old open file dialog somewhere (actually, category right-click context menu) And maybe a design choice (or limitation) to rework the open dialog, and not the save dialog. Would probably worth merging some parts at some point. I would not put high priority on this task, but if you have a clear idea about where to go to simplify without loosing capability. Michaël Le 17/10/2011 20:26, edgar.sol...@web.de a écrit : why do we have several file dialogues anyway? shouldn't we strive to merge them into one only? ..ede On 15.10.2011 21:15, Sunburned Surveyor wrote: The last suggestion by Martin Davis makes sense to me. Landon On Fri, Oct 14, 2011 at 8:39 PM, Martin Davismtncl...@telus.net wrote: So is the behaviour: - if Filter By Extension is unchecked, then the user can select any file and any format - if Filter By Extension is checked, then the user selects a file and the format is determined from the extension ? Would an even simpler alternative be to determine the format from the extension, where this is unabiguous, and if it is ambiguous or undetermined then let the user choose the desired format? So examples are: - if a .SHP file is chosen, the format is set to Shapefile automatically. - if a .ZIP or .XML file is chosen, the user must choose the appropriate format So there is only one dropdown for Format, and then the checkbox On 10/14/2011 12:59 AM, edgar.sol...@web.de wrote: On 10/13/2011 2:24 AM, edgar.sol...@web.de wrote: On 13.10.2011 01:02, Martin Davis wrote: One reason for having the double choice of both format and file name is that there are formats (such as GML) which don't have a standard file extension that can be used to drive the choice of format. Also, in JUMP originally we supported a zipped shapefile concept. It had the extension .zip, but was read by the Shapefile driver. One thing that could be do would be to use the file extension to drive the initial format setting, but allow it to be overridden for files with non-specific extensions. How about a checkbox 'filter by extension', which can be disabled allowing to select any file with any selection in the format dropdown? Ok, but I'm not sure how this solves the problem of determining the format of a file with an unknown extension? there is no determination. but, it allows users to assign a format of their choice to a file of their choice and try to open it. seen? ede -- 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1410 / Virus Database: 1522/3949 - Release Date: 10/13/11 -- 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- All the data continuously generated in your IT infrastructure contains a definitive record of
Re: [JPP-Devel] Design of File Load Dialog (was strings for pan synchronization options are gone
On 17.10.2011 22:46, Michaël Michaud wrote: Hi, Would an even simpler alternative be to determine the format from the extension, where this is unabiguous, and if it is ambiguous or undetermined then let the user choose the desired format? I think such a mechanism exist in the new OpenDialog Framework. If I'm correct, the double combobox currently appears 1) in the old openfile dialog (category context menu) 2) in the save as dialog box i could only find them there too I'm not sure the first one is still needed (but I think users had choosen to keep it when we migrated to the new framework) even so, we currently have two ways to open files. how to explain that to new users? better to have one only. I thing the double dialog is of no use in the save as dialog box where combinations of format and extension can be defined in a single combobox. Zip could be a general option however (a checkbox) i wouldn't say no use, but it is counter-intuitive. it would be easy to merge the options into one dropdwon only without a loss in capabilities. So examples are: - if a .SHP file is chosen, the format is set to Shapefile automatically. - if a .ZIP or .XML file is chosen, the user must choose the appropriate format for save i'd rather have ESRI (*.shp) ESRI Compressed (*.zip) GML (*.gml) GML Compressed (*.zip) ... or ESRI (*.shp) GML (*.gml) ... and a checkbox that signals zipping enabled And even zip files could be automatically opened as long as they contain unambiguous formats. zip and tgz (i think) when opened with OpenFileWizard are automatically scanned for files with known extensions and opened with the appropriate factory. My 2 cents make it 4, ede Michaël So there is only one dropdown for Format, and then the checkbox On 10/14/2011 12:59 AM, edgar.sol...@web.de wrote: On 10/13/2011 2:24 AM, edgar.sol...@web.de wrote: On 13.10.2011 01:02, Martin Davis wrote: One reason for having the double choice of both format and file name is that there are formats (such as GML) which don't have a standard file extension that can be used to drive the choice of format. Also, in JUMP originally we supported a zipped shapefile concept. It had the extension .zip, but was read by the Shapefile driver. One thing that could be do would be to use the file extension to drive the initial format setting, but allow it to be overridden for files with non-specific extensions. How about a checkbox 'filter by extension', which can be disabled allowing to select any file with any selection in the format dropdown? Ok, but I'm not sure how this solves the problem of determining the format of a file with an unknown extension? there is no determination. but, it allows users to assign a format of their choice to a file of their choice and try to open it. seen? ede -- 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1410 / Virus Database: 1522/3949 - Release Date: 10/13/11 -- 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- 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
Re: [JPP-Devel] Design of File Load Dialog (was strings for pan synchronization options are gone
How would you do the saving into GML with the three native dialects we have (JUMP GML, GML 2.0 with hand written template, and FME GML) or possibly with the fourth GML 2.0 variant if deejump plugin is installed? If there would be one line on the list for each alternative then the zip check box would be better, otherwise we would need totally six or eight lines for GML save formats. -Jukka- edgar.soldin wrote: On 17.10.2011 22:46, Michaël Michaud wrote: Hi, Would an even simpler alternative be to determine the format from the extension, where this is unabiguous, and if it is ambiguous or undetermined then let the user choose the desired format? I think such a mechanism exist in the new OpenDialog Framework. If I'm correct, the double combobox currently appears 1) in the old openfile dialog (category context menu) 2) in the save as dialog box i could only find them there too I'm not sure the first one is still needed (but I think users had choosen to keep it when we migrated to the new framework) even so, we currently have two ways to open files. how to explain that to new users? better to have one only. I thing the double dialog is of no use in the save as dialog box where combinations of format and extension can be defined in a single combobox. Zip could be a general option however (a checkbox) i wouldn't say no use, but it is counter-intuitive. it would be easy to merge the options into one dropdwon only without a loss in capabilities. So examples are: - if a .SHP file is chosen, the format is set to Shapefile automatically. - if a .ZIP or .XML file is chosen, the user must choose the appropriate format for save i'd rather have ESRI (*.shp) ESRI Compressed (*.zip) GML (*.gml) GML Compressed (*.zip) ... or ESRI (*.shp) GML (*.gml) ... and a checkbox that signals zipping enabled And even zip files could be automatically opened as long as they contain unambiguous formats. zip and tgz (i think) when opened with OpenFileWizard are automatically scanned for files with known extensions and opened with the appropriate factory. My 2 cents make it 4, ede Michaël So there is only one dropdown for Format, and then the checkbox On 10/14/2011 12:59 AM, edgar.sol...@web.de wrote: On 10/13/2011 2:24 AM, edgar.sol...@web.de wrote: On 13.10.2011 01:02, Martin Davis wrote: One reason for having the double choice of both format and file name is that there are formats (such as GML) which don't have a standard file extension that can be used to drive the choice of format. Also, in JUMP originally we supported a zipped shapefile concept. It had the extension .zip, but was read by the Shapefile driver. One thing that could be do would be to use the file extension to drive the initial format setting, but allow it to be overridden for files with non-specific extensions. How about a checkbox 'filter by extension', which can be disabled allowing to select any file with any selection in the format dropdown? Ok, but I'm not sure how this solves the problem of determining the format of a file with an unknown extension? there is no determination. but, it allows users to assign a format of their choice to a file of their choice and try to open it. seen? ede -- 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1410 / Virus Database: 1522/3949 - Release Date: 10/13/11 -- 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and
Re: [JPP-Devel] Design of File Load Dialog (was strings for pan synchronization options are gone
yes, each would get a separate entry, that's what i meant. i am also in favor of the checkbox, although i have no clue how to integrate it in the filechooser, which seems to be a readymade java api component. ..ede On 18.10.2011 14:08, Rahkonen Jukka wrote: How would you do the saving into GML with the three native dialects we have (JUMP GML, GML 2.0 with hand written template, and FME GML) or possibly with the fourth GML 2.0 variant if deejump plugin is installed? If there would be one line on the list for each alternative then the zip check box would be better, otherwise we would need totally six or eight lines for GML save formats. -Jukka- edgar.soldin wrote: On 17.10.2011 22:46, Michaël Michaud wrote: Hi, Would an even simpler alternative be to determine the format from the extension, where this is unabiguous, and if it is ambiguous or undetermined then let the user choose the desired format? I think such a mechanism exist in the new OpenDialog Framework. If I'm correct, the double combobox currently appears 1) in the old openfile dialog (category context menu) 2) in the save as dialog box i could only find them there too I'm not sure the first one is still needed (but I think users had choosen to keep it when we migrated to the new framework) even so, we currently have two ways to open files. how to explain that to new users? better to have one only. I thing the double dialog is of no use in the save as dialog box where combinations of format and extension can be defined in a single combobox. Zip could be a general option however (a checkbox) i wouldn't say no use, but it is counter-intuitive. it would be easy to merge the options into one dropdwon only without a loss in capabilities. So examples are: - if a .SHP file is chosen, the format is set to Shapefile automatically. - if a .ZIP or .XML file is chosen, the user must choose the appropriate format for save i'd rather have ESRI (*.shp) ESRI Compressed (*.zip) GML (*.gml) GML Compressed (*.zip) ... or ESRI (*.shp) GML (*.gml) ... and a checkbox that signals zipping enabled And even zip files could be automatically opened as long as they contain unambiguous formats. zip and tgz (i think) when opened with OpenFileWizard are automatically scanned for files with known extensions and opened with the appropriate factory. My 2 cents make it 4, ede Michaël So there is only one dropdown for Format, and then the checkbox On 10/14/2011 12:59 AM, edgar.sol...@web.de wrote: On 10/13/2011 2:24 AM, edgar.sol...@web.de wrote: On 13.10.2011 01:02, Martin Davis wrote: One reason for having the double choice of both format and file name is that there are formats (such as GML) which don't have a standard file extension that can be used to drive the choice of format. Also, in JUMP originally we supported a zipped shapefile concept. It had the extension .zip, but was read by the Shapefile driver. One thing that could be do would be to use the file extension to drive the initial format setting, but allow it to be overridden for files with non-specific extensions. How about a checkbox 'filter by extension', which can be disabled allowing to select any file with any selection in the format dropdown? Ok, but I'm not sure how this solves the problem of determining the format of a file with an unknown extension? there is no determination. but, it allows users to assign a format of their choice to a file of their choice and try to open it. seen? ede -- 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1410 / Virus Database: 1522/3949 - Release Date: 10/13/11 -- 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- All the data
Re: [JPP-Devel] Design of File Load Dialog (was strings for pan synchronization options are gone
I think having lots of alternatives is ok... In one app I use (PaintShopPro) there are literally dozens of format options presented in the save dropdown. Martin On 10/18/2011 5:08 AM, Rahkonen Jukka wrote: How would you do the saving into GML with the three native dialects we have (JUMP GML, GML 2.0 with hand written template, and FME GML) or possibly with the fourth GML 2.0 variant if deejump plugin is installed? If there would be one line on the list for each alternative then the zip check box would be better, otherwise we would need totally six or eight lines for GML save formats. -Jukka- edgar.soldin wrote: On 17.10.2011 22:46, Michaël Michaud wrote: Hi, Would an even simpler alternative be to determine the format from the extension, where this is unabiguous, and if it is ambiguous or undetermined then let the user choose the desired format? I think such a mechanism exist in the new OpenDialog Framework. If I'm correct, the double combobox currently appears 1) in the old openfile dialog (category context menu) 2) in the save as dialog box i could only find them there too I'm not sure the first one is still needed (but I think users had choosen to keep it when we migrated to the new framework) even so, we currently have two ways to open files. how to explain that to new users? better to have one only. I thing the double dialog is of no use in the save as dialog box where combinations of format and extension can be defined in a single combobox. Zip could be a general option however (a checkbox) i wouldn't say no use, but it is counter-intuitive. it would be easy to merge the options into one dropdwon only without a loss in capabilities. So examples are: - if a .SHP file is chosen, the format is set to Shapefile automatically. - if a .ZIP or .XML file is chosen, the user must choose the appropriate format for save i'd rather have ESRI (*.shp) ESRI Compressed (*.zip) GML (*.gml) GML Compressed (*.zip) ... or ESRI (*.shp) GML (*.gml) ... and a checkbox that signals zipping enabled And even zip files could be automatically opened as long as they contain unambiguous formats. zip and tgz (i think) when opened with OpenFileWizard are automatically scanned for files with known extensions and opened with the appropriate factory. My 2 cents make it 4, ede Michaël So there is only one dropdown for Format, and then the checkbox On 10/14/2011 12:59 AM, edgar.sol...@web.de wrote: On 10/13/2011 2:24 AM, edgar.sol...@web.de wrote: On 13.10.2011 01:02, Martin Davis wrote: One reason for having the double choice of both format and file name is that there are formats (such as GML) which don't have a standard file extension that can be used to drive the choice of format. Also, in JUMP originally we supported a zipped shapefile concept. It had the extension .zip, but was read by the Shapefile driver. One thing that could be do would be to use the file extension to drive the initial format setting, but allow it to be overridden for files with non-specific extensions. How about a checkbox 'filter by extension', which can be disabled allowing to select any file with any selection in the format dropdown? Ok, but I'm not sure how this solves the problem of determining the format of a file with an unknown extension? there is no determination. but, it allows users to assign a format of their choice to a file of their choice and try to open it. seen? ede -- 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1410 / Virus Database: 1522/3949 - Release Date: 10/13/11 -- 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- All the data continuously generated in your IT infrastructure contains a definitive record of customers,
Re: [JPP-Devel] Design of File Load Dialog (was strings for pan synchronization options are gone
why do we have several file dialogues anyway? shouldn't we strive to merge them into one only? ..ede On 15.10.2011 21:15, Sunburned Surveyor wrote: The last suggestion by Martin Davis makes sense to me. Landon On Fri, Oct 14, 2011 at 8:39 PM, Martin Davis mtncl...@telus.net wrote: So is the behaviour: - if Filter By Extension is unchecked, then the user can select any file and any format - if Filter By Extension is checked, then the user selects a file and the format is determined from the extension ? Would an even simpler alternative be to determine the format from the extension, where this is unabiguous, and if it is ambiguous or undetermined then let the user choose the desired format? So examples are: - if a .SHP file is chosen, the format is set to Shapefile automatically. - if a .ZIP or .XML file is chosen, the user must choose the appropriate format So there is only one dropdown for Format, and then the checkbox On 10/14/2011 12:59 AM, edgar.sol...@web.de wrote: On 10/13/2011 2:24 AM, edgar.sol...@web.de wrote: On 13.10.2011 01:02, Martin Davis wrote: One reason for having the double choice of both format and file name is that there are formats (such as GML) which don't have a standard file extension that can be used to drive the choice of format. Also, in JUMP originally we supported a zipped shapefile concept. It had the extension .zip, but was read by the Shapefile driver. One thing that could be do would be to use the file extension to drive the initial format setting, but allow it to be overridden for files with non-specific extensions. How about a checkbox 'filter by extension', which can be disabled allowing to select any file with any selection in the format dropdown? Ok, but I'm not sure how this solves the problem of determining the format of a file with an unknown extension? there is no determination. but, it allows users to assign a format of their choice to a file of their choice and try to open it. seen? ede -- 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1410 / Virus Database: 1522/3949 - Release Date: 10/13/11 -- 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Design of File Load Dialog (was strings for pan synchronization options are gone
well.. in terms of priority. I installed a new MacOSX over the weekend and the Style dialog bug is gone now. However, one can still not save Datasets with Save Dataset As... without overwriting an existing file - since no new name can be written. ..sadly... stefan On 17/10/2011 2:46 PM, Michaël Michaud wrote: Hi Ede, There are several strata of development : - The original open/save dialog from vivid with a clear separation between format and extension, as explained by Martin. - The addition of several datasource access plugins (wms, databases, images...) - The new Open Datasource framework which tried to uniformise datasource access I think that it has been a user choice to keep the old open file dialog somewhere (actually, category right-click context menu) And maybe a design choice (or limitation) to rework the open dialog, and not the save dialog. Would probably worth merging some parts at some point. I would not put high priority on this task, but if you have a clear idea about where to go to simplify without loosing capability. Michaël Le 17/10/2011 20:26, edgar.sol...@web.de a écrit : why do we have several file dialogues anyway? shouldn't we strive to merge them into one only? ..ede On 15.10.2011 21:15, Sunburned Surveyor wrote: The last suggestion by Martin Davis makes sense to me. Landon On Fri, Oct 14, 2011 at 8:39 PM, Martin Davismtncl...@telus.net wrote: So is the behaviour: - if Filter By Extension is unchecked, then the user can select any file and any format - if Filter By Extension is checked, then the user selects a file and the format is determined from the extension ? Would an even simpler alternative be to determine the format from the extension, where this is unabiguous, and if it is ambiguous or undetermined then let the user choose the desired format? So examples are: - if a .SHP file is chosen, the format is set to Shapefile automatically. - if a .ZIP or .XML file is chosen, the user must choose the appropriate format So there is only one dropdown for Format, and then the checkbox On 10/14/2011 12:59 AM, edgar.sol...@web.de wrote: On 10/13/2011 2:24 AM, edgar.sol...@web.de wrote: On 13.10.2011 01:02, Martin Davis wrote: One reason for having the double choice of both format and file name is that there are formats (such as GML) which don't have a standard file extension that can be used to drive the choice of format. Also, in JUMP originally we supported a zipped shapefile concept. It had the extension .zip, but was read by the Shapefile driver. One thing that could be do would be to use the file extension to drive the initial format setting, but allow it to be overridden for files with non-specific extensions. How about a checkbox 'filter by extension', which can be disabled allowing to select any file with any selection in the format dropdown? Ok, but I'm not sure how this solves the problem of determining the format of a file with an unknown extension? there is no determination. but, it allows users to assign a format of their choice to a file of their choice and try to open it. seen? ede -- 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1410 / Virus Database: 1522/3949 - Release Date: 10/13/11 -- 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net
Re: [JPP-Devel] Design of File Load Dialog (was strings for pan synchronization options are gone
The last suggestion by Martin Davis makes sense to me. Landon On Fri, Oct 14, 2011 at 8:39 PM, Martin Davis mtncl...@telus.net wrote: So is the behaviour: - if Filter By Extension is unchecked, then the user can select any file and any format - if Filter By Extension is checked, then the user selects a file and the format is determined from the extension ? Would an even simpler alternative be to determine the format from the extension, where this is unabiguous, and if it is ambiguous or undetermined then let the user choose the desired format? So examples are: - if a .SHP file is chosen, the format is set to Shapefile automatically. - if a .ZIP or .XML file is chosen, the user must choose the appropriate format So there is only one dropdown for Format, and then the checkbox On 10/14/2011 12:59 AM, edgar.sol...@web.de wrote: On 10/13/2011 2:24 AM, edgar.sol...@web.de wrote: On 13.10.2011 01:02, Martin Davis wrote: One reason for having the double choice of both format and file name is that there are formats (such as GML) which don't have a standard file extension that can be used to drive the choice of format. Also, in JUMP originally we supported a zipped shapefile concept. It had the extension .zip, but was read by the Shapefile driver. One thing that could be do would be to use the file extension to drive the initial format setting, but allow it to be overridden for files with non-specific extensions. How about a checkbox 'filter by extension', which can be disabled allowing to select any file with any selection in the format dropdown? Ok, but I'm not sure how this solves the problem of determining the format of a file with an unknown extension? there is no determination. but, it allows users to assign a format of their choice to a file of their choice and try to open it. seen? ede -- 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1410 / Virus Database: 1522/3949 - Release Date: 10/13/11 -- 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Design of File Load Dialog (was strings for pan synchronization options are gone
On 10/13/2011 2:24 AM, edgar.sol...@web.de wrote: On 13.10.2011 01:02, Martin Davis wrote: One reason for having the double choice of both format and file name is that there are formats (such as GML) which don't have a standard file extension that can be used to drive the choice of format. Also, in JUMP originally we supported a zipped shapefile concept. It had the extension .zip, but was read by the Shapefile driver. One thing that could be do would be to use the file extension to drive the initial format setting, but allow it to be overridden for files with non-specific extensions. How about a checkbox 'filter by extension', which can be disabled allowing to select any file with any selection in the format dropdown? Ok, but I'm not sure how this solves the problem of determining the format of a file with an unknown extension? there is no determination. but, it allows users to assign a format of their choice to a file of their choice and try to open it. seen? ede -- 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Design of File Load Dialog (was strings for pan synchronization options are gone
So is the behaviour: - if Filter By Extension is unchecked, then the user can select any file and any format - if Filter By Extension is checked, then the user selects a file and the format is determined from the extension ? Would an even simpler alternative be to determine the format from the extension, where this is unabiguous, and if it is ambiguous or undetermined then let the user choose the desired format? So examples are: - if a .SHP file is chosen, the format is set to Shapefile automatically. - if a .ZIP or .XML file is chosen, the user must choose the appropriate format So there is only one dropdown for Format, and then the checkbox On 10/14/2011 12:59 AM, edgar.sol...@web.de wrote: On 10/13/2011 2:24 AM, edgar.sol...@web.de wrote: On 13.10.2011 01:02, Martin Davis wrote: One reason for having the double choice of both format and file name is that there are formats (such as GML) which don't have a standard file extension that can be used to drive the choice of format. Also, in JUMP originally we supported a zipped shapefile concept. It had the extension .zip, but was read by the Shapefile driver. One thing that could be do would be to use the file extension to drive the initial format setting, but allow it to be overridden for files with non-specific extensions. How about a checkbox 'filter by extension', which can be disabled allowing to select any file with any selection in the format dropdown? Ok, but I'm not sure how this solves the problem of determining the format of a file with an unknown extension? there is no determination. but, it allows users to assign a format of their choice to a file of their choice and try to open it. seen? ede -- 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1410 / Virus Database: 1522/3949 - Release Date: 10/13/11 -- 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
