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
On Tue, Mar 20, 2012 at 9:43 AM, Jacek Caban <jacek(a)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. J. Leclanche (Sorry for the double post, Jacek)
On 03/20/12 10:48, Jerome Leclanche wrote:
On Tue, Mar 20, 2012 at 9:43 AM, Jacek Caban <jacek(a)codeweavers.com <mailto:jacek(a)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?
I don't believe in success of such project for GSoC. We've already rejected applications for this (at least one last year). I'd much rather see students send applications for other proposals. That's just my opinion, if others feel differently, we may keep it.
It would go a long way towards excellent desktop integration.
Agreed, but that doesn't make it a good project. Cheers, Jacek
On 3/20/2012 12:48, Jerome Leclanche wrote:
On Tue, Mar 20, 2012 at 9:43 AM, Jacek Caban <jacek(a)codeweavers.com <mailto:jacek(a)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.
J. Leclanche
(Sorry for the double post, Jacek)
On Tue, Mar 20, 2012 at 11:02 AM, Nikolay Sivov <bunglehead(a)gmail.com>wrote:
On 3/20/2012 12:48, Jerome Leclanche wrote:
On Tue, Mar 20, 2012 at 9:43 AM, Jacek Caban <jacek(a)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... J. Leclanche
On 3/20/2012 16:45, Jerome Leclanche wrote:
On Tue, Mar 20, 2012 at 11:02 AM, Nikolay Sivov <bunglehead(a)gmail.com <mailto:bunglehead(a)gmail.com>> wrote:
On 3/20/2012 12:48, Jerome Leclanche wrote:
On Tue, Mar 20, 2012 at 9:43 AM, Jacek Caban <jacek(a)codeweavers.com <mailto:jacek(a)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
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: Theming - there are few things that could be done here: 1. Implement comctl v6 controls. Probably way too much for one GSoC project 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. 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. Vitaliy.
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
Hey Jacek, Op 20-03-12 10:43, Jacek Caban schreef:
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
Agreed, would like to add cmd parser to that list too. ~Maarten
On 3/20/12 07:22, Maarten Lankhorst wrote:
Agreed, would like to add cmd parser to that list too.
~Maarten Why is this? Does cmd sound like a bad project?
FWIW I was planning on improving cmd as my GSoC project, and I've talked to Dan Kegel about it - there's been no protests (only support) thus far on that front, so it at least seems doable. In terms of being valid... if cmd were improved it would allow firefox and chromium to be built under wine (if reg was also improved a bit, but that might also fall under my project...) Alex -- Not sent from my iPhone, Windows Phone, or Blackberry; Just an old-fashioned e-mail client.
Hello Alex, On 03/20/2012 05:17 PM, HolyCause wrote:
On 3/20/12 07:22, Maarten Lankhorst wrote:
Agreed, would like to add cmd parser to that list too.
~Maarten Why is this? Does cmd sound like a bad project?
FWIW I was planning on improving cmd as my GSoC project, and I've talked to Dan Kegel about it - there's been no protests (only support) thus far on that front, so it at least seems doable. Writing a proper cmd parser is doable. Getting that into Wine in small and incremental patches will be hard as a big drop in patch is not an option.
In terms of being valid... if cmd were improved it would allow firefox and chromium to be built under wine (if reg was also improved a bit, but that might also fall under my project...) Improving cmd should be fine as a project. Hoping to get the parser fully replaced during that isn't.
bye michael
michael,
Getting that into Wine in small and incremental patches will be hard as a big drop in patch is not an option. I don't know if I understand "a big drop in patch"... Do you mean committing all of the changes as one, large patch?
On that note, are GSoC projects done in smaller, individual patches or are large chunks (say an entire project) integrated at once? I apologise for my newb-ish questions with regards to wine's processes, but I guess I have to learn somehow ;)
Hoping to get the parser fully replaced during that isn't. I hope I didn't imply that I wish to do this... That seems like quite a daunting task indeed. My project goals(*) line up as far as getting certain products (chromium, firefox) to build using wine; or at least, isolate the issue to non-cmd areas as others issues may arise after the cmd related issues are fixed.
Alex (*) Currently. The actual proposal might change between now and submission date depending on what else I can uncover in the coming week. -- Not sent from my iPhone, Windows Phone, or Blackberry; Just an old-fashioned e-mail client.
On 03/20/12 23:15, HolyCause wrote:
michael,
Getting that into Wine in small and incremental patches will be hard as a big drop in patch is not an option. I don't know if I understand "a big drop in patch"... Do you mean committing all of the changes as one, large patch?
On that note, are GSoC projects done in smaller, individual patches or are large chunks (say an entire project) integrated at once?
I apologise for my newb-ish questions with regards to wine's processes, but I guess I have to learn somehow ;)
Patches to Wine should be possibly small and incremental. Otherwise they are hard (or almost impossible) to review. That's a problem in this case. It might be very tricky to split rewrite of the parser and a good plan is required. Perhaps there would be needed some temporary hacks that would allow mixing new and old parsing code while it's rewritten part by part. I think such a project would be good, as long as student is prepared to deal with this.
Hoping to get the parser fully replaced during that isn't. I hope I didn't imply that I wish to do this... That seems like quite a daunting task indeed. My project goals(*) line up as far as getting certain products (chromium, firefox) to build using wine; or at least, isolate the issue to non-cmd areas as others issues may arise after the cmd related issues are fixed.
(I've never worked on cmd myself, so I may be missing some details here). The point is that proper cmd parser implementation is what cmd needs the most. The more code you add before the rewrite, the harder rewrite will be. On the other side, I believe that after rewrite, fixing existing bugs should be easier and cleaner solution. So ideally, parser should be rewritten first, before doing more substantial improvements. That obviously doesn't mean that improvements to cmd should not be accepted. Everyone is free to work on whatever he wants, and I'd really like to be able to compile Firefox under Wine, but I'm not sure we want to promote larger tasks on cmd, such as GSoC project, before parser work is done. Cheers, Jacek
Jacek,
Perhaps there would be needed some temporary hacks that would allow mixing new and old parsing code while it's rewritten part by part. I think such a project would be good, as long as student is prepared to deal with this.
I'm not sure we want to promote larger tasks on cmd, such as GSoC project, before parser work is done.
These statements seem contradictory, but I might be missing something. Could you please elaborate? Alex -- Not sent from my iPhone, Windows Phone, or Blackberry; Just an old-fashioned e-mail client.
On 3/21/12 6:48 PM, HolyCause wrote:
Jacek,
Perhaps there would be needed some temporary hacks that would allow mixing new and old parsing code while it's rewritten part by part. I think such a project would be good, as long as student is prepared to deal with this.
I'm not sure we want to promote larger tasks on cmd, such as GSoC project, before parser work is done.
These statements seem contradictory, but I might be missing something. Could you please elaborate?
In the second quote I was talking about projects related to cmd that are not parser rewrite. I think rewriting parser is a good project (with the big warning that coding is not the only chalenge here, getting it committed is tricky). The mixing that I was talking about in the first quote is that, if possible, new parser should be integrated incrementally, so there would be a mix of old and new code in a middle of work. Cheers, Jacek
--- On Tue, 20/3/12, HolyCause <holy.cause(a)gmail.com> wrote:
On 3/20/12 07:22, Maarten Lankhorst wrote:
Agreed, would like to add cmd parser to that list too.
~Maarten Why is this? Does cmd sound like a bad project?
FWIW I was planning on improving cmd as my GSoC project, and I've talked to Dan Kegel about it - there's been no protests (only support) thus far on that front, so it at least seems doable.
In terms of being valid... if cmd were improved it would allow firefox and chromium to be built under wine (if reg was also improved a bit, but that might also fall under my project...)
There are one of two bugs I filed which has something to do with cmd (or cmd built-in's). One of them is an append-file issue - I think copy file1+file2 file3 does not do what it does in windows. (joining file1 and file2 and put into file3) - but instead, file2 is ignored, or something. Just thought if you are doing cmd things, you might take an interest. That's the sort of things which are do-able in less than a few months for a student.
--- On Tue, 20/3/12, Hin-Tak Leung <htl10(a)users.sourceforge.net> wrote: <snipped>
FWIW I was planning on improving cmd as my GSoC project, and I've talked to Dan Kegel about it - there's been no protests (only support) thus far on that front, so it at least seems doable.
In terms of being valid... if cmd were improved it would allow firefox and chromium to be built under wine (if reg was also improved a bit, but that might also fall under my project...)
There are one of two bugs I filed which has something to do with cmd (or cmd built-in's). One of them is an append-file issue - I think copy file1+file2 file3 does not do what it does in windows. (joining file1 and file2 and put into file3) - but instead, file2 is ignored, or something.
Just thought if you are doing cmd things, you might take an interest. That's the sort of things which are do-able in less than a few months for a student.
Oh, I forgot to add that the bug shows up running ghostscript (or ghostpdl?)'s build under wine - with M$ VC++, the usual way it is built for windows. So it might be an issue which also affect other software builds, which would naturally fall within what you are planning to do. (are firefox/chromium preferably built with MS VC++ or mingw?)
participants (9)
-
Hin-Tak Leung -
Hin-Tak Leung -
HolyCause -
Jacek Caban -
Jerome Leclanche -
Maarten Lankhorst -
Michael Stefaniuc -
Nikolay Sivov -
Vitaliy Margolen