Minimal start

[blobject]

• Write a minimal config in tcl (maybe with stub external functions and api)
  • Decide on what to include in the config
• Start writing goose
  • Decide whether to adopt another project as a template
  • Decide what language to use
  • Try to include logging, init'ing, config'ing
• Start writing a layer that goes between tcl and goose proper/core/base/server

[blobject]

@Eloitor Let's write the base in zig (watched an introductory video about the language yesterday :-p). What do you say?

[Eloitor]

I like Zig, but sadly it is not easy to set up, it is not available in many distros: https://repology.org/project/zig/versions

In void linux (what I use) it is stuck at 0.10.1 for some months... https://github.com/void-linux/void-packages/issues?q=Updating+Zig+to+0.11.0

The upgrade from 0.10.1 to 0.11.0 is not backward compatible. Further updates may not be as well..

Other options we can consider:

• C: No problems
• Rust: I don't like it (I haven't tried) Long compile times?
• Go: Seems easier than rust, but big binaries? Can it work with C libraries?
• Hare is not 1.0 yet, and not available in many repos...
• Haskell would be interesting. I know functional programming but not Haskell specifically. I don't know how well works with C libraries, I think it works.
• V: Ok? I don't know.

Do you have other suggestions? If not, for me the clear winner is C. But we can work with Zig 0.10.1 if you want, it is nice to learn.

[Eloitor]

• Write a minimal config in tcl (maybe with stub external functions and api)

River can work with a tcl config!

https://gist.github.com/Eloitor/5b4b96311e0867057114b266245671b0

Maybe we can use river to get a prototype of the configuration that we wish to have

[blobject]

C: No problems

C it is then :-) I mean Haskell would be a dream, but also a bit too much work for me upfront.

use river to get a prototype of the configuration

Looks good, let's take a tiny subset of this. As a minimum, I'm thinking:

• open a terminal with a keybind
• close a terminal with a keybind
• tiled
  • open one to cover the entire screen by default
  • open two covering left and right (focus switchable by keybind)
• floating
  • open one with app's default size
  • open two stacked with a relative offset (focus switchable by keybind)

void linux (what I use)

Same here!

[Eloitor]

what about something like this?

#!/bin/env tclsh

proc bind {keys action args} {
	# TODO
	# exec riverctl map normal "modifier keys separated with +" "Main key" "translated action"
} 

bind {Super Shift Return} {exec foot}
bind {Super Q} {focused_window close}
bind {Super Shift E} {exit}
bind {Super J} {focus [focused_window next]}
bind {Super K} {focus [focused_window previous]}
bind {Super Space} {toogle-float}
bind {Super F} {toggle-fullscreen}

[Eloitor]

After thinking about it I think that adopting tk syntax is better:

# Keybindings
set Mod Mod4
bind . <$Mod-E> {exit}

https://www.tcl-lang.org/man/tcl/TkCmd/bind.htm

[blobject]

That's awesome. Yes, tk syntax for user events that call tcl procs.

We will need to work around the fact that bind is built for x and maybe implement our own library to support wayland events. Not sure how appropriate that would be for a minimal start.

At some point, though, I would love to do something like:

package require goose
set M Mod4
set S Shift
bind . <$M-Q> close [goose::get_current_window]
bind . <$M-$S-Q> close [goose::get_all_windows]

[Eloitor]

implement our own library to support wayland events.

Yes we'll have to do something like that. Maybe we can adapt something already done.
It should be with "{" to avoid instant execution.

bind . <$M-Q> {close [goose::get_current_window]}

Maybe even better if it is a variable:

bind . <$M-Q> {close $goose::current_window}
bind . <$M-$S-Q> {close $goose::windows}

[Eloitor]

We can also use tk to prototype some possible configurations:

#!/bin/env wish

wm title . "Goose"

set bindings_help {Keybindings:}

rename bind original_bind
proc bind {path binding action description} {
	global bindings_help
	append bindings_help "\n $description"
	original_bind $path $binding $action
}

bind . <c> {spawn foobar}        "c: Create window"
bind . <d> {pack forget [focus]} "d: Delete window"
bind . <e> {exit}                "e: Exit"

label .keybindingsInfo -text $bindings_help -anchor n -justify left
pack .keybindingsInfo -side left -anchor w -fill both

namespace eval goose {
	variable window {}
	variable next_id 1
}

proc spawn {command} {
	set win_name [join ".textBox $goose::next_id" ""]
	append goose::windows $win_name
	text $win_name
	pack $win_name -fill both -expand true -side left
	$win_name insert 1.0 $win_name

	incr goose::next_id
}

[Eloitor]

We also need syntax for place a new window on coordinades X, Y. And move a window to coordinates X, Y (with optional configurable animation).

[Eloitor]

We can take ideas for window placement from

https://blog.teclado.com/side-values-in-tkinters-pack-geometry-manager/

[blobject]

Excellent stuff. I say we aim for #12 (comment) as a minimal config and polish the syntax as we go.

Maybe we can start with a tcl (without tk) syntax. Still need to look at how to make tk minimally support wayland, whether it would be better to roll our own or to adopt a third-party project.

Tried compiling tinywl but it fails due to a deprecated renderer initialisating step. And it builds against wlroots 0.15. So I'll hunt for a more up-to-date project to use as a guide.

[Eloitor]

how to make tk minimally support wayland

Maybe we can see what undroidwish did... https://stackoverflow.com/a/48026908

[blobject]

Yes, will need to do some source diving there and see the least amount of work needed to get tk running natively. That project seems to bundle a version of the entire tcl environment, so I'll need to parse out just the parts we want. Hopefully, what we're trying to achieve with tk isn't as daunting as it first appears.

[Eloitor]

What about using Critcl?