App Browser versus Project Browser

classic Classic list List threaded Threaded
53 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: App Browser versus Project Browser

Richard Gaskin
Richmond wrote:
 > Well, all I can suggest is that LiveCode produces a hybrid
 > [ chimæ ra ??? ] and see what the response is . . .

Maybe that would be useful, but maybe LiveCode Ltd. doesn't need to
build it.

They have a lot of smart people writing C++ in ways beyond the skills
and experience of most members of our community.

But this is true of most of the great scripting languages:  R, Python,
Lua, PHP, and others - they all have rather small teams working on their
engines, but what makes them truly great languages is the scope of
scripted tools and libraries their communities share.

The one thing we know about LiveCode scripters is that they enjoy
scripting in LiveCode.

Would it be so crazy to have a community-managed fork of the IDE?

For a while even Ben used to suggest that as an option between major
versions.  And right now the team at LiveCode Ltd. has already made
changes to the IDE which are version-8-dependent, so there's no
affordable way to backport to the current product version anyway.

Is this a good time for you, or anyone with sufficient time, interest,
and skill, to modify the IDE?

Why not have exactly what you want?

Like the inventor of the engine used to say back where there were three
IDEs with talk of more: "Let a thousand flowers bloom."

--
  Richard Gaskin
  LiveCode Community Manager
  [hidden email]


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: App Browser versus Project Browser

Monte Goulding

> On 8 Oct 2015, at 8:59 am, Richard Gaskin <[hidden email]> wrote:
>
> > Well, all I can suggest is that LiveCode produces a hybrid
> > [ chimæ ra ??? ] and see what the response is . . .
>
> Maybe that would be useful, but maybe LiveCode Ltd. doesn't need to build it.

rIDE was nice but I think it may have suffered from the same single hierarchy issue that the project browser suffers from.

At one point I was thinking of making a stack browser that behaved like the column view in the finder but then I realised that the most annoying thing about the application browser is its use of horizontal space. Unfortunately it’s the use of horizontal space that makes it more functional… Perhaps if it had some nice behavior when the columns compact up and a good way to provide context it would work… We all need to get our Scott Rossi hats on and come up with a UI that both minimises use of horizontal space and keeps the list as clean as possible so you can just look at the objects on a single card.

Other than that I would say I’d be happier with it if we lost a few pixels from each line to make it more compact vertically.

There’s a few other features I’d add as well…

The root of the hierarchy could be Top Stack, Open Stacks, All Stacks, Front Scripts, Back Scripts, Stacks In Use. The card list could have Current Card at the top. If you have the current card selected then as the current card changes the object list updates to show the correct list. This is particularly helpful if you have top stack > current card selected.

Direct integration between the project browser and the script editor would be very nice too. Some kind of context mode in the script editor that would switch the script in the script editor to the selected obhect with some indication of unsaved or unset scripts on the project browser.. Extra bonus points if you can include the project browser directly into the script editor as a pane… Very much like how the inspector will change when you select an object. It seems reasonable that the script editor could have such a mode that would update with object selection via project browser or other means.

Cheers

Monte




_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: App Browser versus Project Browser

Sannyasin Brahmanathaswami
In reply to this post by Paul_Hibbert
Hmmm,  I had to bail on LC8… just not ready do deal with too many broken issues right now.

I stuck in 7.1 for now…

 I like the project browser for several reasons (stopped using the application browser 3 months ago)

1) visual representation of objects is very helpful  I

2) having the groups appear on the left panel with indents is visually easier to see hierarchy. AB has zero easy access to groups. This is my main problem with the AB

3) I like color

where is geof’s plug in these days?


BR








On 10/7/15, 11:02 AM, "use-livecode on behalf of Paul Hibbert" <[hidden email] on behalf of [hidden email]> wrote:

>I am one of the people that generally prefers the Application Browser to the Project Browser, but to be fair I don’t think I gave the PB enough attention to see any of it’s merits.
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: App Browser versus Project Browser

Richard Gaskin
In reply to this post by Monte Goulding
Monte Goulding wrote:

 > At one point I was thinking of making a stack browser that behaved
 > like the column view in the finder but then I realised that the most
 > annoying thing about the application browser is its use of horizontal
 > space. Unfortunately it’s the use of horizontal space that makes it
 > more functional…

I love Miller columns for many things, and started down that road once:
<http://fourthworld.net/revnet/devolution/4W_ObjectBrowser.rev.gz>

I used that for all my MetaCard years, and even with LC until the
Project Browser. I guess I'm in the minority who finds the PB fairly
satisfying (though the speed is abysmal with thumbnails on).

Back in my SuperCard days folks used to make object browsers almost as
frequently as HyperCarders made Finder replacements <g>.  Some good
ideas came from some of that, but I haven't seen one yet that makes me
truly happy in all respects with features, performance, display clarity,
and space.

With so much commercial work to do it's been hard to justify time for
object browsers once the PB came along and it was at least good enough
for me.

But if folks have time and interest there are many possibilities, and
ideally we'd have a good many to choose from so everyone has exactly
what they want.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: App Browser versus Project Browser

ScottR
In reply to this post by J. Landman Gay
IMO, Jacque makes a number of valid points.  In the Project Browser,
because stacks and cards are contained in the single view, a long list of
controls will remove any stack and card references from view, while in the
Application Browser, stacks and cards are always visible.  It seems like
applying an Application Browser layout to the Project Browser could make
it more useful: move stack/card references to a left pane that is always
visible.

