freenode/#clim - IRC Chatlog
Search
4:43:05
loke
jackdaniel: My markup renderer (that renders the texinfo content) uses its own way to draw text that handles things like word-wrap, proper baseline for multisized text etc. It all boils down to DRAW-TEXT* in output records.
4:43:53
loke
Now, I was wondering, would it make sense to rewrite the current text-selection stuff to handle _any_ output record that contains text? (i.e. traverse the output record tree looking for DRAW-TEXT-OUTPUT-RECORD)?
4:44:40
loke
I'm willing to experiment with it, but I'd just like to know if this is something that has been contemplated?
4:45:23
loke
(by the way, the existing text-selection stuff breaks when you have text written to output records that are subsequently moved. the highlighting gets confused about the order of the text blocks)
5:14:49
beach
I have his email. Last time he went missing (and then came back), he encouraged me to check on him by email.
5:31:15
beach
jackdaniel: Maybe I'll write it down. Today is Monday, and Monday mornings are chaotic around here. I will be on and off all morning. It might be better to have a document to discuss.
6:36:36
slyrus_
hmm... I won't have time to track this down for a few days but recent changes totally broke gantlet's scrolling behavior.
8:20:18
jackdaniel
hold your horses, instead of reverting *whole* change maybe think how to fix the regression
8:20:57
jackdaniel
you've already identified the commit, issue is evidently in typecase leg "key-press-event"
8:22:56
beach
OK, I'll work on it today. I need to read three things in parallel. The spec, what nyef wrote, and what you wrote.
8:23:38
jackdaniel
it won't hurt if you also read what clim-tos does (I did), because it originates from the reference implementation
8:37:58
jackdaniel
I'm going to fix breakfast, please point me to a document you wrote, I'll study it and when we both have time we may discuss all three
9:43:24
jackdaniel
fact: in mcclim clim-stream-pane inherits first from standard-extended-output-stream and *then* from standard-output-recording-stream (so if gf has method specialization on both, standard-extended-output-stream's will be called)
9:44:04
jackdaniel
I want to change that order, because recording is an abstraction layer above seos
9:44:50
jackdaniel
the only thing which seems to suggest otherwise is a loose wording in clim-stream-pane (I don't think this is written this way to estabilish precedence order): "This class implements a pane that supports the CLIM graphics, extended input and output, and output recording protocols. Most CLIM stream panes will be subclasses of this class."
9:45:44
jackdaniel
what do you think? (I can easily make a workaround for that in a form of around method, but this seems better organized)
10:14:20
jackdaniel
I think that calling handle-repaint (instead of repaint-sheet) for repaint events will lead to overexposing parent sheets when a region is damaged
10:15:37
jackdaniel
clarification about clim-tos: queue-repaint either puts event on a queue, or handles it immedietely
10:16:37
jackdaniel
and "the program that handles the event" – because it may be that queue-event handles it
10:17:04
beach
That's very unfortunate to have a function named QUEUE-EVENT not always queue the event.
10:18:16
jackdaniel
superficially it is a queue where pregnant ladies are served first (immediate sheets). the only functions there are are dispatch-event
10:19:00
jackdaniel
(I have mixed feelings, on one hand it sounds like a good idea, on the other it complicates event processing model - more moving parts)
10:19:27
beach
I am not saying we should do it, at least not right away. I am saying we should not modify the specification to rule it out.
10:20:36
jackdaniel
sure, I get that. either way specification as it is now is not very good (and I have an impression that it does not show any implementable strategy)
10:21:20
jackdaniel
do you agree with suggestion, that repaint-sheet should be called to prevent overexposing parent sheets?
10:22:19
jackdaniel
port generates window-repaint-event with a region which needs to be repainted for a top-level-sheet
10:23:41
jackdaniel
which is specified to call either handle-repaint or repaint-sheet (what is our matter to clarify)
10:24:03
jackdaniel
if handle-repaint is called, only top-level-sheet is repainted (that is background is slapped on top of damaged region)
10:24:18
jackdaniel
if repaint-sheet is called, then background is called and then its children are repainted
10:26:58
beach
It is specified to queue the event, and the thing that dequeues the event calls handle-repaint.
10:26:59
jackdaniel
yes, it is specified to call handle-event using "the repaint region from repaint-event"
10:28:16
jackdaniel
first we can't call handle-event with region (so this is clearly bogus), so what dequeues event should call handle-event with the event, and that method should call [either handle-repaint or repaint sheet]
10:29:26
jackdaniel
from wording in handle-repaint I have a very strong impression that it performs only drawing specific to a sheet, while repaint-sheet performs drawing of a sheet and its descendants
10:30:39
beach
methods on handle-repaint can do things other than calling repaint-sheet, including not doing anything for instance.
10:34:37
jackdaniel
that is not very convincing to me: queue-event indicates a will to put an event in a queue, how implementation handles it (i.e bypasses the queue for special events) is at its discretion.
10:35:33
jackdaniel
regarding handle-repaint, if it is not handle-repaint what implements primitive drawing on a sheet, then we need to come up with custom internal protocol for specifying how sheets are painted (i.e what calls replay)
10:36:48
beach
I am sorry, but this is too detailed for me. If you think I am wrong, go ahead with your suggestion.
10:37:50
jackdaniel
OK, thank you for writing that up and a discussion. I let some time pass and try to rethink it given all of the above
10:46:00
beach
Apparently, the demo by gilberth does something similar to what I suggested: "Drawing only happens in HANDLE-REPAINT and no where else. Altering the output history just updates a dirty region in the output history object, which is picked up by another thread which calls HANDLE-REPAINT as necessary. This even applies to sheet geometry, changing the size of a sheet does not make it to the window server immediately, but is picked up by
10:47:37
jackdaniel
right now event loop is implemented so it works even on implementations which do not have threading at all (that is worth keeping in mind that spec also suggests that applications should run in such environments)
10:48:41
loke
jackdaniel: but wasn't that part of the spec written at a time when such systems were actually used much more widely than today
10:49:30
jackdaniel
I've put recently a considerable amount of time to make it work again on single-threaded implementations (that shows I do care about that)
10:50:12
beach
jackdaniel: Right, I am not suggesting making it a requirement to be multi-threaded. All I am saying is that we should think twice before modifying the specification to rule it out.
10:50:52
loke
ACTION actually believes that having all the UI stuff in a single thread makes sense, and is in line with what pretty much every other UI toolkit does as well. That include Java and Android
11:36:32
jackdaniel
nb: fact that you have elaborated on your handle-repaint interpretation sheds more light on why you do disagree (it makes more sense than without that particular bit)
16:19:21
Inline
i found that tabify sneaks in tab characters into my files without checking for if use-tabs is set or not
16:33:00
jackdaniel
Inline: please write cleaner issue reports, it will be easier for us to process them (and that makes them more likely to be fixed in a timely fashion)