Updating GSoC proposal

[Nikolay Sivov]

On 3/20/2012 16:45, Jerome Leclanche wrote:
> On Tue, Mar 20, 2012 at 11:02 AM, Nikolay Sivov <bunglehead at gmail.com 
> <mailto:bunglehead at gmail.com>> wrote:
>
>     On 3/20/2012 12:48, Jerome Leclanche wrote:
>>     On Tue, Mar 20, 2012 at 9:43 AM, Jacek Caban
>>     <jacek at codeweavers.com <mailto:jacek at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20120320/687ef68d/attachment.html>