[ANNOUNCEMENT] Updated: fortune-mod 3.14.1
The following packages have been upgraded in the Cygwin distribution: * fortune-mod 3.14.1 The ever-popular fortune program, which will display quotes or witticisms. Fun-loving system administrators can add fortune to users' .profile or .login files so that they get their dose of wisdom each time they log in. For more information see the project home page: https://www.shlomifish.org/open-source/projects/fortune-mod or the Github project page: https://github.com/shlomif/fortune-mod For changes since the previous Cygwin release please see below or read /usr/share/doc/fortune-mod/ChangeLog after installation: https://github.com/shlomif/fortune-mod/blob/master/fortune-mod/ChangeLog August 10, 2022 3.14.1 * Try to fix the manpage's docbook5/XML markup. * Fix issue#67 - typo. * Cleanups. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Updated: fortune-mod 3.14.1
The following packages have been upgraded in the Cygwin distribution: * fortune-mod 3.14.1 The ever-popular fortune program, which will display quotes or witticisms. Fun-loving system administrators can add fortune to users' .profile or .login files so that they get their dose of wisdom each time they log in. For more information see the project home page: https://www.shlomifish.org/open-source/projects/fortune-mod or the Github project page: https://github.com/shlomif/fortune-mod For changes since the previous Cygwin release please see below or read /usr/share/doc/fortune-mod/ChangeLog after installation: https://github.com/shlomif/fortune-mod/blob/master/fortune-mod/ChangeLog August 10, 2022 3.14.1 * Try to fix the manpage's docbook5/XML markup. * Fix issue#67 - typo. * Cleanups.
[ANNOUNCEMENT] Update: ca-certificates-2022.2.54-1
The following packages have been uploaded to the Cygwin distribution: ca-certificates-2022.2.54-1 ca-certificates-letsencrypt-2022.2.54-1 Mozilla's CA root certificates for use with OpenSSL, NSS, GnuTLS, and other software that handles certificate verification. This is an update to the latest upstream release. This update contains the ca-certificates-letsencrypt package, whose installation will make the ISRG R3 intermediate CA a trust anchor and removes trust for the already expired DST X3 root CA (this should strictly not be necessary, but works around bugs present in some libraries in how alternate chains are constructed and verified). This will allow to successfully verify certificates using the Letsencrypt legacy cert chain in certain applications. Install this package when you currently have trouble accessing sites (due to validation complaining about an expired certificate) that had no problems until about September 30 or October 1 2021 depending on your timezone. The release numbering scheme has been aligned with Fedora. -- *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Update: ca-certificates-2022.2.54-1
The following packages have been uploaded to the Cygwin distribution: ca-certificates-2022.2.54-1 ca-certificates-letsencrypt-2022.2.54-1 Mozilla's CA root certificates for use with OpenSSL, NSS, GnuTLS, and other software that handles certificate verification. This is an update to the latest upstream release. This update contains the ca-certificates-letsencrypt package, whose installation will make the ISRG R3 intermediate CA a trust anchor and removes trust for the already expired DST X3 root CA (this should strictly not be necessary, but works around bugs present in some libraries in how alternate chains are constructed and verified). This will allow to successfully verify certificates using the Letsencrypt legacy cert chain in certain applications. Install this package when you currently have trouble accessing sites (due to validation complaining about an expired certificate) that had no problems until about September 30 or October 1 2021 depending on your timezone. The release numbering scheme has been aligned with Fedora. -- *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL.
Re: scallywag / cygport not pulling lzip
Hello, I run into the same problem as discussed in https://www.mail-archive.com/cygwin-apps@cygwin.com/msg37597.html I found no final decision in this mail thread and the problem is still existing. I would also expect cygport depends on lzip, since source files are provided in this format. Maybe also tar should depend on lzip. Best regards, Hannes
Re: setup 2.920 release candidate - please test
On 14/08/2022 17:47, Achim Gratz wrote: Christian Franke writes: This version aborts if "Sync" setting is reverted to "Best". If the abort goes away when building setup with the previous version of libsolv then you might have found an easier reproducer for a bug I'm chasing… Running it in gdb should get you a SIGSEGV in solver_addduprules in this case. After some staring at this crash and the code involved, I think the attached is the fix for this. I think this crash would only occur if the solver was used with at least one package marked for distupgrade, then reused without any.From 480123038537b89bcfca4a8ac9b40271eb7f5d5b Mon Sep 17 00:00:00 2001 From: Jon Turney Date: Sun, 14 Aug 2022 18:45:20 +0100 Subject: [PATCH] Ensure duplinvolvedmap_all is reset when a solver is reused Otherwise this can cause solver_addduprules() to be called even though needduprules is 0, which will crash because solver_createdupmaps() hasn't been called. --- src/solver.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/solver.c b/src/solver.c index 28341d6d..e3779e23 100644 --- a/src/solver.c +++ b/src/solver.c @@ -3533,6 +3533,7 @@ solver_solve(Solver *solv, Queue *job) map_zerosize(>bestupdatemap); solv->fixmap_all = 0; map_zerosize(>fixmap); + solv->dupinvolvedmap_all = 0; map_zerosize(>dupmap); map_zerosize(>dupinvolvedmap); solv->process_orphans = 0; -- 2.37.2 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: setup 2.920 release candidate - please test
On 14/08/2022 13:38, Christian Franke wrote: Jon Turney wrote: A new setup release candidate is available at: https://cygwin.com/setup/setup-2.920.x86_64.exe (64 bit version) https://cygwin.com/setup/setup-2.920.x86.exe (32 bit version) Please test, and report any problems here. This version aborts if "Sync" setting is reverted to "Best". Steps to reproduce: - Install from Internet - For All Users - Use System Proxy Settings - Mirror: any - Change "Best" -> "Sync" - Change "Sync" -> "Best" Result: Setup silently aborts, no setup.log* written. Thanks for the clear reproduction steps. I had reports that this setup version crashes, but nothing to investigate... [] libsolv: pkg rule creation took 0 ms --- Could not be reproduced with the released cygwin*.exe 2.919 from https://cygwin.com/ Could also be reproduced with - 32-bit version - current git HEAD - a rebuild of 2.919 from "git checkout release_2.919" Possible problem in conjunction with newer versions Mingw-w64 toolchain ? It's very likely caused by the long overdue libsolv update in that build. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: Perl distributions
The following Perl distributions have been updated to their latest release version available on CPAN: x86/x86_64 -- perl-Cpanel-JSON-XS-4.32-1 noarch -- perl-Alien-Build-2.56-1 perl-DateTime-TimeZone-2.53-1 perl-Test-Warn-0.37-1 -- *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Updated: Perl distributions
The following Perl distributions have been updated to their latest release version available on CPAN: x86/x86_64 -- perl-Cpanel-JSON-XS-4.32-1 noarch -- perl-Alien-Build-2.56-1 perl-DateTime-TimeZone-2.53-1 perl-Test-Warn-0.37-1 -- *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL.
Re: setup 2.920 release candidate - please test
Christian Franke writes: > This version aborts if "Sync" setting is reverted to "Best". If the abort goes away when building setup with the previous version of libsolv then you might have found an easier reproducer for a bug I'm chasing… Running it in gdb should get you a SIGSEGV in solver_addduprules in this case. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [PATCH setup] Add view mode "Unneeded"
On 02/08/2022 13:17, Christian Franke wrote:
In long standing cygwin installations, many no longer needed
automatically installed packages (e.g. libicuNN) accumulate. This patch
adds a new view which is possibly helpful to cleanup packages manually.
Some possible later enhancements:
- automatically refresh this view (a few seconds) after the user changed
a package status as this may add or remove entries.
- add a keyboard shortcut (^U) to the list view for "Uninstall this
package and then select next package"
Thanks. This looks good.
I think perhaps a better approach would be a view showing all packages
which aren't user_picked, or a dependency of a user_picked package.
(If I've read the code correctly your implementation has the weakness
that if e.g. appA -> libbB -> libC, which is then changed to appA ->
libD -> libE, it will only show libC as unneeded, then libB on the next
run?)
+// Scan installed or desired packages and collect the names of packages
+// which provide the dependencies of other packages or are member of
+// category "Base".
+static void FindNeededPackages (const packagedb & db, std::set &
needed)
+{
+ std::map providedBy;
+ for (const auto & p : db.packages)
+{
+ const packagemeta & pkg = *p.second;
+ if (!pkg.isBinary ())
+continue;
+ if (!(pkg.desired && (pkg.installed || pkg.picked (
+continue;
This seems redundant. Why can't this be just !pkg.desired?
This should also update the tooltip for the view dropdown
(IDS_VIEWBUTTON_TOOLTIP) to describe the new view.
Re: setup 2.920 release candidate - please test
Jon Turney wrote:
A new setup release candidate is available at:
https://cygwin.com/setup/setup-2.920.x86_64.exe (64 bit version)
https://cygwin.com/setup/setup-2.920.x86.exe (32 bit version)
Please test, and report any problems here.
This version aborts if "Sync" setting is reverted to "Best".
Steps to reproduce:
- Install from Internet
- For All Users
- Use System Proxy Settings
- Mirror: any
- Change "Best" -> "Sync"
- Change "Sync" -> "Best"
Result: Setup silently aborts, no setup.log* written.
Console output:
---
Starting cygwin install, version 2.920
User has backup/restore rights
User has symlink creation right
Current Directory: E:\install\cygwin
source: network install
root: C:\cygwin64 system
Selected local directory: E:\install\cygwin
net: Preconfig
site: https://ftp.fau.de/cygwin/
solving: 0 tasks, update: yes, use test packages: no
solving: 0 tasks, update: yes, use test packages: no
solving: 0 tasks, update: yes, use test packages: no
---
With -v option, console output ends with:
---
...
libsolv: obsoletes data: 1 entries
libsolv: added 0 pkg rules for installed solvables
libsolv: added 0 pkg rules for updaters of installed solvables
libsolv: added 0 pkg rules for packages involved in a job
libsolv: added 0 pkg rules because of weak dependencies
libsolv: 2457 of 28475 installable solvables considered for solving
libsolv: pkg rule memory used: 327 K
libsolv: pkg rule creation took 0 ms
---
Could not be reproduced with the released cygwin*.exe 2.919 from
https://cygwin.com/
Could also be reproduced with
- 32-bit version
- current git HEAD
- a rebuild of 2.919 from "git checkout release_2.919"
Possible problem in conjunction with newer versions Mingw-w64 toolchain ?
$ x86_64-w64-mingw32-g++ --version
x86_64-w64-mingw32-g++ (GCC) 11.3.0
$ x86_64-w64-mingw32-ld --version
GNU ld (GNU Binutils) 2.38
Found during testing of my recent setup patches ("Unneeded" view,
keyboard accelerators Ctrl+I/R/U), see cygwin-apps.
--
Regards,
Christian
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[PATCH setup] Keyboard accelerators for install/reinstall/uninstall
This eases state changes of a selected sequence of packages.
Ctrl+U is in particular useful to cleanup installations in conjunction
with "unneeded" view:
https://sourceware.org/pipermail/cygwin-apps/2022-August/042185.html
Open issue: Add some visual clue (tooltip?) to make this functionality
more obvious.
--
Regards,
Christian
From 71da4fbc68022b5083eba0cbdf2c0a4a541ddf1c Mon Sep 17 00:00:00 2001
From: Christian Franke
Date: Sun, 14 Aug 2022 13:43:48 +0200
Subject: [PATCH] Keyboard accelerators for install/reinstall/uninstall
Ctrl+I/R/U select install/reinstall/uninstall and then move selection
to next list item.
---
ListView.cc | 17 +++--
ListView.h | 3 ++-
PickCategoryLine.cc | 3 ++-
PickCategoryLine.h | 3 ++-
PickPackageLine.cc | 17 -
PickPackageLine.h | 3 ++-
package_meta.cc | 4
7 files changed, 43 insertions(+), 7 deletions(-)
diff --git a/ListView.cc b/ListView.cc
index 62a37ab..22009ba 100644
--- a/ListView.cc
+++ b/ListView.cc
@@ -564,14 +564,20 @@ ListView::OnNotify (NMHDR *pNmHdr, LRESULT *pResult)
NMLVKEYDOWN *pNmLvKeyDown = (NMLVKEYDOWN *)pNmHdr;
int iRow = ListView_GetSelectionMark(hWndListView);
#if DEBUG
- Log (LOG_PLAIN) << "LVN_KEYDOWN vkey " << pNmLvKeyDown->wVKey << " on
row " << iRow << endLog;
+ Log (LOG_PLAIN) << "LVN_KEYDOWN vkey " << pNmLvKeyDown->wVKey << " on
row " << iRow
+ << " Ctrl:" << !!(GetKeyState(VK_CONTROL) & 0x8000)
+ << " Alt:" << !!(GetKeyState(VK_MENU) & 0x8000) <<
endLog;
#endif
if (contents && iRow >= 0)
{
+ bool ctrl = !!(GetKeyState(VK_CONTROL) & 0x8000);
+ bool alt = !!(GetKeyState(VK_MENU) & 0x8000);
int col_num;
int action_id;
- if ((*contents)[iRow]->map_key_to_action(pNmLvKeyDown->wVKey,
_num, _id))
+ bool down = false;
+ if ((*contents)[iRow]->map_key_to_action(pNmLvKeyDown->wVKey, ctrl,
alt, _num,
+ _id, ))
{
int update;
if (action_id >= 0)
@@ -591,6 +597,13 @@ ListView::OnNotify (NMHDR *pNmHdr, LRESULT *pResult)
if (update > 0)
ListView_RedrawItems(hWndListView, iRow, iRow + update -1);
}
+ if (down && iRow + 1 < ListView_GetItemCount(hWndListView)) {
+ListView_SetItemState(hWndListView, -1, 0, LVIS_SELECTED |
LVIS_FOCUSED);
+ListView_SetItemState(hWndListView, iRow + 1, LVIS_SELECTED |
LVIS_FOCUSED,
+ LVIS_SELECTED | LVIS_FOCUSED);
+ListView_SetSelectionMark(hWndListView, iRow + 1);
+ListView_EnsureVisible(hWndListView, iRow + 1, false);
+ }
}
}
break;
diff --git a/ListView.h b/ListView.h
index 95dd9ee..a2ecdef 100644
--- a/ListView.h
+++ b/ListView.h
@@ -38,7 +38,8 @@ class ListViewLine
virtual ActionList *get_actions(int col) const = 0;
virtual int do_action(int col, int id) = 0;
virtual int do_default_action(int col) = 0;
- virtual bool map_key_to_action(WORD vkey, int *col_num, int *action_id)
const = 0;
+ virtual bool map_key_to_action(WORD vkey, bool ctrl, bool alt, int *col_num,
+ int *action_id, bool *down) const = 0;
};
typedef std::vector ListViewContents;
diff --git a/PickCategoryLine.cc b/PickCategoryLine.cc
index d2ac899..9872a2e 100644
--- a/PickCategoryLine.cc
+++ b/PickCategoryLine.cc
@@ -97,7 +97,8 @@ PickCategoryLine::get_tooltip(int col_num) const
}
bool
-PickCategoryLine::map_key_to_action(WORD vkey, int *col_num, int *action_id)
const
+PickCategoryLine::map_key_to_action(WORD vkey, bool ctrl, bool alt, int
*col_num,
+int *action_id, bool *down) const
{
switch (vkey)
{
diff --git a/PickCategoryLine.h b/PickCategoryLine.h
index 6a7321d..0bfba33 100644
--- a/PickCategoryLine.h
+++ b/PickCategoryLine.h
@@ -41,7 +41,8 @@ public:
ActionList *get_actions(int col) const;
int do_action(int col, int action_id);
int do_default_action(int col);
- bool map_key_to_action(WORD vkey, int *col_num, int *action_id) const;
+ bool map_key_to_action(WORD vkey, bool ctrl, bool alt, int *col_num,
+ int *action_id, bool *down) const;
private:
CategoryTree * cat_tree;
diff --git a/PickPackageLine.cc b/PickPackageLine.cc
index ae1e520..ba47e1f 100644
--- a/PickPackageLine.cc
+++ b/PickPackageLine.cc
@@ -145,7 +145,8 @@ PickPackageLine::get_indent() const
}
bool
-PickPackageLine::map_key_to_action(WORD vkey, int *col_num, int *action_id)
const
+PickPackageLine::map_key_to_action(WORD vkey, bool ctrl, bool alt, int
*col_num,
+ int *action_id, bool *down) const
{
switch (vkey)
{
@@ -154,6 +155,20 @@ PickPackageLine::map_key_to_action(WORD vkey, int
*col_num, int *action_id) cons
Re: Cygwin-X AWT windows snap back after drag in multi-window mode (w/example): long-standing issue
On 13/02/2022 16:14, John Harris wrote: For well over ten years, I (and other developers with the same configuration) have been experiencing this issue with Cygwin-X in multi-window mode with Java AWT apps. Sigh. The issue is simply that the first time (and only the first time) certain AWT dialogs are dragged to move them, they snap back to their original position. The problem exists across JDK's, computers, cygwin versions, fresh installs, and everything I've tried. This can easily be reproduced by compiling (javac) and running (java) the attached trivial AWT code. If you get this error at runtime: Thanks for the simple test case. This looks like a problem in the same area as [1], where AWT tries to detect what WM it running under, but doesn't really understand about non-reparenting WMs and messes up... This looks like a bug in AWT in that occurs with non-reparenting WMs (something like: learning the size of the "insets" (size of window frame and decorations) the first time a ConfigureNotify event occurs makes it move the window back to it's original location...) You can see some of what's happening if you turn on the sun.awt.X11.XDecoratedPeer logger in AWT. I tried a few things in the multiwindow mode WM as workarounds to avoid tripping over this behaviour in AWT, but without success, so I can only suggest you raise a bug on AWT. [1] https://cygwin.com/pipermail/cygwin-xfree/2010-July/034625.html -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin/X with Win10 display scaling corrupting font display of typed characters - Issue identified - "Solution" found
On 05/02/2022 14:25, Jon Turney wrote: On 27/01/2022 03:12, Ken Whitesell wrote: First, the bottom line: XWin.exe.manifest, line 21 change: PerMonitorV2,PerMonitor to PerMonitor Some details: I managed to get to a point where I could build the packages from source and install them. I looked at the commit you referred me to, and started reverting changes, one-by-one - at least in so far as the change appeared to make sense to me. Anyway, I got to this change, and sure enough, it worked. Removing the "PerMonitorV2" solved the issue. Also, I confirmed that it's the "PerMonitorV2" that is causing the issue and not having both of them by running another test with just the "PerMonitorV2" - and that still shows the problem. Thanks for taking the time to narrow this down. It's been very helpful. Working through the documented effects of that [1], I was able to work out that this mis-rendering is due to the non-client area scaling. [1] See under DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2 in https://docs.microsoft.com/en-us/windows/win32/hidpi/dpi-awareness-context If you turn off 'Hide Root Window' from the tray menu, you can kind of see what's going wrong: normally the client area of the X window is exactly aligned with that in the root window, but when the non-client area is rescaled by a DPI change (the title bar changes size significantly), it's misaligned so that part of the X window is outside the client area (and thus clipped in updates). I think this is due to the AdjustWindowsRectEx() function not being DPI aware (I guess it's always computing the non-client window rect based on the processes initial DPI) Unfortunately, from an initial look, rewriting things to use AdjustWindowRectExForDpi() isn't trivial (since we need to make 'DPI of the monitor this Window is going to end up on' available to it) So for the moment, I think I'll apply your reversion (although this probably comes at the cost of not scaling the window frame, the traymenu and About... dialog) I made this change in xserver 21.1.4-1. Thanks again for tracking this down. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Window flickering problem in XWin multiwindow mode
On 07/05/2022 03:01, S.J. Luo wrote: Hi, I have some EDA tools running on a Linux machine and display on my Windows PC using xorg-server-21.1.3 XWin multiwindow mode Sometimes the application window flickers forever for an unknown reason. The problem became more severe after my PC upgrade to Windows10. Knowing the root cause, I am now able to demonstrate the issue with a small test case as well as a patch that works for me. Both are attached below. Thanks very much for taking the time to look into this, and writing a patch. But I'd like to add a bit more commentary, which perhaps you can supply, about the analysis you did to determine: 1. how the code is misbehaving 2. how this change remedies that 3. how this change doesn't effect anything else What your fix does is examine the queue of pending WM messages to determine if there are any more pending for the window receiving a WM_WM_CHANGE_STATE message, and if there are, ignore it. It seems to me that is error prone, in a couple of ways: 1. it should check the message type as well, as e.g. a pending message of a different type could cause a WM_WM_CHANGE_STATE message to be ignored. 2. even then, assuming that successive WM_WM_CHANGE_STATE messages cancel out each other isn't always true e.g. consider a sequence of _NET_WM_STATE_ADD _NET_WM_STATE_MAXIMIZED_VERT followed by _NET_WM_STATE_ADD _NET_WM_STATE_MAXIMIZED_HORZ. Here I have some details on the problem: In following, WWCS means WM_WM_CHANGE_STATE There exists a message self-generating loop I.e., a WWCS message may generate another WWCS. winSendMessageToWM(WWCS) --> MultiWindowWMProc(WWCS) --> UpdateState() --> ShowWindow() --> MultiWindowProc(WM_SIZE) --> winAdjustXWindowState() --> winSendMessageToWM(WWCS) In normal case, there is a conditional code inside UpdateState() that could break the loop. if (current_state == state) return; Normally after maximizing the window, the WWCS just to be self-generated once. On processing the 2nd WWCS, the current window state matches WWCS target state and ShowWindow() won't be called and the loop could end. Initial Window state normal queue : | WWCS(max1) | --> process WWCS(max1) : Winow state (norm) != target state (max2) Set Window state to max and generate WWCS(max2) queue : | WWCS(max2) | --> Process WWCS(max2) : Winow state (max) == target state (max) break where WWCS(max1) means WWCS msg with target state max and 1 means first generated/inserted WWCS in queue. However, there is case triggering this loop running forever. Assuming intitially there are two WWCS message exists where one is to maximize window and one is to normal window The condition of state compare in UpdateState() would never match. And WWCS(max) and WWCS(norm) is going to self-generate in turn. Initial Window state normal queue : | WWCS(max1) | WWCS(norm1) | --> process WWCS(max1) Winow state (norm) != target state (max) Set window state to max and generate WWCS(max2) queue : | WWCS(norm1) | WWCS(max2) | --> Process WWCS(norm1) Winow state (max) != target state (norm) Set window state to norm and generate WWCS(norm2) queue : | WWCS(max2) | WWCS(norm2) | --> Process WWCS(max2) Winow state (norm) != target state (max) Set window state to max and generate WWCS(max3) queue : | WWCS(norm2) | WWCS(max3) | --> Process WWCS(norm2) Winow state (max) != target state (norm) Set window state to norm and generate WWCS(norm3) queue : | WWCS(max3) | WWCS(norm3) | : (loop forever) Thanks for providing this analysis. I just did some more study on the code of multiwindow window manager and X11 Window Properties as well as the questions you brought up. The first question : it should check the message type as well, as e.g. a different type mesage could cause WM_WM_CHANGE_STYLE to be ignored. Not sure what the "type" of a message means. Do you mean window manager message WM_x that is processed by winMultiWindowWMProc() where it is alreadychecked in HaveMessage(), or do you mean X message XCB_xx that is processed by winMultiWindowXMsgProc()? Maybe you can provide an example of another message type? I mean the various WM_WM_* messages, e.g. WM_WM_NAME_EVENT. The second question: Successive WM_WM_CHANGE_STATE messages cancel out each other isn't always true ex. _NET_WM_STATE_ADD _NET_WM_STATE_MAXIMIZED_VERT followed by _NET_WM_STATE_ADD _NET_WM_STATE_MAXIMIZED_HORZ. Inspecting the code that deal with XCB_CLIENT_MESSAGE, it seems already true before the patch: The window goes maximized only if X client do one _WM_STATE_ADD action with _NET_WM_STATE_MAXIMIZED_VERT and _NET_WM_STATE_MAXIMIZED_HORZ simultaneously specified. Otherwise, the WM_WM_CHANGE would not be sent to the queue. Well, that's arguably a bug in this code :) Further, in UpdateWindowState(), the state and related X properties are either all-overwritten or
[ANNOUNCEMENT] xorg-server-21.1.4-1
The following packages have been uploaded to the Cygwin distribution: * xorg-server-21.1.4-1 * xorg-server-common-21.1.4-1 * xorg-server-extra-21.1.4-1 * xorg-server-devel-21.1.4-1 * xorg-server-xorg-21.1.4-1 * xwinclip-21.1.4-1 These packages contain XWin and the other X.Org X11 servers. In addition to upstream fixes [1], the following cygwin-specific changes have been made since 21.1.2-3: * Fix some mis-rendering in multi-monitor configurations with disparate DPI values (Thanks to Ken Whitesell for tracking this down) Addresses: https://cygwin.com/pipermail/cygwin/2022-January/250544.html * Fix for a window getting stuck in a state where it's continuously switching between maximized and normal state (Thanks to S.J. Luo for the test case) Addresses: https://cygwin.com/pipermail/cygwin/2022-April/251305.html [1] https://lists.x.org/archives/xorg-announce/2022-July/003193.html -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
xorg-server-21.1.4-1
The following packages have been uploaded to the Cygwin distribution: * xorg-server-21.1.4-1 * xorg-server-common-21.1.4-1 * xorg-server-extra-21.1.4-1 * xorg-server-devel-21.1.4-1 * xorg-server-xorg-21.1.4-1 * xwinclip-21.1.4-1 These packages contain XWin and the other X.Org X11 servers. In addition to upstream fixes [1], the following cygwin-specific changes have been made since 21.1.2-3: * Fix some mis-rendering in multi-monitor configurations with disparate DPI values (Thanks to Ken Whitesell for tracking this down) Addresses: https://cygwin.com/pipermail/cygwin/2022-January/250544.html * Fix for a window getting stuck in a state where it's continuously switching between maximized and normal state (Thanks to S.J. Luo for the test case) Addresses: https://cygwin.com/pipermail/cygwin/2022-April/251305.html [1] https://lists.x.org/archives/xorg-announce/2022-July/003193.html
