Re: Shuttleworth on Wine
2009/5/8 Scott Ritchie : > We had "no application regressions" as a release goal for 1.0, more or less > - in practice that meant we were targeting every application users wanted to > test it on. But there were also 4 specific apps targeted too - IIRC stuff > like word viewer. In principle there's no reason an application like > Photoshop couldn't be considered release critical in much the same fashion > these were. Yes, the targets were Microsoft Word/Powerpoint viewer, while cheap and free to download, they're both actually pretty complex (office based). As a shameless plug, this is the kind of stuff I'm planning on testing this summer for Summer of Code. Photoshop, however, is harder to test, since it doesn't have an easy free download available. Adobe reader/photoshop album, however, may be a bit easier to test, and have the bonus of some similar bugs. If anyone has some simple applications that are easy to test (preferably, with no installer), shoot me an e-mail and I'll add it to my my list of applications to look at. -- -Austin
New icons for 1.1.21
Hey everyone, I just wanted to say that the icon discussion I started a couple weeks back has born even more fruit, and I'm really happy with the current state of the icons that I'm now using in the 1.1.21 Ubuntu packages. I've attached them, and will be sending them as patches soon as well. I'm still not quite done with them, and they will likely change a bit after I get some UI feedback at the Ubuntu Developer Summit at the end of the month, but in the meantime I think they're quite better than what we have. Unlike the ubuntustudio icons I found (and packaged with 1.1.20 as an experiment), these should be a bit more visible (and fully tango-compliant). In particular, the stem of the glass is no longer two semitransparent pixels at normal 48x48 size, but instead has a full Tango border/inner brush stroke. Smaller icons for the other standard sizes are being worked on as well, however they have to be retouched individually to maintain the 1 pixel border/brush stroke in the Tango style. Eventually I'll submit a patch for our website's mini icon as well. Anyway, please feel free to give way too much feedback :) Thanks, Scott Ritchie new-wine-tango-icons-may-2009.tar.bz2 Description: application/bzip
Re: Shuttleworth on Wine
Ben Klein wrote: 2009/5/8 Nicklas Börjesson : And the *rest* of the world DO revolve around a few applications. That is why they think so. No, the rest of the world does not revolve around a few applications, it's just that the #1 complaint against free operating systems has been traditionally "it won't run Photoshop". In my experience, most people who argue this don't even care about it, and in fact some people miss the point entirely and dismiss Wine as "not a solution", because they expect it to run natively, fluidly, with complete desktop integration etc. The great thing about this is these are all solvable problems, even in the near term. Photoshop almost works. Desktop integration is almost there. I'm doing what I can to make Wine a very impressive piece of software to the point where its integration into the desktop seems completely natural. Though, I must say, the majority of people I see/hear using Photoshop *are* using it as a toy/hobby, not for 'real' work, i.e., a full time job. I have the same impression. And most haven't paid for it either. Anyway, that really isn't important. Except that WineHQ does not officially support pirated software (it may run, but you'll get no official help getting it to run or work properly). Internet Explorer: Free as in beer. Wine: Free as in speech. Photoshop: Free as in stolen. The important thing is that they want it, no why. As it stands, yes, the fact that they want it is more important than why. It's also unimportant to Wine's goals (which is for *all* applications to run, not just Photoshop), and should not be considered a factor in determining when the next release is ready. We had "no application regressions" as a release goal for 1.0, more or less - in practice that meant we were targeting every application users wanted to test it on. But there were also 4 specific apps targeted too - IIRC stuff like word viewer. In principle there's no reason an application like Photoshop couldn't be considered release critical in much the same fashion these were. For practical reasons, however, we probably don't want to target particular applications just because they're popular - a better strategy would be to target particular users who only need one application that is almost working. At least, that's what the model I wrote told me: http://yokozar.org/blog/archives/48 Thanks, Scott Ritchie
Re: Severity levels
2009/5/9 Remco : > 2009/5/9 Ben Klein : >> Still not your problem? Still feeling bullied, but this time by the >> mailing list server? >> >> I don't believe your earlier mains have been resent. I certainly >> haven't received them. > > My Gmail account tells me that all those mails are like 4 days old. > This has happened to me before. I thought it was a problem with Gmail, > but it may as well be the wine mailing list server, or something else > entirely. > When you're not subscribed to the list, your posts have to go through moderation. Sometimes that can take a while.
Re: Severity levels
2009/5/9 Ben Klein : > Still not your problem? Still feeling bullied, but this time by the > mailing list server? > > I don't believe your earlier mains have been resent. I certainly > haven't received them. My Gmail account tells me that all those mails are like 4 days old. This has happened to me before. I thought it was a problem with Gmail, but it may as well be the wine mailing list server, or something else entirely. Remco
Re: Severity levels
2009/5/8 Nicklas Börjesson : > 2009/5/8 Austin English : >> No offense, but you should probably take the lack of (repeated) >> responses as a sign. > > I did leave it alone. > That post was a reaction to what I considered as bullying. > The answers has almost never been to anything I have said, > but rather to things I haven't said. You've been repeatedly informed why your proposed changes to the severity levels are a bad idea by many people on this list. Let's take an analogy: Imagine you're a fresh, young car tester at Ford. Using an open-door policy to contact an executive, you promise a new, efficient design to replace the current combustion engines completely. You present your idea at a board meeting. The board is not receptive to your proposed changes. The engineering department doesn't believe it will solve any problems, and in fact that it will reduce fuel efficiency and increase pollution. The other board members point out that you're very new to the company, and that you have no experience in engine design or engineering and you are only present in the company as a tester. In this scenario, are you being bullied by the board members? > //Nicklas > PS. > No, I am new to the wine project. > But there is a world outside of it. > DS. You'd have some credibility if you researched what the Wine project does with bugzilla, how it currently works, etc. rather than just assuming it's the wrong way to do it. 2009/5/8 Nicklas Börjesson : > Hi all, > it seems that some of my earlier mails(and some other) has been re-mailed to > the list. > I don't think that our(here, at my workplace) servers has done this, rather, > it feels like the mailing list server did it. > So understand that I am not bombarding the list. > I see that many are replying to some really old posts. Still not your problem? Still feeling bullied, but this time by the mailing list server? I don't believe your earlier mains have been resent. I certainly haven't received them.
Re: Shuttleworth on Wine
2009/5/8 Nicklas Börjesson : > And the *rest* of the world DO revolve around a few applications. > That is why they think so. No, the rest of the world does not revolve around a few applications, it's just that the #1 complaint against free operating systems has been traditionally "it won't run Photoshop". In my experience, most people who argue this don't even care about it, and in fact some people miss the point entirely and dismiss Wine as "not a solution", because they expect it to run natively, fluidly, with complete desktop integration etc. >>Though, I must say, the majority of people I see/hear using Photoshop >>*are* using it as a toy/hobby, not for 'real' work, i.e., a full time >>job. > > I have the same impression. And most haven't paid for it either. > Anyway, that really isn't important. Except that WineHQ does not officially support pirated software (it may run, but you'll get no official help getting it to run or work properly). > The important thing is that they want it, no why. As it stands, yes, the fact that they want it is more important than why. It's also unimportant to Wine's goals (which is for *all* applications to run, not just Photoshop), and should not be considered a factor in determining when the next release is ready.
Re: comctl32/test: test CheckState Macros
Nikolay Sivov wrote: > No actually. Native uses ListView_SetItemState for that macro which is > SNDMSGA in wine and SNDMSG in native. He asked why his patch is not getting in - that's one of the reasons. You should always use SendMessageW where possible. Especially for things that don't care if it's A or W. This is to prevent extra A->W conversions. Vitaliy.
RE: Severity levels
Hi all, it seems that some of my earlier mails(and some other) has been re-mailed to the list. I don't think that our(here, at my workplace) servers has done this, rather, it feels like the mailing list server did it. So understand that I am not bombarding the list. I see that many are replying to some really old posts. //Nicklas
Re: Does wine handle virtual midi ports correct on OSX?
Thanks for that. Hope we can get to the bottom of the issue. Ken Thomases wrote: > > On May 6, 2009, at 11:20 PM, Dewdman42 wrote: > > As far as I know, only Emmanuel Maillard has touched the MIDI code in > the Core Audio driver. I'm CC'ing him, just to be sure he sees this. > > Cheers, > Ken > > -- View this message in context: http://www.nabble.com/Does-wine-handle-virtual-midi-ports-correct-on-OSX--tp23419972p23436811.html Sent from the Wine - Devel mailing list archive at Nabble.com.
Re: Does wine handle virtual midi ports correct on OSX?
Thanks a lot for that. Would be nice to get to the bottom of this issue and I am happy to run some tests if he can help me set debug flags or whatever to figure it out. On May 7, 2009, at 1:14 PM, Ken Thomases wrote: On May 6, 2009, at 11:20 PM, Dewdman42 wrote: Does anyone know if Darwine can be fixed to handle virtual midi ports correctly? They work very sporadically right now. It seems to be related to getting the ports flushed or initialized or something. When there is a virtual midi port present (under OSX), Wine seems to see it and lists it as an available midi port, but I have not been able to consistently get that port to function correctly. Sometimes it does and sometimes it doesn't and it seems to related to switching it on and off in some fashion makes it work, though I can't seem to find a pattern that will work consistently. All I can figure is that somehow Wine is not handling midi ports in a way that is compatible with OSX virtual midi ports. Anyone have any experience or knowledge in this area? As far as I know, only Emmanuel Maillard has touched the MIDI code in the Core Audio driver. I'm CC'ing him, just to be sure he sees this. Cheers, Ken - Steve Schow st...@bstage.com 206-724-8083
RE: Shuttleworth on Wine
>I think you're seriously underestimating Wine, and the amount of >'real' work it can accomplish. The world doesn't revolve around Adobe >products, contrary to what many recent converts to GNU/Linux may >think. As usual, I am not talking about myself, but people in generals' perception of it, which reflected quite well in Shuttleworths comments. Whatever you think of the guy, remember he was a developer on the Debian project in the nineties. He's not totally unitiated. And I don't think he is unique in any way. Also, (quoting http://www.winehq.org/about/): "Wine is still under development, and it is not yet suitable for general use." Doesn't say stability. Especially when the version has passed 1.0. And the *rest* of the world DO revolve around a few applications. That is why they think so. >Though, I must say, the majority of people I see/hear using Photoshop >*are* using it as a toy/hobby, not for 'real' work, i.e., a full time >job. I have the same impression. And most haven't paid for it either. Anyway, that really isn't important. The important thing is that they want it, no why.
RE: Severity levels
>No offense, but you should probably take the lack of (repeated) >responses as a sign. I did leave it alone. That post was a reaction to what I considered as bullying. The answers has almost never been to anything I have said, but rather to things I haven't said. //Nicklas PS. No, I am new to the wine project. But there is a world outside of it. DS.
Re: Dynamically adding debug channels (__wine_dbg_set_channel_flags)
The Problem with a pre-processor setting would be that the endusers may not be able to make good logs for the devs. At the moment you can say to a user "send a log using 'WINEDEBUG=commctrl wine program.exe'", the user doesnt have to know what he is doing exactly, but he sends a usefull text. That wouldnt be possible anymore as i understand it. Best regards André Hentschel Daniel Santos schrieb: It would seem quite helpful for debugging odd situations to be able to turn debugging on and off programmatically. I like not having every debug class loaded in memory by default (and everything that goes with maintaining that global list), but it would seem quite helpful for troubleshooting, testing and debugging special cases (mostly where one doesn't have the sources of the troublesome app). Thus, perhaps __wine_dbg_set_channel_flags could add the debug channel to debug_options if it doesn't exist and even allow setting the default_flags (say by having a zero-length name in the channel argument) or even another function which would allow it. I'm not sure what thread synchronization implications this would bring about (and the associated costs of the sync objects), it seems it would require at the least the use of a critical section to modify the debug_options, but perhaps this can be a pre-processor driven option? The configure could have a --enable-dynamic-channels or some such that would set a pre-processor macro, etc. Alternatively, a cheaper (hackier) mechanism of thread-safety could be achived by having the debug_options be contained in a struct along with the nb_debug_options and have them heap-allocated so that the debug_options pointer could be changed in a single machine instruction. A similar mechanism (i.e., hack) could be use to free the old debug_options struct. That's ugly, but I'm just presenting options. Daniel
Re: tools/winedump: sign compare fixes
Austin English writes:
> -static const char *debugstr_wn(const WCHAR *wstr, int n)
> +static const char *debugstr_wn(const WCHAR *wstr, uint n)
> {
> static char buf[80];
> char *p;
> -int i;
> +uint i;
uint is not a standard type. Use "unsigned int" instead.
--
Alexandre Julliard
julli...@winehq.org
Re: comctl32/test: test CheckState Macros
Vitaliy Margolen wrote: André Hentschel wrote: I made one patch out of them and improved my tests. now i wonder again why its not getting in... You should use SNDMSGW. Vitaliy. No actually. Native uses ListView_SetItemState for that macro which is SNDMSGA in wine and SNDMSG in native.
Re: comctl32/test: test CheckState Macros
André Hentschel wrote: > I made one patch out of them and improved my tests. > now i wonder again why its not getting in... You should use SNDMSGW. Vitaliy.
