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

Re: COMCTL32: Add comctl32 to the list of always builtin dlls.

by Mike McCormack

Vitaly Lipatov wrote: > I do not agree with this patch. There is broken code in WINE's comctl32 > realization (in treeview/listview code) and we need overrides builtin dll by > native for get differences... Sure. You can still do that using WINEDLLOVERRIDES=comctl32=n, so it doesn't impede testing. Mike

March 30, 2006

Re: Why winetools is utterly useless, once and for all.

by Dominic Wise

On Mon, 2006-03-27 at 21:32 -0500, Segin wrote: > There is one reason, inarguable (if you reply to this you have a IQ > of > 0) as to why WineTools is useless: Most of the WineTools 'magic' is > in > it's ~/.wine/config file, which Wine no longer uses/acknoleges, > thefore, > WineTools is utterly useless and has no point in existing AT ALL, > PERIOD. Thought it might be interesting to refer back to the email that kicked all of this off and try to look at it in detail. > There is one reason, inarguable Anything is arguable, if one has arguments that can be backed up with evidence. > (if you reply to this you have a IQ of 0) Everyone has an IQ of more than 0. If they didn't, it is unlikely they would be able to read and so would not be in a position to respond. I also believe that anyone who reads this list has demonstrated a remarkable degree of intelligence in trying to move as far away from Windows as possible. The inference of this statement seems to be 'I am right because I am. I deny you the right to disagree - if you do I have already marked you out as an imbecile and you are not worthy of any consideration' - sounds rather fascist to me. > as to why WineTools is useless. I have used Winetools when necessary, when there was no other easily available option. IE is required for me to use online banking. I have complained to my bank, and asked them to support FireFox and they have declined. Winetools helped me achieve what I needed. For my specific needs, winetools was useful. > Most of the WineTools 'magic' Implication by use of quotation marks - winetools claims to be magic. It does not, as far as I know. > is in it's ~/.wine/config file, which Wine no longer uses/acknoleges, Ignoring the poor spelling and concentrating on the details, I have used versions of winetools that supported the config file, and more recently, versions that support the newer registry configuration. Given my understanding of current wine configuration I think the statement may be misleading. If I am wrong, I am happy to be corrected, preferably in a private email. >WineTools is utterly useless and has no point in existing AT ALL, >PERIOD. I have already described at least one reason for it to exist. Shouting isn't necessary, but if it makes segin feel better, that's entirely up to him. The point of this email is not to argue as to whether winetools is good for Wine or not - I can see both sides of the argument. Neither do I believe that any form of banning is necessary. I'm opposed to censorship generally, and given that no individual attack was made such sanctions could be counterproductive, given that segin has offered to submit code to wine in the future. All I can suggest is that when individuals have an opinion they believe strongly in, perhaps it might be a good idea to read though any open message they send before hitting 'Send' to see if it is readable and stands up to rational criticism. I have the greatest of respect for the entire wine community (no exceptions) and know that with rational debate and argument wine will be a huge (maybe the biggest) factor in ending the Windows monopoly.

March 30, 2006

Re: Improper message recursion revealed by recent desktop window changes

by Troy Rollo

On Friday 31 March 2006 02:41, Alexandre Julliard wrote: > I committed a few fixes that should help, please give it a try. The problem is fixed (so the app now works) although I am still getting the pack_message FIXMEs - it is possible though that this is a different problem that was masked by the earlier one. I will investigate further. -- Troy Rollo - wine(a)troy.rollo.name

March 30, 2006

Re: [WIDL] Implement support for unique strings

by Robert Shearman

Eric Kohl wrote: > case PASS_OUT: >+ if (in_attr && has_size && pointer_type == RPC_FC_UP && phase == PHASE_FREE) >+ break; > if (!out_attr) > continue; > break; > > I don't think this is correct. Firstly, it should continue, not break. Secondly, I think it only doesn't need to free the string if it has a size. I'm pretty sure it shouldn't depend on being a unique string. -- Rob Shearman

March 30, 2006

Re: Direct3D, the kernel and ReactOS

by Tim Schmidt

Sounds like a good project to hack on occasionally while putting the majority of effort into improving the current implementation. In other words, some effort is warranted because of the benefits of sharing code, however, wine can always transition to the new layout after it has a complete and (mostly) correct DirectX implementation. There's no reason the GDI and win32k.sys couldn't be going into the wine tree at the same time as improvements to the current system. --tim

