After recloning from git, all of a sudden my PyQt6 program is scaled weirdly. Many, but not all widgets are overly large.
Example of overly large text in the main QMenuBar
Example of overly large text in a QDockWidget
I've inserted the following so that my pyqtgraph PlotItems scale consistently across monitors of different resolutions, but with/without this code the scaling issue persists.
QApplication.setHighDpiScaleFactorRoundingPolicy(
Qt.HighDpiScaleFactorRoundingPolicy.PassThrough
)
if platform.system() == "Windows":
if int(platform.release()) >= 8:
ctypes.windll.shcore.SetProcessDpiAwareness(True)
I don't think this has to do with having an overly high resolution display, as some text (tab names, for example) are the proper size.
I've also created a new virtual environment and reinstalled libraries.
pyqtgraph~=0.13.1
PyQt6~=6.4.0
PyQt6-sip
PyQt5
PyOpenGL
numpy==1.23.5
Some other things of note:
I'm not using stylesheets to modify my font size/QFont anywhere explicitly.
Sometimes running it from terminal vs pycharm solves the problem, but not always. It is strange that there's an inconsistency here, and I'm not sure why.
I've found the issue.
The sizing becomes weirdly large ONLY when I'm running PyQt6-Qt6==6.4.1. Version 6.4.0 works perfectly fine without any scaling problems.
I've set a hard version requirement to my requirements.txt to solve the issue.
The reason it worked in terminal and not PyCharm is because of my terminal's (err, my global) outdated installation.
Related
Seemingly out of nowhere, one of my Jupyter Notebook .ipynb files now takes forever to open, to the point where I receive Chrome notifications saying that the page is unresponsive. If I wait it out it does open, however. Once it does open, though, it fails to have any of its nbextensions applied. For example, I can now no longer use codefolding. The notebook also seems to have a fair amount of lag when I try to scroll or edit cells.
The file is 556 kB and does have its output cleared (as I've noticed that being an issue for others), though it does contain a few thousand lines of code. I'm able to open smaller files (391 kB) with far fewer lines of code quickly, with all my selected nbextensions active, and with no lag.
Why would this marginally larger file have such issues? What can I do about this?
EDIT:
I have noticed that when opening the file in question, my Anaconda Prompt outputs the following:
404 GET /nbextensions/widgets/notebook/js/extension.js
This error does not pop up when I'm running the smaller file. I'm confused as to why this error would be conditional on the file being ran.
EDIT 2:
The following link seems to be quite related to my issue:
https://github.com/ipython-contrib/jupyter_contrib_nbextensions/issues/822
Basically, it seems like the issue is simply that nbextensions don't play well with larger files. I'm going to try splitting up the code into multiple files and hope the core file becomes small enough for this to work out better.
See Edit 2.
Simple solution - just make the file smaller. Everything is working as expected now.
This is an issue I am encountering for different pieces of codes I am writing in R.
Basically, I would like to generate a window that displays a picture (a .png file). Following for instance guidances from this or this, I come up with this kind of code:
library(tcltk)
tmpFile <- tempfile(fileext = ".png")
download.file("https://www.r-project.org/logo/Rlogo.png", tmpFile)
tcl("image","create","photo", "imageLogo", file=tmpFile)
win1 <- tktoplevel()
tkpack(ttklabel(win1, image="imageLogo", compound="image"))
This works fine under Mac OS, but not on Linux nor on Windows, where I am displayed such an error message:
[tcl] couldn't recognize data in image file
I can find some workarounds when I want to display graphs, using for instance packages tkrplot or igraph. Nonetheless, I would be really eager to understand why I got such errors when running my scripts on Linux or Windows, whereas it works just fine on Mac OS.
Apologies in case this issue is obvious, but I haven't found anything about potential differences with the tcltk package depending on the OS.
Tk's native support for PNG was added in 8.6. Prior to that, you need to have the tkimg extension loaded into Tk to add the image format handler required. If your installation of Tcl/Tk that R is using is set up right, you can probably make it work with:
tclRequire("Img")
once you've initialised things sufficiently. Yes, the name used internally is “Img” for historical reasons, but that's just impossible to search for! (This is the key thing in this mailing list message from way back.)
However, upgrading the versions of Tcl and Tk to 8.6 is likely to be a better move.
Finally and a bit lately, I would like to close this issue and sum up the different suggestions that were kindly made in response of my question:
R comes along with Tcl 8.5, even with the latest version 3.3.2, which means that there is no way for embedding a PNG file with the usual command into a window created thanks to Tcl/Tk. For some reasons it is working on Mac OS, but do not expect this to work easily on other OSs.
In order to display pictures, graphs, etc. in a window generated by Tcl/Tk in R, better look for either using the GIF support (when possible) or trying alternative solutions (see the question for possible alternative options).
In case one really wants to display PNG files, the solution consists of installing Tcl 8.5 (for instance ActiveTcl) along with the extension Img. In order to use the Tcl/Tk package that you've just installed on your computer, you can refer to the R FAQ for Windows for instance (as stated in the FAQ, you need to install Tcl 8.5 - I tried with Tcl 8.6, thereby hoping to solve my issue, but it didn't work). Basically, you need to set up an environment variable (MY_TCLTK) and put the path where the package Tcl/Tk is installed. Needless to be said, Tcl/Tk is commonly used in R in order to implement GUIs; if you have to go through very complex procedures to set up the system, the package definitely loses its advantages.
Finally, since Tcl 8.6 should be available soon or later with R (already implemented in the devel version), this issue will be de facto outdated.
What steps will reproduce the problem?
1. wkhtmltopdf.exe --disable-smart-shrinking --print-media-type --page-size A4 --dpi 96 --margin-top 25 --margin-bottom 25 file:///.../debug.html mytest.pdf
What is the expected output?
I expect to see the non-shrinked content in result pdf-file
What do you see instead?
Shrinked content in the result pdf-file
What version of wkhtmltopdf are you using?
0.11.0 rc2
On what operating system?
Windows 7 64-bit
The problem is a little bit wider. I need to insert page breaks before some divs depending on their height. I wrote the appropriate script. But the thing is in "shrinked world" the coordinates analyzed by the script change and it the result is ugly. So I need to disable shrinking to make it work correctly.
On the other hand the documentation says '--disable-smart-shrinking' is "only available using patched QT". Does my version of 'wkhtmltopdf' implement this stuff? How can I find it out? Should I install QT or even rebuild the wkhtmltopdf?
I am using R 2.15.2 on windows XP.
I was used to use Rgui.exe but it was lacking the UNIX standards I like to use like CTRL+R <=>backward research and CTRL+U <=>erase line ...
If I missed something please tell me !
Then I tried Rterm.exe (which looks identical to R.exe to me) which has all those nice features. I found how to tune it right clicking on the top of the window to set height-width (it is like tuning the window you get from cmd.exe).
The problem is that now I cannot see on the window more than 75 characters, with a $ at the end: like this:
R) ppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppp$
Not sure if it is a R option of a windows one, but if I set options("width"=180) I can see data.frame on the full width of the window...
Not sure what is happening, can I modify this?
We still do not know the answer to that one, so I guess 50 pts goes to Oscar de León... good for him to bad for me...
Sadly, it appears to be built in.
There used to be a problem with R when trying to print long strings. Apparently it was fixed first in Rterm and other versions of R before being fixed in Rgui.
When Rgui was fixed, possibly it was by a different means, since this issue can be fixed in Rgui but not other windows versions of R. You can change the width of the console for output both in Rgui and (later) Rterm.
The prompt is another story. It is actually not the same as the output space, and thus is controlled with a different option; but, this only works for Rgui. To do it, set pgcolumns=180 in the Rconsole file under [R HOME]\etc\. This modifies the width of the internal pager of the Rgui console, and effectively enables you to type up to 180 characters per input prompt.
Possibly there is a way to integrate that behavior into Rterm, and maybe Duncan Murdoch can point you in the correct direction (or prove me completely wrong).
I'm not really sure what is being requested. If what is needed in RTerm.exe is to display the end of a long line (and position the cursor there), then use CTRL-E. You can go back to the beginning of a line with CTRL-A. One can go back and forth repeatedly as needed until the line is use ENTER.
The control character of readline seem to be active, for instance CTRL-P scrolls back one command and CTRL-N brings up the "next" command from history if you hit CTRL-P too many times. (These are the same behavior as the up/down arrow keys.) See link for other expected readline behaviors.
On my machine alt-f and alt-b (which should have been meta-f and meta-b) did not natively move forward or backward by words, but ESC-b and ESC-f did so on a line that exceeded the console width and had the $'s marking either the right or left extents as having further material to look consider.
If you want to wrap display lines, then you need to consider alternatives or additions to readline: link, but that is an untested suggestion and merely the results of a search for: "readline wrap display".
The command should be options(width = 180) (without the quotes around width), but when you run Rterm in the Windows shell, it doesn't respect changes to this value; it just prints output as wide as the console.
The best way of working with R is (almost always) to use an IDE. Try emacs + ESS or one of the many vim plugins (R.vim, vim-R, VIM:r-plugin) if you want something UNIXy.
I'm new here.
I've the same matter as this one but only using QtOctave; beside oct2mat pkg hasn't never been loaded on my pc.
Typing:
pkg unload oct2mat
octave returns:
error: package oct2mat is not installed
error: \share\octave\3.6.2\m\pkg\pkg.m at line 2170, column 9
Using plot function directly in Octave it works properly, very stange!
Can enybody help me?
Thanks in advance.
Addendum to #vinukn's answer, as it might be too cryptic.
Try this:
>>> graphics_toolkit
ans = fltk
>>> agts = available_graphics_toolkits
agts =
{
[1,1] = fltk
[1,2] = gnuplot
}
>>> graphics_toolkit(agts{2}) % This sets the graphics toolkit.
>>> plot([1 2 3 4])
That is, the default was FLTK, and I've set Gnuplot. Try each, they look slightly different to each other.
This is on my default installation of Octave 3.6.2 on Windows Vista, with QtOctave. (I've tried the most recent build of Octave, with built-in GUI, but after starting it never drew in its windows, so it was unusable at this stage, which is a shame as there are probably a handful of lines of code that need to be changed to make it work... Will wait until that is fixed. In the meantime, Gnuplot doesn't freeze.)
Also, here is a list of keys to use in the Gnuplot window. Especially note:
Right-click to draw a zoom box.
a to autoscale (back to default zoom).
p to go back to the most recent previous zoom.
Don't use QtOctave. It has been deprecated for a reason. See the GUI section in Octave FAQ to understand why the GUI doesn't work. It is specially true for things such as plots and dialog windows.
Take special note on the fact that QtOctave and others are specially sensitive to new versions of Octave. You are using Octave 3.6.2 while QtOctave was abandoned back in 3.2.X. Your options are (by order of what I recommend):
use Octave on its own, no QtOctave;
build from development sources to use the experimental GUI;
fix QtOctave (I actually don't recommend this one at all. Its website has been closed, and it would be too much work which would be better spent helping the Octave developers with the native GUI);
Actually,the reason behind this problem is default graphics toolkit fltk or qt. Qtoctave works with pipe, fltk does nt support pipe, ie fltk works inside octave. Pipe does nt support both text and image(gui) same time. The solution is change default toolkit to gnuplot.