A way to refresh settings widget in-place

[RReverser]

Is your feature request related to a problem? Please describe.

In a UI frontend I'm building, I'm constantly monitoring settings from the camera to show up-to-date values and state of various settings (e.g. if user changed a mode wheel or other settings on the camera, I want to make sure new property values and readonly states are reflected in the UI).

Unfortunately, this is not very efficient, since I have to call gp_camera_get_config each time, which has to recreate entire widget tree which I'm immediately throwing away after showing.

Describe the solution you'd like

A way to refresh a widget in-place, changing only readonly states and the actual values, but not re-reading PTP names, types, enumeration lists, and not reallocating the whole tree.

API-wise this could be exposed as user passing a non-NULL pointer to gp_camera_get_config - then camlibs should reuse it by only populating the new values and changing readonly state, but leaving the rest intact.

Describe alternatives you've considered

If there was an API to read the value and readonly state of configs directly, I could do such updates myself, but AFAIK gphoto2 only exposes them through widgets. This would also be more tedious than a built-in way to refresh widgets that probably all GUI frontends could benefit from.

[msmeissn]

it is tricky. i need to spend some time to think about it :/

[RReverser]

Thinking about this a bit more - I see that at ptp2 camlib reports PTP property changes.

Could we leverage that by exposing a function that would walk through all such pending events, consume them and update the provided CameraWidget *? That would be very efficient and perhaps not too complicated to do.

For other camlibs that don't support such events such function could fallback to full gp_camera_get_config call internally.

[RReverser]

@msmeissn How stable are those "PTP Property 1234 changed" messages btw? I could for now try parsing them myself to figure out which config fields have changed, but they are just strings and not a dedicated event type, which makes me somewhat uncomfortable to rely on them if they are an implementation detail that can change at any time.

[msmeissn]

while I currently did not plan to change them, one idea would that they report the properties that were changed by config name space instead of id. But I would emit that additoonaly I think.

[RReverser]

that they report the properties that were changed by config name space instead of id

That would be nice, yeah - otherwise it makes it hard to match prop id to config name as that API is not public.

[msmeissn]

I added a first draft. Currently it looks like this:

UNKNOWN PTP Property d0bf changed, "MovieLogSetting" UNKNOWN PTP Property d138 changed, "VibrationReduction" UNKNOWN PTP Property d1f9 changed, "MovieVibrationReduction" UNKNOWN PTP Property d1fa changed, "MovieFocusMode" UNKNOWN PTP Property d1fa changed, "MovieFocusMode" UNKNOWN PTP Property d0a4 changed, "movieprohibit" UNKNOWN PTP Property d1b4 changed, "ContinousShootingCount" UNKNOWN PTP Property d1b7 changed, "MovieRecFrameCount" UNKNOWN PTP Property d1f1 changed, "availableshots" FILEADDED DSC_1112.JPG /store_00010001/DCIM/100NCZ_6 CAPTURECOMPLETE UNKNOWN PTP Property d0a4 changed, "movieprohibit"

these are the widget names from the config tree. (the mixed case ones from the other/ tree ;) .... I think I can also add string content there.

or would 2 lines preferable?

[RReverser]

I think that looks like a great start, at least it gives a way to figure out which parts of the config have changed, so it's possible to parse it out and retrieve a single setting that has been updated.

A semi-related question: do other drivers (non-PTP) report property changes as well?

If so, maybe this could be changed into its own event type instead of Unknown? Then, instead of parsing, one could retrieve config name via properties of a dedicated structure.

[msmeissn]

i also consider emitting the new value (as string).

once it stabilizes, perhaps as new event type too. would it make sense to give back CameraWidget structures or better just strings for such cases?

so far ptp is the most feature complete driver there... i surely can add it to others.

[RReverser]

would it make sense to give back CameraWidget structures or better just strings for such cases?

I think CameraWidget would be even better, yeah. If, in an addition, there would be a public helper that allows to copy everything from one CameraWidget to another, then on the app side it would be fairly trivial to do something like

1. Read entire settings tree.
2. In an event loop: 2.1. Check if there are any events in the queue. 2.2. Take one if there is. 2.3. If this is "settings changed" event, cast it to CameraWidget and merge into the original tree. 2.4. Update the UI.

This way, both UI and settings tree would always stay up-to-date, and allow bidirectional updates to match camera settings.

[msmeissn]

updated also to emit new content for now: ... FILEADDED DSC_1113.JPG /store_00010001/DCIM/100NCZ_6 CAPTURECOMPLETE UNKNOWN PTP Property d1f1 changed, "availableshots" to "3359.000000" UNKNOWN PTP Property d0a4 changed, "movieprohibit" to "Movie prohibit conditions: Not in application mode,Set liveview selector is enabled" UNKNOWN PTP Property 5007 changed, "f-number" to "f/4" UNKNOWN PTP Property 500d changed, "shutterspeed" to "0.0125s" UNKNOWN PTP Property d100 changed, "shutterspeed2" to "1/80" UNKNOWN PTP Property d0b5 changed, "ISOControlSensitivity" to "100" UNKNOWN PTP Property 5007 changed, "f-number" to "f/4.5"

widget based work sounds also good... i think this might be doable

[Sija]

Bumping the issue for visibility.