Re: App Browser versus Project Browser

[J. Landman Gay]

On 10/7/2015 3:31 PM, Mark Talluto wrote:



On Oct 7, 2015, at 12:58 PM, J. Landman Gay
 wrote:

That's just what I remember from the few days I tried to work with
it. I'm not convinced that the current design can accomodate my
work style unless it can at least be revised to show a columnar
view rather than a linear one. What I would have preferred is an
update for the few glitches in the AB (mainly it doesn't always
refresh automatically, and those blinking tooltips are positively
aggressive) and give it a new coat of paint if you think it looks
too dated. Its plain text layout with clear checkmarks is much
easier for me to work with. I do like how you can change layering
order by dragging in the PB, that would be a nice addition to the
AB.


Have you tried Geoff Canyon’s revNavigator? It is the smallest and
cleanest solution yet. You get the best of both the AppBrowser and
the ProjectBrowser in one package. We design some pretty complex apps
over here. I like the fact that you can focus on a single card at a
time. Filter brings you down to all the controls of the same kind, or
the exact control you are looking for. Edit scripts, properties, and
other useful functionality with keyboard and clicks that you can
define. Drag and drop controls to reorder their layers. Support a
dark background or not, which is something I prefer.


I'm embarrassed to say I haven't. I looked at it a couple of times, but 
the docs require some memorization and I didn't pursue it. If the docs 
could be separated out into a separate window for reference I might have 
an easier time learning it. It does look powerful and I've heard only 
good reports about it.


If LC 8 really does eliminate the app browser, I'll probably move to 
Navigator. The client who owns this big project tried to use PB for a 
while and also dropped it quickly. She liked it at first because of the 
thumbnails and draggable layering but ran into all the other limitations 
soon after and dropped it in favor of the app browser. Her problems with 
the PB were pretty much identical to mine.


--
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: use-livecode Digest, Vol 145, Issue 11

[Terry Dennis]

Message: 18
Date: Wed, 7 Oct 2015 14:58:13 -0500
From: "J. Landman Gay" 
To: How to use LiveCode 
Subject: Re: App Browser versus Project Browser
Message-ID: <56157955.3080...@hyperactivesw.com>
Content-Type: text/plain; charset=utf-8; format=flowed

The issues would probably become clear if you open, say, 10 large 
stacks, each with 50 cards or more, containing dozens of controls per 
card. Since my primary project for the last 2 years uses that setup, I 
haven't been able to use the Project Browser because it isn't practical.
*
+10
I inherited a large, complex project that was written by an early user of 
Revolution.  The Project Browser is darned near worthless in that project.  
Because of that, I am staying with 7.x so I can use the Application Browser.  
Unfortunately, 7.x is slower than 6.X, and has more bugs than I (or anyone) 
should have to deal with.  Intersect caused me much lost time until I finally 
figured out an empty array somehow incorrectly intersected with a large array.  
“Split” of a blank delimited series of numbers created empty elements, instead 
of putting “true” into the value of each entry like the dictionary says it 
does.  The Dictionary filter is ridiculously slow.  Etc. ...
I don’t have time to wait for fixes from RunRev, so I have to roll my own.  
That takes time, and time is money.
If there hadn’t already been significant funds expended on this project, I 
would be transitioning to another development platform.
As to the thought of using an add-on written by somebody else ... WHY?
The requisite basic functionality should be provided by the vendor I support 
with my license fees.  Throwing somebody else’s well-intentioned “enhancements” 
into the mix introduces additional risk of quality control errors (aka: bugs).
TED
___
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: App Browser versus Project Browser

[J. Landman Gay]

On 10/7/2015 1:22 PM, Mark Waddingham wrote:

Far more useful would be constructive criticism of both the Project
Browser and the Application Browser. It does seem a little 'silly' to
maintain two things which serve essentially the same purpose - so Ali's
idea is perhaps the best way forward - what is it that is good and bad
about both and is it possible to design something which everybody would
be happy with?


The issues would probably become clear if you open, say, 10 large 
stacks, each with 50 cards or more, containing dozens of controls per 
card. Since my primary project for the last 2 years uses that setup, I 
haven't been able to use the Project Browser because it isn't practical.


1. The hierarchical organization of the App Browser (AB) is 
indispensable and is the main reason I stay with it. I can see at a 
glance how to drill down to the single object I am looking for and how 
objects are organized on each card by group and layer order. It is by 
far the fastest way to understand how a set of stacks is internally 
structured. The long, scrolling list in the Project Browser (PB) can't 
display the structure as clearly because it is all linear. Multiple 
cards with many objects will run off the top and bottom of the PB window 
and you can't see the overall organization.


2. It is difficult in the PB to quickly find a specific object. If you 
want to know the name of an object on some other card, you have to 
collapse the current card, scroll through 50 cards to find the one 
you're looking for (and if you didn't collapse those already, the 
scrolling is interminable,) expand it, scroll through the objects to 
find the one you want (note the name because it's going to be a long 
trip to find it again,) collapse that card, scroll (forever) again to 
find the card you started with, expand it, find the original object 
again, and continue. In AB, I can just look at the left-hand pane and 
see the name of the target card, click it, note the name of the object, 
then click back where I was. If the AB is sized tall enough to hold 50 
lines of text, I don't have to do much scrolling at all. If I do need to 
scroll, it's minimal because at least 25-30 cards are always visible at 
once.


2. In the AB I can click on any header to view the organization in many 
ways, and I have a choice of which columns I want to display. If I want 
to work only with images, or fields, I can bunch them together in the 
list by type and they are quickly accessible while still allowing me to 
see the other objects on the card. I frequently require info on layering 
order, one click and I have that. I use the ID column extensively. In PB 
I have to type in a filter string to isolate by object type, and then I 
can no longer see any other objects, so if I need some other info I have 
to remove the filter, find what I want, then reinstate the original 
filter. PB does not offer a way to identify an object ID at all, as far 
as I can see, and I need that all the time. (But you could turn off 
those distracting ID tooltips for sure.)


3. Visually, the PB is too cluttered to be quickly scanned. The 
checkmarks in the AB are more useful. In the AB is very easy to see, for 
example, which objects are invisible by simply looking for "gaps" in the 
checkmark column. In the PB I have to examine each object individually 
because the visual difference between the enabled and disabled "eye" 
image is not distinct enough, and even if it were, there's that 
scrolling issue again to see all the objects. Also, there is no single 
column to scan -- the lock icon is interspersed so you have to mentally 
learn to skip over every other icon.


4. I have turned off thumbnails in the PB because with hundreds of 
objects or more, the time required for it to constantly update is (or at 
least, was) unacceptable. Even without thumbnails, it performs much 
slower than the AB. There is also the issue of visual clutter (see 
below) which is main reason I turned off thumbnails on day one. 
Thumbnails also double the amount of scrolling you have to do to find 
things.


5. In the PB there is no clear delineation between cards and substacks. 
Both are left-aligned at the same visual depth. In the AB, all stacks 
are in the left pane, with substacks indented under their mainstack. 
Also, in the PB, the stack you are inspecting scrolls off the top of the 
window, so you are never sure which stack owns the cards that are 
currently displayed. This is a big issue in my project, because all the 
stacks are clones of each other and cards have the same names (usually 
just IDs.) In the AB I can immediately see which stack owns the card 
because the card is highlighted in the left-pane list under its 
easily-viewable owner. Even if I have to scroll to see the stack name, 
the card I'm working with remains selected and its objects remain visible.


6. The icons at the bottom of the PB are so tiny on my screen that they 
are difficult to recognize (and my 

Re: App Browser versus Project Browser

[Sannyasin Brahmanathaswami]

Hmmm,  I had to bail on LC8… just not ready do deal with too many broken issues 
right now.

I stuck in 7.1 for now…

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

1) visual representation of objects is very helpful  I 

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

3) I like color 

where is geof’s plug in these days?


BR








On 10/7/15, 11:02 AM, "use-livecode on behalf of Paul Hibbert" 
 wrote:

>I am one of the people that generally prefers the Application Browser to the 
>Project Browser, but to be fair I don’t think I gave the PB enough attention 
>to see any of it’s merits.
___
use-livecode mailing list
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: App Browser versus Project Browser

[Richard Gaskin]

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

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


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


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


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


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

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


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


Why not have exactly what you want?

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


--
 Richard Gaskin
 LiveCode Community Manager
 rich...@livecode.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: App Browser versus Project Browser

[J. Landman Gay]

