Tinderbox Forum

Changing the default color and/or style of a text link?

Hi

I am finding myself using quicklinks more and more when I write but am noticing it is making my maps more confusing to me. I want to easily differentiate at a glance on my map which links are basic links I have created in map view vs the text links I have created while writing and relating notes during this phase. I realize I can modify each basic link attribute I make as I go, but am curious if there is an attribute I can simply change in my document to easily and automatically initially change the color and/or style of the basic link that I use when I am linking documents in map view.

This would instantly allow me to differentiate visually between the notes I have created on my map: basic vs text link automatically.

Thanks in advance
Tom

I run into this situation pretty regularly. My approach is to create a new link type that I call “navigation” that I use as the link type for in-text links. In the inspector I uncheck the box next to “visible” which means that no links typed as navigation will show in maps. There are other options (color, style, etc.) that might work better for your situation.

I don’t know a way to make basic links automatically default to one type and in-text links default to another, but link creation remembers the previous link type selected. Since I often make certain types of link in batches based on what I’m doing—basic links when I’m doing big-picture stuff, in-text when I’m in the details—I only have to change the type selection occasionally as I shift what I’m doing.

Not a perfect system, but it usually works for me.

Thanks Brian. I did not know about making these links not visible. Question: In my fresh tinderbox note, in spite of changing a link (text or basic: I tried both) it seems to default back to the *untitled default.

What is your process for allowing the link to remember the previous link type?

Thanks in advance

Each time I enter a text link then go to map view and change it to navigation, the next text link remains an untitled, however, when I change the basic link to a new link type it remains the same link type as before.

I would think, making the text link “not visible” would be the most useful.

Thoughts

On my end, if I want to change the type of an existing link, I click the “I” button that is attached to the link and visible when I select the source note. I change the type in the dropdown menu, click away, and it the link type is now changed. For existing links, I don’t know if there is an agent or stamp that can make a bulk change. I always have to make these changes one-by-one.

