Docking classes

If you are using the main C++ distribution of wxWidgets, Feel free to ask any question related to wxWidgets development here. This means questions regarding to C++ and wxWidgets, not compile problems.
Jordy
Knows some wx things
Knows some wx things
Posts: 39
Joined: Tue Jul 12, 2005 6:03 am
Location: Germany

Docking classes

Post by Jordy »

Hi!

Once more, I want to ask you some questions, before doing something stupid.

I am looking for wxWidgets classes for docking. This means dockable Windows (preferably including dockable tabs) and dockable toolbars (preferably freely moveable on the toolbar-space). I think the way they are implemented e.g. in MSVisualC++2003 is very nice.

Such features are essentially for a modern (!) GUI and I need them for my project.

I had a look at the wxIFM sample and the docs. wxIFM provides dockable windows but they look very strange an MS-Windows, having *two* window frames when floating. Also I was able to crash the example program by simply clicking the close-button on the outer window frame. One more problem with wxIFM seem to be that support and development are discontinued. So I would not like to rely on it.
I am wondering if there is an easy way to implement dockable toolbars wit wxIFM because I found stuff about dockable windows only?!

The wxFL solution provides very nice toolbars but apparently no dockable-window support. wxFL seems to be discontinued too and also has some nasty bugs causing the sample applications to crash or causing toolbars to disappear when resizing the window. So wxFL may also not be a reliable framework.

Third package I found is wxDockIt. I provides a solution for both, windows and toolbars. But both of them aren't as good as the solutions found in wxFL and wxIFM respectively: The toolbars can not be freely dragged around in the toolbar-space (which unfortunately means that disabling/enabling toolbars always leads to a changed toolbar layout) and the windows doesn't provide tabs and that nice arrow-controlled docking mechanism.
Officially, wxDockIt is currently under development but there was no release since one and a half year. On the other hand wxDockIt seem to be very stable.

Is there any other solution?
Does someone have experiences in using these packages in practice?
Any recommendations?