I remembered another issue that prevents me from using the PB: there is 
no card number visible. This is actually a big deal for me. My stacks do 
not have named cards, they are all IDs. In the AB I can see the card 
number which is also displayed in my stack or, sometimes, in the 
titlebar. That's how I locate cards, it's quick to spot a card number in 
the AB. The PB doesn't show card numbers at all, so there is no way to 
find a card without physically counting from the top in the collapsed list.


On 10/7/2015 2:58 PM, J. Landman Gay wrote:

On 10/7/2015 1:22 PM, Mark Waddingham wrote:

Far more useful would be constructive criticism of both the Project
Browser and the Application Browser. It does seem a little 'silly' to
maintain two things which serve essentially the same purpose - so Ali's
idea is perhaps the best way forward - what is it that is good and bad
about both and is it possible to design something which everybody would
be happy with?


The issues would probably become clear if you open, say, 10 large
stacks, each with 50 cards or more, containing dozens of controls per
card. Since my primary project for the last 2 years uses that setup, I
haven't been able to use the Project Browser because it isn't practical.

1. The hierarchical organization of the App Browser (AB) is
indispensable and is the main reason I stay with it. I can see at a
glance how to drill down to the single object I am looking for and how
objects are organized on each card by group and layer order. It is by
far the fastest way to understand how a set of stacks is internally
structured. The long, scrolling list in the Project Browser (PB) can't
display the structure as clearly because it is all linear. Multiple
cards with many objects will run off the top and bottom of the PB window
and you can't see the overall organization.

2. It is difficult in the PB to quickly find a specific object. If you
want to know the name of an object on some other card, you have to
collapse the current card, scroll through 50 cards to find the one
you're looking for (and if you didn't collapse those already, the
scrolling is interminable,) expand it, scroll through the objects to
find the one you want (note the name because it's going to be a long
trip to find it again,) collapse that card, scroll (forever) again to
find the card you started with, expand it, find the original object
again, and continue. In AB, I can just look at the left-hand pane and
see the name of the target card, click it, note the name of the object,
then click back where I was. If the AB is sized tall enough to hold 50
lines of text, I don't have to do much scrolling at all. If I do need to
scroll, it's minimal because at least 25-30 cards are always visible at
once.

2. In the AB I can click on any header to view the organization in many
ways, and I have a choice of which columns I want to display. If I want
to work only with images, or fields, I can bunch them together in the
list by type and they are quickly accessible while still allowing me to
see the other objects on the card. I frequently require info on layering
order, one click and I have that. I use the ID column extensively. In PB
I have to type in a filter string to isolate by object type, and then I
can no longer see any other objects, so if I need some other info I have
to remove the filter, find what I want, then reinstate the original
filter. PB does not offer a way to identify an object ID at all, as far
as I can see, and I need that all the time. (But you could turn off
those distracting ID tooltips for sure.)

3. Visually, the PB is too cluttered to be quickly scanned. The
checkmarks in the AB are more useful. In the AB is very easy to see, for
example, which objects are invisible by simply looking for "gaps" in the
checkmark column. In the PB I have to examine each object individually
because the visual difference between the enabled and disabled "eye"
image is not distinct enough, and even if it were, there's that
scrolling issue again to see all the objects. Also, there is no single
column to scan -- the lock icon is interspersed so you have to mentally
learn to skip over every other icon.

4. I have turned off thumbnails in the PB because with hundreds of
objects or more, the time required for it to constantly update is (or at
least, was) unacceptable. Even without thumbnails, it performs much
slower than the AB. There is also the issue of visual clutter (see
below) which is main reason I turned off thumbnails on day one.
Thumbnails also double the amount of scrolling you have to do to find
things.

5. In the PB there is no clear delineation between cards and substacks.
Both are left-aligned at the same visual depth. In the AB, all stacks
are in the left pane, with substacks indented under their mainstack.
Also, in the PB, the stack you are inspecting scrolls off the top of the
window, so you are never sure which stack owns the cards that are
currently displayed. This is a big issue in my 

Re: Basic grouches about LiveCode 8

[Monte Goulding]

> On 8 Oct 2015, at 9:53 am, Richard Gaskin  wrote:
> 
> I have a tool in the works that'll help that conversation along

Talking about tools in the works. Does anyone have a tool to identify 
inaccessible handlers, unused variables etc? I was poking in the IDE the other 
day and I noticed some code that clearly isn’t being used so it would be nice 
to run such a tool on the IDE. I guess it would be a non-trivial tool to write 
given the range of possible ways an object might have a handler called (engine 
message, dispatch, send, call, post from a lcb handler, some custom 
publish-subscribe system … probably some other things I’ve forgotten).

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: App Browser versus Project Browser

[Mark Talluto]

> On Oct 7, 2015, at 12:58 PM, J. Landman Gay  wrote:
> 
> That's just what I remember from the few days I tried to work with it. I'm 
> not convinced that the current design can accomodate my work style unless it 
> can at least be revised to show a columnar view rather than a linear one. 
> What I would have preferred is an update for the few glitches in the AB 
> (mainly it doesn't always refresh automatically, and those blinking tooltips 
> are positively aggressive) and give it a new coat of paint if you think it 
> looks too dated. Its plain text layout with clear checkmarks is much easier 
> for me to work with. I do like how you can change layering order by dragging 
> in the PB, that would be a nice addition to the AB.

Have you tried Geoff Canyon’s revNavigator? It is the smallest and cleanest 
solution yet. You get the best of both the AppBrowser and the ProjectBrowser in 
one package. We design some pretty complex apps over here. I like the fact that 
you can focus on a single card at a time. Filter brings you down to all the 
controls of the same kind, or the exact control you are looking for. Edit 
scripts, properties, and other useful functionality with keyboard and clicks 
that you can define. Drag and drop controls to reorder their layers. Support a 
dark background or not, which is something I prefer.


Best regards,

Mark Talluto
canelasoftware.com
CassiaDB: The rapid development, free local storage database, made for LiveCode 
developers: livecloud.io






___
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: Basic grouches about LiveCode 8

[Richard Gaskin]

Mark Waddingham wrote:


On 2015-10-06 04:54, Richard Gaskin wrote:

Monte Goulding wrote:

On 6 Oct 2015, at 1:15 pm, Richard Gaskin wrote:

some really long script somewhere to create every control and
set every property?


 ^ this


Where can I read that?

I wonder what the break-even ROI calculation for that effort looks
like


Exceptionally good. We moved to dynamically built menus in the
revMenuBar a long time ago, and as a result it became a great deal
easier to maintain (and a lot of bugs were fixed in the transition) -
this is essentially an extension of that work.

Having the principal components generated on-the-fly means that they can
become more customizable. For example, you've pointed out you'd like to
add a button to the revMenuBar to pop up various components.


I think that must have been someone else.  My LC workspace is a very 
simple one in which I very rarely ever see revMenubar:





With the old model, you'd have to patch the revMenuBar yourself, and
each time we do an update you need to update your patch.

The new way of doing things means that it should be relatively
straightforward to enable the menubar buttons to be customizable (a bit
like the 'Toolbar Editor' you get on Mac in many apps).


I do run a set of patches in a plugin on launch to cover for fixes in 
queue, and one just-for-fun patch that updates the revMenubar colors and 
fonts to fit in more nicely with Ubuntu's default theme.  Near as I can 
tell most of my patches (aside from one related to topcolor) work the 
same in both v8 and the current product v7.


Whether I modify object properties or script lines it seems about the 
same to me, except that object names are less likely to change between 
builds than lines in a script that does everything and thus requires 
frequent changes, no?


As long as patchers work on objects after startup, seems to make little 
difference whether the stack was prefab or built during boot from a script.




At the moment, the script is basically the refactored code from the
stack based revMenuBar to be but in a neater structure (the code for
various things was spread out, and in some cases very difficult to see
how changes should be made).


Looking forward to seeing the changes you have in mind.



If you would be interested in helping to add the relevant hooks to the
revMenuBar to make it customizable based on user preference then it is
probably worth starting a discussion on such a thing.


I have a tool in the works that'll help that conversation along

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the 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: App Browser versus Project Browser

[Richard Gaskin]

Monte Goulding wrote:

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

I love Miller columns for many things, and started down that road once:


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


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


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


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


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 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: App Browser versus Project Browser

[Paul Hibbert]

I am one of the people that generally prefers the Application Browser to the 
Project Browser, but to be fair I don’t think I gave the PB enough attention to 
see any of it’s merits.

Now that I’ve used the PB a little more in LC8 I have been able to get a 
slightly better feel for it, so I thought it may be useful to list what I like 
and don’t like, this what I came up with:

What I do like about the Application Browser:
1. Column views, having a separate window to list all controls on the selected 
card makes it easy to locate the control you want to work with especially if it 
isn’t currently visible on the card that’s open.
2. Being able to sort the list by different columns. Really useful for long 
lists of controls, great for grouping control info.
3. Control IDs and Layer numbers are immediately visible.
3. The Refresh button.

What I don’t like about the Application Browser:
1. The column sizes don’t save between sessions, so I find I’m always resizing 
them!
2. No filters, but column sort helps.

What I do like about the Project Browser:
1. Takes up less screen space than the Application Browser.
2. Having options that do stick between session.
3. Some useful options available under the contextual menu, (like Send Message).

What I don’t like about the Project Browser:
1. No easy way to change the sort order (I know it’s in the LC Prefs, but 
that’s too slow to get to).
2. No filter in LC8 - it is there in LC7.
3. No control IDs or layer numbers visible.
4. No easy way to refresh.

What I would like to see in the Project Browser:
1. Reinstate the filter, preferably with more options like show/hide by control 
type.
2. To be able to temporarily hide stacks/cards/controls from the PB, (to enable 
a more focused view), not just collapsing them in the tree view. e.g. Hiding 
controls that are hidden on a card, removing library stacks etc. from the PB 
view.
3. A Refresh button/option to avoid closing and re-opening the PB.
4. Control IDs and Layer numbers should be visible, maybe with a preference 
setting for people that don’t want to see them.
5. The ability to rename controls would be useful.
6. The option to switch between column view and tree view, this would save 
having two different viewers and keep more people happy!

Interestingly every time I open LC8 (dp7) the Application Browser opens, maybe 
it’s because I closed LC7 with the AB still open(?), but as soon as I close it 
I can’t get it back.

I have tried a 3rd party browser, but this discussion is about the native LC 
options.

Just a few of my thoughts.

Paul
___
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: App Browser versus Project Browser (features)

[Paul Dupuis]

On 10/7/2015 3:58 PM, J. Landman Gay wrote:
> On 10/7/2015 1:22 PM, Mark Waddingham wrote:
>> Far more useful would be constructive criticism of both the Project
>> Browser and the Application Browser. It does seem a little 'silly' to
>> maintain two things which serve essentially the same purpose - so Ali's
>> idea is perhaps the best way forward - what is it that is good and bad
>> about both and is it possible to design something which everybody would
>> be happy with?
>
> The issues would probably become clear if you open, say, 10 large
> stacks, each with 50 cards or more, containing dozens of controls per
> card. Since my primary project for the last 2 years uses that setup, I
> haven't been able to use the Project Browser because it isn't practical.
>
> 1. The hierarchical organization of the App Browser (AB) is
> indispensable and is the main reason I stay with it. I can see at a
> glance how to drill down to the single object I am looking for and how
> objects are organized on each card by group and layer order. It is by
> far the fastest way to understand how a set of stacks is internally
> structured. The long, scrolling list in the Project Browser (PB) can't
> display the structure as clearly because it is all linear. Multiple
> cards with many objects will run off the top and bottom of the PB
> window and you can't see the overall organization. 

This is getting at what Mark asked for - what features specifically do
people use or don't use and why.

I actually like the hierarchical model of the PB (in LC 7.0.6) over the
AB for small projects, but I agree with Jacque that for large projects
the scrolling list of objects on a card in AB is superior for
navigation. Possibly if the PB provided Zoom In/Zoom Out so you could
focus just on one card's objects and the scroll would be limited to that
list until you Zoomed out. Some collapse All/Expand All and Collapse
Selected/Expand Selected buttons or options would be helpful. I also
miss the layer number column that the AB has in the PB, but generally I
do prefer the hierarchical navigation of PB (except for cards with a LOT
of objects not structured in groups)


___
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: App Browser versus Project Browser

[Monte Goulding]

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

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

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

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

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

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

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

Cheers

Monte




___
use-livecode mailing list
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

[OT] Lifetime Access to GoSkills ExcelCours for $25 instead of 600

[Matthias Rebbe | M-R-D]

Hi,

for the next 6 hours you can purchase Lifetime Access to 3 Excel courses 
(Basic, Advanced and Pivotables) from GoSkills with Lifetime Update

at AppSumos website at http://www.appsumo.com/~cZ9Ld/

Lifetime updates mean, they will  update their course when new Excel versions 
are released.

This offer will expire in about 6 hours. 

Hope it´s useful for the one or the other.

Matthias





___
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: App Browser versus Project Browser

[Scott Rossi]

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

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

Regards,

Scott Rossi
Creative Director
Tactile Media, UX/UI Design




On 10/7/15, 12:58 PM, "use-livecode on behalf of J. Landman Gay"
 wrote:

>On 10/7/2015 1:22 PM, Mark Waddingham wrote:
>> Far more useful would be constructive criticism of both the Project
>> Browser and the Application Browser. It does seem a little 'silly' to
>> maintain two things which serve essentially the same purpose - so Ali's
>> idea is perhaps the best way forward - what is it that is good and bad
>> about both and is it possible to design something which everybody would
>> be happy with?
>
>The issues would probably become clear if you open, say, 10 large
>stacks, each with 50 cards or more, containing dozens of controls per
>card. Since my primary project for the last 2 years uses that setup, I
>haven't been able to use the Project Browser because it isn't practical.
>
>1. The hierarchical organization of the App Browser (AB) is
>indispensable and is the main reason I stay with it. I can see at a
>glance how to drill down to the single object I am looking for and how
>objects are organized on each card by group and layer order. It is by
>far the fastest way to understand how a set of stacks is internally
>structured. The long, scrolling list in the Project Browser (PB) can't
>display the structure as clearly because it is all linear. Multiple
>cards with many objects will run off the top and bottom of the PB window
>and you can't see the overall organization.
>
>2. It is difficult in the PB to quickly find a specific object. If you
>want to know the name of an object on some other card, you have to
>collapse the current card, scroll through 50 cards to find the one
>you're looking for (and if you didn't collapse those already, the
>scrolling is interminable,) expand it, scroll through the objects to
>find the one you want (note the name because it's going to be a long
>trip to find it again,) collapse that card, scroll (forever) again to
>find the card you started with, expand it, find the original object
>again, and continue. In AB, I can just look at the left-hand pane and
>see the name of the target card, click it, note the name of the object,
>then click back where I was. If the AB is sized tall enough to hold 50
>lines of text, I don't have to do much scrolling at all. If I do need to
>scroll, it's minimal because at least 25-30 cards are always visible at
>once.
>
>2. In the AB I can click on any header to view the organization in many
>ways, and I have a choice of which columns I want to display. If I want
>to work only with images, or fields, I can bunch them together in the
>list by type and they are quickly accessible while still allowing me to
>see the other objects on the card. I frequently require info on layering
>order, one click and I have that. I use the ID column extensively. In PB
>I have to type in a filter string to isolate by object type, and then I
>can no longer see any other objects, so if I need some other info I have
>to remove the filter, find what I want, then reinstate the original
>filter. PB does not offer a way to identify an object ID at all, as far
>as I can see, and I need that all the time. (But you could turn off
>those distracting ID tooltips for sure.)
>
>3. Visually, the PB is too cluttered to be quickly scanned. The
>checkmarks in the AB are more useful. In the AB is very easy to see, for
>example, which objects are invisible by simply looking for "gaps" in the
>checkmark column. In the PB I have to examine each object individually
>because the visual difference between the enabled and disabled "eye"
>image is not distinct enough, and even if it were, there's that
>scrolling issue again to see all the objects. Also, there is no single
>column to scan -- the lock icon is interspersed so you have to mentally
>learn to skip over every other icon.
>
>4. I have turned off thumbnails in the PB because with hundreds of
>objects or more, the time required for it to constantly update is (or at
>least, was) unacceptable. Even without thumbnails, it performs much
>slower than the AB. There is also the issue of visual clutter (see
>below) which is main reason I turned off thumbnails on day one.
>Thumbnails also 

How can I get a high-res image into LC?

[Tiemo Hollmann TB]

Hello,

when importing images into LC as an icon resource for buttons, does the dpi
of the image makes any difference?

I think the dpi is only relevant for printing. If I have a button of 100px
and assign to it an image of 100px it should be irrelevant if the image has
72 dpi or 300 dpi, it only has 100px in both versions. Am I right?

