So I want to learn Uno, UX markup language, built in motion as well as how Fuse Tools handles shaders and thought I’d task myself with my first project a color picker. I have been dreaming up this color picker for a long time. Here is mockup of what I am trying to make:
And a live interactive version using JavaScript and SVG: Color Picker
The only thing not represented in this link is how the swatches get added. Each time you would click the + button, it would subdivide that top arc into smaller segments and store that through some sort of local storage.
What is the best way to tackle this? I don’t have C# for a background, so this is a stretch for me, but I have a weeks vacation to get me started… I do have AS3 as OOP language, so I am used to writing classes and strictly typing variables… so that doesnt scare me.
Ok, ran into my first snag. Tried to use a ux file to set up the circle primitives and almost immediately ran into a layout issue. I was trying to stack the circle on top of each other, but the second circle seems to either remove the first circle or push it off the canvas.
I wasn’t expecting the layering to be backwards from HTML. Although I always thought HTML was weird that the top most element wasn’t above everything else… Like Photoshop Layers panel.
Ok, I was looking at the TextureFill documentation, but the UX equivalent… I have no idea!
I would have guessed (Because of hinting and documentation) adding a path to the Texture attribute would have loaded an external asset: <Circle ux:Name="saturationLightness" Width="265" Height="265" Alignment="Center"> <TextureFill Texture="PATH_TO_ASSET.jpg"/> <SolidColor Color="0,0,1,1"/> </Circle>
But it requires a Texture2D object… I see no way of passing a new object via attributes though.
And it does seem to load something if I double click the .ux file from the project panel. BUT if I make any changes to the .ux file in sublime the refresh blows up and says: Uh oh! Looks like refresh document didnt go very well: Object type Uno.BudleFile cannot be converted to target type:Uno.Graphics.Texture2D.
(By the way it would be great if I could copy and paste that error text.)
Am I even going about this the right way? Is there a Drawing API I should be using or maybe I should be diving directly into Uno instead of .ux? I guess I feel like there is a lot I don’t understand about the .ux markup… at least as it pertains to what I am trying to build.
Maybe .ux is more for quickly wiring up classes to your application and writing an uno Class would be more suited to this kind of UI control?
I guess I am just looking for guidance on where to start first. I went through the tutorials already, but I am not sure where to go from there.
UX is primarily for doing the top level wiring of your app. However you can also use it for creating reusable controls. Depending on how much custom rendering/logic you need, you might have to add som Uno code.
For your gradient I would create a custom Brush class instead of using a texture. Not quite sure why you are getting that crash thuogh. Will investigate.
There are major changes coming to the Fuse tooling that will solve problems like copying errors etc. and generally make the experience much smoother. Basically the entire Fuse window will go away and be replaced by a daemon that lives in your system tray, and everything else happens in your text editor and in stand alone preview/tool windows (or directly on your device).
There is a team here working hard on a big batch of new examples and tutorials that will go along with this upcoming release. We will also release a few along the way.
That makes sense for the coding part… What about the design tools? Initially, in RealTime Studio there was a pretty cool round tripping between designers and developers.
It will make a lot more sense when you see it in action
Bridging the gap between designers and developers is the key to what we do. However we will rely more on third party tools like Sketch and Photoshop to do what they are already excellent at, and integrate well with these. We won’t neccessarily create something exactly like Realtime Studio again. Fuse will focus on the areas that are painful today, like turn-around time for layout, interaction and animation work.
As UX is a declarative document, it is easy to create artist-friendly tools with knobs, sliders and timelines on top of it later, so you can work visually with the content.
But - the infrastructure must be rock solid first, that’s why we are focusing on markup-based workflow for the next few iterations
I hope this doesn’t mean you are solely becoming just another development platform though…
One thing that drew me to the Flash Platform is, of course, it’s cross platform nature… which I believe you guys understand extremely well, but I also enjoy Flash Platform for its integration with Flash Professional for layout and animation.
Realtime Studio looked like it would have some of the major components of what made Flash Professional so great. For example a timeline for animations, layout tools for physically placing objects on the stage. And a panel for introspecting component parameters… (Similar to the way Realtime’s public variables were exposed for designer use.)
I guess, what I am getting at… its fine to rely on Photoshop and Sketch for element design and creation… but in terms of layout, wiring up an app and animating stuff. You really need a specialized app for that.
Sometimes its just easier to drag a Circle primitive into your app layout… tweak some setting, colors, textures and fills. Give it a name and start coding functionality than having to hand code every last detail. Especially when learning a brand new language or API. I don’t think that is designer specific. It helps developers speed some things along too.
For example a timeline for animations, layout tools for physically placing objects on the stage.
Yes - we are definitely planning to add this later We are designing all our frameworks and tools now to allow visual design tools to fit nicely on top. We just need to build the components in the right order.
Okay! That’s cool! I would have probably lost interest otherwise. My role is somewhere between design and development so I would feel naked without one or the other.
Elliot: I can assure you that we have not abandoned the designer friendly tooling at all. We’re just taking a different (and in our opinion) better approach to it. Instead of a monolithic app to “do it all”, we’re splitting things up in smaller, easier to develop (and maintain) parts.
