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