freenode/#clim - IRC Chatlog
Search
4:01:27
beach
What I asked jackdaniel to do was the user interface, i.e., panes, menus, maybe "butcons" for different music elements. But I am still going the implementation of the model, and also the exact layout of the symbols.
4:04:11
beach
I also need to give some more thought to the input. Gsharp had a very efficient input technique, but I don't think it is adapted to a wide audience.
4:05:43
beach
I remove one painful aspect by a key innovation in Gsharp, namely not enforcing the meter.
4:06:57
beach
It is strange that other score editors have not figured that one out, especially since composers are known to use notation that does not enforce the meter. I guess it's because these editors were not written by composers or music engravers.
4:18:48
beach
One basic problem is that the duration of music elements varies a lot, so the user ends up having to select a different kind of music element for each new entry.
4:19:23
ck_
have you thought about using the time used for keyboard presses or mouse clicks for this?
4:21:50
ck_
I was thinking about entering notes by clicking on the staff, and -- for example -- holding the mouse button down and observing it cycle through eights, quarters, halfs and so on, then letting go at the right one
4:22:18
ck_
or using the scroll wheel [ or multi-finger gestures on a tablet ] to scroll through the times
4:24:09
beach
Maybe some pointer icon changes with the wheel, before the user clicks on the position.
4:24:37
beach
That would avoid this necessity of changing the mouse position and eye focus between each note.
4:29:55
beach
The other thing I have been thinking is to have two different presentation modes. One would be "preview" mode that presents the score as it would be printed. The other one would be "edit mode" in which there is additional information shown that is useful to the user, but that won't show up in the printed score.
4:31:22
beach
Preview mode could have lots of presentations on the screen that trigger different actions, so that the user doesn't have to move the eye focus to much to butcons, menus, and the like.
4:31:54
ck_
oh yes, I think a mode split like that is very prudent. Maybe one could call it even necessary
4:33:31
ck_
I'd like to talk with you about this some more, user interfaces are an interest of mine. Maybe on the weekend, or when you pick it back up
4:33:34
beach
So, I think we have identified a main goal, namely that the user should not have to move the pointer too far away from the place where music elements are currently inserted or altered.
6:08:30
jackdaniel
ck_: I did, I wrote a class hierarchy, some basic application frame and utilities (like computing offsets between notes and converting a note to either frequency or a midi key)
6:22:29
jackdaniel
n.b, I mean this question: https://irclog.tymoon.eu/freenode/%23clim?around=1568834687#1568834687
6:26:36
jackdaniel
so it is a progress compared to emacs which indeed likes to hang up on me from time to time too
6:30:58
jackdaniel
I'm sure there are irssi plugins for that, but I'm not much into that so I can't tell for sure (I'm using "vanilla" version)
6:32:00
beach
... i.e. a CLIM-based desktop where things like the spell checker, the abbrevs, etc. could be easily shared between applications.
6:32:54
jackdaniel
I know it doesn't account for a spell checker, but I wrote checkers! ;-) http://hellsgate.pl/files/ac973b5d-checkers.png
6:35:17
jackdaniel
they are basically ready to be commited, but my followup pull request fix-drag-and-drop waits for a better time, so I'm not making another one
7:18:05
jackdaniel
we have clime:draw-glyph (which is basically a single-character variant of draw-text), I plan to eradicate it as undocumented and unnecessary along with medium-draw-glyph from climi package
8:48:45
scymtym
jackdaniel: here is what i have so far: https://techfak.de/~jmoringe/DESIGN.pdf . i'm sharing this at this draft stage to give you a chance to comment on the style and also to discuss an idea
9:23:06
jackdaniel
scymtym: what you wrote there makes sense to me. here are my (minor) remarks: http://hellsgate.pl/files/b40ad8cf-notes.org
9:29:43
jackdaniel
in ieh-1 we do not distribute original event but rather synthetise it (even if it is enter event)
9:31:27
scymtym
there is the notion of "enabled sheets". the implementation in the PR is partially sensitive to sheets being enabled or not
9:32:40
scymtym
i would like to specify how being enabled or not effects boundary events, but i'm not completely sure what "enabled" means
9:33:54
jackdaniel
in other words, if you disable the sheet, that sheet and all its children disappear
9:34:58
jackdaniel
also, regarding z-ordering it might be worth considering how we could leverage sheet-occluding-sheets generic function
9:37:40
jackdaniel
yes, I've just thought that I will forget about this thought, so I've put it here
9:38:38
scymtym
i have thought about overlap and z-ordering as well, but i would like to ignore it for now if that's ok. it should be easy enough to integrate later (famous last words)
9:39:22
jackdaniel
sure, that's what I thought when I've put aside for a week Material Design works (2 years ago)
9:41:40
scymtym
the idea i wanted to discuss is this: the "Algorithm" section is based on having an old pointer sheet and a new pointer sheet. i think we could organize the implementation into two phases as well: 1) for all events, including boundary events, compute the new pointer sheet 2) synthesize boundary events
9:43:34
scymtym
the current code re-implements special cases of the general boundary event synthesis for enter and exit events
9:44:06
scymtym
i'm currently trying that while enforcing the stack properties stated in the "Specification" section
9:47:47
jackdaniel
I don't understand what do you mean by these phases, maybe it will click if you elaborate a little or after a short break on my side
9:49:44
scymtym
sorry, i mean processing all events like this: phase 1: compute new pointer sheet, phase 2: synthesize boundary events. as opposed to handling enter and exit events specially
9:52:53
jackdaniel
synthesize would take then two additional arguments: old-sheet and new-sheet, right?
9:53:16
jackdaniel
sure, I see now issue with that approach, and we'll save ourself setting port-pointer-sheet numerous times
9:53:52
jackdaniel
given it is requirement for the algorithm you've described and we both agree that it is the correct thing to do, then we should do it
9:55:57
jackdaniel
I agree that we could put all these functions as local in distribute-event, but from readibility perspective it makes a reasonably straightforward function which delegates responsibilities into something big (and scary!:)
9:55:58
scymtym
no, i want to put (let ((old-pointer-sheet (port-pointer-sheet )) (new-pointer-sheet old-pointer-sheet)) …) at the top of SYTHESIZE-BOUNDARY-EVENTS. NEW-POINTER-SHEET will then be updated before synthesizing boundary events
9:58:30
jackdaniel
mind you didn't mention in this document how we handle events with regard to pressed sheet, but I gather it is due to "one thing at a time" approach and draft will be expanded when this is working?
9:59:00
scymtym
for non-exit events, NEW-POINTER-SHEET can be set via COMPUTE-POINTER-EVENT-SHEET, for exit events, NEW-POINTER-SHEET is set to an ancestor of the event sheet
10:00:45
jackdaniel
it doesn't, imo it should receive only motion events (in its own native coordinate system) and release event
12:18:25
scymtym
implementing the specification and enforcing the properties works pretty well. i have trouble with border/scroller/viewport panes
12:19:35
scymtym
i don't know exactly, but the stack properties are sometimes violated when a combination of those kinds of panes is involved
12:22:12
jackdaniel
consider this: you have two mirrored sheets: scroller-pane and scroll-bar (positioned on the right)
12:22:57
jackdaniel
when you move pointer from the right to enter the scroll-bar, it might be that pointer is never in the scroller-pane area
12:27:42
scymtym
jackdaniel: i pushed my tool for debugging the sheet stack issue. quickload (:clouseau :clim-examples), load Core/clim-basic/event-log.lisp, load Examples/port-pointer-sheet.lisp to test it
12:45:21
scymtym
ok, border panes are strange. they are part of the sheet hierarchy, they have direct mirrors (i think), but i haven't seen any X-level events for them
12:49:31
jackdaniel
scymtym: regarding border pane behaving "weirdly", please take a tlook at the %realize-mirror method
12:50:11
jackdaniel
;;(rotatef (medium-background (sheet-medium sheet)) (medium-foreground (sheet-medium sheet)))
12:50:33
jackdaniel
so there is no wonder you observe fishy behavior, it accepts only exposure and structure-notify events
12:52:55
jackdaniel
but looking into the history I can tell, that previously that accepted a lot more events
12:53:39
jackdaniel
:exposure :key-press :key-release :button-press :button-release :structure-notify
12:54:33
jackdaniel
one could argue, that for sake of consistency all but top-level sheet mirror should behave exactly the same
12:54:50
jackdaniel
even if you don't really need to make some mirrors sensitive to particular events
12:55:40
jackdaniel
n.b: enter and leave events were not present for border-pane since the initial check-in
12:56:36
scymtym
i don't see why though. somebody could want a border pane that changes color when entered, for example
12:56:38
jackdaniel
working with McCLIM codebase for over three years proven to me, that at various occasions some things were written with some future plan in head which was never executed
12:57:00
jackdaniel
and simplifying it often does not break anything (sometimes it does, as you've noticed with some of my changes)
12:57:53
jackdaniel
and some other code passages are overly strict (like with this border-pane specialization) and other overly lax (like with mirroring everything for convenience and having code not working for unmirrored hierarchies)
12:59:08
scymtym
in a recent change, some code was supposed to signal MISSING-FONT, but the ERROR call uses the wrong MISSING-FONT symbol
12:59:46
jackdaniel
I broke a lot of things and that makes me less certain about my capabilities, but I think that many (if not most) changes were justified and moved the code in good direction (and removed plenty of dead code paths which were never truly working)
13:00:17
scymtym
i think running the font selector demo with the clx-fb backend reproduces the problem. see commit d2b03a701 in the stupid-event-logger branch
13:01:07
scymtym
as i said before: i also think that the last years worth of changes are a clear net positive
13:04:22
jackdaniel
I could have missed that part (or maybe the phrasing was a bit different) either way I think we should at least consider removing this border-pane specialization
13:07:47
jackdaniel
I see the commit and I agree, that is a bug; n.b it is a nice illustration of the type of issues when internals are spread across numerous packages (in this case mcclim-truetype)
13:13:30
scymtym
maybe this is all for performance reasons? if so, the justification should be re-examined
13:14:34
jackdaniel
pointer-motion indeed generates plenty of events, but leaving out enter/exit event does not have valid justification from this angle
13:15:16
jackdaniel
also border-pane has a child so if the child is mirrored, then events go to said child
13:15:32
jackdaniel
if it is not, then we should accepts these events and distribute to unmirrored children
13:18:40
scymtym
i just realized that i should change the sheet stack debugger to maintain on stack for each port
13:27:13
jackdaniel
I have a hypothesis where did this border-pane peculiar behavior come from (no way to verify that): clx allows to set border-width (and even realize-mirror-aux passes such argument to clx's function), so preasumbly border-pane at one point was only declared being a sheet while in fact i was not mapped and only border-width value was passed to clx
13:27:46
jackdaniel
and then it has changed and clx receives always border-width 0 and we draw border ourself
13:29:50
jackdaniel
assuming this hypothesis is correct we should remove the specialization for %realize-mirror and border-width argument from realize-mirror-aux altogether
13:30:31
jackdaniel
(from mcclim perspective removing border-width argument won't change anything, because we ignore the argument anyway)
13:32:31
jackdaniel
what I'm saying is that before the initial code was checked in, border-pane effect was achieved with clx's border-width argument seeded from the border-width in the pane, and (speculatively) it was changed also before the check-in
13:34:43
jackdaniel
n.b I think that the same applies to "border" argument to the realize-mirror-aux
13:41:00
scymtym
i would be glad to get rid of that stuff (after verifying that it is indeed not needed). preferably before merging the event changes
13:42:58
jackdaniel
would you mind if I sneak there a few other small commits I have cleanly commited locally? (text-style-character-width change I've mentioned, removal of draw-glyph protocol and removal of invalid comment)
13:52:09
jackdaniel
if you object having unrelated things in the pr please let me know and I'll make another one and close this one (it will grow because I'm working with basic-medium)