Grouping Controls in selectGroupedControls mode

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

Grouping Controls in selectGroupedControls mode

J. Landman Gay 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 ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

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

Re: Grouping Controls in selectGroupedControls mode

J. Landman Gay 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" <[hidden email] on behalf of [hidden email]> 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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Grouping Controls in selectGroupedControls mode

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
<[hidden email]> 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         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com



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