A multi-platform .NET UI framework. -!-!-!-!- VOTE FOR SUPPORT IN RIDER: https://youtrack.jetbrains.com/issue/RIDER-39247 -!-!-!-!-
can anybody try it?
@cH40z-Lord Sorry!! I didn't see you trying to help me with the Git integration problem! No, I didn't have the extension installed. Everything by default. The funny thing is that it broke when I used modules in my Git repository. I'm not using them anymore, so I think it won't break again! Thanks a lot for your interest :)
@SuperJMN : yes those instructions seem to work!
only thing is i had to remove the call in the ctor to InitializeComponent for some reason
and update the .net framework version to 4.5.2
oh my...
OK, did you put the Build action in MainWindow.xaml to None?
BTW, thanks for trying!
yeah
I'm going to try again!
maybe it's better to just remove the code-behind file
ok, yeah, it's when you set build action to "None" that InitializeComponent disappears
I fixed the guide! :D
"1.Create a new project of type "WPF Application" and be sure that you select at least .NET Framework 4.5.2 "
"4.Delete MainWindow.xaml.cs (the code-behind file). It won't compile if you don't delete it."
it does compile for me even if i don't delete it
just have to remove the call to InitializeComponent
Since it's not used, I just ask people to remove it
it's my way of saying "you don't need that shit!"
But of course, I will need the code behind file for UserControls... oh mamma!
and other nasty stuff
Is removing code behind an important goal?
in case you are using MVVM, yes
otherwise, code-behind is a must
for any view that is using MVVM, you shouldn't have the need to use the code-behind.
View specific stuff makes sense in code behind
yes, sometimes :)
but I try to avoid view-specific stuff
I've seen all sorts of confusion around mvvm, listboxes shwoing up in the vm etc :)
should be an exception, though
ListBoxes in the VM!?
DIE HARD!
My view is pragmatic but it is very rarely code behind is needed
flamethrower for that
yea
haha
anyways, code-behind is needed.
some custom controls NEED them
to define DPs, for instance
yep
everything that is near the view, may need a code-behind
UserControls, lookless Controls (using Styles)
and some view-specific features
^ is perhaps useful for you guys. No more custom controls.
If validation should be in the view is another discussion :)
Hahaha
I wish they had made wpf open source long ago.
Someone said 'WPF is great ideas poorly implemented' I partlially agree.
I partially agree :)
esl, np
I can write dumb things
https://github.com/JohanLarsson/Gu.Wpf.Validation
Very interesting, but it drives us to the debate of view-based validation
i think removing codebehind is a worthy ambition, but so many times on SO answers i've seen 2 lines of codebehind replaced by 150 lines of behaviour
i'm not into that
is validation always a business thing? I think it is 90% of times :P
yeah, we need to work out a vaidation story for perspex
validation is a definite weakness in WPF
@grokys that should be nice!
Nice thing with the attached props is that they validate as you type. Then the binding can be on lost focus
is VERY weak
very stringy
but not because XAML/WPF doesn't have the power
it's because they didn't made an effort big enough to it
I miss a lot of things, like a binding that validates on Enter
and a wise handling of multitasking
on pressing the enter key?
that is horrible as soon as you try to mix viewmodels and tasks
yes :)
That could easily be added to the attached props
yes, but what I'm referring to is that most of things with WPF/XAML are so un-official that it discourages people to use it
Would be nice if WPF did generics
just discovered this project, seems exciting!
object everywhere makes me sad
welcome @xen2. It is!!
@grokys is the captain of the ship, the workers and the ship
I'm the guy that works on XAML support for it
some people here have also contributed with something!
if you want to involve, just run the code and enjoy :D you'll be hooked
@JohanLarsson It would be a good addition. I always missed it in the past.
support for generics?
yes
@SuperJMN thanks for the intro!
what would make sense as syntax List(int)?
<> would probably make parisng harder
xml doc use {T} but it might be annoying with markup extensions
(hi, by the way)
hi @xen2 @Benlitz
hi @JohanLarsson !
new people!
yes, i miss generics support in xaml
there's been a couple of times it'd have been useful
Is there a way to tell what type a binding produces?
The converted type if there is a converter
@JohanLarsson are you talking about XAML or Perspex?
general wpf q:)
i don't think so
does Perspex have a nice solution for it?
you can look at the dependency property that it's bound to though
perspex's binding system is completely different
it uses IObservables
ah, nice
Have you seen Reed Copsey's work on wpf for F#?
also PerspexProperties are typed, e.g.
PerspexProperty<double>
no, i've not
@JohanLarsson I'm afraid that means nothing to me! I don't really know any F#
is there an explanation anywhere?
I don't speak F# either
I can invite him here some time.
I know he did some work on validation.
i don't even know what an F# module is
I wish ms would drop VB and make F# top priority, the language looks so nice.
Editor support etc not so nice.
yeah, i keep meaning to look into it
VB sux
Yeah, and having C# and VB with 98% overlap just costs money.
F# brings great stuff.
bigger difference in verbosity F# vs C# than C# vs VB I think.
yep, the terseness is probably what interests me most in F# !
as long as it doesn't get unreadable like the perl i did in 1993 ;)
default immutable, structural equality for free is nice
yeah, i've been trying to imagine how immutability might work in a UI framework
i can't ;)
me neither, maybe immutablitiy is a poor fit for viewmodels.
np to have mutable stuff in F#, just that the default is immutable which is nice
yeah, course
it's just the main slowness in perspex at the moment is in layout
if things were immutable that could be done in the b/g
at least partially immutable
yay, solved the binding type issue.
F# sounds nice!
Has somebody tried OmniXAML apart from @grokys ?
not me, I have no x-plat needs at the moment
pure pragmatism!
:)
only heard of it today also :)
haha, OK! I hope you could try it and give some feedback
thanks in advance!
Is there a wiki on how to get started?
started with Perspex or with OmniXaml?
either or both :)
for perspex there's a little bit of info at https://github.com/grokys/Perspex/tree/master/Docs
in particular the intro document
there's a few blog posts at http://grokys.github.io/
but mainly there's here ;)
nice
it's still early days, so not documented as well as it could be
the test app in the repos can also be useful, though it's a little hackily written atm as stuf gets bolted on and off as needed
and the Perspex.DevTools project shows MVVM with ReactiveUI
@JohanLarsson Trying OmniXAML? https://github.com/SuperJMN/OmniXAML/wiki/Using-OmniXAML-for-WPF I hope you can validate the steps! Thanks :D
gf booked me for a party tonight, fail, must afk soon.
have a good one!
@SuperJMN I pushed updates fixing a couple of issues.
wow! where are them?
to the validation thing :)
in case you were interested
ahh! you mean to your project?
I'm following it
to take a look!
https://github.com/SuperJMN/OmniXAML/wiki/Using-OmniXAML-for-WPF
regarding
mainWindow = (Window) xamlLoader.Load(stream);why is there no generic overload? :)
@cH40z-Lord Haha, OK. But I thought that, as XAML is inherently un-typed, it would offer no advantages
it would look like this:
mainWindow = xamlLoader.Load<Window>(stream);
it doesn't save you a single keystroke, nor will it offer compiler type safety
isn't one goal of Perspex (and I guess OmniXAML's too?) to get rid of design decisions like that and create more modern APIs? I personally prefer (optional) generic overloads anytime over having to cast manually to improve readability
or is the sole goal of OmniXAML to become 100% compatible with WPF?
haha, nice point
100% compatibility is not even desirable, I think
but at least, the key points :)
:P :P
well, I've got it patched in (wasn't really that much). if you wish I can file a PR
I'm trying to keep everything as simple as I can
btw what about that TestApplication? VS is complaining that the MainWindow class isn't implementing all necessary methods
argh!
can you post the exact message?
@cH40z-Lord OK! but I'm not sure about that. What about creating just an adapter to the loader and offer that extra method?
Severity Code Description Project File Line
Error CS0103 The name 'InitializeComponent' does not exist in the current context TestApplication F:\GitHub\OmniXAML\OmniXaml\TestApplication\MainWindow.xaml.cs 12 /// <summary>
/// Attaches events and names to compiled content.
/// </summary>
/// <param name="connectionId">An identifier token to distinguish calls.</param><param name="target">The target to connect events and names to.</param>
public void Connect(int connectionId, object target)
{
throw new System.NotImplementedException();
}
/// <summary>
/// Loads the compiled page of a component.
/// </summary>
public void InitializeComponent()
{
throw new System.NotImplementedException();
}
O_O
surprising!
:P
is it the main branch?
yeah, master branch
and.. the latest version?!
I'm about to take a look to that :P
just checked it out via GitHub Extensions for VS, implemented the two methods, hit build solution which also restored all packages automatically and there we go :P
that IS strange!
I'm going to delete my working copy
and clone it again
before you remove your working copy and lose any changes, I'd check it out in a separate folder and go on from there
haha, that's is what I'm doing right now
:)
haha
the same error is showing!
what the...!
is it possible that it's related to the build action or so? (I've read something like that above)
I'm looking for something like that, but it looks OK
weird
did you have any problem with Extended.Wpf.Toolkit when building?
yeah, it's complaining about a PropertyGrid
Severity Code Description Project File Line
Error The tag 'PropertyGrid' does not exist in XML namespace 'http://schemas.xceed.com/wpf/xaml/toolkit'. Line 110 Position 18. TestApplication F:\GitHub\OmniXAML\OmniXaml\TestApplication\MainWindow.xaml 110
Aha... damn it
there seems to be a problem with that package
it doesn't restore OK
hm hm hm
I uninstalled it, reinstalled it and the problem with MainWindow disappeared
I think I've fixed the problem
I'm about to commit the fix
:thumbsup:
OK, done
I'll check again
that NuGet package has broken me uncountable times
I don't know why the references to the assemblies are usually broken
sometimes, they point to \packages\Extended.Wpf.Toolkit.2.4
and sometimes, they point to packages\Extended.Wpf.Toolkit.2.4.0
(notice the final ".0"?)
yeah
what version of VS are you using?
I hope it's fixed now
VS 2015 RC
same here, hm. is it possible that you initially committed this project with VS2013 which may have done it differently?
or maybe it was just a specific version of the NuGet extension that broke it
I think it was the latter
it was a nightmare
I had a CI server that was totally unable to restore NuGet Packages
due to that
o_O crazy
I would like to have a CI server for OmniXAML
to avoid problems like that
what about appveyor? :)
but I don't know how to do it
or TeamCity
AppVeyor?
is that free?
yeah, it's a public CI server that offers builds on Windows
afaik it is free for OSS projects
cool!
I can set up an account :)
=)
there's also an alternative to the two but I can't remember what its name was lol
whoops! it seems it doesn't have .NET Framewor 4.6 installed :P
I see it countless times on GitHub but now when I'd need it I can't remember it x_X
oh? do you already require it? :P
yes!
C# 6.0 all the way!
well, Appveyor failed compiling
the .NET version is not related to the C# version :)
haha, I know, but I'm targeting 4.6 in some project, I think
alright :)
sniff :worried:
hold on, I've read a blog post about how to use C# 6 on AppVeyor
OK! thanks!
in the meanwhile I'm testing the fix
see that "Build Engine v12...."? that should be v14
OK! switching!
it's compiling
yay
I hope now it's successful
it's taking a lot of time!
and it doesn't show any log now
:S
maybe when it's done
if this works, the only thing it'll left not automated will be NuGet packages
:)
OK, it says it's "Queued"
:D :D
btw if you need a private (or just a nightly) nuget feed --> https://www.myget.org/opensource
thanks!
I have an account in myget
:)
this is super interesting!
:)
I have 2 NuGet nuspec files that should be generated
OmniXaml
and OmniXaml.Wpf
I don't know it that is a good idea
both packages come from the same solution
how do they differ?
the package id
the version
and the assemblies
and that's it?
yes
well, then it's a bad idea :/
the WPF package is thought to be independent
you can take a look to them if you want
hm okay, one requires framework assemblies. then it is fine with me
woop woop!
it's soooo good!
next step, NuGet packages autogenerated and unploaded to nuget.org
@Super have you created packages before?
yes, but I'm not an expert
I can write a PR for you they way I do them
link to the repo?
Thank you!
@SuperJMN one problem, I'm on 4.5 looking at a massive diff
Should I revert?
There are 2 different
solutions?
Packages
but when I opened it in 4.5 VS or R# touched every file in the project it seems.
lots of noise
sorry, I was writing on my mobile phone and it was almost impossible!
I mean, there are 2 different packages: OmniXaml and OmniXaml.Wpf
I think I'm reverting
please, take a look at them. They are the latests nuspec packages I created
the reference assemblies that are generated from the very same .sln file
(OmniXaml.sln)
@SuperJMN ^ is how I write them, you don't want net45
I usually include .pdbs
I don't have version number in the filename
<id>$id$</id>
<version>$version$</version>
<title>$id$</title>
<authors>$author$</authors>
<owners>$author$</owners>
reads version from the assemblyproperties
I handedited so can be mistakes :)
could not build so could not test
Oh :( Is it because it doesn't compile?