Journal notes - tremho/thunderbolt-common GitHub Wiki

last bits from tbTest journal:

• √ tool and indicator extensions
  • type property -> createExtensionType: invokes new type from mapped name. Right now extensionTypes only contains Example => "ExampleIndicator"
  • extension is an extension of ToolExtension. LC event calls for setToPage, stateChange, press, release. consider interface instead.
  • √ registerToolExtension(name, module) -- So Cool. This works.
    
    • √ but I wonder if we shouldn't send toolInfo instead of component, or both?
    • ◊ would still be nice to have an interface: Declarations!

---

I should set up a project and wiki on Github and use that instead of this for these notes.

• Back Extensions
  • registered in appBack with registerExtensionModule(name, module)
  • called via extApi from front by name and args (w/promise return)
• target SCSS and emSize
• clean (remove riot files, app.scss, and .gen) OR:
  • √ is is possible to reposition all these files into .gen in the first place?
    • uh, yeah. we would need to change PageWriterNS to output to .gen/pages instead of pages.
    • then register components from .gen/pages instead of pages is all
    • and index.html would need to change the stylesheet href to ./.gen/app.css and
    • the build would need to change compileCSS so it creates it there.

So nothing metioned above got started. Actually, that's not true. I did reposition all the generated files to .gen, so that's cool and much cleaner. No need for a 'clean'.

I ran into Nativescript hell when I accidentally nuked my environment variables trying to set up an unrelated path. Then I realized I needed to. update the Android SDK anyway because I was getting warnings about it being outdated, but when I went to do that I learned that the upstream open source project Homebrew links to is discontinued, so no update anyway. The SDK manager wasn't working at all. So I nuked the whole thing and installed Android Studio and set that up with the proper environment vars, etc. and was set to be good to go.

But then I ran into another really weird problem with js_parser.js failing in Generate Static Bindings, so android wouldn't run. iOS would. I found the problem was a failure to parse catch { statements and hacked my way around it in despair and horror, and got it sort of working again (but at such a heavy burden).

But then I found that things weren't coming across from the tens-template properly for some reason. I finally realized that my CLI scripts for ExportNS are calling 'tns' instead of 'ns' and that was the cause... of all of it!!!

So late at night, I am finally ready to look at the responsive refactor for the menu bar. Dusted off the resize event message stuff we had originally, but it won't suffice. See the notes in the new cards.

I've traded whining for wining. Got the 'h' out of there.

I got a response event for changing the class in Mobile. So that rocks. And it was relatively simple. But I'm still buggered by the inability to change the height of the title bar. What the hell controls this?

This is getting on my nerves. Since I have the trigger working, the next step is to take the shot, but I can't because my shot is blinded by a truncated height.

Too much wine, and more to the point too much whining from those who wish me to stop working.

Hallelujah! I've finally gotten past the {N} SCSS hell and have a true responsive action now.

Lots of nasty weirdness in {N} to fight with:

• inconsistencies between iOS and Android (toolbar) about grid cells with size or wrappers and not.
• Fine tune on how to define .constrained, .tiny, and .small
• Need to eliminate prior children (except the content)
• probably some stuff I'm forgetting in here too

What this will accomplish:

• can make edits to tbTest code itself without a rebuild of Nativescript target
• should be quasi-acceptable for hot updates
• Will only do create if needed
• Will do doctor after create
  • look at doctor output for problems
• Will error out on a problem
• Will provide feedback and next steps

This shouldn't be rocket science; it's just a can that's been kicked down the road too long now.

Hasn't really been an annoyance yet, but I need to get these things cleaned up as I go instead of at the end where there will likely be problems.

Minor, but a worthwhile task.

are a good next step given our recent attention to menu

When we get to this point, we've earned a milestone marker.

Okay. Got some stuff done. Lots of little improvements. Feeling pretty good about it all.

Currently looking at making consistent behaving basic layouts. See Layouts and Properties page for this.

Got all the basic layout containers done. Just need to finish off some related icing tasks. Have some cards in queue for improving the build chain a little and testing/tweaking some property support.

Then I need to get to the perennially outstanding tasks of log support and i18n, icons and assets, and the init and doc cli support features.

Going to need to start thinking forward to Alcaeus and WFD design and starts.

This journal has been neglected of late, and that's okay (it's a good thing). But I wanted to relate my frustration with fonts here. I started with the assumption I could treat a change in font-family the same as all the other properties I've been giving API access to. But as it turns out, (surprise?) Nativescript doesn't honor any of these properties. From what I can tell, the only way to change a font in Nativescript is by a CSS class.
So I had to comprise a scheme that formalizes a font name into a class of a similarly decorated name. So you can set this class, or set the "font-name" attribute and get the new font. I already dealt with the issue of adding your own fonts, and using @font-face declarations for Electron and moving font files to the font folder for Nativescript.
Now I think I have a solution and am ready to document it.

It's not a horrible solution, but for some reason, I chafed against it and had to go to a Plan C attempt before I found something practical.

Cest La Vie.