freenode/#clim - IRC Chatlog
Search
14:53:37
jackdaniel
the problem with this approach is that it makes sheet-native-transformation useless (and incorrect) when we leave the x11 land, yet it is baked in the core
14:56:57
jackdaniel
well, maybe usless is not a good word. it still has some use for unmirrored sheets
15:12:39
jackdaniel
I'm not saying that sheet-native-transformation is useless as a concept, I'm saying that it is always identity-transformation for a mirrored sheet (and comment in the file mirrors.lisp confirms that), because how swizzling is implemented
15:15:39
beach
Clipping has to be implemented anyway if mirroring is not used, and you told me that single-mirror frame managers work.
15:16:25
jackdaniel
it does work, I'm saying that relation between mirrors is also enforced in that file
15:17:09
beach
So what are your conclusions from that? It sounded to me like your phrase would continue with something like "so your idea won't work".
15:18:01
jackdaniel
that was observation related to coordinate swizzling implementation, not that your idea won't work
15:18:44
beach
With my idea, coordinate swizzling won't be necessary even when some non-top-level windows are mirrored.
15:19:30
beach
But without the restrictions of the single-mirror frame manager (that often makes foreign gadgets impossible).
15:20:24
jackdaniel
the problem I have encountered regarding swizzling is more mundane than that: when I adopt a mirrored sheet to a graft and move it, it is not reflected in the sheet region nor the sheet native region, only in the "mirror" properties
15:20:56
jackdaniel
so from a backend writing perspective, they have to reach outside the clim specification and use interfaces that are tied to the imlementation of coordinate swizzling
15:21:39
beach
That's not good. I myself have encountered bugs with scrolling, but I have mentioned that before, and they have probably been fixed a long time ago.
15:22:01
jackdaniel
right, I'm looking at the whole thing now from a perspective of the manual for backend writers
15:22:30
jackdaniel
(and some things I'm saying may be incorrect - I'm just expressing my current thought how this works)
15:23:23
beach
Well, if the problem can go away by just not mirroring the viewport pane (or some other child of the scroller pane) then that would simplify your manual too.
15:23:59
jackdaniel
I'm reasoning on a lower level right now - mirrored and unmirrored sheets (and sheet protocols), no panes and viewports
15:26:15
beach
Perhaps REALIZE-MIRROR should do nothing for most sheets if the port does not support nested windows.
15:27:30
beach
I don't think you have to worry about that. They layout protocol will change the position anyway.
15:27:52
jackdaniel
(usually, when the port does not support nested windows, the sheet won't be a subclass of the mirrored-sheet-mixin, so realize-mirror won't be called on it)
15:29:07
beach
As I recall, we concluded that it was not reasonable to have two sets of each pane type, one that is a subclass of mirrored-sheet and one that is not.
15:29:36
beach
So then, it is not up to the sheet class to determine whether a mirror should be created or not.
15:30:24
jackdaniel
it is the frame manager that mixes in the mirrored-sheet-mixin to appropriate panes (creates new classes), so that's how we currently realize the port mirroring strategy
15:30:32
beach
Yes, but the existence of the layout protocol means you don't have to care about the position of the mirror when it is created.
15:31:00
jackdaniel
unless we want to allow building non-clim toolkits on top of the silica part of the specification
15:31:55
jackdaniel
adding a mirror to each class was already part of clx backend when I have joined the project
15:32:58
jackdaniel
that mechanism was already there when I have joined the project, I don't know how introduced it
15:34:03
beach
I still suspect that all that complication would have been avoidable if we had let the port decide whether a mirror should be created for mirrored sheets.
15:34:09
jackdaniel
either way, ignoring mirrored-sheet-mixin completely seems to be at odds with the specification
15:40:57
jackdaniel
looking at the clim-tos source code, top-level-sheet is mirrored and its children are not - and it is decided on the class hierarchy level
15:41:31
jackdaniel
silica provides a set of other classes that are usable without using frames (i.e standard-mirrored-sheet that incorporates all necessary mixins)
15:42:01
jackdaniel
in other words, they do not put a burden of deciding what is mirrored on the frame manager
15:42:30
jackdaniel
individual gadgets from backends are explicitly mirrored, because they use "native" widgets
15:43:03
jackdaniel
that sounds very similar to what you have mentioned (and is much of course much cleaner)
15:45:19
jackdaniel
from things used in a frame yes (unless you create your own pane that is mirrored - mirrored sheets may be adopted like others)
15:47:41
beach
And it would remove all this complication that I mentioned and that I was always uncomfortable with.
15:50:44
beach
Yes, that's a good thing. I try to mention as often as possible that I appreciate all the good work y'all are doing.
15:56:49
jackdaniel
funny times in poland right now, joined forces of military and police "isolate" our parliment from protesters (https://pbs.twimg.com/media/EnHN0w2VkAEtwMu?format=jpg&name=900x900)
16:05:05
beach
How long would it take to clean up all this complication, to unmirror the panes, and to get rid of coordinate swizzling? I.e., how much money would I have to come up with?
16:07:03
beach
By "this complication" I mean that the frame manager decides what panes and gadgets should be subclasses of mirrored sheet.
16:11:45
beach
I can see how this complication happened. We made the mistake very early on to think that pretty much all panes should be mirrored, thinking that all display servers supported that.
16:11:48
beach
Then, gilberth ran into the 16-bit limit of X11 coordinates, so he invented coordinate swizzling.
16:11:55
beach
Then, to support display servers without nested windows, it had to be possible to alter the class hierarchy so that panes were not mirrored.
16:13:21
beach
All this, because the specification was not sufficiently clear about what panes and what gadgets should be mirrored, and because of our naivete as CLIM implementers.
16:14:58
jackdaniel
regarding your earlier question - I will do that anyway because that sounds like an improvement, but if you want to hire me to do that, then I think that 1000 euro greatly benefit me
16:15:58
jackdaniel
as of the price to pay for gaining knowledge, I find having clim-tos sources available as a reference very informative
16:16:12
jackdaniel
even if we disagree with some implementation choices, that gives some other perspective
16:20:26
jackdaniel
(answering my question from before: the initial position of the mirror should be the sheet-region transformed by a delta transformation between the newly created mirrored sheet and its mirrored ancestor)
16:30:32
jackdaniel
by mirrored ancestor I mean a result of calling sheet-mirrored-ancestor on its parent (because said function may return the argument itself if it is mirrored)
16:34:34
loke
jackdaniel: I'm working on a new plotting system for Climaxima. Do you know how stable the double buffering support is?
16:58:25
scymtym
we could soon have double buffering as a port option if loke wants to experiment with it
17:01:15
jackdaniel
btw, I'm thinking about adding a new backend function and extend existing interfaces: https://github.com/McCLIM/McCLIM/pull/1102
17:01:56
jackdaniel
most notably there is graft-pixel-aspect-ratio which allows us to work with non-rectangular device units
17:05:16
scymtym
pixmaps and pixel aspect ratio seem orthogonal to double buffering or am i misunderstanding?
17:06:33
jackdaniel
aspect ratio is orthogonal, however pixmaps - not so much. double buffering at least could be implemented by having the drawable default to a pixmap and copying area as the buffer swap operation (or flush)
17:10:11
scymtym
at least on windows using pixmaps would complicate things. i think my X double buffering also uses X concepts directly