🚀 go-pugleaf

> Or what if the user wants to use ChangeFSI instead of Translator (for reasons

>This is like saying you might want to use StrongEd rather than Edit to edit a
>text file ... you arrange the RunType to point to the one you want, or be
>prepared to load it by hand first.

No. It isn't quite the same. Edit vs StrongEd is generally a permanent choice,
i.e. I run StrongEd all the time, and edit gets run only about 2 times a
month, for about 30 seconds, to do something quick in a task window - I
then save the text output of the taskwindow to StrongEd and quit Edit.

What I meant is, imagine you have 30 'alien format' pictures, and you want to
load them all into Paint. However, *some* of them you want to run through
ChangeFSI, and some through Translator.

If an arbitrary translator is auto-run when you drag the files to Paint,
then you have no idea if the right choice of translator was made until it's
too late.

And what if your default translation settings are not correct - the
translator (possibly the wrong one) will be auto-loaded, and then proceed
to give a totally wrong translation anyway.

In these cases, the user has to choose a translator by running it, set any
translation options they desire, and *then* drag the files to Paint.

However, after some email chats, I have come to the conclusion that translation
can best be handled by a module to which all translators register, and this
can then orchestrate the collaboration between two or more applications to
translate data automatically. Having this module provide a *command for
translators to include in their !Run file would allow all translators
to register themselves not only for translations, but also for auto-running
if no other translation path is already possible with loaded applications.

>> It is extremely likely that I will therefore wish to supply scaling factors,
>> quality factors (like FS dither or no dither, etc), colour translations
>> (e.g. force to greyscale), etc. before loading the file.

>Yes ... but a large part of this kind of system is to make it easy for naive
>users, who just want a default option that works.

Sure. But the method suggested just sounds too hit and miss. If a translation
isn't available then a system variable is used to auto-run a translator
that might stand only a small chance of being suitable, and use default
settings that are more often than not going to be totally wrong.

The suggestion of using a module to control all of this
  a) Makes everything more coherent. Somebody *knows* what is going on, rather
     than applications making inspired guesses about the best course of action.

     This will make the protocol faster, as well as allowing the 'best'
     translation out of a set of choices to be automatically chosen (in the
     case of several translation steps between the source and destination
     file formats)

     Also, it allows the possibility of giving the more advanced user a list
     of possible translations and options and allow them to set things up
     exactly as they want them before OKing the operation.

  b) Moves a lot of the effort from each application/writer into the master
     module, so implementing the protocol from an editor/translator will be
     much much simpler.

>Indeed ... but I don't think you should ever worry about making life a bit
>harder for a programmer, if you make it easier for the user.

Sure, but only lazy sods like myself ever seem to be able to come up with
easier ways of achieveing the same (or better) effect. If you won't even
consider ease-of-programming in your plans, then you may just miss something
crucial. Also, I think if any protocol is to find support, it has to be
as easy as possible for the programmers to implement support for it, or
it'll just fade away, and that benefits nobody.

-- 
themasterofthearcanejwil1@cs.aukuni.ac.nzthismessagewassentonrecycledelectrons