PowerUI - Powerful HTML/CSS UI Framework

Spark 2 is making it's way into PowerUI! The true beginning of PowerUI 2, this, in short, means PowerUI's CSS coverage is about to shoot up without affecting overall performance - The whole system is also modular so you can simply delete stuff that you don't want or need, or extend your CSS with new inventive ideas. This will also be ironing out inconsistencies too such as border-top-left-radius or the rgb()/ rgba() differences. We're intending on it being fully backwards compatible so no large scale changes will be needed.

In another note, this has been blocking up our internal SVN all day so WP8 will get tested shortly after Spark 2 is ready. PowerUI 1.8 and 1.9.x (x<118) work on WP8 without issues; it appears to be just the latest 1.9.118 package that is affected.

 

I tried 1_8, 1__9_94, and 1_9_118. I tried building for WP8, WP8.1, Windows Store 8, Windows Store 8.1. The Nitrocode could not be found issue is present in all but WP8 builds using the 1_8 package for me personally. But even on that build, all the example apps (even just a hello world test app I created) all crash on startup on a Lumia 1020 (running WP 8.1). Not getting past the splash screen on any of them. I couldn't imagine why a perfectly clean, new project would do that on the newest update of Unity. Everything plays on the Unity editor, no problem. Builds are an entirely different story. Emailed support yesterday.

 

Have you got those two boxes checked in the nitro settings? Due to how Unity works, they can become unchecked if you change build settings - unchecking and rechecking them can also make a difference if Unity cached something incorrectly. 1.8 and 1.9.94 certainly work in WP8 as they've both been tested on a device (also a Nokia Lumia, not sure which particular model though)

 

I've been good about keeping those two boxes checked now. I get the Nitro could not be found issue is almost all cases. But when I happen to build, which was only on 1_8, my builds (your examples, and a hello world test) both crashed on startup. I have not gotten a Windows Store (Windows 8) app to build at all. I was looking to use this for Windows mobile and for Windows 8/8.1 proper.

 

I've been on W8 for the last 50 minutes or so and 1.8 and 1.9.94 build Windows Store fine (edit: 1.9.118 does have an issue with the file:// protocol as suggested earlier; that file can just be deleted) - the only way I can repeat that issue is by not having the bottom checkbox ticked? Presumably the Nitro not found error you mean is coming from UICode.cs - that for sure is resolved by making sure the box is ticked; The checkbox adds NoNitroRuntime as a build flag and moves the Nitro source (and if you take a look in UICode.cs, there's an explicit NoNitroRuntime check around the line which you're probably seeing the message coming from). I'm testing in a blank project with nothing else but PowerUI in there too.

 

I'll have to post some screenshots for you. Both boxes were ticked in all cases. I tend to double check that they still are. I'll try on a different PC, different build of unity.

 

Any notes on what would cause the crash on start: Info Below.....

First-chance exception at 0x76EF2F71 in Template.exe: Microsoft C++ exception: Platform::COMException ^ at memory location 0x08A4E6E0. HRESULT:0x80131534 The text associated with this error code could not be found.

WinRT information: System.TypeInitializationException: The type initializer for 'WinRTBridge.WinRTBridge' threw an exception. ---> System.TypeInitializationException: The type initializer for 'WinRTBridge.TypeInformation' threw an exception. ---> System.IO.FileNotFoundException: Could not load file or assembly '1196-9192815865354396745.ntro, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.

at UnityEngineInternal.BootstrapHelpers.FillTypeMaps(Dict

If there is a handler for this exception, the program may be safely continued.

 

Failed to mention, within Unity there is an assembly warning for each and every demo example. Not an error, but a warning, so I can compile just fine. Unsurprisingly this would correspond to what is causing the crash on app start once I deploy the visual studio solution, as it's telling me that some assembly file with the ending .ntro could not be found or loaded. I don't want to give up. There has to be a fix for this if others are able to actually deploy WP8 PowerUI apps to their devices in visual studio. There is nothing special about my setup. Import Power UI, check the two nitro settings boxes, compile to WP8, run the solution in visual studio. Crash. For Windows 8, rinse and repeat. Im at a loss.

 

The C++ mention looks like it could possibly be the culprit - Unity and Microsoft both recommend using a C# solution when compiling for W8/ WP8 rather than a C++ one, and as a result we test using the C# solution mode. In the build platform selection window, with W8 selected, there's a dropdown for solution type - make sure that's on C# and you should hopefully get a better outcome

 

Update on Spark 2: So far Spark 2 has been wonderfully successful with PowerUI's CSS engine gaining more than 50 new features already and better standards compliance too! :before, :after, a whole sleuth of new units, calc(), attr() and more are all now within PowerUI 2. An early access package will get put up on the My PowerUI page fairly soon (a message will get dropped here when it goes up). This is by far the biggest change ever made to PowerUI (and we've made some massive ones in the past!) so we would really appreciate anybody willing to help out with testing - Thank you!

 

