These are chat archives for AvaloniaUI/Avalonia

27th
Aug 2015
Darnell Williams
@Seeker1437
Aug 27 2015 15:02 UTC
Isnt that normal though?
José Manuel Nieto
@SuperJMN
Aug 27 2015 15:17 UTC
I think so! At least I'm replicating that behavior.
If you see something wrong when I speak aloud, just correct me 😋
I'm already implementing the feature (namescopes)
Richard Simpson
@RichiCoder1
Aug 27 2015 15:23 UTC
My two cents would be that while that makes sense, you should wave a big flag documenting that so people don't get confused when they can't access named children from the top level. I know I'd initial be confused.
Steven Kirk
@grokys
Aug 27 2015 15:24 UTC
guys, jose is just trying to replicate normal xaml behaviour - he's trying to understand namescopes
Richard Simpson
@RichiCoder1
Aug 27 2015 15:25 UTC
Is that really how that works in normal Xaml? Bizzare
Steven Kirk
@grokys
Aug 27 2015 15:25 UTC
yep
imagine a usercontrol with a child called "btn" - each time you instantiate the UserControl it creates a new namescope so that the "btn" is unique to the instance
the reason it looks weird in the demo posted about is that namescopes aren't usually implemented on classes like that
they're usually on Window, UserControl, Page and the root of a templated control's template
Darnell Williams
@Seeker1437
Aug 27 2015 15:30 UTC
You know what, it makes sense. I would imagine the namescope mainly tied just how you mentioned... Used in things that have named children. Hehe and Window, Page, and UserControl is the first thing that comes to mind in that regard. Woot xD I am not a complete noob... I think.
José Manuel Nieto
@SuperJMN
Aug 27 2015 15:36 UTC
I love when there's any kind of discussion 😁
José Manuel Nieto
@SuperJMN
Aug 27 2015 15:42 UTC
I usually have problems distinguishing how things should work because WPF uses some tricks. For example, it uses custom reader that is fed with BAML
In BAML all the properties are sorted so they are read in an order where their dependencies between them are always fulfilled.
José Manuel Nieto
@SuperJMN
Aug 27 2015 15:47 UTC
For instance, for a Setter in BAML, the Property appears always before Value
Since OmniXAML uses XAML, not BAML, it has to sort the members itself
It's just an example
There's a big problem I have with WPF's ResourceDictionaries.
I'll tell you when I'm back home
Steven Kirk
@grokys
Aug 27 2015 15:59 UTC
This message was deleted
i'm thinking that ResourceDictionaries in Perspex should be implemented by the XAML library, as they're not needed when you're not using markup
(as an attached property)
José Manuel Nieto
@SuperJMN
Aug 27 2015 16:10 UTC
Will they work completely different?
Steven Kirk
@grokys
Aug 27 2015 16:11 UTC
i don't see why they would... but they could if you like
José Manuel Nieto
@SuperJMN
Aug 27 2015 16:11 UTC
No, no, I want they work like in WPF
If they are different, I hope they are handled easily in XAML
Also, Styles are still to be implemented
I think they will take a bit of courage to marry them to XAML
Steven Kirk
@grokys
Aug 27 2015 16:14 UTC
ok, the only difference then is that they'll be attached properties instead of normal properties
yeah, styles will be a challenge
José Manuel Nieto
@SuperJMN
Aug 27 2015 16:14 UTC
Aha! Then XAML should work
Attached properties work just right in OmniXAML
As long as they have GetValue/SetValue methods with the correct firm 😊
static methods, of course
Steven Kirk
@grokys
Aug 27 2015 16:19 UTC
well my thinking is that they'll be implemented in Perspex.Xaml so they can be how we want
or maybe the stuff that is particular to markup but might be of potential use to other markups could go in Perspex.Markup
José Manuel Nieto
@SuperJMN
Aug 27 2015 16:49 UTC
Yes, I agree
What's sure is that we'll get it working in some way or another
I don't know if that is written in proper English 😆
"in some way or another" 👀
Steven Kirk
@grokys
Aug 27 2015 16:54 UTC
yep, pretty much :)
your english is great these days!
José Manuel Nieto
@SuperJMN
Aug 27 2015 17:01 UTC
Haha, absolutely unexpected!
Steven Kirk
@grokys
Aug 27 2015 17:05 UTC
@SuperJMN: Perspex.Xaml.Desktop.WindowsResourceProvider - is that supposed to load from files compiled into the assembly by setting "Build Action" to resource?
at the moment it reads from disk, is that a hack until resource reading is ready?
José Manuel Nieto
@SuperJMN
Aug 27 2015 17:23 UTC
It's a hack!
You're right
Steven Kirk
@grokys
Aug 27 2015 17:24 UTC
ok, i will implement that properly
José Manuel Nieto
@SuperJMN
Aug 27 2015 17:24 UTC
It should load from resources
Cool! I'll take a look. Thanks, dude!
Darnell Williams
@Seeker1437
Aug 27 2015 17:35 UTC
Pie
You all deserve some pie.
Steven Kirk
@grokys
Aug 27 2015 17:43 UTC
haha
how would WindowsResourceProvider be plugged into XamlTestApplication?
Steven Kirk
@grokys
Aug 27 2015 17:59 UTC
IResourceProvider doesn't seem to be used anywhere...
José Manuel Nieto
@SuperJMN
Aug 27 2015 18:33 UTC
I'm on the bus, wife, shopping bags and all :smile: I cannot see the code right now, but I'll tell you ASAP!
José Manuel Nieto
@SuperJMN
Aug 27 2015 19:12 UTC
Hey, I'm home
first, what do you want to do? I suppose you are trying to load .xaml files from a resource stream
is it?
Steven Kirk
@grokys
Aug 27 2015 19:14 UTC
yeah
José Manuel Nieto
@SuperJMN
Aug 27 2015 19:14 UTC
OK
Steven Kirk
@grokys
Aug 27 2015 19:15 UTC
WindowsResourceProvider seems to be the place to implement it, but its interface, IResourceProvider isn't used anywhere
José Manuel Nieto
@SuperJMN
Aug 27 2015 19:15 UTC
I will have to remove it, it's a leftover from a past design
Steven Kirk
@grokys
Aug 27 2015 19:15 UTC
so how do i plug IResourceProvider into the rest of OmniXaml
ah ok
José Manuel Nieto
@SuperJMN
Aug 27 2015 19:16 UTC
take a look at PerspexInflatableTypeFactory.cs
you will see that it's injected a "new InflatableTranslator()"
line 12
calling the base
you will have to implement your own InflatableTranslator
Steven Kirk
@grokys
Aug 27 2015 19:17 UTC
ah ok
José Manuel Nieto
@SuperJMN
Aug 27 2015 19:17 UTC
and inject it there
Steven Kirk
@grokys
Aug 27 2015 19:17 UTC
i would never have guessed from the name!
José Manuel Nieto
@SuperJMN
Aug 27 2015 19:17 UTC
GetUriFor ... will be called only for inflatables (Window and UserControl)
yes, I have to revise those names!
Steven Kirk
@grokys
Aug 27 2015 19:18 UTC
;)
José Manuel Nieto
@SuperJMN
Aug 27 2015 19:18 UTC
back on topic
you'll be called with a Type
that type is one of the inflatables you choose
(for Perspex, there will be UserControl and Window)
Steven Kirk
@grokys
Aug 27 2015 19:19 UTC
Stream GetStream(Type type) right? so type will be UserControl or Window
how do i know the name of the file to load from?
José Manuel Nieto
@SuperJMN
Aug 27 2015 19:20 UTC
sorry, GetStream
yes, you will be asked by UserControl and Window types
then, you choose which stream to provide
Steven Kirk
@grokys
Aug 27 2015 19:21 UTC
but don't i need a URL to locate the correct file?
José Manuel Nieto
@SuperJMN
Aug 27 2015 19:21 UTC
well, Window or any subtype
Steven Kirk
@grokys
Aug 27 2015 19:22 UTC
ahhh ok
so not just Window or UserControl, but say MainWindow will be passed
José Manuel Nieto
@SuperJMN
Aug 27 2015 19:22 UTC
yes, that's it!
Steven Kirk
@grokys
Aug 27 2015 19:22 UTC
then i can lookup MainWindow.xaml ok
José Manuel Nieto
@SuperJMN
Aug 27 2015 19:22 UTC
I get them by convention
if MainWindow is in the namespace MyLib.Views.MainWindow, then I look into bin\Debug\Views\MainWindow.xaml
If that mechanism isn't enough to locate the Stream, I will have to change the interface :P
Steven Kirk
@grokys
Aug 27 2015 19:29 UTC
i think it should be ok for now, but you might want to allow a path/url in future
José Manuel Nieto
@SuperJMN
Aug 27 2015 19:38 UTC
OK, I've thought a little bit more about why I did the interface without a Uri. It's because it's intended to be used as a replacement for the InitializeComponent stage
OmniXAML should be capable of locating a stream with the XAML to inflate it using only the Type
it shouldn't need anything more
the parser will try to create an instance of each type using a TypeFactory
that TypeFactory will be an InflatableTypeFactory, that when asked for an inflatable (UserControl, Window...) will inflate it
(using the corresponding XAML stream)
Steven Kirk
@grokys
Aug 27 2015 19:46 UTC
sure, might be worth thinking about allowing a url/path just to be flexible in the future but for now it should be ok
the weird thing is that GetUriFor already creates a URI for a type
but that's only used by GetStream
Steven Kirk
@grokys
Aug 27 2015 19:51 UTC
so it's strange that it's in the interface
José Manuel Nieto
@SuperJMN
Aug 27 2015 19:51 UTC
well, it's a successful attempt to decouple the type system and XAML to avoid InitializeComponent
ah, you will like it :) it has it's reason to exist!
Steven Kirk
@grokys
Aug 27 2015 19:54 UTC
what i mean is: GetUriFor seems to be an implementation detail of InflatableTypeFactory
as it's never called from elsewhere in OmniXaml
it's only called from GetStream
ah hold on
sorry, i was wrong ;)
GetUriFor is an implementation detail, it's not in the interface
Steven Kirk
@grokys
Aug 27 2015 20:00 UTC
ok, let me see if i've got this right: GetTypeFor(Uri) returns a Type for a URI
that type is then passed to GetStream(Type)
which then must convert the Type to a URI to load it?
or am i misunderstanding something?
sorry, it's my first try at using the code and i need to get my bearings
José Manuel Nieto
@SuperJMN
Aug 27 2015 20:15 UTC
GetTypeFor is there right now for this scenario
inflatableFactory.Create(new Uri("WpfLikeModel/WindowWithUserControl.xaml", UriKind.Relative));
that could be used when you know the Uri, but you don't know the type
Steven Kirk
@grokys
Aug 27 2015 20:17 UTC
i see, ok
José Manuel Nieto
@SuperJMN
Aug 27 2015 20:17 UTC
let's see how it gets through
everything is too new!
Steven Kirk
@grokys
Aug 27 2015 20:18 UTC
sure, it just seemed strange that you have to go URL -> Type -> URL
José Manuel Nieto
@SuperJMN
Aug 27 2015 20:18 UTC
nobody used it before
Steven Kirk
@grokys
Aug 27 2015 20:18 UTC
yeah, of course, not criticizing
José Manuel Nieto
@SuperJMN
Aug 27 2015 20:20 UTC
don't worry, let's wait for the interfaces to settle a bit
there will be sharp edges, of course :)
Steven Kirk
@grokys
Aug 27 2015 20:20 UTC
it might be useful to take InflatableTranslator an abstract base implementation of IInflatableTranslator because at the moment I have to copy-and-paste the implementaion of GetTypeFor
I assume I want the same implementation, right?
José Manuel Nieto
@SuperJMN
Aug 27 2015 20:22 UTC
how does your current implementation look like?
I'm not sure you will want to create a base type
Steven Kirk
@grokys
Aug 27 2015 20:23 UTC
one sec
José Manuel Nieto
@SuperJMN
Aug 27 2015 20:23 UTC
maybe you're right!
Steven Kirk
@grokys
Aug 27 2015 20:27 UTC
ok, it worked first try!
it's just copied from InflatableTranslator with GetStream changed a bit
José Manuel Nieto
@SuperJMN
Aug 27 2015 20:29 UTC
haha, nice!!
it's the only method that will be called (GetStream)
Steven Kirk
@grokys
Aug 27 2015 20:29 UTC
ok
José Manuel Nieto
@SuperJMN
Aug 27 2015 20:30 UTC
It's really cool that you got it working at the first try!
Steven Kirk
@grokys
Aug 27 2015 20:31 UTC
yeah, tbh i just copied all the code from other places ;)
but still
José Manuel Nieto
@SuperJMN
Aug 27 2015 20:31 UTC
you suggest me to make a base class
Steven Kirk
@grokys
Aug 27 2015 20:31 UTC
not sure
José Manuel Nieto
@SuperJMN
Aug 27 2015 20:31 UTC
and override only the desired methods?
Steven Kirk
@grokys
Aug 27 2015 20:32 UTC
maybe you should move the loading to a different interface?
José Manuel Nieto
@SuperJMN
Aug 27 2015 20:32 UTC
"InflatableResourceTranslatorBase"?"
Steven Kirk
@grokys
Aug 27 2015 20:32 UTC
nooooo ;)
José Manuel Nieto
@SuperJMN
Aug 27 2015 20:32 UTC
ahh!
Steven Kirk
@grokys
Aug 27 2015 20:32 UTC
it's becoming Java ;)
José Manuel Nieto
@SuperJMN
Aug 27 2015 20:32 UTC
hahaha
for God sake!
Steven Kirk
@grokys
Aug 27 2015 20:32 UTC
it seems to me that you're not translating resources
you're loading a file from a path at the end of the day
so it doesn't seem right that to do that, you have to implement all the URL -> Type -> URL stuff
José Manuel Nieto
@SuperJMN
Aug 27 2015 20:33 UTC
Maybe I should separate interfaces there
I will take a look to that
Steven Kirk
@grokys
Aug 27 2015 20:34 UTC
yeah perhaps, something to think about anyway
José Manuel Nieto
@SuperJMN
Aug 27 2015 20:34 UTC
yes, I will like it to be as good-looking and straigtforward as possible
for the developer that uses OmniXAML
Steven Kirk
@grokys
Aug 27 2015 20:35 UTC
mainly it just seems wrong that to implement a new file source you have to implement something called an "InflatableTranslator"
to me that sounds like something deep in the implementation
José Manuel Nieto
@SuperJMN
Aug 27 2015 20:35 UTC
maybe it's a naming problem
Steven Kirk
@grokys
Aug 27 2015 20:35 UTC
maybe
José Manuel Nieto
@SuperJMN
Aug 27 2015 20:35 UTC
the way it works is like this:
Steven Kirk
@grokys
Aug 27 2015 20:36 UTC
but also the fact i had to copy code to translate between urls and types
José Manuel Nieto
@SuperJMN
Aug 27 2015 20:36 UTC
The parser will try to create types will parsing the XAML
there are a lot of types that are plain types, i.e. not described using XAML
but when the parser finds a type liable of loading from XAML ("inflated"), the parser will blindly load it like any other type
for instance, if your MainWindow.xaml contains some UserControl
then, the parser will create the type using the provided TypeFactory
what type factory?
a special kind of type factory that knows that some types can be inflated from XAML
Steven Kirk
@grokys
Aug 27 2015 20:40 UTC
i'm confused..
shouldn't XAML only be inflated when you ask it to?
José Manuel Nieto
@SuperJMN
Aug 27 2015 20:41 UTC
no!
Steven Kirk
@grokys
Aug 27 2015 20:41 UTC
like, if you're parsing the XAML for a window and it comes across a UserControl
José Manuel Nieto
@SuperJMN
Aug 27 2015 20:41 UTC
you don't have to load it explicitly
Steven Kirk
@grokys
Aug 27 2015 20:41 UTC
it creates an instance of that UserControl
José Manuel Nieto
@SuperJMN
Aug 27 2015 20:41 UTC
yes, that should be right if the UserControl isn't defined in XAML
Steven Kirk
@grokys
Aug 27 2015 20:41 UTC
and in the constructor for that UserControl the XAML for the usercontrol is loaded
with a call in code
or am i mistaken?
José Manuel Nieto
@SuperJMN
Aug 27 2015 20:43 UTC
my point of view is that InitializeComponent is coupling the inflate stage to the component itself
UserControl or Windows shouldn't known anything about the inflate mechanism
Steven Kirk
@grokys
Aug 27 2015 20:43 UTC
yes, but the UserControl has a call to InitializeComponent right?
José Manuel Nieto
@SuperJMN
Aug 27 2015 20:43 UTC
no
Steven Kirk
@grokys
Aug 27 2015 20:43 UTC
oh
José Manuel Nieto
@SuperJMN
Aug 27 2015 20:44 UTC
InitializeComponent is rendered useless
the component doesn't need to know how to inflate itself
it is transparent
Steven Kirk
@grokys
Aug 27 2015 20:44 UTC
but it should in my view
because what if I make a UserControl where the controls are created in code
will xaml overwrite that?
José Manuel Nieto
@SuperJMN
Aug 27 2015 20:45 UTC
no
never
the factory will only try to inflate types that you choose to
Steven Kirk
@grokys
Aug 27 2015 20:45 UTC
choose to how?
José Manuel Nieto
@SuperJMN
Aug 27 2015 20:45 UTC
the PerspexInflatableFactory has a list of inflatable types
Steven Kirk
@grokys
Aug 27 2015 20:46 UTC
ok, and one of those is UserControl
José Manuel Nieto
@SuperJMN
Aug 27 2015 20:46 UTC
yes
if there is not MyControl.xaml, then it won't inflate
it's thought to be completely automatic and decoupled
if you want other behavior, you just have to inject it!
Steven Kirk
@grokys
Aug 27 2015 20:47 UTC
ok... that seems to me to be more coupled than in WPF
José Manuel Nieto
@SuperJMN
Aug 27 2015 20:47 UTC
even better, you don't have to rely on any Inflatable thingy
you could even do it with the InitializeComponent method
Steven Kirk
@grokys
Aug 27 2015 20:47 UTC
which is how WPF does it right?
José Manuel Nieto
@SuperJMN
Aug 27 2015 20:47 UTC
yes
you could make your base class have an InitializeComponent that uses a XamlLoader
(to load itself)
every class is optional and can have its behavior injected
so whatever you want OmniXAML to do, you can do it
Steven Kirk
@grokys
Aug 27 2015 20:48 UTC
it would make more sense to me if each class was responsible for how it was initialized
José Manuel Nieto
@SuperJMN
Aug 27 2015 20:49 UTC
you can do it :)
Steven Kirk
@grokys
Aug 27 2015 20:49 UTC
it seems strange that XAML would initialize controls that i've not asked it to
José Manuel Nieto
@SuperJMN
Aug 27 2015 20:49 UTC
that's why it's in AppServices
it's an easy way to make things just happen
you ask for a MainWindow?
OK, here you are
OmniXAML doesn't force you to choose how to load anything
you do
I didn't want you have to modify your Window implementation
or UserControl implementation :)
and that is NICE!
because decoupled it works better
you may create an InitializeComponent inside your UserControl base class that creates a XAML loader and passes itself as root class
it will inflate it using your instance
so, if you load a Window with the UserControl inside the XAML, the UserControl will inflate itself :)
var myWindow = loader.Load(mainWindowStream);
no inflatable factory at all
José Manuel Nieto
@SuperJMN
Aug 27 2015 20:54 UTC
no tokens for windows, the hard but flexible way :)
even better, you could provide your custom type factory to the XAML loader so each type will be created the way you want. You can even pass it an IoC container and let it resolve dependencies of each control :)
Steven Kirk
@grokys
Aug 27 2015 20:56 UTC
sorry i disagree... i'd much prefer that each object was in control of its own initialization
José Manuel Nieto
@SuperJMN
Aug 27 2015 20:56 UTC
it's your point of view
imagine you want to make user controls load from a json file
you will have to modify Perspex
to use whatever method you want
maybe it's not difficult, but my idea is that Perspex should not depend on any Markup
Markup should be an accesory
WPF always tried to load from XAML
it's so attached that is harmful
do you imagine how could you make WPF load from yaml?
or fxml?
Steven Kirk
@grokys
Aug 27 2015 21:00 UTC
but how is that related to XAML?
José Manuel Nieto
@SuperJMN
Aug 27 2015 21:00 UTC
I don't understand
Steven Kirk
@grokys
Aug 27 2015 21:01 UTC
i don't understand how json, yaml, fxml etc is related to omnixaml?
José Manuel Nieto
@SuperJMN
Aug 27 2015 21:01 UTC
I'm offering you reasons why I would keep the loading out of the controls
ahh, OK
I'm saying that you could swith the markup inflate mechanism anytime
(if you take out the loading responsibility from the controls)
Steven Kirk
@grokys
Aug 27 2015 21:02 UTC
i think i see what you're saying, but i strongly disagree
José Manuel Nieto
@SuperJMN
Aug 27 2015 21:02 UTC
about the loading inside controls?
Steven Kirk
@grokys
Aug 27 2015 21:02 UTC
if i'm writing a class, i should be able to control how that class loads its controls
José Manuel Nieto
@SuperJMN
Aug 27 2015 21:02 UTC
yes, but...
Steven Kirk
@grokys
Aug 27 2015 21:02 UTC
imagine i'm writing a library for 3rd parties to use
i create a UserControl that they can put in their XAML
i want to be damn sure that i'm in control of how the controls in that UserControl get created
José Manuel Nieto
@SuperJMN
Aug 27 2015 21:03 UTC
the loading part is so generic that you could consider that inflating is not dependent on the control, but on the markup
haha, OK, but now you are free to do it
I understand your point
and WPF Team did it like that
it's a matter of deciding about the design
Steven Kirk
@grokys
Aug 27 2015 21:05 UTC
i understand your point, but i think by doing that, XAML is fundamentally overstepping it's mark and messing with things that aren't its responsibility
José Manuel Nieto
@SuperJMN
Aug 27 2015 21:05 UTC
It's for that why it's on AppServices
Steven Kirk
@grokys
Aug 27 2015 21:06 UTC
ok, so i can remove that part
i'd much rather things be explicit
José Manuel Nieto
@SuperJMN
Aug 27 2015 21:06 UTC
You can :)
being explicit is OK!
AppServices is to make your life easier when you want to create things that are defined in XAML
I don't want OmniXAML just to be able to read XAML
but to be a framework
Steven Kirk
@grokys
Aug 27 2015 21:08 UTC
ok, yeah that's fair enough
José Manuel Nieto
@SuperJMN
Aug 27 2015 21:09 UTC
WPF does a lot by itself! So I didn't want people to have to be forced to modify their clases in order to be inflated
Steven Kirk
@grokys
Aug 27 2015 21:10 UTC
i assume that by auto-inflating UserControls you wouldn't have access to the controls in the constructor either
José Manuel Nieto
@SuperJMN
Aug 27 2015 21:10 UTC
for me it's better that you could decide "hey, I want my user controls to load themselves" than I saying "Steven, you are forced to create a load method for each control you want to load... "
Steven Kirk
@grokys
Aug 27 2015 21:10 UTC
i much prefer the latter ;)
José Manuel Nieto
@SuperJMN
Aug 27 2015 21:11 UTC
haha, then I say you so!
You HAVE to implement that :P

