a maybe not so stupid question

Romain Lafourcade lafourcade.romain at numericable.fr
Thu Jun 26 04:28:01 EDT 2003


on 26/06/03 0:57, use-revolution-request at lists.runrev.com at
use-revolution-request at lists.runrev.com wrote:

>>> But in the meantime, have you considered making only your Browser app into a
>>> standalone, and having your Builder app be a separate stack that runs with
>>> the same engine?  I would imagine that most folks using your Builder would
>>> want the Browser also, yes?
>> 
>> Yes, I thought about that. Actually I've started out with this solution in
>> mind but it became clear to me that it would look a lot more professional
>> (at least from the user's point of view) to have these two separate apps and
>> to keep that distinction between the "Builder" and the "Browser".
> 
> A lot of apps provide different modes for different tasks.  For example for
> Dreamweaver and GoLive offer a Layout mode and a Preview mode.
> 
> Using an external a Builder stackfile module to deterine the program's
> building capabilities need not necessarily appear "unprofessional".  That
> same basic architecture drives GoLive: many of its modes are in separate
> module files, which can be added to a folder to enhance capabilities.
> 
> There can be benefits to this approach:  if one is Building they may want to
> test by Browsing, and you can better integrate the two as modules in a
> single app than trying to rig some latform-independent mechanism for having
> the two apps talk to one another.   Also, the user saves a lot of memory and
> time switching between Building and Browsing.
> 
> Just how ideal this approach is for your app of course depends on the
> specifics of your app and its workflow.  There can be potential tradeoffs
> with either approach.
> 
>> A big issue I still have to cope with is the revCopyFile command that I
>> simply can't make to work. Since my users are supposed to move images from
>> one point of their hard drive to another this command was interesting
>> because of its ability to move files WITHOUT reading it.
>> 
>> It seems that I'll use the put URL ... into URL ... form or import all these
>> images within the "Book" stack but this solution may create quite big
>> files...
> 
> What is the relationship between copying files and displaying external image
> files in your app?

Thanks for your ideas Richard, I have to stop working on BBB for a couple of
weeks now because of money-making but I promise I'll take this into account.

Actually BBB is nothing more than an advanced "diaporama" making tool. It
provides the same kind of functions as you can find in PhotoShow. But with a
better look and feel.

The user is typically the Graphic Designer or Illustrator who wants to
display his jobs in a way that the end-user (client or future employer) is
able to decide what he wants to watch and how long he will watch it.

Let me explain, the "Browser" is composed of a screenRecte-ed window and a
palette.
This palette displays 0, 2, 3 or 4 custom-labeled buttons and a titled
list-field.
Pressing on a button populate the field with the list of files contained in
a folder named according to the button's label.
Selecting one of the lines displays the corresponding image in the large
underlying window (actually it check if there's a card of that name and, if
not, create the card).

This system gives a lot of control to the end-user on the way the
presentation works, allowing him to "get into it" in a more efficient way
than other diaporama making tools do.

That said, when using the "Builder", the primary-user is supposed to gather
images on his hard drive into folders that he has created and labeled
according to his needs. These images are the ones that are displayed right
into the large window of the "Browser". Here are the options I have to
achieve that :

- using put URL "..." into "URL "...". This option is supposed to read the
file and it may be quite long since the file is supposed to be an image and
probably not a light one. But it works, the file is copied into the right
folder.

- using revCopyFile. This option was interesting because it didn't read the
file and was supposed to be faster than the previous one but, god knows why,
it doesn't work.

- the last option is to import in real time or at the end of the process
these images within a substack "Book" (one image on one card, which is how
the "Browser" works). This option is OK but it makes me re-design my
"Browser" so that it open the cloned stack "Book" as if it was the large
window I've talked of before.

But thanks, I'll come back to it soon...




More information about the use-livecode mailing list