Re: GSoC proposal
--- On Sun, 25/3/12, Cheer Xiao wrote: > 2012/3/25 Hin-Tak Leung : > > --- On Sun, 25/3/12, Cheer Xiao > wrote: > > > > > >> So according to you and the thread Jerome > mentioned, uxtheme > >> is one of > >> the more tricky and less rewarding areas; so I will > set it > >> aside for > >> the moment and work on the IME proposal instead. > > > > > > There is no reason why you cannot submit two proposals, > if you are interested in two areas. You do not get penalized > for doing that, other than your own time of preparing two > proposals, which is twice the preparation work. > > > > In fact it is quite common for GSoC students to apply > for more than one project under different/same > organization. > > > > From the organization's point of view, it may be a good > decision to give the project to the strongest candidate if > there are multiple students applying to the same area; or > not to take up any student for lack of interests (from > mentors); in which case you might be still be taken up and > assigned to your "2nd" choice project. > > > > (poor applications - showing no understandings of the > background technology, etc - are rejected, so in that sense > you are penalized if you cannot devote enough time to your > proposal(s), if you divide your efforts). > > > > Thanks for the clarification. On the "multiple proposals" idea, in fact it is explicitly in the GSoC application schedule that there is a final decision afternoon or something, at which some organization admins come together to decide which organization would take a student, if a student had submitted multiple strong proposals to multiple organizations, and multiple organizations had decided to accept the same student to work on two different proposals. So submitting multiple proposals are explicitly allowed. Obviously, if you submit two proposals to the *same* organization, one of your applications would certainly be dropped at some intermediate stage before reaching that final stage, because they are reviewed by the same people (and there are some communications/decisions between organizations *before* that final stage, if multiple applications are made) . This is just because a student cannot be actually working on two projects over the same summer period, so all except one proposals must be turned down/withdrawn *eventually*. I am just saying that, if you feel like you could be happy working on more than one area, and is confident you can get a good proposal in for each (for the same organization, or different ones), by all means submit more than one proposals.
Re: GSoC proposal
--- On Sun, 25/3/12, Cheer Xiao wrote: > So according to you and the thread Jerome mentioned, uxtheme > is one of > the more tricky and less rewarding areas; so I will set it > aside for > the moment and work on the IME proposal instead. There is no reason why you cannot submit two proposals, if you are interested in two areas. You do not get penalized for doing that, other than your own time of preparing two proposals, which is twice the preparation work. In fact it is quite common for GSoC students to apply for more than one project under different/same organization. >From the organization's point of view, it may be a good decision to give the >project to the strongest candidate if there are multiple students applying to >the same area; or not to take up any student for lack of interests (from >mentors); in which case you might be still be taken up and assigned to your >"2nd" choice project. (poor applications - showing no understandings of the background technology, etc - are rejected, so in that sense you are penalized if you cannot devote enough time to your proposal(s), if you divide your efforts).
Re: GSoC proposal
2012/3/25 Nikolay Sivov : > On 3/24/2012 20:06, Cheer Xiao wrote: >> >> Hi all, >> >> I opened bug 30255 [1](which, unfortunately, was just marked duplicate >> as bug 19263 [2]), which I believe is a long-standing issue. Simply >> put, uxthemes has some performance problems, and consequently UI >> rendering with theming enabled would lag a lot. Since I'm also >> planning for GSoC, I would like make that my GSoC proposal and fix the >> bug myself. Also, there are failing tests regarding dlls/uxtheme - >> running dlls/uxtheme/tests/uxtheme_test.exe.so gives 11 failures out >> of a total of 56 executed tests. I can try to fix that too. With all >> of these, this may still be a trivial proposal. To make it less >> trivial :), I would also like to work on the gtk+ theming bridge [3], >> once the performance issue is fixed. > > Well, fixing performance problems with enabled themes doesn't sound like a > project to me, > it's more like general bug fixing, writing test applications/tests etc., and > it's not necessary that > it's only uxtheme being a problem here. > > As I said in another thread regarding this, first step is to implement > comctl32/user32 > model that is live since Win XP, that is a real task and performance issues > are also important > of course but fixing them before doesn't make much sense. > > Regarding GTK+ integration, it's probably possible to get some key parts of > current theme and > use that data for a kind of Windows theme created on startup or something > like that. The problem > could be in different GTK+ versions for example. And again, what about > Qt-based DEs or any others? > > I think that first of all we need a proper theme implementation > plus some themes shipped by distro maintainers to mimic default distro DE > theme or some more or less > neutral version of it. So according to you and the thread Jerome mentioned, uxtheme is one of the more tricky and less rewarding areas; so I will set it aside for the moment and work on the IME proposal instead. I'll study the code before asking more about it, but I'd also like to hear your ideas and suggestions, like the status of wine's IME API, an estimation of difficulty of the task, etc. If this again is not ideal for a GSoC project, I'll turn to other areas (I have more alternative proposals). -- Regards, Cheer Xiao aka. xiaq
Wine and Window Management
Could someone tell me if Wine has a built-in Window Manager of its own or does it count on the host's window manager for such things as window hierarchy (parent-child relationships), clipping, move, resize, iconify, etc? I want to run Wine on an environment which lacks X and I have been told conflicting information on whether I need to write my own window manager. It has always been my impression that Wine does all the window management so it must have a Windows window manager built-in. I'm interested in knowing that if I remove the X11 driver from Wine, whether I will have to also provide my own window manager or whether what is in Wine is sufficient. If there is a window manager in Wine, what type of functionality does it require from whatever I chose to replace X11 with? Thanks Roger R. Cruz
Re: RFC: KUSER_SHARED_DATA update patch to fix bug 29168
> When numbers don't increment (as happens now) protection is > happy. When they start to increment, even on fast PCs round trip > user-space->wineserver->ntoskrnl will take way longer then it "should". > Indeed, that pathway will never be fast enough. I'm surprised it works with no incrementing, but perhaps that's for backwards compatibility with previous Windows versions. So, to summarize: 1. Can't use a separate per-process thread because it will break applications. 2. Can't used shared memory segment between wineserver and wine processes because it violates design principles of wineserver. 3. Can't use TimerQueue/APC because too much jitter in callback times. Is this a fair appraisal of the position of the Wine devs? If so, I'll fork a TOR-capable branch so others can play. I'll start with my patch for case #1, since it is small and works well for TOR. If I can get #2 working properly, I'll switch to that, since it is more technically correct, though as a larger patch it will be more difficult to maintain. cheers, Joey
Re: RFC: KUSER_SHARED_DATA update patch to fix bug 29168
On 03/24/2012 01:09 PM, Joey Yandle wrote: Any code written for windows expects these values to update every 15.6 ms. Exactly. Wine's wineserver & fake kernel in form of ntoskernl can not work with native speed by definition. For example even earliest versions of safedisk (1.5) were really picky about how long some kernel calls take. This is to protect against debugger. When numbers don't increment (as happens now) protection is happy. When they start to increment, even on fast PCs round trip user-space->wineserver->ntoskrnl will take way longer then it "should". Of course this is all based on research I did 5 years ago. But surprisingly enough those old Safedisk versions still work, assuming you have supported gcc version, and few other requirements. Vitaliy
Re: GSoC proposal
On 3/24/2012 20:06, Cheer Xiao wrote: Hi all, I opened bug 30255 [1](which, unfortunately, was just marked duplicate as bug 19263 [2]), which I believe is a long-standing issue. Simply put, uxthemes has some performance problems, and consequently UI rendering with theming enabled would lag a lot. Since I'm also planning for GSoC, I would like make that my GSoC proposal and fix the bug myself. Also, there are failing tests regarding dlls/uxtheme - running dlls/uxtheme/tests/uxtheme_test.exe.so gives 11 failures out of a total of 56 executed tests. I can try to fix that too. With all of these, this may still be a trivial proposal. To make it less trivial :), I would also like to work on the gtk+ theming bridge [3], once the performance issue is fixed. Well, fixing performance problems with enabled themes doesn't sound like a project to me, it's more like general bug fixing, writing test applications/tests etc., and it's not necessary that it's only uxtheme being a problem here. As I said in another thread regarding this, first step is to implement comctl32/user32 model that is live since Win XP, that is a real task and performance issues are also important of course but fixing them before doesn't make much sense. Regarding GTK+ integration, it's probably possible to get some key parts of current theme and use that data for a kind of Windows theme created on startup or something like that. The problem could be in different GTK+ versions for example. And again, what about Qt-based DEs or any others? I think that first of all we need a proper theme implementation plus some themes shipped by distro maintainers to mimic default distro DE theme or some more or less neutral version of it.
Re: GSoC proposal
On Sat, Mar 24, 2012 at 5:06 PM, Cheer Xiao wrote: > Hi all, > > I opened bug 30255 [1](which, unfortunately, was just marked duplicate > as bug 19263 [2]), which I believe is a long-standing issue. Simply > put, uxthemes has some performance problems, and consequently UI > rendering with theming enabled would lag a lot. Since I'm also > planning for GSoC, I would like make that my GSoC proposal and fix the > bug myself. Also, there are failing tests regarding dlls/uxtheme - > running dlls/uxtheme/tests/uxtheme_test.exe.so gives 11 failures out > of a total of 56 executed tests. I can try to fix that too. With all > of these, this may still be a trivial proposal. To make it less > trivial :), I would also like to work on the gtk+ theming bridge [3], > once the performance issue is fixed. > > I also have another alternative proposal, i.e. to implement full IME > support so that Windows IMEs can be used on Linux. That would consists > of basically two parts - the Win32 API (which, after a brief > inspection, seems to be at least partly implemented) to handle the > Windows part and a daemon to handle the Linux part (half like win32's > ctfmon.exe and half like ibus-daemon). But I haven't investigated much > into that yet, so I don't have much to say. Still, your suggestions > are very welcome. > > And a few words about myself: I have been one of the primary > maintainers of simplified Chinese translation of Wine during the past > few years - so I have already got my name into AUTHORS ;-). I know > quite some C - read K&R thoroughly, plus experience in a few small > projects; I also know the Git workflow well. I'd love to help fix bug > 1 so that Unix can take over the world ;-). > > Your suggestions and ideas are very welcome. > > 1. http://bugs.winehq.org/show_bug.cgi?id=30255 > 2. http://bugs.winehq.org/show_bug.cgi?id=19263 > 3. http://wiki.winehq.org/ThemingSupport > > -- > Regards, > Cheer Xiao aka. xiaq > Welcome, hope to see you in gsoc :) UXTheme came up in another thread recently. While I'm not familiar with the code, I don't think Wine is anywhere near ready to have a theming bridge. Work on theming in general gets an immense +1 from me though, but my vote won't matter here :) J. Leclanche
Re: RFC: KUSER_SHARED_DATA update patch to fix bug 29168
> > BTW one more thing, this change will most likely break number of copy > protection systems. Such as safedisk. They use user shared date times to > estimate time it took for some kernel operations. And some of those time > intervals are really tight. > I'm extremely confused by this statement. Currently, some the USER_SHARED_DATA values are written at process start, and some are not written at all. How can external code possibly rely on Wine's current broken behavior? Any code written for windows expects these values to update every 15.6 ms. If anything, I would expect updating these values to fix copy protection schemes, not break them.
RFC: A donation for Corel Draw 12 - support.
Hi, how much money do I have to donate to winehq.org to let someone fix Wine for CorelDraw 12? http://appdb.winehq.org/objectManager.php?sClass=version&iId=2390 Installation worked, but Corel is not usable and only reports: "Registry Corrupt - The UI Language registration list is invalid" I've donated a few dollars some years ago to wine and I even coded some cabinet.dll stuff some years ago... Maybe someone can help me with fixing this? Best Regards, Gerold
GSoC proposal
Hi all, I opened bug 30255 [1](which, unfortunately, was just marked duplicate as bug 19263 [2]), which I believe is a long-standing issue. Simply put, uxthemes has some performance problems, and consequently UI rendering with theming enabled would lag a lot. Since I'm also planning for GSoC, I would like make that my GSoC proposal and fix the bug myself. Also, there are failing tests regarding dlls/uxtheme - running dlls/uxtheme/tests/uxtheme_test.exe.so gives 11 failures out of a total of 56 executed tests. I can try to fix that too. With all of these, this may still be a trivial proposal. To make it less trivial :), I would also like to work on the gtk+ theming bridge [3], once the performance issue is fixed. I also have another alternative proposal, i.e. to implement full IME support so that Windows IMEs can be used on Linux. That would consists of basically two parts - the Win32 API (which, after a brief inspection, seems to be at least partly implemented) to handle the Windows part and a daemon to handle the Linux part (half like win32's ctfmon.exe and half like ibus-daemon). But I haven't investigated much into that yet, so I don't have much to say. Still, your suggestions are very welcome. And a few words about myself: I have been one of the primary maintainers of simplified Chinese translation of Wine during the past few years - so I have already got my name into AUTHORS ;-). I know quite some C - read K&R thoroughly, plus experience in a few small projects; I also know the Git workflow well. I'd love to help fix bug 1 so that Unix can take over the world ;-). Your suggestions and ideas are very welcome. 1. http://bugs.winehq.org/show_bug.cgi?id=30255 2. http://bugs.winehq.org/show_bug.cgi?id=19263 3. http://wiki.winehq.org/ThemingSupport -- Regards, Cheer Xiao aka. xiaq
Re: RFC: KUSER_SHARED_DATA update patch to fix bug 29168
On 03/24/2012 08:56 AM, Kornél Pál wrote: On 3/22/2012 2:19 PM, Vitaliy Margolen wrote: Since there are a plenty of ways to measure elapsed time, I don't think that this specific way should generally be prohibited. I'm not saying it should be prohibited. I'm saying it fixes only one app and potentially breaks 100s more... Vitaliy
XTestFakeKeyEvent events postponed until wine process exits
Hi list. Currently SendInput() works only with wine windows. I need to send keypresses to all windows, so I created a winelib dll that uses XTestFakeKeyEvent. I call this function from a wine process, but all my fake key presses wait for the process to exit. What is the reason?
Re: RFC: KUSER_SHARED_DATA update patch to fix bug 29168
On 3/22/2012 2:19 PM, Vitaliy Margolen wrote: BTW one more thing, this change will most likely break number of copy protection systems. Such as safedisk. They use user shared date times to estimate time it took for some kernel operations. And some of those time intervals are really tight. I'm not sure that preventig measuring time is a good practice. Since there are a plenty of ways to measure elapsed time, I don't think that this specific way should generally be prohibited. Thank you. Kornel
Re: [website] Spanish translation for release 1.5.0
On Sat, Mar 24, 2012 at 12:13, Eduardo García wrote: > You should send diff using git (e.g. with 'git format-patch -k 1) i.e. sthg like http://source.winehq.org/patches/data/84646
