[softwarelist] Re: New alpha version of DPlngScan

  • From: Jeremy Nicoll - freelists <jn.fr.lsts.74@xxxxxxxxxxxxxxxxxxxx>
  • To: davidpilling@xxxxxxxxxxxxx
  • Date: Fri, 18 Jan 2019 17:47:10 +0000

On 2019-01-17 18:08, Chris Johnson wrote:

Firstly - default behaviour. There are two features of the current
behaviour that still catch me out sometimes.

1. If you raise a save as dialogue, change the filename (eg add /png)
   then change the filetype for the save, the filename change you
   have just made is immediately lost, the filename reverting to the
   previous name. You have to remember to make the filetype change
   before changing the name.

2. Following on from the above: suppose you load a file eg. of type
   sprite. You then save it as type jpeg. If you now perhaps do a
   further edit, and raise the save as again to resave the image, the
   new filename is presented in the writable (assuming the filename
   did change), but the filetype is the previous one ie. the sprite
   filetype of the original image in this example. You have to
   manually change the filetype to jpeg if you wish to save it again
   as the new filetype, jpeg. If you are on autopilot (which can
   sometimes be the case) and simply click OK, you find later you
   have a file named pic/jpg, but of sprite filetype.

Should I leave well alone (better the devil you know ...) or should I
make any changes?

The format in which data is saved is dictated by filetype, so I'd
consider adding a little extra logic that, after the user has told
you what they want (possibly erroneously), examines the chosen
filename & filetype combination.  If the filename has a trailing
"/xyz" portion (hex or typename), then test whether it's in conflict
with the filetype, and if so ask the user to confirm their choice.


Maybe if auto-add is turned on, you should disallow any manual
specification of '/anything' at the end of a save_as filename?

That might be a problem if the user types "fred/jim" expecting
a final name of "fred/jim/png" though.

How does your new code work if someone tries to load "fred/jim"?





-----------------------------------------------------------------

Now we come to the new auto-add extension behaviour. Again,
implementation of features need thought.

The strip current extension / add new extension is implemented and
working. However, it is the anticipating of certain scenarios that
put me into pause mode. Consider when an image is loaded of a
filetype that has a recognised ext, eg. jpg, but the original
filename has no ext. I think that if the image is resaved to its
original location (eg. by clicking OK in the save dbox), no attempt
to add an ext should be made. In other words, the original file is
overwritten.

 - or ask user if they want     name      type:JPG
                         or     name/jpg  type:JPG

and bear in mind that both options could cause a file (the original
one or an adjacent one) to be overwritten.


Maybe your save/save_as logic always has to check if a file is about
to be overwritten, and explicitly ask if that should happen.



Now what happens if the image is saved as the original type, but to a
different location. Do we now add a filename extension, or do we
still leave it without an extension?

I think that depends more on how you present the new code.  Either

a) the new logic is designed always to ensure that there is a filetype-
   appropriate "/xxx" or "/nam" value on the leafname, or

b) the new logic is designed only to ensure that when brand new files
   are written



--
Jeremy Nicoll - my opinions are my own
To unsubscribe or subscribe goto: //www.freelists.org/list/davidpilling

Other related posts: