You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Remember the sort order of lists across sessions #507
Maybe the sort order of lists can be saved and reapplied at the next restart, fort both overview and inspect tabs.
Is your feature request related to a problem?
Every time I start the app, I should reset the sort order. Maybe this is not relevant for users that prefer the default state, but it's quite annoying for others that prefer a different order.
Maybe they could be saved to the config file on shutdown and reloaded at startup.
This is not a big issue, but the usability could be improved after adding this feature.
Anyway, I didn't say it before, but thanks for this application, it's very helpful. There are other tools on Linux that does quite the same thing, but at least sniffnet is more user friendly.
Adding this is extremely trivial since Sniffnet already uses a config file for the parameters included in the settings.
My only concern is whether it's actually meaningful or not.
I'm not sure this kind of stuff is usually saved into configs, and maybe it could be non-intuitive for some users.
I can think of a case where a user changes the sort order just out of curiosity and then reopens the app expecting to see most recent data without noticing that the sort order is still that set last time.
I feel seeing most recent data is what majority of the people are interested in.
Why do you prefer a different sorting strategy? Maybe getting your point of view can help.
Anyway, I didn't say it before, but thanks for this application, it's very helpful. There are other tools on Linux that does quite the same thing, but at least sniffnet is more user friendly.
Thanks so much 🙏
I'm also thankful to you for all the opened issues, they are indeed useful for me / the project.
My only concern is whether it's actually meaningful or not. I'm not sure this kind of stuff is usually saved into configs, and maybe it could be non-intuitive for some users. I can think of a case where a user changes the sort order just out of curiosity and then reopens the app expecting to see most recent data without noticing that the sort order is still that set last time.
I feel seeing most recent data is what majority of the people are interested in. Why do you prefer a different sorting strategy? Maybe getting your point of view can help.
To see which connection is using more data. I think the user expects to see the sort order they set previously. In example, if I set a specific order in Thunderbird to get mails sorted in the way I want, at the next startup the order does not change.
After more carefully evaluating this request I've come to the conclusion that I prefer leaving things as they're now.
Despite adding this configuration is straightforward, the running pages of the app (Overview, Inspect, Notifications) are stateless by design: the idea is that when a new capture is restarted, it begins from a completely clean state.
Adding states for the sort orders would make this more ambiguous, since other parameters'd be reset anyway:
data representation unit
favorite hosts
search filters in Inspect page
notifications list
The parameters with a state are included in the settings of the app, and none of them is relative to the analysis itself (except for the MMDB files, but they are more time consuming to select than a simple click on the sort arrows, and they are not directly visible in the running pages).
I'm reopening this since I realised that saving favourites across different runs of the app is something that'd be really useful, and this issue came back to my mind.
So my previous statement wouldn't be a problem any longer:
Adding states for the sort orders would make this more ambiguous, since other parameters'd be reset anyway:
data representation unit
favorite hosts
In fact, I now plan to have more parameters saved into the app persisted configuration.
Obviously this doesn't apply to parameters that don't make sense to persist, such as:
Activity
GyulyVGC commentedon Apr 14, 2024
Adding this is extremely trivial since Sniffnet already uses a config file for the parameters included in the settings.
My only concern is whether it's actually meaningful or not.
I'm not sure this kind of stuff is usually saved into configs, and maybe it could be non-intuitive for some users.
I can think of a case where a user changes the sort order just out of curiosity and then reopens the app expecting to see most recent data without noticing that the sort order is still that set last time.
I feel seeing most recent data is what majority of the people are interested in.
Why do you prefer a different sorting strategy? Maybe getting your point of view can help.
Thanks so much 🙏
I'm also thankful to you for all the opened issues, they are indeed useful for me / the project.
Digitalone1 commentedon Apr 14, 2024
To see which connection is using more data. I think the user expects to see the sort order they set previously. In example, if I set a specific order in Thunderbird to get mails sorted in the way I want, at the next startup the order does not change.
GyulyVGC commentedon Apr 21, 2024
After more carefully evaluating this request I've come to the conclusion that I prefer leaving things as they're now.
Despite adding this configuration is straightforward, the running pages of the app (Overview, Inspect, Notifications) are stateless by design: the idea is that when a new capture is restarted, it begins from a completely clean state.
Adding states for the sort orders would make this more ambiguous, since other parameters'd be reset anyway:
The parameters with a state are included in the settings of the app, and none of them is relative to the analysis itself (except for the MMDB files, but they are more time consuming to select than a simple click on the sort arrows, and they are not directly visible in the running pages).
GyulyVGC commentedon Jun 8, 2025
I'm reopening this since I realised that saving favourites across different runs of the app is something that'd be really useful, and this issue came back to my mind.
So my previous statement wouldn't be a problem any longer:
In fact, I now plan to have more parameters saved into the app persisted configuration.
Obviously this doesn't apply to parameters that don't make sense to persist, such as: