Win11，启用桌面Copilot，在桌面页为活动窗口时，打开Copilot，会自动唤醒后台的NG窗口，然后NG窗口会失去响应，且无法关闭。我记得以前也反馈过一次，不知道有没有同样问题的坛友？
请问哪版能支持windows7啊？
新建一个网站项目，如果用粘贴的方式输入地址内容，会假死，只能手动输入
没复现。。。。。
is there any way to make dictionary icons render in a better way?
i tried some command line arguments before calling goldendict-ng, but to be honest i didn’t saw much difference:
QT_AUTO_SCREEN_SCALE_FACTOR=1 QT_IMAGE_SCALE_FACTOR=2 QT_APPLICATION_ATTRIBUTE=Qt::AA_UseHighDpiPixmaps goldendict
Sadly, no. Currently, it is hard-coded to 21 [1], however changing its value won’t do anything, because QToolBar won’t upscale icons [2].
(BTW, some icons are missing in your toolbar is because you don’t have qtsvg installed. 
)
goldendict-ng/src/ui/dictionarybar.cc at 34e9ad5654efc2da05be71747be4fd6129ab7bcd · xiaoyifang/goldendict-ng · GitHub ↩︎
“Icons of smaller size will not be scaled up.” as described in QToolBar Class | Qt Widgets 6.7.2 ↩︎
2 个赞
the problem is that those png icons (of the dictionaries) are indeed high quality, but it display terribly on goldendict, i dont know why…
maybe it’s because (like you said) it’s fixed to a amount of pixels.
could you make a function to calculate a better number given the user’s display size? to make it more dynamic
edit: maybe an option for the user to select the size in the preferences?
1 个赞
i changed the value from 21 to 40, but didnt had any difference, the icon resolution stood the same
I think this region of code is the culprit. It does these,
- Scale width to 64 (keep ratio)
- Manually invoking QPainter to change the icon to square
- destroys ratio
- The code is wrong, becuase
RenderHint::Antialiasingonly works for shapes and doesn’t do anything to image painting, there was no smoothing at all
You are right, the image quality is indeed reduced.
I think we should don’t do 1. if image is not super large, and replace the old QPainer code in 2. with a single line:
QImage result =img.scaled(max,max, Qt::KeepAspectRatioByExpanding, Qt::SmoothTransformation)
Then dictionaryIcon will have better quality .
However, I didn’t try, so I could be wrong.
Feel free to try and send a PR.
1 个赞
i was reading the code, and it seems that there’s a reason why it’s being reduced
if we can tackle that problem, we can remove that “workaround” that was did.
i say “workaround” because it doesn’t sound like a proper solution, scaling down the icons doesn’t seem quite right…
solved, but this was a very dumb solution (i deleted the code lmao)
now you can notice how nice the icons look…
it doesn’t sound like a proper solution
scaling down the icons doesn’t seem quite right
The code not only scale down, but also scale up.
The scaling down will automatically happen again when QToolbar setting icons.
I think we have to scale it down to some value because if the user for whatever reason has an insanely large image, the memory consumption will be much higher.
In theory, we can scale perfectly to toolbar’s iconSize, however, the icon is also used for a few other purposes [1].
Since the original code hard coded Toolbar height to 21 and scale the image to 64. I think adjusting code to better scaling to 64×64 and removing arbitrary limitation of 21 would just fix the problem.
Do you want to propose a PR? If not, I can do it some time later.
im worried that my PR is a bit dumb, i just removed some code and that solved the issue.
that same code was added to solve another bug that causes crash when the icon is just too big… this is quite confusing
furthermore, this is quite a interesting line:
but that “size” is ambiguous, we dont know if the person meant size as in the size visualized by the user, or size in pixels , if it’s the size of the image in pixels, then the downscale occurs
this is where the code was added, i removed only the downscaling line
i think we can have a “cap”, it can go and check each icon and only downscale the ones who are needed to downscale, that cap will act as a limit of bytes, if surpassed then the downscale occurs for that unique icon
cap will act as a limit of bytes, if surpassed then the downscale occurs for that unique icon
There is no difference between “limiting bytes” and “limiting of image sizes”. After loading an image to memory, it will be represented as strides of pixels. In fact, it can be calculated by hand. For 64×64 image stored in memory as ARGB32 will consume this much of memory:
32 bits * 64 * 64= 131072 bits = 16 KiB.
I think just down scaling to a certain size is simple and effective to avoid all the troubles.
well, we can limit to 64k instead of 64 pixels
reaching 1mb is already difficult if the limit per icon size is 64k
it looks soooooo beautiful without the limitation 
edit: i think you’re quite right, 64 seems enough.
through investigation i could notice that most icons are 32x32
but i ask you to consider giving room to 64 bit variables, since our modern computers can handle it just fine, you calculated for 32 bits and it was pretty good, but i bet we can do 64 bits without raising a lot of memory consumption, i bet everyone has 2mb of memory to spare, and it’s not even going to reach 1mb if there’s only a few dictionaries…
consider giving room to 64 bit variables
My friend, I don’t know what are you talking here. The 32 bits I mentioned above is because ARGB32 has 4 numbers ranges [0,255] and they only need 8 bits, thus 32 bits. About modern computers, they all have special instructions to process 8/16/32 bits data efficiently. If you take a look at assembly, the instructions have suffixes for 8/16/32 bits data [1]. Good video about this topic if you are interested [2].
Anyway, I don’t think these lower level things matters to the problem at our hand. Since we settled all details, maybe put together a PR? Lets this be the first code change of yours to GD.
my solution is terrible , that’s why i didnt made the PR yet, but if you’re willing to revise the code, then i’m going to open it right now