Project Browser vs App Browser (was "script scope variables inexplicably becoming unset")
J. Landman Gay
jacque at hyperactivesw.com
Sat Jan 3 01:31:12 EST 2015
On 1/2/2015 9:00 PM, Richard Gaskin wrote:
>
> Can you recall offhand what sorts of tasks take you more steps in the
> Project Browser?
I feel like a curmudgeon after writing what follows, but...I don't use
the project browser because it's too slow and cumbersome for my project.
It may be useful for small stacks with only a few controls, but if you
have several open stacks with lots of cards, and lots of groups and
controls on each card, finding anything is almost impossible. It's much
easier in the app browser to just select a card from a list and
immediately see what it contains. I often need to jump between cards in
different stacks, and in the App Browser I can expand the card lists for
the stacks and click back and forth between them to instantly see their
controls and relative layering.
If there are a lot of controls on a card, a single card's content runs
off the bottom of the project browser, which means you lose the relative
relationships of the objects as their containers scroll off the top.
When the browser window is only showing a portion of the controls, there
is no easy way to see what card those controls are on or even what stack
they belong to. You have to scroll up quite a long way to find out what
you're looking at.
This is the reason I keep the Finder in column view too. You can see the
breadcrumbs and you know where you are. The app browser provides the
same thing and is, for what I do, a much clearer layout and much faster
to work with.
Another blocker for me is that the project browser does not list the
card number, only the card name. That's not useful for unnamed cards, or
cards whose names you don't remember. But I can see the card number in
the title bar (and in my stacks it's also displayed on the card.) In the
app browser it's easy to find the card by its number; in the project
browser you can't. And if your stacks contain same-named cards, then
it's too easy to choose the wrong one in the project browser even if you
do know the name. The same problem occurs with layer numbers. If I need
to change the layers on one card to match a card elsewhere, there's no
numerical reference unless you double-click every control to see its
property inspector.
I'm working on stacks with 30-50 cards each, with anywhere from 40 to
1000 controls per card, nested in multiple groups. Since each stack was
created from a master template, there are several identically-named
groups and controls across all cards and stacks. I usually have about a
dozen stacks open at a time, sometimes more. You just can't navigate
through all that in the project browser, and if you do get where you
want to be, you can't tell later what you're looking at because the card
and stack references have scrolled off.
I could navigate to the card in the stack, click something, and the
browser would update -- but if you're working on one card and just need
to reference the contents of another, it's one of those cases that takes
more clicks to accomplish. I often click over to a different card in the
app browser to remember what I named a field, and I don't need to
physically switch cards in the stack to do that.
Here's another thing: the app browser works with messages turned off.
The project browser doesn't. I frequently work with messages off to
avoid script consequences I don't want.
Finally, I can sort the app browser in all kinds of ways -- put all the
images together, all the fields, all invisibles, sort alphabetically, so
it's easy to find things. The project browser is in a fixed order. The
filter feature is a step in the right direction, but the card or stack
references can still scroll off the top, and there's quite a noticeable
delay when filtering a thousand objects for "type:field". I don't see a
way to display more than one type of object, to alphabetize the controls
on a card, or to limit the results to a particular card. The app browser
does all that, and clicking a header is easy, fast, and I always know
where I am.
I may be able to make the switch for simpler projects, but for this one
I need to stay with the app browser. I hate to say that because I know
how much work went into the project browser, and it's a beautiful thing,
but I think we need to keep both tools around to accomodate different
work flows. If I had to use the project browser on this project, my
development time would quadruple.
--
Jacqueline Landman Gay | jacque at hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
More information about the use-livecode
mailing list