March 30, 2006

Re: [RESEND][x11drv] cleanup: Move x11drv escape codes to one common header file.

by Alexandre Julliard

Tomas Carnecky <tom(a)dbservice.com> writes: > This patch doesn't change any logic or C sourcecode, it only moves the > X11DRV escape code definition to one common header file. Currently the > definitions are spread over several C source files, and even there the > definitions differ from file to file. I don't see anything wrong with > this patch unless you *want* to have it difficult to maintain the code. Actually, that's more or less what we want. That sort of inter-dll dependencies should be strongly discouraged, and we don't want to add more of it than strictly necessary; as far as possible we also don't want dlls to depend on private headers, so copying a few things across is the preferred approach. If it becomes a problem it means something is wrong with our implementation. -- Alexandre Julliard julliard(a)winehq.org

March 30, 2006

Need Help for IniFileMapping

by Detlef Riekenberg

Hi all. I need your Help to see, how IniFileMapping works on different NT-Versions. An updated kernel32_crosstest.exe, that prints a lot of informations and a detailed description is here: http://bugs.winehq.org/show_bug.cgi?id=4096 Thanks for your Help (IniFile is the redirection from "*.ini" - Files to the Registry, by GetPrivateProfileString() and Friends.) -- By By ... ... Detlef

March 30, 2006

Re: COMCTL32: Add comctl32 to the list of always builtin dlls.

by Vitaly Lipatov

I do not agree with this patch. There is broken code in WINE's comctl32 realization (in treeview/listview code) and we need overrides builtin dll by native for get differences... В сообщении от 30 марта 2006 07:56 Mike McCormack написал(a): > --- > > dlls/ntdll/loadorder.c | 1 + > 1 files changed, 1 insertions(+), 0 deletions(-) -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

March 30, 2006

Re: [Bug 1181] Keyboard translation broken: uses raw keycodes

by Peter Åstrand

On Thu, 30 Mar 2006, Wine Bugs wrote: > http://bugs.winehq.org/show_bug.cgi?id=1181 > > ------- Additional Comments From Speeddymon(a)gmail.com 2006-30-03 10:26 ------- > Peter, I'm not sure if you ever did subscribe to wine-devel, but you did mention > that wine could possibly reuse parts of your keysym implementation. Could you > email the list (even if you dont scubscribe) and let them know about this bug, > and see if anyone is willing to take a look at it. Just make sure you let them > know you aren't subscribed, if you aren't, and to CC you on replies. Hi, now you know about this bug. As the comment says, it might be possible to reuse some parts from the rdesktop implementation. I'm not saying that it will be easy, though. To be honest, I think bug 4923, and many others, are more important. Instead of fixing Wine, it might be possible to enhance Xvnc so that it can "emulate" a physical Xserver with a certain physical keyboard. Regards, -- Peter Åstrand ThinLinc Chief Developer Cendio http://www.cendio.se Teknikringen 3 583 30 Linköping Phone: +46-13-21 46 00

March 30, 2006

Re: Improper message recursion revealed by recent desktop window changes

by Alexandre Julliard

Troy Rollo <wine(a)troy.rollo.name> writes: > The brute-force approach of changing this to the following makes the > application work, but gives rise to some pack_message FIXMEs (for WM_NCPAINT > and WM_ERASEBKGND), and since this is an extremely sensitive piece of code to > change I thought it best left to people with more familiarity with it. I committed a few fixes that should help, please give it a try. -- Alexandre Julliard julliard(a)winehq.org

March 30, 2006

Re: Direct3D, the kernel and ReactOS

by Christoph Frick

