Flutter GUI

[joe-getcouragenow]

https://github.com/go-flutter-desktop/go-flutter

Would you be open to PR's for a cross platform GUI that runs on all desktops and mobiles ?

[rubiojr]

I'd be happy to help with the new GUI, but no immediate plans to replace the GTK one. I use GNOME every day and I like it to be tightly integrated with my desktop.
Doesn't mean I won't change my mind depending on the result ;), and I'd love to be able to use it from macOS or iOS eventually, but my current focus is to stabilize and document what I have.

The important functionality (indexing, searching, accessing restic repos) is not coupled to the GUI, and we can do a better job at decoupling other backend pieces (downloading/exporting, tagging). I'd be happy to help and document the work for others to use.

It took me a couple of weeks to build a PoC GUI with Gotk3 without knowing much about it, so it's def doable.

[joe-getcouragenow]

@rubiojr

sorry about delay in getting back to you.

Thanks for having a look at the option of flutter GUI.

Flutter is becoming tightly integrated with desktops. SOme examples you might or might not know..
Ubuntu has adopted it as their "one true way" to install snap apps for example.
https://pub.dev/packages/xdg_directories for example for File system aspects.

Also you can just use golang on desktops and wrap it with flutter and its runs on web, Desktop and native. A good example is this: https://github.com/jerson/flutter-rsa.

• Cross compile the golang to WASM for FLutter Web
• Cross compile the golang to native for flutter mobile and desktop.

https://github.com/rubiojr/rindex looks really great.
BTW i am also using github.com/blugelabs/bluge with hugo. Marty is amazing ..

SO do you want me to get started on the Flutter GUI ? I can fork swamp and add to it.. Or if you want to take a different approach for doing this let me know what you are thinking.

[rubiojr]

@joe-getcouragenow been thinking a lot about this lately, thanks for the pointers.

I have plans to split the GUI and and core parts post 1.0, and yes, a Flutter GUI is most welcome.

My current plan post 1.0 is (roughly):

• Split this repository, keep the swamp repository for the core, cross platform parts and add a new swamp-gnome repository where the current GUI is hosted.
• Add a new swamp-gnome repository where this interface will be hosted.
• Move some of the logic now coupled to the GUI to it's own daemon/service (indexd).
• Add macOS support for the core parts: indexer (swampd), CLI (swp) and a new service I'm planning to add to be able to query the index, tag things etc using HTTP (indexd).

1.X series will largely focus on bug fixing and small features for the existing code, but I'll have a 2.0 branch ready to work on cross platform support and all the bits mentioned above. That'd probably be the right time to start a different GUI, since I'll move all the logic to the services so it can be reused from different places.

SO do you want me to get started on the Flutter GUI ? I can fork swamp and add to it.. Or if you want to take a different approach for doing this let me know what you are thinking.

I think it'd be a good idea to start experimenting with it. That'd definitely help me to figure out what the shared logic should be and where we should add it. Whether or not it'll replace the GNOME GUI that I currently have, it's really hard to say right now, as I'm not familiar with Flutter and the possible/future UI.

Adding cross platform support is quite an engineering feat if you take into account all the automated testing that needs to be added, CI environments, manual QA, specialized target platform knowledge, etc. Something that can easily destroy a one man project, so I want to approach that with caution.

[joe-getcouragenow]

Hey @rubiojr sounds like a good approach.

comments below...

@joe-getcouragenow been thinking a lot about this lately, thanks for the pointers.

I have plans to split the GUI and and core parts post 1.0, and yes, a Flutter GUI is most welcome.

My current plan post 1.0 is (roughly):

• Split this repository, keep the swamp repository for the core, cross platform parts and add a new swamp-gnome repository where the current GUI is hosted.
• Add a new swamp-gnome repository where this interface will be hosted.
• Move some of the logic now coupled to the GUI to it's own daemon/service (indexd).
• Add macOS support for the core parts: indexer (swampd), CLI (swp) and a new service I'm planning to add to be able to query the index, tag things etc using HTTP (indexd).

Ok, i understand what your getting at. macOS support i presume is some naive things mac needs...
One thing i really love with bleve is facets. They allow drilling down into data based on the facets. Might be a good idea to consider them with v2 maybe. Does not have to be done, but at least some basic support in the architecture for them.
Anyway i don't want to get into scope creep too much, but just raising it casually for now. Can always be refactored in once things settle down.