If I create an icon image with text in photoshop, I never get the text as
crispy, as real text because the image is a bitmap and the text is vector
based. And I don't even have a retina display for testing, so actually I
don't know how blurred the button images look like on a retina display.

What can I do to get crispy images (on buttons) in LC? How do you handle
this issue? Any workaround? Probably "100px always keep 100px" on the
screen, right?

Thanks

Tiemo

 

 

 

___
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: LC8

[Peter TB Brett]

On 2015-10-07 08:37, Richmond wrote:

On 07/10/15 02:45, Peter Haworth wrote:
Thanks.  I believe the plugin problem was discovered in LC8 dp5 so 
sounds

like will be OK in dp6.


Back to the Future: we currently have a DP7 build:

"We’ll aim to continuously build LiveCode 8.0.0-dp-7 candidates, and
make them available for you to download. No need to wait and wait for
your bug to be fixed – just make sure that you’re always working from
the latest version"

Usual exaggeration: exactly 2 builds: 
http://downloads.livecode.com/global-jam/


Believe me, we were continuously building.  Or builds 2-3 hours to 
complete.  We made about 7 builds; 5 of them had serious bugs in them, 
and we decided that it wouldn't be a good idea to make them public.


The live builds were actually very useful during the Global Jam.  We 
were able to confirm with people who'd reported bugs that our fixes 
actually worked for them.  Totally worthwhile, in my opinion.  It also 
reinforced that we do need to increase the level of automation in our 
testing and releasing process.


Even 6 months ago, it was taking us *2 days* to do a single build and 
release.  We've come a long way since then, wouldn't you agree?


We're just kicking of the final 8.0.0-dp-7 release build, and if it 
passes our full QA tests we'll be releasing it today.


Peter

--
Dr Peter Brett 
LiveCode Open Source Team

LiveCode on reddit! 

___
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: LC8

[Richmond]

On 07/10/15 02:45, Peter Haworth wrote:

Thanks.  I believe the plugin problem was discovered in LC8 dp5 so sounds
like will be OK in dp6.


Back to the Future: we currently have a DP7 build:

"We’ll aim to continuously build LiveCode 8.0.0-dp-7 candidates, and 
make them available for you to download. No need to wait and wait for 
your bug to be fixed – just make sure that you’re always working from 
the latest version"


Usual exaggeration: exactly 2 builds: 
http://downloads.livecode.com/global-jam/


Richmond.



On Tue, Oct 6, 2015 at 4:26 PM Mark Wieder  wrote:


On 10/06/2015 04:17 PM, Ali Lloyd wrote:


The loading of plugins was an issue but should be fixed in the latest
builds.

And indeed that is the case.

--
   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



___
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: How can I get a high-res image into LC?

[Richmond]

On 07/10/15 09:49, Tiemo Hollmann TB wrote:

Hello,

when importing images into LC as an icon resource for buttons, does the dpi
of the image makes any difference?

I think the dpi is only relevant for printing. If I have a button of 100px
and assign to it an image of 100px it should be irrelevant if the image has
72 dpi or 300 dpi, it only has 100px in both versions. Am I right?

If I create an icon image with text in photoshop, I never get the text as
crispy, as real text because the image is a bitmap and the text is vector
based. And I don't even have a retina display for testing, so actually I
don't know how blurred the button images look like on a retina display.

What can I do to get crispy images (on buttons) in LC? How do you handle
this issue? Any workaround? Probably "100px always keep 100px" on the
screen, right?

Thanks

Tiemo

  



Supposedly (!!!) LiveCode post-Moolah-raising-exercises should be 
able to handle vector
images (import, export ???) so one should be able to import a scaleable 
image . . .


SVG

EPS

Anyone 

Or is that a goal / stretch-goal / stretch-the-truth-goal that 'somehow' 
got lost

in the wash?

Certainly if/were that capability available both imported images and 
users would be crispy!


R.

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: App Browser versus Project Browser

[Monte Goulding]

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

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

___
use-livecode mailing list
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: App Browser versus Project Browser

[Scott Rossi]

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

Regards,

Scott Rossi
Creative Director
Tactile Media, UX/UI Design




On 10/7/15, 5:31 PM, "use-livecode on behalf of Peter Haworth"
 wrote:

>I think this thread illustrates the problem the team have trying to figure
>out what type of browser to implement.  Everyone has their own ways of
>working and it's practically impossible to come up with a solution that
>will keep everyone happy.
>
>Perhaps the biggest divide is between the horizontal and vertical layout
>fans.  My preference is for a vertical layout but I recognize that can
>cause a large amount of scrolling.  I tried a few things to alleviate that
>in lcStackbrowser, for example, tabs with only one main stack in each tab
>and the ability to hide a specific stack or all except a specific stack.
>
>I find myself using a lot of groups in my designs and that helps a lot
>with
>the scrolling issue too, assuming groups are expandable/collapsible of
>course.
>
>A lot of the other PB  problems fall into the missing functionality
>bucket.  You should be able to sort objects in whatever way suits your
>mode
>of operation.  lcStackBrowser allows sorting of cards by name, id, or
>number; controls by layer, id, type or name; with a default preference
>setting for each one.  You can sort cards and controls differently for
>each
>stack/card.
>
>I do like the snapshot feature in the PB but not as an ever present
>thumbnail.  In lcstackbrowser, you can display a snapshot of a specific,
>group, or control with either a contextual menu option or a keyboard
>shortcut.
>
>I also wanted access to properties without opening a property inspector
>window and lcStackbrowser has various ways to do that.  You can edit an
>object's name, label, and (for simple text fields) its contents. Right
>click on an object and you will have access to all of its boolean
>properties.  Finally, you can expand an object to show an editable list of
>properties, grouped the way that suits the way you work in preferences,
>with full type-specific editors, including an array editor.
>
>You can also customize just about every element of the display, reorganize
>the contextual menu items and add your own to them, and create/rollback to
>commented checkpoints of your stack.
>
>I don't pretend lcStackbrowser will be the ideal solution for everyone but
>I think the key to a successful implementation is a high degree of
>flexibility so users can customize it to suit their way of working.
>
>
>
>
>
>On Wed, Oct 7, 2015 at 4:21 PM Scott Rossi  wrote:
>
>> IMO, Jacque makes a number of valid points.  In the Project Browser,
>> because stacks and cards are contained in the single view, a long list
>>of
>> controls will remove any stack and card references from view, while in
>>the
>> Application Browser, stacks and cards are always visible.  It seems like
>> applying an Application Browser layout to the Project Browser could make
>> it more useful: move stack/card references to a left pane that is always
>> visible.
>>
>> For myself, I also often rely on numerical references: card numbers,
>>layer
>> numbers, etc.  Filtering in the Project Browser is great, but it's not
>>the
>> same as sorting offered by the Application Browser (AFAICT the Project
>> Browser doesn't offer sorting that I can see).
>>
>> Regards,
>>
>> Scott Rossi
>> Creative Director
>> Tactile Media, UX/UI Design
>>
>>
>>
>>
>> On 10/7/15, 12:58 PM, "use-livecode on behalf of J. Landman Gay"
>> > jac...@hyperactivesw.com> wrote:
>>
>> >On 10/7/2015 1:22 PM, Mark Waddingham wrote:
>> >> Far more useful would be constructive criticism of both the Project
>> >> Browser and the Application Browser. It does seem a little 'silly' to
>> >> maintain two things which serve essentially the same purpose - so
>>Ali's
>> >> idea is perhaps the best way forward - what is it that is good and
>>bad
>> >> about both and is it possible to design something which everybody
>>would
>> >> be happy with?
>> >
>> >The issues would probably become clear if you open, say, 10 large
>> >stacks, each with 50 cards or more, containing dozens of controls per
>> >card. Since my primary project for the last 2 years uses that setup, I
>> >haven't been able to use the Project Browser because it isn't
>>practical.
>> >
>> >1. The hierarchical organization of the App Browser (AB) is
>> >indispensable and is the main reason I stay with it. I can see at a
>> >glance how to drill down to the single object I am looking for and how
>> >objects are organized on each card by group and layer order. It is by
>> >far the fastest way 

Re: App Browser versus Project Browser

[Jerry Jensen]

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

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


___
use-livecode mailing list
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: App Browser versus Project Browser

[Mark Wieder]

On 10/07/2015 11:54 AM, Mark Waddingham wrote:

So if we had deleted the app browser stack from the build, would your point of 
view have changed and would you have started to use the project browser? ;)


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

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


--
 Mark Wieder
 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

[OT] Re-open question on SO

