Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

Free the Editors

<< < (7/9) > >>

thomas:

--- Quote ---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?
--- End quote ---
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" :)


--- Quote ---all nice :) but I don't see how you could avoid writing a bunch of new code to get it  :lol:
--- End quote ---
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.


--- Quote ---I've no problem with such move. Most (I think all) of the wx-2.8 related issues are resolved now.
--- End quote ---
And since the project files were changed to link against the 2.8 library, building for 2.6 is a PITA anyway  8)
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:

--- Quote from: thomas on July 03, 2007, 03:53:53 pm ---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.

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


--- Quote from: thomas on July 03, 2007, 03:53:53 pm ---We should just need to tell wxAUI: "give us a serialized representation of your state" :)

--- End quote ---
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:

--- Quote from: thomas on July 03, 2007, 03:53:53 pm ---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" :)

--- End quote ---

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))


--- Quote ---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.
--- End quote ---

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:

--- Quote from: dmoore on July 03, 2007, 06:15:40 pm ---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...
--- End quote ---
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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page