freenode/#clim - IRC Chatlog
Search
3:15:53
ck_
As suspected there's not much immediate opportunity for Common Lisp, but it also doesn't seem to be totally out of the question.
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