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

Persistent storage of widget layout #1519

Closed
hoppfrosch opened this Issue May 18, 2016 · 8 comments

Comments

Projects
None yet
4 participants
@hoppfrosch

hoppfrosch commented May 18, 2016

Short Summary

Added by CareyH


Komodo should persist all widget layout information through a restart:

  • Order
  • Placement (eg. two widget embedded beside eachother)
  • detached state

As a followup of #1433:
Reordering tabs from bottom pane ("Version Control", Breakpoints" ...) is not stored persistently.

Steps to Reproduce

Having bottom tab visible: reorder the tabs on bottom pane, reorder the tabs, restart Komodo:

Expected results

Ordering of pane tabs should be persistent

Actual Result

The new ordering of the tabs is lost and the original order is active again

Platform Information

Komodo IDE, version 10.0.1, build 89160, platform win32-x86.
Win7 SP1 Ultimate 64-bit

@mitchell-as mitchell-as added this to the 11 milestone May 18, 2016

@mitchell-as mitchell-as removed the Type: UX label May 18, 2016

@Naatan Naatan assigned cgchoffman and unassigned Naatan May 18, 2016

@Naatan Naatan modified the milestones: 10.1, 11 May 18, 2016

@cgchoffman cgchoffman changed the title from Persistent storage of ordering of bottom-pane tabs to Persistent storage of widget layout Jun 14, 2016

@cgchoffman

This comment has been minimized.

Member

cgchoffman commented Jun 14, 2016

It looks like if ko.uilayout started using ko.widget properly then. It doesn't seem like these two things should be mutually exclusive. If ko.uilayout wrapped ko.widget.unload and ko.widget.restoreLayout then we would get more logical UI restoration.

@cgchoffman

This comment has been minimized.

Member

cgchoffman commented Jun 15, 2016

Closing note: We will actually prefer to move away from ko.uilayout in general. We'd like to focus the various tasks that that code handles into more specific tools. Basically, we will eventually deprecate ko.uilayout and move it's functions into more logic modules.

@hoppfrosch

This comment has been minimized.

hoppfrosch commented Feb 1, 2017

Does not work yet - running Komodo IDE, version 10.2.0-alpha1, build 89795, platform win32-x86. Built on Fri Jan 27 01:00:30 2017.

Steps to reproduce:

  • Within bottom panel drag-and-drop Tab "Version Control" from first to the last position
  • Restart Komodo

-> "Version Control" is in the first position again

@cgchoffman

This comment has been minimized.

Member

cgchoffman commented Feb 1, 2017

This unfortunately won't get priority for a little while. Is this a big issue for you @hoppfrosch, it seems like a minor annoyance.

@cgchoffman cgchoffman reopened this Feb 1, 2017

@Naatan Naatan modified the milestones: Perpetual, 10.1 Feb 1, 2017

@Naatan Naatan added the Type: UX label Feb 1, 2017

@hoppfrosch

This comment has been minimized.

hoppfrosch commented Feb 2, 2017

Is this a big thing for me? yesno - but as long as issue #1433 is not fixed, I've got no chance to use my prefered difftool (which is an annoying thing to me). Having the issue above not fixed, I cannot move the "version control" tab persistently from the first position to avoid komodoide permanently opening my preferred difftool on start (as "version control" tab is the default tab on komodo-start).

So I would be glad to see one of the two issues fixed (#1519 or preferred #1433) in order to be able to use my external difftool

And for the sake of consistency, I think the issue above should be fixed ... (Why is it possible to reorder tabs on the left and right panel persistently - and not on the bottom panel?)

@cgchoffman

This comment has been minimized.

Member

cgchoffman commented Feb 2, 2017

I didn't say it shouldn't be fixed. I just asked how big of an issue it is for you :) Sounds like it's not a big issue and @Naatan has labelled it accordingly.

@hoppfrosch

This comment has been minimized.

hoppfrosch commented Feb 3, 2017

I didn't say its not a big issue for me. I said as long as one of both is issues #1519 or #1433 is not fixed, it's a big thing for me ;-)

@cgchoffman

This comment has been minimized.

Member

cgchoffman commented Oct 18, 2017

This should be resolved bye #1975.

@cgchoffman cgchoffman closed this Oct 18, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment