Re: Death of the Application Browser

[Geoff Canyon]

On Wed, Dec 2, 2015 at 4:45 PM, Geoff Canyon  wrote:

> On Wed, Dec 2, 2015 at 2:41 PM, J. Landman Gay 
>  wrote:
>
>> Okay, good to know. As Hermann mentioned, he had to learn its
>> capabilities by reading our discussion. That's a problem I have with
>> Navigator too. Its actions can be obscure to the uninitiated and the
>> documentation is hard to use because it covers up what it's explaining.
>> There are some other usability issues that could benefit from a rework to
>> make Navigator easier for new users to understand.
>
>
> ​Yeah, apparently I could document better... That's a good point about the
> placement of the documentation, and easily fixed. If you care to list any
> other usability issues I'm all ears.​
>

​I had forgotten that I already took care of this. There was so much
documentation that it was contributing significantly to the byte-size of
Navigator. Also, formatting it well, and referencing other material (I've
made some videos, although they aren't included yet). So I pulled out all
the documentation and put it here:
https://gcanyon.wordpress.com/navigator-documentation/. A link to the docs
is still included directly in Navigator's about display.

This of course applies to the most recent updates of Navigator. I've just
added a preference setting for the display font size, and to toggle the
lines in the display. That version will be available after I've tested it.

I also noticed that Navigator already had a preference to display a tooltip
with the long id of the control in the list the pointer is over, but I find
that terribly distracting. I'm amazed it still works, since I haven't used
it in a decade.

gc
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[J. Landman Gay]

Well, in the interests of learning then:

On 12/2/2015 12:01 AM, Geoff Canyon wrote:

I see a list of stacks/cards on the left. So there could be
substantial scrolling to get to the stack/card you're looking for, right?


Yes, sometimes. But not as much as in the Project Browser because stacks 
and cards aren't included in the same list with controls, and because I 
can sort things in different ways to bring items of interest into a 
logical order. If I need to scroll, I always know where I'm at.



Then the list on the right is a straightforward list of everything on the
card: groups and controls. This is the same as Navigator, but much bulkier
and without the ability to have multiple copies open at once. Is it even
filterable/searchable?


Bulky: probably in the eye of the beholder. I prefer the spacing in the 
AB because my eyes aren't great and I find small, tightly packed text 
very hard to read. (Navigator is a problem for me in that respect, btw.) 
A related issue affects me in the PB: too much visual clutter, which 
again makes it difficult for me to locate things quickly. Suggestion for 
users like me: remove the showLines and increase the textheight in all 
the lists.


The AB isn't searchable, but if I want that I use the Search dialog in 
the main menu. I rarely need it. Filtering is also unavailable, but it 
must be useful because it's included in the PB too. If I could get it to 
work I might be able to assess its value, but so far I'm naive about it.



Screen space: Navigator collapses down to just its titlebar (and moves up
out of the way)with a double-click, and all can be collapsed at once (while
avoiding overlapping).


That's a nice touch. It adds to the number of clicks and manipulation 
necessary though for more than one navigator, and unfortunately, 
re-expanding a navigator covers up the others. I spent a little time 
yesterday seeing if I could simulate a list of stacks by lining up 
several navigators but it isn't very workable. Try opening 10+ 
navigators to see what I mean. I think it would work well for just a few 
instances though.



Each Navigator can be re-targeted, so the only reason to close one is if
you don't need that many open anymore. Navigator auto-updates if you choose.


Okay, good to know. As Hermann mentioned, he had to learn its 
capabilities by reading our discussion. That's a problem I have with 
Navigator too. Its actions can be obscure to the uninitiated and the 
documentation is hard to use because it covers up what it's explaining. 
There are some other usability issues that could benefit from a rework 
to make Navigator easier for new users to understand.




And finally, bookmarks and saved sets are definitely your friend here.
Although saved sets don't play well with the new ability to have multiple
Navigators open at once :-/ I'm going to have to look at that.


I may find a use for those some day, it sounds cool, though I don't 
generally work with the same set of controls repeatedly. When would you 
use those?


I have two primary useage cases for the AB: seeing an overview of an 
unfamiliar stack and how its parts fit together (and navigating it,) and 
quickly accessing an object's Property Inspector or script (even when it 
isn't the selected object.) I use the AB in many other ways too, of 
course, but those are the two things I do the most. It's 3 clicks max to 
get to any object, and then a right-click to open the inspector or the 
script.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Geoff Canyon]

On Wed, Dec 2, 2015 at 2:41 PM, J. Landman Gay 
wrote:

> (Navigator is a problem for me in that respect, btw.)


​Interesting. It's just a field, so this should work:

set the textSize of fld ​"list" of stack "revNavigator" to 14 -- or
whatever you like
save stack "revNavigator"

14 works nicely for me as well. The default is 10. You could change the
textFont as well. The style and color are set within Navigator, so that
wouldn't stick if you changed it.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Geoff Canyon]

On Wed, Dec 2, 2015 at 2:41 PM, J. Landman Gay 
 wrote:

> re-expanding a navigator covers up the others


​Only if you set them up to cover other Navigators -- it expands back to
where it was.

On Wed, Dec 2, 2015 at 2:41 PM, J. Landman Gay 
 wrote:

> I spent a little time yesterday seeing if I could simulate a list of
> stacks by lining up several navigators but it isn't very workable.


​I must still not be understanding this use case. Navigator has a list of
stacks in the stack menu. The trade-off of course is two clicks with the
menu in exchange for one click but having to give up screen real estate
constantly displaying the ​list. Is that it, or am I missing something
else? At this point I feel like I'm Steve Jobs telling you you're holding
the iPhone wrong ;-)

On Wed, Dec 2, 2015 at 2:41 PM, J. Landman Gay 
 wrote:

> Try opening 10+ navigators to see what I mean. I think it would work well
> for just a few instances though.
>

​Heh, although Navigator now supports pretty much unlimited copies of
itself, I've never needed to use more than 3. ​See the above Steve Jobs
comment...

On Wed, Dec 2, 2015 at 2:41 PM, J. Landman Gay 
 wrote:

> Okay, good to know. As Hermann mentioned, he had to learn its capabilities
> by reading our discussion. That's a problem I have with Navigator too. Its
> actions can be obscure to the uninitiated and the documentation is hard to
> use because it covers up what it's explaining. There are some other
> usability issues that could benefit from a rework to make Navigator easier
> for new users to understand.


​Yeah, apparently I could document better... That's a good point about the
placement of the documentation, and easily fixed. If you care to list any
other usability issues I'm all ears.​

On Wed, Dec 2, 2015 at 2:41 PM, J. Landman Gay 
wrote:

> I may find a use for those some day, it sounds cool, though I don't
> generally work with the same set of controls repeatedly. When would you use
> those?
>
> I have two primary useage cases for the AB: seeing an overview of an
> unfamiliar stack and how its parts fit together (and navigating it,) and
> quickly accessing an object's Property Inspector or script (even when it
> isn't the selected object.) I use the AB in many other ways too, of course,
> but those are the two things I do the most. It's 3 clicks max to get to any
> object, and then a right-click to open the inspector or the script.
>

​Control sets are intended for use if you switch back and forth on separate
projects. They let you have a set of frequently-used controls for each
project, and switch between them as you choose.

For studying an unfamiliar stack, to my eye AB and Nav are equivalent, but
for the above-listed difference between the stack list in AB and the stack
menu in Nav. Steve Jobs disclaimer here.

Script editing and property palettes (either Navigator's or LC's) are a
right-click away in Navigator, but also a double-click away (edits script
by default) or command-click away. Both are configurable.

Getting to any control is two menu selections: stack, then card; then the
complete control list is in front of you. Or Navigator can do both of the
menu selections automatically and just show you the current card of the
current stack.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Peter Haworth]

Hi Jacque,
Interesting discussion and just emphasizes how different folks have
different needs for the IDE.

I haven't jumped in before but I believe it will do everything you with
with the big exception of the "horizontal" layout issue. Here's a few
things that I think might help with that.

Geoff went with the multiple window approach to displaying different
stacks, I went with a tabbed approach where every main stack optionally
goes into a different tab in the single window so less screen space
needed.  You can also opt to have all your stacks in the same tab and then
drag/drop them onto other tabs if you want to separate them out.

You can hide the currently-selected stack/card or all but the
currently-selected stack/card so it's possible to show just the current
card and its controls if you want to.  And reveal them again of course :-)

The tooltip for an object includes it's complete owner tree so you don't
have to scroll to find who owns what. The only other thing that might help
is that the Home key scrolls to the selected object's owner.

Groups are displayed as a single line which can be expanded to show their
constituent controls.  That's an option of course, you can have them
initially expanded if you wish.

Those all help with the vertical/horizontal issue but I understand they
don't solve it completely.

Like you, I need relatively large text to read comfortably, especially if
the background isn't very contrasting. So I made lcStackbrowser completely
customizable for the text font, font size, font color, line height and
background color.

There's an inline property editor available with a single mouse click which
I admit adds to the vertical scrolling issue but most of the time you
expand the properties, do whatever, and collapse them again.

You can create your own groups of properties to suit the type of
application you're working on.  The groups can be displayed collapsed or
expanded so you can set up a group of your most-used properties and have it
display expanded when it's displayed.

There's a right-click menu option that displays all the boolean properties
of an object and clicking on one flips its value.  You can edit the name
and label/title of objects and the contents of simple fields without
expanding to show the properties.  There's a preference to display a label
field's text instead of its name since a whole bunch of fields named
"Label" doesn't really help you find which one you're looking for. And if
you really want to, you can open the IDE property inspector instead of
using lcStackbrowser's.

Documentation is a pet peeve of mine.  There are so many applications that
don't bother with it these days.  lcStackbrowser has a complete User Guide
and Quick reference card which lists all the keyboard shortcuts,  mouse
click actions and search syntax.

The layer/id/name of every object is displayed, albeit not in separate
columns.  There is a preference setting for the default sort sequence of
cards and controls and you can override that on an individual stack basis
via a right-click menu option.

If you have the need to search, you can do anything from a simple name
search to a complex search based on any combination of an object's
properties.  For example, I can search for all objects with their behavior
containing a certain string then with a right click change their behavior
to something else.

