Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[CLOSED] Sidebar resize refactorization #1765

Open
core-ai-bot opened this issue Aug 29, 2021 · 2 comments
Open

[CLOSED] Sidebar resize refactorization #1765

core-ai-bot opened this issue Aug 29, 2021 · 2 comments

Comments

@core-ai-bot
Copy link
Member

Issue by jbalsas
Thursday Oct 11, 2012 at 00:48 GMT
Originally opened as adobe/brackets#1811


Hi,

Following the inclussion of utils/Resizer in adobe/brackets#1661, I've refactored project/SideBarView to use the existing code.

I've added a new toggleVisibility API in Resizer. This can be called for any resizable panel. Panels with a class collapsable are also toggled when double clicking on their resize handler. Resizable panels also dispatch now panelCollapsed and panelExpanded when changing from one state into another.

This pull request includes also some fixes for the current sidebar resize behavior (which could be merged independently if this whole refactorization is not really required):

  • The resize handler changes to default when going over the CodeMirror gutter space
  • While resizing, if we take the mouse out of the Brackets window and then release it, when entering again, the resize action is still going
  • If the sidebar is hidden, slowly trying to resize it to the left out of the window produces strange behaviors (possibly related to the one above)

jbalsas included the following code: https://github.com/adobe/brackets/pull/1811/commits

@core-ai-bot
Copy link
Member Author

Comment by redmunds
Thursday Oct 11, 2012 at 22:56 GMT


It sounds like there are 3 independent changes here:

  • convert sidebar to use resizer module
  • add toggleVisibility API
  • resizer bug fixes

Is that correct? If so, it wold be much nicer if you could separate them into different pull requests. It's always best to make pull requests as atomic as possible.

@core-ai-bot
Copy link
Member Author

Comment by jbalsas
Thursday Oct 11, 2012 at 23:34 GMT


Of course, sorry about that!

I'm closing this one and will be opening separate pull requests for the different changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant