Project Browser vs App Browser (was "script scope variables inexplicably becoming unset")

J. Landman Gay jacque at
Sat Jan 3 07:31:12 CET 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
HyperActive Software           |

More information about the use-livecode mailing list