[Mark Schonewille]

Does anyone else have sufficient permissions to vote to re-open this 
question on Stackoverflow?


http://stackoverflow.com/questions/32991614/livecode-strict-isnumber-needed

We still need 3 votes.

--
Mark Schonewille
http://economy-x-talk.com

Buy the most extensive book on the
LiveCode language:
http://livecodebeginner.economy-x-talk.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: App Browser versus Project Browser

[Roger Eller]

On Oct 7, 2015 3:02 PM, "Mark Waddingham"  wrote:
>
> As an indication of community division it might be useful - app
browser/project browser/indifferent.
>
> However, I'm not sure a poll would give us the information we need as it
is too binary.

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

~Roger
___
use-livecode mailing list
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: [OT] Re-open question on SO

[Richard Gaskin]

Mark Schonewille wrote:

Does anyone else have sufficient permissions to vote to re-open this
question on Stackoverflow?

http://stackoverflow.com/questions/32991614/livecode-strict-isnumber-needed

We still need 3 votes.


If you can figure out SO's permissions you're a better man than me.  My 
only attempt to provide an answer there was deprecated as a comment from 
some random passerby admin because I also included a follow-up question.


Why do they mark something as a duplicate without providing a link to 
the duplicate?


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the 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: App Browser versus Project Browser

[Peter Haworth]

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

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

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

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

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

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

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

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





On Wed, Oct 7, 2015 at 4:21 PM Scott Rossi  wrote:

> IMO, Jacque makes a number of valid points.  In the Project Browser,
> because stacks and cards are contained in the single view, a long list of
> controls will remove any stack and card references from view, while in the
> Application Browser, stacks and cards are always visible.  It seems like
> applying an Application Browser layout to the Project Browser could make
> it more useful: move stack/card references to a left pane that is always
> visible.
>
> For myself, I also often rely on numerical references: card numbers, layer
> numbers, etc.  Filtering in the Project Browser is great, but it's not the
> same as sorting offered by the Application Browser (AFAICT the Project
> Browser doesn't offer sorting that I can see).
>
> Regards,
>
> Scott Rossi
> Creative Director
> Tactile Media, UX/UI Design
>
>
>
>
> On 10/7/15, 12:58 PM, "use-livecode on behalf of J. Landman Gay"
>  jac...@hyperactivesw.com> wrote:
>
> >On 10/7/2015 1:22 PM, Mark Waddingham wrote:
> >> Far more useful would be constructive criticism of both the Project
> >> Browser and the Application Browser. It does seem a little 'silly' to
> >> maintain two things which serve essentially the same purpose - so Ali's
> >> idea is perhaps the best way forward - what is it that is good and bad
> >> about both and is it possible to design something which everybody would
> >> be happy with?
> >
> >The issues would probably become clear if you open, say, 10 large
> >stacks, each with 50 cards or more, containing dozens of controls per
> >card. Since my primary project for the last 2 years uses that setup, I
> >haven't been able to use the Project Browser because it isn't practical.
> >
> >1. The hierarchical organization of the App Browser (AB) is
> >indispensable and is the main reason I stay with it. I can see at a
> >glance how to drill down to the single object I am looking for and how
> >objects are organized on each card by group and layer order. It is by
> >far the fastest way to understand how a set of stacks is internally
> >structured. The long, scrolling list in the Project Browser (PB) can't
> >display the structure as clearly because it is all linear. Multiple
> >cards with many objects will run off the top and bottom of the PB window
> >and you can't see the overall organization.
> >
> >2. It is difficult in the PB to quickly find a specific object. If you
> >want to know the name of an object on some other card, you have to
> >collapse the current card, scroll through 50 cards to find the one
> >you're looking for (and if you didn't collapse those already, the
> >scrolling is interminable,) 

Re: [OT] Re-open question on SO

[Colin Holgate]

I don’t see how to vote.


> On Oct 7, 2015, at 7:58 PM, Mark Schonewille 
>  wrote:
> 
> Does anyone else have sufficient permissions to vote to re-open this question 
> on Stackoverflow?
> 
> http://stackoverflow.com/questions/32991614/livecode-strict-isnumber-needed
> 
> We still need 3 votes.
> 
> -- 
> Mark Schonewille
> http://economy-x-talk.com
> 
> Buy the most extensive book on the
> LiveCode language:
> http://livecodebeginner.economy-x-talk.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: App Browser versus Project Browser

[Terry Judd]

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

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

Terry...

On 8/10/2015 1:47 pm, "use-livecode on behalf of J. Landman Gay"
 wrote:

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

[J. Landman Gay]

On 10/7/2015 6:20 PM, Scott Rossi wrote:

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

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


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


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


I definitely need card numbers and object IDs.

--
Jacqueline Landman Gay | 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: App Browser versus Project Browser

[Scott Rossi]

As soon as we get a means to irregularly distort images, I'm all for that
:-P 

Regards,

Scott Rossi
Creative Director
Tactile Media, UX/UI Design




On 10/7/15, 6:38 PM, "use-livecode on behalf of Roger Eller"
 wrote:

>On Oct 7, 2015 3:02 PM, "Mark Waddingham"  wrote:
>>
>> As an indication of community division it might be useful - app
>browser/project browser/indifferent.
>>
>> However, I'm not sure a poll would give us the information we need as it
>is too binary.
>
>I personally don't like either one.  I rarely open AB or PB unless I'm
>having trouble visualizing where an object exists within layers and
>groups.  I would prefer something like Windows 7 has when you hold the
>Super-key press TAB and all the open applications appear in a angled 3D
>view.  If a stack could do that, and I could scroll through the
>actual-size
>controls in an exploded 3D view, pick and relayer or edit the script of
>objects, it would feel so much more 'real' and even jarvis-like.  Bring us
>a future IDE that feels like it fell out of sci-fi, not just big icons of
>every object in a stack including groups.
>
>~Roger
>___
>use-livecode mailing list
>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: How Film Sets and Coding Are Equally Important

[Mark Wieder]

On 10/07/2015 07:56 AM, Bob Sneidar wrote:

If I may be so bold as to disagree,


You're not disagreeing, it's just my lack of clarity in what I posted 
earlier.


Amoral implies apathy, a lack of interest in taking a position. It's 
much easier to deal with someone or something with a defined stance than 
to have to be constantly on guard for the unknown. I'd much rather deal 
with people who disagree with me than with those who can't be bothered 
to have opinions.


--
 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: LC8

[Richmond]

On 07/10/15 10:44, Peter TB Brett wrote:

On 2015-10-07 08:37, Richmond wrote:

On 07/10/15 02:45, Peter Haworth wrote:
Thanks.  I believe the plugin problem was discovered in LC8 dp5 so 
sounds

like will be OK in dp6.


Back to the Future: we currently have a DP7 build:

"We’ll aim to continuously build LiveCode 8.0.0-dp-7 candidates, and
make them available for you to download. No need to wait and wait for
your bug to be fixed – just make sure that you’re always working from
the latest version"

Usual exaggeration: exactly 2 builds: 
http://downloads.livecode.com/global-jam/


Believe me, we were continuously building.  Or builds 2-3 hours to 
complete.  We made about 7 builds; 5 of them had serious bugs in them, 
and we decided that it wouldn't be a good idea to make them public.


Aha. That's interesting.



The live builds were actually very useful during the Global Jam. We 
were able to confirm with people who'd reported bugs that our fixes 
actually worked for them.  Totally worthwhile, in my opinion.  It also 
reinforced that we do need to increase the level of automation in our 
testing and releasing process.


Even 6 months ago, it was taking us *2 days* to do a single build and 
release.  We've come a long way since then, wouldn't you agree?


We're just kicking of the final 8.0.0-dp-7 release build, and if it 
passes our full QA tests we'll be releasing it today.


Peter



Should be good to see it and see what has changed.

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: How can I get a high-res image into LC?

[tbodine]

There is still no import feature of SVG vector graphics. (And the EPS import
is very limited and old.)

The "Roadmap" says: "Vector Shape Object Use widget framework to write this
control."  So, like the multimedia player object, SVG is in LC8 limbo. Note
that the bare info. in the roadmap blurb does not specify import, export or
even SVG. So it's hard to know what to expect, though the LC8 DP has some
clues. 

If you are up for an adventure, I believe the LC8 DP has a widget into which
you can paste the SVG path information of a drawing, if you can get a hold
of that data. LC8 also has a widget with the vectorized FontAwesome icon
font, which enables you to easily make scalable button graphics. But all
that is over the LC8 horizon unless you are willing to make your project
with a developer's preview version.

