January 2005 - Wine-Devel - list.winehq.org

Re: Fwd: Re: Q? system wide variables

by Lionel Ulmer

> For some reason setting Reply-To to the list never causes flamewars <grumble> Oh yes it would, believe me (at least I would fan the flame a little bit :-) ). Lionel (who really prefers not to have the Reply-To set to the list) -- Lionel Ulmer - http://www.bbrox.org/

Jan. 30, 2005

Re: Q? system wide variables

by Lionel Ulmer

On Sun, Jan 30, 2005 at 01:00:21AM +0100, Jakob Eriksson wrote: > They don't use X11. They even plan on loading native > binary 3D drivers. And this means that they cannot use Wine's Direct3D code as it does not respect Microsoft's internal APIs between 'user code' and the various HAL / HEL / DDKs and stuff. Lionel -- Lionel Ulmer - http://www.bbrox.org/

Jan. 30, 2005

Re: Q? system wide variables

by Lionel Ulmer

> What's the best place to do this? is the registry code > fast enough or should I add a new function to the X11 > driver so that I can request and release 'fake' video > memory and make all other AvailableVideoMemory > requests ask X11 driver? For me, I think the X11 driver should be the best place for it (at least the one the more 'Windows-like' as all our D3D, DDraw, .... implementations should be layered upon this driver). Lionel -- Lionel Ulmer - http://www.bbrox.org/

Jan. 30, 2005

Debian Winelib...

by Jakob Eriksson

titta här: Scott Ritchie wrote: <snip> >-I've got a special project I've been trying for a while involving >porting Miranda Instant Messenger with Winelib. In theory, I could >convert it into an Ubuntu package that runs on all arches with the Wine >package installed, even though Miranda is a windows program. If this >becomes easy it represents an amazingly huge step in application >compatibility - it won't be long before we start seeing other OSS apps >like DC++ or FileZilla coming into Ubuntu packages. Writing a howto >guide for this based on my experience is part of this goal. > > Inte så dumt eller hur?

Jan. 30, 2005

Re: RICHEDIT once again

by Rob Shearman

Krzysztof Foltman wrote: > Mike McCormack wrote: > >> It might be better to use libwineunicode and kernel32 unicode string >> manipulation functions rather than msvcrt ones. eg lstrlenW, >> lstrcpyW, etc. instead of wcslen, wcscpy, etc. Avoid the TCHAR type >> in Wine code. > > > Good point. I guess it would be nice to replace malloc/free with > LocalAlloc/LocalFree, right ? No, the LocalAlloc/LocalFree/GlobalAlloc/GlobalFree functions are relics from the old days of Win16. You should use HeapAlloc/HeapFree. >> haven't). We can merge the parser into the riched20 code quite >> easily... it's just enters the text into the existing control using >> EM_SETSEL and some formatting messages. > > > LOL :) That's a smart idea :) I'm curious about interactions with undo, > but we have no undo anyway (yet). Undo should be pretty easy as long as you can represent easily represent user actions in a transactions stack. A user doing something will then cause an action to be pushed onto the stack (although you would probably want some coalescing so that you don't have to undo each character you typed, you can just undo a sentence). The undo command will pop a transaction of the stack and apply the inverse. I've written a fairly nice implementation of this before in Java and it didn't take me very long. The code looks good. It looks like you have the basic actions nailed. However, there are a few superfluous typecasts. In particular, please remove the ALLOC_OBJ macro because the name seems to suggest it does more than it actually does. You may want to use the existing doubly-linked list implementation at include/wine/list.h as it has been well-tested and people are familiar with the API. This is just a suggestion and you may feel that it is easier to use your own. A few more comments wouldn't go amiss either. What is the ParaStyle structure used for? How does this relate to the Style structure? Each character can have a different style, so why is there a paragraph style? Rob

Jan. 30, 2005

Re: small fix SafeArryDestroy

by Rob Shearman

Rein Klazes wrote: >Hi, > >Makes WJChess, a French made chess game, accept moves. > >Changelog: > dlls/oleaut32 : safearray.c > SafeArrayDestroy() returns success when called with a NULL > pointer. > > It would be nice to have a test for this as there are already a large number of SafeArray tests. Rob

Jan. 30, 2005

Re: RICHEDIT once again

by Krzysztof Foltman

Mike McCormack wrote: > but I think the way forward is to submit an implementation of > dlls/riched20 then make that work, and after it's debugged and worked > out, rip out the old dlls/riched32 code and forward it to the new > completed riched20 code. I'd prefer to keep it as an app, not a DLL for a while. It just makes testing easier. > You've writen the code to deal with unicode as default, which is > good, but you need to deal with both ASCII and unicode messages in > the window procedure. Sure. And I guess it should be done before making a DLL out of it. > It might be better to use libwineunicode and kernel32 unicode string > manipulation functions rather than msvcrt ones. eg lstrlenW, > lstrcpyW, etc. instead of wcslen, wcscpy, etc. Avoid the TCHAR type > in Wine code. Good point. I guess it would be nice to replace malloc/free with LocalAlloc/LocalFree, right ? > Similarly, you'll need to use "winbase.h" and friends instead of > "windows.h". Good idea. Done. > From what I can see in the old riched32 code, the rtf parser looks > quite good, so don't try rewrite that I'm all for reusing existing Wine code. > haven't). We can merge the parser into the riched20 code quite > easily... it's just enters the text into the existing control using > EM_SETSEL and some formatting messages. LOL :) That's a smart idea :) I'm curious about interactions with undo, but we have no undo anyway (yet). > I have a test I can send to you if you wish. You mean, another container application ? That would be cool, my container is getting better but it's still not very good. > Again, my preference is to get this into the Wine CVS sooner rather > than later, so others can start helping improve it. I'll see what can be done. As soon as there is a minimal text manipulation API (based on RichEdit API, not on function calls), I can separate the control into a DLL and move the app code in the test directory. So far, the next version is available at: http://foltman.com/richtext-20050130b.tar.gz Main changes are: - editor.c contains a list of which messages/notifications/styles work and which don't - incomplete read-only mode - replacement of MSVCRT wcs functions with Win32 lstr - a modification flag - a shy attempt at starting undo - a #define to choose between my editor and the original RICHEDIT. It's not what I want it to be, but it's better than nothing.

