abstracting a widget's draw method

[Daniel Skinner]

Forgive my ignorance in writing a UI from scratch, but has any thought been giving to moving a widget's draw method to a central object of sorts responsible for how said widget is actually drawn to the screen?

Not in the case of say wanting to do something like

type CustomButton struct {

    Button

}

func (c *CustomButton) draw(....) {

    // do something whacky

}

But rather something along the lines of an interface that defines draw methods for supported widgets and when creating a widget, it's default draw method would simply be to call such as given by an implementation of said interface.

And so then if one so desired, they could implement that interface and provide custom draw methods for each widget type and and register that implementation with uik as the default, creating a sort of pluggable/themeable drawing backend that's distinctly set away from the actual widgets.

type DrawFoundation interface {

    DrawLabel func(Label, gc)

    ...

}

Widgets could still specify their own draw method, but the default at some point with built in widgets would be to call into the DrawFoundation implementation registered with uik. Just thoughts

[John Asmuth]

They already have a field "Paint func(draw2d.GraphicContext)", and what you suggest is already in the works (in my head - no code yet).

I was thinking about making a repository of drawing methods, where (for instance) the button type would say 

b.Paint = drawRepo.GetPaint("widgets.Button", b)

And if someone else wanted to register a new paint function, they could do so.

type PaintFunc func(draw2d.GraphicContext)
drawRepo.Register("widgets.Button", func(w interface{}) PaintFunc {
  b := w.(*Button)
  return func(gc GraphicContext) {
    // draw b into gc
  }
})

Does this match what you were thinking about? 

- John

--
You received this message because you are subscribed to the Google Groups "go-uik" group.
To view this discussion on the web visit https://groups.google.com/d/msg/go-uik/-/IsEyR-lyP64J.
To post to this group, send email to go-...@googlegroups.com.
To unsubscribe from this group, send email to go-uik+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/go-uik?hl=en.

[Daniel Skinner]

Yes I see, that explains the part i missed with draw method not being called in block.go, .Paint is set in the init, setting it to the draw method and the block is responsible for calling .Paint

I think the drawRepo is a fine idea (not that I have the experience to say its not), where in the example you gave, i assume the default "widgets.Button" will be replaced with the given closure and handle drawing from there.

I suppose one thing I hadn't considered was that registering new paint functions would have to be statically compiled with the app. I'd have to wonder what the options where for being able to dynamically register new paint methods with app XYZ binary. My viewpoint here being one of an ecosystem of uik apps, not just a singular app. I know that's a bit far out from the current goals of uik though.

[John Asmuth]

Unfortunately there is only static linking with go, for now, so we have to live within the ecosystem we are provided.

- John

[Daniel Skinner]

Certainly, and in light of that it'd be worthwhile to make the default drawRepo as robust as possible for user configured styling.

Of course that's an entirely different discussion and once drawRepo or whatever iteration of it is setup, that discussion can be facilitated with real code and examples.