Re: [JPP-Devel] Design of File Load Dialog (was strings for pan synchronization options are gone

2011-10-18 Thread edgar . soldin
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

Re: [JPP-Devel] Design of File Load Dialog (was strings for pan synchronization options are gone

2011-10-18 Thread edgar . soldin
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

Re: [JPP-Devel] Design of File Load Dialog (was strings for pan synchronization options are gone

2011-10-18 Thread Rahkonen Jukka
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

Re: [JPP-Devel] Design of File Load Dialog (was strings for pan synchronization options are gone

2011-10-18 Thread edgar . soldin
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

Re: [JPP-Devel] Design of File Load Dialog (was strings for pan synchronization options are gone

2011-10-18 Thread Martin Davis
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

Re: [JPP-Devel] Design of File Load Dialog (was strings for pan synchronization options are gone

2011-10-17 Thread edgar . soldin
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

Re: [JPP-Devel] Design of File Load Dialog (was strings for pan synchronization options are gone

2011-10-17 Thread Stefan Steiniger
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,

Re: [JPP-Devel] Design of File Load Dialog (was strings for pan synchronization options are gone

2011-10-15 Thread Sunburned Surveyor
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

Re: [JPP-Devel] Design of File Load Dialog (was strings for pan synchronization options are gone

2011-10-14 Thread edgar . soldin
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.

Re: [JPP-Devel] Design of File Load Dialog (was strings for pan synchronization options are gone

2011-10-14 Thread Martin Davis
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