freenode/#clim - IRC Chatlog
Search
7:22:47
ck_
All I can say is that I can modify the bezier thing with the (cond ...) form, but not with the (case ...) variant
7:27:25
scymtym
jackdaniel: if trying things on windows is inconvenient, gtk also has an inspector: https://blog.gtk.org/2017/04/05/the-gtk-inspector/ . i'm not sure how "semantic" it is, but i assume the concept is the same
7:29:05
jackdaniel
sure, but I still don't see how that helps with automatic ui conversion for disabled people?
7:30:31
scymtym
it's really simple: https://developer.gnome.org/accessibility-devel-guide/stable/dev-start-5.html.en
7:33:07
scymtym
i was joking, of course. but seriously, i think it is a combination of automatic inspection and "annotations" using the atk infrastructure
7:38:45
scymtym
i don't think it does anything fancy. i think it is an API for programming queries like "give me all text objects and buttons currently on screen along with their annotated role"
7:40:31
scymtym
for a cooking application it might answer with: image annotated "picture of finished dish", bullet list annotated "list of ingredients", bullet list annotated "list of steps to prepare the dish"
7:42:29
scymtym
an accessibility application can read this information to the user so they know what information is being presented and e.g. choose on the items
7:45:22
scymtym
i don't know the details, but i think it can do some things automatically based on the structure of the application. maybe skipping over things like container widgets
7:46:40
jackdaniel
so given all presentations have an annotation (so they may be present-to-string), gathered automatically or not, then reading them on the screen is a matter of defining a stream with +reader-view+ where method present "reads" said annotations?
7:49:59
scymtym
i agree that a clim-based should have a good amount of meta-data available when it comes to presentations and commands
7:57:57
scymtym
unrelated: https://www.youtube.com/watch?v=E3GdMyB_PM0&feature=youtu.be&t=65 got me thinking about always including an interactor (i almost always use the layout (vertically <pane with application content> box-adjuster interactor pointer-documentation)). but in this case, the interactor provides no value to the user and takes up screen estate. so maybe i should always provide two layouts, one with and one without the interactor
8:00:09
scymtym
more generally: should we try to promote the command-loop paradigm (interactor, named commands, etc.) or cater to new users and e.g. hide the interactor by default
8:00:56
jackdaniel
I think we should promote command loop paradigm but in a form of a listener (which is both repl and interactor)
8:01:18
jackdaniel
that would require refactoring or creating a new listener which may be used as an ordinary pane
8:03:13
scymtym
it would be cool for tools like the debugger or inspector to have a REPL in the interactor
8:14:55
ck_
using the emacs SMerge tools for conflict resolution is an exercise in self flagellation
8:25:29
loke
ck_: do you happen to know which triangulation algorithm is easiest/fastest? I'm googling and finding a few different ones.
8:27:04
ck_
the easiest is probably the "get upper and lower boundaries, walk them until they don't form a star-shaped region, triangle-fan it, move on" one I guess
8:27:24
ck_
I forget the names but they're in a folder somewhere over there <---- I'll get back to you
8:30:50
jackdaniel
loke: when you implement such algorithm please put it in regions.lisp, it may be useful not only for rendering
8:47:04
scymtym
jackdaniel: what do you normally use for switching layouts? named commands won't work if one layout hides the interactor
8:51:01
jackdaniel
interactor is just a "gadget" to type commands, to see that they still work put :menu t with some command
8:51:16
scymtym
when i define and use a layout that does not include an interactor pane, presentations in my "content" pane are not sensitive
8:54:09
scymtym
switching the layout to the one without the interactor makes the presentations no longer sensitive
8:57:19
jackdaniel
spec says, that standard-output is bound to the first visible defined application-pane and if not present, first visible defined interactor-pane
8:57:34
jackdaniel
standard-input is similar, but in reverse order (interactor-panes are taken before application-panes)
8:58:14
scymtym
yeah, i solved that problem, but some commands are pretty weird when the input/output stream is an application pane instead of an interactor
9:14:33
ck_
loke: do you have any restrictions on the regions you're wanting to triangulate? If you can narrow it down from the general position of vertices, it would be helpful
9:16:45
ck_
here's an early linear-time algorithm: https://link.springer.com/content/pdf/10.1007/BF02574703.pdf -- you can see how involved it can get with arbitrary polygons
9:17:20
ck_
here's an n log log n one: https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.186.5949&rep=rep1&type=pdf
9:54:23
ck_
you must have more than that, an edge list maybe? I mean the ordering is given, right, it's not a set of vertices
9:55:56
jackdaniel
a few months back I've improved 10x time of deciding whenever point belongs to a polygon
9:57:52
loke
jackdaniel: what algorithm did you use? (there is an obvious one, which is to draw a line from the point to some other point that is guaranteed to be outside the polygon, and then count how many times that line crosses any of the edges.
10:07:08
ck_
loke: that's a pretty nice looking convex polygon. for those, just pick a vertex (maybe the lowest-leftmost one) and connect the edges to it.
10:07:36
ck_
if you want a general, always-applicable implementation though, you'll have to either use a library or go paper reading
10:18:28
ck_
The first one I pasted earlier is a good start I think, we could go through the who-cites list and see what the current state of the art is
10:18:53
ck_
judging from your second example, though, I think a partitioning into convex parts seems like a possible choice
10:19:47
ck_
well, then again, it depends. Is the self-intersection near x=100 intentional or an artifact?
10:20:54
loke
There shouldn't be any self intersections in that one. But, it's what is output from cl-vectors, and if we can't use that output we have a bigger problem (and a lot more work on our hands)
10:22:01
jackdaniel
loke: regions may have self-intersections (and draw-design works with that faiirly well)
10:22:49
loke
ck_: This is the input, with the #+nil removed: https://gist.github.com/lokedhs/4afe548554083ee2c39684b1387858a0
10:23:25
jackdaniel
but for sake of drawing I don't think cl-vectors will output anything like that for you
10:24:24
loke
jackdaniel: Yeah, I was just wondering if we need to deal with that once we move draw-design to Xrender
10:25:06
ck_
I don't think I have the full picture yet, but if what i right now suspect is true, there's probably a much better way of obtaining the triangulation of such objects
10:25:08
jackdaniel
I would expect that to work, there is no limitation about points in polygon in the spec
10:29:00
loke
So at least initiaqlly I'd like to use the most correct of algorithms (even if it's slower)
10:35:13
ck_
I understand the motivation, but the part where you create polygons with self-intersections throws a wrench in that plan in my opinion
10:39:00
ck_
loke: what I mean is, you're using cl-vectors for the boundary line segments, and that's what you want to use for the triangulation -- have I got that right?
10:39:43
loke
ck_: right now, yes. The reason I need to do triangualtion is because cl-vectors gives me concave polygons (without intersections, as far as I know)
10:40:20
loke
ck_: later, we need to deal with self-intersections, because DRAW-DESIGN supports it (this use-case probably does not involve cl-vectors)
10:42:02
loke
anyway, if we have an algorithm that can hadle intersectins, then it can be used everywhere.
10:42:25
loke
Are you saying we don't havwe such algorithm? Or that such algorithms are not something we want to use (slow?)
10:44:21
ck_
I'm saying that I'm uncomfortable doing both in the same piece of code. Triangulations of intersection-free polygons are a nicely solved problem.
10:45:22
ck_
If you give me a sequence of boundary line segments that intersect, who's to say what the inside really is? I'd really like to avoid it
12:29:00
scymtym
i tried incrementally changing the old inspector first, but there was no clear path from the old implementation to the new one
12:30:18
scymtym
jackdaniel: which version of the documentation is the canonical one? html or texinfo?
12:35:46
beach
I don't think that has been decided, but if jackdaniel thinks the Texinfo one is better, then go for that.
13:22:06
ck_
right now, you have [path as mathematical line] -> [cl-vector] -> [boundary of path as sequence of line segments] -> [ here be dragons ] -> triangle soup
13:22:38
ck_
and the cl-vector part you want because of the way the paths can be joined and beveled and whatever the names for the frills are
13:24:08
loke
ck_: Yes. Splines will be needed too. Remmeber the end goal is to support all CLIM operations. We know cl-vectos is capable of this, since it's already used for the render backend.
13:25:14
loke
I mean, I can write an algorithm that does it the "hard way" but it'll be crappy and slow.
13:27:29
ck_
you'll find that is often the case, but if you look at the earlier papers, they're often a little simpler and don't hold back so much
13:27:48
ck_
it's a shame that the kind of technical report they had in the 70s or 80s are no longer the standard
13:28:47
ck_
I can put in an evening at the library for this, that should give us plenty of references to read through next weekend or something
13:28:58
loke
The paper I was reading had code for the general outline of the algorithm, but that function called a magic function that did the actual computation described in the paper, and there was no source code for that one(!)
13:30:03
loke
I wonder if I should take alook at the source for something like Cairo. Perhaps there are refences in the code for the algorithms used
13:30:11
ck_
how about "we can triangulate the two examples from earlier and have a visualization for the triangles" as a first milestone
13:30:39
ck_
you could, but I wonder whether they do a triangulation. Isn't cairo mostly rasterization?
13:34:27
scymtym
and no, i'm neither procrastinating nor distracting myself from finalizing the branch: https://techfak.de/~jmoringe/debugger-inspector.png
13:35:47
jackdaniel
I think we need to remove Latex documentation (if someone changes mind about the canonical one they could review it from git history)
14:08:19
ck_
okay let me see if the canonical book, which is Marc de Berg et al.: Computational Geometry, is available somewhere
17:25:48
pouar
ping jackdaniel I kinda missed the live stream, but if you do implement theming, can you make sure it is not limited to just Material Design, as I kinda find flat themes ugly
17:39:18
jackdaniel
pouar: thanks. theming is a matter of implementing a frame manager which /does the thing/, so adding material design won't limit other possibilities (it won't make them easier neither, maybe except that there will be an example of how to do that)
18:23:18
ck_
jackdaniel: could you link me to your winding number test please? We will probably want that for polygon simplification