GUI alternative with Gooey

[celefthe]

Hey folks,

First of all, many thanks for all the great work you've done with the brainglobe suite!

I recently had to convert the CLI into a simple GUI for some less technically minded folk who like what brainreg does but don't like terminals. I'm aware that a GUI exists within napari, but as this was neither part of their workflow (nor something they were interested in switching to in this instance) I used the Gooey project (https://github.com/chriskiehl/Gooey) to wrap the command line version of brainreg into a straight-forward GUI (see screenshot below). This then allows folk who don't want to deal with the terminal to use brainreg as a stand-alone tool, without having to install (or learn) napari.

I appreciate this may not be something you want to support -- I open this PR in case you find it useful, or if you think the use case here is frequent enough to support.

All the best,
Constantinos

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[celefthe]

I forgot to mention - the GUI only runs if 'braineg' is called in the terminal without any arguments. I wrap this in a desktop shortcut for a terminal free experience. Otherwise the command accepts whatever arguments and runs as normal - so the GUI does not replace the CLI here

[adamltyson]

Hey @celefthe, glad brainreg is proving useful! I once had a plan to do exactly this, before I moved to napari.

I'm not sure what I think about merging this. The napari plugin is the main GUI entry point to the software, and will continue to be. There's a lot still left to work on with the plugin, but can I ask what limitations it has from your point of view? Napari is installed with brainreg anyway, and users don't have to learn napari, just the brainreg widget (similar to the Gooey version).

So normally, I would say no to merging. However, the Gooey version is simple, clean, and very few lines of code to maintain. I assume the GooeyParser class doesn't affect the CLI at all?

[adamltyson]

You can ignore the tests (they're broken anyway). However, brainreg now no longer installs on GH actions. The errors mention wxpython, so I guess this is to do with Gooey? I think this would need to be fixed before merging, so that GH actions would at least run (even if we haven't fixed the tests yet).

[celefthe]

Hi @adamltyson,

I think it ultimately depends on how brainreg fits into the bigger picture. If you see napari as the de-facto way users ought to interact with brainreg, then shipping a different GUI with it probably doesn't make a lot of sense - I think giving users too much choice can be a bit overwhelming from their perspective. If, on the other hand, you see brainreg as a thing of its own that also happens to come as a plugin for napari, then I think shipping a GUI with it makes sense for those interested in just using brainreg as a stand-alone tool. I suppose it depends if you intend for brainglobe to be a comprehensive platform or an a la carte set of tools.

I have no qualms with napari - I think it's great at what it does, and it makes sense for all these tools to go under its umbrella. In this particular instance, the users were only interested in comparing the registration output of brainreg with whatever proprietary nightmare they're currently using. The first time I tried installing napari on their machine (Windows 10) the plugin refused to work (I'm still not sure whether this is an issue on our end though, but if not I'll submit a different issue) and my thinking was "I don't need the bells and whistles, I just need to register some brains" so I saw providing a simple GUI alternative to the CLI I would otherwise use as the path of least resistance. Again it all depends on how you'd rather the users interact with brainglobe's different components - in this case the users were more interested in the a la carte approach, at least in the first instance, but this might be an exception rather than the default approach most users would (or should) take.

[celefthe]

You can ignore the tests (they're broken anyway). However, brainreg now no longer installs on GH actions. The errors mention wxpython, so I guess this is to do with Gooey? I think this would need to be fixed before merging, so that GH actions would at least run (even if we haven't fixed the tests yet).

Yep I think the environment needs the wx gtk3 headers to run (python-wxgtk3.0-dev) - if you decide to eventually merge this I'll fix the CI and add tests and docs before you do.

GooeyParser is basically ArgumentParser with widgets, the CLI will still parse args as normal.

[adamltyson]

I suppose it depends if you intend for brainglobe to be a comprehensive platform or an a la carte set of tools.

That's a good question, and the answer is both. We want to provide an integrated environment, but each tool should be fully functional in isolation.

Having thought about it, I think I'd prefer to include this, document it, but not necessarily advertise it. Napari will be the default GUI, but this will be available for those who don't need any other part of the ecosystem, in the same way that cellfinder-core exists for those who want to use the cell detection algorithm, without any of the additional anatomical context that BrainGlobe provides.

Does this sounds good to you?

[celefthe]

Sounds good to me!

I've been thinking a bit about this and I think the current approach of launching the GUI when brainreg is called with no parameters might violate the principle of least astonishment -- the default should probably be the program shouting at you and laying out what it needs to run, instead of running an interface.

I think it might be a good idea to just have the GUI launch if explicitly requested, e.g. with a --gui flag. What do you think? Or do you prefer the default of launching if no parameters are defined?

[adamltyson]

I think you're right. A --gui flag, or even a separate entry point (e.g. brainreg-gui) is better than launching an unexpected GUI.

[celefthe]

Do you have a preference or should I submit whichever version I think looks nicer for review?

[adamltyson]

Happy to go with whatever you think.

[JulesScholler]

Just to say that I was going to also use Gooey for the exact same purpose because many people just want to use BrainReg to register brains and that's it (hence why original data orientation is also important, see my PR).

I agree that Napari is great but it might be a pain to install it with other libraries that are also using graphical backends, especially when using VM and hypervisor (which happens a lot on imaging facilities).

All of this to say that this PR would be very welcomed, thanks @celefthe !

[adamltyson]

Thanks @JulesScholler, good to know! I forgot about VMs and remote desktops etc. which can make napari difficult to use.

@celefthe once this PR is done, we can add the GUI to the docs.

[adamltyson]

Hey @celefthe, do you think you'll have to work on this, or shall I close?

[celefthe]

Hey Adam, apologies, this fell by the wayside — I’ll wrap this up over the weekend. Cheers

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[adamltyson]

Thanks for following this up @celefthe. Just FYI, a fresh install of brainreg seems to be broken at the moment (#56) just in case you're testing stuff and it's going wrong. Shouldn't affect the GUI itself though.

[adamltyson]

Hi @celefthe, do you still have plans to finish off this PR, or shall I close?

Cheers,
Adam

[adamltyson]

Hey @celefthe, I'll close this PR for now, but feel free to reopen it.