On Thu, Mar 30, 2006 at 08:29:03AM -0500, Kuba Ober wrote: > Technically sufficient, maybe, but it might be actually illegal to install > Direct X on anything non-windows. Might be or is? Or will be like dcom? At least with dcom ms made the point clear. they just dont provide it beside the os. but i can not remember a single game in my collection, that does came with the dx-package needed to run it (i hardly remember anything that came with dcom98.exe). so does anybody knows the actual license or is there anything known what ms has in mind in the near future? > I bet there are non-gaming 3D applications that use it. CAD systems > come to mind. I think that for example Solid Edge uses Direct X (no, > didn't try to get it running under wine yet). yeah i am sure there are lots of non-game applications that utilize directx - dsound for sound apps, d3d for cad, office, 3d, ... and so on. all in all i know close to nothing what goes on the various dlls - but from a point of view like this it seems to be a lot of work to redo the work of others if there is no real need for it, like e.g. accessing hardware or operating system stuff. license issues aside i would only a consider a massive performance gain something that is worth it (and there still remains the question, why is that original dll so much slower with the underlying framework then). and of course its a lot easier to implement something that is *cough* well documented than something that is totally unknown to mankind. -- cu

March 30, 2006

Re: [OT] Re: Why winetools is utterly useless, once and for all.

by Tom Spear

On 3/29/06, Segin <segin2005(a)gmail.com> wrote: > > Saulius Krasuckas wrote: > > * On Tue, 28 Mar 2006, Karl Lattimer wrote: > > And also, accusing people of having an IQ of 0 for replying to a flame > isn't in the slightest constructive, > > Hardly. I have actually done something good. I got people to addresses the > Winetools problem a bit early. Sure, it would have gotten adressed anyways, > but only after enough complains come rolling in, months or years from now. > When I sent the flame, i had a purpose, a plan, and a hoped outcome. The end > result was nothing but good, so why shun me? I was just getting a matter > addressed before we have no choice but to address it. We can't just put it > off forever, you know. > It was already being addressed in the wine tools -> wine doors thread. So your flame (more like attack) did nothing good at all that wasnt already being done. Next time you have something that you want done (or addressed) just bring it up in a new thread, and dont be so rude about it. You will find a much more positive result (as opposed to 3 threads all going on about how bad of you it was to say what you said to the doc in private). I haven't written any patches, namely because my eariler code changes i find > cause signal 11. Recently I am working on something that will be offloaded > months from now (if i dont find it to be too fustrating) as a huge diff, so > keep your eyes peeled. If it doesn't work on either of my systems, it's > broken, and sending a diff is a waste of everybody's time. > I wouldn't do it in a huge diff. Break it up, because I have noticed that AJ usually wont commit huge diffs as is. Tom

March 30, 2006

Re: OT: General behaviour of the community (from 'Why winetools is utterly useless, once and for all')

by Tom Spear

On 3/29/06, Chris Morgan <chmorgan(a)gmail.com> wrote: > > How do you propose we prevent people from emailing people that post to > wine-devel? How do we choose who gets to email people directly and > who doesn't? How do we filter the contents of their email? > > Segin doesn't speak for the entire community and he isn't a lead on > the project. If that were the case this would be a more serious > matter. If people quit because of him then what are we to do? Given > the lack of relationship between wine and Segin they might as well > have quit wine development because of some Nigerian money transfer > email or other spam. > > My point is that the solution isn't trying to enforce censorship where > you simply cannot and where it doesn't impact the community. As long > as he doesn't abuse his list membership we have no reason to become > involved in this issue. You won't find me supporting any kind of > restrictions on what he says or which mailing lists he can belong to > at this point in time. > > Chris > Ok, but here is a point for you to chew on. Say that I go on a business trip for my company, and that while on this trip, I meet with some clients, and we go out for a business dinner. A few days later, while still out of town, I run into those clients again, and we all decide to go to a billiard. While at said billiard we all start drinking. No problems there. But if I continue drinking, eventually I am going to get drunk, and need assistance getting back to my hotel room. Mind you I am on a business trip and with some clients, but I am not at a business meeting. Even though I am (at the time) not representing the company, it still looks bad for them that an employee would do that in front of the client. The same principle applies here. It looks bad on the wine project as a whole that someone who participates in the devel list would email someone (even off list) and say the things that were said. Ordinarily I am against censorship myself, but I do believe in moderation, and I believe that people should be held accountable for their actions even if they are speaking only for themself, if it makes other people or things look bad. To answer your question, there isnt really a way, and I wasnt trying to say that we should prevent him from emailing others directly, or filtering his emails, I was saying that a lot of the things he does for the project should be restricted. AFAICT he has some high level permissions on bugzilla, and the appdb. Maybe those could (should?) be suspended temporarily, I dunno, I will leave it up to the big wigs here to decide if he should be punished in any way, and if so, what that punishment should be. As I said though, it is his opinion, and he is entitled to that opinion (at least in the US), but I think he should have kept it to himself, or at least not used such strong wording like "****ing dumb***"....

March 30, 2006

Re: Direct3D, the kernel and ReactOS

by Kuba Ober

On Thursday 30 March 2006 06:51, Christoph Frick wrote: > On Wed, Mar 29, 2006 at 11:12:06PM +0200, Stefan Dösinger wrote: > > My long term suggestion is to move the Direct3D->OpenGL translation > > code from WineD3D to gdi and a win32k sys, and write ddraw.dll, > > d3d8.dll and d3d9.dll to use that interface. The user mode dlls can be > > shared with Reactos, and from a technical point of view, even > > Microsoft's DirectX dlls can be used on Wine(including the hardware > > emulation layer). > > first of all excuse my ignorance of the d3d interface and so on - but > this sounds to me like wine should not deal with the userland dlls at > all then? once all the hardware is handled in the kernel parts what is > the gain in having our own implementations? installing dx with the games > should be sufficient then? Technically sufficient, maybe, but it might be actually illegal to install Direct X on anything non-windows. Of course the blame is shifted to the user, but if one thinks about corporate wine deployments, they wouldn't want to do illegal things. They might as well deploy pirated Windows, you know. And mind you, Direct X is not for games only. I bet there are non-gaming 3D applications that use it. CAD systems come to mind. I think that for example Solid Edge uses Direct X (no, didn't try to get it running under wine yet). Cheers, Kuba

March 30, 2006

Re: advpack: Forward ExecuteCabA to its unicode counterpart

by Robert Shearman

James Hawkins wrote: >@@ -86,6 +87,43 @@ HRESULT WINAPI DoInfInstall(const SETUPC > > /*********************************************************************** > * ExecuteCabA (ADVPACK.@) >+ * >+ * See ExecuteCabW. >+ */ >+HRESULT WINAPI ExecuteCabA(HWND hwnd, CABINFOA* pCab, LPVOID pReserved) >+{ >+ UNICODE_STRING cab, inf, section; >+ CABINFOW cabinfo; >+ HRESULT hr; >+ >+ TRACE("(%p, %p, %p)\n", hwnd, pCab, pReserved); >+ >+ if (!pCab) >+ return E_INVALIDARG; >+ >+ RtlCreateUnicodeStringFromAsciiz(&cab, pCab->pszCab); > > pCab->pszCab can be NULL, right? I don't think RtlCreateUnicodeStringFromAsciiz handles that case in the way you expect. -- Rob Shearman

March 30, 2006

Re: Direct3D, the kernel and ReactOS

by Christoph Frick

On Wed, Mar 29, 2006 at 11:12:06PM +0200, Stefan Dösinger wrote: > My long term suggestion is to move the Direct3D->OpenGL translation > code from WineD3D to gdi and a win32k sys, and write ddraw.dll, > d3d8.dll and d3d9.dll to use that interface. The user mode dlls can be > shared with Reactos, and from a technical point of view, even > Microsoft's DirectX dlls can be used on Wine(including the hardware > emulation layer). first of all excuse my ignorance of the d3d interface and so on - but this sounds to me like wine should not deal with the userland dlls at all then? once all the hardware is handled in the kernel parts what is the gain in having our own implementations? installing dx with the games should be sufficient then? on the other hand, if the interface of the kernel parts is hardly documented why not stick with the current implementation that does a good job with what it does and implement/stub the kernel things once an app crashes? -- cu

March 30, 2006

Re: Improper message recursion revealed by recent desktop window changes

by Jesse Allen

On 3/29/06, Troy Rollo <wine(a)troy.rollo.name> wrote: > The recent changes to the desktop have revealed a problem with recursive > processing of X messages. The problem started to manifest with commit > 1a4f6e579b6aab685fae2e649fd5accee7ec0b4f (7th March). A symptom is a stack > that looks like this: > > <application Window procedure> > WINPROC_wrapper > ... > CallWindowProcW > ... > SendMessageW > X11DRV_SetWindowPos > SetWindowPos > X11DRV_ConfigureNotify > process_events > X11DRV_MsgWaitForMultipleObjectsEx > wait_message_reply > send_inter_thread_message > SendMessageTimeoutW > SendMessageW > send_parent_notify > DestroyWindow > > In other words, a destroy notification is being sent to the parent window with > SendMessageW, and before that message returns an unrelated X message is > processed. Under Windows the equivalent could never happen - if a thread is > in SendMessage(), the only messages that can be delivered to it are ones sent > by SendMessage() from another thread. > > The consequences of this can be unpleasant if the code that processes (in this > case a window movement notification) the message interferes with state that > is being dealt with in earlier stack frames. Yep, that's why the launching of War3 seems to only paint explorer or the launch window depending on how I hacked wine. This is the problem exhibited in bugs 4948, 4897, and 4847. > > wait_message_reply calls X11DRV_MsgWaitForMultipleObjectsEx with: > > res = USER_Driver->pMsgWaitForMultipleObjectsEx( 1, &server_queue, > INFINITE, QS_ALLINPUT, 0 ); > > The brute-force approach of changing this to the following makes the > application work, but gives rise to some pack_message FIXMEs (for WM_NCPAINT > and WM_ERASEBKGND), and since this is an extremely sensitive piece of code to > change I thought it best left to people with more familiarity with it. > > -- > Troy Rollo - wine(a)troy.rollo.name > > > Last thing I did today was looking at the message passing and signal handling. The signal handling doesn't look any different than before. I figured something could be up with the message handling as it seemed one thread was stomping on another but I don't know anything about wineserver. I'll take a better look tomorrow! Jesse

March 29, 2006

Re: OT: General behaviour of the community (from 'Why winetools is utterly useless, once and for all')

by Hiji

On Wednesday 29 March 2006 7:31 pm, Hiji wrote: > > How do you propose we prevent people from emailing people that post to > > wine-devel? How do we choose who gets to email people directly and > > who doesn't? How do we filter the contents of their email? > > I want to chime in and say that I'm with Tom and the ole Doc here. I don't > think there's any way to filter somebody's contents, but I think it's > important for the community to speak up when somebody is out of line. Chris Morgan wrote: > Perhaps you didn't actually read the emails that were sent. This might > explain the discrepancy between your comment about "thinking its important > for the community to speak up when somebody is out of line" and this email > from Tom, the one I was replying to: I read all the emails, and I know exactly what I am referring to; so, there is no discrepancy. ;) I had in mind Segin's initial email (which was sent to the entire list): --- Segin <segin2005(a)gmail.com> wrote: > There is one reason, inarguable (if you reply to > this you have a IQ of > 0) as to why WineTools is useless: Most of the > WineTools 'magic' is in > it's ~/.wine/config file, which Wine no longer > uses/acknoleges, thefore, > WineTools is utterly useless and has no point in > existing AT ALL, PERIOD. To which I responded: > Dude, you need a bit more constructive in your > comments, or you'll be getting a lot of resentment on > this list REAL fast. Per your comment "What he said on the list seemed pretty reasonable to me.", if you don't see anything wrong with what Segin said, then so be it. Others, meanwhile, have recognized his misplaced behavior. Cheers, Hiji

March 29, 2006

Re: OT: General behaviour of the community (from 'Why winetools is utterly useless, once and for all')

by Chris Morgan

On Wednesday 29 March 2006 7:31 pm, Hiji wrote: > > How do you propose we prevent people from emailing people that post to > > wine-devel? How do we choose who gets to email people directly and > > who doesn't? How do we filter the contents of their email? > > I want to chime in and say that I'm with Tom and the ole Doc here. I don't > think there's any way to filter somebody's contents, but I think it's > important for the community to speak up when somebody is out of line. > Perhaps you didn't actually read the emails that were sent. This might explain the discrepancy between your comment about "thinking its important for the community to speak up when somebody is out of line" and this email from Tom, the one I was replying to: > From: > "Tom Spear" <speeddymon(a)gmail.com> > To: > "Wine Developers List" <wine-devel(a)winehq.com> > Date: > Today 5:12:33 pm > >Totally agreed. Segin > needs to be not just kick/banned from the list, he needs to be K-Lined, if > not G-Lined from all things wine! With respect to his comments though, on > behalf of everyone involved with the project, and with the community as a > whole, I sincerely apologize. Sounds to me like this is advocating censorship. > I know I was the first to respond to Sergin's email by asking that he be > more constructive in his feedback, but past that, none of the regulars on > this thread said much. Now, his thread has spawned into something that is > soooo far out there that it almost has no relevancy to this list. I want > to note that I don't see how Sergin's comments and behavior could have been > interpreted as anything but inappropriate; however, with the majority of > people not saying anything, I can only imagine that Sergin felt that what > he did was perfectly okay and acceptable on this list. > What he said on the list seemed pretty reasonable to me. Note that in the headers forwarded by Dr J A Gow the email from Segin appears to be directly from him and not to the list at all. It isn't our place to even care what Segin emails to people, as long as he isn't abusing the mailing list to do so. Chris

March 29, 2006

Interesting D3D testapp

by Willie Sippel

Hi there. I think I just found a very nice D3D testapp: fr-025 by Farbrausch. A nice, small (8.2MB) graphics demo, already works somewhat with Wine (starts, plays, music and everything works, good performance), but lots and lots of effects are simply missing or wrong. It does quite a bit interesting stuff wined3d doesn't seem to handle: strange viewport handling, glow, blending, reflections, blur(?). So many unimplemented features I won't even dare to file bugreports for every single one... :) It's the all-time most popular demo on pouet.net (obviously, given it's called "fr-025 - the.popular.demo" ;) ) You can get it at: http://www.pouet.net/prod.php?which=9450 -- Willie Sippel //////// | Tritium Studios // | ______________________________ //// /// | http://www.tritium-studios.com <willie(a)froq.net>

March 29, 2006

Re: [OT] Re: Why winetools is utterly useless, once and for all.

by Segin

Saulius Krasuckas wrote: >* On Tue, 28 Mar 2006, Karl Lattimer wrote: > > >>And also, accusing people of having an IQ of 0 for replying to a flame >>isn't in the slightest constructive, >> >> Hardly. I have actually done something good. I got people to addresses the Winetools problem a bit early. Sure, it would have gotten adressed anyways, but only after enough complains come rolling in, months or years from now. When I sent the flame, i had a purpose, a plan, and a hoped outcome. The end result was nothing but good, so why shun me? I was just getting a matter addressed before we have no choice but to address it. We can't just put it off forever, you know. > >Yes, he didn't write any single patch yet that was accepted, still he >manages to joke calling one of the developers being a monkey. (Given that >monkeys can't even distinguish between MUAs and MTAs nowadays) > > I haven't written any patches, namely because my eariler code changes i find cause signal 11. Recently I am working on something that will be offloaded months from now (if i dont find it to be too fustrating) as a huge diff, so keep your eyes peeled. If it doesn't work on either of my systems, it's broken, and sending a diff is a waste of everybody's time. >Being of sensitive nature I'd remove him from the list so he will find >appropriate lists to talk constructively in. (Be I wine-devel moderator) > >

