wxAui: Allow restriction of where a given floating pane can dock (Issue #23985)
Jon Evans
Description
It would be useful to be able to define how an AUI panel that can be floated can be re-docked, rather than the current situation where if a panel is allowed to be floated, it can be re-docked anywhere the user drops it.
Taking the KiCad PCB Editor as an example: We have an AUI setup on the right side of the window with a toolbar (pink), a fixed-size pane (green), and variable-size pane (blue) in the screenshot below.
The toolbar is fixed, but the other two panes can be torn out (floated). If the user tears out one of the panes, we want to control the following:
- We only want to allow the panes to be re-docked on the outside of the toolbar (to its right) not to its left
- We only want a single column of panes; we don’t want to allow creating two columns with “Appearance” and “Selection Filter” side-by-side
This should work well with both fixed-size and variable-size panes. For example, the green pane is supposed to be fixed-height and the blue pane is supposed to grow to the rest of the column height. The user should be able to reorder them (e.g. put the green pane on top of the blue pane) when tearing out and re-docking them, but any other state should be prevented.
Implementation thoughts
I don't have strong opinions on how this is exposed or implemented, but maybe it would look something like being able to set layers that are allowed to be drop targets? Right now, the biggest issue with the existing functionality is that not only can we not prevent the user from placing the docked panels to the left of the toolbar, but it is impossible to place them back on the right (if both panels are floated out).
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Andrea Gavana
Description
It would be useful to be able to define how an AUI panel that can be floated can be re-docked, rather than the current situation where if a panel is allowed to be floated, it can be re-docked anywhere the user drops it.
Taking the KiCad PCB Editor as an example: We have an AUI setup on the right side of the window with a toolbar (pink), a fixed-size pane (green), and variable-size pane (blue) in the screenshot below.
The toolbar is fixed, but the other two panes can be torn out (floated). If the user tears out one of the panes, we want to control the following:
- We only want to allow the panes to be re-docked on the outside of the toolbar (to its right) not to its left
- We only want a single column of panes; we don’t want to allow creating two columns with “Appearance” and “Selection Filter” side-by-side
This should work well with both fixed-size and variable-size panes. For example, the green pane is supposed to be fixed-height and the blue pane is supposed to grow to the rest of the column height. The user should be able to reorder them (e.g. put the green pane on top of the blue pane) when tearing out and re-docking them, but any other state should be prevented.
Implementation thoughts
I don't have strong opinions on how this is exposed or implemented, but maybe it would look something like being able to set layers that are allowed to be drop targets? Right now, the biggest issue with the existing functionality is that not only can we not prevent the user from placing the docked panels to the left of the toolbar, but it is impossible to place them back on the right (if both panels are floated out).
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
--
You received this message because you are subscribed to the Google Groups "wx-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wx-dev+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wx-dev/wxWidgets/wxWidgets/issues/23985%40github.com.
Andrea Gavana
I’ve never seen a wxAUI-based app in which you could dock a pane on the left of a left toolbar (or top of a top toolbar or…).
Is your toolbar a standard wxToolBar or a wxAUI one? Are you docking it with ToolbarPane() in you wxAUI manager?
I’m not 100% sure about it though, I only use the pure-Python port of wxAUI in wxPython: that said, can you dock a pane above the toolbar in the wxAUI sample? 😳
As for the rest of your request (and the others you just sent in separate GitHub issues), you might be able to adapt some of the Python code in the wxPython-based AUI as quite a few of the things you ask can already be done there - or could relatively easily be implemented.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Jon Evans
Is your toolbar a standard wxToolBar or a wxAUI one?
Custom class derived from wxAuiToolbar
Are you docking it with ToolbarPane() in you wxAUI manager?
We don't use ToolbarPane(), we use custom wxAuiPaneInfo classes. I can check if re-implementing ToolbarPane() helps, in which case this probably needs to be exposed better.
can you dock a pane above the toolbar in the wxAUI sample?
Don't know, but if there is implicit control over positioning for toolbars in particular, this still needs to be made explicit in a way that can be applied to arbitrary panes. The toolbar in my screenshot is just an example.
As for the rest of your request (and the others you just sent in separate GitHub issues), you might be able to adapt some of the Python code in the wxPython-based AUI as quite a few of the things you ask can already be done there - or could relatively easily be implemented.
Per discussion with @vadz, my requests are opened here in order to get this functionality into upstream wx, which is what we'd prefer to pursue rather than re-implementing it in our application.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Jon Evans
I can check if re-implementing ToolbarPane()
ToolbarPane does not fix the issue, just introduces unwanted grab handles on the toolbar (we don't want the user to be able to move the toolbars around at present)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Andrea Gavana
I can check if re-implementing ToolbarPane()
ToolbarPane does not fix the issue, just introduces unwanted grab handles on the toolbar (we don't want the user to be able to move the toolbars around at present)
I just run a marginally modified version of the wxAUI sample, in which a vertical toolbar is added to the wxAUI manager like this (it's Python, but it's irrelevant as it uses the underlying C++ wxAUI implementation):
self._mgr.AddPane(tb5, aui.AuiPaneInfo().
Name("tbvert").ToolbarPane().
Left().Fixed().Gripper(False).
Floatable(False))
Which ends up looking like this (notice the toolbar with large buttons on the left):
I can't dock anything on the left of this toolbar, at least on Windows 10, wxWidgets 3.2.2.
As for the toolbar "grab handles" - for which I assume you meant "gripper", the very useful:
Gripper(False)
Method may be your friend.
I am pretty sure this does not solve your general use case, but contrary to your convictions, it does what it's supposed to be doing with a toolbar.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
I think that if we allow restricting where a pane can be docked (which is what I think you propose too, right?), it would answer most of, if not all, the points here.
E.g. toolbars are in the layer 10 (auiToolBarLayer) in wxAUI, so letting a pane be docked only in layer 11 or greater would force docking it only beyond the toolbar. And restricting it to exactly the layer 11 should prevent creating the layer 12 which would be appear if you docked them side by side.
But please let me know if you think this is insufficient -- or see any other problems with doing this. If not, I'll try to implement support for this relatively soon.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Bryan Petty
It's been a long time, and I can see that this is still undocumented API, but I seem to recall that it's possible to completely customize exactly what dock locations you want to allow for any/all panes by deriving your own wxAuiManager, and overriding ProcessDockResult already:
Just return false for any special condition/location you can account for in this special case, and don't forget to call the base implementation otherwise.
It's not the most convenient API, but this is meant to open the door for more complicated functionality other than the basic "bottom", "top", "left", "right" dockable settings for panes. You can see how this virtual method implements those four in the base implementation:
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
Thanks Bryan! It indeed looks like it could be used to implement the kind of control KiCad needs. Restricting the docking layer would be more convenient/declarative, but I don't know if it's worth implementing this if you're going to override ProcessDockResult() anyhow, what do you think @craftyjon ?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Jon Evans
@vadz @tierra I'll look at that approach, thanks. If it's not too much work it could be a good path. What we have seen when working with other parts of AUI is that we have to re-implement more than is desirable when deriving some classes (I should probably make reports for those too at some point)
@infinity77 The AUI sample has all floatable / movable toolbars. KiCad does not. I could try to modify the AUI sample until it starts behaving like KiCad, but instead I'll probably just work on fixing the behavior as described above.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
I could try to modify the AUI sample until it starts behaving like KiCad, but instead I'll probably just work on fixing the behavior as described above.
FWIW I think it would be great if you could add something KiCad-like to the aui sample (I think adding an entirely new window, which could be opened from a menu, would be simpler than modifying the existing layout, but either would be fine for me). It would be much simpler to discuss and, especially, test things if we could apply to a simple example that anybody could build/test.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
@craftyjon Almost one year has passed since the last update but I still don't know what to do about this one. As I wrote before, I think we could implement restriction on docking in the given layer only, but I'm still not sure if this is what you actually want/need. I could do it anyhow, of course, as it does seem like it could be generally useful, but I'd rather implement something based on the real users needs if possible.
For now I'm resetting the milestone on this one as I can't really proceed with it.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Jon Evans
Understood, I think the next step is for us to implement something inside of KiCad, and identify any places we run up against the bounds of the wx API more clearly. I haven't had time to do this yet.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
Thanks! This is not particularly urgent/important from my point of view, but it would be great if KiCad could use 3.3.0, when it's released, to make its AUI code simpler. And I do hope to release it relatively soon, although this still probably means 2025 by now...
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.