Updating GSoC proposal

[Jacek Caban]

On 03/20/12 14:14, Vitaliy Margolen wrote:
> On 03/20/2012 03:43 AM, Jacek Caban 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
>>
>
> I don't think we should remove all of them. These projects should
> probably stay:

I think that GSoC projects should not require design decisions for large
scope or core parts. These are tricky to get into Wine, esp. for
students not experienced in Wine. With that in mind:

>
> Theming - there are few things that could be done here:
> 1. Implement comctl v6 controls. Probably way too much for one GSoC
> project

comctl32/user32 duplication of controls needs to be solved first here.
Once we have it in place for some controls and work is needed for more,
it may be a good GSoC project. Until then, chances that a student can
accomplish it are pure.

> 2. Interact with host desktop environment to sync at least colors.
> This one is more of a research then codding. Plus convincing AJ that
> we want that code in. Also questionable if it can be done in pure C.
> Of course it can be just a standalone program.

It looks to me like no one knows exactly how we want this implemented.
Thus we can't expect student on GSoC to know...

>
> Sandboxing - a great project for a security researcher. However the
> scope of it can be huge.
>
> Thin app - depends on how to look at it:
> 1. Not directly helping Wine but along the same lines as Windows'
> wined3d.
> 2. Needs some tricky functions implemented.
> 3. Needs a way to build and incorporate win-pe wine dlls into Wine.
> This is a tough one but helps some some applications as well.

I don't think these would result in any code committed to Wine.

IMO ideal projects are well separated chunks of missing functionality.
None of these are such.

Cheers,
Jacek