2009/12/23 Paul Chitescu <paulc(a)voip.null.ro>:
> Changelog:
> qedit: Implement partially the Sample Grabber filter
>
> The IMediaPosition, IMediaSeeking and IQualityControl interfaces are currently
> not implemented at all. No programs I've tested tried to query them though.
>
> Buffering of samples is also not implemented yet, applications usually install
> an ISampleGrabberCB callback.
Thread-safety is non-existent in your newly written code. DirectShow
uses multiple threads so I would say thread-safety is a requirement,
not a nice-to-have.
--
Rob Shearman
On Tue, 2009-12-22 at 15:36 -0600, Austin English wrote:
> Sure. FWIW, I'm working on some AutoHotKey/Appinstall tests for cmd,
> but it's a bit difficult, since the only way to capture the stdout is
> to pipe it to a file first.
Hey, i think a test suite for cmd is an excellent idea, and is surely
what is needed to lift the quality of this module. However, i think
using AutoHotKey in an external script might not be the optimal
solution. Why not place the test in the source tree along with all of
the other tests. Of course this requires the tests to be run from a C
based file and not a AHK file, as i doubt that AJ wants AHK in git. It
would however mean that one could add tests for all of the other command
line utility programs much easier (not possible now at all). I don't
really see "cmd" as an external tool but and integrated part of the Wine
product. Therefore i think these tests belong in the main git tree.
In any case, tests are better than no tests!
(just to state the obvious :-))
/pedro
2009/12/22 Stefan Dösinger <stefan(a)codeweavers.com>:
> + conv = ((FVF & WINED3DFVF_POSITION_MASK) == WINED3DFVF_XYZRHW ) || (FVF & (WINED3DFVF_DIFFUSE | WINED3DFVF_SPECULAR));
> hr = buffer_init(object, This, Size, Usage, WINED3DFMT_VERTEXDATA,
> - Pool, GL_ARRAY_BUFFER_ARB, NULL, parent, parent_ops);
> + Pool, GL_ARRAY_BUFFER_ARB, NULL, parent, parent_ops, conv);
This looks questionable, we use the FVF to determine that the buffer
is going to need conversion, but don't pass that FVF to the buffer
itself? Shouldn't this just use the existing code in buffer.c to
determine when we need conversion in the first place, and just drop
the VBO when the overhead becomes too large? Note that if we have
EXT_vertex_array_bgra we don't need conversion for the color data in
the first place.
Hi Jeremy
What is your reason for your work in winspool.drv?
What are your plans?
Even if the Patchset changes some things, it's not the correct location to do that.
winspool.drv must not do anything with the registry or the driver files.
winspool.drv must not use cups at all
wineps.drv must not use cups at all
That all belong to a print provider, together with a print monitor.
To make our live easy, the printprovider and printmonitor for CUPS and LPR will be integrated into localspl.dll
(windows is using seperate provider/monitor: See inetpp.dll and lprmon.dll with friends)
I have a Patch here for moving AddPrinter to localspl, that address most of your changes,
but a small peace of code is only in my test app and not in the Patch yet (get default DEVMODEW from the Driver)
An important issue is, that we store DEVMODEA in the registry.
Code is there to handle that, bu it failed on julliards machine.
My localspl.dll has a cups.c, but that need more work(i can't continue before mid januar).
And IMHO, using wine_get_unix_file_name in High-level dlls is wrong by design.
W2k pro and XP pro have driver directories only for supported environments.
(Servers are different)
When you think, that you need the driver directories, they can be created with wine.inf
Please avoid ANSI strings in new code. (strdupWtoA should go away)
--
By by ... Detlef
___________________________________________________________
Preisknaller: WEB.DE DSL Flatrate für nur 16,99 Euro/mtl.!
http://produkte.web.de/go/02/
Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes:
> Changelog:
> gdiplus: Add stub for GdipIsVisibleClipEmpty
You might as well implement it right away, it should be fairly trivial.
--
Alexandre Julliard
julliard(a)winehq.org
Andrew Nguyen <arethusa26(a)gmail.com> writes:
> @@ -453,7 +453,6 @@ HKLM,Software\Microsoft\DirectPlay\Service Providers\Serial Connection For Direc
> HKLM,Software\Microsoft\DirectPlay\Service Providers\Serial Connection For DirectPlay,"Path",,"dpmodemx.dll"
>
> [Environment]
> -HKLM,System\CurrentControlSet\Control\Session Manager\Environment,"APPDATA",,"%16410%"
> HKLM,System\CurrentControlSet\Control\Session Manager\Environment,"ComSpec",0x00020000,"%11%\cmd.exe"
> HKLM,System\CurrentControlSet\Control\Session Manager\Environment,"LOCALAPPDATA",,"%16412%"
> HKLM,System\CurrentControlSet\Control\Session Manager\Environment,"PATH",0x00020002,"%11%;%10%;%11%\wbem"
Looks good, but you should do the same thing for LOCALAPPDATA.
--
Alexandre Julliard
julliard(a)winehq.org
On 12/22/2009 10:43 PM, Nikolay Sivov wrote:
> Don't update buddy text if it's the same.
>
> There's at least one application that depends on this behavior:
> http://bugs.winehq.org/show_bug.cgi?id=18574
>
> This bug is closed cause crash no longer occurs in 1.1.35 due
> a regression it contains, the real problem is fixed by this patch.
Hi Nikolay,
This one introduces a test failure on NT4 but I guess it's due to
comctl32 4.72 and not the OS.
NT4/4.72 sends a WM_SETTEXT instead of WM_GETTEXT (just tested, it's the
only message).
Could you have a look? The NT4 boxes at winetestbot.geldorp.nl have this
issue.
--
Cheers,
Paul.
"Steven Edwards" <winehacker(a)gmail.com> wrote:
> - Removed the LoadLibrary calls in favor of GetModuleHandle as suggested
> by Paul Vriens
> - Match the bad formating of the rest of the file
Avoiding a needless renaming of ID_EXECUTE to ID_RUN would make the patch
much smaller. Also avoiding useless typedef, making WineFile_OnRun() static,
using correct casts, avoiding hungarian notation and magic flags would make
the patch slightly cleaner.
--
Dmitry.