These are chat archives for AvaloniaUI/Avalonia

24th
Feb 2015
José Manuel Nieto
@SuperJMN
Feb 24 2015 13:20
from my experience, Ambient Contexts is the last resort
ALWAYS try to inject dependencies via ctor
if it's a true cross-cutting concern, then it would be a good choice for Ambient Contexts
the advantage is that they provide a true meaning (you could immediately read the name of the context and understand why it's there)
Steven Kirk
@grokys
Feb 24 2015 13:25
yes, i had a look at your branch, but unfortunately constructor injection is a definite no-no
José Manuel Nieto
@SuperJMN
Feb 24 2015 13:25
you mean in the Application class?
Steven Kirk
@grokys
Feb 24 2015 13:26
the two places i saw it were Application and Bitmap
José Manuel Nieto
@SuperJMN
Feb 24 2015 13:26
(also, another advantage is that they are strongly typed)
ahh, OK
I have to reword that part
(Bitmap)
Steven Kirk
@grokys
Feb 24 2015 13:26
there is no way we can require a client to inject a platform-specific impl every time she creates a Bitmap
the same for Application
José Manuel Nieto
@SuperJMN
Feb 24 2015 13:27
yes, that's right
Steven Kirk
@grokys
Feb 24 2015 13:27
even though that is only created once
José Manuel Nieto
@SuperJMN
Feb 24 2015 13:27
I have to eliminate that parameter
but for the application class, I have thought of a better cool way to do it
Steven Kirk
@grokys
Feb 24 2015 13:27
yeah - end-usability wins every time
what is that?
José Manuel Nieto
@SuperJMN
Feb 24 2015 13:28
far more usable than what's there now
Application will be internal
and will be the composition root
then, in Win32, there will be a Win32Application
the one that is public
Steven Kirk
@grokys
Feb 24 2015 13:30
hmm
José Manuel Nieto
@SuperJMN
Feb 24 2015 13:30
oh, sorry, that Win32Application will be the composition root
not the Application class itself
Steven Kirk
@grokys
Feb 24 2015 13:31
oh
José Manuel Nieto
@SuperJMN
Feb 24 2015 13:31
this keeps the Application class testable
you can just inject mocks in there
I always do my design thinking in testability
when your receive all the dependencies from the outside, tests are WAY easier to do
Steven Kirk
@grokys
Feb 24 2015 13:32
you'll have to explain a bit better, still don't quite get what you're proposing
José Manuel Nieto
@SuperJMN
Feb 24 2015 13:32
your are setting extension points
OK, I'll let the code explain it :)
Steven Kirk
@grokys
Feb 24 2015 13:32
yes i know about testability ;)
well it might be better if we discuss it first...
José Manuel Nieto
@SuperJMN
Feb 24 2015 13:32
OK
from the user point of view
App : Win32Application
Win32Application will export EVERY dependency
(and set the contexts to the correct values)
Steven Kirk
@grokys
Feb 24 2015 13:34
so App inherits from Win32Application?
José Manuel Nieto
@SuperJMN
Feb 24 2015 13:34
and will instantiate the real application using all the dependencies (injected via ctor)
yes, Win32Application will set up everything
Steven Kirk
@grokys
Feb 24 2015 13:34
what about on non-windows systems?
José Manuel Nieto
@SuperJMN
Feb 24 2015 13:35
if you don't want the user to fight with different app names, then te Application class could be defined in different assemblies
if you use Perspex.Win32
Application will be x
in Perspex.OtherPlatform
Application will be another, with the same name
but different
Steven Kirk
@grokys
Feb 24 2015 13:36
the thing is, i was trying to make it so that eventually the binary could be cross-platform
José Manuel Nieto
@SuperJMN
Feb 24 2015 13:36
this way, XApplication is just a composer of the real Application (
that wouldn't be a problem
just setting the appropriate dependencies, it will work
no matter if it's cross-platform or not
I will test it into my branch
too see how it looks
Steven Kirk
@grokys
Feb 24 2015 13:38
i have to say i'm not convinced
José Manuel Nieto
@SuperJMN
Feb 24 2015 13:39
it's not my intention to convince you :) it won't affect your code!
and in the end, it's a minor change
the behavior is very similar
Steven Kirk
@grokys
Feb 24 2015 13:40
won't affect my code? is your intention not to merge our two forks?
José Manuel Nieto
@SuperJMN
Feb 24 2015 13:41
yes, but the XAML part is completely separated from the rest of the "core"
you could keep your current code without a problem
and get XAML working
anyways, I cannot release anything related to XAML
Steven Kirk
@grokys
Feb 24 2015 13:42
but this Application change isn't related to XAML is it?
José Manuel Nieto
@SuperJMN
Feb 24 2015 13:43
no, it's not related to XAML in any way
Steven Kirk
@grokys
Feb 24 2015 13:43
ok, so shouldn't the goal be to merge it with the main Perspex?
José Manuel Nieto
@SuperJMN
Feb 24 2015 13:43
I just wanted to remove all the ServiceLocator usages
yes, but we cannot make it work without a XamlReader
Steven Kirk
@grokys
Feb 24 2015 13:43
sorry i'm confused
José Manuel Nieto
@SuperJMN
Feb 24 2015 13:44
let me explain me again:
Steven Kirk
@grokys
Feb 24 2015 13:44
Application and ServiceLocator aren't related to XAML so why do they need a XamlReader?
José Manuel Nieto
@SuperJMN
Feb 24 2015 13:45
  • the XAML feature will not be merged if we cannot use a XamlReader from PCLs libs. Otherwise, the entire thing is broken
  • I've removed the Service Location thingy because I felt it would be good remove it. But it has nothing to do with the XAML feature
Steven Kirk
@grokys
Feb 24 2015 13:47
ok
José Manuel Nieto
@SuperJMN
Feb 24 2015 13:47
  • The current XamlReader gets everything injected via ctor. I had to export some dependencies. So I did the same with the rest of the platform.
So my fork is a "nice to see", but just imaginary until we have a XamlReader
Steven Kirk
@grokys
Feb 24 2015 13:48
lets leave aside all the XAML stuff for the moment - you've said that the service location stuff is not related
have you not got a branch with just the service locator changes?
José Manuel Nieto
@SuperJMN
Feb 24 2015 13:48
yes, I have it
it's still there
the name is CorrectDI
I merged it into my XAML branch
Steven Kirk
@grokys
Feb 24 2015 13:49
so is the plan not to get that merged back into the main Perspex?
José Manuel Nieto
@SuperJMN
Feb 24 2015 13:49
I splitted it just in case you liked it
:)
This message was deleted
and to keep things organized a bit
Steven Kirk
@grokys
Feb 24 2015 13:49
ok, i'm just confused about your plans
José Manuel Nieto
@SuperJMN
Feb 24 2015 13:50
My plan is:
a) to learn
Steven Kirk
@grokys
Feb 24 2015 13:50
is the service locator stuff just an experiment? or is it something you're proposing should be done in the main perspex?
José Manuel Nieto
@SuperJMN
Feb 24 2015 13:50
b) to do things right
c) to see how far I can get with the XAML thing
I'm evaluating the creating of a custom XamlReader
the service locator stuff was just to improve the code base
(my fork's code base)
(with the idea to merge it to XAML)
Steven Kirk
@grokys
Feb 24 2015 13:51
ok, so it isn't something you think should be in the main Perspex
José Manuel Nieto
@SuperJMN
Feb 24 2015 13:52
no, nothing in my fork should be in Perspex
unfortunately
Steven Kirk
@grokys
Feb 24 2015 13:52
oh...
José Manuel Nieto
@SuperJMN
Feb 24 2015 13:52
the only thing that could, is the Ambient Contexts thing
Steven Kirk
@grokys
Feb 24 2015 13:53
which is the service locator stuff?
sorry, i feel like we're going in circles...
José Manuel Nieto
@SuperJMN
Feb 24 2015 13:54
yes, the Service Locator thing
that you already said you don't like
haha
in order to release the XAML feature
we require one of those 2
a) we create a XamlReader that is able to work from a PCL
b) Make every library of Perspex.Xaml NON-PCL in order to use the official XamlReader version
that could be a big lose
XAML feature 100% only for Windows
we can do one thing
target Windows with XAML
Windows only
and that's it
José Manuel Nieto
@SuperJMN
Feb 24 2015 13:59
no PCLs
that way, we could merge to your fork
José Manuel Nieto
@SuperJMN
Feb 24 2015 14:05
I would like to go the PCL way
but time is ticking
and nobody is trying to develop a XamlReader for PCL
I don't know if it's time for me to try
or time to give up and make it 100% Windows only
(XAML)
Steven Kirk
@grokys
Feb 24 2015 14:07
right, yeah
or you could wait a little while - because after all perspex isn't going to be finished anytime soon!
but the service locator stuff - i didn't say i didn't like it
i wasn't convinced about inheriting from Win32Application
but all the Locator.GetService() stuff was just done like that because it was easy
and i didn't want to worry about small details like service location. as you've seen it can be easily replaced.
José Manuel Nieto
@SuperJMN
Feb 24 2015 14:09
believe me, it wasn't really easy :P
it took me 2 days
haha
Steven Kirk
@grokys
Feb 24 2015 14:10
ok :)
José Manuel Nieto
@SuperJMN
Feb 24 2015 14:10
but yes, ServiceLocation absolutely sucks
Steven Kirk
@grokys
Feb 24 2015 14:10
yeah a bit - but - it's not important!
José Manuel Nieto
@SuperJMN
Feb 24 2015 14:10
yes, but it was something I'm good at
DI is one of my strong points
but, yes, I agree
it's not so important as any presentation feature!
Steven Kirk
@grokys
Feb 24 2015 14:11
is writing menu controls by any chance one of your strong points? ;)
because that is VERY important!
and you have so much enthusiasm for the project, it would be so good to use it to move things along in a very real way
José Manuel Nieto
@SuperJMN
Feb 24 2015 14:19
I would have to take a good in-depth look at other controls
Steven Kirk
@grokys
Feb 24 2015 14:20
yeah - it probably would take a bit of learning... also about how WPF does it
i started but got bored ;) haha
i'm tired of writing controls - i've written 20 of the things!
i will try to get dialogs done in the next few evenings though
José Manuel Nieto
@SuperJMN
Feb 24 2015 14:24
it would be nice to have a document to list what currently works
Backgrounds?
FontSize?
TextAlignments?
Steven Kirk
@grokys
Feb 24 2015 14:24
well everything that there is a property for should work to some extent
José Manuel Nieto
@SuperJMN
Feb 24 2015 14:25
I will try with menus
but it's a hard thing to start
:S
Steven Kirk
@grokys
Feb 24 2015 14:25
yeah, i know ;)
i guess we should start adding issues
for things that are missing or broken
José Manuel Nieto
@SuperJMN
Feb 24 2015 14:26
it goes with popups
that is something I don't know how to handle
Steven Kirk
@grokys
Feb 24 2015 14:26
yeah, popups work to an extent
DropDown uses them
José Manuel Nieto
@SuperJMN
Feb 24 2015 14:26
OK, I will take a look
Steven Kirk
@grokys
Feb 24 2015 14:26
but a lot of features are missing there currently
things like placement
José Manuel Nieto
@SuperJMN
Feb 24 2015 14:35
anyways, nobody here wants to try with a XamlReader what is portable?
:anguished:
Steven Kirk
@grokys
Feb 24 2015 14:35
haha
didn't hari say he would let you know MS's plans there?
José Manuel Nieto
@SuperJMN
Feb 24 2015 14:46
yes, but I have no hopes in an open-source XamlReader
Steven Kirk
@grokys
Feb 24 2015 14:46
oh really? that's a shame - i thought the message he tweeted to you sounded positive
José Manuel Nieto
@SuperJMN
Feb 24 2015 16:37
sounded positive in terms of "the guy appreciates our effort"
but after a bit of analysis I think it's not very promising
If only he said "yeah, man, I've run the application and..."
and yes, he and Robert work for Microsoft: I don't know if they would be interested in a PCL version of System.Xaml
anyways, I told them that, if they think of one, I can collaborate with them
it's all I can do
you started it! ;)
José Manuel Nieto
@SuperJMN
Feb 24 2015 21:18
Yes, TDD
I don't know what it will be, but let's try
Steven Kirk
@grokys
Feb 24 2015 21:26
good luck!
José Manuel Nieto
@SuperJMN
Feb 24 2015 22:19
thanks, I will need it
Steven Kirk
@grokys
Feb 24 2015 23:19
ok, Window.ShowDialog is now in there
not sure if i'm doing everything i need to do to show a dialog safely... probably not, but it's a start
ShowDialog returns a Task so it needs to be awaited
dialogs can also return data by calling Window.Close(dialogResult)
which can be retrieved using await Window.ShowDialog<TResult>()
Steven Kirk
@grokys
Feb 24 2015 23:26
btw @SuperJMN are you sure you want to use GPL for your Xaml reader? that will mean that Perspex can't use it!