proposal: panel reordering

[jvanasco]

Before config.add_debugtoolbar_panel, the way to add custom panels was via

config.registry.settings['debugtoolbar.panels'].append(PANEL)

or

config.registry.settings['debugtoolbar.extra_panels'].append(PANEL)

The end behavior of this, was an adjustment to the application config (.ini but now it can by other formats) value of debugtoolbar.panels only affected the ordering/enablement of the default Pyramid panels.

After this api change, everything added via add_debugtoolbar_panel (which happens transparently for 3rd party items via debugtoolbar.includes in the config) goes into the generic panels list. Consequently, utilizing the config value to change the ordering of debugtoolbar.panels will remove any of the panels that were added in debugtoolbar.includes UNLESS they are explicitly named there.

I propose some configuration mechanism that would affect the ordering of panels, so developer can more-easily reorder the panels without having to declare them multiple times.

perhaps something like this...

• debugtoolbar.panels_reorder The list of registered panels is reordered to have these elements, in this order, first. panels that are not listed appear afterwards.
• debugtoolbar.panels_removePanels listed here will be removed.

[digitalresistor]

How many panels do you have?

[jvanasco]

How many panels do you have?

It depends on the app and what is being debugged. Usually anywhere from 5-10 additional panels, though some things have been debugged with much more.

The User Experience problem I've encountered is really due to reordering; when doing a bugfix or new feature implementation it is often desired to shift a particular panel into the first/leftmost position or group several related panels together. With the old behavior, that was simple to accomplish; with the current behavior, every desired panel must be listed. This behavior is fine when you're dealing with the default/shipped panels, but complicates things when dealing with custom or 3rd party panels. I'm trying to stick to a habit of every addon package or internal component being able to register a toolbar for debugging - which has been incredibly timesaving.

[mmerickel]

what about some sort of client-side drag/drop re-ordering that can be stored in local storage?

[jvanasco]

what about some sort of client-side drag/drop re-ordering that can be stored in local storage?

wow, @mmerickel - that's a great idea. that approach could even enable/disable the display of panels, while still having them processed/served. this sounds like my next weekend project!