Community
Participate
Working Groups
currently only the user is able to invoke status area. But in certain cases (automatic reporting) it may be desired to execute support area code without the user action.
Sorry I'm not sure I follow the problem description (or how it relates to the title). Can you elaborate?
Let's assume that you have written your custom support area which allows for reporting errors. This support area is opened when user presses the "bug" button. Now: a. Certain issues should not be reported (f.e. licence expired, etc). b. Other issues should be definitely reported. So, status should be able to carry indication if the support area should be initially shown/hidden when status dialog appears.
Couldn't this just be solved through the use of a custom status dialog? I think its good that we provide a basic dialog with a support area, since that allows good reuse and ease of implemention. But I don't know if I like the trend whereby we add more and more hints into the status adapter with the goal of specializing the behaviour of the pre-canned status dialog.
Kevin, may I take this bug from you?
Chris, Fix for this bug may confuse the user. Just imagine that the we have a couple of statuses in the dialog and the support is open/closed depending on selection. I have fixed bug 249647, and I believe that right now we need only SUPRESS_SUPPORT flag, which will instruct the support area to display appropriate message (f.e. "This issue cannot be reported.") and perform no additional action.
Sorry about the delay, We are trying to solve the fact that 'some products asked to show the support area' when the dialog is opened right ? So if I want to generalize, here is what I see happening - by default, we show the message - Sometimes, some products, based on the selection of the message, need to 'hint' to the user that there is something more to learn about this message The hint may be subtle (a button goes from disable to enable: ala Next in a wizard when you accept a license) or can be non-subtle (a UI suddenly appears) so questions: 1) I do not have an example that comes to mind about the non-subtle... if one has an example, we should follow it :) Kevin ? as a UI Guru ? 2) I am still not sold in having the 2 areas activated but 2 different mechanisms (the details area and the support area), once we figure out how to show the 'non subtle' hint, we should collapse the details/support area no ? Again Kevin, as a UI guru, do they make sense , each, separately ? (the details and the support area) or do they represent the same semantic 'Tell me more about this message' ?
I work much better with pictures. I'd like to see some mockup storyboards to express the different cases and what we want to have happen. I think maybe the confusion that Krzysztof is expressing is that the proposed decision making is at the individual status level, but the dialog can be showing many statuses. What happens if we're showing two statuses and one says they want the support area should be open and the other says it shouldn't? What I'd like to see is a single mechanism by which the product gets to decide, based on the *set* of statuses, how to handle both the client and details area. Not sure if that's answered the questions.
Created attachment 125143 [details] Pictures for Kevin ;-) I want to avoid situation labeled as 1, when user switches between statuses, and the dialog opens and closes the support area. I believe that for Eclipse 3.5 approach 2 would be better - I mean the support area remains opened, but displays message explaining why this error should not be reported. Approach 3 is a fresh idea - we could display details if the error cause is external, or ask the user to report the error if it is product fault. This would be rather big change (how do we determine what is the error cause?), but maybe it could be considered for e4?
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
