Opened 12 years ago

Last modified 3 years ago

#10185 new enhancement

Implement Minimize of wxAui Panes

Reported by: ninjanl Owned by:
Priority: normal Milestone: 3.2.0
Component: wxAui Version: stable-latest
Keywords: wxAuiManager wxAuiPaneInfo Cc: erudix@…, kinaou.herve@…
Blocked By: #13210, #13210 Blocking:
Patch: yes

Description

It is possible for panes to be maximized, wherein they completely cover the client area. It should also be possible to minimize the panes, so that they are effectively removed from the client area.

This patch implements something similar to the minimizing functionality of Eclipse.

Each pane can have a minimize button, (and the auidemo sample is altered so that all panes get a minimize button - not sure if this is desired, but it is a simple matter to add ".MinimizeButton(true)" where required). Clicking on this minimize button causes a new wxAuiToolbar to be created and added to the frame manager, (currently the implementation is such that panes at West will have a toolbar at the right, panes at South will have toolbars at the bottom etc.) and the pane is hidden in the manager.

Clicking on the restore button on the newly created toolbar will result in the toolbar being removed and the original pane being restored.

My current setup is Vista home premium/wxWidgets SVN HEAD/wxMSW/Visual Studio 2005

Attachments (2)

wxAuiMinimize.patch download (21.5 KB) - added by ninjanl 12 years ago.
wxAuiMinimize_VerticalClockwiseLabel_wx29.patch download (64.5 KB) - added by R.U.10 7 years ago.

Download all attachments as: .zip

Change History (28)

Changed 12 years ago by ninjanl

comment:1 Changed 11 years ago by R.U.10

I implemented the ability of creating toolbar tools with [counter]clockwise rotation. This allows to propose a variant of the minimizing functionality with a rotated button which keeps the caption of the pane as label.

I also altered the auidemo sample to see the new abilities.

comment:2 Changed 11 years ago by R.U.10

I added:

  • some flags which allow to choose the orientation and the position of the minimized panes
  • the functions [Get]MinimizeMode() in wxAuiPaneInfo which allow to set/get the flags described above
  • some items in the Options menu of the sample dialog box which allow to test the different position flags
  • a clockwise rotated menu bar on the right of the sample dialog box

I also:

  • reviewed the calculation of the position of the bitmap and the text of the tool bar tools
  • centralized the above calculation in a single function wxAuiDefaultToolBarArt::GetToolsPosition()
  • centralized the label drawing in a single function wxAuiDefaultToolBarArt::DrawLabel()
  • centralized the calculation of the label size in a single static function wxAuiToolBar::GetLabelSize()
  • corrected a memory leak in the function wxAuiManager::MinimizePane
  • updated the doc

About the doc, I did not find the documentation of the class wxAuiToolBar for adding the description of the tool bar tools rotation flags...

Thank you NinjaNL for your original patch !

When I would have more time I would implement a roll up style of minimization for detached panes.

comment:3 follow-up: Changed 11 years ago by rk

The patch is made against the 2.9 branch. But I guess now that 2.9 has already had two release candidates this won't get included into 2.9. So could you please make the patch against the current trunk, because I'd really like to see this in action. ;-)

comment:4 follow-up: Changed 11 years ago by biwillia76

While this is great functionality, I would like to know if this can be implemented without creating additional window panes automatically. A layout mechanism that doesn't automatically create windows for the user promotes statefullness that is essential to the serialization mechanism. Thanks for your patch.

comment:5 in reply to: ↑ 3 Changed 11 years ago by R.U.10

Replying to rk:

The win32 executable demo is available here, until I recreate the patch with the wx2.9 trunk.

comment:6 in reply to: ↑ 4 Changed 11 years ago by R.U.10

Replying to biwillia76:

(...)I would like to know if this can be implemented without creating additional window panes automatically (...)

The standard behavior is to create an new wxAuiToolBar and to hide the window pane. Is this the toolbar creation you want to see disappear?
Consequently, if I well understand, the concerned window pane would have a real minimized appearance and should be independent of the toolbar process (like the "Auto Hide" option of the Visual Studio panes)?
In this case, probably the wxAuiTabArt would be helpful and the wxAuiNotebook could benefit of the new rotation abilities.

comment:7 Changed 11 years ago by R.U.10

  • Cc erudix@… added

Patch regenerated with the last SVN trunk revision (no new implementation).

comment:8 Changed 9 years ago by R.U.10

  • Blocked By 13210 added

comment:9 follow-up: Changed 9 years ago by triton

Can you re-upload the demo? The link is broken.

Can you also re-regenerate the patch updated to trunk?

comment:10 in reply to: ↑ 9 Changed 9 years ago by R.U.10

  • Cc kinaou.herve@… added

I update the patch regularly so you can use it as is and compile the aui sample. It's more lasting than external links.

