Conversation
Notices
-
Embed this notice
@grunfink@comam.es thank you for snac, I've just set up my own instance with it, and I'm loving it
there are a couple of features from GNU social that I'm missing, and that I'd like to implement, namely:
* some means to open a thread or a post from my timeline in a new browser tab, so that I can interact with it later, or keep up with a conversation without having to search for it in the timeline again. I'm thinking of turning the "date / udate" field into a link to it/them, though ATM I don't quite see what to link to. I suppose a search might work to find a single post, but there's no existing way to link to a local view of a thread AFAICT. any objections to adding these?
it would be nice if I could like/boost/mute/etc without reloading the page, let alone be taken to the first timeline page. I'd like to be able to middle-click on these buttons so that they'd take action on another tab, and I could keep on scrolling on the current tab without waiting for it to reload, or bringing new posts, or getting back to the initial timeline page, even if we currently try* to get back to the same spot
* indeed, it would be desirable IMHO for these actions to not always take you back to the admin and timeline page, but rather to the same page you're on, so that, if you're e.g. interacting with a bookmark or a search result or any other way to show a post or a thread, you remain on that page
- I liked the way notifications are marked as seen, and I'd love something like that for the timeline as well. I'm thinking I'd enjoy a view that showed me not the latest posts in the timeline, but the oldest posts more recent than the latest one marked as seen, with a button/link to mark those as seen and show another such page. then I could catch up roughly in order, rather than in reverse order. (this reminds me that diaspora had a nice feature of generating timestamp-based "earlier posts" links, so that there wouldn't be repeats as I paged over posts while new posts came in.
are any of these features something that you definitely wouldn't want to integrate into snac? or does any of these need further details for you to tell?
thanks again!
-
Embed this notice
Hi. You're welcome!
Regarding your first point (saving a thread for later replying or reacting): I use bookmarks for that.
Regarding the page reloading after actions, I'm afraid it's not possible without the use of JavaScript, which is a no/no for this project. The action requires a trip to the server, and a response back with the same (or the most similar) content you were previously shown.
And with regard the mark of "below this line, you've already seen this": it has been on my mind for long time, but due to implementation details, it's trickier than it seems. I will implement it eventually, because it's something that I deeply need 😆
Thanks for taking a chance on #snac.
-
Embed this notice
thanks for your prompt response
I figured bookmarks could be used to that end, but they also cause a separate page to be loaded. and that's fine. the problem IMHO is that there's not an option to open that page on another tab, rather than replace the current one. don't get me wrong, I don't want JavaScript, that's one of the reasons I'm in love with snac. but I know it's possible to send actions to the server by opening links on another tab. I don't know why the action buttons in snac don't work that way. maybe it's a GET/POST thing?
I'm glad we're on the same page WRT wanting/needing the "already seen" marker.
is this a good place to discuss future features? or is there a mailing list or somesuch? I generally like to get agreement on feature designs before setting out to implement them, and I've historically participated in projects that used mailing lists quite heavily, even for patches.
-
Embed this notice
all, right, I have a couple of small patches for #snac that you may be interested in. here's the first one, just rebased onto 2.70.
CC: @grunfink@comam.es
-
Embed this notice
and here's the second patch for #snac that you may be interested in, just rebased onto the first one:
- link to the local copy of a message, from the date, so that one can open it in a separate tab and interact with it without messing with the currently-loaded page
CC: @grunfink@comam.es
-
Embed this notice
now, I'm still trying to work out some user-friendly way to optionally offer some form of "stable" timelines in #snac, namely, if I reload a timeline page (say after a browser restart, reboot, accidental reload, whatever) I get back to the same spot I was, or if I advance to the next page in that timeline whether after minutes or days, I get predictable and repeatable results, rather than something that moves every time it's reloaded
currently, I'm creating dated marker posts only visible to myself, and creating lists of posts by selecting a range of lines from private.idx into say list/20250201.idx, while creating list/20250201.id with "2025-02-01". then I can navigate that list, and keep it for as long as I wish. but that's not very user-friendly. I suppose I could create some interface to create (and delete) such lists over the web.
before finding out about lists, my plan was to enable the use of &latest= (whether md5 or local post's timestamp id), so that I could then start navigating a timeline with a fixed starting (or rather ending) point. it would then start counting skip at that post, rather than at the very latest post in the private timeline.
this could be made more user friendly by enabling the use of one's own posts as reference points for timeline browsing (which would add that post's id as &latest= in a link off of that post), or by offering an alternate current timeline link that created the marker post and used its id as &latest=. these artificial marker posts could be recognized and omitted from the timeline, if that seems desirable.
WDYT?
CC: @grunfink@comam.es
-
Embed this notice
and then, my plans for &latest= in #snac timelines also encompassed &earliest=, that would clip the timeline at that post, even if &show= would otherwise go past that.
this would not only enable me to easily tell where the set of posts that I haven't seen yet ends (which even with perfect memory, that I don't have, isn't very easy as boosts and likes make posts appear again).
having such explicit ranges would also enable us to hide posts that are out of the range. this could enable one to easily identify the parts of a long thread that haven't been seen yet.
I don't have thoughts on how to make the &earliest= marker user-friendly, alas.
it occurs to me that we could maintain a list of marker posts, like bookmarks but separate, so that they could be viewed, deleted, and selected as starting and ending points for timeline viewing.
CC: @grunfink@comam.es
-
Embed this notice
here's an implementation of &latest= and &earliest= taking exclusively md5 codes.
it automatically adds &latest= when one starts paging the private timeline, so that reloading those pages becomes stable (as in, will bring the same posts, even after a while), without depending on any server-side state. &earliest= is only added manually.
CC: @grunfink@comam.es
-
Embed this notice
Thank you very much for your patches, they sound interesting. I'll take a look at them next monday. Have a nice weekend!
-
Embed this notice
I noticed two (hopefully minor) errors in the patches I sent earlier:
- I failed to untabify a couple of added lines in the second patch
- I failed to add the "contributed by" note to RELEASE_NOTES.md in the third patch
if you'd like me to send fixed versions thereof, whether over these minor issues or other ones, just let me know.
I'm open to discussing the design and details of any of them. the third is more of a working prototype than a proper implementation: the packing of so much functionality in a single function is probably unwise, maintenance-wise, but that was what worked, so that's what I shared to get a concrete depiction of the feature across, to get the conversation about it started. I hope the feature makes sense to you.
another nit: I found that the placement of the link to the message in the date is less than ideal. it might be better to place it next to the interaction buttons, where one would look for them after reading the whole message. I find myself occasionally having to page back up to get back to it, which I find less than ideal. the date made sense to me, for not using up more screen real state, and for being "intuitive" for a user coming from GNU social, but I'd be happy to change it. it probably makes sense to add an attribute to have the link opened in a separate tab or page, though; it makes little sense without that IMHO, but I didn't think of it before because I automatically go for the alternate button that will open it in another tab. again, I'd be happy to amend the patch, or post a follow up, just let me know
there's something exciting about using snac to share patches for snac, but I don't suppose it's the most convenient way to share them. if you'd rather get them by other means, I'll probably be happy to oblige; I'm probably going to set up a (plain) anon git server soon (I just haven't got 'round to doing so yet), and I could post only pull requests (in the original sense) here, pointing at branches to pull from in the git server
-
Embed this notice
Hi. I have no short term plan for adding localisation to #snac, but it will eventually happen. Thank you very much!
CC: @lxo@snac.lx.oliva.nom.br
-
Embed this notice
It's incredibly rewarding to witness #FreeSoftware magic unfolding right before our eyes with #snac!
Quick question for the maintainers: Are there any plans to add localization/i18n support in future updates? As a Brazilian Portuguese speaker (as lxo), I'd be happy to contribute translations – I believe this could greatly help expand snac's reach in our region.
Keep up the great work!
CC: @grunfink@comam.es
-
Embed this notice
Hi. Don't worry about the minor errors; I'll fix them.
I still have to take a detailed look at your 3rd patch, as it's longer, but the other two look pretty straightforward. Specifically, regarding the link in the message in the date, it may not be ideal, but it's what Mastodon does (more or less), so I think it's OK as it is.
I have no problem receiving patches via snac, I like it. If fact, it's probably the simpler way for both of us.
I'm a bit busy these days, so sorry about not replying faster.
Alexandre Oliva
The Real Grunfink
daltux
All GNU social JP content and data are available under the