Re: Updating GSoC proposal

[Steven Edwards]

On Tue, Mar 20, 2012 at 2:41 AM, Jacek Caban  wrote:
>
> Cleanup Winemenubuilder to support generating Application Bundles on Mac
> OS X


There is a much better version of my patch for this on the morth-wine tree
on GitHub. It just needs to be broken up and submitted by someone that
cares. If a SoC student shows up with interest, please send them my way, I
would be happy to help point them in the right direction. Our code works, I
just don't have the time to break it up and get it in the tree.

-- 
Steven Edwards

"There is one thing stronger than all the armies in the world, and that is
an idea whose time has come." - Victor Hugo

Re: Updating GSoC proposal

[Jacek Caban]

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

Re: Updating GSoC proposal

[HolyCause]

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.

Re: Updating GSoC proposal

[Jacek Caban]

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

Re: Updating GSoC proposal

[Hin-Tak Leung]

--- On Tue, 20/3/12, Hin-Tak Leung  wrote:


> > 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?)

Re: Updating GSoC proposal

[Hin-Tak Leung]

--- On Tue, 20/3/12, 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.
> 
> 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.

Re: Updating GSoC proposal

[HolyCause]

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.

Re: Updating GSoC proposal

[Michael Stefaniuc]

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

Re: Updating GSoC proposal

[HolyCause]

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.

Re: 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 > wrote:


On 3/20/2012 12:48, Jerome Leclanche wrote:

On Tue, Mar 20, 2012 at 9:43 AM, Jacek Caban
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

Re: 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

Re: Updating GSoC proposal

[Jerome Leclanche]

On Tue, Mar 20, 2012 at 11:02 AM, Nikolay Sivov wrote:

>  On 3/20/2012 12:48, Jerome Leclanche wrote:
>
>  On Tue, Mar 20, 2012 at 9: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
>>
>> 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

Re: Updating GSoC proposal

[Maarten Lankhorst]

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

Re: Updating GSoC proposal

[Vitaliy Margolen]

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.

Updating GSoC proposal

[Jacek Caban]

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

Re: Updating GSoC proposal

[Nikolay Sivov]

On 3/20/2012 12:48, Jerome Leclanche wrote:
On Tue, Mar 20, 2012 at 9: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

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)

Re: Updating GSoC proposal

[Jacek Caban]

On 03/20/12 10:48, Jerome Leclanche wrote:
> On Tue, Mar 20, 2012 at 9: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
>
> 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

Re: Updating GSoC proposal

[Jerome Leclanche]

On Tue, Mar 20, 2012 at 9: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
>
> 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)

Updating GSoC proposal

[Jacek Caban]

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