microsoft / xaml-standard

XAML Standard : a set of principles that drive XAML dialect alignment
Other
803 stars 50 forks source link

Please. Visual editor for XAML like to CorelDraw "Designer along with an interactive node based editor" #98

Open insinfo opened 7 years ago

insinfo commented 7 years ago

This is something that has been asking for a long time, please, it's past the time XAML has a complete visual editor, a decent Designer along with an interactive node based editor for animation, events and custom controls creation and realtime test and prototype

wysiwyg xaml prototype 2 wysiwyg xaml prototype 6 wysiwyg xaml prototype 5 wysiwyg xaml prototype 4 wysiwyg xaml prototype 3 wysiwyg xaml prototype 2

wysiwyg xaml prototype 1

wysiwyg xaml editor 3 wysiwyg xaml editor 2 wysiwyg xaml editor visual editor for xaml 3 visual editor for xaml 2 visual editor for xaml wysiwyg xaml prototype 12 wysiwyg xaml prototype 12 wysiwyg xaml prototype 11 wysiwyg xaml prototype 10 wysiwyg xaml prototype 9 wysiwyg xaml prototype 8 wysiwyg xaml prototype 7

birbilis commented 7 years ago

Blend was nice effort, wrong approach was to keep it separate from Visual Studio (see Expression Suite). Best is to have a Visual Studio personality (+ installer preset) for Designers (totally merge Blend in it). They could even use the Community Edition for free if they don't have access to higher version

insinfo commented 7 years ago

No doubt "Blend" was an excellent effort, but unfortunately "Blend" is not compatible with Xamarin.Forms, it would be great if you had a CorelDraw or Adobe XD-like editor to the point where you can create custom controls and styles graphically, Of beautiful animations, that is to create beautiful, fluid interfaces based on vectors for scheduling between several Devices in an easy and fast way, also for prototyping as for production

I think it would be great for developers if Xamarin adds a unified approach to multi-platform development, that is. "Write once and compile for various platforms without any code change", approach that Embarcadeiro follows, unfortunate to Embarcadeiro is sinning in several aspects; Such as the use of outdated language like Objective Pascal (Delphi) and C ++, not to mention that Embarcadeiro does not have a good IDE and does not have an XML-based language for defining the graphical interface. If Embarcadero places a language such as C # or Java in the Pipeline and an XML-based language for defining the graphical interface, the Embarcadero would be the best alternative for multi-platform development

Mike-E-angelo commented 7 years ago

Yeah, this whole "reinvent yet another entire wheel" business thing with Blend... 😛

insinfo commented 7 years ago

Sometimes it is necessary to reinvent the wheel, to have a revolution or a true evolution

Mike-E-angelo commented 7 years ago

Sure @insinfo. I think Visual Studio Code is a good example of this. However, Blend did not require a completely new IDE. It simply could have created a new IDE out of the existing Visual Studio Shell infrastructure at the time: https://msdn.microsoft.com/en-us/library/bb129445.aspx

insinfo commented 7 years ago

@Mike-EEE If I understood, It would be fantastic for Microsoft to integrate a Designer into the Visual Studio Code, but I find it virtually impossible for Microsoft to do so as this would weaken Visual Studio Enterprise

mossyblog commented 7 years ago

If you look at SketchApp and Adobe XD whats occurring is Adobe's blatantly ripping them off. Product skirmishes aside (cause i dont care), what appeals to me is the ability that these folks share the same attitude towards Symbol creations are an opportunity to export packets of XAML. The other key ingredient here is the styles engine(s) that are built within these tools enforce the notion of "reusability" - everything from Font settings, Border brushes, Foreground brush, Color Palette and so on.

Ideally what you'd want to do is create a vocabulary that defines common "resources" that are then aggregated together to define a "symbol brush". The symbol brush then defines the behaviour of the elements inline.

http://imgur.com/a/8MJsY

The above shows a rectangle with different "fade" techniques applied to give it that spider silk effect. This is essentially just a series of "borders" stacked ontop of each other with different "spacing/gap" applied alongside "opacity". The tooling today can cover this easily enough and asking a "designer" to adopt a Microsoft tool has not only never worked but a source of agitation for the adoption of WPF/Silverlight/UWP etc.

