freenode/#clim - IRC Chatlog
Search
4:59:58
ck_
loke: tell me if you can use any help with that. I can say without much ego that computational geometry is on my list of things I know slightly more than nothing about.
5:23:35
loke
I experimented with this: https://gist.github.com/lokedhs/4afe548554083ee2c39684b1387858a0
5:24:58
loke
ck_: basically, the PATH library gives you the ability to construct pats with joins and caps that are compatible with what CLIM needs. When iterating over the PATH-ITERATOR, you get line segments and (optionally) arcs that describes the enclosing object.
6:05:03
loke
jackdaniel: The emphasis was more on the fact that I want to make it non-backend-specific
6:07:11
loke
I currently don't know what kind of algorithm to use to split the polygon into triangles. I'm just assuming there are existing optimal ones
6:09:08
loke
I have the polygon stuff doen already using Xrender. However, it currently only supports colours (no patterns, etc)
6:09:13
jackdaniel
loke: right, that's what climb package is for: mixins and utilities which may be shared by backend developers
6:10:31
loke
beach & jackdaniel: a pity the resolution of the recorded stream is low so that reading the text is hard.
6:11:36
loke
But I'm assuming it must have been better, or they would have mentioned it on the stream
6:13:24
loke
Hangout have something called “Hangouts on Air” that allows you to stream a meeting at full quality.
6:14:04
jackdaniel
then someone was recording their own hangouts screen and live-streaming it from their desktop
6:14:06
scymtym
i put the X resource leak fixes i found while playing with double buffering into a tiny pull request: https://github.com/mcclim/McCLIM/pull/796
6:15:12
jackdaniel
I had to use different computer, because google refused to let me on the conference without being logged into their product
6:15:56
loke
jackdaniel: Yeah, you mentioned it on the stream. I was like... WTF!? It's almost like they care more about people getting google accounts and handing over all their information than actually providing a useful service. Funny that.
6:17:22
loke
Did you hear about their new “Shoestring” (“shoelace”?) service they announced recently? It's an implementation of a corner of G+, only available in one city in the US.
6:19:06
jackdaniel
I don't personally care that much about google, not using it except some occasions other people are in their walled garden
6:19:38
loke
Not onyl does it implement the meetings feature of G+. It also seems to be a reimplementation of Google Schemer? (also killed, of course)
6:19:58
jackdaniel
(just like I did not use Windows except few occasions when I had to start a particular program and it didn't run on wine0
6:30:01
jackdaniel
mostly stylistical requests, but I have also one question about presentations, it seems to me that you wrap a presentation inside a presentation during redo
6:32:26
ck_
if that's the case, it's an oversight; it was that way before even during creation. I probably didn't fix it at all points in the code
6:40:47
ck_
I was wondering about line width style guides -- the linebreaks are probably there to not cross the 80 column line.
6:42:14
jackdaniel
it is not a rule set in stone, I'm trying to have average size 80, but if sticking to it uglifies the code then I make an exception
6:55:39
ck_
your comment on using case for the bezier control points won't work because the things aren't eql, I guess
7:02:07
jackdaniel
we bend over our knees to preserve that quality when distributing events for unmirrored sheets
7:10:15
ck_
(case (pointer-event-button event) (+pointer-right-button+ (setf cp-x1 x cp-y1 y)) (+pointer-middle-button+ (setf cp-x2 x cp-y2 y)))
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