Free the Editors

[thomas]

However, if you want state information about window positions to be stored persistently the application is going to have to know at least something about state of the windows, no?

Not having looked at it, I would assume this is saved with all of wxAUI's state when you call the serialize/unserialize functions. That's the "normal" behaviour I would expect, anyway. It is not my problem where a window is, or what it's attached to, or how to save/restore that state. wxAUI has to know and nobody else. We should just need to tell wxAUI: "give us a serialized representation of your state"

all nice but I don't see how you could avoid writing a bunch of new code to get it  :lol:

Well, for the simple case of only two views, the idea would be to just create a second editor, and tell AUI to place one on top, and the other on bottom. Each editor would need a "sibling pointer" obtained by Clone() and freed by Release(), so we're taking advantage of wxWidgets' ref-counting and avoid illegal pointers.
The one editor that has the focus forwards all Scintilla edit events to its sibling. If the user gives focus to the other one, that one will forward events. Thus, you would have two editors that are always in sync. Now, on save, reset the sibling to "not modified", and you should have everything you need... in principle.
Does not seem so terribly complicated as an idea.

I've no problem with such move. Most (I think all) of the wx-2.8 related issues are resolved now.

And since the project files were changed to link against the 2.8 library, building for 2.6 is a PITA anyway 
But seriously, I don't think it's a major issue if wx 2.8 is not available on some platforms, it is only a matter of time. The tab-placement feature missing in AUI is probably only temporary, too. It should be a no-timer to implement placement on bottom, they just haven't done it to date.

[rjmyst3]

The tab-placement feature missing in AUI is probably only temporary, too. It should be a no-timer to implement placement on bottom, they just haven't done it to date.

agreed - there are already styles defined for moving the tabs to the sides and bottom, just not yet implemented.

We should just need to tell wxAUI: "give us a serialized representation of your state"

This is the bigger problem with wxAUINotebook. It is self contained. It does not participate in the Save/LoadPerspective() of the wxAUIManager. I think it has it's own wxAUIManager within itself, but it does not even save/load its own perspective.

So, it will be easy to tear tabs and dock them within the bounds of the wxAUINotebook, however, I don't think you'll be able to dock them to other parts of Code::Blocks, nor will you be able to save/restore where they are - without workarounds, anyway.

Maybe this is acceptable, maybe not. Just food for thought.

[dmoore]

It is not my problem where a window is, or what it's attached to, or how to save/restore that state. wxAUI has to know and nobody else. We should just need to tell wxAUI: "give us a serialized representation of your state"

