search

GeopJr / Tuba

Browse the Fediverse
https://tuba.geopjr.dev/
GNU General Public License v3.0
571 stars 61 forks source link

[Request]: destroyed window when closed #794

Open camelCaseNick opened 8 months ago

camelCaseNick commented 8 months ago

Describe the request

Tuba's application continues to run when it is configured to run in background. There is no need to keep the UI in memory, however. For that, it would be great if the window was destroyed, finalised, and freed.

Implementation Details

GeopJr commented 8 months ago

Not sure if it should be done... You'd lose the current timeline position and websocket connections (they are tied to timeline widgets).

I'd rather get rid of run in background altogether and replace it with #42. Run in background is only used for notifications, right?

camelCaseNick commented 8 months ago

You'd lose the current timeline position […]

Would be great if it was restored between closes. [So, yet another feature request then, hehe.]

[…] and websocket connections (they are tied to timeline widgets).

i don't think that is a good idea to have. But then refactoring it just for this doesn't sound like fun.

Run in background is only used for notifications, right?

I'm not aware of any other reason to do so. Is there?

replace it with https://github.com/GeopJr/Tuba/issues/42

To be honest, I would really like to see UnifiedPush to take off on Linux, but did not yet understand how it would look exactly. Are there any real world examples of this already?

GeopJr commented 8 months ago

Would be great if it was restored between closes. [So, yet another feature request then, hehe.]

There's an open issue about this. TLDR: The main problem is that timelines are ListBoxes and NOT ListViews. They are memory intense and populating them from the get-go with 100s of posts is not ideal (there have been progress on listviews but that also has its own limitations etc etc etc. Emmanuele's suggestion was to create our own recycler view, which will take some time)

i don't think that is a good idea to have. But then refactoring it just for this doesn't sound like fun.

It's not that big of an issue but something to consider. The workflow is: For every saved user connect to their notifications websocket and then for the current user, it's websocket per timeline (when needed) (they are not exactly tied, but if no timeline listens to a websocket, the websocket closes)

To be honest, I would really like to see UnifiedPush to take off on Linux, but did not yet understand how it would look exactly. Are there any real world examples of this already?

I think some KDE apps do - they have their own library for it. Someone contacted me on fedi some months ago about a glib library for it. I have no plans on supporting the one from unifiedpush themselves as they are not that confident in it "Linux support is still experimental" "NOTE: This library is unstable as long as it's on version 0.x.x" (plus it would introduce go as a tuba dependency :/)