March 29, 2006

Improper message recursion revealed by recent desktop window changes

by Troy Rollo

The recent changes to the desktop have revealed a problem with recursive processing of X messages. The problem started to manifest with commit 1a4f6e579b6aab685fae2e649fd5accee7ec0b4f (7th March). A symptom is a stack that looks like this: <application Window procedure> WINPROC_wrapper ... CallWindowProcW ... SendMessageW X11DRV_SetWindowPos SetWindowPos X11DRV_ConfigureNotify process_events X11DRV_MsgWaitForMultipleObjectsEx wait_message_reply send_inter_thread_message SendMessageTimeoutW SendMessageW send_parent_notify DestroyWindow In other words, a destroy notification is being sent to the parent window with SendMessageW, and before that message returns an unrelated X message is processed. Under Windows the equivalent could never happen - if a thread is in SendMessage(), the only messages that can be delivered to it are ones sent by SendMessage() from another thread. The consequences of this can be unpleasant if the code that processes (in this case a window movement notification) the message interferes with state that is being dealt with in earlier stack frames. wait_message_reply calls X11DRV_MsgWaitForMultipleObjectsEx with: res = USER_Driver->pMsgWaitForMultipleObjectsEx( 1, &server_queue, INFINITE, QS_ALLINPUT, 0 ); The brute-force approach of changing this to the following makes the application work, but gives rise to some pack_message FIXMEs (for WM_NCPAINT and WM_ERASEBKGND), and since this is an extremely sensitive piece of code to change I thought it best left to people with more familiarity with it. -- Troy Rollo - wine(a)troy.rollo.name

