Draft: Port demos to TypeScript

[vixalien]

This is my attempt to porting demos from javascript to workbench.

Groundwork

• All files were renamed from .js to .ts. I will be running the TypeScript compiler (with tsc) to fix demo files as we go.
• I added a simple README.typescript.md showing basic instructions on how I generated the types
• I added a tsconfig.json file
• I compiled and included all the types in workbench-types

Future tasks

• Don't include all the typescript definitions here. They should probably live in another repo. They are only included here so that I can easily check the validity of the demos I have ported so far.
• Add a simple script that will generate the types for us. Probably similar to https://github.com/vixalien/gi-typescript-definitions/blob/main/generate_types_in_flatpak.sh
• Ensure CI is run for .ts files

Ported demos

• About Dialog
• Accessibility
• Account ⚠️
• Action Bar
• Actions
• Animation
• Audio
• Avatar ⚠️
• Banner
• Box
• Boxed Lists
• Breakpoints
• Button Row
• Button
• CSS Gradients
• Calendar
• Camera ⚠️
• Carousel
• Checkboxes
• Clamp
• Color Dialog ⚠️
• Color Picker ⚠️
• Column View ⚠️
• Context Menu
• Custom Widget
• Database ⚠️
• Dialog
• Drag and Drop ⚠️
• Drawing Area ⚠️
• Drop Down ⚠️
• Drop Zone ⚠️
• Email ⚠️
• Emoji Chooser
• Event Controllers
• File Monitor ⚠️
• Flow Box
• Font Dialog ⚠️
• Frame
• Gamepad
• Grid View
• Grid
• HTTP Image ⚠️
• HTTP Request ⚠️
• HTTP Server
• Image
• Label
• Launcher ⚠️
• Level Bars
• Link Button
• List Model
• List View
• List View with a Tree
• List View with Sections
• Location ⚠️
• Map
• Memory Monitor
• Menu Button
• Menu
• Message Dialogs ⚠️
• Navigation View
• Network Monitor
• Notification
• Open File ⚠️
• Overlay Split View
• Overlay
• Picture
• Popovers
• Power Profile Monitor
• Preferences Dialog
• Progress Bar
• Radio Buttons
• Revealer
• SVG
• Save File ⚠️
• Scale
• Screencast ⚠️
• Screenshot
• Scrolled Window
• Search
• Select Folder ⚠️
• Separator
• Session Monitor and Inhibit ⚠️
• Snapshot
• Source View
• Spell Checker
• Spin Button
• Spinner
• Stack
• Styling with CSS
• Switch
• Tab View
• Text Colors
• Text Fields
• Text View
• Toasts
• Toggle Button
• Tooltip
• Video
• View Switcher
• Wallpaper ⚠️
• Web View
• WebSocket Client
• Welcome

[vixalien]

To work with this version of the demos while hacking on Workbench, you can bind mount it. For example,

sudo mount --bind /path/to/cloned/demos /path/to/Worbench

[vixalien]

Currently all the demos are ported 🥳. However, some demos have // @ts-expect-error directives where the types generated have some issue or another. I have tried to create relevant issues upstream and link to them, but a longer term strategy may be need.

Now it's time for rebase, and working on other steps.

[UrtsiSantsi]

@vixalien Why do you use get_object<Type>("name") in some places and get_object("name") as Type in others? Shouldn't we use get_object<Type>("name") everywhere?

[vixalien]

Yeah we should use that everywhere. I used the former method when I was getting started on this, since I didn't know the latter was possible.

[UrtsiSantsi]

I'll add a commit tomorrow, if you don't beat me to it.

[vixalien]

@sonnyp I have been brought to the attention of ts-blank-space which looks like it might be useful for getting reliable stack traces.

[UrtsiSantsi]

@vixalien I fixed all the places I could find, that were still not using the generic get_object. But I didn't test it 😅

[vixalien]

I had already pushed the changes and you force pushed the branch 🙈🙊

[UrtsiSantsi]

@vixalien I didn't do a force push. According to GitHub I added the commits - "UrtsiSantsi added 12 commits", "UrtsiSantsi added 28 commits", while when you force pushed earlier it is "vixalien force-pushed the wip/vixalien/typescript branch from e41f55e to aeea1bf".

My changes are on top of your changes - you fixed the case where the pattern get_object("name") as Type; was used, but missed the cases where get_object("name); was used without any type and that is what I fixed. Can you check again?

[vixalien]

but missed the cases where get_object("name); was used without any type and that is what I fixed.

Oh, I see. I actually left out those cases, but I was just being lazy 😆. Thanks!

I will need to rebase them so that we have a singular commit for each file. i.e. "port: Camera", "port: Welcome" etc... but don't worry about it.

I've also gone and enabled strict mode, which now causes a few more errors to pop in. You can run tsc in the root of the repo to see the issues.

[sonnyp]

@vixalien don't worry about commit history, I'll squash everything when merging

Individual commits won't be helpful.

[sonnyp]

Don't include all the typescript definitions here. They should probably live in another repo. They are only included here so that I can easily check the validity of the demos I have ported so far.

They should be in Workbench since that's the runtime.

Add a simple script that will generate the types for us. Probably similar to https://github.com/vixalien/gi-typescript-definitions/blob/main/generate_types_in_flatpak.sh

Ditto

Ensure CI is run for .ts files

👍

@sonnyp I have been brought to the attention of ts-blank-space which looks like it might be useful for getting reliable stack traces.

This looks interesting for “compiling” ts files before running.

But we still need a solution to compile ts files to js for humans.

[sonnyp]

But we still need a solution to compile ts files to js for humans.

Actually we could also use ts-blank-space and simplify process the result with prettier.

[UrtsiSantsi]

I think we should leave java script as a language option:

• It is shorter and simpler than type script, which is good for a demos
• Supporting both will require little effort

[vixalien]

They should be in Workbench since that's the runtime.

Add a simple script that will generate the types for us. Probably similar to vixalien/gi-typescript-definitions@main/generate_types_in_flatpak.sh

Ditto

Sure. I'll work on it next.

[sonnyp]

@UrtsiSantsi that's the idea 👍