i assume that by auto-inflating UserControls you wouldn't have access to the controls in the constructor either

I will have to figure out how to deal with named items

Steven Kirk
@grokys
Aug 27 2015 21:12 UTC
you won't be able to load the xaml until after the constructor has finished though
José Manuel Nieto
@SuperJMN
Aug 27 2015 21:12 UTC
WPF has autogenerated code ...
with my autoinflating method, the instance is created first
and then, it's inflated
Steven Kirk
@grokys
Aug 27 2015 21:13 UTC
yeah, so no controls in the constructor
José Manuel Nieto
@SuperJMN
Aug 27 2015 21:13 UTC
so, you won't have access to anything
until the loading is done
yes
Steven Kirk
@grokys
Aug 27 2015 21:14 UTC
wouldn't be a big deal anyway
José Manuel Nieto
@SuperJMN
Aug 27 2015 21:14 UTC
if you add controls to Children, the inflate process won't destroy them
but it will replace values
children are added
values, replaced :P
Steven Kirk
@grokys
Aug 27 2015 21:15 UTC
it will replace e.g. UserControl.Content then
José Manuel Nieto
@SuperJMN
Aug 27 2015 21:15 UTC
yes
but, well.. I imagine that if you are using the autoinflate method, you don't want to create the controls without markup
anyways, you could implement your inflater
Steven Kirk
@grokys
Aug 27 2015 21:16 UTC
anyway, loading xaml from resources is now on master
José Manuel Nieto
@SuperJMN
Aug 27 2015 21:16 UTC
maybe one that notifies you when the inflate process is done
OK! I will update and take a look :D
Steven Kirk
@grokys
Aug 27 2015 21:19 UTC
just going to move the test projects into a Demos folder on disk
José Manuel Nieto
@SuperJMN
Aug 27 2015 21:21 UTC
soooo nice
congrats!
Steven Kirk
@grokys
Aug 27 2015 21:21 UTC
:) congrats to you too!
great work!
José Manuel Nieto
@SuperJMN
Aug 27 2015 21:22 UTC
I love how Perspex work
the DevTools are really cool!
controls highlight when you hover the cursor :D
thank you !
Steven Kirk
@grokys
Aug 27 2015 21:22 UTC
yeah, but the DevTools window slows things down so much
i need to work out why
José Manuel Nieto
@SuperJMN
Aug 27 2015 21:23 UTC
too much info to so
Steven Kirk
@grokys
Aug 27 2015 21:23 UTC
yeah, but it should be able to handle it
José Manuel Nieto
@SuperJMN
Aug 27 2015 21:23 UTC
I've leaving for now
Steven Kirk
@grokys
Aug 27 2015 21:23 UTC
the layout system needs more optimization
ok, good night!
thanks for the help
José Manuel Nieto
@SuperJMN
Aug 27 2015 21:23 UTC
it's been a good day with interesting discussions!
good night, bro!
Steven Kirk
@grokys
Aug 27 2015 21:23 UTC
definitely! :)
José Manuel Nieto
@SuperJMN
Aug 27 2015 21:23 UTC
keep it up!
Steven Kirk
@grokys
Aug 27 2015 21:24 UTC
you too!
José Manuel Nieto
@SuperJMN
Aug 27 2015 21:24 UTC
I don't know why Perspex doesn't have an army of developers wanting to join!
it well deserves it
see you :D
Steven Kirk
@grokys
Aug 27 2015 21:25 UTC
see ya!
Steven Kirk
@grokys
Aug 27 2015 22:22 UTC
well, after saying the layout is slow, i found that it was actually doing the arrange pass twice! grokys/Perspex@1c58e15
that'll slow stuff down
should now be twice as fast after removing that line ;)