March 2004 - Wine-Devel - list.winehq.org

Re: [LostWages] make winehq.org HTML 4.01 Transitional + XHTML 1.0 Transitional Valid

by Brian Vincent

> Dimi, I still don't get you, what you are saying is: > changing class=todo to class=done is considerably easier then > changing class="todo" to class="done" Rule #1: whoever is willing to do the thankless job of maintaining pages on the web site gets to tell anyone else how they'd like the formatting to be. Since this issue has directly affected me in the past I will point out a real argument for making this stuff compliant: If I copy and paste the HTML into a WWN it would be nice if I didn't have to do a ton of markup to make it well-formed. In fact, I almost never reference anything on WineHQ for that very reason. For example, in issue #143 I went through the markup for the original to-do list and corrected it (which is interesting to look at now, btw). Likewise, it's simple to copy things into the documentation. A good example of which is: http://www.winehq.com/site/status_options Parts of which may end up in the User Guide. But that's just me, and I ain't the one maintaining it. So if Dimi doesn't want it then I guess the best thing to do would be to resubmit with those parts left out. -brian

March 30, 2004

Re: systray in desktop mode [unified resend]

by Alexandre Julliard

Mike Hearn <mike(a)navi.cx> writes: > This is still an unanswered question. I wanted to special-case > FindWindow so we get efficiency but I think Alexandre didn't like that, > so I guess we have to always start it. Alexandre? We need to start it some way, exactly how is not defined yet. We can think about that once we have a working implementation... -- Alexandre Julliard julliard(a)winehq.org

March 30, 2004

Re: [LostWages] make winehq.org HTML 4.01 Transitional + XHTML 1.0 Transitional Valid

by hatky

