sb0 changed the topic of #m-labs to: ARTIQ, Migen, MiSoC, Mixxeo & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
<mithro> sb0: the streaming shuts down after the conference is closed for the evening - Videos will be up at https://www.youtube.com/user/linuxconfau2016
evilspirit has joined #m-labs
attie_ is now known as attie
rohitksingh has joined #m-labs
FabM has joined #m-labs
acathla has joined #m-labs
acathla has quit [Changing host]
acathla has joined #m-labs
key2 has joined #m-labs
rohitksingh1 has joined #m-labs
rohitksingh has quit [Ping timeout: 240 seconds]
ylamarre has joined #m-labs
Gurty has quit [Quit: Kooll ~o~ datalove <3³\infty]
evilspirit has quit [Ping timeout: 245 seconds]
Gurty has joined #m-labs
Gurty has quit [Remote host closed the connection]
Gurty has joined #m-labs
rohitksingh1 has quit [Ping timeout: 240 seconds]
rohitksingh has joined #m-labs
evilspirit has joined #m-labs
ylamarre has quit [Quit: ylamarre]
bb-m-labs has joined #m-labs
FabM has quit [Quit: ChatZilla 0.9.92 [Firefox 43.0.4/20160105164030]]
evilspirit has quit [Ping timeout: 250 seconds]
rohitksingh has quit [Ping timeout: 240 seconds]
key2 has quit [Ping timeout: 250 seconds]
rohitksingh has joined #m-labs
rohitksingh has quit [Quit: Leaving.]
ylamarre has joined #m-labs
<cr1901_modern> rjo: Can you test the zoom-in/zoom-out of the new commit? After this, I need to implement "hide sliders on zoom in", "sliders can cross", and "connect signals", and after you approve, it's ready for deployment.
<rjo> cr1901_modern: impports: you mix quamash and pyqt5. there is no QApplication in my pyqt5
<cr1901_modern> rjo: hold on please
<sb0> rjo, when merging subprocess-termination, note that I have renamed tests in newtesting (so that unittest discover finds them)
<rjo> cr1901_modern: i can only test the mouse scroll zoom and observe correct ticks, right? that works "somewhat" ;) if i start it, i only see a single "0.0e+0" in the middle. that should be a "0" and there should always be at least two ticks.
<rjo> cr1901_modern: if i resize the window, there are intermediate ticks that flicker in and out
<rjo> sb0: noted.
<cr1901_modern> rjo: There should always be at least two ticks, so that's a bug on my end.
<cr1901_modern> rjo: Could you read me the numMajorTicks and majorTicksInc debug vars on your end?
<rjo> cr1901_modern: blue/red is good. it would be awesome if the sliders could be "|> >|" for start<stop and "|< <|" for start>stop to indicate direction of scan. then you would not have to indicate it by color. but that is a feate that can be saved for later. don't do it now.
<rjo> cr1901_modern: if i start it i get nummajorticks=2 and majorticksinc=200
<rjo> s/feate/feature/
<rjo> cr1901_modern: and "161" printed in between
<cr1901_modern> okay, something's not right then. Add a print statement to print out the width of the axis: print("width", self.width) after line 44
<rjo> cr1901_modern: 315
mindrunner has quit [Remote host closed the connection]
<rjo> cr1901_modern: and i remember another thing that would be desired for deployment: visual representation of NumPoints as a set of small tick marks (no labels) either on the slider or on the axis (other side than the labeled tick marks). this was on the original "screenshot" but may not have been that obvious.
mindrunner has joined #m-labs
<cr1901_modern> Hmmm... very odd indeed.
<cr1901_modern> And yes, I didn't forget that, I was planning to use green dots for that, but ticks should also work
<cr1901_modern> rjo: I'll see what I can do re: scan direction. Making the sliders even red/blue was not trivial. It's not as simple as reimplementing drawComplexControl either, b/c on Windows Vista/7 Qt doesn't use it's own drawing primitives to draw sliders
<cr1901_modern> It defers to the native engine, and looking at Qt source code, I don't see a way to override this except stylesheets. Which can't really be changed dynamically either?
<rjo> cr1901_modern: ticks should be sufficient. the visual language of "green" won't be immediately obvious to most.
<rjo> cr1901_modern: slider visuals are not that important. they can be improved later imho. i would focus on the behavioral logic (especially corner cases), the ticking, and linkage of signals/widgets now
<cr1901_modern> linkage of signals is one of the last things I do, b/c they have the highest potential for breakage if I change anything else.
<rjo> cr1901_modern: and i would sprinkle that code with many asserts now to verify your assumptions about the behavior. then we don't have to do that much ping-pong.
<cr1901_modern> ack.
<rjo> cr1901_modern: maybe. you will know that best.
<cr1901_modern> rjo: I talked to sb0, and I think we agree that zooming should be relative to the current mouse position. The other two zoom types I considered (zoom relative to view center, zoom relative to slider span center) have buttons for that :)
<rjo> cr1901_modern: ack.
<cr1901_modern> well actually zoom relative to view center is just a special case of "zoom relative to current mouse x position"
<cr1901_modern> It's coming along I think tho. Almost there
<GitHub119> [artiq] jordens pushed 2 new commits to subprocess-termination: https://git.io/vgYbJ
<GitHub119> artiq/subprocess-termination ab81dbb Robert Jordens: Merge remote-tracking branch 'm-labs/master' into subprocess-termination...
<GitHub119> artiq/subprocess-termination c52081c Robert Jordens: Merge remote-tracking branch 'm-labs/newtesting' into subprocess-termination...
<rjo> cr1901_modern: i don't think that 0.5 is a valid tick step. [1, 2, 5] in ever decade includes 0.5
<rjo> every
<cr1901_modern> rjo: At the current zoom level, whenever the view becomes large enough to house at least 2*10^x units (one for each half of the slider), the number of ticks automatically updates to the next power of 10. I've found that sometimes results in barely any labels drawn at all, so I use 0.5 as a way to double the number of ticks drawn.
<cr1901_modern> s/the number of ticks/the tick increment/g
<cr1901_modern> actually, no "g" lol
<rjo> cr1901_modern: i would not halve the slider range that way. treat it as a whole.
mumptai has joined #m-labs
<rjo> cr1901_modern: that sounds like a wrong work around to a bug in the logic.
<cr1901_modern> rjo: I agree it's a bit of a hack that "does the right thing". The idea is that the axis needs to decide whether to draw mantissas in increments of 5 or 10, at which point we'd just increase the exponent for the latter.
<cr1901_modern> (to renormalize back to 1 for the mantissa)
<cr1901_modern> rjo: I looked at the adaptive_ticker code you sent me and I confess that I don't really understand it. (get_ideal_interval) Maaybe I need to look at other source files
<rjo> i can jot down an algorithm if you want.
mindrunner has quit [Quit: quit]
mindrunner has joined #m-labs
<cr1901_modern> Maybe that's a good idea, b/c it seems I'm having trouble getting this right
ylamarre has quit [Quit: ylamarre]
<cr1901_modern> rjo: Actually, looking at the coffee code you sent me, I think I DID basically implement the logic correctly except for "get_ideal_interval". So that's really the only part I need help with.
mumptai has quit [Quit: Verlassend]