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 G
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 GM
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
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 OpenD
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
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, M
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 tr
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 combobo
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 wrote:
>> So is the behavi
The last suggestion by Martin Davis makes sense to me.
Landon
On Fri, Oct 14, 2011 at 8:39 PM, Martin Davis 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 f
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
> 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
Ok, but I'm not sure how this solves the problem of determining the
format of a file with an unknown extension?
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
13 matches
Mail list logo