sakethpathike
Ability to add tags
if possible please add a feature where we can attach tags to link and search and sort via tags . this would make sorting and searhing very easy if there is a large no. of links
Linkora has folders that already organize links, and you can sort and search through them as needed. Adding tags wouldn't make much sense with folders in place 🤔. Searching within folders will be added in upcoming releases.
So are you saying a link can be in multiple folders at the same time?
Tagging really is much better than folders. But I do use both with Raindrop at least, it does make perfect sense.
Folders are great, Panels are awesome, Tags are amazing, if/when considered/implemented.
I personally believe that, with these three, Linkora would become absolutely the most powerful app for organizing links ever.
It's very similar to Notes, Linkora already has but reducing the pain point to keep repeating the input or having to remember the notes used previously.
Just my two cents.
Thanks.
@AtmanActive the thing is i'm not really a big fan of tags in the pocket app, so they never really made sense to me 😭 👍🏻
reopening this issue :)
It all depends on how big of a data set we are dealing with.
To organize 5 records, not even folders are needed. To organize ~100 records folders are sufficient. To organize ~1000 records folders + panels would do. More than that, and you definitely need tags as well.
Linkora is actually very close to having tags. Notes are like tags. The only real difference boils down to:
- whenever a space character is typed in, treat it as a new tag and save it in a separate table referenced by an index number
- save tags as an array of index numbers instead of a simple string Done.
Later on you can have search by tags, view by tags and so on.
Home Assistant recently added tags (called labels there). CloudFlare has tags for DNS records management.
As Linkora is growing to become a whole solution (now having both mobile and desktop and sync-server), the addition of tags would make it top-notch.
If folders stored pointers to links (rather than copies of links) wouldnt this achieve the same thing as a nested tag heirarchy?
Currently if I only have two directories A and B and both have wikipedia, then in "All Links" section wikipedia shows up twice. because A and B both have their own copies of wikipedia.
If both stored pointers, then in "All Links" we would only see wikipedia once
@linky3754
If folders stored pointers to links
It should be the other way; a link can be duplicated if necessary, and a link should contain information about its connection to a folder. A folder is only supposed to exist on its own in the database.
Currently if I only have two directories A and B and both have wikipedia, then in "All Links" section wikipedia shows up twice. because A and B both have their own copies of Wikipedia.
This is expected behaviour, an option to not show duplicates may be implemented in future releases, but each folder is supposed to have its content, even if it means to be duplicating.
If both stored pointers, then in "All Links" we would only see wikipedia once
It's not about the number of times it's shown in "All Links" but how a link is connected to a folder. I get your point, but from a design perspective, this leads to a mess.
Let us say I have the same link in directories A and B. According to your implementation and current data handling mechanism of Linkora, deleting from one folder will delete it from both of them, because there's only one link (instead of having a respective copy for each folder) to which these folders are referring.
Even if I changed the schema as per your implementation, it would pop up other issues:
Deleting/Editing/refreshing/archiving/copying/moving from links of one folder will directly have an impact on all other folders when doing any of these operations, the app SHOULD check in ALL folders to know if the linked link exists or not and then take the necessary step (which again raises complexity and computation issue, it's fine if u have 20 folders, what if you have 2000, this leads to unnecessary complexity), what if u don't want to change the name globally but to certain folder?? That's what the current approach helps us with, coupling to a specific folder means it affects that folder itself and not the entire hierarchy.
The idea of linking links from a folder itself also leads to complex handling when it could be done simply, as Linkora does now.
User should not need to use folders at all if they choose to only use tagging.
To me, that should mean tags are technically implemented completely independently of folders.
IMO there does not need to be a separate "tags" field in the UI for data entry. Even if there is, assuming there is a "description" and/or "notes" field for a bookmark record, the #tags could just be entered inline there and get parsed on save.
@hansbkk
User should not need to use folders at all if they choose to only use tagging.
That goes against the working of Linkora, this idea of Linkora is to be folder driven, but as I plan to include tags in v0.15.0 (the next release is v0.14.0 but I also need to work on the server for the tags, so v0.15.0 will have this) and yes tags will be independent of folders, they'll represent the global hierarchy instead of nested like folders currently do.
the #tags could just be entered inline there and get parsed on save.
I'll add this and will include a row or separate component to directly select from existing tags.
Also, this is technically possible even with the current version; notes can be used as tags, as search supports reading from notes too.
tags will be independent of folders, they'll represent the global hierarchy
There should be nothing hierarchical about tags, no relationship between them, except maybe the tag picker surfacing "others commonly associated" top of the list relative to the last one selected.
User should not need to use folders at all if they choose to only use tagging.
That goes against the working of Linkora, this idea of Linkora is to be folder driven
IMO that should be a user decision. Are you saying even after v15 users will be forced to use folders?
I reco trying Raindrop as an example of leaving it up to the user.
@hansbkk
There should be nothing hierarchical about tags
There will be nothing hierarchical about tags. The tags will be flat. What I meant is that tags can't be nested but can be assigned to any link in any folder (i.e., tags stay at the global level (conceptually), without any children — or flat — which is basically what you're referring to, and that's what I'm saying too) if one prefers.
Are you saying even after v15 users will be forced to use folders?
I don't think I said that :)
The collection screen will have a horizontal pager that includes tags and folders, similar to the panels on the home screen or something better. I'll see about it when I start working on it, but nothing will be forced :)
leaving it up to the user
That's exactly what's going to happen.
@sakethpathike So I think Firefox uses the following schema for places.sqlite :
https://wiki.mozilla.org/images/d/d5/Places.sqlite.schema3.pdf
-
moz_places: stores information about each bookmarked URL, including:
- id: unique identifier
- url: the URL itself
- title: title of the bookmark
- visit_count: number of times the URL has been visited
-
moz_bookmarks: stores information about bookmarks and folders, including:
- id: unique identifier
- type: type of entry (bookmark or folder)
- fk: foreign key referencing the id in moz_places (for bookmarks)
- parent: parent folder ID
- title: title of the bookmark or folder
We can see that folders (which appear in moz_bookmarks) in a rough sense have pointers (fk) to urls/hyperlinks (which are stored in moz_bookmarks)
How exactly is it done in Linkora, and which file contains this schema? Thanks
[EDIT] : p.s. the linkora implementation (which is different from above) works very well. Infact to import bookmarks from a html file I find that Linkora on my mobile is faster than Firefox/Chrome on the desktop. Not sure if this is due to the design implementation or whether it is due to other factors.
@linky3754
We can see that folders (which appear in moz_bookmarks) in a rough sense have pointers (fk) to urls/hyperlinks (which are stored in moz_bookmarks)
Yeah, they do get the favicon (moz_favicons), the URL itself and also the fallback title (I'm pretty sure this title is a meta title or <title> from the HTML of a page because that's what Firefox shows by default when bookmarking) from moz_places.title.
How exactly is it done in Linkora
Linkora stores folders and links in separate tables, but it seems Firefox stores both of them as bookmarks in moz_bookmarks, and the differentiation is probably done based on the foreign key (moz_bookmarks.fk), if fk refers to null, it is a folder; if it does refer to something in moz_places then it's a link.
Besides the foreign key, there are moz_bookmarks.folder_type and moz_bookmarks.type (which you have already mentioned); these can also be a differentiating factor. If these refer to null (moz_bookmarks.folder_type = null ) and link (moz_bookmarks.type = link/url/regular_bookmark) then it's a link/regular bookmark; if not, it's a folder.
So there are a couple of things on how Firefox might differentiate all this by using a single table itself. Whereas Linkora uses two different tables.
and which file contains this schema
Link: https://github.com/LinkoraApp/Linkora/blob/master/composeApp/src/commonMain/kotlin/com/sakethh/linkora/domain/model/link/Link.kt
Folder: https://github.com/LinkoraApp/Linkora/blob/master/composeApp/src/commonMain/kotlin/com/sakethh/linkora/domain/model/Folder.kt
@sakethpathike Thanks for this information I will take a look.
p.s. There are somethings that the Firefox team are trying to change with respect to their schema. For example the following quite old ticket in ongoing work :
tags should not be bookmarks folders, move them to a separate table
Raindrop gives both a Notes field, and a Description one. I sometimes paste other URLs in Notes if they are the exact same cluster of topics/tags. There is a Subtitle field, which along with Title do get auto-populated, but often (esp TikTok) the subtitle contains better text and I'll cut/paste before saving
I want to, but I'm almost not having time to implement it.
Same with reminders, it's almost done. It's been since the last couple of weeks (or probably months), the branch still exists, which was supposed to be merged earlier.
And I have some good news 🤠
(currently in development)
Thanks !!!!! ❤️❤️🤩🤩
released a new preview which adds tags support, will release a new general release soon
https://github.com/LinkoraApp/Linkora/releases/tag/preview-v0.14.0
setup of what?
please create a new issue, we'll keep this issue limited to tags only :)
well finally:
https://github.com/LinkoraApp/Linkora/releases/tag/release-v0.14.0