freenode/#shirakumo - IRC Chatlog
Search
8:39:49
scymtym
Shinmera: i have been thinking about that as well. want to compare notes at some point?
8:43:09
Shinmera
Here's my use-case right now: typically an outside system using Alloy will have its own event types. I'd like it to have "zero cost" event mapping to Alloy's event types by adding them as traits to the instances and implementing the necessary methods to fetch the data. In Alloy itself the event dispatch would then work as if you had created actual instances of the event classes.
8:43:55
Shinmera
So my current problem is primarily about adding type information to an instance without creating a custom subclass.
8:44:58
Shinmera
Possibly something could be done like creating a class without associating it with a name and then change-classing to that, but that would change the class-of result to one that "doesn't exist", so I don't know if that's great.
8:47:24
scymtym
i'm not prepared for this discussion right now, but the insight i had was that determining trait membership is allowed to be expensive since it can be cached and baked into a normal CLOS-style dispatch based on the object class
9:16:14
|3b|
ACTION might end up implementing some of pathfinder anyway... thinking about what i want from a 2d drawing lib, and wondering if it is worth implementing the simple version or if i should just go straight to a 'real' one
9:17:50
|3b|
original idea is just doing things like draw a quad, chops off ends in shader to make round ends, etc
9:19:15
|3b|
but by the time i've added variants for drawing curves, stroked rounded rectangles, polylines with fancy joins, etc, the 'simple' version starts getting complex
9:20:09
|3b|
so might be easier to just start writing something general purpose like pathfinder and use that instead
9:21:33
Shinmera
The interface I use in Alloy at the moment is purposefully very stumped to make it easier on backend implementors
9:22:08
Shinmera
But I have been thinking about adding stuff like bezier curves, and then you quickly get into that same problem.
9:56:22
|3b|
looks like nv style needs lots of stencil buffer multi-samples to get good AA, so guess i'll start with pathfinder tiling and see how it does
9:58:32
|3b|
probably 90% of what i'd want it for would be simple UI stuff where it would be trivial to build, and most of the rest would be on higher-end systems where i could offload it to compute shaders or something
11:15:09
Shinmera
I've been thinking about how to tackle the problem of allowing the user to react to changes happening in the UI without having to subclass.
11:16:02
Shinmera
Currently the only idea I have is something where each component has a list of handlers that call a user function on certain events.
11:16:26
Shinmera
Which is very much what all other systems do, so I wonder if there isn't something else that could be done, too
11:19:32
Shinmera
I /guess/ there could be EQL methods, but that would leak runtime data into the global space (and prevent GC)
11:20:51
Shinmera
I feel a bit trapped at the moment because all of the issues in Alloy that I can see I don't understand well enough to want to implement anything for at the moment.
15:36:45
gingerale
Shinmera: Any particular reason why you don't want to do it the way other system do things?
15:37:38
Shinmera
Especially because most other systems don't have the semantic possibilities of Lisp available
15:55:10
Shinmera
I suppose Qt's method of slots and signals is kinda like a hybrid of handlers and methods, since you can't connect signals to lambdas
15:55:54
Shinmera
Which is worse, because now you have the complexity of a handler list plus a necessary global space function polluting stuff.
15:58:04
Shinmera
JS does a generic handler list thingy, where if an event is created on an element all of its associated handlers are called.
15:58:39
Shinmera
AWT/Swing is more explicit by requiring special interfaces and classes to handle stuff because there's no dynamic lambdas available.
16:09:42
ShinmerAgain
I suppose one of the issues I have with the event system is that now, every change needs to be realised as an extra container type, so you not only need the funtions to programmatically cause the change, but also event classes to represent them
16:12:09
ShinmerAgain
I guess one could register events on the functions themselves, but then you lose type relations, and the functions would still have to manually invoke the "signalling" of the handlers.
16:12:58
ShinmerAgain
The latter could be solved via a macro or custom method combination, but both are annoying because we're stepping away from "simple CLOS"
16:13:51
ShinmerAgain
Type relations could be alleviated by allowing the user to tie a graph between functions manually.
16:24:47
ShinmerAgain
Reconciliating the function arguments between these relations might be tough though
17:43:31
Colleen
irclog.tymoon.eu/freenode/%... Website (XHTML), Title: freenode/#shirakumo - IRC Chatlog
17:52:30
gingerale
Hmm.. Not really. I can't see what layout scroll recomputations needs because I'm not familiar with that part of Alloy. And the instance styling has a similar issue for me besides "these parameters of this style class can be changed in this manner."
17:53:48
Shinmera
Layout scrolling is the issue of: how do I know for which elements to recompute their size when only few of them will be in view after the size change
17:54:06
Shinmera
recomputing size for all of them can be very expensive if you scroll through, say, thousands of elements.
18:01:23
Shinmera
The scrolling thing has another problem, which is a bit simpler and potentially even solvable
18:01:40
Shinmera
Which is, given a view area how do we only draw what's visible rather than everything
18:02:14
gingerale
Hmm.. Layout scrolling reminds me of weird browser behaviour if you update a lot of elements that aren't even visible. On Chrome the scroll bar starts changing size and not updating the bottom-most elements at all even once visible.
18:02:37
Shinmera
This seems easier than it is, because the part that represents a scroll area is not the part that controls how the elements are laid out inside the scroll area
18:03:26
Shinmera
Unless we make the scroll area a layout itself, but then you'd have to have a scroll+layout class for every layout out there.
18:07:40
Shinmera
There's the logs in here, and some videos from the early design phase when I was doing live streams: https://www.youtube.com/playlist?list=PLkDl6Irujx9NUeqnEkRsFZ6bLS24B-6lT
18:07:54
Colleen
reader.tymoon.eu/article/376 Website (XHTML), Title: The End of Daily Gamedev - Confession 87 - 妖怪世捨て人
18:08:40
Fade
ah. well, thanks for all that effort. I learned some things and enjoyed it throughout.
18:11:13
Fade
90% of my day is reading and figuring things out, and like 3% coding, when it's a very productive day.
18:14:54
Shinmera
At least for the scroll area rendering I suppose it could usurp rendering from the layout by using the container's iteration protocol
18:15:35
Shinmera
Which would solve the problem with the exception of if the layout itself has stuff that it wants to draw aside its elements.