Maybe the Global Jam will result in LC8 shipping soon. Hope so. 

Tom 
 







--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/How-can-I-get-a-high-res-image-into-LC-tp4696970p4696974.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: How Film Sets and Coding Are Equally Important

[Bob Sneidar]

If I may be so bold as to disagree, Amoral means the absense of moral aspect. 
Neither moral or immoral.

Bob S


On Oct 6, 2015, at 16:24 , Mark Wieder 
> wrote:

On 10/06/2015 12:03 PM, Richmond wrote:
On 06/10/15 21:57, Bob Sneidar wrote:
It's amoral to my mind.

Well, amoral is a lot better than immoral.

Not sure about that.
Immoral means a choice has been made.
Amoral implies an uneasy uncertainty.

--
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: App Browser versus Project Browser

[Richmond]

On 07/10/15 21:40, Mark Waddingham wrote:

Indeed - but I don't think your tone of phrase was using it in that exact 
manner? ;)

By the way, I'm smiling here - it is a useful conversation to have if it is 
constructive. Either app browser bashing or project browser bashing isn't 
particularly useful to my mind.


I'm not Project Browser bashing as such.

I was very surprised when the Project Browser arrived, and played with 
it quite a bit, but reverted to the App Browser as could not

see any obvious advantages.

As both Browsers are present in current LiveCode 8 builds I don't 
actually see anything wrong with retaining both of them.


The fact that the menu system in the revMenuBar stack does NOT allow 
access to the App Browser does give out a signal which
is fairly blatant that the App Browser is not going to be with us much 
longer:


it was this that precipitated my small hack to allow access to the App 
Browser.


R.



What is useful is getting the information about what the best approach is to 
the problem - which is all I was trying to promote :)

Sent from my iPhone


On 7 Oct 2015, at 19:34, Richmond  wrote:


On 07/10/15 21:22, Mark Waddingham wrote:

On 2015-10-07 20:08, Richmond wrote:
Well, it seems that the "people" are speaking with one voice over here:

http://forums.livecode.com/viewtopic.php?f=6=25503

So, as an experiment in participatory democracy, and whether
RunRev/LiveCode REALLY listen
to their installed customer base, Please go there and give your opinion.

If by the 'people' you mean yourself, one other person and another who said he 
doesn't even use the application browser (and hasn't for years) ;)

Well, I may not know much, but I do know that 'people' is a collective noun, 
so, had I just meant myself I would have used 'person'.


To be fair, whilst preference *might* be an interesting thing to gauge... Far 
more useful would be constructive criticism of both the Project Browser and the 
Application Browser. It does seem a little 'silly' to maintain two things which 
serve essentially the same purpose - so Ali's idea is perhaps the best way 
forward - what is it that is good and bad about both and is it possible to 
design something which everybody would be happy with?

Warmest Regards,

Mark.

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



___
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: App Browser versus Project Browser

[Mark Waddingham]

So if we had deleted the app browser stack from the build, would your point of 
view have changed and would you have started to use the project browser? ;)

Sent from my iPhone

> On 7 Oct 2015, at 19:46, Richmond  wrote:
> 
>> On 07/10/15 21:40, Mark Waddingham wrote:
>> Indeed - but I don't think your tone of phrase was using it in that exact 
>> manner? ;)
>> 
>> By the way, I'm smiling here - it is a useful conversation to have if it is 
>> constructive. Either app browser bashing or project browser bashing isn't 
>> particularly useful to my mind.
> 
> I'm not Project Browser bashing as such.
> 
> I was very surprised when the Project Browser arrived, and played with it 
> quite a bit, but reverted to the App Browser as could not
> see any obvious advantages.
> 
> As both Browsers are present in current LiveCode 8 builds I don't actually 
> see anything wrong with retaining both of them.
> 
> The fact that the menu system in the revMenuBar stack does NOT allow access 
> to the App Browser does give out a signal which
> is fairly blatant that the App Browser is not going to be with us much longer:
> 
> it was this that precipitated my small hack to allow access to the App 
> Browser.
> 
> R.
> 
>> 
>> What is useful is getting the information about what the best approach is to 
>> the problem - which is all I was trying to promote :)
>> 
>> Sent from my iPhone
>> 
 On 7 Oct 2015, at 19:34, Richmond  wrote:
 
> On 07/10/15 21:22, Mark Waddingham wrote:
> On 2015-10-07 20:08, Richmond wrote:
> Well, it seems that the "people" are speaking with one voice over here:
> 
> http://forums.livecode.com/viewtopic.php?f=6=25503
> 
> So, as an experiment in participatory democracy, and whether
> RunRev/LiveCode REALLY listen
> to their installed customer base, Please go there and give your opinion.
 If by the 'people' you mean yourself, one other person and another who 
 said he doesn't even use the application browser (and hasn't for years) ;)
>>> Well, I may not know much, but I do know that 'people' is a collective 
>>> noun, so, had I just meant myself I would have used 'person'.
>>> 
 To be fair, whilst preference *might* be an interesting thing to gauge... 
 Far more useful would be constructive criticism of both the Project 
 Browser and the Application Browser. It does seem a little 'silly' to 
 maintain two things which serve essentially the same purpose - so Ali's 
 idea is perhaps the best way forward - what is it that is good and bad 
 about both and is it possible to design something which everybody would be 
 happy with?
 
 Warmest Regards,
 
 Mark.
>>> 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
> 
> 
> ___
> 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: App Browser versus Project Browser

[Mark Schonewille]

What about making a poll?

Mark Schonewille
http://economy-x-talk.com

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

Op 10/7/2015 om 20:43 schreef Mark Waddingham:

Seriously, no need to feel hot about the collar :)

There are definitely people who do not like the project browser - that is clear.

I'd also suggest that there are people who don't like the application browser.

So - let us assume that it costs a good deal of time to maintain both and thus 
having one such thing would be preferable...

Is there a compromise in design which can be come to that satisfies most?

Sent from my iPhone


On 7 Oct 2015, at 19:31, Richmond  wrote:


On 07/10/15 21:22, Mark Waddingham wrote:

On 2015-10-07 20:08, Richmond wrote:
Well, it seems that the "people" are speaking with one voice over here:

http://forums.livecode.com/viewtopic.php?f=6=25503

So, as an experiment in participatory democracy, and whether
RunRev/LiveCode REALLY listen
to their installed customer base, Please go there and give your opinion.

If by the 'people' you mean yourself, one other person and another who said he 
doesn't even use the application browser (and hasn't for years) ;)

And Jacque Landman Gay.


To be fair, whilst preference *might* be an interesting thing to gauge... Far 
more useful would be constructive criticism of both the Project Browser and the 
Application Browser. It does seem a little 'silly' to maintain two things which 
serve essentially the same purpose - so Ali's idea is perhaps the best way 
forward - what is it that is good and bad about both and is it possible to 
design something which everybody would be happy with?

I wonder what the design team in Edinburgh feel is intrinsically wrong with the 
App Browser.

Warmest Regards,

Umm . . . feeling a bit hot round the collar.


Mark.

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



___
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: App Browser versus Project Browser

[Richmond]

On 07/10/15 21:43, Mark Waddingham wrote:

Seriously, no need to feel hot about the collar :)

There are definitely people who do not like the project browser - that is clear.

I'd also suggest that there are people who don't like the application browser.

So - let us assume that it costs a good deal of time to maintain both and thus 
having one such thing would be preferable...

Is there a compromise in design which can be come to that satisfies most?


Have you ever seen a compromise that satisfies most people?

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

R.


Sent from my iPhone


On 7 Oct 2015, at 19:31, Richmond  wrote:


On 07/10/15 21:22, Mark Waddingham wrote:

On 2015-10-07 20:08, Richmond wrote:
Well, it seems that the "people" are speaking with one voice over here:

http://forums.livecode.com/viewtopic.php?f=6=25503

So, as an experiment in participatory democracy, and whether
RunRev/LiveCode REALLY listen
to their installed customer base, Please go there and give your opinion.

If by the 'people' you mean yourself, one other person and another who said he 
doesn't even use the application browser (and hasn't for years) ;)

And Jacque Landman Gay.


To be fair, whilst preference *might* be an interesting thing to gauge... Far 
more useful would be constructive criticism of both the Project Browser and the 
Application Browser. It does seem a little 'silly' to maintain two things which 
serve essentially the same purpose - so Ali's idea is perhaps the best way 
forward - what is it that is good and bad about both and is it possible to 
design something which everybody would be happy with?