On Tuesday 30 March 2004 18:26, Dimitrie O. Paun wrote: > Jeremy, > > Please don't apply this patch to the pages I maintain: > TODO, Fun Projects, Janitorial, Winelib, Status | Options, Status | > Porting If you have to say it officially I will too: 1. The only change in your pages are class=todo to class="todo" and with other class name (now you can see it for your self) 2. I didn't lay ground rules that any thing written that violates these rules will not be accepted or anything, write what you know, and if I will be bored again I will patch a fix.... > > As I've tried to explain in the past, these changes are totally unnecessary > for manually maintained pages: it makes it harder to maintain, for the > benefit of making it easier for the machine to parse. Bad tradeoff, > especially given that we maintain these pages daily, and the machine has > absolutely no problem parsing them. It changes nothing for the machine, my reasons are: 1, It's good practice 2. It's future compatible with XHTML forcing this way, yet HTML allows and RECEMENDS this way 3. Ground rules for web programming fallow the spec as close as you can and be prepared to accept as many misstakes as you can, this patch fills part one Dimi, I still don't get you, what you are saying is: changing class=todo to class=done is considerably easier then changing class="todo" to class="done" If it only look the same to me then I am very sorry, I must have missed something........ -- Hatky, Worshiper of wine (http://www.winehq.org/) Impossible is only an opinion.

March 30, 2004

Re: problem w/winebuild and '@' in names

by Mike McCormack

Hi Jon, Another way to get around this problem is to use: stdcall func(a)blah@xxx(long long) func_blah because the code only stips off one @ sign and what follows it... I've got no idea if that's the Right Way or not. Mike Jon Griffiths wrote: > Hi, > > winebuild doesn't support export names with an '@' correctly. When > parsing the spec file, the @X is stripped. This causes names to be > incorrectly listed as duplicates. > > I'm hitting this with mapi32.dll. Outlook 97 imports using get > procaddress on the name including the '@', and some exports are given > both with and without the '@' decoration. > > I'm working around this for mapi32 by commenting out > remove_stdcall_decoration( odp->name ); > at line 463 of parser.c. > > Is this a known problem, and is that the right solution? > > Cheers, > Jon

March 30, 2004

Re: problem w/winebuild and '@' in names

by Jon Griffiths

Hi Mike, Hmm, seems a bit hackish, much like my current solution. I'm a while from submitting the mapi32 stuff anyway, so I can wait for a proper resolution. IMO we need to support the mangled exports, ms tools obviously do. I seem to recall this used to work, was it changed for cygwin maybe? Cheers, Jon --- Mike McCormack <mike(a)codeweavers.com> wrote: > > Hi Jon, > > Another way to get around this problem is to use: > > stdcall func(a)blah@xxx(long long) func_blah > > because the code only stips off one @ sign and what follows it... > I've got no idea if that's the Right Way or not. > > Mike ===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html

March 30, 2004

Re: [LostWages] make winehq.org HTML 4.01 Transitional + XHTML 1.0 Transitional Valid

by Dimitrie O. Paun

On Tue, 30 Mar 2004, hatky wrote: > Yes, this time with the patch... > > Change log: > Ofir Petruska <hatky(a)users.sf.net> > Validate the site as HTML 4.01 Transitional + XHTML 1.0 Transitional Valid > (still declaring declaring HTML 4.01 Transitional) > * Case fixes (all html tags should be lower case) > * Quote all attributes > * End empty tags as " />" Jeremy, Please don't apply this patch to the pages I maintain: TODO, Fun Projects, Janitorial, Winelib, Status | Options, Status | Porting As I've tried to explain in the past, these changes are totally unnecessary for manually maintained pages: it makes it harder to maintain, for the benefit of making it easier for the machine to parse. Bad tradeoff, especially given that we maintain these pages daily, and the machine has absolutely no problem parsing them. Thanks. -- Dimi.

March 30, 2004

Fwd: Re: Source code visualization tools?

by Blake Leverett

Joel Konkle-Parker wrote: > Is there such a thing as a source code visualization tool that makes a > "map" of a program's source? Kind of like: > > main() > | > | > function1() > /\ > / \ > func2() func3() > | > | > func4() > > I'm basically looking for something that will help me "see" how a > program is laid out so that I can start working on it. > > Thanks in advance. > > I was looking for a similar thing a while back. One great tool for navigating the wine source is the etags program. In the wine source directory, type 'make etags'. This makes a file called TAGS. Then, start emacs, and type alt-x visit-tags-table, and load the tags file. You can navigate the source by function. See the tags manpage and the emacs manpage for the tags section for details. Blake `--------------- Forwarded message (end)

March 30, 2004

Re: i810 audio fixes 1/2

by Mike Hearn

On Mon, 29 Mar 2004 18:56:46 -0500, Robert Reif wrote: > If usability rather than performance (as in multiple applications) is > important, then higher level drivers like jack or arts should be used. Apart from JACK which is used in pro-audio situations, sound servers are probably going to be phased out on Linux within the next 12-24 months as people migrate to the 2.6 kernel with ALSA and the dmix/asym plugins. So, I still think the best way to solve this problem is simply to have a winecfg check box that says "Use hardware accelerated audio" which people who desire better performance can tick: they incur extra CPU overhead and the benefit is that they can use all their apps together. For many uses of Wine audio support is simply required for the bling!bling! sounds programs sometimes make. This is probably easier on the user than asking them to change their backend Wine audio driver. thanks -mike

March 30, 2004

Re: systray in desktop mode [unified resend]

by Mike Hearn

On Tue, 2004-03-30 at 06:08, Martin Fuchs wrote: > If you want to do exactly what native shell32 does, you can just drop > all the old (non-desktop mode) code and replace it with what my > patch wanted to do in desktop mode. Yes, I realise that. I guess you checked that these are the same messages native shell32.dll uses? > Your new implementation will also create such a message receiver > window. So you want to create your tray window at any startup of > Wine regardless if it will be used or not? May be a bit overkill, but > it would work. This is still an unanswered question. I wanted to special-case FindWindow so we get efficiency but I think Alexandre didn't like that, so I guess we have to always start it. Alexandre? > In the result it will look like this: > If there is no explorer application, the icons will show up in the > Linux systray. If there is an Explorer running, they will show up > _both_ in Linux' and Explorer's systray. That sounds OK thanks -mike

March 30, 2004

Re: Handling dialogs created without using templates

by Dmitry Timoshkov

"Santosh Siddheshwar" <santosh.s(a)sonata-software.com> wrote: > Yes attached is a sample which is pretty similar to what I described > below. Thanks. Now I see where the problem is. We have to hook dialog creation code into common window creation code, something similar to what I've done recently for MDI. Alexandre, are my thoughts correct? -- Dmitry.

March 30, 2004