Probably the feature I'm using the most right now is Checkpoints since I'm
working with LC8 (lcStackbrowser already supports widgets) which has a
propensity to abort for no obvious reason.  With Checkpoints, I can have a
stack saved automatically at an interval I specify (5 minutes in my case),
and with a right click, get a list of the available checkpoints and
rollback to any one of them.  If LC aborts, I just restart and go back to
my latest checkpoint so I never lose more than 5 minutes work. I could also
have a checkpoint created every time I save or only when I request one
manually via a right click menu and, again optionally, associate a comment
with each checkpoint.  Lots of options for how many checkpoints to keep
around too.

In the last release, I added the ability to restore deleted objects of any
sort because I'm clumsy and sometimes delete the wrong object and once it's
gone, it's gone for good unless you go back to a previous version of the
stack and lose all the other work you've done before the deletion.

I've been trying to think of how I might introduce an AB type layout with a
separate field for controls.  I mentioned above the ability to drag/drop a
stack to a different tab.  I think it would be possible to allow dragging a
card to a different tab which would get pretty close to the AB although an
extra click would be required to move between the tab with the
card/controls on it and the tab with its owner on it.  I'll have to look
into that and see what it would take.

Pete
lcSQL Software 
Home of lcStackBrowser 

Re: Death of the Application Browser

[J. Landman Gay]

On 12/2/2015 4:38 PM, Peter Haworth wrote:

Interesting discussion and just emphasizes how different folks have
different needs for the IDE.


I was wondering when you'd jump in. :) To be fair, I have only looked at 
your screen shots on the web site (they're very small on my screen, btw, 
so not easily deciphered.) I saw it was a vertical list and didn't 
pursue it. I should grab the trial.


One problem with all the various control browsers is that they all have 
a learning curve and my time is very short. If I have to study and 
memorize in order to use a stack, I probably won't. That's a generic 
statement, unrelated to lcStackBrowser -- I haven't actually tried it 
yet so I can't say. Your feature list sounds good, though my needs are 
pretty basic and the duplication of existing IDE features wouldn't be 
important to me.


It could be important to other people, of course -- but I've got 15 
years of LC habits behind me and I'm comfortable with it.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Peter Haworth]

Absolutely, and they all have their own benefits.

Pete
lcSQL Software 
Home of lcStackBrowser  and
SQLiteAdmin 

On Wed, Dec 2, 2015 at 3:30 PM, Geoff Canyon  wrote:

> On Wed, Dec 2, 2015 at 5:38 PM, Peter Haworth  wrote:
>
> > Hi Jacque,
> > Interesting discussion and just emphasizes how different folks have
> > different needs for the IDE.
> >
> >
> ​We certainly do have an embarrassment of riches when it comes to project
> tools ;-)​
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Geoff Canyon]

On Wed, Dec 2, 2015 at 5:38 PM, Peter Haworth  wrote:

> Hi Jacque,
> Interesting discussion and just emphasizes how different folks have
> different needs for the IDE.
>
>
​We certainly do have an embarrassment of riches when it comes to project
tools ;-)​
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[J. Landman Gay]

On 12/2/2015 3:45 PM, Geoff Canyon wrote:

>I spent a little time yesterday seeing if I could simulate a list of
>stacks by lining up several navigators but it isn't very workable.


​I must still not be understanding this use case. Navigator has a list of
stacks in the stack menu. The trade-off of course is two clicks with the
menu in exchange for one click but having to give up screen real estate
constantly displaying the ​list. Is that it, or am I missing something
else? At this point I feel like I'm Steve Jobs telling you you're holding
the iPhone wrong ;-)


It's an obscure usage case, I admit. In my big project, all but two 
stacks are clones of a template stack. Each stack has a unique 
identifiable name. Cards are named by a coding system that doesn't 
provide a clear identifier (though I'm starting to remember some of the 
codes now.) About half the cards in any given stack have controls 
identical to the parallel cards in other stacks, including the same 
names and IDs. And since the stacks are clones, most of the cards also 
have IDs identical to the other stacks.


In this situation it is impossible to know where you are unless you can 
always see the stack name. So I was trying to get the same view in 
Navigator that I get in AB where the stack I'm in is always clearly 
visible. In Navigator, once I leave the stack list, I could be anywhere. 
It's true that when I select a stack I know where I am immediately after 
that, but if I work for a while and then go back to Navigator, I've 
likely forgotten which stack it's displaying. The names of the controls 
don't help me, and the card names are all IDs. So then I have to go back 
to the main stack list and renavigate to where I was before, just to 
identify what the stack was.


And to make things more interesting, I usually have a whole bunch of 
cloned stacks open at the same time. It all comes back to breadcrumbs 
for me.


BTW, I found the stack list, which has to be accessed via a popdown 
menu, but I can't find how to disply its card list.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Geoff Canyon]

On Wed, Dec 2, 2015 at 2:41 PM, J. Landman Gay 
wrote:

> remove the showLines


​This should work as well.​
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Geoff Canyon]

On Wed, Dec 2, 2015 at 7:10 PM, J. Landman Gay 
wrote:

> In this situation it is impossible to know where you are unless you can
> always see the stack name. So I was trying to get the same view in
> Navigator that I get in AB where the stack I'm in is always clearly
> visible. In Navigator, once I leave the stack list, I could be anywhere.
> It's true that when I select a stack I know where I am immediately after
> that, but if I work for a while and then go back to Navigator, I've likely
> forgotten which stack it's displaying. The names of the controls don't help
> me, and the card names are all IDs. So then I have to go back to the main
> stack list and renavigate to where I was before, just to identify what the
> stack was.
>
> And to make things more interesting, I usually have a whole bunch of
> cloned stacks open at the same time. It all comes back to breadcrumbs for
> me.
>
> BTW, I found the stack list, which has to be accessed via a popdown menu,
> but I can't find how to disply its card list.
>

​Ah, now I get it. For exactly this reason, the latest version of Navigator
sets the title bar to the path, like:

card "display" of stack "fundamental"
card id 1002 of stack "untitled"

​If you hold down the option key and click the stack menu (to display rev
stacks) you can select the "Message Box" stack. Then the card menu should
list:

this card
Card List
-
Single Line
Multiple Lines
Global Properties
Global Variables
pendingMessages
frontScripts
backScripts
stacksInUse

Which is all the cards. If you care to, you can select "Card List" and then
the list will display:

stack "Message Box"
card "Single Line" [1002]
card "Multiple Lines" [1011]
card "Global Properties" [1012]
card "Global Variables" [1013]
card "pendingMessages" [1014]
card "frontScripts" [1015]
card "backScripts" [1016]
card "stacksInUse" [1147]

Depending on which version of Navigator you have, and how your preferences
are set.

gc
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Scott Rossi]

Yeah, all three of us.  ;-)

Regards,

Scott Rossi
Creative Director
Tactile Media, UX/UI Design




On 12/1/15, 1:24 PM, "use-livecode on behalf of J. Landman Gay"
 wrote:

>You will be everyone's hero. I can't wait. :)
>
>On 12/1/2015 2:51 PM, Scott Rossi wrote:
>> I'm waiting for an LC release that has the AB available as a plugin and
>>to
>> look into doing exactly what you suggest.
>>
>> Regards,
>>
>> Scott Rossi
>> Creative Director
>> Tactile Media, UX/UI Design
>>
>>
>>
>>
>> On 12/1/15, 11:49 AM, "use-livecode on behalf of J. Landman Gay"
>> > jac...@hyperactivesw.com> wrote:
>>
>>> On 12/1/2015 3:53 AM, Monte Goulding wrote:
>>   But IDs are imperative when I get an error message like this:
>>
>>   Hint: field id 12345 of card id 2069 of stackŠ
 Failing a proper mobile debugger some way to scroll to an object
 reference in the project browser would work for this. It probably
would
 require a menu and a dialog to enter the object reference.
>>>
>>> That would be more fiddly than just looking at a column of IDs.
>>>
>>> So far the things we've talked about are work-arounds for the lack of a
>>> column view. The best solution would be to enhance the AB and include
>>>it
>>> as an alternate layout in the PB. It doesn't need much updating if the
>>> only goal is to make it "pretty".
>>>
>>> --
>>> Jacqueline Landman Gay | jac...@hyperactivesw.com
>>> HyperActive Software   | http://www.hyperactivesw.com
>>>
>>>
>>> ___
>>> use-livecode mailing list
>>> use-livecode@lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>>
>>
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>>subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>
>
>-- 
>Jacqueline Landman Gay | jac...@hyperactivesw.com
>HyperActive Software   | http://www.hyperactivesw.com
>
>
>___
>use-livecode mailing list
>use-livecode@lists.runrev.com
>Please visit this url to subscribe, unsubscribe and manage your
>subscription preferences:
>http://lists.runrev.com/mailman/listinfo/use-livecode



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[J. Landman Gay]

On 12/1/2015 12:53 AM, Geoff Canyon wrote:

Navigator doesn't do the Finder column view exactly


That's the blocker for me, not just in Navigator but in all the 
alternate control browsers I've looked at (four so far.) All the 
alternatives are well written and feature-rich, but they are all use 
either separate lists, or very long lists with indentations to indicate 
owners and groups. With any more than a few controls, the indentations 
scroll off the window and you've lost your reference point.


The alternatives all appear to be very good tools for someone who works 
only on their own stacks with a limited number of controls. In that 
case, you already know the layout and structure, and it's fine to 
isolate things into independent lists and groups, or indented lists 
which won't be so long that they require a lot of scrolling or the 
additional overhead of repeated filtering. (And don't get me started on 
the PB filtering. There is no documentation in the user guide, and I 
can't remember the secret syntax that even lets me isolate a control 
type. In the AB you can just click on a header to do that.)


But a lot of my work involves short sprints with stacks that other 
people have written, where I don't know the layout or the organization. 
Controls often have no names and use haphazard layouts. I need an 
overview that doesn't require a lot of clicking around and doesn't 
require me to memorize what objects are on what card before I can 
navigate accurately. In that situation, isolated lists of things don't 
work, you always have to know where you are on the map. I need to jump 
from one place to another repeatedly, and the easiest way to do that is 
with a hierarchical breadcrumb display.


My ideal control browser would be based on the paned column view of the 
App Browser with some of the additional features of the PB added. I wish 
the AB had been enhanced rather than rewritten as an infinite list of 
awkwardly accessible controls that displays less information in a larger 
footprint.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[J. Landman Gay]

You will be everyone's hero. I can't wait. :)

On 12/1/2015 2:51 PM, Scott Rossi wrote:

I'm waiting for an LC release that has the AB available as a plugin and to
look into doing exactly what you suggest.

Regards,

Scott Rossi
Creative Director
Tactile Media, UX/UI Design




