interesting
/
andlabs-ui
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Windows no longer need to be Controls after I reworked the parent-child system so that children do not need ot know what their parents are.

This commit is contained in:
Pietro Gagliardi 2014-02-14 11:13:10 -05:00
parent 80f43a613a
commit 9403224eb0
1 changed files with 0 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
window.go
View File

@ -92,12 +92,3 @@ func (w *Window) Show() (err error) {
func (w *Window) Hide() (err error) {
return w.sysData.hide()
}
// These satisfy the Control interface, allowing a window to own a control. As a consequence, Windows are themselves Controls. THIS IS UNDOCUMENTED AND UNSUPPORTED. I can make it supported in the future, but for now, no. You shouldn't be depending on the internals of the library to develop your programs: if the documentation is incomplete and/or wrong, get the person responsible to fix it, as the documentation, not the implementation, is your contract to what you can or cannot do. Don't worry, this package is in good company: Go itself was designed spec-first for this reason.
// If I decide not to support windows as controls, a better way to deal with controls would be in order. Perhaps separate interfaces...? Making Windows Controls seems the cleanest option for now (and with correct usage of the library costs nothing).
func (w *Window) make(window *sysData) error {
panic("Window.make() should never be called")
}
func (w *Window) setRect(x int, y int, width int, height int) error {
panic("Window.setRect() should never be called")
}