I highly disagree with your view of the user experience.
A panel being open during plugin use is the common and expected way of interfacing with a tool. A photobooth plugin is not a passive plugin meant as an overlay or global toggle, it’s a tool with accessories. We open the toolbox when we need it and close it when we’re done.
“The user has to open up everything again” is just selecting the Photobooth icon in their plugins list. The user will always needs to re-open plugins after closing them. Thankfully closing plugins is very hard to do on accident…
The issue of click fatigue is valid- but you are thinking about this all wrong. Currently the user has two clicks to initiate a viewport and then snap a photo. Yes- this would turn to three.
But, on the flipside, every other aspect of the plugin is less usable as a result of this decision priority.
Right now you have to hop between a panel, quick access menu, and ribbon bar. It is far from intuitive. By reducing the screen real estate required to interface with the plugin you improve usability by providing a single point of focus for the tool. And like I said, it’s rather trivial to add a setting to put the additional buttons back on the ribbon bar.
It seems to me that the Photobooth plugin is a rather power user focused plugin, and those are the types more likely to have a filled plugin bar.
As to the extended scope of the plugin, these suggestions would add value to the plugin since they’re closely in line with typical use cases. No demands for the features, but your suggestion to use a clunky alternative such as the command bar is precisely why they’d be so useful
Managed to get it to work by parenting to StarterGui and just bulk selecting and exporting (may work with a model but I didn’t try it). Not sure why bulk exporting only seems to work when parented to StarterGui when single exporting works fine in ServerStorage.
FYI, the issues with the Plugin RunContext and parallel luau have been resolved! See the update at the top of the announcment here. I’m happy to see those features are being used
I fixed an issue where fullscreen captures were not working when the os scale was not 1, 1. This should now be working correctly in both the fullscreen capture UI and also via bindings. Please read the main post for more details.
Hi! Thank you for fixing this, I did find there’s another faint line at the top of my image as show below. Not the biggest deal but I thought I’d let you know anyway!
I’m certainly interested in fixing this, but I’m a little confused what that faint line even is? Do you have a reproduction file you could send me (via DM)?
It’s also helpful if you provide info such as your screen resolution and OS scale value.
A placefile is proably easiest, but an rbxm works too! Basically, I want to try to recreate the issue on my end. The easiest way to do that is to capture under the same conditions as you (including your capture target).
