Re: wined3d: Silence a noisy fixme.
I don't think so. That FIXME should have been an ERR, and if you're seeing it that's a bug.
How do you make x64 crosstests?
_
Re: Addition of En resources to non-En resources
Francois Gouget fgou...@free.fr wrote: Requiring that translators master both skills severly limits the pool of translators we can draw from. Doesn't this sound similar to so called limitation that exists for people willing to work on Wine code, but have no appropriate skills? I.e. there is always a choice between quality and quantity. Introducing po files lets us treat each task independently and leverage all the online po translation tools. We will still need people to take on the somwhat unsexy control resizing task and that may be a problem. If it turns out we lack volunteers for that we may turn to some automatic layout scheme, for instance describe the resources in a glade-like language and translate+convert them to rc files at build time. Sounds not very exciting. If there is a choice of having resources with properly placed and sized controls but english only, vs. translated but with broken layout ones, then I'm afraid most users would prefer an english variant. I was replying to a comment saying basically me too which the sender tends to reply to almost every message. The sender is excited by the prospect of rc files being used for translating Wine resources and that's pretty understandable. I am too! Good to know. -- Dmitry.
Re: Addition of En resources to non-En resources
On 06/25/2010 11:04 AM, Dmitry Timoshkov wrote: Francois Gougetfgou...@free.fr wrote: We will still need people to take on the somwhat unsexy control resizing task and that may be a problem. If it turns out we lack volunteers for that we may turn to some automatic layout scheme, for instance describe the resources in a glade-like language and translate+convert them to rc files at build time. Sounds not very exciting. If there is a choice of having resources with properly placed and sized controls but english only, vs. translated but with broken layout ones, then I'm afraid most users would prefer an english variant. Once we start using po files we can probably get rid of the 'transl' website as those stats will come from whatever tool we choose to deal with po files. For the actual resources and their size/placements it would be nice to have a tool/website as well that could be used to show how the translated language actually looks in a menu/dialog/whatever with even the possibility to change things. Is that feasible? -- Cheers, Paul.
Re: Addition of En resources to non-En resources
Paul Vriens paul.vriens.w...@gmail.com wrote: For the actual resources and their size/placements it would be nice to have a tool/website as well that could be used to show how the translated language actually looks in a menu/dialog/whatever with even the possibility to change things. Is that feasible? What's wrong with running a test application with those menus/dialogs under Wine? What's the reason to complicate things by separating tasks of translating and verifying the result of the translation? -- Dmitry.
Re: Addition of En resources to non-En resources
On 06/25/2010 11:23 AM, Dmitry Timoshkov wrote: Paul Vrienspaul.vriens.w...@gmail.com wrote: For the actual resources and their size/placements it would be nice to have a tool/website as well that could be used to show how the translated language actually looks in a menu/dialog/whatever with even the possibility to change things. Is that feasible? What's wrong with running a test application with those menus/dialogs under Wine? What's the reason to complicate things by separating tasks of translating and verifying the result of the translation? Well, nothing is wrong with that I guess. It's however geared to people who are coders, not? What we see is that there are several people who want to help us with the translation part but have no idea how to code (or are actually willing to code). We could use them, especially for the more exotic (or let's call it less mainstream) languages. -- Cheers, Paul.
Re: Addition of En resources to non-En resources
On Fri, Jun 25, 2010 at 11:14, Paul Vriens paul.vriens.w...@gmail.comwrote: On 06/25/2010 11:04 AM, Dmitry Timoshkov wrote: Francois Gougetfgou...@free.fr wrote: We will still need people to take on the somwhat unsexy control resizing task and that may be a problem. If it turns out we lack volunteers for that we may turn to some automatic layout scheme, for instance describe the resources in a glade-like language and translate+convert them to rc files at build time. Sounds not very exciting. If there is a choice of having resources with properly placed and sized controls but english only, vs. translated but with broken layout ones, then I'm afraid most users would prefer an english variant. Once we start using po files we can probably get rid of the 'transl' website as those stats will come from whatever tool we choose to deal with po files. For the actual resources and their size/placements it would be nice to have a tool/website as well that could be used to show how the translated language actually looks in a menu/dialog/whatever with even the possibility to change things. Is that feasible? Why reinventing the wheel? Such a tool already exists (ResHacker or similar). What we should do to attract more people is to provide a more user-friendly web page/ translator page explaining in greater detail: - how to find what has to be translated (translation statistics, .rc files, ...) - how to edit a file (#pragma code_page, encoding, menu accelerators, ...) - how to check/adapt actual results with ResHacker, since you have to either adapt the text to fit in, or the dialogs size) - how to create a patch OR send it to e.g. translat...@winehq.org for inclusion I may help in doing this. Furthermore, on the main web page, Development - Become a Wine developer can be intimidating for some potential translators (most non-developers potential translators would not consider themselves... well... developers!). Maybe something like Contribute - How you can help (or similar) would be less repulsive. Frédéric
Re: Addition of En resources to non-En resources
On 6/25/2010 13:29, Paul Vriens wrote: On 06/25/2010 11:23 AM, Dmitry Timoshkov wrote: Paul Vrienspaul.vriens.w...@gmail.com wrote: For the actual resources and their size/placements it would be nice to have a tool/website as well that could be used to show how the translated language actually looks in a menu/dialog/whatever with even the possibility to change things. Is that feasible? What's wrong with running a test application with those menus/dialogs under Wine? What's the reason to complicate things by separating tasks of translating and verifying the result of the translation? Well, nothing is wrong with that I guess. It's however geared to people who are coders, not? What we see is that there are several people who want to help us with the translation part but have no idea how to code (or are actually willing to code). We could use them, especially for the more exotic (or let's call it less mainstream) languages. Hi. Personally I don't see anything complicated or wrong about using .rc files, but yes, it's a bit painful for a contributor that wants to spend some time and discovers that he needs to do some rebuild-n-resize iterations to make it look nice. So correct me if I'm wrong - a po file could be tested without rebuild, right? For a problem with adjusting sizes we could find some free resource GUI tool I guess that creates a dialog as a IDE form designer, and allows for changes made to go directly to rc (with a way to simply switch languages of course). If there's a such way to do I don't see any problem for a non-coders to make changes.
Re: Addition of En resources to non-En resources
Paul Vriens paul.vriens.w...@gmail.com wrote: For the actual resources and their size/placements it would be nice to have a tool/website as well that could be used to show how the translated language actually looks in a menu/dialog/whatever with even the possibility to change things. Is that feasible? What's wrong with running a test application with those menus/dialogs under Wine? What's the reason to complicate things by separating tasks of translating and verifying the result of the translation? Well, nothing is wrong with that I guess. It's however geared to people who are coders, not? Of course not, that's proven by the amount of new translations we see these days from new people, who apparently are not coders. What we see is that there are several people who want to help us with the translation part but have no idea how to code (or are actually willing to code). We could use them, especially for the more exotic (or let's call it less mainstream) languages. Since when the editing of .rc files started to require coding skills? -- Dmitry.
Fwd: Possible patch for #12706
This is a patch that makes WINE detect snd_usb_audio mics and assign
them a mixer and working master control. See bug #12706 for more
information about this problem: http://bugs.winehq.org/show_bug.cgi?id=12706
I wasn't able to test it completely because I wasn't able to switch my
default input device to the USB mic and no one in IRC is helping with
this, but it might make things work because theoretically the only
problem was that WINE was ignoring devices that looked like
snd_usb_audio's microphones. I suggest that someone who CAN get
snd_usb_audio mic as their default test it out and confirm, I would
really appreciate that.
Thanks to all in IRC who helped me get things this far, especially
mlankhorst.
This patch is based against the current git HEAD, eaa227c12d8bb. I've
also posted it at the aforementioned bug.
--
Jeff Cook
(801) 231-3157
j...@deserettechnology.com
diff --git a/dlls/winealsa.drv/mixer.c b/dlls/winealsa.drv/mixer.c
index cfdf95f..352bc83 100644
--- a/dlls/winealsa.drv/mixer.c
+++ b/dlls/winealsa.drv/mixer.c
@@ -245,6 +245,10 @@ static void fillcontrols(mixer *mmixer)
for (id = 0; id mmixer-chans; ++id)
{
line *mline = mmixer-lines[id];
+if (!mline-elem)
+{
+break;
+}
int ofs = CONTROLSPERLINE * id;
int x;
long min, max;
@@ -258,6 +262,7 @@ static void fillcontrols(mixer *mmixer)
else
snd_mixer_selem_get_playback_volume_range(mline-elem, min, max);
+
/* (!snd_mixer_selem_has_playback_volume(elem) || snd_mixer_selem_has_capture_volume(elem)) */
/* Volume, always enabled by definition of blacklisted channels */
mmixer-controls[ofs].enabled = 1;
@@ -332,17 +337,23 @@ static void filllines(mixer *mmixer, snd_mixer_elem_t *mastelem, snd_mixer_elem_
snd_mixer_elem_t *elem;
line *mline = mmixer-lines;
-/* Master control */
-MultiByteToWideChar(CP_UNIXCP, 0, snd_mixer_selem_get_name(mastelem), -1, mline-name, sizeof(mline-name)/sizeof(WCHAR));
-mline-component = getcomponenttype(snd_mixer_selem_get_name(mastelem));
-mline-dst = 0;
-mline-capt = 0;
-mline-elem = mastelem;
-mline-chans = chans(mmixer, mastelem, 0);
-
-snd_mixer_elem_set_callback(mastelem, elem_callback);
-snd_mixer_elem_set_callback_private(mastelem, mmixer);
-
+if (mastelem) {
+FIXME(mastelem found on %s, building master...\n);
+/* Master control */
+MultiByteToWideChar(CP_UNIXCP, 0, snd_mixer_selem_get_name(mastelem), -1, mline-name, sizeof(mline-name)/sizeof(WCHAR));
+mline-component = getcomponenttype(snd_mixer_selem_get_name(mastelem));
+mline-dst = 0;
+mline-capt = 0;
+mline-elem = mastelem;
+mline-chans = chans(mmixer, mastelem, 0);
+
+snd_mixer_elem_set_callback(mastelem, elem_callback);
+snd_mixer_elem_set_callback_private(mastelem, mmixer);
+} else {
+FIXME(no mastelem, skipping\n);
+MultiByteToWideChar(CP_UNIXCP, 0, Empty Master Element, -1, mline-name, sizeof(mline-name)/sizeof(WCHAR));
+}
+
/* Capture control
* Note: since mmixer-dests = 1, it means only playback control is visible
* This makes sense, because if there are no capture sources capture control
@@ -352,8 +363,10 @@ static void filllines(mixer *mmixer, snd_mixer_elem_t *mastelem, snd_mixer_elem_
++mline;
if (capt)
{
+FIXME(captelem found\n);
MultiByteToWideChar(CP_UNIXCP, 0, snd_mixer_selem_get_name(captelem), -1, mline-name, sizeof(mline-name)/sizeof(WCHAR));
mline-component = getcomponenttype(snd_mixer_selem_get_name(captelem));
+FIXME(elem name: %s\n, snd_mixer_selem_get_name(captelem));
mline-dst = 1;
mline-capt = 1;
mline-elem = captelem;
@@ -361,6 +374,8 @@ static void filllines(mixer *mmixer, snd_mixer_elem_t *mastelem, snd_mixer_elem_
snd_mixer_elem_set_callback(captelem, elem_callback);
snd_mixer_elem_set_callback_private(captelem, mmixer);
+} else {
+FIXME(no capt\n);
}
for (elem = snd_mixer_first_elem(mmixer-mix); elem; elem = snd_mixer_elem_next(elem))
@@ -395,6 +410,24 @@ static void filllines(mixer *mmixer, snd_mixer_elem_t *mastelem, snd_mixer_elem_
}
}
+static void filllines_no_master(mixer *mmixer, snd_mixer_elem_t *captelem, int capt)
+{
+snd_mixer_elem_t *elem;
+line *mline = mmixer-lines;
+
+FIXME(captelem found\n);
+MultiByteToWideChar(CP_UNIXCP, 0, snd_mixer_selem_get_name(captelem), -1, mline-name, sizeof(mline-name)/sizeof(WCHAR));
+mline-component = getcomponenttype(snd_mixer_selem_get_name(captelem));
+FIXME(elem name: %s\n, snd_mixer_selem_get_name(captelem));
+mline-dst = 0;
+mline-capt = 1;
+mline-elem = captelem;
+mline-chans = chans(mmixer, captelem, 1);
+
+snd_mixer_elem_set_callback(captelem,
Re: Addition of En resources to non-En resources
On 06/25/2010 11:44 AM, Dmitry Timoshkov wrote: Paul Vrienspaul.vriens.w...@gmail.com wrote: For the actual resources and their size/placements it would be nice to have a tool/website as well that could be used to show how the translated language actually looks in a menu/dialog/whatever with even the possibility to change things. Is that feasible? What's wrong with running a test application with those menus/dialogs under Wine? What's the reason to complicate things by separating tasks of translating and verifying the result of the translation? Well, nothing is wrong with that I guess. It's however geared to people who are coders, not? Of course not, that's proven by the amount of new translations we see these days from new people, who apparently are not coders. Yes, but that also sometimes requires volunteers to do the actual work (editing the resource files and creating patches) for them. I mean, I did a lot of work for Danish and Michael is doing the same for Romanian. It would be much nicer if that can be automated in some way. What we see is that there are several people who want to help us with the translation part but have no idea how to code (or are actually willing to code). We could use them, especially for the more exotic (or let's call it less mainstream) languages. Since when the editing of .rc files started to require coding skills? Fine, let's call it editing an up to date file and creating a patch out of that. -- Cheers, Paul.
Re: Addition of En resources to non-En resources
Paul Vriens paul.vriens.w...@gmail.com wrote: What we see is that there are several people who want to help us with the translation part but have no idea how to code (or are actually willing to code). We could use them, especially for the more exotic (or let's call it less mainstream) languages. Since when the editing of .rc files started to require coding skills? Fine, let's call it editing an up to date file and creating a patch out of that. Creating an actual patch could be done someone else of course. I'm just curious, how the result of translating a .po file was supposed to be sent? Isn't it going to be a patch of some kind in any case? -- Dmitry.
Re: Addition of En resources to non-En resources
On 06/25/2010 12:08 PM, Dmitry Timoshkov wrote: Paul Vrienspaul.vriens.w...@gmail.com wrote: What we see is that there are several people who want to help us with the translation part but have no idea how to code (or are actually willing to code). We could use them, especially for the more exotic (or let's call it less mainstream) languages. Since when the editing of .rc files started to require coding skills? Fine, let's call it editing an up to date file and creating a patch out of that. Creating an actual patch could be done someone else of course. I'm just curious, how the result of translating a .po file was supposed to be sent? Isn't it going to be a patch of some kind in any case? I'm actually not sure if somebody already has an idea how to approach this. I guess that we will end up with both resource files and po files in our tree and that we indeed will have patches to po files as well. The difference however could be that we could have a translation tool in place (for example Pootle if that's viable) that automatically generates the patches and sends them to wine-patches. One can even think of some 'approval layer' in between to verify if the translations actually messes up the layout. Why don't we add this as a nice topic for the next WineConf? -- Cheers, Paul.
Re: Addition of En resources to non-En resources
Dmitry Timoshkov wrote: Paul Vriens paul.vriens.w...@gmail.com wrote: What we see is that there are several people who want to help us with the translation part but have no idea how to code (or are actually willing to code). We could use them, especially for the more exotic (or let's call it less mainstream) languages. Since when the editing of .rc files started to require coding skills? Fine, let's call it editing an up to date file and creating a patch out of that. Creating an actual patch could be done someone else of course. I'm just curious, how the result of translating a .po file was supposed to be sent? Isn't it going to be a patch of some kind in any case? Yes, but that can be automatically generated by the web based translation tool we use. There are a few to choose from. bye michael
Re: Addition of En resources to non-En resources
Michael Stefaniuc mstef...@redhat.com wrote: What we see is that there are several people who want to help us with the translation part but have no idea how to code (or are actually willing to code). We could use them, especially for the more exotic (or let's call it less mainstream) languages. Since when the editing of .rc files started to require coding skills? Fine, let's call it editing an up to date file and creating a patch out of that. Creating an actual patch could be done someone else of course. I'm just curious, how the result of translating a .po file was supposed to be sent? Isn't it going to be a patch of some kind in any case? Yes, but that can be automatically generated by the web based translation tool we use. There are a few to choose from. How is that different from transalting an .rc file and generating a patch from the resulting translation? -- Dmitry.
Re: Addition of En resources to non-En resources
Dmitry Timoshkov wrote: Michael Stefaniuc mstef...@redhat.com wrote: What we see is that there are several people who want to help us with the translation part but have no idea how to code (or are actually willing to code). We could use them, especially for the more exotic (or let's call it less mainstream) languages. Since when the editing of .rc files started to require coding skills? Fine, let's call it editing an up to date file and creating a patch out of that. Creating an actual patch could be done someone else of course. I'm just curious, how the result of translating a .po file was supposed to be sent? Isn't it going to be a patch of some kind in any case? Yes, but that can be automatically generated by the web based translation tool we use. There are a few to choose from. How is that different from transalting an .rc file and generating a patch from the resulting translation? For Alexandre there is no difference; he gets a patch on wine-patches and does his emacs magic on it. But we do not care about Alexandre here ;) For the translator it is a matter of just pressing Submit in the web translation tool he used. I hope I don't have to explain the differences to the manual git way... ;) bye michael
Re: Addition of En resources to non-En resources
Michael Stefaniuc mstef...@redhat.com wrote: How is that different from transalting an .rc file and generating a patch from the resulting translation? For Alexandre there is no difference; he gets a patch on wine-patches and does his emacs magic on it. But we do not care about Alexandre here ;) For the translator it is a matter of just pressing Submit in the web translation tool he used. I hope I don't have to explain the differences to the manual git way... ;) So, is it Alexandre or somebody else who is responsible for verifying that the translation is acceptable, and doesn't break existing layout of controls, and doesn't break other things because the translator simply didn't see things like a requirement written in capital letters in comdlg32 .rc files that common dialogs should not be resized? -- Dmitry.
Re: Addition of En resources to non-En resources
On Fri, 25 Jun 2010, Dmitry Timoshkov wrote: Francois Gouget fgou...@free.fr wrote: Requiring that translators master both skills severly limits the pool of translators we can draw from. Doesn't this sound similar to so called limitation that exists for people willing to work on Wine code, but have no appropriate skills? Absolutely not. For the coding part there is no other choice. For translations we can do better by reusing existing tools. [...] Sounds not very exciting. If there is a choice of having resources with properly placed and sized controls but english only, vs. translated but with broken layout ones, then I'm afraid most users would prefer an english variant. You seem to think that the current situation results in a few translations with perfectly laid out dialogs. I did a few simple tests that make me pretty skeptical of that: dlls/comdlg32/cdlg_En.rc: LTEXT List Files of Type:, 1089, 6, 104, 90, 9 dlls/comdlg32/cdlg_Eo.rc: LTEXT Dosierspeco:, 1089, 6, 104, 90, 9 dlls/comdlg32/cdlg_Wa.rc: LTEXT Djveye des fitchs del srte:, 1089, 6, 104, 90, 9 dlls/comdlg32/cdlg_Fi.rc: LTEXT Luettele tiedostot tyypeittin:, 1089, 6, 104, 90, 9 [27 more] dlls/msvfw32/msvfw32_En.rc:PUSHBUTTON About...,883,129,52,49,14 dlls/msvfw32/msvfw32_Da.rc:PUSHBUTTON Om...,883,129,52,49,14 dlls/msvfw32/msvfw32_Ru.rc:PUSHBUTTON Информация...,883,129,52,49,14 dlls/msvfw32/msvfw32_Uk.rc:PUSHBUTTON Інформація...,883,129,52,49,14 [14 more] dlls/shell32/shell32_Ja.rc: LTEXT Wine was brought to you by:, IDC_ABOUT_WINE_TEXT, 8, 54, 204, 10 dlls/shell32/shell32_Es.rc: LTEXT Wine le ha sido proporcionado por:, IDC_ABOUT_WINE_TEXT, 8, 54, 204, 10 dlls/shell32/shell32_Si.rc: LTEXT Wine smo ustvarili:, IDC_ABOUT_WINE_TEXT, 8, 54, 204, 10 dlls/shell32/shell32_Sv.rc: LTEXT Wine hade inte varit mjligt utan dessa personer:, IDC_ABOUT_WINE_TEXT, 8, 54, 204, 10 [18 more] dlls/winspool.drv/En.rc:LTEXT Output File Name:, -1, 7, 13, 194, 13, WS_VISIBLE dlls/winspool.drv/Pl.rc:LTEXT Nazwa pliku do ktrego ma by zapisany wydruk:, -1, 7, 13, 194, 13, WS_VISIBLE dlls/winspool.drv/No.rc:LTEXT Ut-fil:, -1, 7, 13, 194, 13, WS_VISIBLE [19 more] These were picked at random. Isn't it strange how all these translated controls have the same size as the English version despite widely different text content? So in fact all you get with the status-quo is few translations *AND* broken dialog layouts. -- Francois Gouget fgou...@free.fr http://fgouget.free.fr/ It really galls me that most of the computer power in the world is wasted on screen savers. Chris Caldwell from the GIMPS project http://www.mersenne.org/prime.htm
Re: [PATCH] [try 4] ddraw: Grow indexbuffer as needed
Mikko Rasa t...@tdb.fi writes:
+/* check that the buffer is large enough to hold the indices,
+ * reallocate if necessary.
+ */
+hr = IWineD3DBuffer_GetDesc(This-indexbuffer, desc);
+if(desc.Size IndexCount * sizeof(WORD))
+{
+UINT size = desc.Size;
+IWineD3DBuffer *buffer;
+IUnknown *parent;
+
+while(size IndexCount * sizeof(WORD))
+{
+size = 1;
+/* We keep adding zero bits to the right, so an overflow
+ * will eventually result in all zeroes. Detect this to
+ * avoid infinite loop.
+ */
+if(!size)
+{
+ERR(UINT overflow while trying to grow indexbuffer to hold
%u indices\n, IndexCount);
+LeaveCriticalSection(ddraw_cs);
+return D3DERR_TOOMANYPRIMITIVES;
+}
+}
A simple size = max(desc.Size*2,IndexCount*sizeof(WORD)) would do just as
well.
--
Alexandre Julliard
julli...@winehq.org
Re: sorry guys... slow on uptake today :)
Misha Koshelev misha...@gmail.com wrote: So I've been working on bug 13891, but got sidetracked by what I thought was a race condition as dlls/shell32/tests/shlexec.c was hanging. Spent several hours tracing it to line 464 in dlls/ntdll/directory.c if (stat( entry-mnt_dir, st ) == -1) continue; (read from /etc/mtab) Turned out it was my curlftpfs file system, which tends to disconnect randomly and not unmount (doh!). Anyway I hope to have perhaps some tests for this bug before I leave to Russia (on Sat morning), but unfortunately I might not be able to get this bug fixed until post-code freeze. Sorry :( If the fix is large and ugly, it will not be looked at until after the code freeze is lifted anyway. Have a safe travel. James Mckenzie
Re: sorry guys... slow on uptake today :)
On Fri, 2010-06-25 at 07:31 -0700, James Mckenzie wrote: Misha Koshelev misha...@gmail.com wrote: So I've been working on bug 13891, but got sidetracked by what I thought was a race condition as dlls/shell32/tests/shlexec.c was hanging. Spent several hours tracing it to line 464 in dlls/ntdll/directory.c if (stat( entry-mnt_dir, st ) == -1) continue; (read from /etc/mtab) Turned out it was my curlftpfs file system, which tends to disconnect randomly and not unmount (doh!). Anyway I hope to have perhaps some tests for this bug before I leave to Russia (on Sat morning), but unfortunately I might not be able to get this bug fixed until post-code freeze. Sorry :( If the fix is large and ugly, it will not be looked at until after the code freeze is lifted anyway. Ah I see :) Have a safe travel. Thank you. Much appreciated. James Mckenzie
[no subject]
On 24 June 2010 05:18, Misha Koshelev misha680 at gmail.com wrote: Dan suggested tests ok during code freeze so blame Dan for my patches ;) Certainly will. wine-devel is an open mailing list, and posting is easy. You'll probably want to check with something like git shortlog -s -n if the advice you're getting is actually worth taking. The way I see it, you have more experience with getting patches accepted yourself. More to the point, if you look at http://source.winehq.org/patches/, you'll see 62909 is marked as Deferred, so resending in a slightly different form isn't going to help much. As for the patch itself, I'm not convinced there's value in having a separate file for Shape Drawing Functions, these are clearly mesh constructors. I thought the original patch was mostly ok in that regard, although there are (very) minor issues like using %d for unsigned arguments and using imo ugly typedefs like LPDIRECT3DDEVICE9 over simply IDirect3DDevice9 *. So I don't think I'm going to be getting much productive done with 1.2 bugs done in a single day, and the one I started working on yesterday is now fixed. So might as well start thinking about D3DX9. So here is why I thought maybe having a separate shape.c file might be good. I am very new to D3DX9 so please pardon my ignorance, but simply looking at SDK, I see: i) http://msdn.microsoft.com/en-us/library/bb172976%28v=VS.85%29.aspx Shape Drawing Functions are all defined in D3dx9shape.h whereas http://msdn.microsoft.com/en-us/library/bb172973%28v=VS.85%29.aspx Mesh Functions are all defined in D3dx9mesh.h This is not a reason to implement shape drawing functions in a separate file _per se_, but additionally: ii) all the tests in mesh.c do not rely on CreateWindow calls or Direct3DCreate9 calls whereas those for shape functions inherently will (like line.c) Thus, since I'm going to try to focus on d3dx9 stuff (hope code-freeze is over July 4th), it seems like it might be good to have a separate file. What is the argument for keeping them all in the mesh file besides that they are mesh creation functions? Thank you Misha
Re: [PATCH 2/7] d3dx9: Add IUnknown method calls to ID3DXMesh.
On 24 June 2010 05:18, Misha Koshelev misha680 at gmail.com wrote: +#if !defined(__cplusplus) || defined(CINTERFACE) +/*** IUnknown methods ***/ +#define ID3DXMesh_QueryInterface(p,a,b) (p)-lpVtbl-QueryInterface(p,a,b) +#define ID3DXMesh_AddRef(p)(p)-lpVtbl-AddRef(p) +#define ID3DXMesh_Release(p) (p)-lpVtbl-Release(p) +#else +/*** IUnknown methods ***/ +#define ID3DXMesh_QueryInterface(p,a,b)(p)-QueryInterface(a,b) +#define ID3DXMesh_AddRef(p)(p)-AddRef() +#define ID3DXMesh_Release(p) (p)-Release() +#endif + Which version of the DX SDK do these match? __ Ok, now here I just have to plead ignorance my apologies... If I do not declare these functions, how do I call the Release method of the appropriate interfaces? Specifically, I started looking at the test for line.c - I believe that if I create a mesh, I have to release it. I have largely been learning from this page: http://www.mvps.org/directx/articles/d3dxmesh.htm (which is DirectX 8) but it seems I have to somehow release the functions no? Also, I'm probably going to start with the D3DXCreateBox function, as I need to figure out exactly what's going on with the vertices before I delve into something as complicated as spheres ;) Thanks y'all :) Misha
Re: [PATCH 1/7] d3dx9: Shape functions in own file, add stub and basic tests for D3DXCreateSphere.
On 24 June 2010 05:18, Misha Koshelev misha680 at gmail.com wrote: Dan suggested tests ok during code freeze so blame Dan for my patches ;) Certainly will. wine-devel is an open mailing list, and posting is easy. You'll probably want to check with something like git shortlog -s -n if the advice you're getting is actually worth taking. The way I see it, you have more experience with getting patches accepted yourself. More to the point, if you look at http://source.winehq.org/patches/, you'll see 62909 is marked as Deferred, so resending in a slightly different form isn't going to help much. As for the patch itself, I'm not convinced there's value in having a separate file for Shape Drawing Functions, these are clearly mesh constructors. I thought the original patch was mostly ok in that regard, although there are (very) minor issues like using %d for unsigned arguments and using imo ugly typedefs like LPDIRECT3DDEVICE9 over simply IDirect3DDevice9 *. Oh and the LPDIRECT3DDEVICE9's are straight from line.c tests. But I will heed your advice on the %d's Misha
Re:
On 25 June 2010 18:07, Misha Koshelev misha...@gmail.com wrote: So here is why I thought maybe having a separate shape.c file might be good. I am very new to D3DX9 so please pardon my ignorance, but simply looking at SDK, I see: i) http://msdn.microsoft.com/en-us/library/bb172976%28v=VS.85%29.aspx Shape Drawing Functions are all defined in D3dx9shape.h whereas http://msdn.microsoft.com/en-us/library/bb172973%28v=VS.85%29.aspx Mesh Functions are all defined in D3dx9mesh.h This is not a reason to implement shape drawing functions in a separate file _per se_, but additionally: ii) all the tests in mesh.c do not rely on CreateWindow calls or Direct3DCreate9 calls whereas those for shape functions inherently will (like line.c) Thus, since I'm going to try to focus on d3dx9 stuff (hope code-freeze is over July 4th), it seems like it might be good to have a separate file. What is the argument for keeping them all in the mesh file besides that they are mesh creation functions? Essentially that there's no convincing reason not to. It's only a handful of functions, clearly related to the mesh functions, so you can't justify it with reasons like prohibitive source file size or being clearly distinct functionality. Also, Wine as a project has a preference of fewer large files over lots of small ones. You can make good arguments for that in terms of e.g. ease of editing and keeping a good overview of things, but if nothing else you can simply consider it project policy.
Re: [PATCH 1/7] d3dx9: Shape functions in own file, add stub and basic tests for D3DXCreateSphere.
On 25 June 2010 18:20, Misha Koshelev misha...@gmail.com wrote: regard, although there are (very) minor issues like using %d for unsigned arguments and using imo ugly typedefs like LPDIRECT3DDEVICE9 over simply IDirect3DDevice9 *. Oh and the LPDIRECT3DDEVICE9's are straight from line.c tests. But I will heed your advice on the %d's I wouldn't object to a patch based on either of those alone, but if you'll have to resend anyway I might as well point those out.
Re: [PATCH 2/7] d3dx9: Add IUnknown method calls to ID3DXMesh.
On 25 June 2010 18:14, Misha Koshelev misha...@gmail.com wrote: If I do not declare these functions, how do I call the Release method of the appropriate interfaces? Specifically, I started looking at the test for line.c - I believe that if I create a mesh, I have to release it. If it's just about releasing the interface, using the generic IUnknown_Release macro should always work. The larger issue though is that most (all?) of the d3dx9 interfaces don't have corresponding C macros. That means you'll have to call those functions explicitly through lpVtbl in C, but you'd have to do that when using the MS headers as well.
Re: [PATCH 1/7] d3dx9: Shape functions in own file, add stub and basic tests for D3DXCreateSphere.
On Fri, 2010-06-25 at 18:59 +0200, Henri Verbeet wrote: On 25 June 2010 18:20, Misha Koshelev misha...@gmail.com wrote: regard, although there are (very) minor issues like using %d for unsigned arguments and using imo ugly typedefs like LPDIRECT3DDEVICE9 over simply IDirect3DDevice9 *. Oh and the LPDIRECT3DDEVICE9's are straight from line.c tests. But I will heed your advice on the %d's I wouldn't object to a patch based on either of those alone, but if you'll have to resend anyway I might as well point those out. Very well then. Let's just leave the deferred patch as is if that's okay http://source.winehq.org/patches/data/62909 and I'll send out further patches post-code freeze heeding all of your advice. Thank you Misha
Re: Debian package backorder
Ben Klein wrote: Unless someone wants to donate an AM2/DDR2 motherboard to me, someone is going to have to take over the packaging of Debian Stable, Testing and Unstable packages. Sure. Send me a newegg link and an address. ~Nate
Re: Tests for msvcrt
On Thursday 24 June 2010 12:14:34 pm Piotr Caban wrote: On 06/24/10 10:49, Paul Chitescu wrote: Hi! What would be the best way of testing MSVCRT.DLL considering that many functions may or may be not present in the native version? There are already such tests in msvcrt. Take a look on e.g. dlls/msvcrt/tests/misc.c. It's working well on older systems. There are already tests of msvcr90. MsvcrXX specific tests should go there (unless the function is not present there). The problem is that these functions will be available: - on Wine in MSVCRT and MSVCRxx = 80 - on Windows XP only in MSVCRxx = 80 (if installed) - on Windows 7 in MSVCRT and MSVCRxx = 80 (if installed) - no idea about Vista and other intermediate versions, service packs, etc. What should the test do and where should it be located? In msvcrt/tests ? Or in msvcr90/tests ? Or create a msvcr80/tests ? Or...? Would it be acceptable to test the functions only if available in msvcrt.dll ? If the functions are not present should the code in msvcrt/tests attempt to load msvcr80 or msvcr90 or...? What do you think? Paul
structure has #pragma pack(8) in Windows SDK (AMD64) and #pragma pack(1) in wine headers
The struct in question is CSFV defined in shlobh.h. If I try to compile shell32_test for x64 using headers from windows 2008 SDK, I get assertion failure here: http://source.winehq.org/source/dlls/shell32/tests/generated.c?v=wine-1.2-rc5#L1395 Is it normal for wine to have different structure packing?
Re: structure has #pragma pack(8) in Windows SDK (AMD64) and #pragma pack(1) in wine headers
Ilya Basin basini...@gmail.com writes: The struct in question is CSFV defined in shlobh.h. If I try to compile shell32_test for x64 using headers from windows 2008 SDK, I get assertion failure here: http://source.winehq.org/source/dlls/shell32/tests/generated.c?v=wine-1.2-rc5#L1395 Is it normal for wine to have different structure packing? No, please send a patch. -- Alexandre Julliard julli...@winehq.org
automated stack dumps broken, just output winedbg usage message now?
Is anybody else seeing winedbg fail to generate stack dumps? I'm seeing wine: Unhandled page fault on read access to 0x at address 0xb736bd68 (thread 0009), starting debugger... Usage: winedbg [ [ --gdb ] [ prog-name [ prog-args ] | num | file.mdmp | --help ] on a lot of apps when they crash. Could be me, but I figured I'd ask. This is with wine-1.2-rc3.
Re: [PATCH 1/6] d3dx9: Add stub and basic test for D3DXCreateSphere.
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=2930 Your paranoid android. === WINEBUILD (build) === Make failed
Re: [PATCH 6/6] d3dx9: Test raw vertex data for D3DXCreateSphere.
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=2935 Your paranoid android. === WINEBUILD (build) === Make failed
Re: [PATCH 2/6] d3dx9: Add a few more tests for D3DXCreateSphere.
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=2931 Your paranoid android. === WINEBUILD (build) === Make failed
Re: [PATCH 4/6] d3dx9: Test number of vertices for D3DXCreateSphere.
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=2933 Your paranoid android. === WINEBUILD (build) === Make failed
Re: [PATCH 5/6] d3dx9: Add tests for D3DXCreateSphere vertex buffer description.
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=2934 Your paranoid android. === WINEBUILD (build) === Make failed
Re: [PATCH 3/6] d3dx9: Add framework for a more sophisticated D3DXCreateSphere test.
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=2932 Your paranoid android. === WINEBUILD (build) === Make failed
Re: How do you make x64 crosstests?
On Fri, Jun 25, 2010 at 2:49 AM, Ilya Basin basini...@gmail.com wrote: Should be install 64-bit mingw, compile wine in 64-bit mode, and run 'make crosstest'. Though I just tried this on Ubuntu Lucid, and it fails for me there (configure is looking for checking for x86_64-pc-mingw32-gcc... no checking for x86_64-w64-mingw32-gcc... no while on Ubuntu, it is: amd64-mingw32msvc-gcc however, it seems compiling with it is broken: aus...@midna:~/64-wine-git$ amd64-mingw32msvc-gcc foo.c /usr/lib/gcc/amd64-mingw32msvc/4.4.2/../../../../amd64-mingw32msvc/bin/ld: cannot find -lgcc collect2: ld returned 1 exit status perhaps someone else has tried and had better luck... -- -Austin
Re: Addition of En resources to non-En resources
Francois Gouget fgou...@free.fr wrote: [skipped] These were picked at random. Isn't it strange how all these translated controls have the same size as the English version despite widely different text content? There is nothing strange there, if the text still fits and doesn't get clipped out. So in fact all you get with the status-quo is few translations *AND* broken dialog layouts. Same position and size of the controls in different languages doesn't suddenly make the dialog layout broken. -- Dmitry.