I really don't know how to continue. Qt seems to have those features but I don't want to switch. :(
SnakeChomp
Filthy Rich wx Solver
Filthy Rich wx Solver
Posts: 235
Joined: Sun Oct 10, 2004 2:53 am

Post by SnakeChomp »

I think the way they are implemented e.g. in MSVisualC++2003 is very nice.
The MSVC2005 way is clearly superior and that is the path I took with wxIFM.

Dockable toolbars are a joke because they do not make sense in the cross platform world. There is a reason why I stopped trying to implement them. (Mac applications don't even have more than one toolbar that I've seen and the toolbars aren't even displayed all the time let alone able to move all over the place. Alas, this is wxWidgets fault in its design, not mine.)

I cannot believe you are even considering wxFL. That is all I am going to say on that matter.
having *two* window frames when floating.
This is by design. If there was no "native" window frame being displayed, and you had multiple panels docked into the same floating window, it would be _impossible_ to move all of the at once _unless_ you realized that the thing gray bar on the left allows you to drag the entire container, thereby moving all of the windows at once. It is far more natural to drag all of the floating windows at once using the native caption and I believe easier for users to understand.

If you really don't like it, just change the source to suit your needs.
One more problem with wxIFM seem to be that support and development are discontinued. So I would not like to rely on it.
I am truely disgusted to hear this. I worked on wxIFM for many many months. Being a perfectionist, I did not stop until I felt wxIFM was good enough. I now feel that way. I'm not going away any time soon. I'm always on IRC. I'm always available to offer wxIFM help. Support is definately not discontinued. For your own good I hope you reconsider your stance on wxIFM.

I personally do not consider wxDockIt to be under development. Any project with no releases in over a year is not being developed imo.
Also I was able to crash the example program by simply clicking the close-button on the outer window frame.
I just did that in the version of the precompiled demo currently distributed and it doesn't happen to me. I would never release anything with such a serious bug.

I specifically wrote wxIFM because wxFL was a huge, unmaintained, buggy joke of a docking system. Even if wxIFM is not being actively developed by me anymore, its not like any of your other choices are either, and (IMO) wxIFM is clearly the surperior choice over all of them.
Jordy
Knows some wx things
Knows some wx things
Posts: 39
Joined: Tue Jul 12, 2005 6:03 am
Location: Germany

Post by Jordy »

SnakeChomp wrote:Dockable toolbars are a joke because they do not make sense in the cross platform world. There is a reason why I stopped trying to implement them. (Mac applications don't even have more than one toolbar that I've seen and the toolbars aren't even displayed all the time let alone able to move all over the place. Alas, this is wxWidgets fault in its design, not mine.)
Hm. I don't need Mac compatibility. I want to support Windows and Linux/Unix. For these platforms, extended toolbar seem to be no problem. At least they are officially supported in wxDockIt (dragable toolbars) and wxIF (dockable toolbars). But I don't know how good this works in practice on Linux/Unix platforms.
SnakeChomp wrote:I cannot believe you are even considering wxFL. That is all I am going to say on that matter.
Toolbars...
SnakeChomp wrote:This is by design. If there was no "native" window frame being displayed, and you had multiple panels docked into the same floating window, it would be _impossible_ to move all of the at once _unless_ you realized that the thing gray bar on the left allows you to drag the entire container, thereby moving all of the windows at once. It is far more natural to drag all of the floating windows at once using the native caption and I believe easier for users to understand.
Aha! Know I understand what you intended when designing this.
SnakeChomp wrote:If you really don't like it, just change the source to suit your needs.
Yes, I really don't like it. It doesn't look nice and it is confusing and breaks the common look-and-feel taken from the VisualC++ GUI. Additionally I simply don't need the feature to drag multiple panels at once using an extra frame. I would like to treat floating windows the way VC++ does it.

So I would need some changes on the sources:
1) Floating windows should be treated separated so that no other window can be docked at them (like in VC++).
2) The gray dragbar needs to be removed (is obsolete by #1).
3) The outer window frame needs to be removed (is obsolete by #1).
4) Floating windows in wxIFM should use the same frame style as floating windows in VC++ (you surely noticed how the frame style changes when a docked VC++ window starts floating) so they use the native style and are resizeable.

Could all this easily done by someone who doesn't know wxIFM in detail (i.e. by me)? Could you give some hints where to change?
SnakeChomp wrote:I am truely disgusted to hear this. I worked on wxIFM for many many months. Being a perfectionist, I did not stop until I felt wxIFM was good enough. I now feel that way.
I understand you very much. But for me wxIFM currently isn't the perfect solution even if I think it would have the potential to be.

I am very unlucky about your decision to stop development especially in respect of your perfectionism. To be honest I think improving wxIFM would be much more important then creating a new framework from the scratch (even if wxWidgets isn't perfect). Sometimes evolution ist better than revolution. But thats not my decision, its yours. I wish you much success in developing the new framework!!!
SnakeChomp wrote:I'm not going away any time soon. I'm always on IRC. I'm always available to offer wxIFM help. Support is definately not discontinued. For your own good I hope you reconsider your stance on wxIFM.
Nice to here about ongoing support!

Currently I simply consider four solutions. None of the WX solutions seems to fullfill all my needs. Currently I see the following ways for getting a GUI with both some kind of alterable toolbars and dockable windows:

1) Switching to Qt
2) Combining wxIFM (dockable windows) and wxFL (dockable toolbars)
3) Combining wxDockIt (dockable windows) and wxFL (dockable toolbars)
4) Using wxDockIt stand alone

#1 Isn't nice because I couldn't cope with a non-commercial project.

#2 Needs changes on wxIFM and corrections on wxFL. This means much, much, work but probably gives me the best solution (tabbed, arrow-dockable windows and dockable toolbars).

#3 Needs corrections in wxFL only. This means less work but also doesn't give me the best solution for dackable windows (no tabs, no arrow-docking).

#4 Means few work but gives me a minimal solution too (dragable but non-dockable toolbars and simple dockable windows only)
SnakeChomp wrote:I personally do not consider wxDockIt to be under development. Any project with no releases in over a year is not being developed imo.
I agree! But for the users there is no difference between 'discontinued by the lack of time' and 'officially discontinued'. I hope you can understand this.
SnakeChomp wrote:I just did that in the version of the precompiled demo currently distributed and it doesn't happen to me. I would never release anything with such a serious bug.
I get this in the wxIFMComponent::GetType() function: "Unhandled exception at 0x00664f66 in demo1.exe: 0xC0000005: Access violation reading location 0x00000010." This seems to be an access to an already deleted object using a NULL pointer (this==NULL).
SnakeChomp
Filthy Rich wx Solver
Filthy Rich wx Solver
Posts: 235
Joined: Sun Oct 10, 2004 2:53 am

Post by SnakeChomp »

So I would need some changes on the sources:
1) Floating windows should be treated separated so that no other window can be docked at them (like in VC++).
2) The gray dragbar needs to be removed (is obsolete by #1).
3) The outer window frame needs to be removed (is obsolete by #1).
4) Floating windows in wxIFM should use the same frame style as floating windows in VC++ (you surely noticed how the frame style changes when a docked VC++ window starts floating) so they use the native style and are resizeable.
You're kidding right? If you haven't noticed, VS (2003) does the EXACT SAME THING AS I DO in this regard. You can dock multiple windows into the same floating window, so point #1 completely fails. When you do this, you will have a native caption (it will be a thin caption) as well as the "custom" caption for each window that is docked. When you select one of the two docked windows, its "custom" caption will color itself in and appear blue like the native caption is doing. Sounds a lot like what I do doesn't it? (Except my captions are blue all the time, and the fact that you can use the native caption to dock stuff unlike wxiFM where the native caption only moves the window.) If you're talking about VC6, VC6 docking sucks compared to VS2003 which sucks compared to VS2005. I implemented VS2005 docking. Why should I downgrade to VC6?

Picture of VS2003: www.snakesoft.net/images/vs.png

What you are asking me to do is to remove the advanced docking facilities that I built into wxIFM. Did you run through the tutorial text in the demo application? If you had you would realize the powerful docking that wxIFM is capable of.

Yes I noticed that floating windows in VC have a different kind of caption. Its called a "tool window". If you want it, add the wxTOOLWINDOW or whatever style to the floating windows and they will look how you want them to on windows (but nowhere else because this is a windows only style).
Could all this easily done by someone who doesn't know wxIFM in detail (i.e. by me)? Could you give some hints where to change?
No, it can't, because you would be writing code to limit the power that I built into wxIFM. Such a quest is vain. It can be done, but I wouldn't say easily.

wxIFM is capable of "dockable toolbars" right now. Support is "sort of" there but I stopped working on it at one point. Use then IFM_CHILD_TOOLBAR style and ask it to manage a toolbar. It should work well enough. There will definately be some quirks though. You also need to use a special style on win32 to get the toolbar to move to an arbitrary position within its parent. I forget the name of this style, but its win32 only. I have never tried letting wxIFM manage a gtk toolbar.

I can't tell by your wording, but when you said "I need some changes on the source," were you saying that you wanted me to change some things for you so you could use wxIFM they way you want it to be? Commercial feature support is available as outlined in the readme file that came with wxIFM 1.0. Adding "official" support for toolbars can be accomodated. The version of wxIFM that will be in cpaf will also need this kind of toolbar support (The kind of support MSOffice has. VS2003 uses MSOffice toolbars).
I get this in the wxIFMComponent::GetType() function: "Unhandled exception at 0x00664f66 in demo1.exe: 0xC0000005: Access violation reading location 0x00000010." This seems to be an access to an already deleted object using a NULL pointer (this==NULL).
I'm going to need more information than this, like exactly what you did before you closed the demo. The demo application source comes with the wxIFM distro, so you could also make a debug compilation of that and see whats going on.
Jordy
Knows some wx things
Knows some wx things
Posts: 39
Joined: Tue Jul 12, 2005 6:03 am
Location: Germany