March 29, 2006

Re: OT: General behaviour of the community (from 'Why winetools is utterly useless, once and for all')

by Mike McCormack

Hiji wrote: > I know I was the first to respond to Sergin's email by asking that he be more constructive in his feedback, but past that, none of the regulars on this thread said much. Now, his thread has spawned into something that is soooo far out there that it almost has no relevancy to this list. I want to note that I don't see how Sergin's comments and behavior could have been interpreted as anything but inappropriate; however, with the majority of people not saying anything, I can only imagine that Sergin felt that what he did was perfectly okay and acceptable on this list. It's more about not feeding the trolls that agreeing with him. In my mind, Jon is a much more respectable member of the Wine community than "segin". It would be disappointing to see a real contributor scared off by a troll. Personally, I think Winetools has it's place, but it would be more helpful to the Wine community if it was a bit better supported, and used builtin dlls in preference to natives ones whenever possible. Mike

March 29, 2006

Re: OT: General behaviour of the community (from 'Why winetools is utterly useless, once and for all')

by Hiji

> How do you propose we prevent people from emailing people that post to > wine-devel? How do we choose who gets to email people directly and > who doesn't? How do we filter the contents of their email? I want to chime in and say that I'm with Tom and the ole Doc here. I don't think there's any way to filter somebody's contents, but I think it's important for the community to speak up when somebody is out of line. I know I was the first to respond to Sergin's email by asking that he be more constructive in his feedback, but past that, none of the regulars on this thread said much. Now, his thread has spawned into something that is soooo far out there that it almost has no relevancy to this list. I want to note that I don't see how Sergin's comments and behavior could have been interpreted as anything but inappropriate; however, with the majority of people not saying anything, I can only imagine that Sergin felt that what he did was perfectly okay and acceptable on this list. I'm trying to say two things here: 1) If somebody says/ does something that is not okay, say something to that person. Of course, be constructive about it. For example, when I first joined this list, people got upset that I was top-posting - I learned that it was not ok in this community because people said someting. So, I try to bottom post (when I remember.) 2) I've always said Wine is an awesome thing - probably the best thing to come out of the Linux community since ... well, Linux and its desktops. Now, more than ever, Wine need as many developers as possible to keep it improve b/c as Linux adoption continues people will look to Wine and CrossOver for application cross-compatibility. And, I'm not talking about the developer who pops in with a patch every 6 months (I see that person as a patch submitter), but instead, I'm talking about a developer who dedicated him/herself to the Wine project. And with that, the team can't afford to lose that good talent b/c the "newbie talent" was mistreated in this community. Those are my 2 cents that I think will go a long way. Thanks, Hiji