Instead the above can be achieved if the tooling has discrete "Export" capabilities that can be merged into the XAML platform/tooling pipeline. Key here is to not drag people kicking and screaming into the implementation of XAML but enable the providers who make such platforms/tools to have an agreed "contract" on how they can both retrofit their tooling and move towards accepting the standard.

insinfo commented 7 years ago

@Mossyblog Yes it would be wonderful if Adobe XD, Sketch or CorelDraw among others had an XAML export option. It would be up to Microsoft to partner with Adobe for this, but on the other hand you can aver a Microsoft Graphical Interface Desgin application that imports UI design of prototyping software like Adobe XD, who knows now XAML being an open standard to Community as a whole strengthens XAML and force these companies to implement XAML export plugins or even base their UI design entirely on XAML, plus in (Developers) we can encourage companies like Google, Apple etc. to use XAML. Making our voice heard through communities, forums, events etc.

mossyblog commented 7 years ago

First stage is to rebuild trust with xaml .. "we mean you no harm here is our open dialog with your tools of choice" and show xaml

Next stage is how to entice and illustrate how the existing tooling providers If invested can generate more pull through in sales acquisition

I think Microsoft story should and only be the integration editor .. like Unity3d .. use your design tools of choice to create and we support them to get you back to xaml middle ground but we only allow tweaks and minor changes in that creation pipeline.

It's simply way too expensive to fight the entire design tooling pipeline while also trying to regenerate a rebirth in developer ide etc support + platform / framework implementation.

That was the ultimate mistake we made with Expression suite believing he warchest was big enough to take on those juggernauts and innovate a pipeline at the same time .. too many fires to fight

birbilis commented 7 years ago

actually there is an exporter to XAML from Illustrator http://www.mikeswanson.com/xamlexport/ http://www.mikeswanson.com/xamlexport/eye%20candy.htm

have used it (with minor tweaking of output with injection of a Viewbox in it) with both WPF and Silverlight

such exports are a bit verbose (path oriented usually), but they do the job

birbilis commented 7 years ago

btw, recent versions of Blend have come closer to Visual Studio I think (probably already using VSX internally). And vice-versa VS is re-using Blend code I think in WPF designer

insinfo commented 7 years ago

@birbilis If I am not mistaken Blend at the beginning had support for PSD and AI file import from Adobe Photoshop and Adobe Illustrator, but for some reason this feature was removed

lokitoth commented 7 years ago

This seems completely unrelated to XAML standard, and is probably more applicable to be suggested here: https://visualstudio.uservoice.com/forums/121579-visual-studio-ide

It simply could have created a new IDE out of the existing Visual Studio Shell infrastructure at the time

@mike-EEE It really couldn't. When Blend was first built it was the lighthouse application for WPF; at the time Visual Studio was not WPF-based. That happened later, and when it did happen, a lot of the shell code was shared. In fact, I was one of the developers working on getting the VS Docking system into Blend. Afterwards, the entire Blend design surface was brought into VS, because it was much richer than what VS had. As I understand it, Blend now lives within the full VS shell.

Mike-E-angelo commented 7 years ago

Cool. Thanks for the correction, @lokitoth. That is my understanding as well (that Blend is now in VS). However, even if the Shell infrastructure wasn't WPF, it would seem that it could have been leveraged to save some effort in at least some capacity. I say this while being reminded of a lot of the bugs that Blend started out with seemed to have been simple, fundamental issues that would have been avoided if they were within Visual Studio. Or rather stated, that the issues that were happening were once happening in Visual Studio, but had since been addressed and solved.

monkeynoises commented 7 years ago

Maybe it is just me....but I found the original Blend shell (with the rounded corners on various elements in that IDE),....just "smoother" and nicer in how it felt....maybe my perceptions are wrong...but it just felt different after it switched over to to the Visual Studio 2015+ look, etc......can't quite put my finger on it.

JerryNixon commented 5 years ago

Would be nice.