Skip to content
This repository has been archived by the owner on Sep 6, 2021. It is now read-only.

Fixed status bar so it can add indicators to itself again #6304

Merged
merged 5 commits into from
Dec 27, 2013
Merged

Fixed status bar so it can add indicators to itself again #6304

merged 5 commits into from
Dec 27, 2013

Conversation

lkcampbell
Copy link
Contributor

This fix addresses issue #5682. StatusBar.addIndicator() now adds the indicators to the DOM correctly.

@lkcampbell
Copy link
Contributor Author

Just a couple of notes on this.

@njx indicated that he only wanted relative positioning for core features, so I named the new parameter for addIndicator with an underscore name _beforeID and indicated it is for CodeInspection internal use only in the documentation. Didn't know the exact style you guys use for this situation so that's my best guess.

I didn't add the new indicator to the very leftmost position, because I thought it would look weird if the "busy" indicator appeared in the middle of a bunch of indicators. So, I kept the "busy" indicator as the leftmost indicator always. If you don't like this, let me know and I can change it.

@@ -121,6 +122,13 @@ define(function (require, exports, module) {
$indicator.hide();
}

if (_beforeID) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If _beforeID is specified, but doesn't exist, then indicator won't get inserted. So, what do you think about checking for it like this:

    if (_beforeID && $("#" + _beforeID).length > 0) {

@lkcampbell
Copy link
Contributor Author

@redmunds, code review change committed.

*/
function addIndicator(id, indicator, visible, style, tooltip) {
function addIndicator(id, indicator, visible, style, tooltip, _beforeID) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the preceding underscore should be removed. I don't see any reason why extensions shouldn't be allowed to use it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, it will be an API addition then. I have to make sure I understand exactly how it is to work so I name and document it correctly. When it was internal use, didn't have to worry about it.

First off, when I say BEFORE an indicator, I mean "to the left of" an indicator in the user interface. When I say AFTER an indicator, I mean "to the right of" an indicator in the user interface. This needs to be clarified because the DOM model of the indicator elements runs top-to-bottom, while the view of the indicators runs right-to-left. Makes it easy to confuse jQuery concepts of BEFORE and AFTER, with UI concepts of BEFORE and AFTER.

It seems like relative positioning should really have the ability to specific FIRST, LAST, and BEFORE, or AFTER, an existing element. So, one question is, is there any place we do not want to have extensions inserting indicators?

For example, putting an indicator FIRST would put it BEFORE the "busy" indicator. That would probably look weird.

Another example, putting an indicator LAST would put it AFTER the space/tab indicator. It seems like this messes with the user experience a bit.

But do we want to constrain relative positioning? Or do we allow it and let issue reports from users deal with the odd cases that crop up?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Upon further reflection (i.e. a good night's sleep) we can probably pull this off with just beforeID. Except I am going to call it insertBefore because it is similar nomenclature to the jQuery method. In fact, I am going to paraphrase the jQuery documentation description as well because the purpose of this parameter is surprisingly difficult to describe without tying the sentence into knots:

An id of an existing status bar indicator. The new indicator will be inserted before (i.e. to the left of) the indicator specified by this parameter.

Ugh. Not great, but close enough.

The main side effect of only using insertBefore is that it is impossible to insert any indicator AFTER the space/tab indicator. I think this is a good thing though. It keeps the space/tab indicator in the lower right corner at all times.

We do need to decide, however, if we are going to prevent an insert BEFORE the "busy" indicator. If so, I need to update the parameter documentation a little and tweak the code. If not, we should be good to go with this next commit.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, we don't need to worry about inserting before the "busy" indicator because that indicator doesn't have an id. I suppose they could, theoretical, set the id to "status-bar .spinner", but the code discourages this behavior. So, we should be set with this next commit.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with keeping this simple.

@lkcampbell
Copy link
Contributor Author

@redmunds, code review changes committed.

if (insertBefore && $("#" + insertBefore).length > 0) {
$indicator.insertAfter("#" + insertBefore);
} else {
// No positioning is provided, put after "busy" indicator
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd like a little more detail regarding positioning of busy indicator. Maybe:

    // No positioning is provided, put on left end of indicators, but
    // to right of "busy" indicator (which is usually hidden).

@redmunds
Copy link
Contributor

Done with review. Code looks good. Just one nit about comments.

@lkcampbell
Copy link
Contributor Author

@redmunds, code review changes committed.

@ghost ghost assigned redmunds Dec 27, 2013
@redmunds
Copy link
Contributor

Looks good. Merging.

redmunds added a commit that referenced this pull request Dec 27, 2013
Fixed status bar so it can add indicators to itself again
@redmunds redmunds merged commit 7c3aad3 into adobe:master Dec 27, 2013
@lkcampbell lkcampbell deleted the fix-5682 branch December 28, 2013 16:08
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants