Activity for MBaz
-
MBaz posted a comment on ticket #516
Ethan, thank you for your reply. I have had a chance to run more tests, both in Firefox and in Chromium. I can toggle the plots now; I don't know what I was doing wrong before. These are my conclusions and feature requests: Documentation: The mousebox appears to the left of the plot, not the bottom, as stated in the documentation. Documentation: State that the # button is only active if set grid has been issued. Feature request: add a configuration option to the canvas terminal to place the mousebox...
-
Canvas terminal not fully functional
-
Canvas terminal documentation imprecise
-
Ethan, thank you so much for the time and energy spent on this. I hope it turns out to be worthwhile in the end. You seem to have installed Gaston correctly. I'm assuming we're on Linux. Try these two commands: julia> plot(1:10) julia> Gaston.gnuplot_send("q") (The gnuplot_send command is not exposed directly to users; that is why you have to include Gaston.. Also, this function appends a newline to the string sent to gnuplot.) What I see is that the plot window disappears. Now, let's try on gnuplot....
-
Ethan, thank you so much for the time and energy spent on this. I hope it turns out to be worthwhile in the end. You seem to have installed Gaston correctly. I'm assuming we're on Linux. Try these two commands: julia> plot(1:10) julia> Gaston.gnuplot_send("q") (The gnuplot_send command is not exposed directly to users; that is why you have to include Gaston.. Also, this function appends a newline to the string sent to gnuplot.) What I see is that the plot window disappears. Now, let's try on gnuplot....
-
Ethan, first of all, thanks for the detailed explanation and for pointing out where I am being unclear. I will try to clarify. Keep in mind I'm also not a Windows expert or even much of a user; I mainly use linux. I'm just trying to debug an issue that Windows users found in my code. For context, I develop Gaston.jl, a plotting package for the Julia language, that uses gnuplot to plot. Gaston's documentation is here, and the source code is here. Also important: Julia uses libuv for I/O. This library...
-
I see. I just sent q to gnuplot from Julia (via stdin) and saw the plot close. This surprises me, because typing q in gnuplot's console doesn't close the window -- I just get a q on the command line. It's almost like the q gets sent to the plot window! Speaking with vey little knowledge of gnuplot's design decisions, I guess I would have expected the plot window to have its own stdin, and a separate communications channel to gnuplot. I think the problem is exacerbated on Windows because it is so...
-
More tests: I can reproduce the problem with the wxt terminal, but NOT with the windows terminal.
-
Ethan, Issue 2098 is quite interesting and might be related. I think that there is a link between keyboard events and reading from stdin, where those two processes should be completely independent. In what follows, keep in mind that working with streams in Windows is extremely slow. In the command sequence I describe above, the plot usually takes less than a couple of seconds to appear, but the full sequence may take as long as six or seven seconds to complete (where, in Linux, it's essentially instantaneous)....
-
-
Incorrect reading of characters from pipe
-
Incorrect reading of characters from pipe
-
I think the question is, which has priority, an axis range set indirectly by scrolling, or an offset specification? The user is explicitly configuring the offset, but scrolling doesn't "feel" like explicitly changing the plot configuration. My personal preference is to always keep the offsets, but I think it's also reasonable to prefer the opposite approach.
-
I think the question is, which has priority, an axis range set by indirectly set by scrolling, or an offset specification? The user is explicitly configuring the offset, but scrolling doesn't "feel" like explicitly changing the plot configuration. My personal preference is to always keep the offsets, but I think it's also reasonable to prefer the opposite approach.
-
I just had a chance to test the fix. Scrolling now works much better and is quite usable. However, the offsets specified in ~/.gnuplot are lost when scrolling. Autoscaling applies them again. I think the ideal behavior would be to maintain the offsets while scrolling.
-
Ethan, thanks for looking into this.
-
[5.2-8] Bad interaction of `set offsets` with scrolling
-
Background not reset after `set term`
-
I discovered the solution in the documentation (set term push|pop). My apologies for the invalid report; this ticket can be closed. I've been using gnuplot for years and I still have much to (re)learn.
-
I hadn't realized it until now, but this is not restricted to background... once I set the terminal size, font, etc, I can't easily revert them to their default values.
-
Background not reset after `set term`
-
Background not reset after `reset session`
-
Thanks for your help (I'm the OP). For some reason, I thought that xterm had the ability to map 24-bit color to 256 colors internally. Please, close this ticket.
-
Hi. I'm the original submitter. Thank you for the response. I don't know enough about...
1