-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature Request]: Import Export Grid items #885
Comments
For now the screen layout will be stored in browser, storing it on server side would require additional api adjustments which are not making that much sense in my opinion. |
In my point of view of share devices, like not only one pc/laptop, also mobile, tablets for me exactly it make sence. Maybe it does not make sence 20 years ago when computer had 1 family at village, but even now if IP address will change, settings is gone, because I guess is 'domain' based. So if you access by VPN to it and IP will change, you are without layyou again. Yes, it would need API and some storage. But yes, simple export/import from some json file and save it somewhere on filesystem would be enough too, because of shared cloud (like nextcloud) storage user can access to it from all devices too. |
Yes, I understand your points. I'm using FreeDATA via (side to side & client to side)-VPN since some years now. The point is, why should the server address change ( and therefore a loose of browser local settings? If we are going to save the settings server side, we also have to implement different user profiles, say we are accessing server "A" from Client "b" and "c", where "b" and "c" can be desktop PC and Tablet for example. So I think, we might benefit more from an import/export setting for now. The other thing is, if we make this server side, the GUI becomes sticked to the server again. Other 3rd party GUIs would have to adapt the same behavior as well. What we could probably do - thats maybe a future thing - we already have a database on server side. So maybe there is a way of storing such data on server side ( explicitly naming Station database) for requesting it from a client. But to be honest, I would do this after a 1.0 release, as this should be our main focus for now. I want to focus work on stability and reducing bugs for having a first reliable release. |
Yes, good point of 1 gui and more servers. I forgot to mention in title, but take this as nice2have low prio. Higher prio will have ability to change api server, so gui can be hosted at one site and switch between servers. |
I have been thinking about the ability to switch servers as well. This would result in a more scalable infrastructure. But it's of the same priority ( p3 ) as well - better having a working server first, then we can focus on more features in my opinion. However, what about renaming this issue to "Import / Export GUI profiles? I think this would fill a gap between those topics. |
Ok let's rename, i do not know if I have permissions to it. It was just quick idea yesterdayc when i switch to 'pocket' laptop and had to rearange widgets again. So until i'll forgot on it, i rather filled it here, just that was first idea blinded situarion when I have one server and more clients |
Problem Description
In case if you change browser, laptop, environmet. Use have to arrange GUI widgets again.
There would be handy if those positions and widgets will be possible save as some profiles on server. And in browser's cookie/storage/where ever page can store data in browser keep name of that profile.
Also it would be nice if someone want try more designs which fill fit more and do not want to lose that "previous" one.
Also it could be handy like for regular QSO one layout, for contest QSO different layout (there also may be some new widgets later).
Also different screens, someone have fullHD, someone 4K and someone 8" miniPC.
Proposed Solution
Some API to store data on server-side
Alternatives Considered
Import/export browser data? Maybe?
Additional Information
No response
The text was updated successfully, but these errors were encountered: