Module: wine
Branch: master
Commit: 3b8f4a280c904b084733dacab722199728242135
URL: http://source.winehq.org/git/wine.git/?a=commit;h=3b8f4a280c904b084733dacab…
Author: Dmitry Timoshkov <dmitry(a)baikal.ru>
Date: Wed Dec 25 13:25:04 2013 +0900
cabinet: Remove a no longer valid comment about seeking and restoring CAB position.
---
dlls/cabinet/fdi.c | 30 ------------------------------
1 files changed, 0 insertions(+), 30 deletions(-)
diff --git a/dlls/cabinet/fdi.c b/dlls/cabinet/fdi.c
index f9e6522..ae0576b 100644
--- a/dlls/cabinet/fdi.c
+++ b/dlls/cabinet/fdi.c
@@ -543,36 +543,6 @@ static BOOL FDI_read_entries(
TRACE("(fdi == ^%p, hf == %ld, pfdici == ^%p)\n", fdi, hf, pfdici);
- /*
- * FIXME: I just noticed that I am memorizing the initial file pointer
- * offset and restoring it before reading in the rest of the header
- * information in the cabinet. Perhaps that's correct -- that is, perhaps
- * this API is supposed to support "streaming" cabinets which are embedded
- * in other files, or cabinets which begin at file offsets other than zero.
- * Otherwise, I should instead go to the absolute beginning of the file.
- * (Either way, the semantics of wine's FDICopy require me to leave the
- * file pointer where it is afterwards -- If Windows does not do so, we
- * ought to duplicate the native behavior in the FDIIsCabinet API, not here.
- *
- * So, the answer lies in Windows; will native cabinet.dll recognize a
- * cabinet "file" embedded in another file? Note that cabextract.c does
- * support this, which implies that Microsoft's might. I haven't tried it
- * yet so I don't know. ATM, most of wine's FDI cabinet routines (except
- * this one) would not work in this way. To fix it, we could just make the
- * various references to absolute file positions in the code relative to an
- * initial "beginning" offset. Because the FDICopy API doesn't take a
- * file-handle like this one, we would therein need to search through the
- * file for the beginning of the cabinet (as we also do in cabextract.c).
- * Note that this limits us to a maximum of one cabinet per. file: the first.
- *
- * So, in summary: either the code below is wrong, or the rest of fdi.c is
- * wrong... I cannot imagine that both are correct ;) One of these flaws
- * should be fixed after determining the behavior on Windows. We ought
- * to check both FDIIsCabinet and FDICopy for the right behavior.
- *
- * -gmt
- */
-
/* read in the CFHEADER */
if (fdi->read(hf, buf, cfhead_SIZEOF) != cfhead_SIZEOF) {
if (pmii) set_error( fdi, FDIERROR_NOT_A_CABINET, 0 );
Module: wine
Branch: master
Commit: bcde44fb8a34a9fc9bab60a8ff90700f07b0d6c4
URL: http://source.winehq.org/git/wine.git/?a=commit;h=bcde44fb8a34a9fc9bab60a8f…
Author: Ken Thomases <ken(a)codeweavers.com>
Date: Tue Dec 31 01:05:13 2013 -0600
winemac: Explicitly unhide the app early when showing windows.
Cocoa would implictly unhide it when we order a window, anyway. Doing it
early avoids problems from querying -[NSWindow isVisible] while the app is
hidden. That method returns FALSE even for windows which would be visible
if the app weren't hidden.
---
dlls/winemac.drv/cocoa_window.m | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/dlls/winemac.drv/cocoa_window.m b/dlls/winemac.drv/cocoa_window.m
index a025d59..07abbca 100644
--- a/dlls/winemac.drv/cocoa_window.m
+++ b/dlls/winemac.drv/cocoa_window.m
@@ -1118,9 +1118,11 @@ static inline NSUInteger adjusted_modifiers_for_option_behavior(NSUInteger modif
if (![self isMiniaturized])
{
BOOL needAdjustWindowLevels = FALSE;
- BOOL wasVisible = [self isVisible];
+ BOOL wasVisible;
[controller transformProcessToForeground];
+ [NSApp unhide:nil];
+ wasVisible = [self isVisible];
if (activate)
[NSApp activateIgnoringOtherApps:YES];
Module: wine
Branch: master
Commit: 6447e8e75cd8eb7b50b385d1b98b2f9ae76e4b04
URL: http://source.winehq.org/git/wine.git/?a=commit;h=6447e8e75cd8eb7b50b385d1b…
Author: Ken Thomases <ken(a)codeweavers.com>
Date: Tue Dec 31 01:05:05 2013 -0600
winemac: Defer adjusting window levels while the process is hidden.
While the process is hidden, it can't get a list of its windows which would
be visible were it not hidden.
---
dlls/winemac.drv/cocoa_app.m | 14 ++++++++++++--
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/dlls/winemac.drv/cocoa_app.m b/dlls/winemac.drv/cocoa_app.m
index c31bceb..17644d0 100644
--- a/dlls/winemac.drv/cocoa_app.m
+++ b/dlls/winemac.drv/cocoa_app.m
@@ -488,8 +488,8 @@ int macdrv_err_on;
- (void) adjustWindowLevels:(BOOL)active
{
- NSArray* windowNumbers = [NSWindow windowNumbersWithOptions:0];
- NSMutableArray* wineWindows = [[NSMutableArray alloc] initWithCapacity:[windowNumbers count]];
+ NSArray* windowNumbers;
+ NSMutableArray* wineWindows;
NSNumber* windowNumber;
NSUInteger nextFloatingIndex = 0;
__block NSInteger maxLevel = NSIntegerMin;
@@ -497,6 +497,11 @@ int macdrv_err_on;
__block WineWindow* prev = nil;
WineWindow* window;
+ if ([NSApp isHidden]) return;
+
+ windowNumbers = [NSWindow windowNumbersWithOptions:0];
+ wineWindows = [[NSMutableArray alloc] initWithCapacity:[windowNumbers count]];
+
// For the most part, we rely on the window server's ordering of the windows
// to be authoritative. The one exception is if the "floating" property of
// one of the windows has been changed, it may be in the wrong level and thus
@@ -2127,6 +2132,11 @@ int macdrv_err_on;
[self releaseMouseCapture];
}
+ - (void) applicationDidUnhide:(NSNotification*)aNotification
+ {
+ [self adjustWindowLevels];
+ }
+
- (BOOL) applicationShouldHandleReopen:(NSApplication*)theApplication hasVisibleWindows:(BOOL)flag
{
// Note that "flag" is often wrong. WineWindows are NSPanels and NSPanels