<sb0>
whitequark, re. rewriting llvmlite. before that there was llvmpy that was worse and even slower, so I had a look at it and using the C LLVM API seems fairly straightforward
<whitequark>
yes
<whitequark>
llvmpy was not using the C API, it did some clever but ultimately pointless crap
<sb0>
whitequark, are you happy with the new misoc boot mechanism?
<whitequark>
it always prints the serialboot token, right?
<sb0>
yes
<whitequark>
yes, that will work
FabM has joined #m-labs
evilspirit has quit [Disconnected by services]
evilspirit has joined #m-labs
kyak has joined #m-labs
<rjo>
sb0: yes. i would use scroll for the individual widgets and not for the scrollarea.
<sb0>
this makes scrolling difficult because spinboxes always catch it
<rjo>
yes. i would use the scrolling for the spinboxes and scanwidgets etc. not for scrolling the entire scrollarea of the experiment editor
<sb0>
the best behavior would be to consider where the scrolling started (on a scanwidget or not) but AFAICT Qt does not easily permit that
<sb0>
no no. users will use the scroll wheel. who still use scroll bars these days...
<rjo>
yes.
<rjo>
i was not talking about the scroll bars.
<rjo>
if you scroll the editor with the wheel, a widget will catch it eventually and grab all subsequent events. i assumed that is what you were referring to.
<rjo>
i would also prefer to have scroll caught by spinboxes for editing values. rather than scrolling the editor area
<rjo>
sb0: i'll work a bit on the spi master design today. do you have other material than the notes in the issue?
<sb0>
you can try with the spinboxes catching the scroll wheel, but I definitely prefer without
<rjo>
why?
<sb0>
scroll wheel is essentially unusable otherwise. it often lands on a spinbox, at which point scrolling stops _and_ the value in the spinbox is corrupted
<sb0>
it's very obnoxious
<rjo>
i would actually abandon scrolling the editor area with the wheel.
<sb0>
that's not good either, everyone uses the scroll wheel these days
<rjo>
yes. for editing spinboxes
<rjo>
this is how people use it in the lab
<rjo>
they don't scroll aroound. they maximise the window and fold stuff so that there is no area scrolling at all
<sb0>
how about Ctrl + scrolling on the spinboxes?
<sb0>
it's too easy to corrupt values otherwise
<rjo>
would need to be on the scanwidgets as well
<sb0>
yes
<rjo>
then i would shift the behavior: wheel: scroll the area, shift-wheel: change spinboxes/zoom scanwidget, ctrl-wheel: nothin on spinboxes/npoints on scanwidget
<sb0>
sounds good
<rjo>
how are shortcuts handled w.r.t. focus? dows qt know which widget is supposed to receive a keyboard shortcut?
<rjo>
and the Tab/Shift-Tab focus sequence needs to be cleaned up.
<sb0>
yes, but you need to configure that
<sb0>
e.g. set the shortcut scope
<sb0>
what is the problem with Tab?
<rjo>
it jumps around randomly. instead of going top left-bottom right and/or adhering to the standard editing sequence
<sb0>
doesn't do that here, at least in the couple cases I tried
evilspirit has quit [Ping timeout: 240 seconds]
evilspirit has joined #m-labs
evilspirit has quit [Remote host closed the connection]
evilspirit has joined #m-labs
<rjo>
e.g. the {no scan, linear etc} is selected after the scanwidget but before the recompute. imho it should be the type selection, then the scanwidget and then the recompute (maybe recompute should be a context menu of the left hand label)
<sb0>
touching the layout of this thing tickles another hoard of Qt bugs, so I recommend keeping the recompute as a button
<rjo>
sb0: ping re spi ^
<sb0>
besides, that's what Joe wanted, and it doesn't use much space
<sb0>
SPI: all the info I have is in the issue
<rjo>
sb0: that doesn't mean others want it too nor that it is the right thing to do ;)
key2 has joined #m-labs
evil_spirit has joined #m-labs
evilspirit has quit [Ping timeout: 252 seconds]
<rjo>
sb0: ping re the dns trouble with ns[23].serverraum.org. they still dish out the wrong ip address with a week of ttl.