For myself, I also often rely on numerical references: card numbers, layer
numbers, etc.  Filtering in the Project Browser is great, but it's not the
same as sorting offered by the Application Browser (AFAICT the Project
Browser doesn't offer sorting that I can see).

Regards,

Scott Rossi
Creative Director
Tactile Media, UX/UI Design




On 10/7/15, 12:58 PM, "use-livecode on behalf of J. Landman Gay"
<[hidden email] on behalf of
[hidden email]> wrote:

>On 10/7/2015 1:22 PM, Mark Waddingham wrote:
>> Far more useful would be constructive criticism of both the Project
>> Browser and the Application Browser. It does seem a little 'silly' to
>> maintain two things which serve essentially the same purpose - so Ali's
>> idea is perhaps the best way forward - what is it that is good and bad
>> about both and is it possible to design something which everybody would
>> be happy with?
>
>The issues would probably become clear if you open, say, 10 large
>stacks, each with 50 cards or more, containing dozens of controls per
>card. Since my primary project for the last 2 years uses that setup, I
>haven't been able to use the Project Browser because it isn't practical.
>
>1. The hierarchical organization of the App Browser (AB) is
>indispensable and is the main reason I stay with it. I can see at a
>glance how to drill down to the single object I am looking for and how
>objects are organized on each card by group and layer order. It is by
>far the fastest way to understand how a set of stacks is internally
>structured. The long, scrolling list in the Project Browser (PB) can't
>display the structure as clearly because it is all linear. Multiple
>cards with many objects will run off the top and bottom of the PB window
>and you can't see the overall organization.
>
>2. It is difficult in the PB to quickly find a specific object. If you
>want to know the name of an object on some other card, you have to
>collapse the current card, scroll through 50 cards to find the one
>you're looking for (and if you didn't collapse those already, the
>scrolling is interminable,) expand it, scroll through the objects to
>find the one you want (note the name because it's going to be a long
>trip to find it again,) collapse that card, scroll (forever) again to
>find the card you started with, expand it, find the original object
>again, and continue. In AB, I can just look at the left-hand pane and
>see the name of the target card, click it, note the name of the object,
>then click back where I was. If the AB is sized tall enough to hold 50
>lines of text, I don't have to do much scrolling at all. If I do need to
>scroll, it's minimal because at least 25-30 cards are always visible at
>once.
>
>2. In the AB I can click on any header to view the organization in many
>ways, and I have a choice of which columns I want to display. If I want
>to work only with images, or fields, I can bunch them together in the
>list by type and they are quickly accessible while still allowing me to
>see the other objects on the card. I frequently require info on layering
>order, one click and I have that. I use the ID column extensively. In PB
>I have to type in a filter string to isolate by object type, and then I
>can no longer see any other objects, so if I need some other info I have
>to remove the filter, find what I want, then reinstate the original
>filter. PB does not offer a way to identify an object ID at all, as far
>as I can see, and I need that all the time. (But you could turn off
>those distracting ID tooltips for sure.)
>
>3. Visually, the PB is too cluttered to be quickly scanned. The
>checkmarks in the AB are more useful. In the AB is very easy to see, for
>example, which objects are invisible by simply looking for "gaps" in the
>checkmark column. In the PB I have to examine each object individually
>because the visual difference between the enabled and disabled "eye"
>image is not distinct enough, and even if it were, there's that
>scrolling issue again to see all the objects. Also, there is no single
>column to scan -- the lock icon is interspersed so you have to mentally
>learn to skip over every other icon.
>
>4. I have turned off thumbnails in the PB because with hundreds of
>objects or more, the time required for it to constantly update is (or at
>least, was) unacceptable. Even without thumbnails, it performs much
>slower than the AB. There is also the issue of visual clutter (see
>below) which is main reason I turned off thumbnails on day one.
>Thumbnails also double the amount of scrolling you have to do to find
>things.
>
>5. In the PB there is no clear delineation between cards and substacks.
>Both are left-aligned at the same visual depth. In the AB, all stacks
>are in the left pane, with substacks indented under their mainstack.
>Also, in the PB, the stack you are inspecting scrolls off the top of the
>window, so you are never sure which stack owns the cards that are
>currently displayed. This is a big issue in my project, because all the
>stacks are clones of each other and cards have the same names (usually
>just IDs.) In the AB I can immediately see which stack owns the card
>because the card is highlighted in the left-pane list under its
>easily-viewable owner. Even if I have to scroll to see the stack name,
>the card I'm working with remains selected and its objects remain visible.
>
>6. The icons at the bottom of the PB are so tiny on my screen that they
>are difficult to recognize (and my eyesight isn't great anyway.) I have
>to use the tooltips. That takes too long, so I just open the property
>inspector or use the menu items instead. I suppose with some use I'd
>memorize what each icon does, but the other issues have prevented me
>from becoming familiar enough with it.
>
>That's just what I remember from the few days I tried to work with it.
>I'm not convinced that the current design can accomodate my work style
>unless it can at least be revised to show a columnar view rather than a
>linear one. What I would have preferred is an update for the few
>glitches in the AB (mainly it doesn't always refresh automatically, and
>those blinking tooltips are positively aggressive) and give it a new
>coat of paint if you think it looks too dated. Its plain text layout
>with clear checkmarks is much easier for me to work with. I do like how
>you can change layering order by dragging in the PB, that would be a
>nice addition to the AB.
>
>--
>Jacqueline Landman Gay         |     [hidden email]
>HyperActive Software           |     http://www.hyperactivesw.com
>
>_______________________________________________
>use-livecode mailing list
>[hidden email]
>Please visit this url to subscribe, unsubscribe and manage your
>subscription preferences:
>http://lists.runrev.com/mailman/listinfo/use-livecode



_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: App Browser versus Project Browser

Peter Haworth
I think this thread illustrates the problem the team have trying to figure
out what type of browser to implement.  Everyone has their own ways of
working and it's practically impossible to come up with a solution that
will keep everyone happy.

Perhaps the biggest divide is between the horizontal and vertical layout
fans.  My preference is for a vertical layout but I recognize that can
cause a large amount of scrolling.  I tried a few things to alleviate that
in lcStackbrowser, for example, tabs with only one main stack in each tab
and the ability to hide a specific stack or all except a specific stack.

I find myself using a lot of groups in my designs and that helps a lot with
the scrolling issue too, assuming groups are expandable/collapsible of
course.

A lot of the other PB  problems fall into the missing functionality
bucket.  You should be able to sort objects in whatever way suits your mode
of operation.  lcStackBrowser allows sorting of cards by name, id, or
number; controls by layer, id, type or name; with a default preference
setting for each one.  You can sort cards and controls differently for each
stack/card.

I do like the snapshot feature in the PB but not as an ever present
thumbnail.  In lcstackbrowser, you can display a snapshot of a specific,
group, or control with either a contextual menu option or a keyboard
shortcut.

I also wanted access to properties without opening a property inspector
window and lcStackbrowser has various ways to do that.  You can edit an
object's name, label, and (for simple text fields) its contents. Right
click on an object and you will have access to all of its boolean
properties.  Finally, you can expand an object to show an editable list of
properties, grouped the way that suits the way you work in preferences,
with full type-specific editors, including an array editor.

You can also customize just about every element of the display, reorganize
the contextual menu items and add your own to them, and create/rollback to
commented checkpoints of your stack.

I don't pretend lcStackbrowser will be the ideal solution for everyone but
I think the key to a successful implementation is a high degree of
flexibility so users can customize it to suit their way of working.





On Wed, Oct 7, 2015 at 4:21 PM Scott Rossi <[hidden email]> wrote:

> IMO, Jacque makes a number of valid points.  In the Project Browser,
> because stacks and cards are contained in the single view, a long list of
> controls will remove any stack and card references from view, while in the
> Application Browser, stacks and cards are always visible.  It seems like
> applying an Application Browser layout to the Project Browser could make
> it more useful: move stack/card references to a left pane that is always
> visible.
>
> For myself, I also often rely on numerical references: card numbers, layer
> numbers, etc.  Filtering in the Project Browser is great, but it's not the
> same as sorting offered by the Application Browser (AFAICT the Project
> Browser doesn't offer sorting that I can see).
>
> Regards,
>
> Scott Rossi
> Creative Director
> Tactile Media, UX/UI Design
>
>
>
>
> On 10/7/15, 12:58 PM, "use-livecode on behalf of J. Landman Gay"
> <[hidden email] on behalf of
> [hidden email]> wrote:
>
> >On 10/7/2015 1:22 PM, Mark Waddingham wrote:
> >> Far more useful would be constructive criticism of both the Project
> >> Browser and the Application Browser. It does seem a little 'silly' to
> >> maintain two things which serve essentially the same purpose - so Ali's
> >> idea is perhaps the best way forward - what is it that is good and bad
> >> about both and is it possible to design something which everybody would
> >> be happy with?
> >
> >The issues would probably become clear if you open, say, 10 large
> >stacks, each with 50 cards or more, containing dozens of controls per
> >card. Since my primary project for the last 2 years uses that setup, I
> >haven't been able to use the Project Browser because it isn't practical.
> >
> >1. The hierarchical organization of the App Browser (AB) is
> >indispensable and is the main reason I stay with it. I can see at a
> >glance how to drill down to the single object I am looking for and how
> >objects are organized on each card by group and layer order. It is by
> >far the fastest way to understand how a set of stacks is internally
> >structured. The long, scrolling list in the Project Browser (PB) can't
> >display the structure as clearly because it is all linear. Multiple
> >cards with many objects will run off the top and bottom of the PB window
> >and you can't see the overall organization.
> >
> >2. It is difficult in the PB to quickly find a specific object. If you
> >want to know the name of an object on some other card, you have to
> >collapse the current card, scroll through 50 cards to find the one
> >you're looking for (and if you didn't collapse those already, the
> >scrolling is interminable,) expand it, scroll through the objects to
> >find the one you want (note the name because it's going to be a long
> >trip to find it again,) collapse that card, scroll (forever) again to
> >find the card you started with, expand it, find the original object
> >again, and continue. In AB, I can just look at the left-hand pane and
> >see the name of the target card, click it, note the name of the object,
> >then click back where I was. If the AB is sized tall enough to hold 50
> >lines of text, I don't have to do much scrolling at all. If I do need to
> >scroll, it's minimal because at least 25-30 cards are always visible at
> >once.
> >
> >2. In the AB I can click on any header to view the organization in many
> >ways, and I have a choice of which columns I want to display. If I want
> >to work only with images, or fields, I can bunch them together in the
> >list by type and they are quickly accessible while still allowing me to
> >see the other objects on the card. I frequently require info on layering
> >order, one click and I have that. I use the ID column extensively. In PB
> >I have to type in a filter string to isolate by object type, and then I
> >can no longer see any other objects, so if I need some other info I have
> >to remove the filter, find what I want, then reinstate the original
> >filter. PB does not offer a way to identify an object ID at all, as far
> >as I can see, and I need that all the time. (But you could turn off
> >those distracting ID tooltips for sure.)
> >
> >3. Visually, the PB is too cluttered to be quickly scanned. The
> >checkmarks in the AB are more useful. In the AB is very easy to see, for
> >example, which objects are invisible by simply looking for "gaps" in the
> >checkmark column. In the PB I have to examine each object individually
> >because the visual difference between the enabled and disabled "eye"
> >image is not distinct enough, and even if it were, there's that
> >scrolling issue again to see all the objects. Also, there is no single
> >column to scan -- the lock icon is interspersed so you have to mentally
> >learn to skip over every other icon.
> >
> >4. I have turned off thumbnails in the PB because with hundreds of
> >objects or more, the time required for it to constantly update is (or at
> >least, was) unacceptable. Even without thumbnails, it performs much
> >slower than the AB. There is also the issue of visual clutter (see
> >below) which is main reason I turned off thumbnails on day one.
> >Thumbnails also double the amount of scrolling you have to do to find
> >things.
> >
> >5. In the PB there is no clear delineation between cards and substacks.
> >Both are left-aligned at the same visual depth. In the AB, all stacks
> >are in the left pane, with substacks indented under their mainstack.
> >Also, in the PB, the stack you are inspecting scrolls off the top of the
> >window, so you are never sure which stack owns the cards that are
> >currently displayed. This is a big issue in my project, because all the
> >stacks are clones of each other and cards have the same names (usually
> >just IDs.) In the AB I can immediately see which stack owns the card
> >because the card is highlighted in the left-pane list under its
> >easily-viewable owner. Even if I have to scroll to see the stack name,
> >the card I'm working with remains selected and its objects remain visible.
> >
> >6. The icons at the bottom of the PB are so tiny on my screen that they
> >are difficult to recognize (and my eyesight isn't great anyway.) I have
> >to use the tooltips. That takes too long, so I just open the property
> >inspector or use the menu items instead. I suppose with some use I'd
> >memorize what each icon does, but the other issues have prevented me
> >from becoming familiar enough with it.
> >
> >That's just what I remember from the few days I tried to work with it.
> >I'm not convinced that the current design can accomodate my work style
> >unless it can at least be revised to show a columnar view rather than a
> >linear one. What I would have preferred is an update for the few
> >glitches in the AB (mainly it doesn't always refresh automatically, and
> >those blinking tooltips are positively aggressive) and give it a new
> >coat of paint if you think it looks too dated. Its plain text layout
> >with clear checkmarks is much easier for me to work with. I do like how
> >you can change layering order by dragging in the PB, that would be a
> >nice addition to the AB.
> >
> >--
> >Jacqueline Landman Gay         |     [hidden email]
> >HyperActive Software           |     http://www.hyperactivesw.com
> >
> >_______________________________________________
> >use-livecode mailing list
> >[hidden email]
> >Please visit this url to subscribe, unsubscribe and manage your
> >subscription preferences:
> >http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: App Browser versus Project Browser

ScottR
Agreed that satisfying everybody will never happen, but I would argue that
the dual-pane approach of the Application Browser can display more
information in a single view than the Project Browser.  IMO, accessing
multiple stacks is more efficient using this approach compared to using a
single scrolling list.

Regards,

Scott Rossi
Creative Director
Tactile Media, UX/UI Design




On 10/7/15, 5:31 PM, "use-livecode on behalf of Peter Haworth"
<[hidden email] on behalf of [hidden email]> wrote:

>I think this thread illustrates the problem the team have trying to figure
>out what type of browser to implement.  Everyone has their own ways of
>working and it's practically impossible to come up with a solution that
>will keep everyone happy.
>
>Perhaps the biggest divide is between the horizontal and vertical layout
>fans.  My preference is for a vertical layout but I recognize that can
>cause a large amount of scrolling.  I tried a few things to alleviate that
>in lcStackbrowser, for example, tabs with only one main stack in each tab
>and the ability to hide a specific stack or all except a specific stack.
>
>I find myself using a lot of groups in my designs and that helps a lot
>with
>the scrolling issue too, assuming groups are expandable/collapsible of
>course.
>
>A lot of the other PB  problems fall into the missing functionality
>bucket.  You should be able to sort objects in whatever way suits your
>mode
>of operation.  lcStackBrowser allows sorting of cards by name, id, or
>number; controls by layer, id, type or name; with a default preference
>setting for each one.  You can sort cards and controls differently for
>each
>stack/card.
>
>I do like the snapshot feature in the PB but not as an ever present
>thumbnail.  In lcstackbrowser, you can display a snapshot of a specific,
>group, or control with either a contextual menu option or a keyboard
>shortcut.
>
>I also wanted access to properties without opening a property inspector
>window and lcStackbrowser has various ways to do that.  You can edit an
>object's name, label, and (for simple text fields) its contents. Right
>click on an object and you will have access to all of its boolean
>properties.  Finally, you can expand an object to show an editable list of
>properties, grouped the way that suits the way you work in preferences,
>with full type-specific editors, including an array editor.
>
>You can also customize just about every element of the display, reorganize
>the contextual menu items and add your own to them, and create/rollback to
>commented checkpoints of your stack.
>
>I don't pretend lcStackbrowser will be the ideal solution for everyone but
>I think the key to a successful implementation is a high degree of
>flexibility so users can customize it to suit their way of working.
>
>
>
>
>
>On Wed, Oct 7, 2015 at 4:21 PM Scott Rossi <[hidden email]> wrote:
>
>> IMO, Jacque makes a number of valid points.  In the Project Browser,
>> because stacks and cards are contained in the single view, a long list
>>of
>> controls will remove any stack and card references from view, while in
>>the
>> Application Browser, stacks and cards are always visible.  It seems like
>> applying an Application Browser layout to the Project Browser could make
>> it more useful: move stack/card references to a left pane that is always
>> visible.
>>
>> For myself, I also often rely on numerical references: card numbers,
>>layer
>> numbers, etc.  Filtering in the Project Browser is great, but it's not
>>the
>> same as sorting offered by the Application Browser (AFAICT the Project
>> Browser doesn't offer sorting that I can see).
>>
>> Regards,
>>
>> Scott Rossi
>> Creative Director
>> Tactile Media, UX/UI Design
>>
>>
>>
>>
>> On 10/7/15, 12:58 PM, "use-livecode on behalf of J. Landman Gay"
>> <[hidden email] on behalf of
>> [hidden email]> wrote:
>>
>> >On 10/7/2015 1:22 PM, Mark Waddingham wrote:
>> >> Far more useful would be constructive criticism of both the Project
>> >> Browser and the Application Browser. It does seem a little 'silly' to
>> >> maintain two things which serve essentially the same purpose - so
>>Ali's
>> >> idea is perhaps the best way forward - what is it that is good and
>>bad
>> >> about both and is it possible to design something which everybody
>>would
>> >> be happy with?
>> >
>> >The issues would probably become clear if you open, say, 10 large
>> >stacks, each with 50 cards or more, containing dozens of controls per
>> >card. Since my primary project for the last 2 years uses that setup, I
>> >haven't been able to use the Project Browser because it isn't
>>practical.
>> >
>> >1. The hierarchical organization of the App Browser (AB) is
>> >indispensable and is the main reason I stay with it. I can see at a
>> >glance how to drill down to the single object I am looking for and how
>> >objects are organized on each card by group and layer order. It is by
>> >far the fastest way to understand how a set of stacks is internally
>> >structured. The long, scrolling list in the Project Browser (PB) can't
>> >display the structure as clearly because it is all linear. Multiple
>> >cards with many objects will run off the top and bottom of the PB
>>window
>> >and you can't see the overall organization.
>> >
>> >2. It is difficult in the PB to quickly find a specific object. If you
>> >want to know the name of an object on some other card, you have to
>> >collapse the current card, scroll through 50 cards to find the one
>> >you're looking for (and if you didn't collapse those already, the
>> >scrolling is interminable,) expand it, scroll through the objects to
>> >find the one you want (note the name because it's going to be a long
>> >trip to find it again,) collapse that card, scroll (forever) again to
>> >find the card you started with, expand it, find the original object
>> >again, and continue. In AB, I can just look at the left-hand pane and
>> >see the name of the target card, click it, note the name of the object,
>> >then click back where I was. If the AB is sized tall enough to hold 50
>> >lines of text, I don't have to do much scrolling at all. If I do need
>>to
>> >scroll, it's minimal because at least 25-30 cards are always visible at
>> >once.
>> >
>> >2. In the AB I can click on any header to view the organization in many
>> >ways, and I have a choice of which columns I want to display. If I want
>> >to work only with images, or fields, I can bunch them together in the
>> >list by type and they are quickly accessible while still allowing me to
>> >see the other objects on the card. I frequently require info on
>>layering
>> >order, one click and I have that. I use the ID column extensively. In
>>PB
>> >I have to type in a filter string to isolate by object type, and then I
>> >can no longer see any other objects, so if I need some other info I
>>have
>> >to remove the filter, find what I want, then reinstate the original
>> >filter. PB does not offer a way to identify an object ID at all, as far
>> >as I can see, and I need that all the time. (But you could turn off
>> >those distracting ID tooltips for sure.)
>> >
>> >3. Visually, the PB is too cluttered to be quickly scanned. The
>> >checkmarks in the AB are more useful. In the AB is very easy to see,
>>for
>> >example, which objects are invisible by simply looking for "gaps" in
>>the
>> >checkmark column. In the PB I have to examine each object individually
>> >because the visual difference between the enabled and disabled "eye"
>> >image is not distinct enough, and even if it were, there's that
>> >scrolling issue again to see all the objects. Also, there is no single
>> >column to scan -- the lock icon is interspersed so you have to mentally
>> >learn to skip over every other icon.
>> >
>> >4. I have turned off thumbnails in the PB because with hundreds of
>> >objects or more, the time required for it to constantly update is (or
>>at
>> >least, was) unacceptable. Even without thumbnails, it performs much
>> >slower than the AB. There is also the issue of visual clutter (see
>> >below) which is main reason I turned off thumbnails on day one.
>> >Thumbnails also double the amount of scrolling you have to do to find
>> >things.
>> >
>> >5. In the PB there is no clear delineation between cards and substacks.
>> >Both are left-aligned at the same visual depth. In the AB, all stacks
>> >are in the left pane, with substacks indented under their mainstack.
>> >Also, in the PB, the stack you are inspecting scrolls off the top of
>>the
>> >window, so you are never sure which stack owns the cards that are
>> >currently displayed. This is a big issue in my project, because all the
>> >stacks are clones of each other and cards have the same names (usually
>> >just IDs.) In the AB I can immediately see which stack owns the card
>> >because the card is highlighted in the left-pane list under its
>> >easily-viewable owner. Even if I have to scroll to see the stack name,
>> >the card I'm working with remains selected and its objects remain
>>visible.
>> >
>> >6. The icons at the bottom of the PB are so tiny on my screen that they
>> >are difficult to recognize (and my eyesight isn't great anyway.) I have
>> >to use the tooltips. That takes too long, so I just open the property
>> >inspector or use the menu items instead. I suppose with some use I'd
>> >memorize what each icon does, but the other issues have prevented me
>> >from becoming familiar enough with it.
>> >
>> >That's just what I remember from the few days I tried to work with it.
>> >I'm not convinced that the current design can accomodate my work style
>> >unless it can at least be revised to show a columnar view rather than a
>> >linear one. What I would have preferred is an update for the few
>> >glitches in the AB (mainly it doesn't always refresh automatically, and
>> >those blinking tooltips are positively aggressive) and give it a new
>> >coat of paint if you think it looks too dated. Its plain text layout
>> >with clear checkmarks is much easier for me to work with. I do like how
>> >you can change layering order by dragging in the PB, that would be a
>> >nice addition to the AB.
>> >
>> >--
>> >Jacqueline Landman Gay         |     [hidden email]
>> >HyperActive Software           |     http://www.hyperactivesw.com
>> >
>> >_______________________________________________
>> >use-livecode mailing list
>> >[hidden email]
>> >Please visit this url to subscribe, unsubscribe and manage your
>> >subscription preferences:
>> >http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>>
>>
>> _______________________________________________
>> use-livecode mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>_______________________________________________
>use-livecode mailing list
>[hidden email]
>Please visit this url to subscribe, unsubscribe and manage your
>subscription preferences:
>http://lists.runrev.com/mailman/listinfo/use-livecode



_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: App Browser versus Project Browser

Roger Eller
In reply to this post by Mark Waddingham-2
On Oct 7, 2015 3:02 PM, "Mark Waddingham" <[hidden email]> wrote:
>
> As an indication of community division it might be useful - app
browser/project browser/indifferent.
>
> However, I'm not sure a poll would give us the information we need as it
is too binary.

I personally don't like either one.  I rarely open AB or PB unless I'm
having trouble visualizing where an object exists within layers and
groups.  I would prefer something like Windows 7 has when you hold the
Super-key press TAB and all the open applications appear in a angled 3D
view.  If a stack could do that, and I could scroll through the actual-size
controls in an exploded 3D view, pick and relayer or edit the script of
objects, it would feel so much more 'real' and even jarvis-like.  Bring us
a future IDE that feels like it fell out of sci-fi, not just big icons of
every object in a stack including groups.

~Roger
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: App Browser versus Project Browser

J. Landman Gay
In reply to this post by ScottR
On 10/7/2015 6:20 PM, Scott Rossi wrote:

> IMO, Jacque makes a number of valid points.  In the Project Browser,
> because stacks and cards are contained in the single view, a long list of
> controls will remove any stack and card references from view, while in the
> Application Browser, stacks and cards are always visible.  It seems like
> applying an Application Browser layout to the Project Browser could make
> it more useful: move stack/card references to a left pane that is always
> visible.
>
> For myself, I also often rely on numerical references: card numbers, layer
> numbers, etc.  Filtering in the Project Browser is great, but it's not the
> same as sorting offered by the Application Browser (AFAICT the Project
> Browser doesn't offer sorting that I can see).

You can choose to sort layers from top to bottom, or bottom to top in
Preferences, but there's no option to sort by anything other than layers.

Suppose the project browser had a slide-out left panel that listed the
stacks and cards, like the app browser does now? Maybe it could be a
preference, and if it's turned off, the PB works the way it currently
does. If the panel option is turned on, it would keep its selection but
get out of the way if you need the screen space. People could choose if
they wanted to view by stack/card/object hierarchy with a panel, or just
single-list as it is now.

I definitely need card numbers and object IDs.

--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: App Browser versus Project Browser

ScottR
In reply to this post by Roger Eller
As soon as we get a means to irregularly distort images, I'm all for that
:-P

Regards,

Scott Rossi
Creative Director
Tactile Media, UX/UI Design




On 10/7/15, 6:38 PM, "use-livecode on behalf of Roger Eller"
<[hidden email] on behalf of
[hidden email]> wrote:

>On Oct 7, 2015 3:02 PM, "Mark Waddingham" <[hidden email]> wrote:
>>
>> As an indication of community division it might be useful - app
>browser/project browser/indifferent.
>>
>> However, I'm not sure a poll would give us the information we need as it
>is too binary.
>
>I personally don't like either one.  I rarely open AB or PB unless I'm
>having trouble visualizing where an object exists within layers and
>groups.  I would prefer something like Windows 7 has when you hold the
>Super-key press TAB and all the open applications appear in a angled 3D
>view.  If a stack could do that, and I could scroll through the
>actual-size
>controls in an exploded 3D view, pick and relayer or edit the script of
>objects, it would feel so much more 'real' and even jarvis-like.  Bring us
>a future IDE that feels like it fell out of sci-fi, not just big icons of
>every object in a stack including groups.
>
>~Roger
>_______________________________________________
>use-livecode mailing list
>[hidden email]
>Please visit this url to subscribe, unsubscribe and manage your
>subscription preferences:
>http://lists.runrev.com/mailman/listinfo/use-livecode



_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: App Browser versus Project Browser

mwieder
In reply to this post by Mark Waddingham-2
On 10/07/2015 11:54 AM, Mark Waddingham wrote:
> So if we had deleted the app browser stack from the build, would your point of view have changed and would you have started to use the project browser? ;)

Wow. I step away for a day and look what happens.
Interesting question.

I'd probably stay with previous builds and cut my ties with a company
that's out of touch with its user base.

--
  Mark Wieder
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
--
 Mark Wieder
 ahsoftware@gmail.com
Reply | Threaded
Open this post in threaded view
|

Re: App Browser versus Project Browser

Terry Judd-2
In reply to this post by J. Landman Gay
Like others I find the left pane of the app browser pretty useful. I¹ve
given the project browser a number of runs but usually end up returning to
the app browser because of the way it displays (simply) stacks and cards.
I don¹t much like the right pane of the app browser when there are lots of
objects involved, particularly if they are in nested groups but I usually
find myself struggling amongst those lists rather than opening up a second
tool (project browser).

My ideal hybrid would probably take the left pane of the app browser and
place the card controls of the project browser in the right pane,
maintaining the expandable/collapsible UI of the project browser. Add in a
layer number for each control and it¹s all good. The only other thing
would be a way to collapse all the controls in the right pane (unless it¹s
already there and I¹ve missed it). Do that and I¹ll happily let go of the
app browser and never look back.

Terry...

On 8/10/2015 1:47 pm, "use-livecode on behalf of J. Landman Gay"
<[hidden email] on behalf of
[hidden email]> wrote:

>On 10/7/2015 6:20 PM, Scott Rossi wrote:
>> IMO, Jacque makes a number of valid points.  In the Project Browser,
>> because stacks and cards are contained in the single view, a long list
>>of
>> controls will remove any stack and card references from view, while in
>>the
>> Application Browser, stacks and cards are always visible.  It seems like
>> applying an Application Browser layout to the Project Browser could make
>> it more useful: move stack/card references to a left pane that is always
>> visible.
>>
>> For myself, I also often rely on numerical references: card numbers,
>>layer
>> numbers, etc.  Filtering in the Project Browser is great, but it's not
>>the
>> same as sorting offered by the Application Browser (AFAICT the Project
>> Browser doesn't offer sorting that I can see).
>
>You can choose to sort layers from top to bottom, or bottom to top in
>Preferences, but there's no option to sort by anything other than layers.
>
>Suppose the project browser had a slide-out left panel that listed the
>stacks and cards, like the app browser does now? Maybe it could be a
>preference, and if it's turned off, the PB works the way it currently
>does. If the panel option is turned on, it would keep its selection but
>get out of the way if you need the screen space. People could choose if
>they wanted to view by stack/card/object hierarchy with a panel, or just
>single-list as it is now.
>
>I definitely need card numbers and object IDs.
>
>--
>Jacqueline Landman Gay         |     [hidden email]
>HyperActive Software           |     http://www.hyperactivesw.com
>
>_______________________________________________
>use-livecode mailing list
>[hidden email]
>Please visit this url to subscribe, unsubscribe and manage your
>subscription preferences:
>http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: App Browser versus Project Browser

Jerry Jensen
In reply to this post by ScottR
What Scott and Jacque wrote. I might add that it doesn’t take many controls to get confusing. Just a few modTableFields (thanks, Bernd!) that have fields named the same, and you can easily be lost. I can guess it would be even more confusing with datagrids.
.Jerry

> On Oct 7, 2015, at 4:20 PM, Scott Rossi <[hidden email]> wrote:
>
> IMO, Jacque makes a number of valid points.  In the Project Browser,
> because stacks and cards are contained in the single view, a long list of
> controls will remove any stack and card references from view, while in the
> Application Browser, stacks and cards are always visible.  It seems like
> applying an Application Browser layout to the Project Browser could make
> it more useful: move stack/card references to a left pane that is always
> visible.


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: App Browser versus Project Browser

Monte Goulding
In reply to this post by ScottR

> On 8 Oct 2015, at 2:19 pm, Scott Rossi <[hidden email]> wrote:
>
> As soon as we get a means to irregularly distort images, I'm all for that

How do you want to distort them? There’s an underlying affine transformation these days doing angle, flip & resize so anything you can do with affine transformations is up for grabs without huge amounts of effort.

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: App Browser versus Project Browser

Rolf Kocherhans-2
In reply to this post by Richmond Mathewson-2
+1 from me

Cheers
Rolf


> Agreed that satisfying everybody will never happen, but I would argue that
> the dual-pane approach of the Application Browser can display more
> information in a single view than the Project Browser.  IMO, accessing
> multiple stacks is more efficient using this approach compared to using a
> single scrolling list.
>
> Regards,
>
> Scott Rossi
> Creative Director
> Tactile Media, UX/UI Design

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: App Browser versus Project Browser

ScottR
In reply to this post by Monte Goulding
I had to look up "affine" (dude, you're getting technical) and my
impression is this type of distortion could be useful.  There appears to
be a type of transformation named "projective" which, if I understand what
it does, would be ideal.

Anyway, I posted an example here that illustrates the desired options in
LiveCode terms: good (single axis distortion) and best (irregular
distortion).  http://tactilemedia.com/download/image_distortion.jpg

:-)

Regards,

Scott Rossi
Creative Director
Tactile Media, UX/UI Design




On 10/7/15, 9:56 PM, "use-livecode on behalf of Monte Goulding"
<[hidden email] on behalf of
[hidden email]> wrote:

>
>> On 8 Oct 2015, at 2:19 pm, Scott Rossi <[hidden email]> wrote:
>>
>> As soon as we get a means to irregularly distort images, I'm all for
>>that
>
>How do you want to distort them? There¹s an underlying affine
>transformation these days doing angle, flip & resize so anything you can
>do with affine transformations is up for grabs without huge amounts of
>effort.
>
>_______________________________________________
>use-livecode mailing list
>[hidden email]
>Please visit this url to subscribe, unsubscribe and manage your
>subscription preferences:
>http://lists.runrev.com/mailman/listinfo/use-livecode



_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: App Browser versus Project Browser

Paul_Hibbert
This would be awesome!

Paul

> On 7 Oct 2015, at 23:37, Scott Rossi <[hidden email]> wrote:
>
> I had to look up "affine" (dude, you're getting technical) and my
> impression is this type of distortion could be useful.  There appears to
> be a type of transformation named "projective" which, if I understand what
> it does, would be ideal.
>
> Anyway, I posted an example here that illustrates the desired options in
> LiveCode terms: good (single axis distortion) and best (irregular
> distortion).  http://tactilemedia.com/download/image_distortion.jpg
>
> :-)
>
> Regards,
>
> Scott Rossi
> Creative Director
> Tactile Media, UX/UI Design
>
>
>
>
> On 10/7/15, 9:56 PM, "use-livecode on behalf of Monte Goulding"
> <[hidden email] on behalf of
> [hidden email]> wrote:
>
>>
>>> On 8 Oct 2015, at 2:19 pm, Scott Rossi <[hidden email]> wrote:
>>>
>>> As soon as we get a means to irregularly distort images, I'm all for
>>> that
>>
>> How do you want to distort them? There¹s an underlying affine
>> transformation these days doing angle, flip & resize so anything you can
>> do with affine transformations is up for grabs without huge amounts of
>> effort.
>>
>> _______________________________________________
>> use-livecode mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: App Browser versus Project Browser

Mark Waddingham-2
In reply to this post by xtalkprogrammer
On 2015-10-07 21:02, Mark Schonewille wrote:
> That is a strange question: if we take away something you like, would
> you use the one and only thing that's left?

I can see how (out of context) my question could have appeared to be
that, but it wasn't.

The previous post had indicated the following:

Was excited about a new component and tried Project Browser.

Did not see any advantages over the Application Browser.

Went back to Application Browser.

Continues to see Application Browser there, so continues to use
Application Browser.

i.e. There is was a strong hint that continued usage of the Application
Browser was related to its presence, rather than fondness.

Essentially I was trying to determine whether it was familiarity or like
which was the issue here.

So - yes - apologies for the slightly obscure and easy to take out of
context question (it probably didn't help it was top-posted due to using
iPhone mail, and not interleaved!).

Warmest Regards,

Mark

--
Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: App Browser versus Project Browser

Monte Goulding
In reply to this post by ScottR

> On 8 Oct 2015, at 5:37 pm, Scott Rossi <[hidden email]> wrote:
>
> Anyway, I posted an example here that illustrates the desired options in
> LiveCode terms: good (single axis distortion) and best (irregular
> distortion).  http://tactilemedia.com/download/image_distortion.jpg <http://tactilemedia.com/download/image_distortion.jpg>
I think will affine transformations you can skew on both axes but I think projective is a step up. The engine has functions for affine skew already so it sould be relatively easy to add skewX skewY properties to an image. The projective stuff would need investigation on whether Skia supports it.
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: App Browser versus Project Browser

AndyP
This post was updated on .
In reply to this post by Richmond Mathewson-2
I tend to use the AP more than PB.
I find the 2 column layout easier to navigate and quicker for finding what I want in a larger project.

In my view to make the AP better would just require.

1. A collapse button to collapse the RHS column so that the AP takes up less screen.
2. A filter field as in the current PB.
3. The OPTION to have thumbnails as per the PB.

All of the above should not impede the speed of the AP rendering (thumbnails excluded).
Andy Piddock

My software never has bugs. It just develops random features.

TinyIDE a Free alternative minimalist IDE Plugin for LiveCode

Script editor Themer for LC http://2108.co.uk

PointandSee is a FREE simple but full featured under cursor colour picker / finder. http://www.pointandsee.co.uk - made with LiveCode

123