On 12/1/15, 11:49 AM, "use-livecode on behalf of J. Landman Gay"
 wrote:


On 12/1/2015 3:53 AM, Monte Goulding wrote:

  But IDs are imperative when I get an error message like this:

  Hint: field id 12345 of card id 2069 of stackŠ

Failing a proper mobile debugger some way to scroll to an object
reference in the project browser would work for this. It probably would
require a menu and a dialog to enter the object reference.


That would be more fiddly than just looking at a column of IDs.

So far the things we've talked about are work-arounds for the lack of a
column view. The best solution would be to enhance the AB and include it
as an alternate layout in the PB. It doesn't need much updating if the
only goal is to make it "pretty".

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode




___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode




--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Scott Rossi]

I'm waiting for an LC release that has the AB available as a plugin and to
look into doing exactly what you suggest.

Regards,

Scott Rossi
Creative Director
Tactile Media, UX/UI Design




On 12/1/15, 11:49 AM, "use-livecode on behalf of J. Landman Gay"
 wrote:

>On 12/1/2015 3:53 AM, Monte Goulding wrote:
>>> >  But IDs are imperative when I get an error message like this:
>>> >
>>> >  Hint: field id 12345 of card id 2069 of stackŠ
>> Failing a proper mobile debugger some way to scroll to an object
>>reference in the project browser would work for this. It probably would
>>require a menu and a dialog to enter the object reference.
>
>That would be more fiddly than just looking at a column of IDs.
>
>So far the things we've talked about are work-arounds for the lack of a
>column view. The best solution would be to enhance the AB and include it
>as an alternate layout in the PB. It doesn't need much updating if the
>only goal is to make it "pretty".
>
>-- 
>Jacqueline Landman Gay | jac...@hyperactivesw.com
>HyperActive Software   | http://www.hyperactivesw.com
>
>
>___
>use-livecode mailing list
>use-livecode@lists.runrev.com
>Please visit this url to subscribe, unsubscribe and manage your
>subscription preferences:
>http://lists.runrev.com/mailman/listinfo/use-livecode



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Geoff Canyon]

I'm not sure I understand. If you have two buttons that you want to work
with, and the buttons are each three groups deep on separate cards in
separate stacks, then if you were looking at button "a" and wanted to look
at button "b" wouldn't a column view require you to:

1. Click on the stack containing button "b"
2. Click on the card in the stack containing button "b"
3. Click on the group on the card in the stack containing button "b"
4. Click on the group within that group on the card in the stack containing
button "b"
5. Click on button "b" to do whatever with it.

...and then rinse and repeat each time you want to switch

With Navigator you can either:

1. Open two copies of Navigator.
2. In one, navigate to button "a"
3. In one, navigate to button "b"

... and then leave both Navigators that way so you can easily work on the
two buttons.

Or:
1. Navigate to button "a" and bookmark it
2. Navigate to button "b" and bookmark it
3. Work with the bookmarks in any way you like.

And note that you can rename the bookmarks any way you like, so although
they start as something like:

 button "Button" [1008] of card id 1002 of stack "Untitled 1"

You could change it to:

 Account Management Library -- button "Button" [1008] of card id 1002
of stack "Untitled 1"


And as an aside, Navigator has two easy ways of filtering controls:

The filter box simply filters on the text displayed in Navigator, so it's
easy to type "button" to see only buttons (assuming no fields are named
"button") or type (part of) the id of a control to show it.

The Filter... command on the Actions menu lets you type any livecode you
like, using tID to reference the control in question. So for example, this
will work as a filter:

word 1 of the name of tID is "button" and (the height of tID is 30 or char
3 of the short name of tID is "b")

gc



On Tue, Dec 1, 2015 at 3:39 PM, J. Landman Gay 
wrote:

> On 12/1/2015 12:53 AM, Geoff Canyon wrote:
>
>> Navigator doesn't do the Finder column view exactly
>>
>
> That's the blocker for me, not just in Navigator but in all the alternate
> control browsers I've looked at (four so far.) All the alternatives are
> well written and feature-rich, but they are all use either separate lists,
> or very long lists with indentations to indicate owners and groups. With
> any more than a few controls, the indentations scroll off the window and
> you've lost your reference point.
>
> The alternatives all appear to be very good tools for someone who works
> only on their own stacks with a limited number of controls. In that case,
> you already know the layout and structure, and it's fine to isolate things
> into independent lists and groups, or indented lists which won't be so long
> that they require a lot of scrolling or the additional overhead of repeated
> filtering. (And don't get me started on the PB filtering. There is no
> documentation in the user guide, and I can't remember the secret syntax
> that even lets me isolate a control type. In the AB you can just click on a
> header to do that.)
>
> But a lot of my work involves short sprints with stacks that other people
> have written, where I don't know the layout or the organization. Controls
> often have no names and use haphazard layouts. I need an overview that
> doesn't require a lot of clicking around and doesn't require me to memorize
> what objects are on what card before I can navigate accurately. In that
> situation, isolated lists of things don't work, you always have to know
> where you are on the map. I need to jump from one place to another
> repeatedly, and the easiest way to do that is with a hierarchical
> breadcrumb display.
>
> My ideal control browser would be based on the paned column view of the
> App Browser with some of the additional features of the PB added. I wish
> the AB had been enhanced rather than rewritten as an infinite list of
> awkwardly accessible controls that displays less information in a larger
> footprint.
>
>
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.com
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Geoff Canyon]

On Tue, Dec 1, 2015 at 5:37 PM, Geoff Canyon  wrote:

> 1. Navigate to button "a" and bookmark it
> 2. Navigate to button "b" and bookmark it
> 3. Work with the bookmarks in any way you like.
>

Also, Navigator can bookmark the mouseControl, so you don't have to
"navigate" to anything, really. If you're looking at the control (and
there's nothing in front of it, obviously) you can bookmark it that way
without having to know its name or id, or anything really.

There's no way to create a bookmark using a given long id (the way you
might based on your error report scenario. That's an interesting feature to
add to the list.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[J. Landman Gay]

On 12/1/2015 4:37 PM, Geoff Canyon wrote:

I'm not sure I understand. If you have two buttons that you want to work
with, and the buttons are each three groups deep on separate cards in
separate stacks, then if you were looking at button "a" and wanted to look
at button "b" wouldn't a column view require you to:

1. Click on the stack containing button "b"
2. Click on the card in the stack containing button "b"
3. Click on the group on the card in the stack containing button "b"
4. Click on the group within that group on the card in the stack containing
button "b"
5. Click on button "b" to do whatever with it.

...and then rinse and repeat each time you want to switch


Groups are always expanded in the AB and substacks are always in the 
stack list, so you're never more than 3 clicks away from anything. (You 
can collapse the substacks, but I don't.) That's the advantage of a 
column layout.


You're right that two Navigators would eliminate the back and forth, 
though at the expense of screen space and a lot of manual manipulation. 
Imagine 25 Navigators, and the need to manually add a new one for each 
additional stack you open (and remove the old ones you don't need any 
more.) There are hundreds of stacks in this particular system, though I 
rarely open more than a couple dozen at a time. But those swap in and 
out of memory as I open and close various parts of the collection. An 
auto-updating text list is easier to work with.


I'm guessing my needs are unique, and also that the rest of the list is 
getting tired of us by now, so I'll taper off. Unless LC eliminates the 
AB entirely I'm okay. This discussion began because I thought they had, 
and I'm glad I was wrong.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[[-hh]]

> Jacqueline L.G. wrote:
> I'm guessing my needs are unique, and also that the rest of the list is 
> getting tired of us by now, so I'll taper off.

No, certainly no. I learned a lot from this whole discussion and became also an 
impression of very interesting working styles that I will also try to use 
(parts of).

I also started to use Geoff C.'s "revNavigator" which I overlooked in the 
plugins menu (also other valuable things). Perhaps one should read this thread 
before using it, there were many details about it and other tools to read one 
can find nowhere else (?).

Hermann
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Geoff Canyon]

On Tue, Dec 1, 2015 at 6:48 PM, J. Landman Gay 
wrote:

> Groups are always expanded in the AB and substacks are always in the stack
> list, so you're never more than 3 clicks away from anything. (You can
> collapse the substacks, but I don't.) That's the advantage of a column
> layout.
>

I'm only asking this because I want to learn (in case this comes off as
argumentative) -- I'm not seeing this. It's my first time in forever with
the AB. I see a list of stacks/cards on the left. So there could be
substantial scrolling to get to the stack/card you're looking for, right?

Then the list on the right is a straightforward list of everything on the
card: groups and controls. This is the same as Navigator, but much bulkier
and without the ability to have multiple copies open at once. Is it even
filterable/searchable?



> You're right that two Navigators would eliminate the back and forth,
> though at the expense of screen space and a lot of manual manipulation.
> Imagine 25 Navigators, and the need to manually add a new one for each
> additional stack you open (and remove the old ones you don't need any
> more.) There are hundreds of stacks in this particular system, though I
> rarely open more than a couple dozen at a time. But those swap in and out
> of memory as I open and close various parts of the collection. An
> auto-updating text list is easier to work with.
>

Screen space: Navigator collapses down to just its titlebar (and moves up
out of the way)with a double-click, and all can be collapsed at once (while
avoiding overlapping).

Each Navigator can be re-targeted, so the only reason to close one is if
you don't need that many open anymore. Navigator auto-updates if you choose.

And finally, bookmarks and saved sets are definitely your friend here.
Although saved sets don't play well with the new ability to have multiple
Navigators open at once :-/ I'm going to have to look at that.

gc
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Geoff Canyon]

On Tue, Dec 1, 2015 at 8:00 PM, [-hh]  wrote:

> I also started to use Geoff C.'s "revNavigator" which I overlooked in the
> plugins menu (also other valuable things). Perhaps one should read this
> thread before using it, there were many details about it and other tools to
> read one can find nowhere else (?).


Yeah, many times it's easier to add a feature than to document it -- not
sure whether that deserves a winky face or a sad face.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[J. Landman Gay]

On 12/1/2015 3:53 AM, Monte Goulding wrote:

>  But IDs are imperative when I get an error message like this:
>
>  Hint: field id 12345 of card id 2069 of stack…

Failing a proper mobile debugger some way to scroll to an object reference in 
the project browser would work for this. It probably would require a menu and a 
dialog to enter the object reference.


That would be more fiddly than just looking at a column of IDs.

So far the things we've talked about are work-arounds for the lack of a 
column view. The best solution would be to enhance the AB and include it 
as an alternate layout in the PB. It doesn't need much updating if the 
only goal is to make it "pretty".


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Monte Goulding]