It is, in fact, a c# solution. Always has been since I first downloaded the asset. No matter what, all windows solutions, whether WP8, 8.1 or windows store solutions will deploy but crash on start. They are all set to a c# solution in the build window.

 

Hmm right ok, I've never managed to get it to crash on startup/ heard of it doing so before so I'd need a lot more information to be able to probe it properly - I think the easiest thing though is just avoid Nitro as it's completely optional anyway; Write any functionality in e.g. C# and use direct C# calls ( onmousedown='ACsharpClass.AStaticCSharpMethod' ) - a few of the example scenes do this, and there's one specifically for this feature

P.s. the My PowerUI page has an updated 1.9.118 which doesn't throw any build errors on W8

 

The WP8 exception thrown in Visual Studio using the 1.9.94 build. The same start menu crashing. I'll try the new 1.9.118. On another note, the 1.8 just works on WP8. I haven't had the crashing problems when trying it again but it seems rather limited compared to 1.9, not recognizing css floats and that sort of thing.

{System.TypeInitializationException: The type initializer for 'WinRTBridge.WinRTBridge' threw an exception. ---> System.TypeInitializationException: The type initializer for 'WinRTBridge.TypeInformation' threw an exception. ---> System.IO.FileNotFoundException: Could not load file or assembly '1196-9192815865354396745.ntro, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
at UnityEngineInternal.BootstrapHelpers.FillTypeMaps(Dictionary`2& typeToTypeIdMap, List`1& typeIdToTypeMap)
at WinRTBridge.TypeInformation..cctor()
--- End of inner exception stack trace ---
at WinRTBridge.TypeInformation..ctor()
at WinRTBridge.WinRTBridge..cctor()
--- End of inner exception stack trace ---}

 

Even when you leave the nitro language out of the scripts, any of the 1.9 versions are a no-go on windows for me. period. Just tried it.

 

You've probably still got some compiled DLL's in the project - i.e. the DLL's that it's saying it can't find for some reason - either uncheck the precompile nitro setting (which will hunt them down and delete them), or look for any .ntro.dll files within the example scenes. That's really interesting that you can get it working with 1.8 though - that would suggest that there is something hanging around in 1.9 that has gotta go rather than some obscure setting somewhere. 1.9 is significantly better than 1.8 for sure (and PowerUI 2 is better than 1.9!) so it's a big shame it's not working for you - I've been trying to figure out what could possibly be causing it but it doesn't seem to want to repeat here at all; also the kind of odd thing is I'm 99.9% certain that the precompile system didn't change from 1.8->1.9

 

would it be possible to ask for a check box on an updated version that allows all the nitro stuff to be completely turned off for those who are going straight c# or javascript. I'm thinking maybe that could eliminate my issue or anyone else in the windows world that runs into my problem. Because turning off the precompile nitro boxes just introduced more issues for me. It wouldnt build at all after doing that. And there's no .ntro dlls anywhere as far as I can see in this hello world test I just created. Im stumped and I know you've been trying to help. I just want the next versions to be compatible or i'll be stuck using the 1.8.

 

That's exactly what the "No Nitro Runtime" checkbox does On W8 it has to be checked at all times because W8 does not support compiling Nitro at runtime. Instead, it gets compiled in the Editor, becoming any ordinary .NET DLL, and then it's as if it was written in C#. At that point it's as if Nitro doesn't exist at all from PowerUI's point of view. To stop using Nitro, simply check the bottom one at least, and make sure you don't have any Nitro in the html files that you use.

 

Awesome milestone has just been passed - Spark 2 is now bringing an enormous 110+ new CSS features to PowerUI! That makes it the first update to single handledly double PowerUI's CSS coverage. It's genuinely bonkers but we're loving it and we know you will too!

@keyframes, calc(), box-sizing, ::before and so much more. See http://powerui.kulestar.com/css for what's new in nightly, and what will be coming soon - An early version will be getting dropped on My PowerUI when at least the core of Spark 2 stabilizes fully. Thanks for your support!

 

There goes another milestone - We're now at 150 new features including the HTML5 fullscreen API, generic event listeners (addEventListener etc), full selector coverage and as a nice bit on the side, some CSS selector level 4 ("CSS4".. sort of) features too!

Still in the queue: flexbox and possibly CSS grid (would anybody find either useful?)

As mentioned earlier, much of the new functionality added over the last week can simply be removed by deleting their files from the source so you don't need to worry about bloat or performance impacts.

 

How do you set up your styles (or through c# scripts) so that you don't have smallish menus and graphics on high resolution screens and way too huge graphics on low resolution screens. Is there a way to achieve a nice balance whether you are scaling up or down? On mobile web, I would do this with breakpoints. I haven't played with the PowerUI resolution bits yet.

 

You don't actually need to do anything to the styles - just set UI.Resolution and it will scale accordingly. The most common approach is to design a UI at a reference size, then simply set UI.Resolution using the current screen dimensions and your reference size. This help guide (getting started #9) describes UI.Resolution in a little more detail

 

Thanks. That's powerful. I'm assuming the common method is to use the UnityEngine Screen classes to get resolution and then use UI.Resolution to scale since on Android and WP there's more variety as opposed to say on ios, where you can actually check for the specific device types since there aren't a ton of distinct devices.

 

Yep that's right - PowerUI 1.9+ also has a handy DesignSize class which makes that common use case simpler too, with usage like this:

UI.Resolution=new ResolutionInfo( new DesignSize( 1920 , 1080 ) );

With the size given being the one you use during development (you can pass DPI as well if your development environment isn't 72dpi); everything else will scale relative to that

 

This might be a dumb question, but what if I need to use 4f to get double the size of the pixels on a device. Does that mean it's a DPI thing? In the Unity editor, 2f does what I would think it would. On the Lumia 1020, 2f is barely noticeable and 4f results in what appears to be double the size. But 4f in the unity editor of course look outrageous. Am I missing something here?

Edit: hmmmm, it seems like using the Designinfo results in a much much smaller pixels. Using 2f, 4f, etc... is not making a difference at all. I don't think it's triggering anything.

 

Yep, that's a DPI thing - to correctly scale a UI for a particular screen, the DPI must be considered too. Common desktop DPI is 72, whilst mobile phones are often in the 120+ zone (i.e. twice as many pixels per inch than a desktop). The DesignSize class essentially figures out that scale factor by comparing inch sizes rather than pixel sizes

 

I tried UI.Resolution=new ResolutionInfo( new DesignSize( 1376 , 768 ) ); and my menu buttons could only be tapped with a needle. Everything got infinitely small

I did some debugging and Unity is reporting the phone has the correct screen resolution being sent out so I don't think that's the issue.

 

WOW....nevermind. The inspector value overrides whatever you put in the script (for the simpleresolution variable). I'll use the new ResolutionInfo method with the float. Thats working well for me now...

 

Are input (type=range) html5 sliders supported?

 

Not directly, but there's a few implementations around (including some built on top of horizontal scrollbars, i.e. input type='hscroll'), like this one

 

Thanks for the resource.

 

How do you quickly swap out one image for another using "src." ? I see many attributes in the element class but I don't see any way to change the src attribute of an image.

Edit: got it, Element[src] = "mypic";

 

Yep looks like you got it In Nitro it's either element["src"] or element.src too, and PowerUI 2 also supports the standard getAttribute etc functions (which just directly map to element[attribute]).

 

I've hidden an element using the style.visibility="hidden"; and it still accepts touches even though its hidden. How do I disable touches on that element, and then re-enable touches on it when ready for it to accept touches again?

 

Depending on what your flow is like (i.e. if you need that hidden element to still take up space or not), display="none"; is a more popular approach which also disables touch (as well as being a tiny bit better performing). Alternatively a simple trick is to set the opacity to 0 too I believe (.opacity="0"; ) and back to 1 when you're done - I'll double check

 

The support you guys provide is unmatched! I appreciate that. display=none did it.

 

No problem According to the CSS specs visibility:hidden shouldn't trigger clicks at all so a small check just got added to the PowerUI source - visibility="hidden"; in all future versions of PowerUI (1.9.120+) is no longer clickable

Anybody interested:

- PowerUI/Source/Engine/Element/Element-Click.cs
- Find "RunClick" method
- Right at the top you'll see a return false; if DisplayType is none:

Code (csharp):

1.  
2. if(Handler.IgnoreClick || Style.Computed.Display==DisplayType.None){
3.          return false;
4.        }
5.  
6.  

Add visibility there like so:

Code (csharp):

1.  
2. if(Handler.IgnoreClick || Style.Computed.Display==DisplayType.None || Style.Computed.Visibility==VisibilityType.Hidden){
3.          return false;
4. }
5.  

Tada

 

hmm....when I set display=none and then when I set it back to some other display style like "inherit", my element fails to become reenabled. It's as if it permanently dissappears. Let me try opacity =0.

Edit: opacity 0 is accepting triggers.

 

Display is not inheritable Try just a blank string/null (which will restore the default), "block" "inline", "inline-block" etc

 

I tried "", "Block", none of those are restoring the element.

Well, "block" works

It would seem thats maybe a bug. I anticipated the null string setting the element back to default would be the expected functionality. Because this is sort of a hack, the element wasn't initially set to block.

 

Display is used lots so it sounds like you might be changing it on the wrong element? It's also a lowercase B - "block" in CSS http://www.w3schools.com/cssref/pr_class_display.asp

 

Interestingly it seems Google Chrome is now doing what we did, but in reverse! Nitro in PowerUI is typed Javascript, which is almost identical to Microsoft's "TypeScript". Chrome V8 has recently started implementing their own variant of TypeScript, which their calling "SoundScript".

So, Chrome started with traditional JS and is adding types; Meanwhile we started with typed JS and are removing them to get to traditional JS. It get's interesting when you consider what Nitro used to be called when it was first built - yep, that's right, Nitro was called "SoundScript" It was called SoundScript because of it's original use with audio synthesis, and got renamed when we wanted to use the same engine for both audio synthesis and PowerUI. "Nitro" seemed like a nice generic name that covered both. Is there a relationship in the Chrome naming decision? Who knows! After all, their reasoning for picking the name is a little odd - Food for thought though I guess

 

GPU accelerated text rendering

Hello everybody! We're currently in the process of GPU accelerating all the behind the scenes signed distance field generating process. This is expected to address a few quality concerns, boost speed a little and also introduce some unique functionality too. As far as we're aware, text rendering has never been done this way before, so we're breaking some exciting new ground!



This new rendering mode is going into 1.9 and will be available for all Unity 5 users and Unity Pro users pre Unity 5. As usual we can't wait to unveil this to you guys shortly!

 

Another view of the new GPU text rendering system - it's a little tight in places, but it's not far off! In short, it can render around 50 signed distance fields in parallel (one for each character) and the results get transferred over to an atlas. From there, the existing SDF shader takes over. Distance fields are traditionally intense to compute, but our method makes it as trivial as rendering some triangles!

 

Is there anything special that needs to be done to get the nitro settings window to show up on a mac. I have PowerUI installed in a project, but the Window -> Tools -> NitroSettings is missing. So, I'm unable to change the settings. Any workarounds? I already tried reimporting the powerui package with no success. The window is still missing.

 

I've never heard of that happening before - it's just an ordinary editor script. Maybe you're looking in the wrong spot? It lists under Window -> PowerUI -> Nitro Settings. Can you see the other windows like emoji/ about/ auto translate etc?

 

Hi Kulestar, I would love to see you officially support this. Video support within Unity is very limited, if you in any way think PowerUI framework is a good solution to this problem then I would recommend that you reply to the various posts that ask about this feature, it's something people are very unaware of and google searches turn up no solutions to this problem (and none of them link here). If you look at the Video section of the Unity Asset store you'll see that it's incredibly limited and not supported well, this might be an opportunity for you to become the standard.

 

Hey there,

Thanks for your input! Video is so awkward in the sense that most formats are covered in patents and decoders have to be written in managed .NET to get it working on all platforms in Unity too. We didn't get too much of a response about WebM so it's pretty low priority at the moment (e.g. people would rather we spend the time on the much more requested PowerUI 2 instead), but it will certainly be getting worked on in the future as it's both fun and WebM is great all round so we've got plans for using it on some of our projects. I would imagine that lack of response is more because people just aren't aware we're working on it so like you say there's probably quite a few people out there who would find it useful.

For anybody wondering, the WebM extension is called "Super8" and it will be available free to anybody who has PowerUI hooking straight into the <video> tag, and also as a standalone asset too. It's a big project so if you would find it useful please let us know and that'll raise it's priority a lot

 

Perhaps this has been asked before, but if I purchase PowerUI, will PowerUI 2 be an update or a new package that will need to be purchased?

Will the Super8 extension work with PowerUI 2?

 

It's a free update for anybody who already has any license of PowerUI http://powerui.kulestar.com/css/ gives a good idea of what's available in PowerUI 2 vs. 1.9, and http://powerui.kulestar.com/releases/ lists the changes.

All extensions will be ensured their compatible with 2, so yep it will be. 2 is also designed to be as backwards compatible as possible, so most custom extensions should be unchanged too.

The latest version of PowerUI is 1.9+GPU which is only available on the My PowerUI page (which is free to access for anybody with any license) and that's also where extensions/ other freebies can be found.

 

Hi,

I wonder is it compatible with Adobe Edge Animate?

Thanks