Submitted by LeftEccoForIQ on 2025/03/23 03:54

Hi Pierre,

- minor: when the new Properties Pane filter box has the focus (which is the statup default, I think), the pane cannot be scrolled with the wheel, which is kind of annoying. Maybe not set focus on the box on startup or make pane scrollable anyway.

- major issue: I think this was introduced with: "Fixed: Grid: Moving an item to be under a new parent could remove it from another parent item". It seems that you've over-compensated so that now when an item is made a TLI in another grid (maybe just when that grid is shown in a second pane - haven't checked), it retains its parent context from the source grid. Please see the attached screencast. (After dragging the item back to the main grid as a TLI, I refreshed that grid and it brought back the context from the original grid.) If this was intentional, it would be a fundamental change in the way IQ operates. 

Looking back, I don't understand Wayne's post (here) and your fix. Isn't what Wayne described as a bug the default (and intended) behaviour? I admit I have been fully ignorant of the whole idea of multiple parents as it is not how I work. However, I believe there should be a clear distinction between traditional outlining, where items can only be in one hierarchical place at a time, and this new approach, which introduces ambiguty.

The manual states with regard to drag and drop: "By default, items are moved. To leave items at their current place and add these in another place (i.e. shown in multiple grids or under more than one parent), press the Ctrl key while dragging the item(s) (i.e. not before drag-drop)". I hope we can agree that this should be the fundamental principle.

So when Wayne states "In grid-2, move "Sub-item 1" underneath Parent-2.  Note that sub-item loses its assignment to Parent-1 in grid-1 =", this is what I'd expect to happen. If you want the item to remain under the parent in grid 1 and want to add an extra, "secondary" parent, I'd say users would need to use a specific command like Ctrl-Drag (perhaps there should be a keyboard equivalent, too?).

I suppose that once an item has multiple parents, things get complicated. What happens when you drag and drop such an item without holding down CTRL? Does that depend on whether you've picked it up under its main or secondary parent? Which one is overwritten by the target position of this drag? Or does this just add a tertiary parent?

Cheers

Edit: Seems I can't upload screencasts anymore so have put it on imgur.

 

Comments

Hi Left,

The fix for Wayne's issue was needed. Moving an item under a parent should not remove it from other parents (unless the other parent is shown in that grid, in which case the user knows that it needs to hold the Ctrl key to preserve the parent link)

Now, in your case, would you agree that it is ONLY an issue in a very particular case:

  • The sub-item in the source grid is drag-dropped to become a TLI in another instance of the same grid

Then it is true that it should lose it parent link. In all other cases, it should not

Pierre_Admin
IQ Designer

Also, isn't the implementation inconsistent with regard to e. g. Wayne's modus operandi? When I drag a subitem to become a TLI in another grid, it retains the parent in the source grid, but when I drag it under a new parent in the target grid it does not? Or maybe it does and I don't now where to look? The Properties Pane doesn't indicate anywhere that it has a secondary parent and it's gone from the source grid even on refresh...

That looks to me like in this case drag and drop does 'move' rather than 'add in new place'. My mind still boggles...

BTW, just now IQ was doing 'pure' moving again in the very same situation of the screencast. Had to restart it to make it retain the parent context again. There seems to be a bug where under certain conditions IQ enters a state in which it forgets to retain the context. Couldn't reproduce but will continue to look out for it.

Hi Pierre,

Moving an item under a parent should not remove it from other parents

I'm sorry, but my mind is starting to boggle here because the opposite of what you are saying has been my assumption in working with IQ over the years. I used to grab a subitem and drag it to a new position anywhere, either in the same or a different grid, either as a TLI or a subitem and my expectation was for it to always disappear from under its parent in the source grid without it showing any trace of its previous position in the target position. This was also the user experience in Ecco. When I asked you to change behaviour in what led to Wayne's issue, I though that was kind of glitch or oversight because it did not fit in with my expectations. Obviously that was not the case, but it was connected to the multiple parent functionality.

So now if you are saying that the behaviour I'm showing in the screencast is the expected behaviour this puts me at a loss. I drag (which, in accordance with the manual, I take to mean 'move') a subitem to a TLI position in a different grid but the item is not moved but instead added to the new place on top of its existing position? I refresh the target grid and suddenly the item is no longer shown as a TLI but hidden under the "shadow" of a non-existent parent (that is not present in that grid)? Not at all desirable for how I use outlining. I refresh the source grid and the item is back where it was in the first place? For me that means the drag operation did not perform its primary (and sole?) purpose of moving the item.