> On 1 Dec 2015, at 5:57 pm, J. Landman Gay  wrote:
> Number-name would work, though it isn't as easy to read as a column. But I'd 
> be okay with it. Not sure what you mean by "object descriptor" though.

I just meant that some folks might like "number. name" and others might like 
"name (number)" and others might like "[id] name (number)” and some way to 
specify in the preferences might be good. Even just a range of choices might 
help.

>  But IDs are imperative when I get an error message like this:
> 
>  Hint: field id 12345 of card id 2069 of stack…

Failing a proper mobile debugger some way to scroll to an object reference in 
the project browser would work for this. It probably would require a menu and a 
dialog to enter the object reference.
> 
> Left-clicking the name should change the target object that will be acted on. 
> Double-clicking a name should both change the target and additionally 
> navigate to it in the stack.

Yes, I suspect the navigate on single click is one of those cases where it 
works well for people new to the platform but for complicated apps I at least 
do a lot of work without opening the stacks I’m working on. You might change 
one thing and know it’s going to cause errors elsewhere so you change a lot of 
things before wanting to open the stack to test. Perhaps this could be a 
preference too?

> Right-clicking should present the contextual menu and leave the original 
> target intact.

This appears to be the case already. In LC 7.1 I see that when using a 
contextual menu on a control will fail and the selected row will be the target 
but in LC 8 this works fine. The problem I find with LC 8 is that you can’t 
browse to a grouped control without selecting and navigating to the group 
because the clicking the flipper does that. I suspect this is just a bug.
> 
> And a feature request: It would be nice to be able to copy or cut an object 
> from elsewhere and paste it into the current card you're looking at, without 
> needing to first change your location to go get that object.

Yes that would be nice.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Dave Kilroy]

Having another look at the PB and AP side-by-side this afternoon - apart from
one being essentially vertical and the other horizontal it seems the two
things missing on the PB are display of control ids and easy sorting by
layer, visibility and selectibility

- control ids - in the AP these (and parent ids) are shown in tooltips
- sorting - in the AP it is easy to sort by number, visibility and
selectibility

In the PB settings you can only sort by layer (top-to-bottom or
bottom-to-top) but only as a global option - @Mark Waddingham could we add
ability to sort by visibility and selectibility?

Also @Mark Waddingham, could we give users the choice to change tooltip
display between the control name or full id like is done in the AP?

Kind regards

Dave



-
"The difference between genius and stupidity is; genius has its limits." - 
Albert Einstein
--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Release-8-0-DP-10-tp4698978p4699208.html
Sent from the Revolution - User mailing list archive at Nabble.com.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Bob Sneidar]

On Nov 26, 2015, at 12:07 , Scott Rossi 
> wrote:

I doubt anybody is arguing with you.

Well...  is. :-)

Bob S

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Dr. Hawkins]

On Sat, Nov 28, 2015 at 10:50 PM, Brahmanathaswami  wrote:

> Jacque: can you detail your requirements that make it a must for your
> stacks to use the AP?
>

I'm not Jacqui, but the biggest single thing for me is the information
density:  the application browser puts far more on the screen, in those
nice single lines.  A close runner up is the extra clicks in the project
browse/  (for that matter, it should be fully navigable, including
collapse/expand, from the keyboard.


-- 
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[J. Landman Gay]

On 11/29/2015 12:50 AM, Brahmanathaswami wrote:

Jacque: can you detail your requirements that make it a must for your
stacks to use the AP?


1. Horizontal/column view so it is easy to drill down from stack to card 
to object, and see their relationships to everything else. Basically I 
want Finder column view.

2. I need to see card numbers and object layer numbers.
3. I need to see IDs for all cards and objects.
4. I need the ability to open the property inspector for an unselected 
object for quick reference, without changing the current selection or 
location.


I'll probably think of other things. The main problem for me is the 
amount of scrolling necessary to locate things, the inability to see 
where I'm at in the object hierarchy, and the way the PB forces unwanted 
navigation.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Monte Goulding]

Thanks Jacque, this is a good list.
> On 1 Dec 2015, at 7:41 am, J. Landman Gay  wrote:
> 
> 1. Horizontal/column view so it is easy to drill down from stack to card to 
> object, and see their relationships to everything else. Basically I want 
> Finder column view.

Yes, I think this would be helpful too. A list view could probably also be 
implemented along with something like cover flow as an option to use instead of 
the thumbnails.

> 2. I need to see card numbers and object layer numbers.

Would it be sufficient to have something like .  instead of just 
? Perhaps there might be a way in preferences to specify an object 
descriptor to use??? This would be a fairly lightweight change I think. Trying 
to add proper columns would be much more work.

> 3. I need to see IDs for all cards and objects.

Do you need to see IDs all the time or just sometimes? What do you need them 
for? the tooltip gives you the long ID in LC 8. Would it be helpful to have a 
Copy Object Reference > Short ID … Long Name in the contextual menu? What about 
drag and drop object references to the script editor or drag an image off the 
browser and drop on a button and it sets the icon and IDs into the property 
inspector? All fairly easy fixes but you need to detail what you are using the 
ID for to see if they resolve the issue.

> 4. I need the ability to open the property inspector for an unselected object 
> for quick reference, without changing the current selection or location.

Yes! Me too. Perhaps a preference whether clicking on the flipper of a group 
selects the object and actions from the contextual menu shouldn’t select the 
object. You should need to click on the name to select the object and open the 
stack. I expect this isn’t all that tricky a change either.
> 
> I'll probably think of other things. The main problem for me is the amount of 
> scrolling necessary to locate things, the inability to see where I'm at in 
> the object hierarchy, and the way the PB forces unwanted navigation.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Dr. Hawkins]

On Mon, Nov 30, 2015 at 12:41 PM, J. Landman Gay 
wrote:

> 1. Horizontal/column view so it is easy to drill down from stack to card
> to object, and see their relationships to everything else. Basically I want
> Finder column view.
> 2. I need to see card numbers and object layer numbers.
> 3. I need to see IDs for all cards and objects.
> 4. I need the ability to open the property inspector for an unselected
> object for quick reference, without changing the current selection or
> location.
>

I knew I'd agree with her . . .




-- 
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Geoff Canyon]

On Sun, Nov 29, 2015 at 4:57 PM, Paul Looney  wrote:

> I personally use Geoff's Navigator all the time. I find it indispensable!
> I have never liked the Application Browser.
>
> I’m always surprised at how few people have even heard of the Navigator -
> let alone actually using it - despite the fact that it is bundled with
> LiveCode.
>
> Thanks again, Geoff.
>
> Paul Looney
>

You're welcome, and despite the lack of attention I've given Navigator over
the past ten years or so, I have to admit a certain perverse joy that it
still functions as well as it does. I'm a bit concerned about how it will
fare with LC 8's new control types though...
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[J. Landman Gay]

On 11/30/2015 4:29 PM, Monte Goulding wrote:

Thanks Jacque, this is a good list.


I deleted a long commentary before I hit Send. :)





2. I need to see card numbers and object layer numbers.


Would it be sufficient to have something like . 
instead of just ? Perhaps there might be a way in preferences
to specify an object descriptor to use??? This would be a fairly
lightweight change I think. Trying to add proper columns would be
much more work.


Number-name would work, though it isn't as easy to read as a column. But 
I'd be okay with it. Not sure what you mean by "object descriptor" though.





3. I need to see IDs for all cards and objects.


Do you need to see IDs all the time or just sometimes?


Just sometimes, but I usually leave IDs in view anyway. The tooltips in 
the AB make me crazy so I turn off tooltips (and I don't want them in LC 
8 either, but they're better than nothing.) I keep the ID column visible 
in the App Browser instead.



What do you
need them for? the tooltip gives you the long ID in LC 8. Would it be
helpful to have a Copy Object Reference > Short ID … Long Name in the
contextual menu? What about drag and drop object references to the
script editor or drag an image off the browser and drop on a button
and it sets the icon and IDs into the property inspector? All fairly
easy fixes but you need to detail what you are using the ID for to
see if they resolve the issue.


I do need IDs for icons, so either the "copy short ID" or drag/drop you 
suggest would be great -- as long as clicking on the image to drag it 
didn't change the selection. But IDs are imperative when I get an error 
message like this:


  Hint: field id 12345 of card id 2069 of stack...

This is common in mobile apps, and when it shows up it's almost 
impossible to find the object if you can't scan a list for IDs. In the 
App Browser you can display the IDs in their own column, and then sort 
the controls by ID. It only takes seconds to find the object that way. 
When I'm working on mobile apps I always have the ID column in the App 
Browser showing.


Which reminds me, someone mentioned the ability to sort by various 
criteria and this example is one of those times I need that. I work a 
lot on other people's stacks and you'd be surprised how many people 
never name the controls.





4. I need the ability to open the property inspector for an
unselected object for quick reference, without changing the current
selection or location.


Yes! Me too. Perhaps a preference whether clicking on the flipper of
a group selects the object and actions from the contextual menu
shouldn’t select the object. You should need to click on the name to
select the object and open the stack. I expect this isn’t all that
tricky a change either.


Agreed. Left-clicking the name should change the target object that will 
be acted on. Double-clicking a name should both change the target and 
additionally navigate to it in the stack. Right-clicking should present 
the contextual menu and leave the original target intact.


And a feature request: It would be nice to be able to copy or cut an 
object from elsewhere and paste it into the current card you're looking 
at, without needing to first change your location to go get that object.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Geoff Canyon]

On Mon, Nov 30, 2015 at 3:41 PM, J. Landman Gay 
wrote:

> 1. Horizontal/column view so it is easy to drill down from stack to card
> to object, and see their relationships to everything else. Basically I want
> Finder column view.
>

Navigator doesn't do the Finder column view exactly -- there is a menu with
all the cards listed, and you can select any of them to see everything on
that card. There's also a card list view, which shows all the cards (in
case there are too many to show on a menu) and you can right-click any card
to browse its controls. The list is filterable (as all control lists are)
to make it easy to find the one you're looking for.


> 2. I need to see card numbers and object layer numbers.
>

Navigator doesn't do this at all -- it never occurred to me. What's the
purpose? It would be easy to add in general, but maybe a little bother to
get right with the filtering.


> 3. I need to see IDs for all cards and objects.
>

Done, this is a preference setting.


> 4. I need the ability to open the property inspector for an unselected
> object for quick reference, without changing the current selection or
> location.
>

