Anton, I do not agree to your comments. I am implementing a different message to enable the touch functionality compared to your software changes. There is only a copy of the win8orlater variable because this is required for my api's too!! Rest all those changes have to be laid in a similar way as opposed to other kinds of windows messages that are handled in the system. I say that you have copied the organization from other software changes what other authors have made long time back. Is'nt it? We both have to use the similar code organization because of the existing laid out code organization inevitably. Our api calls are also dependent on the same library as well and we both need to import from the same dll. To illustrate my argument, there are other dll import functions that are present in the file awt_Toolkit module for eg., splashscreen.dll importing ' SplashClose' at line no. 2807 to 2812. So this is the reason you have put the import calls in the same file as well after seeing a similar change and I will have to do the same thing as well because of the existing code organization. And obviously I have to change the awt_component module in order to insert the new messages(in this case WM_POINTER message and not the WM_TOUCH as opposed to your's). They are completely different implementations and there is no copy of your code as such.
So if you see in a way everybody has copied the code organization which some author has put it a long time ago(That's the framework implication). I agree to the copy of the win8orlater variable and the corresponding macro IS_WIN8. But again this macro is available in the internet too. I expect once either of our code gets checked in and while doing the other code check in would resolve that issue if they are same. That's the reason I copied as is so that check in would not cause further problems. Even if it causes who ever checks in later would need to resolve it which I think would be me since you have already started the review some time back. Copying here make sense because we both would end up creating different variables for the same functionality which I did not wanted to since I knew that you are also doing a similar change. If you do not wish to share the same variable , alternatively I can very well create my own namespace for my functionality and hide that variable(isWin8OrLater). Is this approach is fine? Thanks and regards, Shashi -----Original Message----- From: Anton Litvinov Sent: Tuesday, September 19, 2017 8:25 PM To: Shashidhara Veerabhadraiah <shashidhara.veerabhadra...@oracle.com>; Sergey Bylokhov <sergey.bylok...@oracle.com> Cc: awt-dev@openjdk.java.net Subject: Re: <AWT Dev> [10] JDK-8178361: JFileChooser does not allow to open folders with a double tap when using the touch screen interface Good day Shashidhara, You took parts of my fix for the bug (https://bugs.openjdk.java.net/browse/JDK-8166772) which is being reviewed on this e-mail alias since 17/08/2017 and which is almost approved by one reviewer (http://mail.openjdk.java.net/pipermail/awt-dev/2017-September/012999.html). You did not inform me about intention to use the parts of my fix anyhow and you are trying to present these copied parts of my fix as yours. This is not acceptable and looks as a plagiarism. You fully copied the code organization from my fix - your fix changes the same files in the identical places, in all 4 files there is the code which is identical to the code from the same files in my fix, you even did not change the text of my source code comments. Though you are trying to address a different issue and use a different API, your fix edits the same files in the same places what makes our 2 fixes overlap each other and conflict with each other. And you knew about these compatibility problems, because last week you entered the review of my fix and after that you sent your review request on 19/09/2017. I do not want to remove my parts of the fix from my fix and test and review my fix again just to be able to apply my fix over yours containing my code, if yours is approved first and pushed first. My review request was filed more than one month before your review request. How to quit this situation? In order to resolve this situation, I suggest you: 1) To link your bug to my bug JDK-8166772 and to mark your as "is blocked by" my bug. 2) To agree to remove my parts of the fix from your fix, wait until I provide the final version of my fix with 2 micro changes to the reviewers, what I will do within next 2 days, and we will sort out with you offline, how to recreate your new version of the fix. Currently I suppose that I will give you the changeset with my approved fix, you will clone two instances of "jdk10/client", in one you will "hg import" my changeset, then apply your changes and create a "webrev" for your fix, in the second instance of "jdk10/client" you will apply my fix just using "patch" and then apply your patch from "webrev", we will discuss these details offline. If you accept this way of resolution, I agree to forget about the earlier described issue with your fix. What do you think about my suggestion? Thank you, Anton On 19/09/2017 04:35, Shashidhara Veerabhadraiah wrote: > Hi Sergey, When I checked it was not working on the Java applications. None > of the controls could take touch click events but it used to highlight > because when we touch on the touch screen interface the system moves the > cursor over to the touch point thereby enabling mouse focus events being sent. > > Thanks and regards, > Shashi > > -----Original Message----- > From: Sergey Bylokhov > Sent: Tuesday, September 19, 2017 3:39 AM > To: HYPERLINK "mailto:shashidhara.veerabhadra...@oracle.com"; > shashidhara.veerabhadra...@oracle.com >> Shashidhara > Veerabhadraiah < HYPERLINK "mailto:shashidhara.veerabhadra...@oracle.com"; > shashidhara.veerabhadra...@oracle.com> > Cc: HYPERLINK "mailto:awt-dev@openjdk.java.net"; awt-dev@openjdk.java.net > Subject: Re: <AWT Dev> [10] JDK-8178361: JFileChooser does not allow > to open folders with a double tap when using the touch screen > interface > > Hi, Shashi. > Why the bug is JFileChooser specific? > Does it means that it works for other elements(buttons/lists/menu/etc)? > > On 9/18/17 08:58, Shashidhara Veerabhadraiah wrote: >> Hi All, Please review this software changes for the /_enhancement_/ >> JDK-8178361. >> >> Issue: Request was filed to enable the touch event processing for >> Java client applications. >> >> Fix: Windows platform offers 'pointer' implementation thro' which one >> can tap for the touch inputs as well. A typical 'pointer' function >> may contain touch, pen, touch pad or mouse inputs. This allows for a >> uniform input processing though the event source may defer. This fix >> enables the 'touch' events(via TOUCH pointer) to be passed to the >> components using the other type of pointer 'mouse'. Essentially there >> is a conversion put in place to convert a touch event input into a >> left click mouse event. I think this is the right thing to do >> considering desktop scenarios to which the typical Java applications >> that gets exposed to. This is also the same behavior on my touch >> enabled windows 10 laptop as well. Please let me know if a different >> behavior is expected. Below is the output: >> >> Now touch event works as a typical mouse left click as in general. >> But there is an issue because the icon size of the Java UI is >> typically small, touching that icon exactly is sometimes difficult. >> This is handled by an Windows application by having larger icon size >> or icon view as a standard. Hence I believe this is outside the scope >> this software update. Any changes to it would be done later as a new >> bug or an enhancement. >> >> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8178361 >> >> Webrev: http://cr.openjdk.java.net/~sveerabhadra/8178361/webrev.00/ >> >> Thanks and regards, >> >> Shashi >> > > -- > Best regards, Sergey.
