Author Topic: Docking library  (Read 28109 times)

SnakeChomp

  • Guest
Docking library
« on: August 19, 2005, 11:37:41 am »
Hi. I happened to do a random google search for wxIFM and the third hit happened to be a bounty thread on this forum for wxIFM testing. I browsed further and happened to notice that you seem to be using wxDockIt now for docking windows? I am curious as to why you made this mistake, I mean choice. :lol:

p.s. If you don't know who I am, I am the author of the wxIFM library.

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: Docking library
« Reply #1 on: August 19, 2005, 12:02:08 pm »
Hi. I happened to do a random google search for wxIFM and the third hit happened to be a bounty thread on this forum for wxIFM testing. I browsed further and happened to notice that you seem to be using wxDockIt now for docking windows? I am curious as to why you made this mistake, I mean choice. :lol:

p.s. If you don't know who I am, I am the author of the wxIFM library.

Hi there :)

Two reasons:
1) The demo would crash with some specific operations (sorry, can't remember more now)
2) I read in one of your posts at the wxwidgets forum, that you stopped development of wxIFM. That was not exactly encouraging ;)

Please, make me feel stupid for choosing wxDockIt ;) (IOW: make me understand that I was wrong).
Great work anyway :D

Yiannis.
Be patient!
This bug will be fixed soon...

SnakeChomp

  • Guest
Re: Docking library
« Reply #2 on: August 19, 2005, 12:26:59 pm »
You must not have run a recent version of the demo. The recent code is rock solid as far as my testing goes. As for why wxDockIt is the wrong choice, have you ran the wxIFM demo program and run through the tutorial? That tutorial will let you experience the power of the docking wxIFM provides. Its not like wxDockIt, where you can only have a single row of windows on any side of the frame. This is full blown docking ala MS Visual Studio 2003 and 2005. You can have anything where ever you want it, including every single dockable window contained in the same floating window. (Pointless but fun!) You say that me not actively developing wxIFM is discouraging, but use wxDockIt which has not had a release in a year (this recent distribution of CVS doesn't count imo) and claim it is being developed? I personally say that wxDockIt has been long dead and I see no real evidence against that. I may not actively develop new features for wxIFM but I will actively maintain wxIFM for quite some time. If the wxWidgets devs ever get their act together and branch, wxIFM will finally move into its new home in the wxWidgets source. Once its there I will be its maintainer and will accept patches and what not. If I get bored I may add new things to it myself. I don't plan on it, but its not an impossibility. I will also assist anybody who wants to add new features but has questions.

Some more concrete reasons as to why wxIFM > wxDockIt (IMO)

  • Based around a plugin architecture, wxIFM is easily extensible, allowing you to create new features which can be loaded and unloaded at run time, even from a dll!
  • Forget XOR rectangles; wxIFM uses the vastly more intuitive drag'n'drop docking system seen in recent betas of MS Visual Studio 2005. As you drag a window, arrows pop up letting you know exactly where you need to place to mouse to dock a window in a specific location. No more blindly wiggling the mouse hoping that XOR rectangle goes where you want it to.
  • Unlimitedly flexible docking mechanisms provide you the power to create absolutley any window layout you can imagine.
    • Tear-able tabs let you have more than one window in the same spot saving space but still allowing flexability in your interface
    • Put as many windows into the same floating window as you want
    • Drag entire containers containing many child windows just like you were dragging any other dockable window
  • Less important reasons but things I still consider to be important none the less
    • wxIFM will have a home within wxWidgets source, so it will be supported indefinately
    • The source is clean which aids maintainance and feature additions

*end salesman act*

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: Docking library
« Reply #3 on: August 19, 2005, 12:36:00 pm »
*end salesman act*

Heheh, thanks for the info.
Since we have you here, would you mind answering the following?:

1) Does it only support wx2.6x or does it work with wx2.4.2 too?
2) Does it work under non-windows platforms?
3) The main problem I found with wxDockit (as well as other wx libs) is to build it for usage in C::B. C::B links to a dynamic wx dll (compiled with WXMAKINGDLL=1). Does your code allow for linking to wx DLL? Most wx-related libs I tried (wxDockit too), only build well when linked statically with wx. Notice that when C::B is compiled, it uses -DWXUSINGDLL.

Now point us to the newest wxIFM demo so we can get even more enlightened ;)

Yiannis.
Be patient!
This bug will be fixed soon...

SnakeChomp

  • Guest
Re: Docking library
« Reply #4 on: August 19, 2005, 12:48:15 pm »
Win32 precompiled demo: www.snakesoft.net/wxifm/demo.zip
Official wxIFM thread: http://www.solidsteel.nl/users/wxwidgets/viewtopic.php?t=2153
My site with only a small bit of info: www.snakesoft.net/wxifm