In the preferences, unhilite AutoUpdate Selection. Then either right click
and select Object Inspector (N) or set the prefs so a double-click,
option-double-click, or option-command-double-click opens the object
inspector. Or use Navigator's built-in property tools.

Oh, or make a bookmark of the controls -- clicking bookmarks doesn't update
the selection.


> I'll probably think of other things. The main problem for me is the amount
> of scrolling necessary to locate things
>

For really long lists of controls the filter function is your friend here.
And the ability to open multiple Navigators. I was especially pleased when
I made *everything* in Navigator behavior-based, so you can have dozens of
copies if you need -- and a titlebar-double-click minimizes any of them, or
a command-double-click in any titlebar minimizes/opens all of them.

Bookmarks also help here. Wow, and saved control sets. I'd forgotten I did
this. Bookmark whatever controls you like, then save and name the set. You
can have as many sets as you like, and swap them out with a menu selection
whenever you like. It seems control sets are local to a specific copy of
Navigator, so I should look at that.

, the inability to see where I'm at in the object hierarchy,
>

Navigator does this well for me, but YMMV

and the way the PB forces unwanted navigation.
>

See the above, and again YMMV.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Paul Looney]

I personally use Geoff's Navigator all the time. I find it indispensable! I 
have never liked the Application Browser.

I’m always surprised at how few people have even heard of the Navigator - let 
alone actually using it - despite the fact that it is bundled with LiveCode.

Thanks again, Geoff.

Paul Looney

> On Nov 26, 2015, at 7:50 PM, Geoff Canyon  wrote:
> 
> Have you tried Navigator? It is a very simple list view, fairly quick, can
> be made small and collapses down even smaller, and allows for multiple
> instances so you can see/work with many separate stacks at the same time.
> 
> I only kinda sorta support it though, so your mileage may vary. The version
> included with LC is nowhere near up to date. I can send you a more recent
> one if you like. Also, I haven't updated Navigator at all for LC 8, so I
> don't know at all how well it handles the new LCB controls.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Monte Goulding]

It really would be better of people enumerated the problems they have with the 
new IDE stacks rather than just say use them and see. We all do things 
differently and the problems you see might not be the problems I see.

Sent from my iPhone

> On 29 Nov 2015, at 9:50 pm, [-hh]  wrote:
> 
> And here in advance a tip for the handful of persons here who
> think that *everything* new is better

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[[-hh]]

> > R. Mathewson wrote:
> > Although I would still like to know why it has been
> > downgraded to a Plug-in. 

> M. Wieder wrote:
> Actually, I don't see that as a downgrade at all. Making 
> it a plugin allows it to be more malleable, fixable,
> replaceable. Taking it out of the IDE hierarchy should
> give us more options to work on the Application Browser. 
> Since the team wants to do other things, it's up to the
> community to fix the AB, and making it a plugin makes it  
> easier to do so. 

Reading that one could wish, the LC 7 property inspector
could become upgraded to a plugin too.

And here in advance a tip for the handful of persons here who
think that *everything* new is better (there are improvements,
but also changes for the worse).

== Just try both, the oldPI and the newPI, with small stacks
and large stacks, then you don't need a listing of what is good
and what should become better with the newPI.

== And just try both, the AB and the new PB, with small stacks
and large stacks, then you don't need a listing of what is good
enough and what should become better with the PB.

Hermann

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Brahmanathaswami]

OK, I'm glad I deferred again from even testing 8+... without the AB I 
would be lost.


But, I really like the visual look-and-feel option of icons and previews 
etc in the PB... that said, there are definitely scenarios where you 
want really lean lists for stacks with many cards, many controls... if a 
single card has 50 controls (not unusual) then the BP becomes overly 
long and you lose the over view.


 So now I find myself using both...But just because we *can* use 
both... I think it is very "retro"  and actually a little irritating to 
switch back and forth.


So, I agree with Monte. Why don't we just work together to make the 
Project Browser that much more "awesome" than even the current AP?


Jacque: can you detail your requirements that make it a must for your 
stacks to use the AP?


Other than the icons and visuals forcing a super oversized tree that 
becomes hard to navigate, what other things does the AB do that the PB 
does not? You can get to the inspector and the script just as fast for 
any object.


BR

Monte Goulding wrote:

What I don't really understand is why people aren't offering suggestions on how 
to improve the project browser so it will work for them. To my mind the simple 
solution would be to have multiple layout modes (tree, list, column) and the 
ability to detach chunks of the hierarchy into a separate window by double 
clicking or dragging. That would open up a world of possibilities for copying 
and moving objects around.



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Brahmanathaswami]

Ooops... i replied to an earlier post before reading all the latest 
discussion.


Yeah... I use lcStackbrowser too..




Brahmanathaswami wrote:
OK, I'm glad I deferred again from even testing 8+... without the AB I 
would be lost.


But, I really like the visual look-and-feel option of icons and 
previews etc in the PB... that said, there are definitely scenarios 
where you want really lean lists for stacks with many cards, many 
controls... if a single card has 50 controls (not unusual) then the BP 
becomes overly long and you lose the over view.


 So now I find myself using both...But just because we *can* use 
both... I think it is very "retro"  and actually a little irritating 
to switch back and forth.


So, I agree with Monte. Why don't we just work together to make the 
Project Browser that much more "awesome" than even the current AP?


Jacque: can you detail your requirements that make it a must for your 
stacks to use the AP?


Other than the icons and visuals forcing a super oversized tree that 
becomes hard to navigate, what other things does the AB do that the PB 
does not? You can get to the inspector and the script just as fast for 
any object.


BR

Monte Goulding wrote:
What I don't really understand is why people aren't offering 
suggestions on how to improve the project browser so it will work for 
them. To my mind the simple solution would be to have multiple layout 
modes (tree, list, column) and the ability to detach chunks of the 
hierarchy into a separate window by double clicking or dragging. That 
would open up a world of possibilities for copying and moving objects 
around.



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-livecode



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Richmond]

On 27/11/15 16:12, Kevin Miller wrote:

Richmond,

Real people work at LiveCode. Often they work long hours and are here late
into the evenings. We care a great deal about our community.

I was out of the office yesterday and returned today to find two team
members stressed and demotivated. I enquired as to the cause. They felt
that your posts were a personal attack on their good work and wholly
unrepresentative of their intentions. Considering the intensity of the
work undertaken of late I must say that strikes me as very unfair.

I have reviewed your posts and they fall way below an acceptable standard
of politeness or respect. Would you really like to be on the receiving end
of some of the comments you wrote? Will you consider an apology?

Kind regards,

Kevin




I do apologise fully, and I am sorry if my word demotivated members of 
your team:

I assure you that was far from my aim.

Richmond.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Kevin Miller]

Richmond,

Real people work at LiveCode. Often they work long hours and are here late
into the evenings. We care a great deal about our community.

I was out of the office yesterday and returned today to find two team
members stressed and demotivated. I enquired as to the cause. They felt
that your posts were a personal attack on their good work and wholly
unrepresentative of their intentions. Considering the intensity of the
work undertaken of late I must say that strikes me as very unfair.

I have reviewed your posts and they fall way below an acceptable standard
of politeness or respect. Would you really like to be on the receiving end
of some of the comments you wrote? Will you consider an apology?

Kind regards,

Kevin

Kevin Miller ~ ke...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps




On 26/11/2015 20:24, "use-livecode on behalf of Richmond"
 wrote:

>On 26/11/15 22:02, Mark Wieder wrote:
>> On 11/26/2015 10:36 AM, Richmond wrote:
>>
>>> Although I would still like to know why it has been downgraded to a
>>> Plug-in.
>>
>> Actually, I don't see that as a downgrade at all.
>> Making it a plugin allows it to be more malleable, fixable,
>> replaceable. Taking it out of the IDE hierarchy should give us more
>> options to work on the Application Browser. Since the team wants to do
>> other things,
>
>Aah, so the team isn't going to bother to listen to the Community
>because it wants to do other things;
>so it is chucking the Application Browser out to grass.
>
>> it's up to the community to fix the AB, and making it a plugin makes
>> it easier to do so.
>
>Makes me wonder, again, again, about that word: "community".
>
>R.
>
>
>___
>use-livecode mailing list
>use-livecode@lists.runrev.com
>Please visit this url to subscribe, unsubscribe and manage your
>subscription preferences:
>http://lists.runrev.com/mailman/listinfo/use-livecode



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Richmond]

On 27/11/15 00:19, Fraser Gordon wrote:

On 26/11/15 20:24, Richmond wrote:
Aah, so the team isn't going to bother to listen to the Community 
because it wants to do other things;

so it is chucking the Application Browser out to grass.

I'm not sure I follow. The application browser isn't going anywhere. 
If it works for you already, why refine it any further?


It is probably working fine at the moment; but, by hiving it off into the
Plug-ins it means that no further development is likely to be done on 
it, and, as new features
in LiveCode are implemented it may be that it will no longer keep up 
with those

developments.



If it doesn't meet your needs then wouldn't resources be better spent 
improving one tool to meet everybody's needs than trying to keep two 
at feature parity?


On the other hand, the LiveCode community contains many outstanding 
developers. If you have an idea on how to make the AB better, please 
go ahead and do so. Moving the AB to a plugin rather than a core part 
of the IDE makes this much easier, both to develop and distribute (for 
example, making it more difficult to break the IDE!). I'd be delighted 
if someone makes an Application Browser++ Awesome Edition plugin.


The future of LiveCode is extensibility and 8 is the first step on 
that journey. Widgets are one part. Making the IDE pluggable is another.


In short, the change to a plugin is a structural change, not an 
abandonment.


I hope so.
 However, time will tell.


Fraser



Richmond.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Fraser Gordon]

On 26/11/15 20:24, Richmond wrote:
Aah, so the team isn't going to bother to listen to the Community 
because it wants to do other things;

so it is chucking the Application Browser out to grass.

I'm not sure I follow. The application browser isn't going anywhere. If 
it works for you already, why refine it any further?


If it doesn't meet your needs then wouldn't resources be better spent 
improving one tool to meet everybody's needs than trying to keep two at 
feature parity?


On the other hand, the LiveCode community contains many outstanding 
developers. If you have an idea on how to make the AB better, please go 
ahead and do so. Moving the AB to a plugin rather than a core part of 
the IDE makes this much easier, both to develop and distribute (for 
example, making it more difficult to break the IDE!). I'd be delighted 
if someone makes an Application Browser++ Awesome Edition plugin.


The future of LiveCode is extensibility and 8 is the first step on that 
journey. Widgets are one part. Making the IDE pluggable is another.


