search

lxn / walk

A Windows GUI toolkit for the Go Programming Language
Other
6.84k stars 884 forks source link

Do not use global init functions #606

Closed zx2c4 closed 5 years ago

zx2c4 commented 5 years ago

This allows walk to be used inside other applications without the overhead of the UI parts aren't used.

JoshuaSjoding commented 5 years ago

This accomplishes the primary goal of #601. It moves even more things out of init() which I think is great.

zx2c4 commented 5 years ago

Indeed it's a good start. Not totally there, as there still are globals, and you don't want globals at all. But it, at the very least, is a step in the right direction.

JoshuaSjoding commented 5 years ago

@zx2c4 Do you plan to pursue removal of the globals? If not then I can take a stab at it with a separate pull request, but I don't want to conflict with any of your current efforts.

zx2c4 commented 5 years ago

@JoshuaSjoding Maybe, but I wonder what the value would be. Not all globals need to be per-thread. I would be interested in doing something smarter with the ToolTip situation, as at the moment we're using the non-blocking cmpxchg instead of sync.Once, because the tooltip init functions calls InitWindow resulting in a deadlock. So getting that settled might be a more immediate priority. https://github.com/scjalliance/walk/commit/adb0efbb4f83a4ec6bb08ce4f33404a196b05f01 might be a way of fixing it, but there's also a performance hit to doing that too (the tree traversal), so I'm not quite sure yet.

JoshuaSjoding commented 5 years ago

@zx2c4 I think I have a better design in mind now. I'm going to create a WindowGroup type that stores state for a group of windows that share a thread, then store the common ToolTip control in the WindowGroup. I'll prepare a PR if I'm happy enough with the result.

JoshuaSjoding commented 5 years ago

@zx2c4 I've prepared #610 as an alternative solution to #601.