But new features are implemented in the trac #13210 for the handling of the toolbar. When the trac will be treated I will come back on the minimization behavior. Because IMHO the actual patch implements two complementary things but which should be treated separately.

comment:11 Changed 9 years ago by vadz

  • Blocked By

(In #13210) This patch seems more extensive but doesn't it duplicate the work of #11712 (see also r65061)? I.e. I think we already support toolbars which can be used in any orientation, don't we?

comment:12 Changed 9 years ago by R.U.10

  • Blocked By

(In #13210) The work of #11712 implements the auto orientation of the toolbar according to the place where it is docked but the toolbar tools always stay horizontal.

My work is complementary because it implements the rotation of the toolbar tools depending on the orientation of the toolbar (text and icons are rotated of 90 or 270°).

I'm opened to discuss on the name to give at the functions and style macros to be more explicit. For example:
void SetOrientation(int a) { orientation = a; } could be renamed in
void SetRotation(int a) { rotation = a; }

wxAUI_TBTOOL_VERT_COUNTERCLOCKWISE could be
wxAUI_TBTOOL_VERTICAL_270

etc.

comment:13 Changed 9 years ago by vadz

  • Blocked By

(In #13210) Replying to R.U.10:

The work of #11712 implements the auto orientation of the toolbar according to the place where it is docked but the toolbar tools always stay horizontal.

My work is complementary because it implements the rotation of the toolbar tools depending on the orientation of the toolbar (text and icons are rotated of 90 or 270°).

Ah, I see, thanks. Is it common to do this? I don't believe I've actually seen the tools rotate themselves like this in any of the applications I use.

I'm opened to discuss on the name to give at the functions and style macros to be more explicit. For example:
void SetOrientation(int a) { orientation = a; } could be renamed in
void SetRotation(int a) { rotation = a; }

wxAUI_TBTOOL_VERT_COUNTERCLOCKWISE could be
wxAUI_TBTOOL_VERTICAL_270

etc.

We definitely need to use some more clear names than "orientation" because this word is used for horizontal/vertical in many places in wx. Maybe "rotation" is indeed more clear. I'm still not sure to understand what do the constants above mean though, isn't the rotation determined by the orientation? I.e. if the toolbar is normally horizontal but is currently docked on the left, then the buttons should be rotated by 270 degrees, if it's docked on the right -- by 90 degrees (and I have no idea what should happen if it's docked at the bottom).

comment:14 Changed 9 years ago by R.U.10

  • Blocked By

(In #13210) Replying to vadz:

Replying to R.U.10:

implements the rotation of the toolbar tools (text and icons are rotated of 90 or 270°).

Is it common to do this? I don't believe I've actually seen the tools rotate themselves like this in any of the applications I use.

You are right but my initial idea was to release this behavior in prerequisite to the minimization of the AUI panes (see the blocked trac) even if I think now that it should be better to implement the rotation for the wxAuiNotebook tabs and to use a tab for the minimized pane state.
That said, I find that keeping the horizontal orientation of the toolbar tools is not aesthetic when the tools contain text, the toolbar can become very wide. So I propose this patch if it looks worthwhile for other people than me (you decide).

if the toolbar is normally horizontal but is currently docked on the left, then the buttons should be rotated by 270 degrees, if it's docked on the right -- by 90 degrees (and I have no idea what should happen if it's docked at the bottom).

If the toolbar is docked at the bottom, IMHO it is a little bit extravagant to have a 180° rotation so I did not implemented it, the tools are horizontal.
I don't know if it is desirable to rotate the text differently on the right and on the left. I think it could be disorienting. But perhaps some will prefer one direction over another, thats why I give the possibility to choose the both. But in the auto-rotation mode, the rotation is the same on the right and on the left (but I can modify it if you feel it is better to have a different rotation).

comment:15 Changed 9 years ago by vadz

  • Blocked By

(In #13210) I didn't think about text but it does make sense to rotate it so I agree such functionality would be useful.

I think that rotating the text differently depending on whether the toolbar is docked on the left or right would be better, but this could be an option. So basically I see the following different modes of operation:

  • No rotation at all (default).
  • Automatic rotation as necessary (which would do what I suggest just because there doesn't seem any better way to name it).
  • Fixed rotation by 90 or 270 degrees (or clock- or counter-clockwise, as you prefer) to have the same orientation in both cases.

What do you think?

Also, what about the relationship with auto-orientation at the API level? I initially though it should be an error to specify the rotation for non-auto-orientable toolbar but now it looks like it could be useful for vertical toolbars too. Using any non-default rotation for the fixed horizontal toolbars should probably still be an error though?

comment:16 Changed 9 years ago by R.U.10

  • Blocked By

(In #13210) Replying to vadz:

What do you think?

That sounds good to me.

Using any non-default rotation for the fixed horizontal toolbars should probably still be an error though?

Not necessarily an error but a no effect option.

comment:17 Changed 9 years ago by R.U.10

  • Blocked By

(In #13210) Ok, I updated the patch with the recommendations, that seems good now.

I'm undecided about the name of the flag which defines "auto-orientation and auto-rotation text and icons":
wxAUI_TB_SMART_TEXT
wxAUI_TB_AUTO_TEXT
wxAUI_TB_SPIN_TEXT
...
I defined wxAUI_TB_SPIN_TEXT but I think it could be confusing with the spin control, what is your opinion?

comment:18 follow-up: Changed 7 years ago by from_mars

Thanks for your patch and sory for my english.

There are no such strings in wxWidgets 2.8.12 framemanager.h:

extern WXDLLIMPEXP_AUI const wxEventType wxEVT_AUI_PANE_RESTORE;
extern WXDLLIMPEXP_AUI const wxEventType wxEVT_AUI_RENDER;
extern WXDLLIMPEXP_AUI const wxEventType wxEVT_AUI_FIND_MANAGER;
.

They replaced by:

DEFINE_EVENT_TYPE(wxEVT_AUI_PANE_RESTORE)
DEFINE_EVENT_TYPE(wxEVT_AUI_RENDER)
DEFINE_EVENT_TYPE(wxEVT_AUI_FIND_MANAGER)
.

When i manuly added:

DEFINE_EVENT_TYPE(wxEVT_AUI_PANE_MINIMIZE)
DEFINE_EVENT_TYPE(wxEVT_AUI_PANE_MIN_RESTORE)

and everything compiled without errors.

3.
I compiled aui sample and ran it on Windows 7 64. Then I found it in Proccess Explorer, and there is such a thing - every time i minimizing panel with minimize button and then restoring it from created toolbar, Memory Working Set parameter in Proccess Explorer, grows up to about 24 Kbyte.
Could it be a memory leak?

comment:19 in reply to: ↑ 18 Changed 7 years ago by R.U.10

Replying to from_mars:

Thank you for reporting that.

3.
Could it be a memory leak?

That was due to the creation of the toolbar during the pane minimization.
There was no memory leakage because the toolbar was properly deleted at the application closing, but it was not very clean.

I corrected all in the updated patch.

Regards

comment:20 follow-up: Changed 7 years ago by vadz

  • Blocked By
  • Milestone set to 3.2
  • Status changed from new to confirmed

As usual, I'm going to struggle to review the patch of this size, especially in still unfamiliar to me wxAUI code. I wonder if splitting the text rotation patch could make it more manageable?

Any help/review from others (Jens Lody, mmarsan, ...) would be very welcome!

comment:21 in reply to: ↑ 20 Changed 7 years ago by jens

Replying to vadz:

Any help/review from others (Jens Lody, mmarsan, ...) would be very welcome!

I will see if I find the time to look into it as soon as possible.

comment:22 follow-up: Changed 7 years ago by from_mars

  • Status changed from confirmed to infoneeded_new

For catching wxEVT_AUI_PANE_MIN_RESTORE event, i need use such code:

//wxAuiManager    m_mgr;
m_mgr.Bind(wxEVT_AUI_PANE_MIN_RESTORE, &wxContainerDBFrame::OnPaneRestore, this);

But for wxEVT_AUI_PANE_MINIMIZE, i can use such:

Bind(wxEVT_AUI_PANE_MINIMIZE, &wxContainerDBFrame::OnPaneMinimize, this);

Does it normal?

comment:23 Changed 7 years ago by vadz

  • Status changed from infoneeded_new to new

No changes, just resetting the (probably accidentally) changed status.

comment:24 in reply to: ↑ 22 Changed 7 years ago by R.U.10

Replying to from_mars:

It's due to the processing of the event MIN_RESTORE which is not redirected to the manager's frame like the others. See the commented line in the file auibar.cpp l.2773:

                    //manager->ProcessMgrEvent(e);
                    manager->ProcessEvent(e);

Uncommenting this line (and commenting the following) will probably resolve the issue but I don't know why this line is commented (is there unexpected border effects?).

ninjanl is the author of this part of code, perhaps he can say more than I?

comment:25 Changed 7 years ago by vadz

  • Blocked By

(In #13210) This should be dealt with as part of AUI rewrite/refactoring.

comment:26 Changed 3 years ago by hackish

manager->ProcessMgrEvent(e);
manager->ProcessEvent(e);

As above, ProcessMgrEvent(e) is private and cannot be called here.

I did take all these patches and apply them against the nhold branch of aui which I have been running for a number of years. Unfortunately it does not process the wxEVT_AUI_PANE_MIN_RESTORE event properly nor work as I would have expected.

I think for the future re-write, a floating pane should be allowed to be minimized as this patch attempts, but a docked pane should probably roll up to a toolbar only state.

Note: See TracTickets for help on using tickets.