freenode/#clim - IRC Chatlog
Search
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)
16:55:11
jackdaniel
everyone values their time above others, so asking people to review tickets which are not well formatted (or making pull requests which are code dumps) usually doesn't fly
16:59:07
jackdaniel
for instance making a honest peer review of a small non-trivial change may take a few hours (sometimes a day or more if there are doubts about some solutions) -- I'm saying that to share some experience (not to reproach you)
17:05:02
Inline
issue is this: i tabify a file and afterwards some words are almost like condensed together like (and (symbolpsym)) the thing is when i open it with emacs there's a real space, so nothing seems wrong but in climacs after selecting whole buffer and useing M-x Tabify Region on it my display is like i told at the beginning, some words seems like writ together, they are not ofc the space is there too but the cursor