Re: Grouping Controls in selectGroupedControls mode

2017-10-06 Thread J. Landman Gay via use-livecode
I run for days at a time with selectGroupedControls turned on, setting it 
to false is the exception. It's already possible to align or move any 
controls together regardless of the groups they are in.


While I rarely use the project browser, it's my understanding that you can 
align and manipulate multiple controls even if they are on different cards 
or stacks.



On October 6, 2017 2:06:10 PM Sannyasin Brahmanathaswami via use-livecode 
 wrote:


NOW! I want to be able to select any object at any time, sometime even 
object in different groups.. go to align, align left, move over 5 pointes 
etc… and typically run with "selectGroupedControls" on… for days at a  stretch.


--
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: Grouping Controls in selectGroupedControls mode

2017-10-06 Thread Sannyasin Brahmanathaswami via use-livecode
@ Mark As one who is constantly switching from Indesign (editorial work for our 
magazine) and Livecode

My testimony is I can't tell you often I "bark" at indesign "why on earth can't 
I change the properties of a single object in a group without ungrouping! like 
we can do in Livecode!"

So what you describe as "non-standard" I see has a huge plus.

That said, I agree there are frequent times (and lots of wasted time) ensuing 
from the "condition" in selectGroupControls where all the objects become 
untethered from their group.

If but people work in in different ways, so possibly you will need to use 
preferences.

The typical work flow I find, both in Indesign and in Livecode

Phase one: creating the Layout/UI/UX -- 
# Now we doing a lot of testing creation of groups, adding objects, one is 
more focused on the overall layout architecture and structure, if some 
objects/controls in a group are not quite right yet, you tend to ignore this 
saying to yourself "I will tweak all the eye candy later" and if you scripting 
architecture is picking the target higher up the msg path 80% of the objects 
may have no script at all. so you are never editing scripts of objects… working 
in the card script, the stackscript or a external text only behavior etc.  more 
and more I am never touching any script of any object (which still surprises me)
 
  in this environment the model you describe as in Pages has utility. It keeps 
us from creating weird issues we face, Where the "sankalpa" - intention is to 
be creating objects in a group or add an object to an existing group, there a 
too many caveats right now. 

I frequently end up with an object that appears outside the intended group. One 
has to train oneself to constantly to toggle the selectGroupedControls on and 
off, and if you miss it just once, suddenly you have a new object on the card 
outside all groups. relayering in deeply nested groups is too  tricky: select, 
cut, switch off selectGroupControls edit, edit, now in nested group: paste.  

So this behavior would seem useful:

Mark: "Double-clicking on a object within the selected group will select the
object, or the next nested group if the object is within the group."

And Yes this! "  When you create an object it is created in the currently 
selected
group of the group which directly contains the selected object.

I like this too…"When a nested object is selected, its immediate owning group 
has a
border around it (grey, rather than the blue of the selected border 

Though Richard is concerned about adding more default border treatments for 
apps that use the pointer too: which is a valid point.

 Yes " So, anyway, perhaps just making the 'Group' operation enabled/disabled
based on selected objects is the most reasonable thing to do now."


--
But not this!

 "However, it would be nice to imagine how selectGroupedControls could
actually be eliminated" 

Ouch: think carefully before eliminating what is a huge plus/feature for LC 
over the "other tools" people are coming from.

Phase 2
  OK most of  the UI/UX architecture is locked in, the UX designer's interface 
is all laid out. Stack holders reviewed signed off "OK looks good, lets go with 
it like this."

NOW! I want to be able to select any object at any time, sometime even object 
in different groups.. go to align, align left, move over 5 pointes etc… and 
typically run with "selectGroupedControls" on… for days at a  stretch.

And of course sometimes we toggle back and forther between

phase 1 (create UI/UX) and 
phase 2 (tweaks objects, work on scripts) 

In the course of several sessions in a single day.

Just my two avocados from Kauai

BR



On 10/6/17, 2:36 AM, "use-livecode on behalf of Mark Waddingham via 
use-livecode"  wrote:

   When you create an object it is created in the currently selected 
group of the group which directly contains the selected object.

Of course, the last rule here exposes a distinct difference in the way 
things are created in Pages compared to LiveCode - in LiveCode, the 
'object tools' allow you to click-drag-create; whereas in Pages it is 
click to create at standard size and then edit.

So, anyway, perhaps just making the 'Group' operation enabled/disabled 
based on selected objects is the most reasonable thing to do now.

However, it would be nice to imagine how selectGroupedControls could 
actually be eliminated - as it (together with 'Edit Group mode') are, 
well, just plain odd when viewed from the eyes of someone coming from 
other tools which have the concept of object and group.

Warmest Regards,

Mark.

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

Grouping Controls in selectGroupedControls mode

2017-10-06 Thread Mark Waddingham via use-livecode

Hi all,

I just wondered if anyone had any thoughts on this report:

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

The summary of the report is that when a 'group' operation fails you 
only get a 'beep' and no indication as to why the failure occurred.


Group operations will fail if the owner of all controls being grouped is 
not the same - I think this is a reasonable restriction, as otherwise it 
would be very easy to break things by accidentally grouping controls you 
did not intend. Obviously, the obvious 'fix' is to make it so that the 
'Group' operation in the IDE is disabled if the owner-rule is violated.


However, whilst perhaps clearer in the sense you would know ahead of 
time whether you can group, it still does not help you work out *why* 
you cannot group. One thought I had here was whether a visual indication 
of the ownership of selected controls in 'selectGroupedControls' mode 
might help - basically perhaps painting a subtle border around the 
owning groups of each selected object.


Of course, this might just be highlighting the fact that 
'selectGroupedControls' mode in LiveCode is perhaps somewhat 
'non-standard'. For example Pages (which just happened to be a 
convenient app I have installed which does grouping and such) works 
quite differently:


  Clicking on a grouped object selects the group.

  Double-clicking on a object within the selected group will select the 
object, or the next nested group if the object is within the group.


  You can only select object / groups together which have the same 
owner.


  You can select a nested object directly by doing an 'n-click' - where 
n is the nesting of the group


  When a nested object is selected, its immediate owning group has a 
border around it (grey, rather than the blue of the selected border).


  When you create an object it is created in the currently selected 
group of the group which directly contains the selected object.


Of course, the last rule here exposes a distinct difference in the way 
things are created in Pages compared to LiveCode - in LiveCode, the 
'object tools' allow you to click-drag-create; whereas in Pages it is 
click to create at standard size and then edit.


So, anyway, perhaps just making the 'Group' operation enabled/disabled 
based on selected objects is the most reasonable thing to do now.


However, it would be nice to imagine how selectGroupedControls could 
actually be eliminated - as it (together with 'Edit Group mode') are, 
well, just plain odd when viewed from the eyes of someone coming from 
other tools which have the concept of object and group.


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