InfoQube IM - Community

Submitted by Jon on 2011/02/24 08:49

Using version K. I confess that I do not use links all that much to create multiple parents, so this may be my problem. I do use the Ultra Recall equivalent of this quite a lot, and must say that it is rather simple and straightforward.

I have created links by CTRL-Dragging to another parent in another grid. I have also used the copy/past link method. Both yield similar results. Thhe property pane lists each of thhe linked items as having only one parent, and the items no longer are displayed in their original location. I have refreshed the grids and re-started IQ.

Is it something I am doing wrong?

Jon

Comments

[quote=Jon]I have created links by CTRL-Dragging to another parent in another grid. I have also used the copy/past link method. Both yield similar results. Thhe property pane lists each of thhe linked items as having only one parent, and the items no longer are displayed in their original location. I have refreshed the grids and re-started IQ.[/quote]

I'll chance replying as I do this a lot, but just using the Ctrl+Drag method.

Just realised I was still with version J - now have K installed - I still cant reproduce it though (again with Ctrl+Drag)

Can you clarify -

does this always happen?

I presume the one parent is the "destination" parent? Which would mean the item is moved, rather than simply being given a new parent.

Which sounds like a bug - if we can just figure out how/when it happens...

[quote=Jon]

I'm curious how UR does this?

[quote=Tom]

[quote=Jon]

I'm curious how UR does this?

[/quote] Am curious too...

Thanks for reporting this problem, Jon. Like Tom, I'm not sure what's happening. I can't reproduce it. I use ctrl-click drag & drop multiple times a day and never have a problem. Maybe you're releasing the "ctrl" key too soon ?

Tom and Armando:

Thanks for testing.

For Tom:

Can you clarify -
does this always happen?

Yes.

I presume the one parent is the "destination" parent?

Correct.

Which would mean the item is moved, rather than simply being given a new parent.

Yes. However, I am trying to link items to another grid, but after refreshing the grids, the items show in both. Now if moved, I would expect to see their occurrence in only one of the grids. What I see is the destination grid displays the items under their new parent. The grid of origin displays the items too, but the new parent appears as a context parent. Properties indicates one parent.

For Armando and Tom:

UR can create these types of links using a few methods. My tree is quite large and deep, so using any method involving drag/drop does not work well. The easiest way is to right-click on the item and choose Link/Move. Youa are then presented with a dialogue that has a miniature version of the tree.Navigate to the parent you want to create the links under and click OK. In this dialogue there are choices to copy, move or link.

Oh, and there is an easier way. Copy/paste creates links by default. Very quick and easy..

In IQ, you can also tag the item and then right-click on a parent and select Add tagged items as sub-items

Otherwise, I'll try to reproduce it and will report back

[quote=Jon]

[/quote]

There's something I don't quite get. Are you trying to move items (click + drag & drop) or create a new link (ctrl + click + drag & drop) ?

In any case, there are at least 2 things not behaving intuitively :

First case :

1- move a sub-item (click + drag & drop) from a grid to another grid, but dropping it as a TLI in the second grid.

2- refresh both grids : item is still in the first grid.

Second case (this will create an instant crash here) :

1- move a TLI (click + drag & drop) from a grid to another grid, but dropping it as a Sub-item in the second grid.

2- IQ crashes.

Can anyone confirm that ?

Jon : are there other weird cases which steps could be broken down ?

[quote=Jon]

For Armando and Tom:

Oh, and there is an easier way. Copy/paste creates links by default. Very quick and easy..

[/quote]

This is quite similar to IQ IMO.

1- Like Pierre said (and I did too in another of your threads I think), you can tag any items to create a list (in the properties pane you can see that list of tagged items), and then select any item wherever you want, right click and select : "add tagged items as sub-items"

