On Tue, Jul 1, 2008 at 2:17 PM, Owen Rudge owen@owenrudge.net wrote:
This patch adds a new applet, winecfg.cpl, to Wine, based on a patch sent a few months ago by Metody Stefanov (pure_evil @ mail.bg). The control panel features three icons, for Wine Configuration, the Registry Editor, and the Task Manager.
Isn't it more logical (and closer to native) to have a control panel applet for each category/tab already in winecfg instead of having one winecfg applet? Otherwise you're just moving winecfg to another place.
Isn't it more logical (and closer to native) to have a control panel applet for each category/tab already in winecfg instead of having one winecfg applet? Otherwise you're just moving winecfg to another place.
Well, my plan, as mentioned before in another thread, is to split up winecfg a bit, but there's only so much you can do this, due to the fact that most of the tabs in winecfg can work on a global or application-specific basis. As far as I can tell, the Desktop and Sound tabs are the only bits of winecfg that are global-only and as such can be split from the rest in this manner, and this is something I would be considering for a "next step" for this applet. However, I figured a simple applet that showed some icons that a) let us actually have something in the control panel and that would b) provide a more user-friendly interface to these tools for users would be a good start, rather than coming along straight away with a large patch that hacks up winecfg!
On Tue, Jul 1, 2008 at 4:22 PM, Owen Rudge owen@owenrudge.net wrote:
Isn't it more logical (and closer to native) to have a control panel applet for each category/tab already in winecfg instead of having one winecfg applet? Otherwise you're just moving winecfg to another place.
Well, my plan, as mentioned before in another thread, is to split up winecfg a bit, but there's only so much you can do this, due to the fact that most of the tabs in winecfg can work on a global or application-specific basis. As far as I can tell, the Desktop and Sound tabs are the only bits of winecfg that are global-only and as such can be split from the rest in this manner, and this is something I would be considering for a "next step" for this applet. However, I figured a simple applet that showed some icons that a) let us actually have something in the control panel and that would b) provide a more user-friendly interface to these tools for users would be a good start, rather than coming along straight away with a large patch that hacks up winecfg!
As we said before, implementing a control panel applet doesn't mean you have to do anything to the current winecfg code.
As we said before, implementing a control panel applet doesn't mean you have to do anything to the current winecfg code.
True, but would it really benefit to add an icon for each winecfg tab (which I think is what you are suggesting, yes?) to the control panel, compared to having one general icon for Wine configuration?
Owen Rudge wrote:
As we said before, implementing a control panel applet doesn't mean you have to do anything to the current winecfg code.
True, but would it really benefit to add an icon for each winecfg tab (which I think is what you are suggesting, yes?) to the control panel, compared to having one general icon for Wine configuration?
I don't think think making winecfg seem more like the Windows Control panel is really something wine should strive for. Wine may be a compatibility layer for Windows but I'm not sure it should mimic it.
Rob Thornton
On Tue, Jul 1, 2008 at 6:05 PM, Rob Thornton rob_t@sunwave.net wrote:
Owen Rudge wrote:
As we said before, implementing a control panel applet doesn't mean you have to do anything to the current winecfg code.
True, but would it really benefit to add an icon for each winecfg tab (which I think is what you are suggesting, yes?) to the control panel, compared to having one general icon for Wine configuration?
I don't think think making winecfg seem more like the Windows Control panel is really something wine should strive for. Wine may be a compatibility layer for Windows but I'm not sure it should mimic it.
Then what's the point of this mini-project? We've already decided it's what we want for Wine, so you won't get much sympathy for this argument. Keep in mind: we're not removing winecfg (yet)...we're just adding applets to the control panel.
On Tue, Jul 1, 2008 at 5:47 PM, Owen Rudge owen@owenrudge.net wrote:
As we said before, implementing a control panel applet doesn't mean you have to do anything to the current winecfg code.
True, but would it really benefit to add an icon for each winecfg tab (which I think is what you are suggesting, yes?) to the control panel, compared to having one general icon for Wine configuration?
First, that's not what I was suggesting. I was disagreeing with adding a winecfg cpl applet. Second, I'm likening winecfg to a very poorly-designed control panel. There are several categories that can go into their own cpl applet, like 'Sound' and 'Graphics' (or whatever you want to call them), though there's not a 1-to-1 correspondence between winecfg tabs and potentially beneficial cpl applets.
First, that's not what I was suggesting. I was disagreeing with adding a winecfg cpl applet. Second, I'm likening winecfg to a very poorly-designed control panel. There are several categories that can go into their own cpl applet, like 'Sound' and 'Graphics' (or whatever you want to call them), though there's not a 1-to-1 correspondence between winecfg tabs and potentially beneficial cpl applets.
Ah, I see now. Well, that's what I'm ultimately hoping to do, although as mentioned before, working out issues with the likes of how to integrate an interface for application-versus-global settings for each applet will require a bit of thinking. In addition, I imagine splitting up/redesigning winecfg is something that may involve a bit of resistance from those already accustomed to its present manner of working. This patch is just the first part of a submission to create a basic control panel skeleton - as I said before, I am hoping to redesign parts of winecfg and shift those parts into their own control panel applets (which technically can be all part of this same .cpl file). For the bits that don't get moved into separate applets, I don't see why a general Wine Configuration icon would be a bad thing, for the time being at least.
On Tue, Jul 1, 2008 at 6:15 PM, Owen Rudge owen@owenrudge.net wrote:
First, that's not what I was suggesting. I was disagreeing with adding a winecfg cpl applet. Second, I'm likening winecfg to a very poorly-designed control panel. There are several categories that can go into their own cpl applet, like 'Sound' and 'Graphics' (or whatever you want to call them), though there's not a 1-to-1 correspondence between winecfg tabs and potentially beneficial cpl applets.
Ah, I see now. Well, that's what I'm ultimately hoping to do, although as mentioned before, working out issues with the likes of how to integrate an interface for application-versus-global settings for each applet will require a bit of thinking. In addition, I imagine splitting up/redesigning winecfg is something that may involve a bit of resistance from those already accustomed to its present manner of working. This patch is just the first part of a submission to create a basic control panel skeleton - as I said before, I am hoping to redesign parts of winecfg and shift those parts into their own control panel applets (which technically can be all part of this same .cpl file). For the bits that don't get moved into separate applets, I don't see why a general Wine Configuration icon would be a bad thing, for the time being at least.
I still don't see the need for a winecfg cpl applet at this point. You say that the Wine Configuration icon is ok for the time being. Take your time and design it correctly the first time, so you or others don't have to go back and fix it later. Measure twice, cut once, as they say. I want to reiterate that, as far as I remember, this project doesn't have anything to do with redesigning winecfg. Correct me if I'm wrong.
I still don't see the need for a winecfg cpl applet at this point. You say that the Wine Configuration icon is ok for the time being. Take your time and design it correctly the first time, so you or others don't have to go back and fix it later. Measure twice, cut once, as they say. I want to reiterate that, as far as I remember, this project doesn't have anything to do with redesigning winecfg. Correct me if I'm wrong.
Well, the first part of the project was to get the shell namespace implementation of Control Panel working properly, which is now effectively complete. The second part of the project is to work on some applets for Wine, including improving the standard winecfg applets, unifying all of Wine's configuration tools in the Control Panel. As an example, I'm working on a new Add/Remove Programs applet, to replace the standard Wine uninstaller with one of enhanced functionality, and I am looking into what other applets will be useful within Wine. Splitting up appropriate parts of winecfg into separate control panels is another intention. As this latter goal may take a while to design and implement, I personally believe this control panel applet (which also adds icons for the Registry Editor and Task Manager, two other key utilities, which would be useful to have easy access for) is a useful stepping-stone, as it were.
I do get your point about designing things correctly, of course, but considering the relativey minor functionality of this control panel, it seems to me to be reasonable to include for the time being, so that it can be developed over the next month or so to include all this extra functionality - instead of turning up at the end of July with a large unwieldy patch!
Hope this helps clarify things,
2008/7/2 Owen Rudge owen@owenrudge.net:
Well, the first part of the project was to get the shell namespace implementation of Control Panel working properly, which is now effectively complete.
Hi,
I just tested Cepstral SwiftTalker with latest git (see bug: http://bugs.winehq.org/show_bug.cgi?id=12534) and I can't see the options from the `control` program. You might want to get this and other applets displaying/working before creating default Wine-specific ones (e.g. like the one installed by Internet Explorer).
From my investigation into that bug (12534), I found that built-in
control panel applets and installed ones were processed differently - installed ones used the registry, built-in ones didn't.
- Reece
Hi Reece,
I just tested Cepstral SwiftTalker with latest git (see bug: http://bugs.winehq.org/show_bug.cgi?id=12534) and I can't see the options from the `control` program. You might want to get this and other applets displaying/working before creating default Wine-specific ones (e.g. like the one installed by Internet Explorer).
I'll look into that, then. I know that the shell namespace control panel does check the registry for entries (could you try using a program like the ReactOS Explorer to browse the control panel and see if it shows up there?), but I'm not sure if the standalone control.exe does. Ideally, the standalone control.exe would be replaced with a stub that launches the Explorer, but of course Wine doesn't have a built-in Explorer yet.
I'll do some testing with this app later and see what the problem is.
Cheers,
I'll look into that, then. I know that the shell namespace control panel does check the registry for entries (could you try using a program like the ReactOS Explorer to browse the control panel and see if it shows up there?), but I'm not sure if the standalone control.exe does. Ideally, the standalone control.exe would be replaced with a stub that launches the Explorer, but of course Wine doesn't have a built-in Explorer yet.
Wine's builtin control does just launch the shell's version of the control panel, unless it's given an argument like "DESKTOP", "DATE/TIME", etc. See programs/control.c.
Those string arguments to control aren't functional, because the control panel applets they reference don't exist in Wine. Launching control panel items via name is described in MSDN: http://msdn.microsoft.com/en-us/library/bb776838.aspx See especially "Executing Control Panel Items", http://msdn.microsoft.com/en-us/library/bb776841(VS.85).aspx
You might try to make some of those that have an analogue work in Wine, especially the "Legacy Control Panel Commands" "desktop" and "color". --Juan
Wine's builtin control does just launch the shell's version of the control panel, unless it's given an argument like "DESKTOP", "DATE/TIME", etc. See programs/control.c.
Indeed, I'm aware of that. Effectively, there are two versions of the control panel in the shell of course, the namespace version and the built-in simple version. The latter didn't check the registry for control panels - I've just implemented such a check, which will fix this bug. I'll submit a patch shortly.
You might try to make some of those that have an analogue work in Wine, especially the "Legacy Control Panel Commands" "desktop" and "color".
That's something I can look into, indeed.
Cheers,
You might try to make some of those that have an analogue work in Wine, especially the "Legacy Control Panel Commands" "desktop" and "color".
That's something I can look into, indeed.
Having had a brief look into it, currently the control panel attempts to launch the appropriate .cpl file that would be launched on Windows. I think, rather than altering this to load winecfg instead, it'd probably be best to leave any changes here for the time being. If I do (or someone else does) end up splitting up winecfg, then the best plan would simply be to name the resulting control panels in a way compatible with Windows.
Regards,
Owen Rudge owen@owenrudge.net writes:
I personally believe this control panel applet (which also adds icons for the Registry Editor and Task Manager, two other key utilities, which would be useful to have easy access for) is a useful stepping-stone, as it were.
The control panel is not supposed to be a general application launcher, regedit and taskmgr don't belong there.
-
Alexandre Julliard -
James Hawkins -
Juan Lang -
Owen Rudge -
Reece Dunn -
Rob Thornton