In particular, how to give a commit a note/message...

Also want to throw errors for other problems too...

...unless this scuppers indexOf and/or splice..?

Currently, Group.draw() and Shape.draw() take different arguments - ideally I think we should match these up, as then we needn't have differing calls to draw() depending on various conditions...

Maybe use .draw(active, drawingContext, colour, line_colour)..? And let Shape.draw() decide how to show active / non-active shapes? - how do we best standardise the transparency/grey-ness across different shapes..? - maybe add a inactive() method to Colour?..

This is sort of the opposite of Issue #13, although a little more complicated. Needs ability to insert items at a given point in a group (related to Issue #9).
Need to decide where to insert the new sub-group if the selected items are scattered through the parent group... Choices are probably:

• front-most position of selected items
• back-most position of selected items
• half way between the front-most and back-most positions
• average (mean?) of all the item's positions
• position of the 'middle' item within the selection
  • for an even number of items, go for the front-middle item
• identify the largest contiguous section of selected items within the parent group
  • when there are multiple sections of the same size, go for the (front-)middle section

For a group of ten items, with 3 selected, these might produce the following results:

1
2 Selected - Back-most
3 Selected - 'Middle' item + Largest contiguous selection
4
5 'Average' position
6 'Half-way' position
7
8
9
10 Selected - Front-most

I think I currently favour Largest contiguous selection... Second choice is probably 'Middle' item (with a bias towards 'front-middle' if there an even number of items selected), and third choice is probably Front-most.

Maybe (eventually) offer this as an option to the user..? Either a global option, or a pop-up option when grouping items (if different algorithms give different results...)..?? (pop-up option might get really annoying!..)

Currently a group doesn't really have a maxX, maxY, etc. This means that a group containing a group doesn't draw it's selected box correctly!..

...purely just to make it seem a little more list-like in the Chrome Debugger...

Add things like 'delete()' (which can just call parent.delete(this)) and 'select()' (which can call parent.selection.add(this))... Could make code elsewhere much more legible!

It might also be neat to change 'parent' and 'index' into getter/setter values, with the setter function calling the appropriate functions to make the change...

For example, until recently Group.moveAndResetDragOffset would directly change Shape.x, Shape.y and Shape.dragOffset - I think it's better to call a function within Shape.prototype (or a more specific version from Circle) to make these changes. This keeps code related to modifying Shapes within Shape, etc...

In case we ever want to know what is somewhere other than under the mouse!

Copy out details from archive versions

Mouse.prototype.cancelDrag() contains a loop to (try to) reset all the selected objects' offsets to mouse.dragNoOffset - but the loop doesn't iterate down through any groups. So the group itself gains an offset property, and the child elements remain with their offset properties linked to mouse.dragOffset - therefore if you subsequently drag another item, the group moves with it! And then, even weirder, pings back to where it was when you finish the drag (when mouse.dragOffset gets reset to null values)!!

Instead of this (faulty) loop, Mouse.prototype.cancelDrag() should just call current_stack.selection.setOffset(this.dragNoOffset)...

Currently they get put at the front of the group, regardless of where the sub-group was. Requires ability to insert items within a group at a certain point - related to Issue #9.

ie. if we have

1. Circle (1)
2. Group (2)
   1. Circle (3)
   2. Group (4)
      1. Circle (5)
      2. Circle (6)
   3. Circle (7)
3. Circle (8)

Then ungrouping Group (2) should leave us with this:

1. Circle (1)
2. Circle (3)
3. Group (4)
   1. Circle (5)
   2. Circle (6)
4. Circle (7)
5. Circle (8)

But it looks like it currently leaves this:

1. Circle (1)
2. Circle (3)
3. Circle (5)
4. Circle (6)
5. Circle (7)
6. Circle (8)

...should only get called once, when the item is first created!

Maybe also add another method - something like .move() for when an item moves from one group to another..?

Not yet sure of exactly what's going on, but it looks like any items that are selected within the group go wrong - presumably their .selected property is remaining set, but they are not actually listed within the new .selection list..?

Should have left, right, top, bottom, width & height properties, which auto-update when one is changed.

Would be great if it were possible to link to (some of) these attributes somehow - eg so that a group's left was actually just a link to the left-most item's left, so that as the group gets moved around the group's left automatically follows the item's left, with no additional work. (similar to the concept of how mouse.dragOffset works)

If you delete everything, then Item.count == 1... Technically this is correct, but it's a misleading piece of information.
Alternatively, maybe we want to add indicators of how many items there are in the current view (plus in the current selection would be nice!)..?

Currently it is created in both Group() and Shape()! (Previously Groups didn't have any need for it, but now they do)

May need to tweak some code to keep the attributes of the .dragOffset property the same (currently they are set up differently for Groups and Items...)

It would help to reduce the chance of conflicts (like Issue #24) if we had either a Selection list or .selected flags - not both. .selected flags reduce/remove the need to call Selection.indexOf() - which I believe speeds things up a little bit for frequently called functions like draw(). If we got rid of the Selection list then various operations would need to iterate through the entire group to find the currently selected items, which will be (a little bit) slower - but if these are only called occasionally then that's not too much of a concern...

Would it still be useful to keep a count of selected items (for Selection.any() for example), or is that still (in effect) leaving room for conflicting information..?

Should have similar behaviour to how Group.delete() works!

Might need to check over the code that calls Group.remove() - especially ungrouping code - does it also attempt to delete the group after removing everything from it..?

We sometimes set the conf property to true, but never (yet) enu

Currently they do similar, related functions - but they return different things (and Group.whichItem() takes a parameter, whereas Shape.isMouseOver() doesn't). It would be nicer/neater/better if we could use the same function name for Shapes and Groups (and CompoundItems)... Maybe whatIsHere()? Or just whichItem() - although that reads a little odd within the context of a Shape..?

Currently we have no check to make sure that the item passed actually belongs to the group...

Mainly for three reasons:
1 Reduce repetition of code
2 Make the code a little more readable
3 It looks like the Chrome debugger will treat an Object as being Array-like if it has a splice() method in the prototype... This isn't conclusive, but removing the function from my prototypes seems to make Chrome remove the length in square-brackets from the object name (see also this answer to a similar question on Stack Overflow)

Currently a simple click causes the 'move' cursor to appear briefly. If we could add a delay before showing it (0.5s? 0.2s?) that would be nicer. At the same time, if the cursor actually moves (between a mousedown event and a mouseup event) then it should instantly change to a 'move' cursor!..