Author Topic: GUI state triaging  (Read 592 times)

garry23

  • Hero Member
  • *****
  • Posts: 1266
GUI state triaging
« on: May 19, 2017, 04:56:48 PM »
@A1ex/@dmilligan

I've hit a final challenge in my focus bar script.

I wish to switch off the focus bar (eg switch of the display) if the ML menu is showing or the Canon Menu. I seem to be able to do this with the following snippet:

Code: [Select]
if (menu.visible or camera.state ~= 0) or (not showing) then -- don't show bar'
        if not hidden then
            display.clear()
        end
            hidden = true -- now hidden so don't need to keep hiding'
    else
            hidden = false -- show the focus bar

The variable 'showing' is a one of the focus bar inputs, ie to turn on or off the focus bar.

So far, so good.

What I can't seem to do is work out how to detect various other GUI state, eg I would like to switch the focus bar off if the user is using one (or all) the info screens, ie not just the Menu screens (Canon and ML).

I've looked into the source code but can't seem to see the info I'm after, eg the GUI state codes.

Would the above be possible...and, of course, how ;-)

Cheers

Garry


dmilligan

  • Developer
  • Hero Member
  • *****
  • Posts: 3203
  • 60Da / 1100D / EOSM
Re: GUI state triaging
« Reply #1 on: May 19, 2017, 08:01:42 PM »
From the Lua docs:
Quote
Get the current Canon GUI state of the camera (PLAY, QR etc; see gui-common.h)
gui_common.h (starts at line 180)

a1ex

  • Administrator
  • Hero Member
  • *****
  • Posts: 10180
  • 5D Mark Free
Re: GUI state triaging
« Reply #2 on: May 19, 2017, 08:27:15 PM »
That would only give info about "major" GUI changes on Canon's side (and the constants are model-dependent, though pretty much compatible across DIGIC 4 and 5 models). Small dialogs (such as ISO) are not covered here.

For the latter, I use display_idle(). In Lua, this is exposed as display.idle(), although these should be probably all grouped into some sort of GUI routines (along with SetGUIRequestMode, for example) and abstract some model-specific differences. That's where the GUI emulation in QEMU is going to be useful.

garry23

  • Hero Member
  • *****
  • Posts: 1266
Re: GUI state triaging
« Reply #3 on: May 19, 2017, 08:32:56 PM »
@A1ex/@dmilligan

Thanks for the info.

I had already convinced myself, by looking at the common.h, that GUI state was not sufficient.

I'll look into the other stuff.

Cheers

Garry

garry23

  • Hero Member
  • *****
  • Posts: 1266
Re: GUI state triaging
« Reply #4 on: May 19, 2017, 09:27:54 PM »
@A1ex

My knowledge has let me down, ie how to use display.idle()

I get an error regarding calling a Boolean.

My test snippet of code looks like this:

Code: [Select]
if display.idle() then
    display.print("AAA", 100, 100, FONT.MEDIUM ,COLOR.WHITE,COLOR.BLACK)
else
    display.print("BBB", 100, 100, FONT.MEDIUM ,COLOR.WHITE,COLOR.BLACK)
end

Any insight would be appreciated, ie why do I get an error?

dmilligan

  • Developer
  • Hero Member
  • *****
  • Posts: 3203
  • 60Da / 1100D / EOSM
Re: GUI state triaging
« Reply #5 on: May 19, 2017, 10:26:14 PM »
Code: [Select]
if display.idle then

garry23

  • Hero Member
  • *****
  • Posts: 1266
Re: GUI state triaging
« Reply #6 on: May 19, 2017, 10:51:43 PM »
 :o

@dmilligan thanks  :-[

Unfortunately it doesn't help me.

All display.idle dose is detect the MENU change state, not the INFO.

Oh well, I just have to live with the focus bar being on when INFO used.

Cheers and thanks for your help.

Garry