2- Copy paste, as you know will also work. The terminology might be clunky and the dialog might miss the option to "paste as sub items of the selected item" (there's a Mantis issue for that), but... it does work. No ?

Hi Armando:

Second case (this will create an instant crash here) :
1- move a TLI (click + drag & drop) from a grid to another grid, but dropping it as a Sub-item in the second grid.
2- IQ crashes.

Can anyone confirm that ?

Confirmed.

Jon

Confirmed and fixed in v0.9.25L

Thanks for reporting !

Are both of these fixed : [quote] First case : 1- move a sub-item (click + drag & drop) from a grid to another grid, but dropping it as a TLI in the second grid. 2- refresh both grids : item is still in the first grid. Second case (this will create an instant crash here) : 1- move a TLI (click + drag & drop) from a grid to another grid, but dropping it as a Sub-item in the second grid. 2- IQ crashes. [/quote] or one of the two ? thanks

[quote=Jon]

[/quote]

There's something missing here - I presumed it was a sub-item you were wanting to show in another grid - am I incorrect?

(I presumed because it already had a parent - which is not fully logical, I know ...)

You say the item shows in both, in the first post, you say the items no longer are displayed in their original location.

Can you clarify there? Thanks.

Hi Tom:

Good assumption. I realized this on my drive to work, but you beat me to it. In UR, all items are below the root entry which cannot be deleted (the root that is). I was wondering about the difference in the way the two programs handle these links (in UR they are called clones which helps differentiate them from other types of links). So ultimately, all items in UR must have a parent. What I was doing in IQ was trying to link (clone) a TLI to a new parent in another grid. This seems to be a limitation that should not exist. In Ecco, there are occasional issues with orphaned items, and I don't think that in IQ TLIs are orphans. They have an ID, are assigned to a grid, etc. It seems to me that I should be able to make a TLI a clone. Do you agree?

Jon

[quote=Jon]

Hi Tom:

Jon

[/quote]

Hi Jon,

you may know a good bit of this, but I not sure how much so:

1) I'll avoid using the word "clone", as, by definition, it means an identical but seperate copy (I'm not sure exactly what it means in UR). This (creating a new item exactly the same as the copied item - but with new ID number, i.e. is a new item) can also be done in IQ using copy and paste. As that's something, different I'll leave it there for the moment...

2) A "Link" in IQ "does not create new items, it simply adds new parent links" (as the paste dialogue says). So, you are simply showing the original item in a new location.

3) In IQ there is no overall parent for a grid (unless you set up a hierarchy like this - I have a couple of grids like this).