I don't think there is anything specific preventing compiling wxIFM using a dynamic build of wxWidgets. The wxIFM project files are set up to only link against wxWidgets statically but that is easily correctable. wxIFM source itself needs a few changes to be compiled into a dll itself (exporting symbols is all).

wxIFM works on all the major platforms (windows, gtk, mac). Floating is not enabled on the mac because afaik wxWindow::Reparent is not implement for that platform. I don't have access to test this so I don't know if this is true. It can be tested easily by strictly enabling flloating support for a mac build and seeing if it works.

There is nothing stopping wxIFM from working on wxWidgets 2.4.2 except for the fact that wxIFM uses some wxWidgets #defines contained in the more recent events header, those being the new event declaration macros (wx__DECLARE_EVT0 or something) and the wxFooEventHandler() cast macros. You would have to change all of the event declarations, or copy / paste the wx_DECLARE_EVT_0 macro for things to compile in a 2.4.2 environment, as well as any wxFooEventHandler cast macros the source uses.

I feel I should mention that there are a few "heavy hitting" features I believe wxIFM still lacks: namely being able to have more than one interface state which you can switch to at any given moment and the ability to save / load these states. That being said, if wxIFM was used by a "heavy hitting" project like Code::Blocks I would be more inspired to add those features.  :wink:

SnakeChomp

  • Guest
Re: Docking library
« Reply #5 on: August 19, 2005, 02:01:24 pm »
From another topic:

Quote
Now that CB has tabs, do we really need the 'opened files' portion anymore? IMO, it would work out better to nuke it, and have the symbols occupy that space. If needed, the files that are currently opened can be set to bold bold in the workspace view.

Quote
Yes, but disabling it is different then being able to see the workspace and symbols at the same time. I always have to switch between them. Perhaps combine all 3 into 1 tab then?

Like:
Symbols
Workspace
Files

Because wxDockIt is not capable of allowing you to have docking windows which are actually tabs, you are forced to make these user interface decisions on your own (and these are purely subjective choices). wxIFM can manage dockable windows as tabs, so you don't have to decide where to put the tabs within the UI; the user does. He mentions being able to see symbols and workspace at the same time. That is the choice you are able to make with wxIFM, you can just tear the symbols tab out of the panel holding the workspace tab and put the symbols next to (or above or below) the workspace tab.
« Last Edit: August 19, 2005, 02:08:03 pm by SnakeChomp »

Offline Urxae

  • Regular
  • ***
  • Posts: 376
Re: Docking library
« Reply #6 on: August 19, 2005, 03:06:08 pm »
wxIFM can manage dockable windows as tabs, so you don't have to decide where to put the tabs within the UI; the user does.
I'd just like to say that this is a very good feature, and one I would love for Code::Blocks to have. 8)

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: Docking library
« Reply #7 on: August 19, 2005, 03:07:50 pm »
Let me settle (I just came back from vacations) and I promise to give a second look at wxIFM. Just stick around 'cause I 'll be having lots of questions ;)

Yiannis.
Be patient!
This bug will be fixed soon...

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: Docking library
« Reply #8 on: August 19, 2005, 05:57:51 pm »
Perhaps we would need an EXTENSION of the MainFrame class. This way the structural important changes would be in MainFrameBase (to say a name), and MainFrame would take care of what docking library is used.

