wxWidgets / wxWidgets

Cross-Platform C++ GUI Library
https://www.wxwidgets.org/
6.32k stars 1.79k forks source link

Allow forbidding dragging individual wxAuiNotebook tabs #25074

Closed vadz closed 3 days ago

vadz commented 3 weeks ago

(BTW, can locked tabs still be moved to another position in the "locked tabs" group or should even this be forbidden?).

We would like to forbid this. Might be nice to make this configurable in case some other users don't want to forbid it.

Originally posted by @craftyjon in https://github.com/wxWidgets/wxWidgets/issues/25072#issuecomment-2585795475

vadz commented 3 weeks ago

To forbid dragging an individual tab we just need to make wxEVT_AUINOTEBOOK_BEGIN_DRAG vetoable, which should be quite simple, I'll do it soon.

vadz commented 2 weeks ago

This was indeed simple to do (although, as usual, not without unforeseen problems as event propagation in AUI notebook code is weird), please see #25095 (and please ignore the other commit referenced above as I accidentally used a wrong issue number in it).

However I'm not so sure if we should apply this any more because, after testing it, this just doesn't seem useful: even if you forbid dragging the first tab, as the updated sample does, you can still change its position by dragging other tabs in front of it, and so achieve the same result as if you had dragged this tab in the first place — and what is the point of forbidding to do it then?

So if we do this, we probably also need to allow vetoing END_DRAG event, but this would make things a bit difficult for the application, as it would have to check for the same condition in both handlers and it looks like it would be just simpler to mark the tab as "fixed", as discussed in the original #25072.

Anyhow, please let me know if

  1. Just the current changes in #25095 would be useful for you.
  2. If these changes augmented with END_DRAG vetoing would be useful.
  3. Or if we should forget about this and just implement fixed/locked tabs instead.

TIA!

craftyjon commented 2 weeks ago

However I'm not so sure if we should apply this any more because, after testing it, this just doesn't seem useful: even if you forbid dragging the first tab, as the updated sample does, you can still change its position by dragging other tabs in front of it, and so achieve the same result as if you had dragged this tab in the first place — and what is the point of forbidding to do it then?

I guess it only makes sense if you can also pin these tabs so that it is impossible to drag other tabs in front

vadz commented 2 weeks ago

Just to make sure I am explaining myself correctly: by allowing to veto END_DRAG, we could allow the application to implement its own version of "pinned" tabs, but the question is whether it's worth doing this knowing that we'll support pinned tabs in wxAUI itself directly soon? I.e. are there any situations (in particular in KiCad) where you'd like to avoid dragging tabs without pinning/locking them? E.g., I don't know, to avoid changing the right most tab (not that I see any point in doing this)? Or maybe to effectively pin them without showing the "pin" icon and allowing to unpin them (but without locking them completely)?

If not, I think we should drop this PR/issue and only provide pinned/locked tabs. FYI currently I have this (but I haven't finished implementing it yet):

// Tabs are normal by default but can be given a special state.
enum class wxAuiTabKind
{
    Normal, // Can be closed and dragged by user.
    Pinned, // Can be closed but can't be dragged. Can be unpinned by user.
    Locked  // Can't be closed, dragged nor unlocked by user.
};
craftyjon commented 2 weeks ago

are there any situations (in particular in KiCad) where you'd like to avoid dragging tabs without pinning/locking them?

Not in KiCad, not that I can think of.

vadz commented 3 days ago

I'm going to close this one, as it doesn't make much sense independently of #25072 itself, finally, sorry for not realizing it initially.