In short, the change to a plugin is a structural change, not an abandonment.

Fraser


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Peter W A Wood]

> On 27 Nov 2015, at 04:26, Richmond  wrote:

> For exactly the same reason why the Application Browser is being hived off to 
> the "community",
> because, while Lip-service is being paid to listening to the community . . .

Given Mark Waddingham’s recent view of LiveCode stacks and GPL, if the 
Application Browser is hived off to the community anybody using it would only 
be able to sell it under the GPL. :-)

Peter



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Monte Goulding]

> On 27 Nov 2015, at 7:07 am, Scott Rossi  wrote:
> 
> I doubt anybody is arguing with you.  I think most agree that the Project 
> Browser is a great step toward a modern editor.  But the capabilities lacking 
> in the Project Browser have been pointed out numerous times -- see the mail 
> archives.  Perhaps a better question to ask is why these have been pointed 
> out repeatedly and not acted upon, or at least acknowledged.

I think their persistence with the project browser has actually resulted in a 
number of performance optimisations and features in the engine which we all 
benefit from image cache, object reference optimisations, snapshot at size and 
possibly others are direct results of their effort to improve the project 
browser implementation. I don’t doubt that they are keen to provide what we 
need to get the job done and will look for solutions where the existing 
implementation doesn’t work. My point is to try and avoid the “i prefer the app 
browser so leave it in” or even the “the project browser doesn’t work for this 
reason” type comments and come up with constructive options that could be added 
to the project browser to resolve the situation. If all they are hearing is a 
handful of people saying they don’t like it and want to use the application 
browser instead then can you blame them for coming up with a solution of 
putting the application browser in plugins for those users?

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Monte Goulding]

> On 27 Nov 2015, at 9:24 am, Peter W A Wood  wrote:
> 
> Given Mark Waddingham’s recent view of LiveCode stacks and GPL, if the 
> Application Browser is hived off to the community anybody using it would only 
> be able to sell it under the GPL. :-)

Actually that would appear to only be the case if the edits were made using 
LiveCode Community as the IDE is MIT licensed:
https://github.com/livecode/livecode-ide/blob/develop/IDE%20License.txt 


Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Mark Wieder]

On 11/26/2015 10:36 AM, Richmond wrote:


Althought I would still like to know why it has been downgraded to a
Plug-in.


Actually, I don't see that as a downgrade at all.
Making it a plugin allows it to be more malleable, fixable, replaceable. 
Taking it out of the IDE hierarchy should give us more options to work 
on the Application Browser. Since the team wants to do other things, 
it's up to the community to fix the AB, and making it a plugin makes it 
easier to do so.


--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Monte Goulding]

> On 27 Nov 2015, at 7:02 am, Mark Wieder  wrote:
> 
> Actually, I don't see that as a downgrade at all.
> Making it a plugin allows it to be more malleable, fixable, replaceable. 
> Taking it out of the IDE hierarchy should give us more options to work on the 
> Application Browser. Since the team wants to do other things, it's up to the 
> community to fix the AB, and making it a plugin makes it easier to do so.

It would probably be better if it were no longer distributed with the IDE at 
all if you are thinking of community maintenance.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Scott Rossi]

I doubt anybody is arguing with you.  I think most agree that the Project 
Browser is a great step toward a modern editor.  But the capabilities lacking 
in the Project Browser have been pointed out numerous times -- see the mail 
archives.  Perhaps a better question to ask is why these have been pointed out 
repeatedly and not acted upon, or at least acknowledged.

Regards,

Scott Rossi
Creative Director
Tactile Media UX/UI Design

> On Nov 26, 2015, at 11:04 AM, Monte Goulding  wrote:
> 
> It's clearly a waste of resources to maintain two things that are intended to 
> provide the same service. Do you do that in your apps?
> 
> What I don't really understand is why people aren't offering suggestions on 
> how to improve the project browser so it will work for them. To my mind the 
> simple solution would be to have multiple layout modes (tree, list, column) 
> and the ability to detach chunks of the hierarchy into a separate window by 
> double clicking or dragging. That would open up a world of possibilities for 
> copying and moving objects around.
> 
> Cheers
> 
> Monte
> 
> Sent from my iPhone
> 
>> On 27 Nov 2015, at 5:36 am, Richmond  wrote:
>> 
>> Althought I would still like to know why it has been downgraded to a Plug-in.
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[[-hh]]

> J. LG wrote:
> Something like that would work for me ...

If such wonderful things could be realized (will be a feature-exchange),
what should then the significantly confused crowd of newcomers do?
Use the Application browser plugin?

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Richmond]

On 26/11/15 22:02, Mark Wieder wrote:

On 11/26/2015 10:36 AM, Richmond wrote:


Although I would still like to know why it has been downgraded to a
Plug-in.


Actually, I don't see that as a downgrade at all.
Making it a plugin allows it to be more malleable, fixable, 
replaceable. Taking it out of the IDE hierarchy should give us more 
options to work on the Application Browser. Since the team wants to do 
other things,


Aah, so the team isn't going to bother to listen to the Community 
because it wants to do other things;

so it is chucking the Application Browser out to grass.

it's up to the community to fix the AB, and making it a plugin makes 
it easier to do so.


Makes me wonder, again, again, about that word: "community".

R.


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Richmond]

On 26/11/15 22:07, Scott Rossi wrote:

I doubt anybody is arguing with you.  I think most agree that the Project 
Browser is a great step toward a modern editor.  But the capabilities lacking 
in the Project Browser have been pointed out numerous times -- see the mail 
archives.  Perhaps a better question to ask is why these have been pointed out 
repeatedly and not acted upon, or at least acknowledged.


For exactly the same reason why the Application Browser is being hived 
off to the "community",

because, while Lip-service is being paid to listening to the community . . .

R.



Regards,

Scott Rossi
Creative Director
Tactile Media UX/UI Design


On Nov 26, 2015, at 11:04 AM, Monte Goulding  wrote:

It's clearly a waste of resources to maintain two things that are intended to 
provide the same service. Do you do that in your apps?

What I don't really understand is why people aren't offering suggestions on how 
to improve the project browser so it will work for them. To my mind the simple 
solution would be to have multiple layout modes (tree, list, column) and the 
ability to detach chunks of the hierarchy into a separate window by double 
clicking or dragging. That would open up a world of possibilities for copying 
and moving objects around.

Cheers

Monte

Sent from my iPhone


On 27 Nov 2015, at 5:36 am, Richmond  wrote:

Althought I would still like to know why it has been downgraded to a Plug-in.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[[-hh]]

@Monte:
> If all they are hearing is a handful of people saying they don’t like it
> and want to use the application browser instead then can you blame them
> for coming up with a solution of putting the application browser in
> plugins for those users?

People in this list are saying repeatedly since two years (in my words):

I would like to have that project browser does at least the same functional
(working) things as the application browser.

This *is* a very clear and voluminous *constructive* critique.


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Monte Goulding]

> On 27 Nov 2015, at 11:11 am, [-hh]  wrote:
> 
> I would like to have that project browser does at least the same functional
> (working) things as the application browser.

While it may seem like there are a lot of people saying this stuff there’s 
actually only a handful. The project browser appears to have all the same 
features (plus a good deal more) as the application browser. The only thing it 
doesn’t have as far as I can tell is the separate card view which I agree often 
means you can end up a little lost if you ave a complex hierarchy with a lot of 
objects deeply nested in groups. Personally I think the app browser card view 
can also get a bit hectic if there’s a lot of objects in nested groups. That’s 
why I suggested having options to drag out an object and have it be the root 
node of tree in a new window. Also perhaps a simple pulldown button so the list 
might only show the current card of the top stack, the whole top stack, open 
stacks, main stacks etc. Something like that should only take a small amount of 
time to implement but could make it much more functional with large projects.

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Monte Goulding]

> On 27 Nov 2015, at 11:58 am, Peter W A Wood  wrote:
> 
> Given Mark’s earlier explanation, it is difficult to see how the IDE can be 
> MIT licensed.

I posted the link to the license file in the repo. I don’t think I can do much 
more than that to prove it ;-)

> After all, it is just a stack and if other stacks run with the Community 
> engine can only be issued under the GPL, surely the IDE can only be issued 
> under the GPL if it is run by the Community engine?

As the owners of the copyright it is within their rights to license it however 
they see fit. They have not restricted themselves from distributing stacks 
under licenses other than the GPL.

> In fact, surely anything distributed within LiveCode Community must be under 
> the GPL? 

If this were the case then they would have trouble putting the engine together 
at all as none of the libraries they use are GPL otherwise they could not 
distribute a commercial engine...
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Peter W A Wood]

Monte 

> On 27 Nov 2015, at 06:29, Monte Goulding  wrote:
> 
> 
>> On 27 Nov 2015, at 9:24 am, Peter W A Wood  wrote:
>> 
>> Given Mark Waddingham’s recent view of LiveCode stacks and GPL, if the 
>> Application Browser is hived off to the community anybody using it would 
>> only be able to sell it under the GPL. :-)
> 
> Actually that would appear to only be the case if the edits were made using 
> LiveCode Community as the IDE is MIT licensed:
> https://github.com/livecode/livecode-ide/blob/develop/IDE%20License.txt 
> 

Given Mark’s earlier explanation, it is difficult to see how the IDE can be MIT 
licensed. After all, it is just a stack and if other stacks run with the 
Community engine can only be issued under the GPL, surely the IDE can only be 
issued under the GPL if it is run by the Community engine? In fact, surely 
anything distributed within LiveCode Community must be under the GPL? 

Regards

Peter
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Geoff Canyon]

Have you tried Navigator? It is a very simple list view, fairly quick, can
be made small and collapses down even smaller, and allows for multiple
instances so you can see/work with many separate stacks at the same time.

I only kinda sorta support it though, so your mileage may vary. The version
included with LC is nowhere near up to date. I can send you a more recent
one if you like. Also, I haven't updated Navigator at all for LC 8, so I
don't know at all how well it handles the new LCB controls.

On Thu, Nov 26, 2015 at 2:36 PM, J. Landman Gay 
wrote:

