Details

    • Type: RFC
    • Status: Implemented
    • Resolution: Done
    • Component/s: DM
    • Labels:
      None

      Description

      For various PFS-related reasons I needed to write display_ginga, and came across a couple of things I'd like to modify in the afw.display.Device API. None of these changes modify any APIs (although the first could theoretically break a backend specification).

      This is not an RFC about the far-reaching changes that we'll probably need to make full use of the power of firefly (or ginga for that matter)!

      1. If you have a backend "foo" I'd like to try importing "lsst.display.foo" before "foo"
      2. I'd like to add a default to the frame argument in the Display constructor (this isn't a ginga thing, but it's an annoying gotcha currently)
      3. I'd like to add a __getattr__ method to Device that allows you to call methods on the implementation (e.g. ginga has a way to embed an image into a notebook; while eventually we may promote that API to Device, for now I want a way to get at it without going through device._impl.display)

      The last of these is probably the only contentious change as there are other less-magic ways to do it.

      P.S. I have display_ginga more-or-less working. No mask overlays or callbacks yet, and a number of bug reports into Eric Jeschke...

        Issue Links

          Activity

          Hide
          tjenness Tim Jenness added a comment -

          Robert Lupton did you mean to have this RFC open for a whole month?

          These changes look good to me. #1 does make more sense (I struggled a bit with that area in the Python 3 port).

          Show
          tjenness Tim Jenness added a comment - Robert Lupton did you mean to have this RFC open for a whole month? These changes look good to me. #1 does make more sense (I struggled a bit with that area in the Python 3 port).
          Hide
          shupe David Shupe added a comment -

          These changes look good to me too. #3 will be helpful. I'm not yet fully clear on how #1 will impact things but I'm confident we can handle it.

          Show
          shupe David Shupe added a comment - These changes look good to me too. #3 will be helpful. I'm not yet fully clear on how #1 will impact things but I'm confident we can handle it.
          Hide
          wmwood-vasey Michael Wood-Vasey added a comment -
          • Yes, definitely to #1!
            I've had to work-around this myself.
          • Yes to #2.
          • I don't fully understand the implications #3, but I don't have objections.
          Show
          wmwood-vasey Michael Wood-Vasey added a comment - Yes, definitely to #1! I've had to work-around this myself. Yes to #2. I don't fully understand the implications #3, but I don't have objections.
          Hide
          rhl Robert Lupton added a comment -

          Work will be done in DM-7848

          Show
          rhl Robert Lupton added a comment - Work will be done in DM-7848
          Hide
          swinbank John Swinbank added a comment -

          Given that DM-7848 is now done, I assume it's safe to mark this as implemented. Robert Lupton, please reopen if you disagree.

          Show
          swinbank John Swinbank added a comment - Given that DM-7848 is now done, I assume it's safe to mark this as implemented. Robert Lupton , please reopen if you disagree.

            People

            • Assignee:
              rhl Robert Lupton
              Reporter:
              rhl Robert Lupton
              Watchers:
              David Shupe, John Swinbank, Michael Wood-Vasey, Robert Lupton, Tim Jenness
            • Votes:
              1 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Planned End:

                Development