For a new basic link and for new in-text links created using the link creation widget (see pic) then TBX will autoselect the previously used link type in the link creation pop-ups dropdown menu. This doesn’t work in the current release when creating in-text links using “[[” and then typing a note name. In this case, TBX seems to assign no link type at all (even *untitled) unless a type is manually selected in the pop-up. I think this is not the intended behavior and have reported it as a bug. So for now, if you want to style in-text links, I think it’d be easier to create them using the widget.

44

When I make a basic link, I get this following pop-up:

On my end, selecting a link type and clicking “create link” sets the link to the type shown in the dropdown menu. If that’s not happening for you, then something odd is going on.

Thanks Brian,

My default behavior is to use the quick links method “[[” which as you report does NOT work but if I use the Text Link Button in green, it does keep the last used type.

Thanks for pointing this out. I was hoping the quick link method had an attribute or followed the last link type. Hopefully this is on the roadmap for bug fixes as I agree it does not seem to follow the expected behavior.

Tom

1 Like

Brian,

Thanks for your help. I “discovered” (thanks to you) the ability to customize each link type which I previously did not utilize. I noticed that the text links use the blank selection just before untitled which I found by accident. Since this is the default link used by text links, I made this one invisible.

With my basic links, happily it does use the last one used which makes it easy to keep these more important (in my case) links visible.

Tom

1 Like

Could you describe where you’ve found this or perhaps post an image? I can’t find it and would like to.

Hi Brian

I found it quite by accident. I reproduced in a new document as well. What you need to do is to create a new link that is: not visible and not labeled. The key is that the name should be left blank. What I like about it is that it allows me to create invisible text links. Even better, if I then check the visibility box I create a light gray which allows me to easily see and differentiate these text links but in a nice light gray.

Here are the screenshots

Unfortunately, I can’t upload the video. It is saying I am not authorized.

Tom

1 Like

Here is what my system link palette looks like:

1 Like

I can reproduce @TomD’s method to create a nil link.

I suspect that’s a bug.

As my document grows, the ability to visually separate basic links vs text links helps me better understand why and when I created these links. I am a big fan of the zettelkasten method and I like to relate one note from another while writing the text of my notes. I do this rather spontaneously…answering the simple question: how does this note relate to any other note.

In contrast, in my workflow while in map view, I am trying to view my notes more holistically: what concepts are emerging, are there any themes etc. Having the ability to easily control the visibility and contrast text vs basic are a welcome addition in my toolkit. I agree with PaulWalters, this is probably a bug, but hopefully will either be left alone or incorporated into the palette option for user control. Fingers crossed.

Here is the map with the light gray text link and a basic link in black. You can see the nice contrast and most importantly…with minimal effort or interruption of my workflow.

Tom

The likely bug here is the existence of a blank or unnamed link style because this “style” can’t be accessed or assigned outside of the inspector. All of the link styling features you are now using are working as advertised.

I make the distinction just because if the bug is fixed, then I’m not sure what happens to the links you are currently naming “blank” or nil. Will they simply revert to *untitled and take on the styling of that type? Given the uncertainty, it might be worth considering doing your work using a named style that will behave predictably going forward. Setting that style manually makes [[-links slightly more difficult to construct but might set them on a more solid ground for future updates.

I’m not completely sure the “bug” should be eradicated, and @bcrane makes a good argument against unintended consequences — both from using the nil feature, and from eliminating it.

Hi Brian,
I agree this is a workaround and experimental at that however the bug itself is something different. I propose that the bug itself is that the text link style does NOT retain the link style assigned under the system properties… Take a look. In the first screen shot I have initially assigned the color green to *untitled however the text links remain a solid black.

Next, if you go into the info box of the text link line, it clearly uses the *untitled style but does not retain the green color until it is manually changed. Once it is changed manually that single line is changed color then the color behavior reverts to black.

So in summary: [the BUG] the current text link prototype that text link uses cannot be customized by the user in the document link properties window in a consistent manner as one would expect. The only current workaround for this bug right now it to create a nil link. This does work but as you point out, it is not perfect and cannot be assigned hence not perfect.
Currently, If one tries to create a new default text link, you will need to manually change each link by hand which adds lots of additional work. I have reported this bug to Eastgate in hopes it will be on the roadmap. . Fingers crossed.

Cheers and thanks again
Tom

I agree, currently it is definitely in the “use at your own risk” and experimental category but I think the “nil” should be left alone. The focus should be in correcting the "*untitled link " text link prototype/style bug: 1. allow customization of styles and visibility when set to apply to text styles or be able to choose a default style for text links and currect the inconsistent behavior between the document/link setting and link infobox.

Tom

1 Like

I agree it’s not clear what to do. Simply regularizing the treatment of the nil-type across the menus may be enough of a fix. My question would be: can link types can be queried or targeted with action? If so, would the inclusion of a nil-type make a set of links in a document unnamable in queries and actions?

Since this thread has been flagged as a discussion of the bug backstage, I’ll take the chance to say that in the screenshots above it looks like the *untitled type hasn’t actually been applied to the link because it doesn’t show in the two places the applied type is normally identified in the Browse Links pop-up. The dropdown seems to be showing *untitled simply because there is no blank option in the menu (unlike in the inspector). Once *untitled is manually selected, the type will show correctly in the box above the dropdown menu and to the right of the link list in the right hand box.

Hi Brian

Personally, in my workflow, I only target basic links not text links so for me, querying text links is not the main issue.

The lack of visibility between visually differentiating between my text links and basic links are important for me to differentiate and see. If they blend in together with the same color (black) they blend in together and are quite confusing me. Not only that, since I am now using text links for relating one note to another, there are A LOT more of them and therefore add unneeded complexity in my maps.

From a link perspective, I use text links to minimally relate 1 note to another to create a thread and a reminder of what I was thinking at the time I was writing my note (much like a breadcrumb) and us basic links for a much different purpose. The basic notes are for an overall holistic view to view concepts and themes, therefore, I am only and primarily interested in querying basic links. This workflow is of course the way I work and therefore only my perspective.

I am certain others like you would like to query all links including text links. For this, you are correct, it might be harder to query text links if you use the “nil” link type. I am including a sample file I have been using to play around with and experiment.

Q: I have not done this but have you tried to build a link query using the “nil link” by querying: “TextLinkCount” & using link type " " (nil)
Not sure if this would work but worth a try if using “nil link types” and want to query text links.

Anyway, this discussion has been awesome for me. It has made my maps much more readable and useful to me.

Thanks for your assistance. It was your initial suggestion and request to post my findings that helped me further refine my workflow.

Tom

here is the sample file.

Nil Link Example.tbx (87.7 KB)

1 Like

Why not assign the basic links you create in map view to a specific link type — say “manual” — and let Quicklinks retain their default type?