April 2008 - Wine-devel - list.winehq.org

Re: a proposed fix for bug 11690 concerning hhctrl.ocx
by Hin-Tak Leung 07 Apr '08

07 Apr '08

apologies - there was a typo in that patch - should be looking for "://" rather than "::/" . Otherwise my questions are the same. --- On Mon, 7/4/08, Hin-Tak Leung <htl10(a)users.sourceforge.net> wrote: > From: Hin-Tak Leung <htl10(a)users.sourceforge.net> > Subject: a proposed fix for bug 11690 concerning hhctrl.ocx > To: jacek(a)codeweavers.com, truiken(a)gmail.com > Cc: wine-devel(a)winehq.org > Date: Monday, 7 April, 2008, 7:02 PM > Hi Jacek and James - according to git, you two are the ones > last working on the part > of code which I have a possible fix for bug 11690 (see the > bug report for somebody > tested okay something like this), so I'd like to see > what you think of this patch, specially (and others can > chip in as well...) Here is what I think: > > NavigateToUrl() in hhctrl.ocx/help.c is only used by the > HH_HELP_CONTEXT case in HtmpHelpW() in hhctrl.ocx/hhctrl.c > - I think in some circumstances, it may return a full url, > but in the case of bug 11690, it returns a > "relative" one inside the same CHM, > so the code in NavigateToUrl() should drop through to look > up in chm. The top part of > NavigateToUrl() is really wrong because it assumes a > IWebbrowser_navigate would fail > on a relative url and drop through, but the way I see it, > Iwebbrower_navigate should return the status of whether > talking to IE/gecko is successful, not whether they gets > "404 not found". > > I have a few questions for you two: > 1) is there any known case where HH_HELP_CONTEXT returns a > fully formed URL? (i.e. if > this change is committed, it is going to break something > else?) > > 2) Since NavigateToUrl is only used once (and it needs to > drop through to NavigateToChm() in most cases, pending your > answer question 1), wouldn't it make sense > to just remove it? > > Thanks, > Hin-Tak > > > > ___________________________________________________________ > > Yahoo! For Good helps you make a difference > > http://uk.promotions.yahoo.com/forgood/ ___________________________________________________________ Yahoo! For Good helps you make a difference http://uk.promotions.yahoo.com/forgood/

1 0

Re: a proposed fix for bug 11690 concerning hhctrl.ocx
by Hin-Tak Leung 07 Apr '08

07 Apr '08

apologies - there was a typo in that patch - should be looking for "://" rather than "::/" . Otherwise my questions are the same. --- On Mon, 7/4/08, Hin-Tak Leung <htl10(a)users.sourceforge.net> wrote: > From: Hin-Tak Leung <htl10(a)users.sourceforge.net> > Subject: a proposed fix for bug 11690 concerning hhctrl.ocx > To: jacek(a)codeweavers.com, truiken(a)gmail.com > Cc: wine-devel(a)winehq.org > Date: Monday, 7 April, 2008, 7:02 PM > Hi Jacek and James - according to git, you two are the ones > last working on the part > of code which I have a possible fix for bug 11690 (see the > bug report for somebody > tested okay something like this), so I'd like to see > what you think of this patch, specially (and others can > chip in as well...) Here is what I think: > > NavigateToUrl() in hhctrl.ocx/help.c is only used by the > HH_HELP_CONTEXT case in HtmpHelpW() in hhctrl.ocx/hhctrl.c > - I think in some circumstances, it may return a full url, > but in the case of bug 11690, it returns a > "relative" one inside the same CHM, > so the code in NavigateToUrl() should drop through to look > up in chm. The top part of > NavigateToUrl() is really wrong because it assumes a > IWebbrowser_navigate would fail > on a relative url and drop through, but the way I see it, > Iwebbrower_navigate should return the status of whether > talking to IE/gecko is successful, not whether they gets > "404 not found". > > I have a few questions for you two: > 1) is there any known case where HH_HELP_CONTEXT returns a > fully formed URL? (i.e. if > this change is committed, it is going to break something > else?) > > 2) Since NavigateToUrl is only used once (and it needs to > drop through to NavigateToChm() in most cases, pending your > answer question 1), wouldn't it make sense > to just remove it? > > Thanks, > Hin-Tak > > > > ___________________________________________________________ > > Yahoo! For Good helps you make a difference > > http://uk.promotions.yahoo.com/forgood/ ___________________________________________________________ Yahoo! For Good helps you make a difference http://uk.promotions.yahoo.com/forgood/

1 0

a proposed fix for bug 11690 concerning hhctrl.ocx
by Hin-Tak Leung 07 Apr '08

07 Apr '08

Hi Jacek and James - according to git, you two are the ones last working on the part of code which I have a possible fix for bug 11690 (see the bug report for somebody tested okay something like this), so I'd like to see what you think of this patch, specially (and others can chip in as well...) Here is what I think: NavigateToUrl() in hhctrl.ocx/help.c is only used by the HH_HELP_CONTEXT case in HtmpHelpW() in hhctrl.ocx/hhctrl.c - I think in some circumstances, it may return a full url, but in the case of bug 11690, it returns a "relative" one inside the same CHM, so the code in NavigateToUrl() should drop through to look up in chm. The top part of NavigateToUrl() is really wrong because it assumes a IWebbrowser_navigate would fail on a relative url and drop through, but the way I see it, Iwebbrower_navigate should return the status of whether talking to IE/gecko is successful, not whether they gets "404 not found". I have a few questions for you two: 1) is there any known case where HH_HELP_CONTEXT returns a fully formed URL? (i.e. if this change is committed, it is going to break something else?) 2) Since NavigateToUrl is only used once (and it needs to drop through to NavigateToChm() in most cases, pending your answer question 1), wouldn't it make sense to just remove it? Thanks, Hin-Tak ___________________________________________________________ Yahoo! For Good helps you make a difference http://uk.promotions.yahoo.com/forgood/

1 0

Re: d3dx8: D3DXCreateMatrixStack
by tony.wasserka＠freenet.de 07 Apr '08

07 Apr '08

> Well no, you keep track of the array size and grow it when it's too > small when doing a push. i.e. HeapReAlloc http://msdn2.microsoft.com/en-us/library/aa366704(VS.85).aspx You may optimize that if you allocate space for 2 or so matrices at once, as it decreases the number of HeapReAlloc calls. However, for a basic implementation this isn't relevant, yet.

1 0

d3dx8: D3DXCreateMatrix
by David Adam 07 Apr '08

07 Apr '08

I agree that the good implementation is with array. The bad thing is that we must bound the size of the array ourself. I think that a size of 64 or 128 for the array is enough, right? The advantage of a list is that we do not need to take care about the size. David

2 1

Re: d3dx8 :Fix D3DXCreateMatrixStack
by tony.wasserka＠freenet.de 07 Apr '08

07 Apr '08

> The commit comment for this patch is rather non-descriptive... what is > this supposed to fix? > An array based stack seems more appropriate than a list based one for > ID3DXMATRIXStack, why change that? I think so, too (after taking a closer look at the interface documentation at msdn). Though it ain't really a good argument, but msdn gives a code example where they show that they use arrays internally: http://msdn2.microsoft.com/en-us/library/bb174057(VS.85).aspx m_pstack[m_currentPos] = m_pstack[m_currentPos] * (*pMat); Unbegrenzter Speicher, Top-Spamschutz, 120 SMS und eigene E-MailDomain inkl. http://office.freenet.de/dienste/emailoffice/produktuebersicht/power/mail/i…

1 0

Re: d3dx8 :Fix D3DXCreateMatrixStack
by H. Verbeet 07 Apr '08

07 Apr '08

On 07/04/2008, David Adam <david.adam.cnrs(a)gmail.com> wrote: > The commit comment for this patch is rather non-descriptive... what is this supposed to fix? An array based stack seems more appropriate than a list based one for ID3DXMATRIXStack, why change that?

1 0

Fwd: [ubuntu-x] Future of digitizing tablet support in xorg?
by Dan Kegel 07 Apr '08

07 Apr '08

I ran one of our X issues by Bryce Harrington. Here's his reply: ---------- Forwarded message ---------- From: Bryce Harrington <bryce(a)canonical.com> Date: Sun, Apr 6, 2008 at 9:46 PM Subject: Re: [ubuntu-x] Future of digitizing tablet support in xorg? To: Dan Kegel <dank(a)kegel.com> Cc: ubuntu-x(a)lists.ubuntu.com On Sun, Apr 06, 2008 at 11:05:30AM -0700, Dan Kegel wrote: > At the moment, users of digitizing tablet > often have to compile x drivers themselves (!), e.g. > https://help.ubuntu.com/community/Wacom > https://help.ubuntu.com/community/TabletSetupWizardpen > which seems rather a throwback to the 90's. > And even if they don't have to compile the drivers > themselves, it seems users still have to edit xorg.conf. > > What are the prospects for moving from the current > situation to plug'n'play nirvana? > > I ask because Wine is getting good enough that > tablet issues like this are starting to become limiting > factors for Photoshop use in Ubuntu. For hardy we experimented with the new input hotplugging in xserver 1.4 (Timo in particular did extensive testing of it). Unfortunately, the new HAL approach with fdi files was proving to be even more complicated to configure than editing xorg.conf. Timo's testing also was turning up bugs a bit too readily. So we decided to hold off on it for now, and stick with the devil we know. The main deficiency that needs to be addressed is input configuration. The input hotplugging seems to work fine with default parameters, but as soon as a user wishes to set things to non-default values things get complicated. I think before we can really seriously consider moving to it, we need to have some configuration tools. So, I would like to see as a start, at least some sort of command line tool - the input device equivalent of 'xrandr'. GUI tools would be nice but can come in time. In addition, as I understand it, each of the input devices need to be updated to take advantage of input hotplug - much as each video driver has had to be updated to use Xrandr. So even though some drivers have transitioned, it may behoove us to wait until a larger proportion are updated. Bryce

1 0

Re: WINEDLLPATH, ddiwrapper, msvcrt40 (Re: wine based win32 printer drivers)
by Ulrich Hecht 07 Apr '08

07 Apr '08

Hi! On Saturday 05 April 2008, Hin-Tak Leung wrote: > 2) (to uli and Till) - do you mind if I put a mod/update of ddiwrapper > out publicly, or uli can release a new one that works with current > wine? Hand it over, and I'll put it on the FTP server and update our package. CU Uli -- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)

1 0

Re: wined3d: Check for NULL vertex declarations
by H. Verbeet 07 Apr '08

07 Apr '08

On 07/04/2008, Chris Robinson <chris.kcat(a)gmail.com> wrote: > + if(!This->stateBlock->vertexDecl) { > + WARN("(%p) : Called without a valid vertex buffer set\n", This); That WARN is misleading.

2 1