And this would allow us to organize better the branching etc. because some parts of the SDK are depending on the interface style (i.e. message manager has some resizing stuff that is hard-coded).

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: Docking library
« Reply #9 on: August 20, 2005, 08:43:26 pm »
@SnakeComp:
The demo looks nice :)
Although I noticed a bug: tab-text doesn't appear on the inactive tabs, i.e. you have to select a tab to see it's text (I guess that's a coloring issue).

I have another question which is really important: does it support multiple (draggable) toolbars?

Keep up the good work.
Yiannis.
Be patient!
This bug will be fixed soon...

SnakeChomp

  • Guest
Re: Docking library
« Reply #10 on: August 21, 2005, 04:21:28 am »
Although I noticed a bug: tab-text doesn't appear on the inactive tabs, i.e. you have to select a tab to see it's text (I guess that's a coloring issue).

This is an issue with your theme. What happens is that wxSystemSettings::GetColour(wxSYS_COLOUR_INACTIVECAPTIONTEXT) returns the same color as wxSystemSettings::GetColour(wxSYS_COLOUR_BTNSHADOW), so the background of a tab has the same color as the text of the tab, resulting in the text not being visible. The real fix for this involves creating a real way to request a color to use from within the framework instead of each individual function that wants to draw something picking its own color with wxSystemSettings::GetColour(). This could allow "theming" of wxIFM which is separate (or linked) to the global theme of the system.

I have another question which is really important: does it support multiple (draggable) toolbars?

Sort of. I dont know if it works on gtk, but on MSW, if you create the toolbar with the appropriate win32 only styles which let it appear at an arbitrary position within its parent window, yes it can be managed by wxIFM. Real toolbar support (like how VS and MSOffice handle toolbars) is not provided. That means that you can put toolbars anywhere, including making a toolbar a tab of a panel, which doesn't make any sense. What I would like to see for toolbars is an area on the edges of the frame in which only toolbars can go. Non toolbar windows would be placed inside of the toolbar area. This is what VS2002+ does (VS uses MSOffice toolbars) and it prevents mixing toolbars with non toolbar windows. It wouldn't be terribly hard to do, its just a matter of doing it. Other things missing with toolbars is not displaying the resize sash for them (I may already do this, not sure) and working around some sizing issues (GetBestSize returns a value that isn't tall enough on msw as far as I can tell).

The reasoning behind not putting in real toolbar support is the fact that toolbars on Mac do not and cannot work like this. There is one toolbar and it can be hidden / shown via a button on the top right of the frame and it is only displayed in one spot. Mac applications are supposed to use pallete windows and not multiple toolbars like MSW / Gtk applications do. This is an oversight of wxWidgets design and not really my fault.
« Last Edit: August 21, 2005, 04:23:07 am by SnakeChomp »

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: Docking library
« Reply #11 on: August 21, 2005, 09:37:11 am »
Although I noticed a bug: tab-text doesn't appear on the inactive tabs, i.e. you have to select a tab to see it's text (I guess that's a coloring issue).

This is an issue with your theme. What happens is that wxSystemSettings::GetColour(wxSYS_COLOUR_INACTIVECAPTIONTEXT) returns the same color as wxSystemSettings::GetColour(wxSYS_COLOUR_BTNSHADOW), so the background of a tab has the same color as the text of the tab, resulting in the text not being visible. The real fix for this involves creating a real way to request a color to use from within the framework instead of each individual function that wants to draw something picking its own color with wxSystemSettings::GetColour(). This could allow "theming" of wxIFM which is separate (or linked) to the global theme of the system.
Hmm... I use the Silver winXP standard style...
Anyway, that's some strange color combination you got there. I mean wxSYS_COLOUR_INACTIVECAPTIONTEXT is for *frames* (windows with caption bars) and wxSYS_COLOUR_BTNSHADOW is just for control shadows...
Yes, you can use them for everything but, as we see here, not all (not-intended) combinations work for every theme.

Look at the attachement...
I couldn't possibly tell every user to change their themes. Sorry to say this but It 's clearly a wrong choice of system color constants on your part...
Anyway, I believe it is configurable somewhere in the code so that shouldn't be an issue ;)

I have another question which is really important: does it support multiple (draggable) toolbars?

Sort of. I dont know
Let me clarify:
wxDockit allows us to have many different toolbars which can wrap-around if the width of the window is too small to fit them all. I 'm not talking about full dragging and floating support (although it would be great ;) ). Just many different toolbars managed by the framework.

Yiannis.

[attachment deleted by admin]
Be patient!
This bug will be fixed soon...

SnakeChomp

  • Guest
Re: Docking library
« Reply #12 on: August 21, 2005, 10:29:32 am »
Look at the attachement...
I couldn't possibly tell every user to change their themes. Sorry to say this but It 's clearly a wrong choice of system color constants on your part...
Anyway, I believe it is configurable somewhere in the code so that shouldn't be an issue ;)

I already knew this problem exists (you aren't the first to report it). Yes it is configurable and I already said what the fix was, so no its not an issue.

wxDockit allows us to have many different toolbars which can wrap-around if the width of the window is too small to fit them all. I 'm not talking about full dragging and floating support (although it would be great ;) ). Just many different toolbars managed by the framework.

I have no idea what "wrap-around" means. If toolbars don't have enough room they are supposed to display a chevron which opens a menu displaying the toolbar items which don't fit (in win32 land anyway). I don't know what usually happens if you have too many toolbars which end up being too big in wx so I don't know how the wxDockIt behavior is any different.

SnakeChomp

  • Guest
Re: Docking library
« Reply #13 on: August 21, 2005, 10:25:48 pm »
Please see this post. http://www.solidsteel.nl/users/wxwidgets/viewtopic.php?p=16139#16139. I'm sure you will like what you see. Specifically, look at http://pecholt.wz.cz/ifm.png.
« Last Edit: August 21, 2005, 10:30:14 pm by SnakeChomp »

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: Docking library
« Reply #14 on: August 21, 2005, 11:14:28 pm »
Please see this post. http://www.solidsteel.nl/users/wxwidgets/viewtopic.php?p=16139#16139. I'm sure you will like what you see. Specifically, look at http://pecholt.wz.cz/ifm.png.

Now, that looks better ;)

Yiannis.
Be patient!
This bug will be fixed soon...