I wonder what the design team in Edinburgh feel is intrinsically wrong with the 
App Browser.

Warmest Regards,

Umm . . . feeling a bit hot round the collar.


Mark.

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


___
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: App Browser versus Project Browser

[Richmond]

On 07/10/15 21:54, Mark Schonewille wrote:

What about making a poll?


+1

Richmond.



Mark Schonewille
http://economy-x-talk.com

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

Op 10/7/2015 om 20:43 schreef Mark Waddingham:

Seriously, no need to feel hot about the collar :)

There are definitely people who do not like the project browser - 
that is clear.


I'd also suggest that there are people who don't like the application 
browser.


So - let us assume that it costs a good deal of time to maintain both 
and thus having one such thing would be preferable...


Is there a compromise in design which can be come to that satisfies 
most?


Sent from my iPhone


On 7 Oct 2015, at 19:31, Richmond  wrote:


On 07/10/15 21:22, Mark Waddingham wrote:

On 2015-10-07 20:08, Richmond wrote:
Well, it seems that the "people" are speaking with one voice over 
here:


http://forums.livecode.com/viewtopic.php?f=6=25503

So, as an experiment in participatory democracy, and whether
RunRev/LiveCode REALLY listen
to their installed customer base, Please go there and give your 
opinion.
If by the 'people' you mean yourself, one other person and another 
who said he doesn't even use the application browser (and hasn't 
for years) ;)

And Jacque Landman Gay.

To be fair, whilst preference *might* be an interesting thing to 
gauge... Far more useful would be constructive criticism of both 
the Project Browser and the Application Browser. It does seem a 
little 'silly' to maintain two things which serve essentially the 
same purpose - so Ali's idea is perhaps the best way forward - what 
is it that is good and bad about both and is it possible to design 
something which everybody would be happy with?
I wonder what the design team in Edinburgh feel is intrinsically 
wrong with the App Browser.

Warmest Regards,

Umm . . . feeling a bit hot round the collar.


Mark.

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



___
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: App Browser versus Project Browser

[Mark Schonewille]

That is a strange question: if we take away something you like, would 
you use the one and only thing that's left?


I think you need to be a little careful with that. While some people 
might use whatever tool is available, some other people will decide to 
use a different tool (like me), but yet again some other people might 
decide to switch to an entirely different programming environment.


--
Mark Schonewille
http://economy-x-talk.com

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

Op 10/7/2015 om 20:54 schreef Mark Waddingham:

So if we had deleted the app browser stack from the build, would your point of 
view have changed and would you have started to use the project browser? ;)

Sent from my iPhone


On 7 Oct 2015, at 19:46, Richmond  wrote:


On 07/10/15 21:40, Mark Waddingham wrote:
Indeed - but I don't think your tone of phrase was using it in that exact 
manner? ;)

By the way, I'm smiling here - it is a useful conversation to have if it is 
constructive. Either app browser bashing or project browser bashing isn't 
particularly useful to my mind.

I'm not Project Browser bashing as such.

I was very surprised when the Project Browser arrived, and played with it quite 
a bit, but reverted to the App Browser as could not
see any obvious advantages.

As both Browsers are present in current LiveCode 8 builds I don't actually see 
anything wrong with retaining both of them.

The fact that the menu system in the revMenuBar stack does NOT allow access to 
the App Browser does give out a signal which
is fairly blatant that the App Browser is not going to be with us much longer:

it was this that precipitated my small hack to allow access to the App Browser.

R.


What is useful is getting the information about what the best approach is to 
the problem - which is all I was trying to promote :)

Sent from my iPhone


On 7 Oct 2015, at 19:34, Richmond  wrote:


On 07/10/15 21:22, Mark Waddingham wrote:
On 2015-10-07 20:08, Richmond wrote:
Well, it seems that the "people" are speaking with one voice over here:

http://forums.livecode.com/viewtopic.php?f=6=25503

So, as an experiment in participatory democracy, and whether
RunRev/LiveCode REALLY listen
to their installed customer base, Please go there and give your opinion.

If by the 'people' you mean yourself, one other person and another who said he 
doesn't even use the application browser (and hasn't for years) ;)

Well, I may not know much, but I do know that 'people' is a collective noun, 
so, had I just meant myself I would have used 'person'.


To be fair, whilst preference *might* be an interesting thing to gauge... Far 
more useful would be constructive criticism of both the Project Browser and the 
Application Browser. It does seem a little 'silly' to maintain two things which 
serve essentially the same purpose - so Ali's idea is perhaps the best way 
forward - what is it that is good and bad about both and is it possible to 
design something which everybody would be happy with?

Warmest Regards,

Mark.

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


___
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: App Browser versus Project Browser

[Mark Waddingham]

As an indication of community division it might be useful - app browser/project 
browser/indifferent.

However, I'm not sure a poll would give us the information we need as it is too 
binary.

It's not about preference as such it's about having a component which serves 
everyone's needs.

The reality is that the app browser is old code wise and doesn't sit on the new 
abstractions we are building to make the components in the IDE more robust and 
easier to adapt and evolve.

We could certainly look at rewriting it on top of those abstractions - however, 
it seems sensible to find out if there is some sort of AppProjBrowser we could 
build first before considering such an undertaking.

Mark

Sent from my iPhone

> On 7 Oct 2015, at 19:54, Mark Schonewille  
> wrote:
> 
> What about making a poll?
> 
> Mark Schonewille
> http://economy-x-talk.com
> 
> Buy the most extensive book on the
> LiveCode language:
> http://livecodebeginner.economy-x-talk.com
> 
> Op 10/7/2015 om 20:43 schreef Mark Waddingham:
>> Seriously, no need to feel hot about the collar :)
>> 
>> There are definitely people who do not like the project browser - that is 
>> clear.
>> 
>> I'd also suggest that there are people who don't like the application 
>> browser.
>> 
>> So - let us assume that it costs a good deal of time to maintain both and 
>> thus having one such thing would be preferable...
>> 
>> Is there a compromise in design which can be come to that satisfies most?
>> 
>> Sent from my iPhone
>> 
 On 7 Oct 2015, at 19:31, Richmond  wrote:
 
> On 07/10/15 21:22, Mark Waddingham wrote:
> On 2015-10-07 20:08, Richmond wrote:
> Well, it seems that the "people" are speaking with one voice over here:
> 
> http://forums.livecode.com/viewtopic.php?f=6=25503
> 
> So, as an experiment in participatory democracy, and whether
> RunRev/LiveCode REALLY listen
> to their installed customer base, Please go there and give your opinion.
 If by the 'people' you mean yourself, one other person and another who 
 said he doesn't even use the application browser (and hasn't for years) ;)
>>> And Jacque Landman Gay.
>>> 
 To be fair, whilst preference *might* be an interesting thing to gauge... 
 Far more useful would be constructive criticism of both the Project 
 Browser and the Application Browser. It does seem a little 'silly' to 
 maintain two things which serve essentially the same purpose - so Ali's 
 idea is perhaps the best way forward - what is it that is good and bad 
 about both and is it possible to design something which everybody would be 
 happy with?
>>> I wonder what the design team in Edinburgh feel is intrinsically wrong with 
>>> the App Browser.
 Warmest Regards,
>>> Umm . . . feeling a bit hot round the collar.
>>> 
 Mark.
>>> 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
> 
> 
> ___
> 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: App Browser versus Project Browser

[Richmond]

On 07/10/15 21:54, Mark Waddingham wrote:

So if we had deleted the app browser stack from the build, would your point of 
view have changed and would you have started to use the project browser? ;)


When I finally got to look at a LiveCode 8 build after a week's hiatus 
with various computer problems,
as the App Browser  was not accessible from the menus my first reaction 
was to try to export the

App Browser from LiveCode 7.1 and port it over to LiveCode 8.

While I'm on a roll, I could also point out that I cannot see any 
obvious advantages in the complete

remake of the Preference Palette in LiveCode 8.

To contextualise things: I remember the major interface overhaul that 
took place via RR/LC 2.6 to 3.0,
and the 'new' preference palette was vastly better than the previous 
one, as was the whole IDE.


Richmond.



Sent from my iPhone


On 7 Oct 2015, at 19:46, Richmond  wrote:


On 07/10/15 21:40, Mark Waddingham wrote:
Indeed - but I don't think your tone of phrase was using it in that exact 
manner? ;)

By the way, I'm smiling here - it is a useful conversation to have if it is 
constructive. Either app browser bashing or project browser bashing isn't 
particularly useful to my mind.