> On 11/26/2015 1:04 PM, Monte Goulding wrote:
>
>> What I don't really understand is why people aren't offering
>> suggestions on how to improve the project browser so it will work for
>> them. To my mind the simple solution would be to have multiple layout
>> modes (tree, list, column) and the ability to detach chunks of the
>> hierarchy into a separate window by double clicking or dragging. That
>> would open up a world of possibilities for copying and moving objects
>> around.
>>
>
> Something like that would work for me. The list had a long discussion
> about this before and I'm sure the team read it. It mainly comes down to
> those of us who work with very large stacks (mine contain hundreds or
> thousands of objects over 50 or more cards per stack.) The best way to work
> with stacks like this is to have a column view like Finder offers where you
> can see breadcrumbs that display the relationship of objects to their
> owners.
>
> In my case, every stack is a clone of a master stack with only text and
> some objects replaced. That means that cards have no names (only IDs) and
> most objects are named identically across all the stacks. It isn't possible
> to identify where you are in the Project Browser because the containing
> group, card, or stack has scrolled out of view.
>
> Another issue is the visual clutter, which I find very difficult to work
> with. I'd like to see the plainest kind of text list possible. I have
> already turned off thumbnails because outside of the clutter, they slow
> down the browser unacceptably when it is trying to update that many objects
> repeatedly. Even so, it is still too slow to work with. The App Browser
> updates instantly because it is pure text.
>
> If the Project Browser could respond faster and offer column view so I
> know which object belongs to which card and stack I could possibly work
> with it.
>
> If the team would like an example to work with, they have already signed
> the NDA for my big project and it shows these issues clearly. If they no
> longer have the stacks, I'd be very happy to resend them.
>
> (Finally, I hope I didn't show any claws, though I admit that removing the
> App Browser would force me to remain in LC 7 indefinitely and I had a
> moment of despair.)
>
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.com
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Mark Wieder]

On 11/26/2015 02:19 PM, Fraser Gordon wrote:

I'd be delighted if someone makes an Application Browser++ Awesome Edition 
plugin.


lcStackBrowser
Now if it were only dual-licensed...

--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[[-hh]]

>> J. LG wrote:
>> It needs to come back. I can't work without it. Project browser is not an
>> acceptable replacement for the kind of stacks I work with. 
> 
> I stopped to edit any stack in LC 8.
> 
> The Project Browser is beautiful to look at, also the Property Inspector,
> beautiful design, but there are too much things one can NOT do.
> 
> It's twice as fast to quit LC 8, to open LC 7 and do the simplest edit in LC 
> 7's
> Application Browser supported by LC 7's Property inspector.
> 
> For me it's the pair (Application Browser, LC 7 - Property Inspector) that is
> much more useful, for EACH AND EVERY stack.

That was me, I don't know why I became anonymous, I'm not.

Hermann
[-hh]
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Peter TB Brett]

On 26/11/2015 02:10, Mark Wieder wrote:

On 11/25/2015 01:38 PM, Richmond wrote:

On 25/11/15 22:54, Ali Lloyd wrote:

It was put into the plugins menu in DP 9. Apologies for the lack of
release
note to that effect.



Then why does it not show up menu/development/plugins  ???


Nor in /opt/livecode/livecodecommunity-8.0.0-dp-10.x86_64/Plugins
Looks like it's just gone.


Oh dear, that sounds like a bug.  I'll look into it.

  Peter

--
Dr Peter Brett 
LiveCode Open Source Team

LiveCode on reddit: https://reddit.com/r/livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Ali Lloyd]

http://quality.livecode.com/show_bug.cgi?id=16497

On Thu, Nov 26, 2015 at 9:13 AM Peter TB Brett 
wrote:

> On 26/11/2015 02:10, Mark Wieder wrote:
> > On 11/25/2015 01:38 PM, Richmond wrote:
> >> On 25/11/15 22:54, Ali Lloyd wrote:
> >>> It was put into the plugins menu in DP 9. Apologies for the lack of
> >>> release
> >>> note to that effect.
> >>>
> >>>
> >> Then why does it not show up menu/development/plugins  ???
> >
> > Nor in /opt/livecode/livecodecommunity-8.0.0-dp-10.x86_64/Plugins
> > Looks like it's just gone.
>
> Oh dear, that sounds like a bug.  I'll look into it.
>
>Peter
>
> --
> Dr Peter Brett 
> LiveCode Open Source Team
>
> LiveCode on reddit: https://reddit.com/r/livecode
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Peter TB Brett]

On 25/11/2015 23:13, Mark Schonewille wrote:

Does this mean that [the Application Browser] is no longer supported?


*Everything* shipped with LiveCode is supported.  If we don't intend to 
support it, we don't ship it.


Bearing that in mind:

1) In general, we have found that the Project Browser is easier to use 
by newcomers to LiveCode, and easier to explain in training materials.


2) We also found that there was significant confusion caused by the 
presence of both "Project Browser" and "Application Browser" in the 
"Tools" menu, which was leading to users trying to follow instructions 
and ending up in completely the wrong place.


3) In the LiveCode 8 development team, we made a conscious decision to 
focus our resources on the Project Browser, because most of our users 
(and most of us) find it easier to use.  This means that the LiveCode 8 
Application Browser has received fewer feature improvements and testing 
that the Project Browser.


The Application Browser has been moved to the "Plugins" menu.  This 
improves the usability of the IDE, makes it easier to produce 
easy-to-follow training materials, and reflects the fact that we are 
slightly less confident about the Application Browser than the Project 
Browser.


If you find any bugs in LiveCode -- for example, an Application Browser 
that is unusable or missing -- then please file a bug (or if you have a 
support contract, contact ).  The core development 
team does, in fact, fix bugs.


Ali has investigated and has found that the Application Browser was 
missing from the latest *Development Preview* release of LiveCode 8 due 
to a bug, which is now fixed.


I'm sure you'll be delighted to hear that the Application Browser plugin 
will be included in the next LiveCode 8 release.


 Peter

--
Dr Peter Brett 
LiveCode Open Source Team

LiveCode on reddit: https://reddit.com/r/livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Richmond]

On 26/11/15 04:10, Mark Wieder wrote:

On 11/25/2015 01:38 PM, Richmond wrote:

On 25/11/15 22:54, Ali Lloyd wrote:

It was put into the plugins menu in DP 9. Apologies for the lack of
release
note to that effect.



Then why does it not show up menu/development/plugins  ???


Nor in /opt/livecode/livecodecommunity-8.0.0-dp-10.x86_64/Plugins
Looks like it's just gone.



It wasn't in the plug-ins folder of DP 9.

Richmond.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[[-hh]]

Peter B. wrote:

> 1) In general, we have found that the Project Browser is easier to use 
> by newcomers to LiveCode, and easier to explain in training materials.

There is nearly no difference if you have one button and one field.

> 2) We also found that there was significant confusion caused by the 
> presence of both "Project Browser" and "Application Browser" in the 
> "Tools" menu, which was leading to users trying to follow instructions 
> and ending up in completely the wrong place.

What makes you think that the whole big community has that confusion too?
I'm only 30 months with LC, I can use already both without any confusion.

> 3) In the LiveCode 8 development team, we made a conscious decision to 
> focus our resources on the Project Browser, because most of our users 
> (and most of us) find it easier to use.  This means that the LiveCode 8 
> Application Browser has received fewer feature improvements and testing 
> that the Project Browser.

The "most of us" may be true.
But on which data is the wording "most of our users" based?

The discussion is NOT about the quality of the project Browser, it has it's 
(high) qualities. It's about its lack of certain important features, in sum:

It's *unusable* if you have a real big stack, just try.

Given your arguments are valid, you should consequently make a LC-Lite version, 
for real beginners. (Good idea, isn't it?)

But do NOT diminish improvements and testing and do NOT cut, as now, one of the 
most valuable parts from the full version.

Hermann
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Peter TB Brett]

On 26/11/2015 13:33, [-hh] wrote:

But do NOT diminish improvements and testing and do NOT cut, as now, one of the 
most valuable parts from the full version.


As I explained, the absence of the Application Browser from the latest 
Developer Preview release was a bug which will be fixed in the next DP 
release.


Peter

--
Dr Peter Brett 
LiveCode Open Source Team

LiveCode on reddit: https://reddit.com/r/livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Mark Wieder]

On 11/26/2015 01:37 AM, Peter TB Brett wrote:


Ali has investigated and has found that the Application Browser was
missing from the latest *Development Preview* release of LiveCode 8 due
to a bug, which is now fixed.


Peter, Ali- thanks for that.



I'm sure you'll be delighted to hear that the Application Browser plugin
will be included in the next LiveCode 8 release.


Indeed.

--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Richmond]

On 26/11/15 15:33, [-hh] wrote:

Peter B. wrote:


1) In general, we have found that the Project Browser is easier to use
by newcomers


So, all we give a damn about are newcomers . . .


  to LiveCode, and easier to explain in training materials.


Funny that; my group of 9 to 15 year old, non-native speakers had no 
trouble at all with

the Application Browser.

Oh, but that's probably because I'm a qualified and highly experienced 
teacher who CAN explain things

properly.


There is nearly no difference if you have one button and one field.


I've got several buttons, and getting rid of the Application Browser just
pushed one of them quite hard.




2) We also found that there was significant confusion caused by the
presence of both "Project Browser" and "Application Browser" in the
"Tools" menu, which was leading to users trying to follow instructions

Mun be the "instructions: were screived by some one who did not do their job
very well.

and ending up in completely the wrong place.

What makes you think that the whole big community has that confusion too?
I'm only 30 months with LC, I can use already both without any confusion.


I would suppose we are to take that as implying that we, your loyal 
user-base, are all glaikit.


This would not be the first time that aspersions have been cast upon us.

You micht be better to hearken to your user base, lest they decide they 
will not thole

any longer to that sort of handling.




3) In the LiveCode 8 development team, we made a conscious decision to
focus our resources on the Project Browser, because most of our users
(and most of us) find it easier to use.  This means that the LiveCode 8
Application Browser has received fewer feature improvements and testing
that the Project Browser.


Before you made your "conscious decision" you could have taken a few 
more depth-soundings

than you obviously did . . .

Too fast, too furious, and losing sight of what's important: I've said 
it before.



The "most of us" may be true.
But on which data is the wording "most of our users" based?

The discussion is NOT about the quality of the project Browser, it has it's 
(high) qualities. It's about its lack of certain important features, in sum:

It's *unusable* if you have a real big stack, just try.

Given your arguments are valid, you should consequently make a LC-Lite version, 
for real beginners. (Good idea, isn't it?)

But do NOT diminish improvements and testing and do NOT cut, as now, one of the 
most valuable parts from the full version.

Hermann



Richmond.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Richard Gaskin]

Richmond wrote:


I've got several buttons, and getting rid of the Application Browser just
pushed one of them quite hard.


