Skip to content
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: 'Recover' All for Recoverable #43

Open
sarxworks opened this issue Jan 12, 2019 · 4 comments
Open

Feature Request: 'Recover' All for Recoverable #43

sarxworks opened this issue Jan 12, 2019 · 4 comments

Comments

@sarxworks
Copy link

I've emailed before about recovering all partitions and I understand that was not a great idea. Now I raise the question, If it is possible to recover the partitions that are listed as recoverable instead of having to individually filter through each one. I am confident that each partition contains important date because as I am looking for a variety of file types on this rescue image. If you could lead me to the solution or a better solutions that would also be appreciated. Thanks you in advance.

@Lazza
Copy link
Owner

Lazza commented Jan 25, 2019

I think this issue relates to a more broader topic: the UI of RecuperaBit needs a big revamp.

In the future I think one shall be able to sort partitions and select what to recover.

@beaster99
Copy link

beaster99 commented Dec 29, 2019

If you wanted help doing the UX Work what would you be seeking to use?
GTK+, Qt, Tk, wxWidgets, HTML5,
Platform Independent or GDM/Gnome specific?

@Lazza
Copy link
Owner

Lazza commented Feb 3, 2020

I have not conducted a deep comparison on the toolkits yet. I guess probably it would be better to choose either Qt or wxWidgets to keep it cross-platform.

A web based interface seems a cool idea though, I'd need to investigate it further.

@NicolasCARPi
Copy link
Contributor

Just throwing the idea out here: a master server process running in the background, that can receive events from clients either CLI or GUI. You'd have jobs that can be suspended, and once finished you can extract stuff from it easily without having to keep your python process open. This would allow a good separation between the core and the interface. But that's probably out of scope for an open source project that was not designed like that from the start. Small incremental changes sounds better here.

Anyway, for GUI I'd vote for Qt.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants