Community
Participate
Working Groups
Build ID: I20090313-0100 Steps To Reproduce: I suggest the following methods for a TitleAreaDialog: setDialogComplete, getDialogComplete, setDescription, getDescription (and probably getMessage, getErrorMessage). This would allow (when data binding is used) the TitleAreaDialog together with TitleAreaDialogSupport to behave the same way as a WizardPage with WizardPageSupport. And this again provides a consistent GUI feel for the user.
Created attachment 132523 [details] Patch for TitleAreaDialog This patch implements the above mentioned methods and allows the fix suggested in bug 272794 to work.
Gah, "select to remove" indeed. Sorry Remy, and thanks Mylyn! ;)
ping
I'm still triaging the backlog for 3.6, so am not assigning milestones to anything yet. I'll assign this to myself and mark 3.6 for now...
I just want to report that I am using this patch now for quite some time and it seems to work flawlessly. Any chance to have it in one of the next milestones?
I'll mark this one for M3
It feels like a red flag to me to ask that WizardPage-like methods be introduced into TitleAreaDialog. in my mind the mapping is WizardDialog->TitleAreaDialog WizardPage->DialogPage In the dependent bug, you mentioned > As I am using a lot of databinding lately, I also wanted to have the same > support for my TiteAreaDialog as for the WizardPage. Can you not use a DialogPage inside your TitleAreaDialog? This would allow you to get the page description for free, and would be a bit more consistent, such that descriptions are provided at the page-level, not the dialog page level. I've used this technique when I have code that might live inside a wizard, a title area dialog, or even a preference page. To tie the page to the title area dialog, you need to do something like: protected Control createDialogArea(Composite parent) { page = new MyDialogPage(); page.createControl(parent); this.setMessage(page.getDescription()) return page.getControl(); } It's even possible that data binding introduces a DialogPage subclass that handles whatever is needed here. Thoughts?
Good point, but I still don't see how the DialogPage could emulate an WizardPage like description. TitleAreaDialog does not even support getting it's message field.
On the other side ... why not just give TitleAreaDialog (and therefore also WizardDialog) the same "description" feature as a page has? It doesn't break anything and only makes things easier. And I never read anywhere that by definition a dialog only can have messages and not descriptions ;-)
(In reply to comment #8) > Good point, but I still don't see how the DialogPage could emulate an > WizardPage like description. TitleAreaDialog does not even support getting it's > message field. There is no specific support in TitleAreaDialog for pages, but it would work as demonstrated in my snippet above. The dialog subclass would set its message to the dialog page's description. I'm suggesting that this technique might be useful to solve your original problem, which I believe is that you want to treat wizards and title area dialogs similarly. (I don't understand the specific data binding scenario, but I've had similar issues myself along these lines). I think having a single-page title area dialog would give you the abstraction you want. (In reply to comment #9) > On the other side ... why not just give TitleAreaDialog (and therefore also > WizardDialog) the same "description" feature as a page has? > It doesn't break anything and only makes things easier. Are you suggesting that two descriptions would be shown at any one time (the dialog and the current page's description?), or that the page description would win over the dialog's description? These are the kinds of things that would need to be worked out in a very specific API description, I don't think duplication necessarily makes things easier. > > And I never read anywhere that by definition a dialog only can have messages > and not descriptions ;-)
Yes, I absolutely see your point. But I am not sure if it can be implemented without changing the TitleAreaDialog at all. The last time I tried, I came to the conclusion that it can't and rewrote the TitleAreaDialog for my application. From a quick look I see that WizardDialog has methods and internal attributes a TitleAreaDialog does not have, like updateDescriptionMessage() and pageDescription. I am sorry, I am very busy and can't look into it at the moment. Can you come up with a runnable DialogPage/TitleAreaDialog example? I will try the binding then (with DialogPageSupport).
(In reply to comment #11) > Yes, I absolutely see your point. > But I am not sure if it can be implemented without changing the TitleAreaDialog > at all. The last time I tried, I came to the conclusion that it can't and > rewrote the TitleAreaDialog for my application. > From a quick look I see that WizardDialog has methods and internal attributes a > TitleAreaDialog does not have, like updateDescriptionMessage() and > pageDescription. It's quite possible that there would need to be some changes. But what I was imagining was a subclass of TitleAreaDialog (SinglePageDialog?)...that could be tailored to your needs. I'm not suggesting this goes into the platform, I'm suggesting that if you want to treat wizards and title area dialogs in the same way, using a paged dialog might be the way to go. Maybe this belongs in data binding. > I am sorry, I am very busy and can't look into it at the moment. > Can you come up with a runnable DialogPage/TitleAreaDialog example? I will try > the binding then (with DialogPageSupport). Sorry, equally busy, and I don't have the use case. But really what I'm thinking of is not that much more interesting than the snippet I showed you in comment #7. I sense you want more than that. My suggestion is to try implementing what you need in terms of a single-page title area dialog (when you have time) and then attach a patch that demonstrates what is missing in TitleAreaDialog. I would hope that most of what is needed could be implemented in a subclass of TitleAreaDialog, but if there are method visiblity problems we could fix those. I'm going to remove the milestone on this bug for now.
> But what I was imagining was a subclass of TitleAreaDialog > (SinglePageDialog?)...that could be tailored to your needs. I'm not suggesting > this goes into the platform, I'm suggesting that if you want to treat wizards > and title area dialogs in the same way, using a paged dialog might be the way > to go. Maybe this belongs in data binding. In my opinion we should look for a solution that goes into the platform. For myself I have a solution. I use that patched TitleAreaDialog in my RCP application without any problem. But data binding is a common task nowadays. And TitleAreaDialog is one of the most used custom dialogs of the platform. So we should easily allow the user to add that feature to their plugins and RCP applications. At the moment the TitleAreaDialogSupport is simply broken. Maybe we should support a TitleAreaDialogPage and allow to add or set it in the TitleAreaDialog. And then have a TitleAreaDialogPageSupport. That would fulfill the mapping as you suggested in comment #7. I do not think that another subclass of TitleAreaDialog just to have the data binding for people to work is any solution.
Matthew, what is your opinion on this?
(In reply to comment #13) > Maybe we should support a TitleAreaDialogPage and allow to add or set it in the > TitleAreaDialog. And then have a TitleAreaDialogPageSupport. > That would fulfill the mapping as you suggested in comment #7. > I do not think that another subclass of TitleAreaDialog just to have the data > binding for people to work is any solution. That sounds reasonable, I just wouldn't want to force the use of a page on clients of TitleAreaDialog.
I gave that whole thing a second thought ... and came up as result with my first solution :-/ Here is why: In my opinion TitleAreaDialog has implicitly one page. In comment #10 you wrote about duplication of the description attribute. I don't think that this is really true. The dialog is the view and the page is the content. So the page stores it's description and shows it by using the dialog when it is the current visible page. This could also be done by using a dialog.setDescription() method (and not just updating the message). But even if you still think that this is duplication, how do you explain that both page and dialog already have a message and errorMessage attribute. So it would just be fair for the dialog (TitleAreaDialog) to have the description attribute, too. This is by far the most straight forward solution. It doesn't break anything and provides all needed features.
Susan, would it be possible to have two getters at least for message and error message (getMessage and getErrorMessage)? That way the TitleAreaDialogSupport could emulate the description.
Susan can we possibly have public getters for the message and errorMessage properties?
will have to take another look later, marking M6 since it's API affecting.
Hi, Kai and Matthew. I don't see a technical problem with introducing getters here. (ie, there's no confusion or funky timing issues about the values that make it confusing). So the request seems reasonable. Now, I put on my "stop API bloat" hat. (I'm not trying to be difficult, at this point it would be much simpler for me to release the new API, but I don't feel good doing that without understanding the requirement.) You want to be able to attach some data binding support code to any random TitleAreaDialog and have the data binding code get a result and set the message/error message accordingly. You'd like to use the same code for WizardPageSupport and TitleAreaDialogSupport. Both classes have set methods so setting the message is not your problem. It has something to do with retreiving the message. I looked briefly at DialogPageSupport and its subclasses and they don't seem to use the existing public getters, so I still don't understand the use case. If this is some kind of "instrumentation" code where reflection or subclassing could be used instead, then I'm not sure adding API is appropriate. If it seems like it's more general use, I'm not against adding those methods.
The use case on question is that we want to remember any previously set dialog message so it can be restored when validation finally passes.
(In reply to comment #21) > The use case on question is that we want to remember any previously set dialog > message so it can be restored when validation finally passes. TitleAreaDialog keeps separate messages so that it can do this for you. It remembers the message and restores it when the error message is set to null. Is the issue that you have a different way of remembering the message (ie, other severities besides error that should replace the message?). If you like, we can talk about this on IRC (susanmccourt). Maybe we can resolve it faster.
DataBinding posts messages of all types, not just errors. The use case is that the client manually sets an initial message, e.g. setMessage(IMessageProvider.INFO, "something informative"), and we want DataBinding to restore that manually set message when there is no DataBinding validation message. DataBinding itself is using setMessage so calling it again with null clears the message rather than restoring the old value.
thanks, Matt. That's what I needed to understand. Just trying to cut through the more general argument of "things should be the same." Will put these in.
fixed in HEAD >20100303. Changing title of bug to reflect what happened.
Comment on attachment 132523 [details] Patch for TitleAreaDialog patch marked obsolute - we went with a different approach
.
verified via source inspection. win7, Build id: I20100309-0100