If you e.g. tick the inbox field for an item - it will now show inthe inbox grid. That's the basis of IQ's grids (at it's simplist)

4) To give a top-level item a parent ('Link' as in #2 above) I personally use Ctrl+Drag (in dual-pane setup).

The item still shows in original grid as expected - at top-level
It also shows in the other pane/grid as a sub-item

this is correct (and logical) behaviour.

This can also be done using copy/paste "Paste under the current parent as Links to existing items"

[quote=Tom]

4) To give a top-level item a parent ('Link' as in #2 above) I personally use Ctrl+Drag (in dual-pane setup).

The item still shows in original grid as expected - at top-level
It also shows in the other pane/grid as a sub-item

this is correct (and logical) behaviour.

This can also be done using copy/paste "Paste under the current parent as Links to existing items"

[/quote]

Hi Tom:

Yes, I know all of what you said except for certain details in the above quote. You describe exactly what I was doing in my original post, but it does not work. I was thinking that perhaps I was incorrect in assuming that this can be done with a TLI. In other words, that it can only be done with an item that already has a parent. If this is the case, I don't like this limitation. However, you are describing what I was trying to do, what I think should be able to be done, but it absolutely does not work here. What you are describing is the behavior I am looking for, but cannot achieve.

Jon

Hi Jon,

A little video showing the issue would be great. Jing works great, but there are others. (be sure to include the whole IQ window with toolbars and source bar showing.

Thanks !

[quote=Jon]

[quote=Tom]

4) To give a top-level item a parent ('Link' as in #2 above) I personally use Ctrl+Drag (in dual-pane setup).

The item still shows in original grid as expected - at top-level
It also shows in the other pane/grid as a sub-item

this is correct (and logical) behaviour.

This can also be done using copy/paste "Paste under the current parent as Links to existing items"

[/quote]

Hi Tom:

[/quote]

I'm still confused Jon - cause you say in a post above that you did acheive this "However, I am trying to link items to another grid, but after refreshing the grids, the items show in both" which seems to me to be what I describe above. Yet, you say you cannot achieve what I describe in quote in this post.

Can you clarify exactly what it is that is not working for you, and exactly how it is not working? (which methods/steps taken).

thanks, Tom

[quoting is gone wonky]

[quote=Tom]I'm still confused Jon - cause you say in a post above that you did acheive this "However, I am trying to link items to another grid, but after refreshing the grids, the items show in both" which seems to me to be what I describe above. Yet, you say you cannot achieve what I describe, as in quote in this post above.

Can you clarify exactly what it is that is not working for you, and exactly how it is not working? (which methods/steps taken).

thanks, Tom

[/quote]

Sorry, thought I was clear. Here is what I said. I think the underlined text clarifies, but if not, let me know.

"However, I am trying to link items to another grid, but after refreshing the grids, the items show in both. Now if moved, I would expect to see their occurrence in only one of the grids. What I see is the destination grid displays the items under their new parent. The grid of origin displays the items too, but the new parent appears as a context parent. Properties indicates one parent."

[quote=Jon]

Sorry, thought I was clear. Here is what I said. I think the underlined text clarifies, but if not, let me know.

[/quote]

Steps would really have been more helpful, but let me try and deduce exactly what is happening:

You Ctrl+Drag (or equivalent via copy/paste) a TLI to a second grid where you "make" it a sub-item

It shows in the destination grid under a new parent

It also shows in it's original position in it's original grid

In the original grid the new parent shows as context parent (i.e. context parents is turned on under grid)

You say "if moved, I would expect to see their occurrence in only one of the grids" - you have not moved the item - you have linked it. This makes me think there might be some misunderstanding of terms here - you talk about linking and then moving -two different things! I dont know why you mix the two and it makes what you say confusing...

The behaviour you underline in the quote is the same as I describe - it is expected bahaviour when you "Link" items/create a new parent.

what do you find incorrect (or odd) there?
what's the difference between my description and yours (I can see there are minor differences in details described, but which one is the problem for you?)
What do you expect to happen in this situation?

[edit] Jon, I suspect this is related to having particular concepts from UR - and IQ being different. Please check the terms you are using and check the definitions closely in my post above, thanks :-) [/edit]

[quote=Tom]

The behaviour you underline in the quote is the same as I describe - it is expected bahaviour when you "Link" items/create a new parent.

what do you find incorrect (or odd) there?
what's the difference between my description and yours (I can see there are minor differences in details described, but which one is the problem for you?)
What do you expect to happen in this situation?

[/quote]

Yes, there might be some carry-over from UR, but in my opinion, UR makes more sense in this regard.

I completely understand the difference between move and link. What I don't anticipate as correct behavior is seeing the now linked item with its context parent in the original grid. That really messes up the meaning of multiple parents for me. In UR I can see the multiple parents displayed in a separate panel. IQ accomplishes this in the properties pane. While I now understand why the TLI which is now linked as a child in another grid shows up as having only one parent, I don't understand why the TLI should be displayed as a child in its original grid (I understand the concept of context parents as I use Ecco quite a lot). With the case of the TLI in its original grid, I think it should continue to be displayed as it was - as a TLI.

I have far less experience with linking in IQ than you, but allow me this perhaps stupid question. I have not tried this, but if my TLI is now being displayed under a context parent in its original grid, what happens when there are many parents? How would they be displayed under the same conditions?

Jon

now we're getting places

It was (and is) interesting to hear how other apps do these things. The concept of IQ is relatively easy (well now I understand it) but it can be problematical that there are so many options, implementation could pften be improved, and (with apologies) wording of dialogues.

I came from using a very simple PIM to IQ so while I found it difficult, I at least didnt have habits/concepts related to other software...

Context parents can be truned on or off via the menu: Grid >Context Parents

This should probably be off by default (must check in sample db). If it's off you wont have the confusion of the new parent being displayed.

If an item has multiple parents, one of these will be the main parent. It will be displayed in bold in the properties pane.

Right-click any parent there to make it main parent or remove parent link

Click any parent there to open it in the Scratch grid

[quote=Jon]I have not tried this, but if my TLI is now being displayed under a context parent in its original grid, what happens when there are many parents? How would they be displayed under the same conditions?[/quote]

no - a good question!

The main parent will be displayed as the context parent - the only way to know if there are other parents is by looking in the properties pane

Have a good weekend!

Tom

[quote=Tom]

no - a good question!

The main parent will be displayed as the context parent - the only way to know if there are other parents is by looking in the properties pane

Have a good weekend!

Tom

[/quote]

The original item has no main parent, therefore I think the display is incorrect. I also think the display of items with multiple parents in context is problematic. The context differs from grid to grid and link to link. However, upon filtering a grid I agree that context parents are appropriate.

I've got a headache... I'm sure I'm giving Pierre one too.

Jon

Hi Jon, If an item has one or many parent(S), at least one parent has to be a context parent (bolded in the properties pane). If it's not the case (no parent is bolded in the properties pane), then maybe there's one more bug with main parents. They were supposed to be fixed in this release. >I also think the display of items with multiple parents in context is problematic. You're right. But it's the simplest implementation if you want to know which parent was the first and main linked parent to the currently focused item. ========= Slightly off topic : I guess that if Pierre pushes forward the idea of "home grids" for items (meaning : a field where the primary context is defined), then the idea of contextual parents could become more sophisticated as it would still be possible to figure out where (in which context) an item or a hierarchy originated (that kind of sophistication might come to the expense of usability though.) - Context parents would be grid dependent. E.g. : for each grid, users could decide if an item has a different "main" parent, or, more simply, context parent would always show the parent which is normally shown in the current grid. - main parents could be changed "in batch" and easily. But that's seems like a pretty complicated system for a user to manage and maintain... And maybe for the software too. Are there other ways to achieve that ? AFAICT, the current filter implementation wouldn't allow IQ to esily "guess" which parents you would like it to present as a context parent in a specific context. BUT : it might be possible that with the changes Pierre wants to make to the filtering system, that context parents could relatively simply become grid specific. I don't know.