Bugzilla – Full Text Bug Listing
| Summary: | Remote File Property Pages should be able to pick up changes from other property pages | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Tools] Target Management | Reporter: | Violaine Batthish <batthish> | ||||
| Component: | RSE | Assignee: | David McKnight <dmcknigh> | ||||
| Status: | RESOLVED INVALID | QA Contact: | Martin Oberhuber <mober.at+eclipse> | ||||
| Severity: | enhancement | ||||||
| Priority: | P3 | CC: | ankitp, dmcknigh | ||||
| Version: | 2.0.2 | ||||||
| Target Milestone: | 3.0 M5 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Violaine Batthish
There is an API, IRemoteFile.setEncoding(String encoding). If you call it, it does the following: RemoteFileEncodingManager.getInstance().setEncoding(getHostName(), getAbsolutePath(), encoding); The Info property page picks up the encoding info via IRemoteFile.getEncoding() which makes use of the RemoteFileEncodingManager. Is this what you're looking for or is there more to it than that? I don't believe that works when the property page is already up, and has been populated. So you're trying to set the value of a field in the RSE property page from your own? Note, that SystemFilePropertyPage is internal, so making calls on it is discouraged. How are you getting at the page anyway? Currently - USS contributes a page which allows the user to specify a bidi control table (BCT) which controls the bidi codepage conversion options. When a bidi control table is specified - it may override the codepage that is specified on the info page and it would be nice if the user switched ack to that page after specifying a BCT - that it would reflect the correct codepage. On this USS property page, can I assume that the change to the encoding doesn't actually take effect until the user clicks okay? that is correct. The behaviour suggested here doesn't seem very standard in Eclipse. I don't recall ever seeing an incomplete properties/preference dialog affecting some other properties/preference dialog (i.e. normally I'd expect the user to click "ok" or "apply"). originally the request was for the ability to contribute to the info page directly and have the codepage modified from there (but that was refused) Could that be an option in openRSE? What about registering a listener on the OK/Apply button of the properties dialog.
User specifies a bidi table, but before he presses apply all other settings remain unchanged. He can switch pages etc as he likes. But when pressing Apply / Ok, validation takes place. If it turns out the code page is not ok for the Bidi table, a dialog pops up:
"Bidi Table XYZ is not supported with codepage ABC.
Do you want to switch to codepage KLM instead"?
OK CANCEL"
Pressing cancel brings the user back to teh properties dialog.
I'm not sure if it's actually possible to implement such a scheme, but would it be an option?
(In reply to comment #9) > What about registering a listener on the OK/Apply button of the properties > dialog. > User specifies a bidi table, but before he presses apply all other settings > remain unchanged. He can switch pages etc as he likes. But when pressing Apply > / Ok, validation takes place. If it turns out the code page is not ok for the > Bidi table, a dialog pops up: > "Bidi Table XYZ is not supported with codepage ABC. > Do you want to switch to codepage KLM instead"? > OK CANCEL" > Pressing cancel brings the user back to teh properties dialog. > I'm not sure if it's actually possible to implement such a scheme, but would it > be an option? I don't think it's an issue of the codepage being incompatible, because it would automatically change when the user presses okay. If the user brought up the properties, changed something in the bidi table, then clicked okay, the dialog would close. The next time the dialog comes up, the new encoding would be seen in the file property pgae. I think what Violaine wants (correct me if I'm wrong) is the ability to see what the encoding will change to if something is selected in the bidi table. Hm. I'm wondering why the user would bother? (In reply to comment #11) > Hm. I'm wondering why the user would bother? I think, ideally, they want to be able to see the encoding on the same page as the table but, because we don't have any extension point for our property page, they're not able to do that. Perhaps this property page could show the encoding as well in a read-only field that responds to the bidi table settings. That sounds like a good idea to me. When a user specifies a BCT - it contains the host encoding as part of the information. Here's a sample of a BCT: <?xml version="1.0" encoding ="UTF-8"?> <!-- Bidi Conversion Table --> <BidiTable> <!-- 1) Client attributes :--> <Client Type="Intel" CodePage="Cp1255"> <TextAttributes> <OrderingScheme> Implicit </OrderingScheme> <TextOrientation> LTR </TextOrientation> <SymmetricSwapping> Yes </SymmetricSwapping> <TextShaping> Nominal </TextShaping> <Numerals> Nominal </Numerals> </TextAttributes> </Client> <!-- 2) Server attributes :--> <Server Type="EBCDIC" CodePage="Cp424"> <TextAttributes> <OrderingScheme> Visual </OrderingScheme> <TextOrientation> LTR </TextOrientation> <SymmetricSwapping> No </SymmetricSwapping> <TextShaping> Nominal </TextShaping> <Numerals> Nominal </Numerals> </TextAttributes> </Server> <!-- 3) Conversion Options :--> <ConversionOptions> <ArabicOptions> <LamAlef> Auto </LamAlef> <SeenTail> Auto </SeenTail> <YehHamza> Auto </YehHamza> <Tashkeel> Auto </Tashkeel> </ArabicOptions> <WordBreak> Off </WordBreak> <RoundTrip> Off </RoundTrip> </ConversionOptions> </BidiTable> So we'd like to be able to sync what appears on the Info page with what gets specified in the BCT. Violaine, is it necessary to synch up the other page when the changes aren't yet applied? I don't understand what's wrong with just reflecting the associated encoding on the bidi page, itself. I haven't heard back about this one. Violaine, any more thoughts on this? What about when they press Apply? The user wouldn't be able to see the change reflected then. They would only be able to see the change when they close the properties and reopen them. That still seems weird to me. Did not make the fix for M4, targeting 3.0M5 (In reply to comment #17) > What about when they press Apply? The user wouldn't be able to see the change > reflected then. They would only be able to see the change when they close the > properties and reopen them. That still seems weird to me. After pressing Apply, I would expect for the other pages to be uptodate with the changed remote file. If that's not the case right now, that should be fixed. Created attachment 87682 [details]
patch to allow remote file property pages to pick up changes from other property pages
Violaine, would this patch help your scenario (i.e. when you apply your property page)?
Bulk reassign missed M5 tasks to M6 ok, finally managed to get some time to try this out. Yes this patch does make the properties work much better. Thanks! (In reply to comment #22) > ok, finally managed to get some time to try this out. Yes this patch does make > the properties work much better. Thanks! Okay, then I'll mark this as fixed. I committed the code a while back. According to SearchCVS, the patch was committed on 2008-01-25 15:25:16 so this happened with M5 already. Also changed the summary to be in line with what the patch finally does. Previous value was: API needed to access the file encoding field on a file's property page Ok - I'm still having some troubles :-( Even with the fix above, if a usermodifies the info page and the bidi page I've contributed, I have no guarantee that the performOk() method on my page will get run last. In fact, in English the BIDI page gets run first (due to alphabetical reasons), which means that even though my page sets the encodign of the remote file using the RemoteFileEncodingManager.getInstance().setEncoding() API, it has no effect since the Info page's performOk() method runs and resets the encoding using the value on that page. The problem is that since I'm not supposed to subclass DStoreFileService (see bug 220379), I can't override the encoding that gets sent to the IFileServiceCodePageConverter.isServerEncodingSupported(String, IFileService) method. I can think of a couple possible solutions: 1. Ensure that the performOk() in the Info page checks to see if the encoding has been modified since the page opened and not set it (even if the user had modified the field) 2. Pass in the remote path with isServerEncodingSupported (like the other APIs) so that the converter may ignore the encoding parameter if necessary. (In reply to comment #25) > Ok - I'm still having some troubles :-( > Even with the fix above, if a usermodifies the info page and the bidi page I've > contributed, I have no guarantee that the performOk() method on my page will > get run last. In fact, in English the BIDI page gets run first (due to > alphabetical reasons), which means that even though my page sets the encodign > of the remote file using the > RemoteFileEncodingManager.getInstance().setEncoding() API, it has no effect > since the Info page's performOk() method runs and resets the encoding using the > value on that page. > The problem is that since I'm not supposed to subclass DStoreFileService (see > bug 220379), I can't override the encoding that gets sent to the > IFileServiceCodePageConverter.isServerEncodingSupported(String, IFileService) > method. > I can think of a couple possible solutions: > 1. Ensure that the performOk() in the Info page checks to see if the encoding > has been modified since the page opened and not set it (even if the user had > modified the field) > 2. Pass in the remote path with isServerEncodingSupported (like the other APIs) > so that the converter may ignore the encoding parameter if necessary. Looking at the code, it seems that we do try to ensure that in performOk() we don't set the encoding if it hasn't changed: String selectedEncoding = getSelectedEncoding(); if (... && !prevEncoding.equals(selectedEncoding)) { .... } As far as I can see, if the user hasn't changed the encoding (from the original prevEncoding to the new selected encoding) we should not enter the if block that sets it. If you tried this in a debugger, how are prevEncoding and selectedEncoding different? (In reply to comment #26) > Looking at the code, it seems that we do try to ensure that in performOk() we > don't set the encoding if it hasn't changed: > String selectedEncoding = getSelectedEncoding(); > if (... && > !prevEncoding.equals(selectedEncoding)) > { > .... > } > As far as I can see, if the user hasn't changed the encoding (from the original > prevEncoding to the new selected encoding) we should not enter the if block > that sets it. If you tried this in a debugger, how are prevEncoding and > selectedEncoding different? Dave, the problem isn't when a user doesn't modify the info page, the problem is when they do. If a user modifies both settings, I still need my setting to win. (In reply to comment #27) > (In reply to comment #26) > > Looking at the code, it seems that we do try to ensure that in performOk() we > > don't set the encoding if it hasn't changed: > > String selectedEncoding = getSelectedEncoding(); > > if (... && > > !prevEncoding.equals(selectedEncoding)) > > { > > .... > > } > > As far as I can see, if the user hasn't changed the encoding (from the original > > prevEncoding to the new selected encoding) we should not enter the if block > > that sets it. If you tried this in a debugger, how are prevEncoding and > > selectedEncoding different? > Dave, > the problem isn't when a user doesn't modify the info page, the problem is when > they do. If a user modifies both settings, I still need my setting to win. So a user changes both property pages prior to pressing apply such that they conflict with each other. To me this seems like a user error. It also seems strange that RSE would have to pick a winner in such a case. Martin, do you know of any precedent in eclipse for such a scenario? Note that I'm aware of. Some Prefs pages work around similar issues by embedding an Apply button in their client area, and when the user switches to a different page they ask for Apply Or Discard. But mostly, Property Pages do not influence each other. For our commercial product, we invented a special framework to deal with the issue of multiple pages (in our case in a wizard OR property dialog) influencing each other... we basically have all pages operate on a common data model, and ask EACH page to extract data, validate and push it back into the model when ANY page is changed. well to me the ideal solution would be if I could somehow just disable the field so that it would be greyed out. The original request from the BIDI centre was to be able to put a composite on the info page itself and directly interact with the combo, instead of using a seperate page. I believe you could use some SWT inspection on the widget hierarchy if you want to do that badly - automated UI testing tools like SWTBot do this all the time. But you'd certainly be accessing non-API if you did that. Violaine, I think one of the cleaner solutions would be to disallow changing from the bidi property page to another without applying outstanding modifications. In order to do that, though, you'd need to do this with the bidi property page. For the info property page perhaps a similar things needs to be done. What do you think? What's the status of this? Can we close this bug and open separate new one(s) for dealing with remaining issues? Can we close this? Closing this since I haven't heard anythign from the reporter. Please reopen this if it's still an issue. |