今天多线程服务器端程序使用Qt基本构架已经完成，在调试调试过程中，发现很多警告：
compile output显示:
&"warning: GDB: Failed to set controlling terminal: /346/227/240/346/225/210/347/232/204/345/217/202/346/225/260/n"
.dynamic section for "/usr/lib/libfreetype.so.6" is not at the expected address
difference appears to be caused by prelink, adjusting expectations
.dynamic section for "/lib/libgobject-2.0.so.0" is not at the expected address
difference appears to be caused by prelink, adjusting expectations
.dynamic section for "/usr/lib/libSM.so.6" is not at the expected address
difference appears to be caused by prelink, adjusting expectations
.dynamic section for "/usr/lib/libICE.so.6" is not at the expected address
difference appears to be caused by prelink, adjusting expectations
.dynamic section for "/usr/lib/libXrender.so.1" is not at the expected address
difference appears to be caused by prelink, adjusting expectations
.dynamic section for "/usr/lib/libXext.so.6" is not at the expected address
difference appears to be caused by prelink, adjusting expectations
.dynamic section for "/usr/lib/libX11.so.6" is not at the expected address
difference appears to be caused by prelink, adjusting expectations
由于反复调试，发现这个警告并不是程序本身引起的，关于GDB在设置控制终端时造成的，完全是由于调试器引起的，尽管我目前使用的是linux操作系统，但是我使用qtCreator集成开发环境，因为我比较懒，linux上使用命令行调试效率太低，但是qtcreator使用的调试器依然是GDB,只不过对于我们程序员来说可视化而已，因为我目前用的是feodra12,所以我估计这个与系统版本有关系，网上有人遇到类似问题：
With the current CVS version, if the user specifies a different terminal
for the inferior to run on, GDB doesn't set it as the inferior's
controlling terminal.
This leads to some problems. For instance, the inferior will not
get SIGINT sent to the terminal. Also, if the inferior is GDB itself,
the following message is shown in the inferior GDB's debugging session:
[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
The attached patch makes GDB set the inferior's controlling terminal,
fixing both of the symptoms above. If the user specifies a different
inferior terminal, GDB will now create a new session right after forking
to run the inferior, and use the TIOCSCTTY ioctl to set the controlling
terminal.
基于这种情况，我觉得升级系统也许是明智之举，yum -y update,升级后发现问题不再出现，所以我认为fedora12 在刚刚发布的更新包中，
已经认识到这个bug。
The new Windows Terminal and the original Windows console host, all in the same place!
最近提交(Master分支：4 个月前 )
ba87ab52
The conhost window uses the window message WM_GETDPISCALEDSIZE to scale
its client rect non-linearly. This is done to keep the rows and columns
from changing when the window changes (font sizes scale non-linearly).
If you size the window such that the text perfectly fits the width (and
cursor is on the first row of the next line), dragging the window
between monitors with different DPIs should NOT change how much of the
text fits on each line.
https://learn.microsoft.com/en-us/windows/win32/hidpi/wm-getdpiscaledsize
The current code is assuming that the size that should be scaled is the
current window size. This is sometimes the case, for example when
dragging a window between monitors, but it is not always the case. This
message can sometimes contain a size that is different from the window's
current size. For example, if the window is maximized, minimized, or
snapped (the size in these cases is the normal rect, or restore rect).
The msdn page above does (now) call this out, though it is possible that
this was added after this conhost code was added...
> The LPARAM is an in/out pointer to a SIZE struct. The _In_ value in
the LPARAM is the pending size of the window after a user-initiated move
or a call to SetWindowPos.
If the window is being resized, this size is not necessarily the same as
the window's current size at the time this message is received.
This incorrect assumption can cause the conhost window to be
unexpectedly large/small in some cases. For example:
1. Requires two monitors, set to different DPIs.
2. Size window somewhat small, and type text to fit exactly the width of
the window, putting cursor on first row of next line.
3. Win+Left (or otherwise snap/arrange the window).
4. Win+Shift+Left (migrates the window to the other monitor)
5. Win+Shift+Down (restore window, can also click maximize caption
button twice, maximizing then restoring)
Expected: The window should restore to the original logical size, with
the text perfectly fitting one line.
Actual: The window restores to another size; it is the snapped size on
the original monitor (the size of the window at the time it was changing
DPI, in step 4 above).
## References and Relevant Issues
This message (WM_GETDPISCALEDSIZE) is not widely used, but it is used by
dialogs (user32!CreateDialog), since they also size their windows using
font sizes. The code in this change borrows from the code in the dialog
manager, user32!GetDialogDpiScaledSize.
## Detailed Description of the Pull Request / Additional comments
The WM_GETDPISCALEDSIZE message contains the new DPI and the new size,
which is an in/out parameter. It starts as the new window size, scaled
to the window's current DPI, and is expected to be scaled to the new
DPI.
The client area (the part with the text) is NOT scaled linearly. For
example, if the font at 100% DPI has a height of 7, it could have a
height of 15 at 200%. (And if it did have a height of 14, linearly
scaled, it would surely not be linearly scaled at 150%, since fonts
cannot have a height of 10.5.) To pick the right size, we need to
resolve the font at the new DPI and use its actual size to scale the
client area.
To keep the amount of text in the window the same, we need to remove the
non-client area of the window (caption bars, resize borders, etc). The
non-client area is outside the area with the text, and its size depends
on the window's DPI and window styles. To remove it and add it back, we
need to:
- Reduce the provided window rect size by the non-client size at the
current DPI.
- Scale the client size using the new/old font sizes.
- Expand the final size by the non-client size at the new DPI. 1 天前
3e669029
Oops, it didn't support more than 100 items! 3 天前
免费下载资源
GitHub 加速计划 / term / terminal
8
0
0
0
已为社区贡献4条内容
所有评论(0)