Alpha 1.0 Release (Database Agnostic Spreadsheet Program)

[mathaou]

I've realized that I could turn the program into a database agnostic fully fledged spreadsheet program with about a months worth of work. Any features you'd like? Here's what I have planned:

• Edit cell
• Add row below/above
• Remove row below/above
• Add column left/right
• Remove column/right
• Macros? Need to think about which functions would be most helpful in which circumstances. Currency conversion or something maybe.
• Cell highlight/coloring
• Expand column to fill screen
• Serialize (this is going to be the hardest part because it's different for every database)
• Copy/paste (going to also be tricky to implement

That's all for Alpha 1.0 release

Need to think about input. I need text and dialog boxes, maybe some more fancy stuff, but having mouse / keyboard support for all of this is maybe kind of cluttered so maybe some kind of vim-esque structuring idk

PRs related to this effort welcome and suggestions / feedback appreciated!

[mathaou]

Edit cell and serialization were just added. Likely a first pass of both but they hold up pretty well with testing I've done. Up next is add remove row, raw SQL, and an expanded edit during selection mode!

[gedw99]

Awesone concept .

I think that you might want to consider using gio which is a 100% golang based gui that runs on web, desktop and mobile

It already has a lot of what you need for a spreadsheet.

[gedw99]

https://gioui.org/

start with this example 👍 . It’s a app scaffold: https://github.com/gioui/gio-example/tree/main/component

This example shows multiple tabs, which you will need: https://github.com/gioui/gio-example/tree/main/tabs

There is a list component that scrolls and a forms component .

you could easily extend the list component to make a Data Table widget which is really the missing but you need.

If you want some advice just ask.

[mathaou]

I've seen that library floating around, one of my favorites after Fyne.

This app was designed to run in a headless environment (I made it for work initially). I'm not sure how useful it would be to 180 pivot what I'm doing here to do a GUI, however. I've seen lots of SQLite GUIs, and making this app GUI based would require a complete overhaul in order to make it platform agnostic. It would honestly be easier to just build something from scratch.

That being said, if you want a challenge @gedw99, feel free to fork or open a PR or whatever. I started this project with 0 expectations and I have no idea if a GUI based off termdbms is needed/wanted in the world. Do you think there's a need for it?

I've just started on 0.7-alpha release. After I finish SQL querying and context dialogs for add/remove rows/columns or macros, I think I'll be ready for the final round of polish before 1.0-alpha. GUI for beta 1.0?

[gedw99]

There already is USQL

https://github.com/xo/usql

it’s a cli / tui for all databases . It supports about 20 db’s and is written in golang also.

I am personally more interested in gui tools that can express a database where users can work without a cli / tui and that run on web , desktop and mobile.

Why ?

Tooling is what your into and so am I. Can’t help it :)

but the tooling value chain is now moving higher up in the stack into Low Code sector where non devs can build a pretty decent web or mobile app with a developer only getting involved to tweak the hard bits.

It’s my own bias of course.

Gio is compelling for these tooling scenarios becaus it can run anyway and it’s pretty easy to build a Low Code like IDE on top of it .

The database editor is very easy to build on top.

that’s why I started to use gio on top of ent .

ent of course is semi low code. It’s basically hibernate for the golang community but better and you need to code gen. But it so close to billet proof that you could stick a Compiler as a Service layer on top of it with a gui and the Low Code user would have no des that it’s doing code generation under the hood .

Hope I am explaining myself well enough

[mathaou]

@gedw99 yeah you're explaining it fine. UI is a useful thing and I'll keep it in mind if I want to expand this.

That other project may be very powerful and feature rich but it looks kind of horrible. The whole reason I love @meowgorithm libraries is because it makes using the terminal feel good. UI/UX is important no matter the medium.

[gedw99]

Yeah usql is not as complete as yours .

[gedw99]

Hey @mathaou Are you still planning on making this into a quasi spreadsheet ?

I think the hardest part would be a datalog / prolog like aspect, where changing a value in one cell causes other functions and cells to update ?

http://www.j-paine.org/compiling_spreadsheets_to_prolog.html explains the logic of this concept.

[mathaou]

Hey @mathaou Are you still planning on making this into a quasi spreadsheet ?

I think the hardest part would be a datalog / prolog like aspect, where changing a value in one cell causes other functions and cells to update ?

http://www.j-paine.org/compiling_spreadsheets_to_prolog.html explains the logic of this concept.

Thanks for the info. Yeah after learning more go and realizing mistakes I made along the way, I need to basically rewrite good portions of the backend to support things like that and also support line wrapping among other things.

Basically there needs to be a shim between the data layer and presentation layer, and the buffer of what gets displayed on the screen needs to be a single array. Implementing functions for cells should be fairly easy, but I would need to think about if those functions should be preset or I have functionality to write your own functions.

So I'm currently in the rearchitecture phase rn, but I'm also very strapped for time so the rewrite is a 2022 goal. Forks + PRs appreciated.