Re: How to convert msvcp names to legible names?
On 19/08/2012 01:04, Bruno Jesus wrote: Which is the roseta stone used to read all msvcp function names like "msvcp80.dll.??0?$basic_stringstream@GU?$char_traits@G@std@@V?$allocator@G@2@@std@@QAE@H@Z, aborting" as the real function name in source code? http://slush.warosu.org/c++filtjs/ is handy if you want to quickly decode a mangled name. -- Owen Rudge http://www.owenrudge.net/
Re: GSoC mentor summit 2012
On 06/08/2012 17:17, Stefan Dösinger wrote: Am Freitag, 3. August 2012, 14:38:29 schrieb Aric Stewart: ok, then how about you two just go. That seems easy. Cool :-) . I've filled out the attendee registration, and I'm currently figuring out how to add myself to the attendee list on the gsoc wiki(there's some password for the wiki I keep forgetting). OK, well, I shall do the same too. :) -- Owen Rudge http://www.owenrudge.net/
Re: GSoC mentor summit 2012
On 02/08/2012 11:48, Stefan Dösinger wrote: Am Montag, 30. Juli 2012, 08:16:38 schrieb Aric Stewart: I could be interested. I have never been and am a first time mentor. October is still a bit far off for me to be able to plan. So if someone else can completely commit that is cool. But I will try to get info about my availability that weekend asap. I know that I'll have time to attend the summit, fwiw. Likewise, I would be fine to do so too, so it would be good for us to get something arranged reasonably soon. I think Google wants everything sorted by September, but the main hotel tends to fill up pretty quickly. -- Owen Rudge http://www.owenrudge.net/
Re: GSoC mentor summit 2012
On 27/07/2012 12:20, Stefan Dösinger wrote: > That said, I've been there before, so if two other mentors who haven't been to > the summit yet want to go I am happy to yield the spot. Likewise, I'd put my name forward to attend again this year, but as with Stefan, if there are others who haven't been who would like to attend, then they should come first. :) -- Owen Rudge http://www.owenrudge.net/
GSoC mentor summit 2012
It looks like the GSoC mentor summit for 2012 has been announced. Are any of the mentors this year interested in attending? It's happening on the 20th/21st October in Mountain View. Details are on the GSoC mentor wiki: http://gsoc-wiki.osuosl.org/index.php/2012 Cheers, -- Owen Rudge http://www.owenrudge.net/
Re: [2/2] msvcp90: Sync spec files
On 28/06/2012 11:33, Owen Rudge wrote: --- dlls/msvcp60/msvcp60.spec | 638 ++-- Sorry, I ran the make_specfiles script without realising that msvcp60.spec shouldn't have been updated. I've resent the patch without these changes. -- Owen Rudge http://www.owenrudge.net/
Re: [1/3] user32/tests: Add GetUserObjectInformation tests
On 14/05/2012 11:43, Alexandre Julliard wrote: Using the number of Unicode chars multiplied by 2 is a reasonable upper bound on the A string size, and it's used in a number of places. This can't really be considered a Windows bug. OK; it's perhaps not a bug in that case. I believe my patch is still functionally correct; would you like me to resubmit it to modify/remove the comments referring to it being a 'bug'? Cheers, -- Owen Rudge http://www.owenrudge.net/
Re: hhctrl.ocx: Don't show unimplemented buttons.
Could you point me to a link on this behavior? I'm pretty sure that many of these buttons send a signal that applications can hook into and override the default (do-nothing) behavior. The documentation for those specific values appears to be non-existent - the latest (as far as I'm aware) HTML Help documentation can be found here: http://www.microsoft.com/download/en/details.aspx?id=21138 Additionally, as Francois mentioned, the HTML Help header files do include some references to unimplemented functionality. -- Owen Rudge http://www.owenrudge.net/
Re: hhctrl: IDTB_XXX resource strings
So I propose the attached patch. I wouldn't object to that. If somebody wants to implement support for the Jump buttons in the future, they can always be re-added, although I would say that in such a circumstance, a resource file entry wouldn't be necessary anyway. -- Owen Rudge http://www.owenrudge.net/
Re: hhctrl: IDTB_XXX resource strings
I see the strings being added to the toolbar with LPWSTR szBuf = HH_LoadString(buttons[dwIndex].idCommand); ... buttons[dwIndex].iString = (DWORD)SendMessageW(hToolbar, TB_ADDSTRINGW, 0, (LPARAM)szBuf); But from there it's not clear to me they whether they will be used or not. Did you specifically mean that only Jump1/2 would not be used or does that apply to the other IDTB_XXX strings too? I was referring specifically to Jump1/2 in this case. They do get used, particularly as it looks like we don't currently replace them with the custom text. However, the "IDTB" strings that we have are all noted as "unimplemented" in Microsoft's htmlhelp.h file, and in theory nobody should be using them. Considering we don't support any of them in TB_AddButtonsFromFlags, I think the resource entries for them can be removed. James does seem to have added support for creating the toolbar buttons for IDTB_TOC_NEXT/PREV, but I can't find any documentation on what they're meant to do, and he added no actual functionality, so they can probably go too. -- Owen Rudge http://www.owenrudge.net/
Re: hhctrl: IDTB_XXX resource strings
However a number of them make no sense at all and are a pain to translate. For instance: IDTB_NOTES "IDTB_NOTES" IDTB_BROWSE_FWD "IDTB_BROWSE_FWD" IDTB_BROWSE_BACK "IDT_BROWSE_BACK" With regards to these buttons, attempting to use those constants on Windows results in buttons (captioned "Notes", "Next", "Previous") with no apparent functionality whatsoever. Microsoft's own documentation suggests these are "not implemented". I expect we could remove those from Wine's hhctrl without any great consequences. -- Owen Rudge http://www.owenrudge.net/
Re: hhctrl: IDTB_XXX resource strings
What's the difference between 'Jump1' and 'Jump2'? Both are, it appears, toolbar buttons that can be customised by the help file developer and used to link to individual topics or URLs. The captions are customisable. The strings "Jump1" and "Jump2" themselves, as far as I can tell, should never be displayed to the user. -- Owen Rudge http://www.owenrudge.net/
Re: gsoc mentor summit
On 27/07/2011 16:04, Stefan Dösinger wrote: Yes. I'd be interested as well, that's why I started this thread. I've been there already in 2009, so if anyone else wants to go I'd be happy to yield. Any further thoughts on this from any of the other mentors? It looks like the latest date to officially confirm things is the 30th September, but we probably want to figure things out before then to sort out travel, etc. -- Owen Rudge http://www.owenrudge.net/
Re: gsoc mentor summit
The gsoc mentor summit organizing is getting started. Do any fellow mentors want to travel there? I'd be interested if there's a space going free. We just get to send 2 mentors though as I understand it? Cheers, -- Owen Rudge http://www.owenrudge.net/
Re: [GSoC] Merge winecfg and Control Panel
Hi Tony, I have briefly walked through Owen Rudge's code of splitting out the Desktop Integration tab into its own control panel, but have no luck in getting a decent understanding of it. So I'm hoping some of you can point me to some documents that related to this task so I can have an overall understanding of the challenges of this task. Actually creating a new control panel applet is a fairly straightforward task. You can look at the existing control panels (appwiz.cpl, inetcpl.cpl) to get an idea of what's involved, or consult MSDN for more information (http://tinyurl.com/6yu7cw4). If you've not got a background in Windows programming already, it may of course take a little longer to figure everything out. More complicated is actually working out how to split up winecfg effectively, and how to do so in a way that doesn't result in unnecessary code duplication, otherwise you'll likely find it difficult to actually get your code into the project. I would say that there's certainly potential for a project here, if you can flesh it out - I do think a unified control panel containing all of Wine's configuration options would be a good thing, rather than the current situation where options are scattered between the control panel, winecfg, etc. The key will be figuring out what you want to do, how you're going to achieve it, and making sure it will be acceptable to the wider Wine community. Regards, -- Owen Rudge http://www.owenrudge.net/
Re: [PATCH 01/13] dsound: New sample rate converter core functions. (resend)
It looks like it may be too big to be accepted. Anyway, I will try to resend it with 4 space indent for new files. Hopefully these patches won't get wrapped this time. Your patches still appear to be being wrapped by your mail client. Try sending them as an attachment instead of inline (i.e., use the --attach parameter to git format-patch). -- Owen Rudge http://www.owenrudge.net/
Re: [PATCH 1/4] wineaddon.cpl: Added initial Wine Add-ons Manager stub.
On 06/12/2010 12:15, Jacek Caban wrote: I must have misunderstood your plan then. Now I understand that we will have MSI file with self extracting archive for both Gecko and Mono that can be downloaded and/or installed by control panel applet. I agree that appwiz.cpl looks like a better place than a new applet for that. Adding in an "optional components" tab to appwiz.cpl would seem to be the most sensible thing there, similar to that used in Windows. While you could have an entry in the Installed Programs list when they're installed, it would seem slightly perverse to include them in that list when they're not actually installed. To me, a separate tab would seem better. -- Owen Rudge http://www.owenrudge.net/
Re: Wineconf 2011 venue suggestion
I know 2010 has just finished but could I recommend Edinburgh for 2011? voted above London and Paris by Tripadvisor and Conde nast as a destination and amongst the top ten cities in the world 2008 by Wanderlust. Do we have another Scottish Wine hacker? :) I have suggested Edinburgh as a potential WineConf venue in the future, and would be happy to organise such a conference. Next year is I think currently planned to be Minnesota, however, as Michael explains. Regards, -- Owen Rudge http://www.owenrudge.net/
Re: [resend]: [dlls/dbgeng]: add initial stub dll implementation
On 19/11/2010 16:04, Volodymyr Shcherbyna wrote: Ouch, I did not know that. OK, I will re-format comments sections and typo and will re-send patch again. A minor niggle, but you should use your own name in the copyright line, rather than "WINE Project", as the project is not a legal entity in its own right. -- Owen Rudge http://www.owenrudge.net/
Re: Group Picture Wineconf 2010
The group picture taken this morning: http://www.flickr.com/photos/marcusmeissner/5191522943/ For all the ones who staid at home ;) Nice use of Photoshop. ;) -- Owen Rudge http://www.owenrudge.net/
Re: [try 2] [1/3] dsound: Add support for 32-bit IEEE float buffers
On 08/09/2010 15:41, Chris Robinson wrote: Is it safe to call le32 on a float? Especially one that's going to be used more? If the system is big-endian, the float/integer will need to be in big- endian to be processed. The raw data should be in a little-endian format. But you're right that it would probably have to be converted to big-endian to be processed, and then converted back to be stored. I'm also not sure that the conversion math is correct. In this case, -1.0 would get converted to -126.5 (or -32766.5, etc), instead of -128 (or -32768, etc). As well, I don't think the rules for converting a negative float value to an unsigned integer are that straight forward. I seem to recall mention that some systems will actually give 0 in that case. I realise now that I actually made a mistake in using WORD, DWORD, etc, as - with the exception of 8-bit audio - all of the destination buffers are signed. So hopefully we shouldn't have an issue with negative values being multiplied incorrectly. I'll have a poke around and produce a revised patch. Cheers, -- Owen Rudge http://www.owenrudge.net/
Re: [2/3] d3dx9: Implement D3DXCreateTextureFromFileInMemoryEx
Hi Henri, Probably depends on the device supporting NPOT textures again. The capabilities are checked in the D3DXCheckTextureRequirements function, and the values adjusted if necessary. (Yeah, this is a mostly unchanged copy of my earlier comments.) My apologies, I somehow missed the previous e-mail at the time. (I do see it now.) Thanks for your feedback, -- Owen Rudge http://www.owenrudge.net/
Re: [01/11] d3dx10: Add stub for d3dx10_43
At least with all d3dx10 DLLs released so far, D3D10_SDK_VERSION has not changed. Obviously, if it does change in the future, we will need to accommodate that in new DLLs. Although I suppose we could hard-code the SDK version into the DLLs now, rather than having to change it later, which I guess is what you were getting at, Henri. I'm not too convinced Microsoft is likely to change it during the D3D10 lifecycle, but I guess it doesn't hurt to be safe. Cheers, -- Owen Rudge http://www.owenrudge.net/
Re: [01/11] d3dx10: Add stub for d3dx10_43
Is it really safe to assume D3D10_SDK_VERSION will always keep the same value? (I know d3dx9 does it as well.) For d3d9 the SDK version changed between d3d9b and d3d9c, for example. At least with all d3dx10 DLLs released so far, D3D10_SDK_VERSION has not changed. Obviously, if it does change in the future, we will need to accommodate that in new DLLs. -- Owen Rudge http://www.owenrudge.net/
Re: (Resent) Documentation - Reference to MSDN?
No. MSDN is in the habit of changing its URLs all too frequently. For what it's worth, while MSDN seems to like changing its URLs a lot, it does seem to be quite good at maintaining forwarders for the old URLs - most API documentation URLs I've randomly found from 5 years ago still work, for instance. But I agree that it's probably not worth including them in Wine's documentation. -- Owen Rudge http://www.owenrudge.net/
Re: [6/10] winemapi: Add MAPIInitialize implementation.
On 18/01/2010 08:46, Alexandre Julliard wrote: This seemed to be the easiest and most trivial way to allow MAPIInitialize to succeed in the tests, which will be added in the next several patches. That doesn't seem right. The tests should be able to work without an extended provider. Indeed, unless we're actually going to implement some Extended MAPI functions in winemapi, we shouldn't really be adding MAPIInitialize - particularly as mapi32 will ignore winemapi for Extended MAPI purposes unless it's actually registered in the Clients section of the registry as an Extended MAPI provider. -- Owen Rudge http://www.owenrudge.net/
Re: Unable to connect to #winehackers
Hi James, I have been trying to connect to #winehackers from my Mac using Conversation. However, this is not working as I am not receiving the welcome screen from irc.freenode.net. There's possibly some issue with Freenode, as is not uncommon. Have you tried connecting to any particular Freenode server manually? I seem to be on "lindbohm.freenode.net", and it's working fine. Cheers, -- Owen Rudge http://www.owenrudge.net/
Re: [2/4] imagehlp/tests: Add tests for adding/removing multiple certificates
Hi Paul,
Would something like this be ok:
file_size_orig = get_file_size();
+ if (file_size_orig % 16 != 0)
+ {
+ trace("We need to adjust the file size\n");
+ file_size_orig = ((file_size_orig / 16) + 1) * 16;
+ }
Does anybody know if '16' is indeed the alignment needed?
The ImageHlp routines pad out to an 8-byte boundary, rather than 16
bytes. I guess as long as we're testing a DLL that we don't control,
this step may well be necessary.
Cheers,
--
Owen Rudge
http://www.owenrudge.net/
Re: [2/5] winemapi: Add Simple MAPI functions
On 16/12/2009 05:13, Henri Verbeet wrote: > These don't look quite right to me. They were copied from the existing mapi32.dll. I think they're mostly correct, although they do use "ptr" instead of "str". I'll double-check them and update if necessary. > Somewhat related, LHANDLE is a > ULONG in include/mapi.h, but a ULONG_PTR in my copy of the PSDK. I can confirm the same with the Windows 7 PSDK, although I do have an older SDK that has it just as ULONG. I imagine it perhaps changed when Windows went 64-bit. I'll submit a patch for this too. Cheers, -- Owen Rudge http://www.owenrudge.net/
Re: [3/5] imagehlp: Implement ImageAddCertificate
The virtual address is not necessarily the same as the disk offset. Actually, it seems that the security directory is one of the few places where a disk offset is intentionally used. Trying to compensate for the virtual address results in failure in this case. I have been amending the code to make it more robust however, and shall submit a revised version tomorrow. -- Owen Rudge http://www.owenrudge.net/
Re: Patch Tracker?
There's a new patch tracker? http://source.winehq.org/patches/ :) -- Owen Rudge http://www.owenrudge.net/
Re: [PATCH 4/5] comctl32/tests: Add further tests for IImageList
Owen, also please use more reasonable names for particular tests - dotest means nothing. I agree that the test names are not particularly descriptive. However, I chose those names to indicate that the tests match the existing DoTest functions. Perhaps both sets of functions should ideally given more descriptive names. Cheers, Owen
RE: Owen Rudge : comctl32: Add support for scrolling during marquee selection.
Hi Nikolay, > I've tested this a bit and it flickers like hell in some cases. Looks > like list requests redraw even if selection doesn't change (pointer is > still over already selected item). Hmm, yes, it seems it does still redraw if you move the mouse when selecting, although it shouldn't if the mouse is stationary. Trying with regedit does show it flickering a bit. I'll see what I can do to improve this. > - selection logic is wrong when some items are already selected before > marquee. On native it deselects those items, your code leave them as > is. This is visible in regedit (report mode listview) - select first > entry and start selection -> first item remains selected. This appears to be a bug that, as far as I can see, only shows up in report mode. Additionally, even if you don't select any item, the first item will be selected upon starting a drag. Items are cleared as intended when clicking, the bug seems to be that the first item in the list automatically selects itself. Again, I shall work on a patch for this. > - sometimes I get corrupted focus rectangle - moving pointer down > causes bottom side to clear, rectangle contains three side after that > (it could be a problem for my virtual box of course, or some embedded > video drivers, but I don't see a problem moving up for example). I'll have a play around and see if I can reproduce this. Cheers, Owen
Re: [PATCH 02/16] comctl32: Add basic structure for IImageList interface
is wrong because it changes offsets... but it also breaks those comments. (Can you put the vtable at the end?) In comctl32 v6, IImageList and HIMAGELIST are the same thing. See, for instance, http://msdn.microsoft.com/en-us/library/bb762185%28VS.85%29.aspx: "The IImageList pointer type, such as that returned in the ppv parameter, can be cast as an HIMAGELIST as needed; for example, for use in a list view. Conversely, an HIMAGELIST can be cast as a pointer to an IImageList." Obviously, the IImageList requires the vtable to be placed at the first offset. If any applications do rely on the (undocumented) imagelist structure, then these patches will indeed break them. Nikolay's solution would be a possibility, although it would complicate the code a bit. I would probably prefer to wait and see if we get reports of anything actually breaking, but I realise others may disagree there. Cheers, -- Owen Rudge http://www.owenrudge.net/
RE: [PATCH 16/16] comctl32/tests: Remove todo_wine from SHGetImageList tests
> This patch suggest that one of the previous patches in this series makes > the tests succeed or actually fail as they are inside a todo_wine(). The previous patch is the one that makes the tests succeed. I split the todo_wine removal from the tests due to the modifications being in separate parts of the source tree, although I realise now that means the tests will give an error for the prior commit. I've submitted an updated patch that merges the two. Cheers, Owen
Re: comctl32: Scroll listview when performing a marquee selection
Hi Nikolay, I don't think you need such duplication. Why not to use a single rectangle? Looks like you always offset it to listview origin, so these rectangle differ in offset only, that's why you introduced another iterator_* helper. If I'm right about that it's better to add another OffsetRect than consistently maintain two variables with same meaning. On second thoughts, having looked at this a bit, I think that if I weren't to have the two separate rectangles, I would still need to record the previous offset. In the MarqueeHighlight function, the old draw rectangle is invalidated (which has been offsetted by the previous call), and then the old absolute rectangle is used for the inversion of the selected items. Then the new rectangle is created, and is adjusted by the present offset. If we wanted to store only one rectangle, the previous offset - which would differ from the present offset - would also need to be stored, in order to cancel out the marquee draw and the item selection, which use different figures. So it's either two rectangles being stored, or one rectangle with the previous offset. So I may as well leave it as it is, I think. It might of course just be that I've been staring at this bit of code too long and have missed something obvious! I'll submit a new patch anyway that adds in a check in WM_KILLFOCUS to stop a marquee selection if focus is lost. Cheers, Owen
Re: comctl32: Scroll listview when performing a marquee selection
Hi Nikolay, I don't think you need such duplication. Why not to use a single rectangle? Looks like you always offset it to listview origin, so these rectangle differ in offset only, that's why you introduced another iterator_* helper. If I'm right about that it's better to add another OffsetRect than consistently maintain two variables with same meaning. I think I originally found myself implementing it in this manner, but ended up duplicating the offsetting code in a couple of locations while drawing/invalidating, so reworked it. However, the patch did grow a bit since then, a bit more than I think I expected it would, so it probably would be tidier to go back and simplify that again, with a couple of OffsetRect calls where appropriate. I'll have a look at tidying it up a bit more tomorrow. Cheers, Owen
Re: comctl32: Ensure listview control has focus when marquee dragging
Hi Nikolay, This doesn't look right. Try with ControlSpy and you'll see WM_SETFOCUS sent just after LButton pressed on client area (not on item, that's important). LButtonUp event used to set focus item was under mouse pointer and it's released without any mouse movements (or maybe drag threshold doesn't count). I've just tested this with ControlSpy on wine with my patch, NM_SETFOCUS is sent after LButton is released, when clicking on the client area. It is also sent when clicking on an item and releasing the pointer without any mouse movements, as you say. Possibly I'm misunderstanding what you're saying here, but I'm not sure I see where the problem is? Behaviour is, as far as I can tell, identical with my patch and without it, with the exception of course of the NM_SETFOCUS if the window does not already have focus. Cheers, -- Owen Rudge http://www.owenrudge.net/
Re: comctl32: initial theming tests (try 4)
Ah, I see, no, it won't link I think without static. Some time ago I thought about adding v6util.c back and move code here, I'm not very familiar with makefile generation but I think we could place this new v6util.c into C_SRCS section of test makefile (if it's allowed of course, but I think if it isn't we should enabled it someway). After that it will build as any other module does. I think when I tried that (using C_SRCS), the makefile simply didn't pick it up at all. You'd need to alter the makefile rules a bit higher up the chain I think for that to work. And of course, including v6utils.c in the same manner as the other source files will result in an empty test being added. Also, André, would it perhaps make sense for you to put your manifest generation/child process running code in v6utils.h along with the other manifest code? The code may well be useful for other tests that use the v6 controls (if not now then perhaps in th future, if they encounter the same issues you did). Cheers, -- Owen Rudge http://www.owenrudge.net/
Re: Owen Rudge : comctl32: Capture the mouse when performing a listview marquee selection.
Hi Nikolay, - open regedit and select any branch from tree - list will display a single item. I don't have this issue - I can select any branch, and the full list of items will appear, as expected, not just a single item. Then start marquee selection after selecting an item move pointer somewhere outside the list - try to left and up. It crashes after that for me in ListView code This is indeed a bug, I should have validated that the coordinates passed to the hit test were within the window bounds. I've submitted a fix for this, which also fixes the selection rectangle issue you mention. - list should be scrolled with selection rectangle; This isn't a bug as such, it's simply a feature that's not yet been implemented. :) - with regedit again - select something from tree and don't click in list, just start marquee. You'll see that item isn't selected at all. That's the same bug you mentioned in your previous e-mail - I've not yet submitted a fix for this, but shall do as soon as I can. Thanks for your testing, -- Owen Rudge http://www.owenrudge.net/
Re: Image List tests for comctl32 v6
It sounds like I need to investigate further, but no - I'm only talking about Windows. With crosstest, load_v6_module seems not to switch to v6 with regard to image lists. That's curious. What version of Windows are you using? Could you try applying my imagelist patches I linked to earlier and see if those tests work? For me at least, they all functioned correctly on both XP and Vista. -- Owen Rudge http://www.owenrudge.net/
Re: Image List tests for comctl32 v6
Hi Joel, I'm working on some tests to demonstrate some alpha-channel behaviour in comctl32 ImageLists. The problem is that this behaviour is only present in comctl32 v6, which of course you usually activate with an xml manifest. For the wine test suite we have a helper function, load_v6_module, that dynamically creates a manifest resource entry in the module, which seems to activate v6 behaviour. However, while this seems to activate v6 behaviour for controls, it seems not to for image lists - my tests work if I link a manifest into the test suite, but don't work via load_v6_module. Do you mean that the tests pass on Windows but not Wine when using load_v6_module, or that they don't pass on either platform? I used load_v6_module for some v6 imagelist tests (which may not yet be merged into Wine actually; I should probably check that and resubmit) and they worked fine. You may want to look at http://tinyurl.com/ybo28lt for instance. If the tests are working on Windows but not on Wine, the obvious reason for your tests failing would be that the required alpha channel support is not implemented. Cheers, -- Owen Rudge http://www.owenrudge.net/
Re: Owen Rudge : comctl32: Implement highlighting (marquee) selection support in listview.
Hi Nikolay, Didn't test it much yet, but few issues from a start: I'll look into these issues and try to submit a fix as soon as possible. Cheers, -- Owen Rudge http://www.owenrudge.net/
Re: [try 3] comctl32: Implement highlighting (marquee) selection support in listview
:). Now we have 3 different names for a single thing. D'oh! Let's try this one last time... ;) -- Owen Rudge http://www.owenrudge.net/
Re: [try 2] comctl32: Implement highlighting (marquee) selection support in listview
Hi Nikolay, Focus rectangle is an item focus bounds in current naming, so comment is a bit confusing here. Ah, yes, that seems sensible - I named it "focus rectangle" as that's what the API function was called, but of course the way it's used would lend itself better to different nomenclature. I'll amend that and send in an updated patch. Regards, -- Owen Rudge http://www.owenrudge.net/
Re: [1/2] comctl32: Implement highlighting (marquee) selection support in listview
Hi Nikolay, Why do you need this restoring code? I tried to replicate the way that Windows did the selections. Testing various manners of selection with Windows Explorer, that code was needed for a relatively specific scenario: If you're starting a selection box with some items already selected and Shift is pressed, then the items should, as you say, remain selected. If you then highlight some different items, but then un-highlight them before releasing the mouse button, the original items should remain selected. However, if in that time you highlight some of the already highlighted items, and then unhighlight them, they should not remain highlighted. Due to the fact that, with this code, I'm deselecting all the items (if neither shift nor ctrl are pressed) whenever the bounding box is altered, we obviously need to keep a record of how the items were highlighted before the selection was started. The alternative would be, I believe, to maintain a list of all the items that have become highlighted or de-highlighted during the selection process, so that they can be restored if need. This would probably be more efficient, at least with large numbers of items, but it would be more complex to implement. If need be, of course, I can try to reimplement the code in this manner. If you're starting selection box with some items selected they should be deselected if not Shift pressed and leaved untouched if Shift used. I don't see a reason to restore it - when you want to toggle selected state moving rectangle with Ctrl pressed you could just: LISTVIEW_GetItemState() and place inverted state with following LISTVIEW_SetItemState(). The issue with doing it this way is it would result in massive flickering every time you moved the mouse, unless I perhaps misunderstood you. Otherwise I guess there would have to be some way of tracking that the pointer is still within the hit area of a certain item, and has not moved out from that area, and hence the state should not be inverted again. Also such large cycles shouldn't be used if you could manage not to use them. See above - but that was indeed a concern of mine. I tested with some reasonably large collections of items (in the hundreds), and it did not seem noticeably slow, but I admit to not trying with thousands if items. Anyway this part: > ... is wrong. You can't do it that way cause selected state could also be cached at parent side with corresponding callback bit set (look at LISTVIEW_GetItemT()). I'll look into that, thanks. P.S. No need to split in two patches here, fist is useless if we can't see rectangle. I can of course combine the two patches. However, the first isn't actually useless on its own - even if the rectangle can't be seen, it is obvious where the selection box is due to the highlighting of the icons. :) Thanks for your comments! -- Owen Rudge http://www.owenrudge.net/
Re: [8/21] comctl32: Add basic structure for IImageList interface
Hi Detler, > Disassembling Windows Code is not allowed for Wine. > You should have know that and you should know the result. I'd just like to explain what it was exactly that I did, to possibly clear up any confusion. After submitting a set of patches, and receiving the comment that HIMAGELIST/IImageList should be the same, I was wondering about maintaining internal compatibility with the "old" structure, since it looked to me as if the existing HIMAGELIST structure had been specifically ordered to be compatible with Windows (see the commit at http://tinyurl.com/mfwl54 for instance - I presumed there was a reason behind this involving application compatibility). I then wrote a very simple little test program which took the existing Wine structural definition of HIMAGELIST, and then cast that onto the Windows structure, and performed a couple of tests to compare various values (eg, the "magic" value), to see if they were compatible. This was the extent of my "debugging" of the code, and I did not then make use of any of the seemingly-nonsensical values the program returned. The code in the header file in the patch (http://tinyurl.com/l4ffln) is the only part that was "affected" by this, and I simply moved the two structure members I had previous defined in another structure to the HIMAGELIST structure. I made no effort to further investigate or make compatible the structure with the native Windows structure. Additionally, at no time did I actively "disassemble" any Windows code, or do anything more than compare the first few values in the structure with this test program. I have since been made aware that even this is possibly unacceptable, and I understand that I may have made a mistake in doing so. Possibly I screwed up a bit, I accept that. I would just like to reiterate however that it was a very crude form of "debugging", as detailed above, and that no changes to the code were ultimately made as a result of it. No other code I have ever written has involved similar practices, and I would personally argue that this piece of code itself is for the largest part unaffected. I appreciate your comments, and hopefully this message will help explain things. It was obviously never my intention to put the project into jeopardy by replicating MS code directly (and, of course, this is something I have not done anyway). Cheers, -- Owen Rudge http://www.owenrudge.net/
Re: [8/21] comctl32: Add basic structure for IImageList interface
This layout is not officially published anywhere, however (nor is the new one), so I presume it will be acceptable to modify it to fit the vtable and reference count, etc, in? It might conceivably cause problems for any pre-comctl32-v6 app that tries to poke around the internals (not that they should be anyway), but I can't see any way around that other than having full WinSXS support implemented and having two separate versions of comctl32, as in Windows itself. Hmm, to clarify this, I think I've managed to answer my own question, in that I gather I should just make the changes to HIMAGELIST to incorporate the vtable, etc, into it, abolishing ImageListImpl. I also understand now that I shouldn't have written that little test program, as I did somewhat naïvely, to verify whether the internal structure on Windows matched that in the Wine header, as it could be construed as disassembly. This is a mistake I won't be making again. I'll make the appropriate changes tomorrow and re-submit if there are no other issues that need dealing with. Cheers, -- Owen Rudge http://www.owenrudge.net/
Re: [8/21] comctl32: Add basic structure for IImageList interface
You can't do that. HIMAGELIST should be the same thing as IImageList. Hmm. Looking at the HIMAGELIST/IImageList internals in a debugger on Windows, the layout appears to be entirely different to the HIMAGELIST layout defined in dlls/comctl32/imagelist.h (as you'd expect -the vtable, etc, needs accommodating). Judging by the comments in imagelist.h, the layout of the structure was designed to imitate the Windows layout (or an earlier version thereof). This layout is not officially published anywhere, however (nor is the new one), so I presume it will be acceptable to modify it to fit the vtable and reference count, etc, in? It might conceivably cause problems for any pre-comctl32-v6 app that tries to poke around the internals (not that they should be anyway), but I can't see any way around that other than having full WinSXS support implemented and having two separate versions of comctl32, as in Windows itself. Cheers, -- Owen Rudge http://www.owenrudge.net/
Re: [7/10] [try 2] comctl32: Add basic structure for IImageList interface
You can't do that, you need to at least implement stubs for the other methods. This is something I did in the following patch, mainly to reduce the size of the individual patches (based on the assumption all the patches would be committed at once anyway). I will recombine the patches into a single patch though if necessary. Cheers, -- Owen Rudge http://www.owenrudge.net/
Re: [1/6] comctl32/tests: Move v6 test initialisation routines into separate file
Not sure for the reason. But one thing I don't like is that this comctl32/msg.c (with no actual tests itself) is also shown on test.winehq.org. That is something that unfortunately does happen with v6util, too (v6util shows itself as another test in the test list). However, I thought it better than duplicating a significant amount of code - particularly since there was already a precedent set with msg.c. I guess it should be possible to simply move the offending files from CTESTS to C_SRCS in the Makefile, perhaps? That would hopefully stop those files registering as tests in their own right. I'll try it later. Placing the code in a header would I be another solution, albeit in my opinion a bit of a messy one. -- Owen Rudge http://www.owenrudge.net/
Re: appwiz.cpl: updated French translation
The installer-button I agree, but the (previously) Add/Remove button doesn't if I'm correct. It depends entirely on the installer in question. For instance, many MSI-based installers will let you add components, remove components, etc, from an application (eg, MS Office, Visual Studio). "Add/Remove" is probably still the best name for it, or "Modify/Remove" perhaps. The "modern"-style Add/Remove applet in Windows 2000 and later do display separate buttons for Modify, Repair and Remove (IIRC), for applications that support them. If I find a bit of time in the next couple of weeks, I may submit a patch to support that in the Wine applet. Cheers, -- Owen Rudge http://www.owenrudge.net/
Re: GSoC 2009
Hi Tim, I'd like to help out with wine during the summer of code. I have never done any dll development apart from a little messing with the windows research kernel, so I'd rather work on something else. If you have had exposure to Microsoft source code, then I believe I'm right in saying that you are not able to work on Wine, I'm afraid. (I seem to recall reading somewhere that it might be OK for you to work on, say, client apps if you've only seen kernel code, but I might be wrong - somebody else will no doubt know better.) I would love to work on control panel applets or the wine config tool as in the project ideas, however, theming and the test suite would be two other things I'd be interested in. It would be great if you could give me some pointers as to where my help would be appreciated most so I dig a little deeper into that for a couple of days before I write my proposal. I worked on the control panel last year, and was in the process of converting some winecfg pages to separate applets - indeed, there's some outstanding work in my git repository that needs finishing/merging (but I have had a lack of time to work on this year, sadly.) Assuming you aren't barred from contributing for the aforementioned legal reasons, then there is lots more work that can be done on improving Wine configuration and so on if you're interested in that. Theming and the test suite are also areas which could do with work though, and you may be able to make a more substantial project out of those areas. Cheers, -- Owen Rudge http://www.owenrudge.net/
Re: GSoC 2009 application sent
One more thing. Maarten doesn't have time to do this, so I would need someone as a backup admin to take over in case I'm hit by a bus or the like. I was acting as Maarten's backup last year, and I didn't have to do a thing. :) I'll also promise to be careful when crossing roads, it's just a safety measure to make sure I'm not the single point of failure. What kind of would be involved in being a backup admin? I could perhaps put myself forward for this - hopefully of course you won't be hit by any buses, though. ;-) Cheers, -- Owen Rudge http://www.owenrudge.net/
Re: GSoC 2009 coming up
> My biggest motivation for requiring weekly status updates is that in the past > years I had a hard time following the GSoC projects I was not involved with > directly. At WorldForge, we required weekly reports to the mentor at first > and then decided that the weekly reports should go to the developer mailing > list. That kept everybody informed what was going on. I would say this seems sensible - the weekly reports would not necessarily have to be greatly detailed, but I imagine it would help to keep students on track, and would enable the rest of the community to know what's going on with the students. From experience, I would say that I probably only tended to post on the lists when I had specific problems, or patches to submit, so a weekly update would have likely resulted in more interaction. Cheers, -- Owen Rudge http://www.owenrudge.net/
Re: Wine menu creation questions
> I have noticed that when wine creates a menu item (that for example, > on Ubuntu gets put in the Applications > Wine > Programs menu), the > command that gets written uses 'wine' as the program to run. This > means that you need to have Wine in your PATH and cannot use more than > one version of Wine. For example, if I wanted to use /opt/wine-1.0, > /opt/crossover and /opt/wine for different applications I cannot > access these correctly from the menu items created. Additionally, the > user experience (yes, I have been watching Owen's Google talk :)) is > that the application does not start (especially if the only version of > Wine is not on the PATH). > The solution to this is to add the full path to wine, e.g. > '/opt/wine-1.0/bin/wine' when generating the menus. Are there any > objections to this? This would probably seem sensible. It may cause some confusion for users if they do intentionally have multiple versions installed (knowing which items point to which version, etc), but unless one were to come up with some kind of "version switching" app that lets the user choose which version to run with, it would seem like it's the kind of thing we shouldn't be too bothered with. > Along similar lines, building on what Owen said in the talk that if > all goes well Jane user will not notice that she is using Wine to run > her Windows software: why is there an entry in the Applications > section that says 'Wine' (and why does it have the folder icon and not > the Wine icon)! It would be better if this said something like > "Program Files", replacing Wine > Programs -- this removes a level of > indirection and gives the user something that they are familiar with > and is more discoverable than 'Wine'. "Windows software" may be a better term than "Wine". "Program Files" wouldn't really make sense, since all the items in the Applications menu are meant to be program files. On the issue of whether we should keep the "Programs" subfolder, I guess you could transparently redirect things that try to create items there, and it would probably not cause too many problems. The current system though doesn't seem too bad. -- Owen Rudge http://www.owenrudge.net/
Talk at Google, "the Wine user experience"
Hey all, I've been a bit quiet as of late with uni work and so on, but figured I'd let you guys know that I was visiting Google in Mountain View on Thursday, and while there gave a tech talk on "Windows Meets Linux: the Wine user experience" - basically going over some of the issues with getting Wine out to users, ensuring a smooth experience for these users, and the challenges involves in this. It seemed to be well-received, and the talk is now up on YouTube: http://uk.youtube.com/watch?v=5E2HDQw4xmM Cheers! -- Owen Rudge http://www.owenrudge.net/
Re: Usability: WineCfg Part 1 -- Desktop Integration tab
> I was thinking of creating a control panel applet that invokes winecfg > to only display the appearance/theme tab. This is to allow the theme > selection command-line to share the code with the displaying of the > configuration UI. That would be harder to do using a control panel. Well, this is actually what I originally implemented during the summer - I wrote some code in winecfg to allow certain applets to be invoked depending on which arguments were passed, and had a desk.cpl as just a wrapper. I was advised that it'd be better just to move the code into a separate cpl entirely though, so that's what I did. The theory is that the Desktop control panel could of course grow to feature other desktop-related settings, too. > Sure. In that case, we could probably drop the "Folder" groupbox, > rename the tab "Folders" and just have the content of what is > currently within the Shell folders section here. Yep, that was pretty much my plan. > The winecfg code supports colour schemes. I know because I added some > fixes to support importing a Ubuntu Human colour scheme based theme > file :). Ah, good. :-) Then in theory this should be quite straightforward. > That way, winecfg and desk.cpl can be kept in sync with each other, we > can avoid copy/paste-style duplication and winecfg can be used to > provide the command-line functionality. Yes, this is something we were thinking about at WineConf - whether to have all the command-line features in one app (winecfg would seem sensible here), or whether to manipulate individual applets/programs (reg.exe, uninstaller.exe, etc) separately. My opinion is that it's probably best to keep them all in one app, and have that app import whatever logic is needed from individual applets, etc. > So, coordinating this: I'm happy to hold of on doing major changes in > this area until you land desk.cpl. I shall try to get this done over the next couple of weeks - I've not really had much time to think about wine recently due to a whole pile of academic work, but I'm hoping things might quieten down for at least a weekend so I can get some hacking done. :-) Cheers, -- Owen Rudge http://www.owenrudge.net/
Re: Usability: WineCfg Part 1 -- Desktop Integration tab
Hi all, > Reading up on the wineconf WWN issue, I noticed that it mentions > usability and winecfg. Therefore, I decided to dig up my RFC relating > to some ideas I had about winecfg that I sent to the list. Ah, lovely. This is something I'm planning on doing some work on, once I get a bit more free time. > == APPEARANCE == I've currently got some code that splits the Appearance and Theme sections of Winecfg out into separate control panels. I've not yet submitted this code (I hope to do so relatively soon), but your suggestions can certainly be incorporated into them. > 1. The "(No Theme)" text is replaced with "Wine Default". No theme > does not make sense -- there is a theme, it is just the default one > that Wine is using. That makes sense. > 2. The "Install theme..." button is now "Load...". > > 3. There is a "Save..." button to save a users theme modifications. > This makes it easier to create custom themes (especially colour-based > themes). That's a good idea, indeed. > 4. There is a divider between the theme and appearance settings. This > is to make it clearer that these are separate, but related. Currently, my control panel code has these split onto separate tabs. Perhaps some sort of text explaining the link between the two may be a good idea here. > 5. The "Item" list field always has an item selected (currently does > not select an item by default). This helps keyboard navigation. > > 6. The "Font" button has an elipsis at the end. This button brings up > another dialog, so should have an elipsis. Sensible suggestions indeed. It's little things like these that are important when designing a user interface, so thanks for picking those up. :-) > == FOLDERS == Just for information, my current plan is for this section to remain within winecfg. But your changes would certainly be good to implement, too. > 1. We may want to provide a set of colour themes (e.g. Windows 95, > Windows 2000, Ubuntu Human, ClearLooks, KDE Oxygen) to provide a > better experience for the user by default - i.e. not just have the "No > Theme" option initially. Well, the way Windows does it is to have themes, and colour schemes within those. For instance, the Windows Classic theme has all the old colour schemes that have been in Windows since Windows 3.x, whereas the Windows XP theme has the different variations of "blue", "silver", etc. The desk.cpl/winecfg code supports themes to a certain degree, but I don't think it has support for the colour schemes (from memory). This is something that I can work on once I get my basic code finished. > 2. We may want to be able to load a theme using the command line. > This would allow - for example - distributions to setup Wine with a > theme that matches their desktop, providing a more integrated > experience to the user. There are various configuration-based things that we want to be able to control by command line (appearance, uninstallers, etc) - this was brought up at WineConf in the desktop integration talk. It would probably be best to try to unify such things as much as possible - a command-line based extension to winecfg may be most sensible. This will require a bit more thinking, based on what sort of things we are going to want to configure. > 3. We may want to have a "Use the system's appearance" checkbox to > enable Gnome/KDE/other integration, so that the colours and/or > appearance is picked up from (and updated with) the native Linux > environment. This would go above the theme drop-down. Something like that may be sensible, or alternatively, have a "(No theme, use system appearance)" item in the theme drop-down (which would then disable the appearance tab, or replace it with a "to modify appearance, please use your window manager's configuration panel" message). Cheers, -- Owen Rudge http://www.owenrudge.net/
Re: OT [ReactOS-related] Win32s API dosumentation
> Does anyone know where to get copies of the Win32s documentation, such as > it > is? I don't know where to find a copy as such (perhaps tucked away in the old Microsoft FTP server, or linked to from a KB article?), but I do have a couple of versions here, shipped with various old compilers. Probably the more detailed file I have is came with the Win32 SDK shipped with Watcom C/C++ 10.6. You may be able to find a copy of it on eBay, I guess. Another version came with Borland C++ 4.51, in a self-contained .hlp file, although this only seems to apply to Win32s 1.1 (the help file is dated 1992-1993). According to http://wrc.gro.clinux.org/johnfindlay/lcc-win32/links.htm, Borland used to have a copy of those help files on its FTP server. They no longer seem to be there, but I've taken the liberty of uploading the old 1.1 programmer's guide to http://www.owenrudge.net/various/win32s.hlp. Note that Win32s 1.1 didn't support things like OLE 2.0, MAPI, ODBC, etc (which later versions of Win32s did, I believe), so getting the latest documentation would probably be best. Hope this helps, -- Owen Rudge http://www.owenrudge.net/
Re: Wineconf-er caught at security.
> I was stopped at security for carrying 'a wine bottle' through > security. Upon a brief inspection it was revealed that my > super-awesome crossover t-shirts had tripped the machine due to their > lusciously exquisite compressed shape. Whoops. I'll be sure to put mine in my hold luggage rather than my hand luggage, then. ;-) -- Owen Rudge http://www.owenrudge.net/
Re: Summer of code evaluations
Hi all, > I would like to request from the mentors to fill in the final evaluation > form and from the students to give a final write up: What went well? Did > you meet the goals you set? Did you have fun? Is there anything we can > do to make wines summer of code better and do you feel like you've > become part of the wine community? I'd say my project has gone quite well. I've completed the main objectives of my project, including fixing the shell namespace implementation of Control Panel, improving the built-in control panel, and working on some new control panels to improve Wine's configuration options (Add/Remove Programs, plus a new Desktop control panel that I'm just tidying up ready to submit this week). While I will have university-related things to carry on with in September, I'm not intending to disappear completely - I'm hoping to split off and tidy up the multimedia settings in winecfg to its own control panel, too, and then tidy up winecfg a bit, making it more logical by restricting it to panels that are specific to Wine itself. So hopefully you'll still see me around a bit. :-) Overall, I rather enjoyed Summer of Code, and learnt a lot about how to go about getting things done in an open source environment. Thanks to all, particularly my mentor Juan, for help and support along the way! Cheers, -- Owen Rudge http://www.owenrudge.net/
Re: [10/10] [try 5] appwiz.cpl: Gather extra information for SupportInfo dialog
> 3 files changed, 86 insertions(+), 0 deletions(-) I'm just wondering if there's a reason this patch wasn't committed with the other appwiz patches? The patch applies cleanly to the current git master. If there's anything obviously wrong with it that I've not spotted, please do let me know so I can fix it. Cheers, -- Owen Rudge http://www.owenrudge.net/
Re: [3/9] shell32: Load Control Panel title from resources
> The indentation is wrong, looks like you are using the wrong tab size. I've resubmitted the patches with the indentation matching each .rc file. Not all of the .rc files have the same indentation, and even within them they are inconsistent, but my lines should now be consistent with most of it. (Note also that the "New Folder" line in many of the .rc files, which is above IDS_CPANEL_TITLE, is wrong in most of them.) -- Owen Rudge http://www.owenrudge.net/
Re: [1/3] [try 3] appwiz.cpl: Add GUI for Add/Remove Programscontrolpanel
> The larger a chunk is the harder a review is. I think a patch doesn't > necessarily have to have a "sensibly" functional result. E.g. you could > start off with a very skeleton control panel, maybe icons which don't do > anything. Sure, it's not very functional, but it is very easy to review. > Likewise, the next step could add a do-nothing dialog ... and so on. Yes, this is more or less what I was planning to do now. I'll have a rumble around and see what I can come up with. -- Owen Rudge http://www.owenrudge.net/
Re: [1/3] [try 3] appwiz.cpl: Add GUI for Add/Remove Programs controlpanel
> Perhaps you could split them into smaller parts? Well, I'm not sure how much smaller I can realistically split them, at least, if the individual parts are to be functional, although I guess the first and second ones (which are the largest) could be split up a little more if that is the reason they weren't accepted. -- Owen Rudge http://www.owenrudge.net/
Re: [1/3] [try 3] appwiz.cpl: Add GUI for Add/Remove Programs controlpanel
> OK, seems there was a small bug in the last patch that could cause > crashes, plus I'd forgotten to include wine.inf.in. I'm pretty sure this > one should be fine now, at least. Sorry for all the messages. ;-) Just wondering if anybody has any feedback on these, as I notice they've not been accepted into the last couple of rounds of commits. If there's anything glaringly wrong with it that I haven't spotted, or another reason why they've not made it into the codebase yet, please do let me know. :-) Thanks, -- Owen Rudge http://www.owenrudge.net/
Re: [2/3] appwiz.cpl: Read uninstallable applications from registry, add to list.
> Seems to be a copy-paste Well spotted, apparently both my mentor and I managed to miss this! Shall get that sorted now... -- Owen Rudge http://www.owenrudge.net/
Re: Slovak translation for shlwapi
Hi Kario, > btw. if you want that i send to you diff/patch file, > please write me the full command for git You should avoid sending messages in HTML to the mailing lists. Send them in plain text instead. With regards to generating a patch, see this wiki page: http://wiki.winehq.org/GitWine#head-f7a29e7ed999b5924748a60c5a1cd4a019032d26 Regards, -- Owen Rudge http://www.owenrudge.net/
Re: Midterm evaluations for summer of code students
> Also, I would like to hear from all students now a reflection. What > went well, and what didn't, and what did you accomplish so far? :-) My project so far has gone fairly well, and I'd say I'm currently just a little ahead of schedule, which I'm pleased about. The first part of the project was to get the Control Panel working in the shell namespace, and it turned out that a lot of the work had already been done, it just wasn't glued together properly. It took me a little while to figure out what needed doing, but I managed to work it out and it made it into Wine 1.1. :-) I'm now moving onto developing some new control panel applets, and looking at ways to improve winecfg. I've been working on an Add/Remove Programs applet for the past week or so, which is now more or less complete, and will likely be submitted to wine-patches soon. I'm also thinking about what I'm going to do with winecfg, with my thinking that the bits that are not configurable on a per-application basis (desktop appearance and sound, mainly) can be moved into/reimplemented in new control panels. So that'll be my main focus over the next few weeks. The biggest challenge for me now is probably working out a "work plan", and making sure I set targets for myself, to ensure I can try to get as much done and use my time efficiently. Other than that, I've learned a lot about the general process of Wine development, and have quite enjoyed things so far. The majority of my code can be found at http://repo.or.cz/w/wine/gsoc_cpanel.git. Cheers, -- Owen Rudge http://www.owenrudge.net/
Re: [UPDATE] shell32: Check registry entry for cpl files (in standard control panel)
> While they may be registered there as well, I'm pretty sure that some > versions of Microsoft Office register control panel applets in the key > I mentioned. Well, yes - what I meant is that the key at HKLM\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\IniFileMapping\control.ini maps any requests for control.ini, section [mmcpl] to HKCU\Control Panel\MMCPL. -- Owen Rudge http://www.owenrudge.net/
Re: [UPDATE] shell32: Check registry entry for cpl files (in standard control panel)
> Control Panel applets can also be registered in "HKCU\Control > Panel\MMCPL". Well, technically, they would be registered in the [mmcpl] section of control.ini, which is then mapped in the registry (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\IniFileMapping\control.ini) to the appropriate registry entry. However, as far as I can tell, Wine's profile string functions don't currently support INI file mapping (there's a patch on the bug tracker, but it was never accepted, it seems), so if any old application did try to write to the control.ini file, it wouldn't end up in the registry. I could add a check for CPL entries in control.ini if desired using the GetPrivateProfileSection function, and if/when Wine does support INI file mapping, the code wouldn't then need updating to point to the "right" place. -- Owen Rudge http://www.owenrudge.net/
Re: shell32: Check registry entry for cpl files (in standard control panel)
Hi Juan, > Style nit: get rid of that blank line. > Prefer WCHAR strings to char strings. You can declare a string > constant at the beginning of the function, next to wszAllCpl. > Style nit: put Control_RegisterRegistryApplets above Control_DoWindow > to avoid adding the prototype at the top of the file. I've submitted an updated patch to wine-patches now. Thanks. -- Owen Rudge http://www.owenrudge.net/
Re: winecfg.cpl: Add new control panel applet for winecfg
>> 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 http://www.owenrudge.net/
Re: winecfg.cpl: Add new control panel applet for winecfg
> 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, -- Owen Rudge http://www.owenrudge.net/
Re: winecfg.cpl: Add new control panel applet for winecfg
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, -- Owen Rudge http://www.owenrudge.net/
Re: winecfg.cpl: Add new control panel applet for winecfg
> 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, -- Owen Rudge http://www.owenrudge.net/
Re: winecfg.cpl: Add new control panel applet for winecfg
> 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. -- Owen Rudge http://www.owenrudge.net/
Re: winecfg.cpl: Add new control panel applet for winecfg
> 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 http://www.owenrudge.net/
Re: winecfg.cpl: Add new control panel applet for winecfg
> 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! -- Owen Rudge http://www.owenrudge.net/
Re: Control panel developments and winecfg
> The biggest reason your patch was not accepted is because you can not separate most of the settings from application tab. This makes it useless to put only separate tabs into > control panel applets. You're perhaps confusing pure_evil's patch with my proposal. My proposal would only split up the tabs that are not application-specific, which are the Desktop Appearance and Sound portions. These would become accessible through standard control panels, with the rest of the tabs remaining in winecfg normally. Regards, -- Owen Rudge http://www.owenrudge.net/
Control panel developments and winecfg
Hi all, As some of you may know, my Summer of Code project is working on control panel support for Wine, and writing some new control panels. Part of my plan was also to split bits of winecfg into their own control panels, specifically, the Appearance section of the Desktop tab, and the Sound tab. Now, I realise people will have got quite used to winecfg working the way it does, so I'm wondering what people will think of this, or if it's better to leave winecfg alone. Due to lots of shared utility functions in winecfg, I've currently implemented a bit of code, similar to that submitted by pure_evil @ mail.bg some months ago, which enables winecfg to be executed with a combination of parameters to display a combination of tabs (see http://tinyurl.com/5yua77), as opposed to physically moving the code into a separate file. winecfg would then be called by a .cpl file to display the appropriate tabs. The default setting for winecfg, then, would be to display all tabs except for the Desktop and Sound tabs, which would be accessible as separate icons in the control panel. What do people think of this? I can imagine there may be a bit of resistance, so I figured it'd be best to ask now, before I do any more work on it. ;-) My intention for the rest of my project is also to working on assorted other control panels, however, which don't overlap with winecfg's functionality! Cheers, -- Owen Rudge http://www.owenrudge.net/
Re: SOC 2008 Projects Announced
> Could the students come forward and say something about themself? Hello all. :-) I already introduced myself a while ago when I was writing my proposal, and I'm very pleased to see that it was accepted! I'm a 3rd year comp sci student at the University of St Andrews in sunny(!) Scotland. Looking forward to getting to work on Wine, although I've got exams and a junior honours project to get finished first, alas! I've got various ideas floating around my head and have figured out how I think I'm going to start tackling the project, so hopefully I'll be all ready to go when exams are out of the way. Cheers, -- Owen Rudge http://www.owenrudge.net/
Re: GSOC proposal - control panel
> What I and the other Ubuntu UI people would really like to see is the > ability to uninstall Wine programs from within gnome-app-install (The > Gnome applet the user interacts with after selecting > Applications->Add/Remove). > > The UI is a fairly intuitive step - just add a "Windows Applications" > category and list the installed Wine apps on the right. Once that's > done, we don't need a special Wine program for uninstalling anymore, > since we can expand the functionality in a similar place where the user > could reasonably expects to find it. This sounds somewhat like it'd be a bit of a side project to my intended plan. Implementing such a "Windows Applications" category wouldn't involve much more than interating through the registry, and then calling wine on the appropriate uninstaller .exe. I would still suggest a proper Control Panel namespace for Wine would be best. Implementing functionality to embed the Wine control panel into other X windows would then be possible too, although looking at the patch submitted a few months ago, I fear the implementation of it may not be the most tidy thing. The idea of a side project implementing a basic set of reusable functions to iterate through the registry to retrieve application details (for Add/Remove Programs, at least) may be better. Regards, -- Owen Rudge http://www.owenrudge.net/
Re: GSOC proposal - control panel
> No dice. > CPls are DLLs that export a function - CPlApplet(). > winegcc coughs on dllexport. - not implemented. > I've been hacking at it for days on end now. > Result: CPl can be compiled under windows and run under wine. CPls > compiled > with winegcc don't export that function => not treated as control panel > applets. I'm sure it must be possible to export routines in Wine .dll.so libraries via .def files or similar - whether GetProcAddress supports Wine "DLLs" is the issue. Even if for some reason it's not possible, I don't see that it would be impossible to detect that the .cpl file is actually a Wine DLL, and to use the appropriate dlopen-type routines to read it. -- Owen Rudge http://www.owenrudge.net/
Re: GSOC proposal - control panel
Hi Steven, > I don't really know if we want to just focus on applets or if we > should not aim for having this project provide better integration with > the native desktop. As far as I understand there is some > infrastructure work that will need to be done in shell32 as I don't > think we fully implement the entire Control Panel shellname space. I > expect implementing this properly will take a good bit of time. What > would be cool would be if we fully supported the namespace so that > when you called control.exe it loaded the control panel window and > that could be embedded in a GTK or QT window for use by native > applications. There was a patch floating around on wine-patches a few > months back to allow for embedding a Win32 Wine window inside of an > existing X window that should do the trick. Implementing the proper Control Panel namespace would certainly make the control panel section of the project a much longer one. My initial thoughts were that it may be an easier task to implement the Control Panel in a more old-fashioned style of simply having a list view into which the control panel icons were placed - this would certainly provide a sufficient interface for accessing the control panel. However, it probably would be better in the long run to implement things "properly", and at the very least getting Control Panel integrated with the shell namespace. Integration with native applications certainly looks as though it would provide an added challenge to that project, but is an interesting idea that could work quite nicely. > As far as migration of the stuff in winecfg and other programs go, I > think starting with the Add/Remove applet is a good. I don't think it > would be too hard to take all of the current logic in > wine/programs/uninstall and wrap it in a proper applet. We want to > make sure that we don't introduce any sort of regression when we make > the switch over so reusing that code would be a good place to start. Indeed, my plan was to make use of appropriate Wine tools where they existed, such as in the case of the uninstaller, and flesh them out into fully-featured control panel applets. > So to recap, (this just goes for for me) I think the project should be > laid out as follows > > 1. A fully working Control Panel Namespace > 2. The ability to embed the Control Panel window in a native window > 3. Have a collection of applets to configure wine This sounds like a pretty decent way of going about things. Number 2 was something I hadn't particularly considered doing initially, but I'll have a look for the patch that was posted recently and see what I think about it and how much work is likely to be involved. Cheers, -- Owen Rudge http://www.owenrudge.net/
GSOC proposal - control panel
Hi everyone, I'm intending to apply for a Google Summer of Code placement working on the Wine control panel support. My main intention is to work on a proper Control Panel application for Wine that accepts standard .cpl files, and turn winecfg's configuration sections into appropriate control panels. (I notice that pure_evil @ mail.bg has been doing some work on this - if I were to get accepted to work on this, then I would like to continue his line of work, or assist him with it.) However, as I don't believe that project alone would necessarily take up an entire summer, my intention would also be to work on some new control panel applets for Wine. The examples given on the GSOC wiki pages (basic desktop/screen resizing, general network information, and font details) would be good applets for me to implement, but I would also be interested in working on some other applets, such as an Add/Remove Programs applet, or a Multimedia applet. Obviously, there wouldn't necessarily be time to implement all of these, so my intention would be to get the main control panel and basic Wine control panel applets from winecfg working well first, and then look at other applets that could be implemented. I've developed applications and, indeed, Control Panel applets for Windows for many years now (I started programming using the Windows API when I was 12!), so I feel confident that this is a task I would be able to handle. I believe that a good configuration interface for Wine that supports third-party control panels is something that would be very useful for end-users. If anyone has any comments or suggestions regarding my proposal, I'd very much appreciate any feedback. Regards, -- Owen Rudge http://www.owenrudge.net/