1.X series will largely focus on bug fixing and small features for the existing code, but I'll have a 2.0 branch ready to work on cross platform support and all the bits mentioned above. That'd probably be the right time to start a different GUI, since I'll move all the logic to the services so it can be reused from different places.

agree thats makes sense... I get familiar with your code base in the meantime.

SO do you want me to get started on the Flutter GUI ? I can fork swamp and add to it.. Or if you want to take a different approach for doing this let me know what you are thinking.

I think it'd be a good idea to start experimenting with it. That'd definitely help me to figure out what the shared logic should be and where we should add it. Whether or not it'll replace the GNOME GUI that I currently have, it's really hard to say right now, as I'm not familiar with Flutter and the possible/future UI.

Ok we will start, but also wait for the v2 version with a decent separation of GUI and logic.

Regarding this separation, I tend to use Protobufs as a neutral way to have flutter talk to anything else. Here is an example: https://github.com/jerson/rsa-mobile/blob/master/proto/bridge.proto. I know it sounds a bit over the top but once tooled up its really nice as Flutter and golang have full proto support. Not sure about gnome aspects though.. I have never done gnome. But this approach generally keeps you out of trouble as they say.

The other thing about the protobufs is the code generation for both sides and type support. It makes refactoring easier IMHO.

Adding cross platform support is quite an engineering feat if you take into account all the automated testing that needs to be added, CI environments, manual QA, specialized target platform knowledge, etc. Something that can easily destroy a one man project, so I want to approach that with caution.

Regarding CI with Flutter and golang its pretty nice situation. A makefile can be called from github action. Its really nice also because you can run the identical code on your laptop as what runs in the github actions.
Here is a good example: https://github.com/jerson/rsa-mobile/tree/master/.github/workflows where its just "make blah blah"
As far as gnome and CI i am again totally useful i am afraid.

How about making a new Issue and adding my handle, where we can scope out the thing as it moves forward for now ?

[rubiojr]

Ok, i understand what your getting at. macOS support i presume is some naive things mac needs...

Yeah, it's mostly about using the right directories for storing config and data, adding CI (eventually) for it, publishing packages to install it and automating the release tasks.

One thing i really love with bleve is facets. They allow drilling down into data based on the facets. Might be a good idea to consider them with v2 maybe. Does not have to be done, but at least some basic support in the architecture for them.

I'm not super familiar with Bleve and facets. Happy to explore it and see the benefit it'd bring to the project. I need to revisit my choice of using Bluge for rindex, as it's currently a developer preview and, although I've been able to fine tune it so it works reasonably well for large restic repositories, I'm still considering exploring an alternative engine (Bleve) for rindex before the final release.

Regarding this separation, I tend to use Protobufs as a neutral way to have flutter talk to anything else. Here is an example: https://github.com/jerson/rsa-mobile/blob/master/proto/bridge.proto. I know it sounds a bit over the top but once tooled up its really nice as Flutter and golang have full proto support. Not sure about gnome aspects though.. I have never done gnome. But this approach generally keeps you out of trouble as they say.

I wanted to explore Twirp for IPC eventually (I need to use it for unrelated reasons, so wanna kill two birds with one stone). Right now the communication between the GUI and swampd is limited to getting the status of the indexer and some metrics and it's quite simple, so doesn't need to be super performant, currently using HTTP over a UNIX socket which gets the job done for now. I think exploring a more efficient and secure IPC will make sense once we decouple other components like indexd, that will handle queries and other index related tasks.

Regarding CI with Flutter and golang its pretty nice situation. A makefile can be called from github action. Its really nice also because you can run the identical code on your laptop as what runs in the github actions.

That's good news, because testing GUI code right now (gotk3 GTK bindings) is unexplored territory from what I've seen, and there are not a lot of great options out there.

Regarding CI with Flutter and golang its pretty nice situation. A makefile can be called from github action. Its really nice also because you can run the identical code on your laptop as what runs in the github actions.

Definitely, please feel free. Happy to answer questions, the documentation is currently lacking. I can prioritize that if you plan to start playing with the code.

[joe-getcouragenow]

Reading Twirp, which i know, i think you will get a better solution using grpc for IPC on the awesome some list.

GRPC is very flexible.

https://github.com/grpc-ecosystem/awesome-grpc#tools