two complications:
1. as far as I can tell wxAUINotebook doesn't support the concept of detaching pages from the notebook entirely and letting them float. you can move pages from one notebook to another or divide up the notebook, but I don't think that either of these options is satisfactory for notebooks like the message manager. Thus, if you want fully detachable pages I think some coding of either a sub-classed notebook or message manager to spawn new dockable windows (or even dockable notebooks) is unavoidable. I'm not talking about a lot of coding, though...
2. the serialized state has to be synchronized with the initialization of windows. e.g. plugins must register their dockables with cb before their state is loaded. If we want a detached build messages log to persist between sessions, we will need to register its dockable somewhere so that on restart it gets initialized in a dockable... (I'm also not sure that the current implementation of wxAUI_NB_TAB_EXTERNAL_MOVE in wxAUINotebook saves any state information about tabs moved to new notebooks (e.g. a message manager notebook page moved to the project notebook))

Well, for the simple case of only two views, the idea would be to just create a second editor, and tell AUI to place one on top, and the other on bottom. Each editor would need a "sibling pointer" obtained by Clone() and freed by Release(), so we're taking advantage of wxWidgets' ref-counting and avoid illegal pointers.
The one editor that has the focus forwards all Scintilla edit events to its sibling. If the user gives focus to the other one, that one will forward events. Thus, you would have two editors that are always in sync. Now, on save, reset the sibling to "not modified", and you should have everything you need... in principle.
Does not seem so terribly complicated as an idea.

sounds good to me   (my only point was that wxAUI doesn't do this for you, it just helps a little - but probably no more than wxFlatNotebook)

[David Perfors]

1. as far as I can tell wxAUINotebook doesn't support the concept of detaching pages from the notebook entirely and letting them float. you can move pages from one notebook to another or divide up the notebook, but I don't think that either of these options is satisfactory for notebooks like the message manager. Thus, if you want fully detachable pages I think some coding of either a sub-classed notebook or message manager to spawn new dockable windows (or even dockable notebooks) is unavoidable. I'm not talking about a lot of coding, though...

Strange I thought it was possible to detach the pages. But when trying to do so (in a program which uses AUINotebook) it doesn't work. You can move them between other notebooks...

[dmoore]

How about we define a new notebook class cbNotebook that offers a core set of features to the main CB app and plugins? These features would include the usual add/remove/select page, and some persitency code to allow users to define the ordering of their notebook pages in static books that would get called when the CB layout is saved/loaded. Then we can drop-in wxFlatNotebook, wxAUINotebook or any other notebook we feel like for cbNotebook's implementation and not have to worry about breaking the main app.

In addition to detachable pages that I've been working on, cbNotebook could also offer features like a proper z-order (nothing is more frustrating than closing a file and having its neighbor selected instead of the last selected file), draggable tabs etc all of which would be invisible to the sdk user.

[raph]

How about we define a new notebook class cbNotebook that offers a core set of features to the main CB app and plugins? These features would include the usual add/remove/select page, and some persitency code to allow users to define the ordering of their notebook pages in static books that would get called when the CB layout is saved/loaded. Then we can drop-in wxFlatNotebook, wxAUINotebook or any other notebook we feel like for cbNotebook's implementation and not have to worry about breaking the main app.

I think writing a notebook control from scratch is a waste of time and resources.
I think we should extend wxAuiNotebook (which nearly already supports all the features we need) to fit our needs, since it already comes with wxWidgets.
wxAuiNotebook would be a perfect candidate for the open files notebook, since it allows splitting of tabs (here: open files) in a very intuitive way (I think being able to dock the main tabs to the/into the other panes ("Messages", "Management"...) is unintuitive and confusing).
Anyway the other notebooks ("Messages", "Management"...) really need a "detach" feature, since splitting the tabs isn't enough here.

In addition to detachable pages that I've been working on, cbNotebook could also offer features like a proper z-order (nothing is more frustrating than closing a file and having its neighbor selected instead of the last selected file), draggable tabs etc all of which would be invisible to the sdk user.

Hm, never realized this. Never saw an application which implemented that behavior.

[dmoore]

I think writing a notebook control from scratch is a waste of time and resources.

If you read my post more carefully I didn't say anything about writing a notebook from scratch . As you say we would drop in wxAuiNotebook or wxFlatnotebook to provide the core of the implementation.

I think we should extend wxAuiNotebook (which nearly already supports all the features we need) to fit our needs, since it already comes with wxWidgets.

I don't have a strong preference either way, but I agree it will be easier to maintain one external GUI dependency instead of two

wxAuiNotebook would be a perfect candidate for the open files notebook, since it allows splitting of tabs (here: open files) in a very intuitive way

i still need to see it in action. I can also see wanting to detach files from the notebook altogether

(I think being able to dock the main tabs to the/into the other panes ("Messages", "Management"...) is unintuitive and confusing).

i can't imagine using it either. but more generally people might want to create their own notebooks and collect tabs in them as they see fit.

Anyway the other notebooks ("Messages", "Management"...) really need a "detach" feature, since splitting the tabs isn't enough here.

I've implemented this as a right click menu option (well, at least for messages, I'm in the process of adding the default right click menu option to detach pages to my tearawaynotebook class to handle the management notebook).

[raph]

i still need to see it in action.

Do you mean wxAuiNotebook? There is a sample in wx_src_dir/samples/aui.

[dmoore]

I was just being lazy about building the sample (because I had to rebuild wx). anyway, I've done it now. very impressive tab splitting and, obviously, the notebooks are more consistent with wxAUI theming. I think upgrading to wxAuiNotebook makes sense, but I still think wrapping it in a cbNotebook class is agood idea from a maintainability/extensibility viewpoint.

[zarnce]

Thanks for the proof of concept.  I was starting to look through the code in my free time to make the editors movable.

Thanks
  Zarnce

[dmoore]

no problem - it is a feature whose absence was annoying me too. you can see the buggy patch in all its glory via my cbilplugin project's svn http://developer.berlios.de/svn/?group_id=7745
(the latest win32 build is also available there) the file is under trunk/CBExperimental/edfree-win32.patch. (I'll commit a patch with fewer bugs later tonight)

[Huge]

Hi sorry about using an old thread.
I have written some code for wxAUI that does "auto notebooks".  In these, a notebook is created by docking 2 more more items together.  You can rip them out and dock them back in somewere else - say next to each other.  You can also drag out some of your code windows and dock them together on, say, a second monitor.
See: http://gamemosaic.com/auimod/index.html for some changes and a windows executable demo.
Let me know if you find this interesting.

Huge

[raph]

Looks like that is exactly what we need .
This wxAUI mod would make all the tabs we have (Projects, Symbols, Resources, Code::Blocks, Search Results, ... even Open files list and all the plugin panes) fully user customizable and we wouldn't have to hardcode their locations anymore.
For the file-tabs we could use wxAuiNotebook cause of its splitting-ability.