Hi, I've got a couple of questions tonight:
1) Currently the default printer is read from win.ini - setting this is annoying and doesn't work out of the box. I think it'd make more sense to have it also in the wine configuration, so if no win.ini string is retrieved it'll still work. I have an app here that dies if there is no default printer. Is it acceptable to make a fallback in the registry/config branch? The default would be "Wine Postscript Driver", though I guess we could be clever - enumerate the printers actually installed and pick the first. I don't know enough about printing to say. Huw?
2) The reason I've been so quiet on the winecfg front lately (ignoring university) is because I'm working on porting an app commercially. As a part of that process, I'm generating patches and committing to a private branch. However, I'm not sure how best to manage patch submission. There are a few alternatives:
a) Just keep them "secret" until I get paid, at which point I send them in all together. Pros: Simple, Cons: people might duplicate my work.
b) Notify the Wine community of what the patches do/are but keep their contents secret. Pros: Less chance of duplication, Cons: if people need the patch, knowing I have one won't be much use and it'd be hard to notify people without spamming the mailing list. Not enough people monitor bugzilla for me to be sure it'd work.
c) Post them all to wine-devel but under a license that prevents them being merged unless you get a special exception from me. That way people can see, peer review the patches etc but they don't get committed. Of course, as this is just supposed to be insurance anyway, that seems a bit worthless.
d) Say "screw it", submit as usual and just hope I'm dealing with trustworthy people (unfortunately no contract in this case, the job isn't really big enough to warrant one).
Does anybody have any experience of this? What is the best approach?
thanks -mike
On Thu, Nov 27, 2003 at 09:37:16PM +0000, Mike Hearn wrote:
Hi, I've got a couple of questions tonight:
- Currently the default printer is read from win.ini - setting this is
annoying and doesn't work out of the box. I think it'd make more sense to have it also in the wine configuration, so if no win.ini string is retrieved it'll still work. I have an app here that dies if there is no default printer. Is it acceptable to make a fallback in the registry/config branch? The default would be "Wine Postscript Driver", though I guess we could be clever - enumerate the printers actually installed and pick the first. I don't know enough about printing to say. Huw?
We should be doing this already. If cups is installed then we use the cups default, otherwise for printcap systems we use the PRINTER env variable or if that isn't set the first entry in /etc/printcap. Take a look at dlls/winspool/info.c
Huw.
On Thu, 2003-11-27 at 22:59, Huw D M Davies wrote:
We should be doing this already. If cups is installed then we use the cups default, otherwise for printcap systems we use the PRINTER env variable or if that isn't set the first entry in /etc/printcap. Take a look at dlls/winspool/info.c
Well, at least in the copy I have WINSPOOL_EnumPrinters has this:
/* PRINTER_ENUM_DEFAULT is only supported under win9x, we behave like NT */ if(dwType == PRINTER_ENUM_DEFAULT) return TRUE;
ie it's a no-op. Bear in mind I don't have any printers installed, the only driver available is the Wine PostScript driver so neither CUPs nor printcap is set up.
thanks -mike
Mike Hearn mike@theoretic.com writes:
b) Notify the Wine community of what the patches do/are but keep their contents secret. Pros: Less chance of duplication, Cons: if people need the patch, knowing I have one won't be much use and it'd be hard to notify people without spamming the mailing list. Not enough people monitor bugzilla for me to be sure it'd work.
Don't do that. Patches that aren't released under a free license should be treated as if they didn't exist; we don't want to discourage people from working on something just because someone has a patch that may or may not be released at some indeterminate point in the future.
This may cause some duplication, but it's always better to have two implementations of something than to risk having none at all if it turns out that you can't release the patch in the end.
Also make sure that you get the customer's agreement before releasing anything; most likely if you are doing work for hire they own the copyright and you can't release it without their permission (of course once they distribute the result it has to be LGPL, but they don't necessarily want to distribute it).
On Fri, 2003-11-28 at 02:28, Alexandre Julliard wrote:
This may cause some duplication, but it's always better to have two implementations of something than to risk having none at all if it turns out that you can't release the patch in the end.
OK, this is a good point.
Also make sure that you get the customer's agreement before releasing anything; most likely if you are doing work for hire they own the copyright and you can't release it without their permission (of course once they distribute the result it has to be LGPL, but they don't necessarily want to distribute it).
I'll have to check on who owns the copyright, but in this case at least a stipulation of doing the work was that the changes would be merged back into Wine if possible, so that isn't a problem.
thanks -mike
-
Alexandre Julliard -
Huw D M Davies -
Mike Hearn