I would just say thanks this was sooooooo needed and maybe, finally, hopefully the developers mad about Silverlight being 86'd will say wow, we have a jump on a plaform XAML that we will soon be able to really cross platform roll on. It seems no matter what venue I some how fall into their is some developer still with a grudge they spent all that time learning SIlverlight and it was just taken away from them or not supported as they wanted. Then you have the developers with the fool me once shame on you attitude and have been afraid to commit to learning new tech from Mr. Softy becuase lkie Silverlight it might be waisted time. I think maybe it was not only waisted time guys and in my opinion MSFT is cool as heck again. Man they are on a magical roll. Lovin' this one XAML idea i cannot thank you enough. Hopefully the one this and that will continue to expand to VR and Streamer to use as a base camp. No issue just thanks.
codin4mrsoftytheybecoolnow opened this issue · 13 comments
Thank you for contributing to XAML Standard! We are at the very early stages of a long term collaboration towards a unified XAML vocabulary that all XAML developers can comfortably rely on to target all your desired end points.
All submissions
- Have you read the principles?
- Have you checked that your post fits the nature of proposals?
- Have you checked to ensure that there aren't other open issues for the same topic?
- Have you followed the contributor code of conduct?
If you are posting an API for XAML standard consideration:
- Add a brief overview of what you are proposing and why it belongs in XAML Standard (in keeping with the principles of the effort).
- Provide a clear usecase/scenario that describes how this API benefits in sharing cross-platform UI code, preferably a scenario from your experience or application that clearly illustrates why a control/API would benefit from being standardized.
- Add a brief example in XAML syntax for your proposal.
- Provide links to issues/discussions where this proposal has been talked about as well as any other pointer to where this originated or got discussed that could describe the motivation.
For discussions that are not concrete proposals, please prefix title with "Discussion" so we can categorize accordingly.
I think if you can match the Silverlight Namespaces and do not forget about the EFFECTS.
i= this. Resources [testcolor] as ImageBrush;
testnameeffect.testsomethingerffect h = new testnameeffect.testsomethingerffect();i
h.lighttonetester = i;
and so on ...........
Thanks for whatever you can do but the more Silverlight similar the better in my opinion.
but the more Silverlight similar the better in my opinion
Let's match that up to @markrendle's Scale of Seething Silverlight Stew:
How angry are you about Silverlight, five years on?
- Really angry.
- Really, really angry.
- I am consumed with hatred and poisoned by regret.
- Meh, I'm over it. LOL NOT REALLY I'M STILL SPITTING CHIPS.
!!! can you rename the title of this one? too long
What's wrong with a little character, @birbilis??? 😆 😆 😆
the problem is in this view
https://github.com/Microsoft/xaml-standard/issues
I'd expect GitHub to trim long titles there, but it doesn't
not even sure if this was done on purpose, or just typed in the issue body text in the issue title field by mistake
think if you can match the Silverlight Namespaces and do not forget about the EFFECTS.
Why would you want a new specification to be limited / defined by a dead technology? If there are specific features you want that silverlight had why not suggest them as single actionable items?
Also is you want effects suggest it as its own issue but bear in mind this stuff need to run on multiple platforms and look native on each.
Effects would be done with shaders probably. Any platform that can't support them, well not support it. Can't spec the least common denominator
Windows uses DirectX shaders everyone else opengl. Silverlight avoided this problem by doing it in software which is a horrible performing solution - especially on mobile hardware. But we really should be discussing that in a specific Effects issues. Anything in this generic off topic issue probably won't be seen.
if the issue here is effects in the standard, please create a proper issue asking for effect support. I would also suggest adding in what effects you feel are needed (those may want to be broken out into individual asks as well).
Thanks everyone
One effect would not be appropriate as I was generalizing. Since 90% of all applications use something that could be considered "effects" via some route java, css, html 5, flash even if just changing a color in the code behind that the point of the reference to Silverlight was missed. I though the intention was to make Universal XAML a complete solution and that would mean being able to use the Asset button in Blend and adding quick behaviors to ONE XAML in an app targeted towards Windows, IOS & Android with the same code. I may have picked the wrong venue and maybe I should talk to MSFT direct. There have been a lot of promises along the line in regards to Visual Studio and specifically adding Effects with XAML and anyone that was used to using the Asset feature in Blend with Silverlight misses it. Who would not want a one button click to assets to add effects with the click of a button via behaviors like in Silverlight? Blend still has it, there are just no MSFT behaviors or way too limited. The shader effects could be combined in a lot of ways even removing backgrounds out of jpg's on loads etc.
Sure there are a million things out there to use to do all of it. Maybe I have not discovered what the advantage of using one XAML is yet if it will always be graphically limited.
If MSFT had a way to let users use Visual Studio (Blend) with ONE XAML and it could do everything Java, Flash ...... could do and create UWP apps for Cross-Platform IOS, Android & Windows they would have every developer in the World using them and laughing at everything else. It would end having to use everything and the kitchen sink to create a modern day app that is "THE BEST". The Asset Behaviors is just the easy button.
Did not mean to post this in the wrong place, just not sure you understood my point.
What type of apps is XAML intended to create if not the kind like you see people with modern UI's? You cannot do that without effects.
I though the intention was to make Universal XAML a complete solution and that would mean being able to use the Asset button in Blend and adding quick behaviors to ONE XAML in an app targeted towards Windows, IOS & Android with the same code
Read the FAQ. That isn't the intention. What you want is Xamarin.Forms - It does exactly that today.
What the standard tries to do is bring some consistency between UWP and Forms, so that things aren't too jarring when switching between developing for the different platforms. For instance from your whining it you sounds like you have a Silverlight background , so if you want to pick up Xamarin.Forms tomorrow and build a cross-platform app, I guarantee that you would be swearing at all the little senseless naming changes they have. The standard wants to remove all that swearing and make it easy for you to move your skills and knowledge over.
create a modern day app that is "THE BEST".
No one has ever created a cross-platform UI that creates "THE BEST" apps. "THE BEST" apps are the ones that are tailored to the individual platforms, takes full advantage of each platforms capabilities and looks like it's native to that platform. Xamarin.Forms gets pretty close, but most serious apps wish a larger budget generally shun Forms, and just use Xamarin on top of the native UI layers. That's not to say Forms isn't useful - they are usually just better fit for quick simpler apps on a lower budget, and many B2B apps doesn't care too much about feeling perfectly native - they just need something that works quick.
Silverlight 5 supported shaders from what I remember. Btw, effects are described (eg if there is a list of predefined ones) in high level and platforms implement or skip them.
Shaders also can be transpiled or defined at higher level language, even C# via some constrained vector-based API interface if needed. Not sure if that low level access is asked for, would be nice though.
Think Compositing API of UWP is useful to have, not sure if it affects xaml syntax though