Interesting is that [...] pay for bug fixes.
Wow, they must be rich. Wish I had one Euro for every bug.
Yes, if a user would like to move several tabs, this could lead to
Even if the user only moves one tab. As long as the user keeps moving the mouse, the tab must be deleted and re-inserted every time it moves one position up or down.
Alternatively, you could show a little marker like they do it in Firefox, but that is quite lame, to be honest. It looks like "hey sorry, we can't afford to do it in real time". In fact, when I first used that feature, I did not even see this little blue arrow. I kept moving the mouse and wondered why the tab did not move...
Hmmm. I thought that if you insert a page where another page exists already, the old page would be automatically deleted.
My fault because I used wrong terminology. You do not have ownership of the page or the contained child (editor in this case), so you must not
delete it.
But: You still have to get rid of the page somehow, or else the user will see two pages. For this, you can call the notebook's
RemovePage() or
DeletePage() functions. In the former case, the child window is not touched (It is not specified who owns the object afterwards. So maybe you could re-add it, supposed you have kept a pointer to it, but who knows...), and in the latter case, it is deleted along with the page (which would be quite bad).
What really happens if you do something like
noteBook->Insert(GetPage(someIndex)->GetChild(), someOtherIndex); noteBook->Remove(someIndex); is rather obscure... I seriously doubt it will work, and I would not want to work with such code -- you are juggling with objects that you don't necessarily own and whose allocation state you don't control (or even know).
All in all, this smells of a lot of problems (for a rather small advantage).