Draft: Flash
Flash looked lonely here, so while waiting for other pieces to move forward, I made this rough draft (manual only for now despite UI).
Not sure how to determine automatic activation.
Draft cause the icons need background and the blinking can be better.
Merge request reports
Activity
mentioned in issue #38
mentioned in issue #37
@sam.hewitt do you want to take a look at this? The design is a bit crude now.
Here's a version which should work even if you don't have a camera at all. It does work on my laptop with a USB webcam: https://source.puri.sm/dorota.czaplejewicz/megapixels/-/pipelines/83352
Once the pipeline is complete, choose the relevant package and go to Artifacts.
My specific thoughts, just from the video:
Flash: Auto|On|Off
makes sense to me for a toggle for the flash.Secondary thoughts: at some point it would be nice to give the UI a larger facelift overall and possibly turn these dropdowns into icon-based menus (I did create several symbolic icons for camera actions some time ago that could be used here.)
Right now I'm looking for minial feedback on the colors, backgrounds (now there's a black 80% backgrund for the entire dropdown), and outlines. If it's sufficient as-is, then cool.
I'll replace the text with icons, but I need to ask: how to represent auto=off and auto=on states on the top bar?
Longer term I want to replace the entire UI with something more appropriate for a fast camera application (immediate mode), like egui. Then we could get serious about styling the widgets.
how to represent auto=off and auto=on states on the top bar?
I assume those two states are whether or not the camera/app is deciding when to fire the flash while in Automatic flash mode. Would this state be frequently changing if you're panning around with the camera and the app is deciding if it's a sufficiently bright/dark scene in which to use flash?
Yeah I asked to get that clarification. I don't think I have used any camera app either that disclosed the internal state, as I don't think it would factor in much to user's decision making process for taking a photo--"Auto" would already imply they are trusting the app to chose the right state. tl;dr I think we'd be fine to not display that status and just have Auto be Auto
Longer term I want to replace the entire UI with something more appropriate for a fast camera application (immediate mode), like egui. Then we could get serious about styling the widgets.
Out of curiosity mostly, is there a reason to not use gtk here? (I ask since if I were to create mockups for the camera app it would likely be with LibAdwaita/GTK and GNOME HIG in mind).
GTK is designed in a way that it takes care of most UI things for you, and is geared towards showing widgets. This is a mismatch compared to what a camera application needs, which is primarily displaying a processed picture, and having strong manual control over the presentation of the widgets. Things like keeping controls in the same place while the display is rotating would be a pain in GTK, and we also don't need many controls apart from a separate configuration screen.
This mismatch is maybe not enough on its own, but GTK is also a retained mode GUI, and thus makes it more complicated to synchronize UI elements with actual state. (I actually implemented the flash control as a slider like the others first, but it was harder to get right than the current version.)
I looked at GtkFixed, and it seems like it's addressing a different thing, like absolute positioning in CSS?
I agree that it would be possible to keep the controls in the right place using GTK if we create some extra buffer that we manually render on top of something whose coordinate system/rotation we tightly control. But it would be relatively harder to compose the pieces compared to a solution where we control the transformation matrix directly and deal with controls in a naive way.
Right now I'm looking for minial feedback on the colors, backgrounds (now there's a black 80% backgrund for the entire dropdown), and outlines. If it's sufficient as-is, then cool.
Black is an obvious way to go for the camera app, just to have the UI defer to the photo content as much as possible. So no comment on the colors.
You'll never going to be able to achieve that unless you get a robust power quota system, which AFAIK we're nowhere close to having. The best we can do for now is to limit the maximum flash current in the device tree to some reasonable value, and perhaps disable flash functionality when on low battery.