Overlapping source code windows

[TheWiz]

Does C::B support multiple overlapping source code windows that I can position wherever I want on my monitors?

I see its standard config uses the now popular tabbed editing method (just like Eclipse), where you can have multiple open source windows (each representetd by a tab), allowing you to easily switch between them. However, with this method, you can generally only see one source window at a time.

I personally find this way of working extremely annoying, and would not be willing to adapt to such an IDE. I bought my two large LCD monitors for a reason. The powerful concept of multiple overlapping windows, which can be arranged in any way I see fit, was invented some 20 years ago. I don't quite feel like going back to that tiled Windows-version-1-style look now  :shock:.

If this is currently not a possibility, I think it could make sense to add this capability to a future version. I.e., providing the option of either haing a "docked" desktop, where all windows are tiled (not overlapping), and live within their own little boxes. Or a free-format desktop where each window lives in its own, intependently positionable, window, where multiple overlapping source windows can be visible at the same time. If this is already possible with C::B, perhaps someone can enlighten me.

[MortenMacFly]

You can eighter run a second instance of C::B or (as I do) configure a tool for source code inspection. For this I use SciTE. Anyway: Please note that there is a lot of functionality inside C::B that IMHO helps navigating in source code a lot better than a second window. I think of bookmarks, the symbol browser, easily switching between source/header etc...
With regards, Morten.
Ps.: Just a wild guess: Did you use something like emacs before?

[thomas]

I personally find this way of working extremely annoying, and would not be willing to adapt to such an IDE.

In that case, I am afraid you will have to look for a different IDE.

Personal preference put aside, at the time being, there is no way we could support this from a purely technical point of view. It may be not much of a problem if we switch to a different docking library (wxIFM) at some future time, or if the current one (wxAUI) is updated to incorporate tabs.

If I remember correctly (I may be wrong, it is a long, long time since I used it), Dev-CPP lets you drag around editor windows in a MDI-like interface. That is still not exactly what you asked for, but close enough, I guess.

[MortenMacFly]

But if C::B is highly dependent on a docking lib, I guess it would be close to impossible to change it cleanly to use freely positionable windows instead (as well as multiple open and overlapping source windows).

What I don't understand: Using a docking library you can undock a window and place it anywhere you want. So why doesn't this fit your needs? Docking does not mean you have to dock in to the main application window allthough it is possible. The debugger windows I usually undock and place them on a second monitor. So I guess it's not the docking lib that makes it impossible... or... am I getting something wrong here?
With regards, Morten.

[thomas]

Hmm... somehow the latest post seems to have been deleted while I was away getting a coffee...

Anyway: Yes, Code::Blocks depends on a docking lib (wxAUI) to handle the docking stuff (not surprising). However, it is no way impossible to change this, we have done it before (although I see no urgent reason at the present time).
The editor tabs, on the other hand, are implemented as wxFlatNotebook, since wxAUI does not support (at least to my knowledge) tabs yet. One could for example use a docking library like wxIFM, which has tear-off tabs and treats tabs and dock windows the same. I don't know how much time this would take, it will probably not quite be an issue of 10 minutes, but I wouldn't expect it to be an endeavour for many weeks, either.

However, since you wrote that docking generally annoys you, too, I don't think you'll ever be happy with Code::Blocks. We had MDI back in the old times, and due to the problems it caused, it is 100% certain that we will never go back to that.

[PChris]

I don't think, that wxFNB is a perfect solution, I have had many annoyances with wxFNB, so I think wxIFM can only be better. But that's only my opinion, of course I do not request a change.
with regards, Christopher

[mandrav]

I have had many annoyances with wxFNB, so I think wxIFM can only be better

Comparing oranges to apples here?
wxFNB is an improved notebook control and wxIFM is a docking library. They share nothing in common...

[takeshimiya]

AFAIK the functionality wanted is on the roadmap of wxAUI.

I asked once the author and replied that it'll be high likely he will implement it after wxAUI 1.0 (just like wxIFM handles it).

So, TheWiz, you can either wait, or help the author to implement it.

[TheWiz]

So I get the impression that with some docking lib, it would be possible to "tear off" multiple source windows and "float" them as overlapping windows. That could work, I guess. I have no problem with docking windows as long as I can turn them into regular windows  . Hopefully, the "stickyness" of the windows can then also be turned off so they won't cling to the desktop's edges, trying to turn themselves back into docked "tiles". I guess I'll take a look at this wxAUI. Thanks for all your replies!

[TheWiz]

You can eighter run a second instance of C::B or (as I do) configure a tool for source code inspection. For this I use SciTE. Anyway: Please note that there is a lot of functionality inside C::B that IMHO helps navigating in source code a lot better than a second window. I think of bookmarks, the symbol browser, easily switching between source/header etc...

Well, running a second instance would only give me *one* more window, and in a fairly clumsy way at that. I regularly open numerous windows to refer to other source files. Sometimes even multiple views of the same file, in order to see one part of the file while editing another. Using some other tool would not provide the nice C::T functionality you talk about. Besides, *not* having to use several other tools/editors is one of the primary reasons of using an IDE in the first place as far as I am concerned.

Perhaps if the docking library supported tabbed windows, allowing them to be "torn off", and allowing the docking behavior to be controlled (in my case, turning it off), we could have both. But that seem to be quite far away from what I understand. Perhaps something for the wish-list...

[TDragon]

Hopefully, the "stickyness" of the windows can then also be turned off so they won't cling to the desktop's edges, trying to turn themselves back into docked "tiles".

You appear to be confusing the concepts of docking, which involves switching a toolbar/widget between an integrated state and a free-floating state, and snapping, which causes a dragged widget to align itself with nearby borders and other widgets. A docking system can includes a form of snapping in that when the widget is dragged close enough to its assigned dockable position, it will revert to its docked form, but generally nothing beyond that. In fact, wxAUI (which Code::Blocks uses) does not use snapping in the docking system, instead showing a shaded area that the toolbar will appear in when dropped.