March 29, 2006

Re: OT: General behaviour of the community (from 'Why winetools is utterly useless, once and for all')

by Chris Morgan

> > I'm pretty sure people are capable of filtering their own email. > > Afaict the offending emails were between two individuals. You may not > > like them but that has no bearing on whether they should be allowed to > > post to the mailing list given that those emails to the mailing list > > are appropriate. > > > > Chris > > > > Be that as it may, the person who made those comments made them as a direct > attack on someone who posted to the list. Regardless of whether or not the > insults were posted to the list, he shouldn't have made them. As the person > who reported the incident said, had it been a new developer interested in > helping wine (either directly by contributing code to the project, or > indirectly by writing a support app), he probably would have said screw > this, I'm not going to help out a project that has developers who verbally > attack me. I know I would have. > How do you propose we prevent people from emailing people that post to wine-devel? How do we choose who gets to email people directly and who doesn't? How do we filter the contents of their email? Segin doesn't speak for the entire community and he isn't a lead on the project. If that were the case this would be a more serious matter. If people quit because of him then what are we to do? Given the lack of relationship between wine and Segin they might as well have quit wine development because of some Nigerian money transfer email or other spam. My point is that the solution isn't trying to enforce censorship where you simply cannot and where it doesn't impact the community. As long as he doesn't abuse his list membership we have no reason to become involved in this issue. You won't find me supporting any kind of restrictions on what he says or which mailing lists he can belong to at this point in time. Chris

March 29, 2006