I'm not Project Browser bashing as such.

I was very surprised when the Project Browser arrived, and played with it quite 
a bit, but reverted to the App Browser as could not
see any obvious advantages.

As both Browsers are present in current LiveCode 8 builds I don't actually see 
anything wrong with retaining both of them.

The fact that the menu system in the revMenuBar stack does NOT allow access to 
the App Browser does give out a signal which
is fairly blatant that the App Browser is not going to be with us much longer:

it was this that precipitated my small hack to allow access to the App Browser.

R.


What is useful is getting the information about what the best approach is to 
the problem - which is all I was trying to promote :)

Sent from my iPhone


On 7 Oct 2015, at 19:34, Richmond  wrote:


On 07/10/15 21:22, Mark Waddingham wrote:
On 2015-10-07 20:08, Richmond wrote:
Well, it seems that the "people" are speaking with one voice over here:

http://forums.livecode.com/viewtopic.php?f=6=25503

So, as an experiment in participatory democracy, and whether
RunRev/LiveCode REALLY listen
to their installed customer base, Please go there and give your opinion.

If by the 'people' you mean yourself, one other person and another who said he 
doesn't even use the application browser (and hasn't for years) ;)

Well, I may not know much, but I do know that 'people' is a collective noun, 
so, had I just meant myself I would have used 'person'.


To be fair, whilst preference *might* be an interesting thing to gauge... Far 
more useful would be constructive criticism of both the Project Browser and the 
Application Browser. It does seem a little 'silly' to maintain two things which 
serve essentially the same purpose - so Ali's idea is perhaps the best way 
forward - what is it that is good and bad about both and is it possible to 
design something which everybody would be happy with?

Warmest Regards,

Mark.

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


___
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: App Browser versus Project Browser

[Mark Waddingham]

Seriously, no need to feel hot about the collar :)

There are definitely people who do not like the project browser - that is clear.

I'd also suggest that there are people who don't like the application browser.

So - let us assume that it costs a good deal of time to maintain both and thus 
having one such thing would be preferable...

Is there a compromise in design which can be come to that satisfies most?

Sent from my iPhone

> On 7 Oct 2015, at 19:31, Richmond  wrote:
> 
>> On 07/10/15 21:22, Mark Waddingham wrote:
>>> On 2015-10-07 20:08, Richmond wrote:
>>> Well, it seems that the "people" are speaking with one voice over here:
>>> 
>>> http://forums.livecode.com/viewtopic.php?f=6=25503
>>> 
>>> So, as an experiment in participatory democracy, and whether
>>> RunRev/LiveCode REALLY listen
>>> to their installed customer base, Please go there and give your opinion.
>> 
>> If by the 'people' you mean yourself, one other person and another who said 
>> he doesn't even use the application browser (and hasn't for years) ;)
> 
> And Jacque Landman Gay.
> 
>> 
>> To be fair, whilst preference *might* be an interesting thing to gauge... 
>> Far more useful would be constructive criticism of both the Project Browser 
>> and the Application Browser. It does seem a little 'silly' to maintain two 
>> things which serve essentially the same purpose - so Ali's idea is perhaps 
>> the best way forward - what is it that is good and bad about both and is it 
>> possible to design something which everybody would be happy with?
> 
> I wonder what the design team in Edinburgh feel is intrinsically wrong with 
> the App Browser.
>> 
>> Warmest Regards,
> 
> Umm . . . feeling a bit hot round the collar.
> 
>> 
>> Mark.
> 
> 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

App Browser versus Project Browser

[Richmond]

Well, it seems that the "people" are speaking with one voice over here:

http://forums.livecode.com/viewtopic.php?f=6=25503

So, as an experiment in participatory democracy, and whether 
RunRev/LiveCode REALLY listen

to their installed customer base, Please go there and give your opinion.

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: App Browser versus Project Browser

[Mark Waddingham]

On 2015-10-07 20:08, Richmond wrote:

Well, it seems that the "people" are speaking with one voice over here:

http://forums.livecode.com/viewtopic.php?f=6=25503

So, as an experiment in participatory democracy, and whether
RunRev/LiveCode REALLY listen
to their installed customer base, Please go there and give your 
opinion.


If by the 'people' you mean yourself, one other person and another who 
said he doesn't even use the application browser (and hasn't for years) 
;)


To be fair, whilst preference *might* be an interesting thing to 
gauge... Far more useful would be constructive criticism of both the 
Project Browser and the Application Browser. It does seem a little 
'silly' to maintain two things which serve essentially the same purpose 
- so Ali's idea is perhaps the best way forward - what is it that is 
good and bad about both and is it possible to design something which 
everybody would be happy with?


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: App Browser versus Project Browser

[Richmond]

On 07/10/15 21:22, Mark Waddingham wrote:

On 2015-10-07 20:08, Richmond wrote:

Well, it seems that the "people" are speaking with one voice over here:

http://forums.livecode.com/viewtopic.php?f=6=25503

So, as an experiment in participatory democracy, and whether
RunRev/LiveCode REALLY listen
to their installed customer base, Please go there and give your opinion.


If by the 'people' you mean yourself, one other person and another who 
said he doesn't even use the application browser (and hasn't for 
years) ;)


And Jacque Landman Gay.



To be fair, whilst preference *might* be an interesting thing to 
gauge... Far more useful would be constructive criticism of both the 
Project Browser and the Application Browser. It does seem a little 
'silly' to maintain two things which serve essentially the same 
purpose - so Ali's idea is perhaps the best way forward - what is it 
that is good and bad about both and is it possible to design something 
which everybody would be happy with?


I wonder what the design team in Edinburgh feel is intrinsically wrong 
with the App Browser.


Warmest Regards,


Umm . . . feeling a bit hot round the collar.



Mark.



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: App Browser versus Project Browser

[Richmond]

On 07/10/15 21:22, Mark Waddingham wrote:

On 2015-10-07 20:08, Richmond wrote:

Well, it seems that the "people" are speaking with one voice over here:

http://forums.livecode.com/viewtopic.php?f=6=25503

So, as an experiment in participatory democracy, and whether
RunRev/LiveCode REALLY listen
to their installed customer base, Please go there and give your opinion.


If by the 'people' you mean yourself, one other person and another who 
said he doesn't even use the application browser (and hasn't for 
years) ;)




Well, I may not know much, but I do know that 'people' is a collective 
noun, so, had I just meant myself I would have used 'person'.


To be fair, whilst preference *might* be an interesting thing to 
gauge... Far more useful would be constructive criticism of both the 
Project Browser and the Application Browser. It does seem a little 
'silly' to maintain two things which serve essentially the same 
purpose - so Ali's idea is perhaps the best way forward - what is it 
that is good and bad about both and is it possible to design something 
which everybody would be happy with?


Warmest Regards,

Mark.



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: App Browser versus Project Browser

[Mark Waddingham]

Indeed - but I don't think your tone of phrase was using it in that exact 
manner? ;)

By the way, I'm smiling here - it is a useful conversation to have if it is 
constructive. Either app browser bashing or project browser bashing isn't 
particularly useful to my mind.

What is useful is getting the information about what the best approach is to 
the problem - which is all I was trying to promote :)

Sent from my iPhone

> On 7 Oct 2015, at 19:34, Richmond  wrote:
> 
>> On 07/10/15 21:22, Mark Waddingham wrote:
>>> On 2015-10-07 20:08, Richmond wrote:
>>> Well, it seems that the "people" are speaking with one voice over here:
>>> 
>>> http://forums.livecode.com/viewtopic.php?f=6=25503
>>> 
>>> So, as an experiment in participatory democracy, and whether
>>> RunRev/LiveCode REALLY listen
>>> to their installed customer base, Please go there and give your opinion.
>> 
>> If by the 'people' you mean yourself, one other person and another who said 
>> he doesn't even use the application browser (and hasn't for years) ;)
> 
> Well, I may not know much, but I do know that 'people' is a collective noun, 
> so, had I just meant myself I would have used 'person'.
> 
>> To be fair, whilst preference *might* be an interesting thing to gauge... 
>> Far more useful would be constructive criticism of both the Project Browser 
>> and the Application Browser. It does seem a little 'silly' to maintain two 
>> things which serve essentially the same purpose - so Ali's idea is perhaps 
>> the best way forward - what is it that is good and bad about both and is it 
>> possible to design something which everybody would be happy with?
>> 
>> Warmest Regards,
>> 
>> Mark.
> 
> 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