How to move alias around / how to remove them?


(Rene Trappel) #1

I have an agent that queries for every note with the $Status “active”. The alias this agent creates are then moved to “/” in order that I can see & work with them.

Here is query:

$Status==“active” & DesktopAlias==false

and the agents action:

$Container="/"; $DesktopAlias=true;

This works fine (I need $DesktopAlias to avoid multiple copies). The problem starts when I’m done with a note and want to remove the alias. Is there a way to delete an alias? I also tried moving them to an archive, but this did not work either.

The query finds the correct alias

$Status!=“active” & $DesktopAlias==true & $IsAlias

But the action just creates another alias in the /archive

$EndDate=“today”; $Container="/archive";$DesktopAlias=false;

Any idea how I could remove the remaining alias at “/”? Thanks!


(Mark Anderson) #2

An agent create a new alias for each note matching the query. If you move an alias out of the agent, if the note still matches the query, it simply creates a fresh new alias.

The trick is to ensure the agent action does something extra to ensure the ‘moved’ alias’ original note no longer matches the agent query.


(James Fallows) #3

Following up on what @mwra says – yes, the system will keep repopulating the aliases, as long as they meet the test.

So for this situation…

… the basic goal would be to express “when I’m done with a note” with an attribute.

For instance, you could create a Boolean attribute called (something like) $DoneWithThisNote, set to false by default. When you’ve finished with a note, you could click that attribute from false to true. And you could set up your main query to be:

$Status=="active" & $DesktopAlias==false & $DoneWithThisNote==false  

Then clicking that attribute will keep the agent from matching “done” items any more, and the alias will no longer show up in “/”.

The experts will correct me if I’m wrong, but I think this is the main idea: find a way to mark items that you’re finished with, and add that marker to the agent that is populating the container.


(Rene Trappel) #4

Thanks - this is what I use the boolean $DesktopAlias for. After the query matched, $DesktopAlias is set true and the Alias is moved to “/”. The query is matched only one time.

Regrettably this does not appear to work either.

I’ve attached a sample file. In it “task 1” is done (by setting the $Status to “done”). The agent “remove non-active alias from desktop” has correctly changed $EndDate and $DesktopAlias. It also created a new alias in /Archive instead of moving the one at “/” to /Archive (this is what I want).

remove alias problem.tbx (63.6 KB)


(Mark Anderson) #5

Thanks, the demo makes it much easier to see what you’re up to. The problem arises because you’re trying to use he agent action to move an alias that isn’t the alias within the agent. How to reference that specific alias. We can’t use designators. ‘original’ would act on the original note not the alias, and ‘this’ or ‘current’ would act on the alias in the agent.

So, this is one of those rare occasions where we need to specify the full path of the target item as a left-side offset:

$EndDate="today"; $Container("/"+$Name)="/Archive";$DesktopAlias=false;

More precisely, this

$Container="/Archive";

becomes

$Container("/"+$Name)="/Archive";

This tells Tinderbox that the object at path given at the left side is to be moved to a new container. Note we need to give the full path and not just the note title. This is because at this point there are at least 3 objects of the same title: the original note, the alias at root and the alias in the agent doing the above work. We need to explicitly target the second of those three items.

So this fixes your problem, but it also suggests it is perhaps not the best way to use aliases. Bear in mind:

  • Agents resolve all matches to one item, i.e. it de-duplicates originals & aliases if both match and the item is aliases in the agent only one.
  • Action code cannot create or delete aliases, but moving an alias out of an agent may appear to create a new alias as the moved alias is created within the agent.

I hope that helps… :grinning:


(James Fallows) #6

Thanks to @mwra for the authoritative answer; thanks to @laotang for the interesting question.

Further on this…

[quote=“mwra, post:5, topic:1067”]
So this fixes your problem, but it also suggests it is perhaps not the bast way to use aliases.[/quote]

Your set-up, and question, rest on the idea of the aliases being more or less permanent things, akin to the original note itself. A mental TB leap for me was realizing that, when it comes to aliases created by agents, it was worth thinking of them as highly transient, disposable-and-recreateable bits of ephemera. You can always make more of them, by any criteria you want, with a new agent or rule.

Why does this matter? Because it might highly streamline what you’re doing. Your query is based on working with an alias, and later moving that specific alias to the Archive container. But you don’t have to be that precise. All that matters is having an alias of your original item show up in the archive.

This suggests, in turn, a simpler way to set up the agent structure. You would just need:

  1. An agent to find items you want to move into your active work zone-- and then remove aliases from that active work zone once you mark them as finished. (So the query would include $DoneWithThisItem==false to bring items in. When you changed that to true, the alias would disappear from this area.)

  2. Another agent to populate your Archive container with items that are finished. The query for this would include $DoneWithThisNote==true.
    The conceptual difference here is that you are not moving the alias. You’re creating one when you want to work on it; you’re making that one disappear when you’ve completed the item; and you’re creating a new alias to store in Archives. The system doesn’t know whether the original alias has been “moved” or whether a new one has been created there, but for your programming purposes it’s a lot easier, I think.


(Rene Trappel) #7

Thanks a lot for this, I learned something today! It now works as intended, but I understand that it might not be the most reliable long-term solution.


(Rene Trappel) #8

Thanks @JFallows for developing this model further!

This is what I originally intended. The idea to move them into an archive was only a workaround, because I could not make these alias disappear. It appears that when you move an alias from its original agent they become detached from it (they turn into Zombi-alias, if you will).

To my understanding your solution would only work if I would deal with alias directly in the agent (by perhaps placing an agent at “/”). Right now I’m thinking that perhaps the Attribute Browser or Outline view might be a better way to deal with this.

Still, I appreciate the input! This forum is really one of the nice corners of the internet.


(James Fallows) #9

My default approach to almost anything in Tinderbox is: try the Attribute Browser first. For my style of thinking and working, it’s usually the clearest and most effective way to see what I want to see, arrayed how I want to see it.


(Rene Trappel) #10

The Attribute Browser is really a great tool. The only limitation is that there is (almost) no way to move from one of the items listed there to a Map view of the same item (no right-click > Open in New Tab; right now I use a workaround mentioned here: From Attribute Browser to Map View?).

The model outlined in this thread would allow me to directly go to the Map view of a project, that was one of the reasons to go this route.


(Pat Maddox) #11

I find this very useful. I can use an agent to find things, and drag them into different areas and the agent gives me a new alias.

That said, the inside test works on aliases. So you can add something like & !inside("/Archive") to your agent and it will hide any notes that have an alias that is a direct child of /Archive. I don’t believe that descendedFrom works the same way, however.


(Mark Anderson) #12

Correct. The discrepancy goes back to solving a particular problem in the early days of Tinderbox. inside() generally works as expected until you hit the point where it doesn’t and sadly there’s no built-in alias-ignoring equivalent of inside() although there is an existing feature request that there be one.


(eastgate) #13

If you want to know whether a note is inside a container, and ignore aliases inside that container:

query: inside(/path/to/container) & (!$IsAlias)