Jeff Carr f48d3fbcfe | ||
---|---|---|
cmds | ||
toolkit | ||
.gitignore | ||
LICENSE.md | ||
Makefile | ||
README.md | ||
button.go | ||
checkbox.go | ||
doc.go | ||
dropdown.go | ||
example_test.go | ||
go.mod | ||
go.sum | ||
group.go | ||
int.go | ||
main.go | ||
node.go | ||
slider.go | ||
spinner.go | ||
structs.go | ||
tab.go | ||
text.go | ||
textbox.go | ||
window-debug.go | ||
window-demo-toolkit.go | ||
window-demo.go | ||
window-golang-debug.go | ||
window.go |
README.md
gui
Package gui implements a abstraction layer for Go visual elements in a cross platform and library independent way. (hopefully this is will work)
A quick overview of the features, some general design guidelines and principles for how this package should generally work:
Definitions:
* Toolkit: the underlying library (MacOS gui, Windows gui, gtk, qt, etc)
* Node: A binary tree of all the underlying GUI toolkit elements
Principles:
* Make code using this package simple to use
* When in doubt, search upward in the binary tree
* It's ok to guess. We will return something close.
* Hide complexity internally here
* Isolate the GUI toolkit
* Function names should follow [[Graphical widget]]
Quick Start
This section demonstrates how to quickly get started with spew. See the sections below for further details on formatting and configuration options.
// This creates a simple hello world window
package main
import (
"log"
"git.wit.org/wit/gui"
)
var window *gui.Node // This is the beginning of the binary tree of widgets
// go will sit here until the window exits
func main() {
gui.Main(helloworld)
}
// This initializes the first window and 2 tabs
func helloworld() {
gui.Config.Title = "Hello World golang wit/gui Window"
gui.Config.Width = 640
gui.Config.Height = 480
window := gui.NewWindow()
addTab(window, "A Simple Tab Demo")
addTab(window, "A Second Tab")
}
func addTab(w *gui.Node, title string) {
tab := w.NewTab(title)
group := tab.NewGroup("foo bar")
group.NewButton("hello", func() {
log.Println("world")
})
}
Debian Build
This worked on debian sid on 2022/10/20 I didn't record the dependances needed
GO111MODULE="off" go get -v -t -u git.wit.org/wit/gui
cd ~/go/src/git.wit.org/wit/gui/cmds/helloworld/
GO111MODULE="off" go build -v -x
[./helloworld](./helloworld)
Toolkits
The goal is to design something that will work with more than one.
Right now, this abstraction is built on top of the go package 'andlabs/ui' which does the cross platform support. The next step is to intent is to allow this to work directly against GTK and QT.
It should be able to add Fyne, WASM, native macos & windows, android and hopefully also things like libSDL, faiface/pixel, slint
Errors
Since it is possible for custom Stringer/error interfaces to panic, spew detects them and handles them internally by printing the panic information inline with the output. Since spew is intended to provide deep pretty printing capabilities on structures, it intentionally does not return any errors.
Debugging
To dump variables with full newlines, indentation, type, and pointer information this uses spew.Dump()
Bugs
"The author's idea of friendly may differ to that of many other people."
-- manpage quote from the excellent minimalistic window manager 'evilwm'
External References
Useful links and other external things which might be useful
Functions
func DebugTab
func DebugTab()
this function is used by the examples to add a tab dynamically to the bugWin node TODO: make this smarter once this uses toolkit/
func DebugWindow
func DebugWindow()
Creates a window helpful for debugging this package
func DemoToolkitWindow
func DemoToolkitWindow()
This creates a window that shows how the toolkit works internally using it's raw unchanged code for the toolkit itself
This is a way to test and see if the toolkit is working at all right now it shows the andlabs/ui/DemoNumbersPage()
func DemoWindow
func DemoWindow()
This creates a window that shows how this package works
func GetDebugToolkit
func GetDebugToolkit() bool
func GolangDebugWindow
func GolangDebugWindow()
func IndentPrintln
func IndentPrintln(a ...interface{})
func Main
func Main(f func())
func Queue
func Queue(f func())
Other goroutines must use this to access the GUI
You can not acess / process the GUI thread directly from other goroutines. This is due to the nature of how Linux, MacOS and Windows work (they all work differently. suprise. surprise.) For example: gui.Queue(NewWindow())
func SetDebugToolkit
func SetDebugToolkit(s bool)
func ShowDebugValues
func ShowDebugValues()
func StandardClose
func StandardClose(n *Node)
Types
type GuiConfig
type GuiConfig struct { ... }
Variables
var Config GuiConfig
type Node
type Node struct { ... }
The Node is simply the name and the size of whatever GUI element exists
func NewStandardWindow
func NewStandardWindow(title string) *Node
func NewWindow
func NewWindow() *Node
This routine creates a blank window with a Title and size (W x H)
This routine can not have any arguements due to the nature of how it can be passed via the 'andlabs/ui' queue which, because it is cross platform, must pass UI changes into the OS threads (that is my guess).
This example demonstrates how to create a NewWindow()
Interacting with a GUI in a cross platform fashion adds some unusual problems. To obvuscate those, andlabs/ui starts a goroutine that interacts with the native gui toolkits on the Linux, MacOS, Windows, etc.
Because of this oddity, to initialize a new window, the function is not passed any arguements and instead passes the information via the Config type.
package main
import (
"git.wit.org/wit/gui"
)
func main() {
// Define the name and size
gui.Config.Title = "WIT GUI Window 1"
gui.Config.Width = 640
gui.Config.Height = 480
// Create the Window
gui.NewWindow()
}
Output:
You get a window
type Widget
type Widget int
Readme created from Go doc with goreadme