Post by Jordy »

SnakeChomp wrote:You're kidding right? If you haven't noticed, VS (2003) does the EXACT SAME THING AS I DO in this regard. You can dock multiple windows into the same floating window, so point #1 completely fails. When you do this, you will have a native caption (it will be a thin caption) as well as the "custom" caption for each window that is docked. When you select one of the two docked windows, its "custom" caption will color itself in and appear blue like the native caption is doing. Sounds a lot like what I do doesn't it? (Except my captions are blue all the time, and the fact that you can use the native caption to dock stuff unlike wxiFM where the native caption only moves the window.) If you're talking about VC6, VC6 docking sucks compared to VS2003 which sucks compared to VS2005. I implemented VS2005 docking. Why should I downgrade to VC6?

Picture of VS2003: www.snakesoft.net/images/vs.png
Hm. I never noticed that VS2003 can do this. I knew that VS2005 is able to dock multiple floating windows into one common frame, but not 2003. How can this be done without having the 2005's docking arrows?!

I agree that this feature (even if I don't need it for myself) isn't a problem. It may be a plus for some users. But it should really behave like in Visual. There are (even compared to 2005) some differences if I am not at fault:

The first is the gray bar on the left of every window. I hate this. Does it have any purpose which isn't fullfilled by the normal window's title bar?! Ok, I can drag the window without getting the docking-arrows. But thats not neccessary. Visual also doesn't have an axtra dragbar. If you drag a floating window there, the docking-arrows appear every time, don't they?

One more is that the outer, secondary frame isn't displayed in VS if there is only *one* window floating and no other is connected to it. I think this makes sense. For what do we need a outer frame if there is only one inner window to be enclosed?! It should only appear if needed.

The third difference is the style of the outer frame. You already mentioned to toolbar-style used in VS. I will try it out on monday.

What do you think about these?
SnakeChomp wrote:What you are asking me to do is to remove the advanced docking facilities that I built into wxIFM. Did you run through the tutorial text in the demo application? If you had you would realize the powerful docking that wxIFM is capable of.
Of course I did so. And I noticed the flexibility of the system. But I also noticed some oddities (some were my fault but there are still some issues I don't understand).
SnakeChomp wrote:
Could all this easily done by someone who doesn't know wxIFM in detail (i.e. by me)? Could you give some hints where to change?
No, it can't, because you would be writing code to limit the power that I built into wxIFM. Such a quest is vain. It can be done, but I wouldn't say easily.
No, I don't want the remove this features any more. I would like to make them a little "smoother".
SnakeChomp wrote:wxIFM is capable of "dockable toolbars" right now. Support is "sort of" there but I stopped working on it at one point. Use then IFM_CHILD_TOOLBAR style and ask it to manage a toolbar. It should work well enough. There will definately be some quirks though. You also need to use a special style on win32 to get the toolbar to move to an arbitrary position within its parent. I forget the name of this style, but its win32 only. I have never tried letting wxIFM manage a gtk toolbar.
Doesn't sound like getting happy with this?!
SnakeChomp wrote:I can't tell by your wording, but when you said "I need some changes on the source," were you saying that you wanted me to change some things for you so you could use wxIFM they way you want it to be? Commercial feature support is available as outlined in the readme file that came with wxIFM 1.0.
I thought about something like "helping me making the changes myself".

(btw. please be patient, english isn't my native language)
SnakeChomp wrote:Adding "official" support for toolbars can be accomodated. The version of wxIFM that will be in cpaf will also need this kind of toolbar support (The kind of support MSOffice has. VS2003 uses MSOffice toolbars).
What do you have in mind?
SnakeChomp wrote:
I get this in the xIFMComponent::GetType() function: "Unhandled exception at 0x00664f66 in demo1.exe: 0xC0000005: Access violation reading location 0x00000010." This seems to be an access to an already deleted object using a NULL pointer (this==NULL).
I'm going to need more information than this, like exactly what you did before you closed the demo. The demo application source comes with the wxIFM distro, so you could also make a debug compilation of that and see whats going on.
I did almost nothing. I compiled the demo (VS2003, WinXP prof., debug mode) I started it, I undocked one of the windows and I closed this window via its outer frame -> crash. On monday I could send you a compiled archive including the Win32 debug binary so maybe you are able to reproduce the problem. Do you have an e-mail address I should use for this purpose?
SnakeChomp
Filthy Rich wx Solver
Filthy Rich wx Solver
Posts: 235
Joined: Sun Oct 10, 2004 2:53 am

Post by SnakeChomp »

Jordy wrote:Hm. I never noticed that VS2003 can do this. I knew that VS2005 is able to dock multiple floating windows into one common frame, but not 2003. How can this be done without having the 2005's docking arrows?!
Inconveniently. Just drag something and mouse over a floating window. It will draw the XOR line within the floating window.
Jordy wrote:The first is the gray bar on the left of every window. I hate this. Does it have any purpose which isn't fullfilled by the normal window's title bar?!
If you had read the tutorial, that gray bar allows you to drag an entire container at once. This lets you move rows of windows at the same time instead of moving them all one by one. It was also going to be a space to put a close and minimize button to allow you to close and entire row or minimize an entire row. I didn't get that far, but theres nothing stopping somebody else from doing so.
Jordy wrote:One more is that the outer, secondary frame isn't displayed in VS if there is only *one* window floating and no other is connected to it. I think this makes sense. For what do we need a outer frame if there is only one inner window to be enclosed?! It should only appear if needed.
Your opinion has been noted, but I'm not changing it. My goal with wxIFM was not to create a to-the-letter Visual Studio clone, you'll just have to accept that and change the code yourself if you want that behavior.
Jordy wrote:Doesn't sound like getting happy with this?!
I dont understand what you said.
Jordy wrote:
SnakeChomp wrote:Adding "official" support for toolbars can be accomodated. The version of wxIFM that will be in cpaf will also need this kind of toolbar support (The kind of support MSOffice has. VS2003 uses MSOffice toolbars).
What do you have in mind?
There would be "toolbar enabled" sections of the managed window on the top, left, right, and bottom. You can put toolbars into these sections. Dock enabled areas for wxIFM components come after these sections, so its not possible to mix toolbars and other components in a layout. VS has these toolbar enabled secitons too. Toolbars would not have my custom drawn title bars, but grippers on one side.
Jordy wrote:I did almost nothing. I compiled the demo (VS2003, WinXP prof., debug mode) I started it, I undocked one of the windows and I closed this window via its outer frame -> crash.
That was an important piece of information that you neglected to tell me the first time. I didn't know you closed a floating window by its "outer frame". I will find out whats wrong and fix this today.

Edit: Fixed it, patch is already uploaded
Jordy
Knows some wx things
Knows some wx things
Posts: 39
Joined: Tue Jul 12, 2005 6:03 am
Location: Germany

Post by Jordy »

SnakeChomp wrote:Inconveniently. Just drag something and mouse over a floating window. It will draw the XOR line within the floating window.
Right. I just tried it. I had never noticed that before.
SnakeChomp wrote:It was also going to be a space to put a close and minimize button to allow you to close and entire row or minimize an entire row. I didn't get that far, but theres nothing stopping somebody else from doing so.
I think there is nothing in VS which can be compared to this "row drag-bar", right?

I was confused by the fact that the gray bar always reamains visible even in single windows (where it has the same effect as the outer frame's titlebar).

I suspect I have seen some layout errors corresponding to these bars. Try the following: Let one window (A) float. Let another window float (B). Drag (B) *below* (A).
Now there are two grey bars on the left, side by side, both of them as high as the entire outer frame (-> is this a mistake? Should the grey bars not be on the top of each other, each of them half as high as the window?).
Now un-dock one of the two windows (A) or (B). Both grey bars remain. (-> is this a mistake? I think at least one of them should disappear?).
SnakeChomp wrote:Your opinion has been noted, but I'm not changing it. My goal with wxIFM was not to create a to-the-letter Visual Studio clone, you'll just have to accept that and change the code yourself if you want that behavior.
Ok. It's a pity.
SnakeChomp wrote:There would be "toolbar enabled" sections of the managed window on the top, left, right, and bottom. You can put toolbars into these sections. Dock enabled areas for wxIFM components come after these sections, so its not possible to mix toolbars and other components in a layout. VS has these toolbar enabled secitons too. Toolbars would not have my custom drawn title bars, but grippers on one side.
Sounds great. Do you have any plans when you want to start with this?
SnakeChomp wrote:That was an important piece of information that you neglected to tell me the first time. I didn't know you closed a floating window by its "outer frame". I will find out whats wrong and fix this today.
Oh sorry, I thought this would be understood when talking about an "outer frame" meaning the secondary frame of a floating window.

(what's the best word for this in english? Outer frame? Secondary frame? Outmost frame? Surrounding frame?)
SnakeChomp wrote:Edit: Fixed it, patch is already uploaded
Thanx!

Thank you for your explanations too. Now I know what I need to do to make wxIFM my ideal solution: Disable the grey bar (nice feature but not important and to confusing for average users like me); remove the outmost frame for *single* floating windows (wastes space); changing the outer frame to Toolbar style (looks more familiar); waiting for the official toolbar support (fingers crossed :)
Chr
Earned some good credits
Earned some good credits
Posts: 115
Joined: Tue May 31, 2005 2:17 pm

Post by Chr »

if you (@Jordy) change all that can you post the code?
wxWidgets is nice
SnakeChomp
Filthy Rich wx Solver
Filthy Rich wx Solver
Posts: 235
Joined: Sun Oct 10, 2004 2:53 am

Post by SnakeChomp »

Jordy wrote:I suspect I have seen some layout errors corresponding to these bars. Try the following: Let one window (A) float. Let another window float (B). Drag (B) *below* (A).
Now there are two grey bars on the left, side by side, both of them as high as the entire outer frame (-> is this a mistake? Should the grey bars not be on the top of each other, each of them half as high as the window?).
Now un-dock one of the two windows (A) or (B). Both grey bars remain. (-> is this a mistake? I think at least one of them should disappear?).
No, this is correct. The root container of a floating window aligns its children horizontally. When you request to dock vertically within a horizontal container, (which is what happens when you dock under window "A"), a vertical container is created, windows A and B are placed inside of it, and the vertical container is then placed into the horizontal container. Each container has a gray bar.
Jordy wrote:Sounds great. Do you have any plans when you want to start with this?
When I have absolutely nothing better to do and just happen to think about wxIFM before the countless other things I would rather work on right now? :wink:
Jordy
Knows some wx things
Knows some wx things
Posts: 39
Joined: Tue Jul 12, 2005 6:03 am
Location: Germany

Post by Jordy »

SnakeChomp wrote:
Jordy wrote:I suspect I have seen some layout errors corresponding to these bars. Try the following: Let one window (A) float. Let another window float (B). Drag (B) *below* (A).
Now there are two grey bars on the left, side by side, both of them as high as the entire outer frame (-> is this a mistake? Should the grey bars not be on the top of each other, each of them half as high as the window?).
Now un-dock one of the two windows (A) or (B). Both grey bars remain. (-> is this a mistake? I think at least one of them should disappear?).
No, this is correct. The root container of a floating window aligns its children horizontally. When you request to dock vertically within a horizontal container, (which is what happens when you dock under window "A"), a vertical container is created, windows A and B are placed inside of it, and the vertical container is then placed into the horizontal container. Each container has a gray bar.
I think I need to answer you back.

I can understand the former issue, why wxIFm creates a additional graybar/container if the orientation V/H has changed. I think this is no big problem.
Nevertheless I want to suggest you a solution (probabely it would be possible and easy for *you* to realize ;) ): It would be better to *change* the orientation of the root container from or *replacing* the root container by a container of a proper type instead of *adding* a second, redundant container.
The basic user will not understand why there are two gray bars for only one child even if it reasonable.

The latter issue is certainly more critical and I still consider it an error. Let me explain why I think this: I played with the wxIFM demo. By repeatedly docking and undocking four child windows, I was able to create a floating window with only four child windows but a with *dozend* graybars/containers. The result looks absolutely unadjusted. And there is no limit: Whenever a window is undocked and docked and the orientation changes from V to H (or vice versa) an additional graybar/container is created and currently never discarded (except by tearing apart the floating window-cluster completely).

Maybe this could be corrected: Whenever a child window is undocked, wxIFM had to delete all redundant containers (i.e. all containers which only contain *one* child) and put the child at its place (except the for the root container of course).
SnakeChomp wrote:When I have absolutely nothing better to do and just happen to think about wxIFM before the countless other things I would rather work on right now? :wink:
Ok, I will be patient :)
BTW is there any mailinglist I could join?
Jordy
Knows some wx things
Knows some wx things
Posts: 39
Joined: Tue Jul 12, 2005 6:03 am
Location: Germany

Post by Jordy »

Hi SnakeChomp!

I noticed an oddity in the window layout calculation. Please try the following:

Start the demo under WinXp, using everything in default. The Tab 3 "Console" in the right Window "Build" should be activated. Now please drag this tab out of its window so that it is floating. Now dock this floating window to the top of the "wxIFM Test Application" main window. Please look out for the window "Files" and the left Window "Build" as they will flow into each other.
Making the main window larger solves this but its rather nasty effect.

Do you have a notion which the cause is? Can you adjust this?

P.S. I hope its in your interest that I report those things.
SnakeChomp
Filthy Rich wx Solver
Filthy Rich wx Solver
Posts: 235
Joined: Sun Oct 10, 2004 2:53 am

Post by SnakeChomp »

Jordy wrote:The latter issue is certainly more critical and I still consider it an error. Let me explain why I think this: I played with the wxIFM demo. By repeatedly docking and undocking four child windows, I was able to create a floating window with only four child windows but a with *dozend* graybars/containers. The result looks absolutely unadjusted. And there is no limit: Whenever a window is undocked and docked and the orientation changes from V to H (or vice versa) an additional graybar/container is created and currently never discarded (except by tearing apart the floating window-cluster completely).
Thats not supposed to happen because I wrote code that removes superfluous containers when they are no longer needed. It may no longer be functioning.
Jordy wrote:It would be better to *change* the orientation of the root container
I tried doing this in my copy of the source and yes it is better than creating an extra container. The change was only adding an if statement and 4 lines of code to switch the alignment.
Jordy wrote:Maybe this could be corrected: Whenever a child window is undocked, wxIFM had to delete all redundant containers (i.e. all containers which only contain *one* child) and put the child at its place (except the for the root container of course).
Its supposed to be doing this but doesn't seem to anymore...

I found the bug. There was one constant I forgot to switch when I changed the meaning of the constant. The problem you mentioned about generating infinitely large numbers of useless containers doesn't happen anymore.
Jordy wrote:BTW is there any mailinglist I could join?
No. #wxifm on freenode.net is the best place you can be.
Jordy wrote:Please look out for the window "Files" and the left Window "Build" as they will flow into each other.
I know that this is an issue. It wouldn't be an issue if no windows have minimum sizes, but in many cases they do (as in the demo). This was one of those things that I would have eventually fixed but the chances of me getting around to it now are not astronomically high.

All of the things that you have mentioned are easily solvable by someone willing to invest a little time trying to fix them. Its just like wxWidgets development. Reporting bugs is all well and good. Reporting a bug while you submit the patch that corrects it is far better.

wxWidgets 2.7 should be branching on or around August 1st. At that point wxIFM will have more exposure and a patch submission mechanism. I do hope that those wanting to "fix" wxIFM (or those who have already done so) will share what they have done.
vasek
Experienced Solver
Experienced Solver
Posts: 77
Joined: Wed Jul 27, 2005 2:52 pm
Location: Ostrava, Czech Republic
Contact:

Post by vasek »

wxIFM looks like very good library, but there are some reasons why i found it unuseful for my project:

1. double borders. Yes, i know, you already tried to explain WHY, but i think they make users more confused than anything!

2. docking system. Looks like very good idea to draw these "docking sites" (haven't seen it before), but again - very confusing for users.

3. it has some troubles with redrawing! Especially when the window what is about to be docked, is bigger than parent window, or when i play 'so long' with tabs.

I don't think it's good to introduce something new, until what works is bad/deprecated :) . I would prefer something like http://www.codeproject.com/wtl/wtldockingwindows.asp . OK, don't tell me anything, it's WTL, but when i used to code with this library, users never get confused.

Anyays, good work, I bet there are happy coders using wxIFM. GL :)
Jordy
Knows some wx things
Knows some wx things
Posts: 39
Joined: Tue Jul 12, 2005 6:03 am
Location: Germany

Post by Jordy »

vasek wrote:1. double borders. Yes, i know, you already tried to explain WHY, but i think they make users more confused than anything!
ACK. I will try to get around this but the code isn't documented well and the project is rather complex. I am not sure if I will find a good (!) solution without bothering SnakeChomp.
vasek wrote:2. docking system. Looks like very good idea to draw these "docking sites" (haven't seen it before), but again - very confusing for users.
This one is funny. Those docking-arrows are the main reason why I *WANT* to use wxIFM :-)

I think it is a great feature and is solved very similar to VC.
vasek wrote:3. it has some troubles with redrawing! Especially when the window what is about to be docked, is bigger than parent window, or when i play 'so long' with tabs.
Have you ever tried to understand wxIFM and correct these issues by your own?
vasek wrote:I don't think it's good to introduce something new, until what works is bad/deprecated :) . I would prefer something like http://www.codeproject.com/wtl/wtldockingwindows.asp . OK, don't tell me anything, it's WTL, but when i used to code with this library, users never get confused.
I think wxIFM has much potential. Some erros should be corrected, toolbar support should be added and it should be a little more configureable (so that every programmer could enable and disable features he doesn't like without modifing new code).

I think porting such a project (WTL docking) would be more work then perfecting wxIFM.
vasek
Experienced Solver
Experienced Solver
Posts: 77
Joined: Wed Jul 27, 2005 2:52 pm
Location: Ostrava, Czech Republic
Contact:

Post by vasek »

This one is funny. Those docking-arrows are the main reason why I *WANT* to use wxIFM :-) I think it is a great feature and is solved very similar to VC.
Ok, I din't say these arrows are bad. I said they are confusing for users (especially for those "I love M$ Word"). Perfect solution would be to switch between both modes.
Have you ever tried to understand wxIFM and correct these issues by your own?
I downloaded snake's package yesterday and today it's not programming time (37 deg. C), so - No, I haven't tried it yet. But I guess some of these problems were caused by wx bug (that was fixed in last patch).
I think wxIFM has much potential. Some erros should be corrected, toolbar support should be added and it should be a little more configureable (so that every programmer could enable and disable features he doesn't like without modifing new code). I think porting such a project (WTL docking) would be more work then perfecting wxIFM.
Yes, of course it has, but - as you said - there are no options for programmer to e.g. enable/disable those 'double borders' or even make one's own drawing code (a kind of 'custom draw'). These are features I really miss, and i bet i am not the only one. Anyways, snake has IMHO created a good starting point for perfect docking framework for wx :wink:

That WTL docking was just a sample of perfect docking system. I haven't even thought about porting it to wx :)
Post Reply