Hello all,
I was just checking around some old bugs and found 786 still opened. I've
written a patch for it, but I want to know if I'm anywhere close to get it
in.
I'm sorry if I'm only wasting your time.
Matijn
Hi,
I know that CodeWeavers supports quite nicely Mac builds of Wine, and
CrossOver for Mac, yet all of them are X11.
There was also once Darwine - an effort to provide Carbon Wine UI
driver and Mac optimizations & L&F.
Pretty many of those were merged back to Wine, but not winequartz.drv.
Do you guys think about reviving winequartz.drv?
This would greatly improve Wine on Mac as we could have native Mac
fonts handling that's faster than FreeType, Dock icons for Wine
applications, and few others.
There's still old copy of the it hanging around, but it is abandoned,
and no longer compiles with Wine.
Or I think it would be cool to write new winecocoa.drv or sthing like
that, as Apple officially states that Carbon is deprecated.
While it is not well documented, it is pretty easy with Cocoa to make
console non-bundled process to be UI foreground process and handle
events and Dock:
(This code is copyrighted by myself ;P)
> int main(int argc, const char * argv[]) {
> ProcessSerialNumber psn = {0, kCurrentProcess};
> OSStatus returnCode = TransformProcessType(&psn,
> kProcessTransformToForegroundApplication);
> SetFrontProcess(&psn);
>
> NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
> [NSApplication sharedApplication];
>
> NSImage *icon = [NSImage imageNamed:@"NSApplicationIcon"];
> [NSApp setApplicationIconImage:icon];
>
> [NSApp finishLaunching];
>
> NSWindow *window = [[NSWindow alloc]
> initWithContentRect:NSMakeRect(0, 0, 100, 100)
> styleMask:NSTitledWindowMask|
> NSClosableWindowMask|NSMiniaturizableWindowMask|NSResizableWindowMask
> backing:NSBackingStoreBuffered defer:NO];
> [window center];
> [window setTitle:@"Test"];
>
> NSButton *button = [[NSButton alloc]
> initWithFrame:NSMakeRect(10, 10, 80, 80)];
> [button setTitle:@"What?"];
> [button setBezelStyle:1];
> [[window contentView] addSubview:button];
> [button release];
>
> [window makeKeyAndOrderFront:NSApp];
>
> while(1) {
> NSEvent *event = [NSApp
> nextEventMatchingMask:NSAnyEventMask
> untilDate
> :[NSDate distantFuture]
> inMode:NSDefaultRunLoopMode
> dequeue:YES
> ];
> if(event) [NSApp sendEvent:event];
> }
> [pool release];
> return 0;
> }
BTW. I heard that someone previously working for Wine project is now
in Apple, it is true?
Regards,
--
Adam Strzelecki |: nanoant.com :|
2009/6/30 Daniel Santos <javatroubadour(a)yahoo.com>:
> Some pointers are getting used prior to initialization. It would appear that the current compilers are initializing them to zero or we've been lucky.
>
No, the C standard specifies that these are initialized to NULL, since
they have static storage duration.
"Christoph von Wittich" <Christoph(a)ApiViewer.de> wrote:
> + if (*pcbProvName > INT_MAX)
> + *pcbProvName = INT_MAX;
In which way WideCharToMultiByte is broken? It always helps to provide
an explanation and if possible a test case.
--
Dmitry.
Strike that, I must have misread the documentation.
Only thing I am wondering is do we really need the (unsigned long) here?
If anyone has a pointer to clear documentation that would be nice; what I
found so far leaves some questions open...
Gerald
On Sun, 28 Jun 2009, Gerald Pfeifer wrote:
> The generated file include/bits1_5.h is the same before and after this
> patch, yet somehow the original form strikes me as a bit odd at best...
>
> Gerald
>
>
> ChangeLog:
> Fix prototype for GetReplyData().
>
> diff --git a/include/bits1_5.idl b/include/bits1_5.idl
> index 274a7de..29520e2 100644
> --- a/include/bits1_5.idl
> +++ b/include/bits1_5.idl
> @@ -39,7 +39,7 @@ interface IBackgroundCopyJob2 : IBackgroundCopyJob
> } BG_JOB_REPLY_PROGRESS;
>
> HRESULT GetReplyProgress([in, out] BG_JOB_REPLY_PROGRESS *progress);
> - HRESULT GetReplyData([out, size_is( , (unsigned long) *pLength)] byte **pBuffer,
> + HRESULT GetReplyData([out, size_is((unsigned long) *pLength)] byte **pBuffer,
> [in, out, unique] UINT64 *pLength);
> HRESULT SetReplyFileName([unique] LPCWSTR filename);
> HRESULT GetReplyFileName([out] LPWSTR *pFilename);
Hi,
http://bugs.winehq.org/show_bug.cgi?id=19028
winecfg on Mac OSX (10.5.6 and .7) does not link "My Videos" etc. to the
equivalent directories on the Mac. Everything is linked to $HOME (or was it
Desktop/?) instead. What a pity!
Mac OSX uses directories named Documents/, Pictures/, Videos/, Music/ -- even
in the German locale. The Finder GUI provides localized names. Unlike
XDG/Gnome there are no crazy hacks at session begin to rename directories based
on the session's locale.
I don't know how earlier releases of Mac OSX behave, i.e. whether these
directories have always been present. Does anyone know a reference?
I located the relevant places that would need a patch:
dlls/shell32/shellpath.c:_SHCreateSymbolicLinks
and possibly
dlls/shell32/xdg.c:XDG_UserDirLookup
However, some design issues are unclear to me, hence prevent me from writing a patch:
- In what order to add the Mac check?
- When to check for a folder named "My Documents" (MS-Windows non-localized
name in English locale, possibly translated), and when for "Documents"
(MacOS constant name)?
- Use XDG on the Mac or not? (if linked in, e.g. possibly when compiled via
MacPorts, which pulls in a zillion libraries. Apple does not provide
libfreedesktop.)
Thanks for your comments,
Jörg Höhle
Am Monday 29 June 2009 21:41:58 schrieb Tobias Jakobi:
+ const UINT max_lconsts = gl_info->ps_arb_max_local_constants;
Please use the GL_LIMITS macro for consistency
Am Monday 29 June 2009 21:42:20 schrieb Tobias Jakobi:
> + if (flags) FIXME("Only ordinary sampling from NP2
textures is supported.\n");
Why does projected sampling not work? Is this a limit of Tex_rect or the NP2
fixup code? TXB certainly does not work because tex_rect doesn't support
mipmapping
Its fine with me if projected texturing is just not implemented in this
patchset currently, I'm just curious. If it is not a GL limit it should just
work with the code you wrote, unless I am missing something.