On 3/20/2012 16:45, Jerome Leclanche wrote:
On Tue, Mar 20, 2012 at 11:02 AM, Nikolay Sivov <bunglehead@gmail.com mailto:bunglehead@gmail.com> wrote:
On 3/20/2012 12:48, Jerome Leclanche wrote:On Tue, Mar 20, 2012 at 9:43 AM, Jacek Caban <jacek@codeweavers.com <mailto:jacek@codeweavers.com>> wrote: Hi all, GSoC is starting this year and, if we want to have good applications, we need to update our proposals. Usually the most attention is directed into adding new ones, while we keep obviously bad (or just bad IMO) proposals on the page. I'm planning to remove following project proposals: Security - implement sandboxing Theming - Implement Wine theming support NTDLL - support performance registry keys Winelib Aware Scons (or cmake) Cleanup Winemenubuilder to support generating Application Bundles on Mac OS X Wine-based application virtualization If someone knows a reason to not remove them, please reply. Cheers, Jacek Why remove theming support? It would go a long way towards excellent desktop integration.I'm not sure how it helps with desktop integration actually, you're probably referring to using host system looking alike control theme to be used by win32 application? The problem with getting this work properly is that you need to touch loader most likely (so kernel32/ntdll), duplicate all user32 controls inside comctl32 including tests, make them register themselves when application really wants to. And of course fix uxtheme bugs. So it's quite a lot of work, and not really explored part actually. And in my opinion this accomplishes nearly nothing, except one nice thing - some applications want new comct32 v6 controls that are formerly implemented in user32, and it's not right to fix that in user32 code now, cause native user32 doesn't provide new buttons styles for example. It's not really related to theming support, it's all about use32/comctl32v6 coexisting.Yes, something like that. Googling for it brought this topic up: http://www.pclinuxos.com/forum/index.php?topic=91452.0 It's how GTK apps are themed under Qt environments; with GTK themes cloning Qt themes. Oxygen does it really well, I'm sure it would be possible to create an oxygen-for-windows theme. Of course this is quite far. I think the whole thing should be split into smaller projects involving better desktop integration to be honest.
Adding to that list: The ability to use native file pickers over Wine's win32 ones; at least the GTK one (Qt would be in C++ so I don't know if AJ would even consider it). With, of course, a configure option such as --with-file-picker=native|gtk (native by default). I don't know how much work this would involve, at least converting the data back and forth between win32 and gtk; but I'm not even sure if it's possible to use the file pickers without a GtkApplication. Just throwing it out there...
I don't think it's really possible to replace common dialogues with something completely different, just few problems:
- application expects not only particular API for that dialogues but also certain control layout, to add its own controls for example. It's not possible to guarantee that when you don't fully control a dialogue; - if you want a file picker it should be based on some shell folder internally, so you can explore you virtual c: drive and everything else you added on top of default wine config, I'm not sure how deeply you can interact with native file pickers to do that; - why GTK ones? or Qt ones? every toolkit will need its own implementation to work with, and no way to guess which toolkit user wants exactly. So it's not really an integration.
J. Leclanche