In effect then, this changes the functionality of drag and drop from 'move' to a kind of 'backlink to', which does not make sense to me as its breaks basic outlining functionality for the sake of the "side hustle" of allowing multiple parents for a (small for almost any user?) subgroup of items. Like I said, I feel there need to be two different commands to achieve the effects of 'move' and 'backlink to' (or 'add to target position' if you will) in the first place. I thought most people would expect an outliner to do basic outlining by default but maybe that's not the case.

Anyway, I'd be very happy if you could introduce a 'pure' move command that I could use as an option or by holding a modifier during drag and drop. I don't really mind if it's not the default for drag and drop because I can probably achieve this via Autohotkey but my gut feeling is that it should be.

Cheers

 

Hi Left,

You should not see any major change to the behavior as very little has changed:

  1. Drag-drop from a parent in one grid to another grid will do a move
  2. If the item's parent is not shown in the source grid, a drag-drop will not remove it from that parent
  3. Remember, in Wayne's case, initially he did not do a drag-drop, he simply assigned a field value, then in grid 2, he moved it to be under a new parent (parent 2). In this case, parent 1 remains

So the operation that you showed in that screencast will now work as you expected

If the item's parent is not shown in the source grid, a drag-drop will not remove it from that parent

Sorry, but this is exactly where I see the problem. Pre12 did not help with it, I really need a way to drag and drop so that the item will be removed from the source parent.

So this only applies when the item is parked at top level in the new grid first (or otherwise assigned to the grid source field), then moved on to a child position in that grid as a second step. Moving it directly under a new parent in the target grid will remove the source grid parent-child relation, won't it? I can't really grasp the logic behind this seemingly inconsistent approach, but that may be due to my never having made use of multiple parents. Wouldn't it be cleaner to have an 'add item here'-type drag command that would retain the source parent in any case (dropping at top or child level) and have a 'move item here'-type drag command that would always remove the source parent?

Here is what it feels like for me (as shown in the screencast): The dragged item first seemingly disappears from the source grid (this is due to my having the 'Keep source field values...' option disabled for the source grid, I think. It does not disappear with the option checked) and appears as a normal TLI in the target grid. Great, that's what I want. But on refresh or when restarting IQ things start to go horribly wrong. The item is now back under its parent in the source grid, from which I asked IQ to remove it by performing the drag in the first place, but not only that, it suddenly appears as a subitem with the "blued-out" parent from the other grid in the target grid as well.

This state of affairs will be really hard for me to tolerate in the long term, as it is utterly counter-intuitive to my 25 years of outliner experience. For all of these items unintentionally appearing under ghost parents, I then have to first unfold the 'ghost tree' (in which my 'top level' item (now not at top level) is now hidden from view) and then manually drag them back to top level to make it lose its unwanted association with the ghost parent for good and to return it to top level, where I had dropped it in the first place. To make things worse, this problem only becomes apparent on refreshing the grid or restarting IQ so I have to turn back from what I am currently working on to stuff I did earlier to fix these uwanted results.

Sorry about all my rambling posts here but having to take four actions (drag, refresh / wait for next IQ session, unfold, drag again) for such a basic operation as 'move child item to become a top item in a different grid' is giving me the creeps.

OK, let's recap

Grid 1

  • Parent 1
    • Sub 1
    • Sub 2

You then drag Sub 1 to be a TLI of Grid 2. It works as expected

Can you describe your case and/or show a screencap (light theme) with if possible some audio

 

Thanks for looking into this!

So, here is a new subitem in grid 'Week' shown in a pane at the left.

Now I've dragged the item across to become a TLI in grid 'Act' in the main pane. Everything looks like it should, the item is gone from the 'Week' grid and a TLI in 'Act'.

Now when I refresh the grid in the pane on the right, the parent from the source grid 'Week' makes its unwanted appearance in the other grid. If I hadn't refreshed but had restarted IQ, the 'Mittwoch' tree would even be folded and the subitem would be hidden instead of being visible as a TLI.

Refreshing the source grid now reveals that the subitem also still exists in its original location from which I was intending to remove it. To fix this, I (usually) have to unfold the tree under the blue context parent, move the subitem up to top level in that grid (again), then refresh the grid to hide the blue context parent. I move items in this exact way several times a day as part of my daily task management, which makes it a substantial annoyance.

Bug reports