Jan. 30, 2005

Re: Wine packages, universe maintainence, and myself

by Diego 'Flameeyes' Pettenò

On Sunday 30 January 2005 14:00, Mike Hearn wrote: > Final thing, we need a nice icon for win32 EXE files. I filed a bug > against gnome-icon-theme (really we want it in hicolor so non-GNOME users > get it too) but Jimmac is a busy busy man ... KDE's default theme (CrystalSVG) already has an exec_wine icon. I think it's worth to make the icons have the same name so that uses of different environments can make use of different icons (KDE should look inside the current selected theme, then in his default theme, then in hicolor, then in locolor, so if it finds the icon in his themes, it doesn't go look in the hicolor one). -- Diego "Flameeyes" Pettenò flameeyes(a)users.berlios.de - http://flameeyes.web.ctonet.it/

Jan. 30, 2005

Re: RICHEDIT once again

by Boaz Harrosh

Krzysztof Foltman wrote: > My rich text control is still far from even semi-complete, but I think > too much is done to start over, so I'm releasing it today. The number > one reason of its incompleteness is that I put more emphasis on making > things work exactly like in the original than on implementing more > functions. Sorry to be barging in like this and maybe it is all Old news. But ... I have been using in a few projects, Windows side and Linux, a grate rich edit control, I'm sure every body knows, and used even if he doesn't know. "Scintilla"! It has anything a RichEdit control needs (and much more but that does not have to be used). It even has the export to RTF function. (And to HTML for clipboard operations) It has 95% EditBox emulation. It is very stable, heavily used and debugged, and highly portable. The License is a BSD type license so I don't think it will be any problem. The only things missing are the RTF parser and the MS-RichEdit emulation (Data types and message translations). But it looks like these two are what above patch and existing code has. I am almost positive that if such a parser (And emulation layer) is submitted to the Scintilla project it will be farther maintained by the project. One more thing good about it, that makes a lot of sense, is its popularity, which means there are a lot of people that know this code-base and can help fix problems. (And it does compile under wine out of the box.) Please forgive me if all this is "Old News". I didn't check the archives. Any way just my $0.02. Free Life Boaz

Jan. 30, 2005

Re: Wine packages, universe maintainence, and myself

by Mike Hearn

On Sat, 29 Jan 2005 17:49:01 -0800, Scott Ritchie wrote: > We may want to have an entirely new applications menu for Wine. I > envision having Wine installed and then having it create a new folder > Applications->Wine, which will contain the Winecfg program labeled > "Configure Wine" as well as a near empty start menu with Wine's shipped > winelib Notepad program. When other windows programs get installed, > they can be put in the Wine start menu there. FWIW the GNOME HIG recommends stating what something is, rather than it's name. This makes sense because to a new Linux user the name "Wine" is meaningless, the fact that it's a cute abbreviation for Windows Emulator or "Wine is not an emulator" (depending on whether you read Slashdot) isn't obvious at all. So I think it'd make more sense to put a launcher called "Configure Windows Emulation" in the System tools/System settings menu, rather than give it a dedicated menu. We should do this in the upstream sources rather than have it be an Ubuntu specific patch. On menu integration: this is hard. Really hard. You do not want to know about the contortions we go through in Crossover to make it work. It's simpler for WineHQ because we can tell anybody not using bleeding-edge desktops that they lose, but even so I'd suggest starting by fixing the current menu code to write out .desktop files with a special category "Win32", and dumping them in ~/.local/share/applications or wherever they're supposed to go. That way you'd get all the Windows start menu items in one submenu. You lose the tree structure but that's not as big a deal as you may think, because a nearly empty start menu looks a bit weird and most of the time I guess Wine users will have one or two apps installed. You may need to wait for Hoary for this to work, as the current stable release of GNOME doesn't understand XDG menus which is the spec we must target. The unstable/development GNOME in Hoary does understand it. Oh, remember to make the .desktop files use the start.exe program ... some apps need that and it's an easy fix! Final thing, we need a nice icon for win32 EXE files. I filed a bug against gnome-icon-theme (really we want it in hicolor so non-GNOME users get it too) but Jimmac is a busy busy man ... thanks -mike

Jan. 30, 2005