Peter and Ali have already made multiple posts noting that the omission 
of the App Browser is a bug which will be fixed in the next build.


One of the benefits of counting to ten before expressing annoyance is 
that it provides your In Box a moment to catch up to find out if the 
annoyance is needed at all.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for Desktop, Mobile, and Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Richmond]

On 26/11/15 19:32, Richard Gaskin wrote:

Richmond wrote:

I've got several buttons, and getting rid of the Application Browser 
just

pushed one of them quite hard.


Peter and Ali have already made multiple posts noting that the 
omission of the App Browser is a bug which will be fixed in the next 
build.


One of the benefits of counting to ten before expressing annoyance is 
that it provides your In Box a moment to catch up to find out if the 
annoyance is needed at all.




The fact that the Application Browser was removed, and the bumf that the 
representatives of the mothership

trotted out:

" In general, we have found that the Project Browser is easier to use
by newcomers to LiveCode, and easier to explain in training materials." 
and so on


are quite sufficient to show that they had NO intention at all of doing 
anything but dumping
Application Browser, and that they back-tracked when they realised that 
people that HAVE to

listen to (Ms. Gay) had unsheathed their claws.

So, stop writing apologia for Peter and Ali: it is so flipping obvious

This sort of attitude does not do much for customer relations.

Richmond.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Mark Waddingham]

On 2015-11-26 19:23, Richmond wrote:

Application Browser, and that they back-tracked when they realised
that people that HAVE to
listen to (Ms. Gay) had unsheathed their claws.


There was absolutely no back-tracking at all.

The PR to move the Application Browser to a plugin was done quite a 
while ago:


https://github.com/livecode/livecode-ide/pull/594

It was merged into 'develop' for dp-9 15 days ago. However, as it turns 
out, we had omitted adding it to the description file the installer 
builder uses to build the installers, hence the plugin did not appear in 
dp-9 nor dp-10. This was a bug, which was quickly rectified after you 
pointed out its omission.


So, stop writing apologia for Peter and Ali: it is so flipping 
obvious


Richard is not writing apologia. He was merely stating facts - which he 
checked before posting :)


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Richmond]

On 26/11/15 20:31, Mark Waddingham wrote:

On 2015-11-26 19:23, Richmond wrote:

Application Browser, and that they back-tracked when they realised
that people that HAVE to
listen to (Ms. Gay) had unsheathed their claws.


There was absolutely no back-tracking at all.

The PR to move the Application Browser to a plugin was done quite a 
while ago:


https://github.com/livecode/livecode-ide/pull/594

It was merged into 'develop' for dp-9 15 days ago. However, as it 
turns out, we had omitted adding it to the description file the 
installer builder uses to build the installers, hence the plugin did 
not appear in dp-9 nor dp-10. This was a bug, which was quickly 
rectified after you pointed out its omission.


So, stop writing apologia for Peter and Ali: it is so flipping 
obvious


Richard is not writing apologia. He was merely stating facts - which 
he checked before posting :)


Warmest Regards,

Mark.



OK: you've put me right.

Thanks.

Althought I would still like to know why it has been downgraded to a 
Plug-in.


Richmond.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Monte Goulding]

It's clearly a waste of resources to maintain two things that are intended to 
provide the same service. Do you do that in your apps?

What I don't really understand is why people aren't offering suggestions on how 
to improve the project browser so it will work for them. To my mind the simple 
solution would be to have multiple layout modes (tree, list, column) and the 
ability to detach chunks of the hierarchy into a separate window by double 
clicking or dragging. That would open up a world of possibilities for copying 
and moving objects around.

Cheers

Monte

Sent from my iPhone

> On 27 Nov 2015, at 5:36 am, Richmond  wrote:
> 
> Althought I would still like to know why it has been downgraded to a Plug-in.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[J. Landman Gay]

On 11/26/2015 1:04 PM, Monte Goulding wrote:

What I don't really understand is why people aren't offering
suggestions on how to improve the project browser so it will work for
them. To my mind the simple solution would be to have multiple layout
modes (tree, list, column) and the ability to detach chunks of the
hierarchy into a separate window by double clicking or dragging. That
would open up a world of possibilities for copying and moving objects
around.


Something like that would work for me. The list had a long discussion 
about this before and I'm sure the team read it. It mainly comes down to 
those of us who work with very large stacks (mine contain hundreds or 
thousands of objects over 50 or more cards per stack.) The best way to 
work with stacks like this is to have a column view like Finder offers 
where you can see breadcrumbs that display the relationship of objects 
to their owners.


In my case, every stack is a clone of a master stack with only text and 
some objects replaced. That means that cards have no names (only IDs) 
and most objects are named identically across all the stacks. It isn't 
possible to identify where you are in the Project Browser because the 
containing group, card, or stack has scrolled out of view.


Another issue is the visual clutter, which I find very difficult to work 
with. I'd like to see the plainest kind of text list possible. I have 
already turned off thumbnails because outside of the clutter, they slow 
down the browser unacceptably when it is trying to update that many 
objects repeatedly. Even so, it is still too slow to work with. The App 
Browser updates instantly because it is pure text.


If the Project Browser could respond faster and offer column view so I 
know which object belongs to which card and stack I could possibly work 
with it.


If the team would like an example to work with, they have already signed 
the NDA for my big project and it shows these issues clearly. If they no 
longer have the stacks, I'd be very happy to resend them.


(Finally, I hope I didn't show any claws, though I admit that removing 
the App Browser would force me to remain in LC 7 indefinitely and I had 
a moment of despair.)


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Richmond]

On 26/11/15 21:36, J. Landman Gay wrote:



(Finally, I hope I didn't show any claws, though I admit that removing 
the App Browser would force me to remain in LC 7 indefinitely and I 
had a moment of despair.)




We know that you are really a "pussy cat"; rather like my cats;
who are soft and sweet most of the time, but when
they come up against something they feel strongly about . . .

[ And, shake it which ever way you will, you will admit that
the Livecode people probably listen to your opinion a lot
more than mine! ]

Love, Richmond.


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Richmond]

AND, defensive as you like . . .

The "one" about that the Application Browser had been moved into the
Plug-ins was nothing but a  . . .

I wasn't there!

Try harder next time . . .

Richmond.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Mark Schonewille]

Does this mean that it is no longer supported?

Kind regards,

Mark Schonewille
http://economy-x-talk.com
https://www.facebook.com/marksch

Buy the most extensive book on the
LiveCode language:
http://livecodebeginner.economy-x-talk.com

Op 11/25/2015 om 21:54 schreef Ali Lloyd:

It was put into the plugins menu in DP 9. Apologies for the lack of release
note to that effect.

On Wed, Nov 25, 2015 at 8:42 PM Richmond 
wrote:


I see the Application Browser has been removed
completely from LiveCode 8.0 DP 10.

I am not happy about that as I much prefer it to the
Project Browser.

Richmond.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[J. Landman Gay]

It needs to come back. I can't work without it. Project browser is not an 
acceptable replacement for the kind of stacks I work with. 

On November 25, 2015 8:19:05 PM CST, Colin Holgate  
wrote:
>Maybe it was there in DP9. Seems not to be there in DP10.
>
>
>> On Nov 25, 2015, at 9:10 PM, Mark Wieder 
>wrote:
>> 
>> On 11/25/2015 01:38 PM, Richmond wrote:
>>> On 25/11/15 22:54, Ali Lloyd wrote:
 It was put into the plugins menu in DP 9. Apologies for the lack of
 release
 note to that effect.
 
 
>>> Then why does it not show up menu/development/plugins  ???
>> 
>> Nor in /opt/livecode/livecodecommunity-8.0.0-dp-10.x86_64/Plugins
>> Looks like it's just gone.
>> 
>> -- 
>> Mark Wieder
>> ahsoftw...@gmail.com
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
>___
>use-livecode mailing list
>use-livecode@lists.runrev.com
>Please visit this url to subscribe, unsubscribe and manage your
>subscription preferences:
>http://lists.runrev.com/mailman/listinfo/use-livecode

-- 
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Mark Wieder]

On 11/25/2015 01:38 PM, Richmond wrote:

On 25/11/15 22:54, Ali Lloyd wrote:

It was put into the plugins menu in DP 9. Apologies for the lack of
release
note to that effect.



Then why does it not show up menu/development/plugins  ???


Nor in /opt/livecode/livecodecommunity-8.0.0-dp-10.x86_64/Plugins
Looks like it's just gone.

--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Colin Holgate]

Maybe it was there in DP9. Seems not to be there in DP10.


> On Nov 25, 2015, at 9:10 PM, Mark Wieder  wrote:
> 
> On 11/25/2015 01:38 PM, Richmond wrote:
>> On 25/11/15 22:54, Ali Lloyd wrote:
>>> It was put into the plugins menu in DP 9. Apologies for the lack of
>>> release
>>> note to that effect.
>>> 
>>> 
>> Then why does it not show up menu/development/plugins  ???
> 
> Nor in /opt/livecode/livecodecommunity-8.0.0-dp-10.x86_64/Plugins
> Looks like it's just gone.
> 
> -- 
> Mark Wieder
> ahsoftw...@gmail.com
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Richmond]

On 25/11/15 22:54, Ali Lloyd wrote:

It was put into the plugins menu in DP 9. Apologies for the lack of release
note to that effect.



Then why does it not show up menu/development/plugins  ???

Richmond.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Death of the Application Browser

[Richmond]

I see the Application Browser has been removed
completely from LiveCode 8.0 DP 10.

I am not happy about that as I much prefer it to the
Project Browser.

Richmond.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[Ali Lloyd]

It was put into the plugins menu in DP 9. Apologies for the lack of release
note to that effect.

On Wed, Nov 25, 2015 at 8:42 PM Richmond 
wrote:

> I see the Application Browser has been removed
> completely from LiveCode 8.0 DP 10.
>
> I am not happy about that as I much prefer it to the
> Project Browser.
>
> Richmond.
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Death of the Application Browser

[[-hh]]

> J. LG wrote:
> It needs to come back. I can't work without it. Project browser is not an 
> acceptable replacement for the kind of stacks I work with. 

I stopped to edit any stack in LC 8.

The Project Browser is beautiful to look at, also the Property Inspector, 
beautiful design, but there are too much things one can NOT do.

It's twice as fast to quit LC 8, to open LC 7 and do the simplest edit in LC 
7's Application Browser supported by LC 7's Property inspector.

For me it's the pair (Application Browser, LC 7 - Property Inspector) that is 
much more useful, for EACH AND EVERY stack.


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode