Disappearing Disabled Prop Inspector? and other possible bug

[PaulDaMacMan]

Just started playing around with widgets... wasn't long before I hit a snag. After changing some Navbar widget properties (font-awesome icons) my Property Inspector stop showing up and can't select any controls. It's only when I have this particular stack open that this occurs. This stack is at my home and so I can't attach right now, but can anyone confirm any similar problems?

Can anyone tell me where it pulls font-awesome from... the web? What exact version of the font we are dealing with here? It doesn't appear to be the latest 4.3 version of the font/icons as some of the icons don't jive-up. Version 3.2 maybe?

And finally, when I try to print the card with this widget it results in instant crash.

I know it's early on in the LC 8 cycle but I did a check for a related bug reports and didn't find match.
Wondering if there will be another LiveCode "Jam" for 8.0x?

Mac OS X SnowLeopard 10.6.8
LC 8.0sp1

[PaulDaMacMan]

Here is the bad stack from my original post

[trevordevore]

@PaulDaMacMan - looks like the printing issue has been addressed internally.

https://github.com/runrev/livecode/comm ... 53532d4be0

[PaulDaMacMan]

@PaulDaMacMan - looks like the printing issue has been addressed internally.

https://github.com/runrev/livecode/comm ... 53532d4be0

Thanks for that. Though the printing issue was kind of an afterthought for me, I assumed it was due to the early build nature of the version I was trying. However, I find that solution less then optimal: "Widgets are rasterized to a screen-resolution image and then printed." That means you loose the vector paths of an SVG Based Icon or Canvas! Not very good when your goal is high-resolution printing.

[PaulDaMacMan]

"Widgets are rasterized to a screen-resolution image and then printed." That means you loose the vector paths of an SVG Based Icon or Canvas! Not very good when your goal is high-resolution printing.

Perhaps a setting/parameter could be added to allow higher-then screen-resolution (like "set the widgetCanvas to 300" -- as in 300dpi)

[LCMark]

@PaulDaMacMan: the rasterisation of widgets for printing is temporary (I figured printing something was better than nothing). We need to do some updates to the internal printing architecture to allow widgets to print with high-fidelity. I filed this after patching the crash: http://quality.runrev.com/show_bug.cgi?id=15133

[PaulDaMacMan]

Awesome!
As I said, I know it's early on in the LC8 dev cycle but I've been looking into the Skia rendering engine and I'm just so damn excited! I can't wait for Widgets & Open Language to mature! Looking forward to better/native sound/music capabilities in LC!

I see there are some updates to some widget things on git hub and I'm getting a little confused and have more questions:
I uninstalled "SVG Icon" to get ready to update it to the revised and more appropriately named "SVG Path" (as well as having inverting bug fix?),
and decided to test a SVG path based path animation stack I whipped up using SVG Icon's iconPath parameter WITHOUT having the widget I used installed and it still worked!

^So this mean widgets get embedded into a stack? ...or card? once they are placed?

^Then is there anyway of getting the original name or type /version number of the original widget from a widget placed on a card?

As mentioned in this forum, with the hopeful coming of the widget & library extension explosion about to take place,
there will have to be some very good widget management system in place!

[PaulDaMacMan]

^So this mean widgets get embedded into a stack? ...or card? once they are placed?

Actually took the time to read the builder guide!
"LiveCode saves this data along with instances of the widget in the stack file." (btw, there's a typo in the guide right before this)

Still the instances that are saved have no meta info about the original that the instance was created from attached to them.
Could it be possible to have say PaulsSuperGreatWidget v.1.0 AND PaulsSuperGreatWidget v2.0 in the same stack?

I know you brilliant LiveCode peoples are probably already on/or past this, but I thought I'd throw it out there anyway.

[trevordevore]

I don't know how to get the version of the widget, but you can check the "kind" property.

[PaulDaMacMan]

Yes, the "kind of me" returns the Reverse DNS of the widget (community.livecode.pgmcclernan.supergreatwidget), but "version of me" returns the engine version.
I believe I read somewhere that the meta system that is currently in place is only temporary and will be replaced in a later revision.
I guess for now I'll tack on the version number to the reverse DNS ID (community.livecode.pgmcclernan.supergreatwidget002)
It seems 8.0dp1 has trouble replacing an already installed version properly anyway (at least with libraries / icon.png have to quit and restart to check).

[LCMark]

Versioning is still a 'to be implemented' feature

When a widget is saved to a stackfile, it is saved with the array generated by OnSave and the full name of the widget 'type'. In a future iteration, it will also save along with it the version of widget's module.

We still have yet to finalize the details, however one current option is that a widget will be able to implement multiple OnLoad handlers - one for each supported widget version. As a widget is entirely defined by its state returned by OnSave, a suitably implemented widget will be able to support older versions by implementing an OnLoad handler for a previous version of the widget's state structure.

[PaulDaMacMan]

Finally got around to posting a bug report for the stack in the original post.
Bug 15328 http://quality.runrev.com/show_bug.cgi?id=15328