freenode/#clim - IRC Chatlog
Search
7:58:22
slyrus
jackdaniel: I'm not sure I follow what you're getting at. The :borders nil thing definitely seems bogus to me and we should fix that immediately. The larger issue I don't feel like I understand well enough to weigh in yet.
7:59:18
slyrus
Some knucklehead writes in an annotation on application-pane in the spec: "Is there somewhere in the spec where the superclasses of application-pane are listed? In McCLIM, it is a subclass of clim-stream-pane, but it doesn't seem that the spec says that this has to be the case."
8:00:24
slyrus
Earlier on in the page it says: "Most CLIM stream panes will be subclasses of this class."
8:17:54
jackdaniel
I'm getting at that this PR just solves your immediate problem while I think we have more systematic issue which is very much possible to solve
8:20:05
jackdaniel
it wouldn't be non-conforming if application-pane would not subclass clim-stream-pane, but a) why wouldn't it, b) even if it doesn't, what does it matter?
8:22:32
jackdaniel
right now the helper macro which creates a panes uses make-clim-*stream-type*-pane if the name is a keyword being a member of (:interactor :application :pointer-documentation), otherwise it simply uses make-pane
8:24:56
jackdaniel
I'm aiming at that make-clim-stream-pane should be used for all pane types which denote streams (and imho even if they are not, we could use this function - that't give us some additional perks)
8:26:20
jackdaniel
so the minimal solution is to remove also `:scroll-bars` from initargs (it shouldn't do a thing anyway, because scroll-bars are not part of stream-pane in light of the spec)
8:28:21
jackdaniel
preferable solution is do the minimal solution, remove the slot scroll-bars and improve do-pane-creation-form to create all panes which are issued as symbols with make-clim-*-pane
10:33:39
loke`
Shouldn't the following be equivalent? I'm in a situation where the first works, but the second gives me no outpout:
10:52:36
loke`
jackdaniel: No. But I noted that it worked if I wrapped all of it inside a WITH-ROOM-FOR-GRAPHICS
10:54:26
jackdaniel
with-room-for-graphics may call implicit replay (or finish-output) when it's done
10:56:03
loke`
Well, I needed the W-R-F-G anyway. But are you saying that it works with it just out of luck, and I should finish output anyway?
10:59:17
loke`
Never mind. Don't waste your time. :-) I'll read it when I get home and gain access to it.
11:48:46
scymtym
jackdaniel: you probably know this: the clx backend dynamically creates mirror(?) classes for panes, including user-defined ones. unfortunately, the cache is keyed on the symbol-name of the name of the pane class, i.e. packages are ignored. i have a simple fix but i wanted to ask whether you already have something more far-reaching planned
11:56:54
jackdaniel
I am aware of that (and I have a plan, but there won't be a conflict with a fix in clx backend)
11:57:41
scymtym
i don't understand, though. if you have a fix planned, wouldn't that make my fix unnecessary?
11:57:53
jackdaniel
as of the plan: frame-managers are underutilized right now, but when (ha ha) I get back to material design I want to write a documentation on them as well
11:59:06
jackdaniel
no, problem is in a default clx frame manager (which doesn't have much use), I want to shed more light on how to use frame managers
12:01:59
jackdaniel
so your immediate fix will affect default clx frame manager while my plan is to enable programmers to supply their own frame managers in order to bypass it if the default one is not to their liking
12:05:03
scymtym
thanks for laying out your plan. i'm not super clear on what frame managers do, but i understand custom frame managers will allow clients to work around the problem (among other things)?
12:07:15
jackdaniel
I was thinking where we could stick the "look and feel realization" without increasing api complexity and frame managers seem to be exactly the place
12:10:11
jackdaniel
but there are no examples nor code I'm aware of which uses that (and it *most probably* doesn't work as expected on McCLIM), so that will require careful documentation and example. it is frame-manager task to do the final mapping between abstract pane and concrete pane class - so we may have different sets of panes for the same port
12:23:42
jackdaniel
but we had also "pixie look" which procured its own api for that (it isn't there anymore)
14:46:05
slyrus
jackdaniel: (backing up a few hours...) the reason it matters to me is that if application-pane really must be a clim-stream-pane (which the spec implies but doesn't explicitly state) then that motivates me more strongly to clean up the initargs.
14:46:34
slyrus
The make-foo stuff is fine, but it should be another way of "spelling" make-instance 'foo IMO
14:47:15
slyrus
and right now we have e.g. :borders as an arg to make-stream-pane but can't do make-instance 'application-pane :borders t, which is lame.
14:53:02
jackdaniel
and my point is that we should clean up the whole thing instead of fixing up the itching part only and forget about the issue until it breaks somewhere else
14:53:37
jackdaniel
so as the minimum please remove :scroll-bars from default-initargs in the ESA module as part of this PR
14:54:08
jackdaniel
and in that case I will create an issue for myself, so I will fix the generated point when I have some time for that
15:16:37
slyrus
what do you mean by "can't make-instance..."? It doesn't work or the spec forbids it?
15:35:40
jackdaniel
(sheets, as abstract entities, may be created in vain, but pane is a concrete realization of the coded concept)
17:43:28
jackdaniel
slyrus: according to 29.9 you may use make-instance. whenever it may be used outside the context of the application-frame is another question (make-pane must be invoked in either :pane, :panes or within with-look-and-feel-realization)
19:35:03
slyrus1
jackdaniel: ok, thanks. The whole :panes thing is nice for quick demos, but breaks down for more complex applications, IMO. But that's the subject for another day's gripe.