Community
Participate
Working Groups
Recent refactoring that moved all connector-specific settings under "Additional Settings" can be too restrictive for some connectors. For example, for web repository connector, we need to make repository-specific settings (i.e. group id, etc) visible by default and also show some description/guidelines that would come from selected repository template. Besides, web repository connector already has "Advanced Settings" section which is now showed under "Additional Settings" and that is somehow weird.
What I would like us to continue to strive towards is keeping the page as simple as possible, which to me means that by default only the following should be visible: URL/label and credentials. All other configuration information then goes into a foldable section. However, as the description points out this could be too idealistic for some more sophisticated connectors. I propose that we do the following: 1) Allow connectors to contribute foldable sections. This will prevent the current problem with the generic web connector having a foldable section within a foldable section. 2) Allow connectors to specify that a foldable section is required or strongly encouraged, causing it to be automatically unfolded and visually marked as required. This will always be better to avoid, but such a mechanism would keep the dialog clean and consistent.
Mik, my point is that there are certain repository parameters that are mandatory, so hiding or folding them lead to confusion. I also believe that folding is currently overused in the configuration dialogs. If you are concerned about too many properties on a single page, that page need to be splitted to multiple pages. Eclipse Platform UI gives numerious examples of that.
(In reply to comment #2) > Mik, my point is that there are certain repository parameters that are > mandatory, so hiding or folding them lead to confusion. Please read point (2) of my comment#1 and let me know if that doesn't answer this question. > I also believe that folding is currently overused in the configuration dialogs. > If you are concerned about too many properties on a single page, that page need > to be splitted to multiple pages. Eclipse Platform UI gives numerious examples > of that. Yup, I realize that this is your point of view. However, I think that the foldable sections are much less complicated than multi-page dialogs, as I've responded multiple times. What you could do is create a new bug called something like "consider changing repository settings from foldable section UI to tabbed/multipage property UI" and we could discuss and gather feedback there.
(In reply to comment #3) > > Mik, my point is that there are certain repository parameters that are > > mandatory, so hiding or folding them lead to confusion. > Please read point (2) of my comment#1 and let me know if that doesn't answer > this question. a) It wasn't question and b) as a web repository connector component owner I constantly have to explain users how to configure obvious things, including those you are trying to hide so desperately. I fail to see why it should be your concern and why connectors should be limited if some connectors have more advanced configuration then others. In context of the web repository connector these configuration properties are practically the same thing as URL or user credentials and need to be visible all the time like URL and credentials.
My point in comment#1 was that we would provide a mechanism for the web connector to always keep that section expanded. You are not arguing against that, so could you please clarify whether you are saying that this would not be visible/close/apparent enough?
(In reply to comment #5) > My point in comment#1 was that we would provide a mechanism for the web > connector to always keep that section expanded. You are not arguing against > that, so could you please clarify whether you are saying that this would not be > visible/close/apparent enough? The main feature of foldable sections is that they can be folded, or in other words hidden. Settings I am talking about should not be hidden. Are you arguing against that?
Eugene: I don't know how to say that "a required section would always be expanded" any more clearly than I have said so I won't bother doing that again. I'm not sure if you're not reading my comments or still trying to argue on this bug against the use of folding as the UI for this (the latter comments should go on bug 195704 as I have also asked).
I am arguing that "section" (foldable or not) does not making any sense because those settings are at the same level as login or password, because hiding them is misleading. So, they should be in the same section as login and password, or should not be on that dialog at all. We clearly have a communication issue here and in my opinion it does interfere with the issues that users of the web connector have.
I understand what you are arguing and I have stated my points for why I believe that supporting this would in the end cause more of a problem than it would provide benefit (comment#1) and on bug 195704 stated why I don't want to alter the simplicity of the UI around the generic web connector. For this case please consider implementing this within the constraints that I have outlined and and if the result is terrible we can reconsider. Yes, we have a communication problem and I need to act on it now because I cannot afford to be engaged in lengthy circular arguments with you, especially now that we have such a large number of new bug reports coming in. Some of these arguments are simply differences of opinion, and that's OK since we'll leave the bugs open. Some seem to be a failure of following logic, having read reading what I wrote, or respecting my judgment. It's hard for me to tell which but those are not OK with me. Here's what I will be doing: 1) Only posting two replies to these sorts of arguments. This means that you will either need to convey your point in description+2 comments and at that point the bug will need to await further input. 2) Further input can come from others, but in order to avoid the other committers from wasting time on circular arguments I would like the other committers to follow the guideline of (1). This also means that we have up to 6 comments of argument if other committers want to chime in. If these guidelines are successful at addressing this problem I will post them on the wiki.
I am out of arguments and since we have this 2 comments game, there is no point in the further discussion.
