Author Topic: Docking library  (Read 28410 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...

SnakeChomp

  • Guest
Re: Docking library
« Reply #15 on: August 22, 2005, 05:27:46 am »
Here is what I have come up with after some work: www.snakesoft.net/wxifm/images/wxifm.png. Unfortunately a wxWidgets bug is preventing me from completing another thing I wanted to do tonight, which is to dynically show or hide the caption of a floating window depending on how many children it has. I can add a caption just fine but it never goes away again.

Edit
Looks like I spoke too soon, it was my codes problem, not wx's.
« Last Edit: August 22, 2005, 05:34:10 am by SnakeChomp »

SnakeChomp

  • Guest

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: Docking library
« Reply #17 on: August 27, 2005, 11:23:34 am »
Damn! Man, you really wanna make us switch, don't you?
Well, you 're making a great job with it :P :D

I will definetely check out this 1.0.4 version.

Just to avoid confusion:
The reason I pospone checking wxIFM within C::B is that C::B would need an overhaul to support it correctly (mainly because the tab panels we use expect a wxNotebook as a parent, while with wxIFM it could be any wxWindow, right?). Not that major but still...
I sure plan to embed and test it though. I don't think it should be *that* hard...

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

SnakeChomp

  • Guest
Re: Docking library
« Reply #18 on: August 27, 2005, 11:35:39 am »
The tab panels would be children of the main frame (or a floating window). There wouldn't be any more notebooks anywhere (except for document windows). Why do your tab windows assume their parents are notebooks right now anyhow?

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: Docking library
« Reply #19 on: August 27, 2005, 12:29:47 pm »
The tab panels would be children of the main frame (or a floating window). There wouldn't be any more notebooks anywhere (except for document windows)

That's what I figured. Thanks :)
Be patient!
This bug will be fixed soon...

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: Docking library
« Reply #20 on: August 27, 2005, 12:45:24 pm »
SnakeChomp, have you ever tried building wxIFM with a wxWidgets-DLL?
Be patient!
This bug will be fixed soon...

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: Docking library
« Reply #21 on: August 27, 2005, 01:39:45 pm »
SnakeChomp, have you ever tried building wxIFM with a wxWidgets-DLL?

Like I thought: doesn't work...

Anyway, I 've patched the sources to allow for mixed-environment compilations, i.e.:
wx DLL, IFM static
wx DLL, IFM DLL
should also work with wx static and IFM [DLL|static], but I haven't tested it...

Attached is the patch and C::B workspace for wxIFM (extract in top-level wxIFM folder).

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

SnakeChomp

  • Guest
Re: Docking library
« Reply #22 on: August 27, 2005, 10:17:50 pm »
Tortoise SVN doesn't like that patch so its pretty useless to me. And by the way, yes wxIFM does work fine when compiled against a wxWidgets DLL. I just tried it. I did have to remove the one WXDLLEXPORT that I had which was on the wxInterfaceManager class (I just put it there once and never did anything with it) but after that all went well. There were quite a few warnings about to inconsistant dll linkage due to the event macros I used, but it still works. I'd personally rather not support using wxIFM itself as a dll due the highly pointless nature of using any kind of DLL in wxWidgets land. You can't upgrade any wx DLL's without recompiling everything that uses them anyhow so it only opens room for disaster with no benefit if wxIFM was a dll too.

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: Docking library
« Reply #23 on: August 27, 2005, 11:05:25 pm »
Tortoise SVN doesn't like that patch so its pretty useless to me. And by the way, yes wxIFM does work fine when compiled against a wxWidgets DLL. I just tried it. I did have to remove the one WXDLLEXPORT that I had which was on the wxInterfaceManager class (I just put it there once and never did anything with it) but after that all went well. There were quite a few warnings about to inconsistant dll linkage due to the event macros I used, but it still works. I'd personally rather not support using wxIFM itself as a dll due the highly pointless nature of using any kind of DLL in wxWidgets land. You can't upgrade any wx DLL's without recompiling everything that uses them anyhow so it only opens room for disaster with no benefit if wxIFM was a dll too.

You see, the point is that it works for you, but not for me.
* I 'm talking about gcc compilation
* I don't like any kind of warnings in my code (neither should you).
* "I get a tons of warnings but I don't care as long as it works" is not a good response at all, if you don't mind...

I 'm not talking about wxIFM as a DLL itself. I 'm talking about static wxIFM with wxWidgets DLL. The thing is that WXUSINGDLL must be defined but if you use WXDLLEXPORT in wxIFM, it will wrongly use declspec(dllimport) when building it.
Also, you haven't exported any classes, except for that one using WXDLLEXPORT. Gcc doesn't like it. It builds the library (with many warnings) but chokes when trying to build the demo which uses it...

The patch I sent you, fixes all those issues (check only if the static wx case works).

If the patch doesn't work, you have three options:
a) use a command-line patch utility
b) check why it doesn't work. I can guess: I made this patch *outside* wxIFM dir. This means a simple search for "wxIFM\" and replacing it with "" should make tortoise happy...
c) ask someone to help you

Everything contributed to you, you should learn to accept it happily. Phrases like "Tortoise SVN doesn't like that patch so its pretty useless to me." should really be avoided...

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

grv575

  • Guest
Re: Docking library
« Reply #24 on: August 28, 2005, 02:12:43 am »
It's a standard patch.
cd wxIFN/
patch -p1 -i ../wxifm.diff

tortoise may have the option to remove prefixes (-p1 removes 1 prefix [directory portion])?
otherwise just do the above in MSYS or cygwin

SnakeChomp

  • Guest
Re: Docking library
« Reply #25 on: August 28, 2005, 03:49:34 am »
Sorry. I went and got GnuWin32 patch and managed to figure out how to apply it. I had to add more WXIFM_DECLSPEC to some base classes that you didn't add them to as I was getting warnings about the derived class being exported while the base class was not. I'm only going to support build configurations where either wxWidgets and wxIFM are both statically linked, or they are both dynamically linked. (Using static wxIFM and dll wxWidgets "should" be ok but I haven't tried it) I tested all of these configurations (going through much pain due to the joy of the wx build system) and they all work except a strange problem with the release dll configuration. It crashes somewhere inside of wxmsw26_ifm.dll before the program displays anything. This doesn't happen for any other build so I am not going to bother wasting my time trying to figure out what exactly is going wrong. Another thing to note is that the wx bujild system fails during DLL builds because the "qa" project does not output any .lib files during dll builds. The wx headers force all programs to link against the qa .lib files, but the linker can't find these files (because the build system didn't make the file) so the builds fail. I had to modify my include/msvc/wx/setup.h to not force linking against these files for builds to complete succesfully. I have an oldish version of the 2.6 series so that might have something to do with it but I'm not going to bother with it anymore.

I dont think I'll be releasing another patch just for this change because it hardly effects anybody using wxIFM (nobody uses dll wx builds unless they have a very specific requirement to do so, like you do) and I haven't actually tried writing a plugin that uses symbols exported by dll versions of wxIFM. For all I know it may not really work at all and in that case dll builds of wxIFM are just as pointless as dll builds of wx.

I attatched a patch which has the modifications I made (remove the .txt extension). It is patched against 1.0.4, not against your changes, but it includes your changes. Note that I changed the name of the symbols you chose to identify a dll build of wxIFM. Those now being: IFM_DLL and IFM_BUILDING. IFM_DLL is defined when you are using the dll version of wxIFM and IFM_BUILDING is defined when you are building the wxIFM library. I haven't touched the makefiles so if you modified them to build dll versions of wxIFM you'll need to change them again. The makefiles aren't that good anyway, but I don't do makefiles so I couldn't make them any better myself.

[attachment deleted by admin]
« Last Edit: August 28, 2005, 04:00:49 am by SnakeChomp »

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: Docking library
« Reply #26 on: August 28, 2005, 09:55:13 am »
Alright. On with testing now  :lol:
Be patient!
This bug will be fixed soon...

Offline byo

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 837
Re: Docking library
« Reply #27 on: August 28, 2005, 03:47:43 pm »
Wow, I've just looked into wxIFM demo. And it has almost all features I would like to see in C::B... especially grouping in tabs - one of my favorite features in Visual Studio - just put everything where You like it to be :) now it can be done in my favorite IDE :)...
The only thing I would like to have is to easily order tabs by dragging it. But even without it, it will be great to see C::B cooperating with wxIFM ;).

grv575

  • Guest
Re: Docking library
« Reply #28 on: August 28, 2005, 09:13:22 pm »
Neat demo.  It builds with codeblocks.  I'm using the dll version of wxWidgets 2.6 and wxIFM as a static lib.  Steps:

1.  Build wxWidgets 2.6 according to the wiki:
http://wiki.codeblocks.org/index.php/Compiling_wxWidgets_2.6.1_to_develop_Code::Blocks_%28MSW%29#Building_wxWidgets_2.6.1_mingw32_.26_vc.2B.2B_toolkit_2003
under "for vc++ toolkit 2003 compiler"

2.  Download wxIFM 1.0.4
http://www.solidsteel.nl/users/wxwidgets/viewtopic.php?p=16704#16704
2b. and this patch:
http://forums.codeblocks.org/index.php?action=dlattach;topic=748.0;id=84 (reply #25 of this thread)

3.  Extract wxIFM source and patch it
open MSYS (download from mingw sourceforget site if needed), and do
cd wxIFM
patch -p0 -i ../wxifm_diff.patch.txt

4.  open codeblocks and import the .sln.  You will need to add some paths, enable c++ exceptions option, and also the WXUSINGDLL define.  Then build wxIFM and then the demo.  I've attached the modified .cbp codeblocks files.  You will need to modify any absolute paths as needed if you use these.  I only changed things for the nonunicode release builds as wel...

4b. if you want to link against msvcrt.dll instead of libc.lib (you can choose in the compiler options (MT DLL runtime lib or MT runtime lib) then do this to produce msvcprt.lib:

open MSYS
cd /c/WINDOWS/system32
PATH=$PATH:/c/Program\ Files/Microsoft\ Platform\ SDK/Bin/win64/
echo LIBRARY msvcp71.dll > msvcprt.def
echo EXPORTS >> msvcprt.def
link -dump -exports msvcp71.dll | sed -nf exports.sed >> msvcprt.def
link -lib -machine:X86 -def:msvcprt.def -out:msvcprt.lib
exit

---exports.sed---
# echo LIBRARY msvcp71.dll > msvcprt.def
# echo EXPORTS >> msvcprt.def
# link -dump -exports msvcp71.dll | sed -nf exports_alt.sed >> msvcprt.def
# link -lib -machine:X86 -def:msvcprt.def -out:msvcprt.lib
#
/[ \t]*ordinal hint/,/^[ \t]*Summary/{
 /^[ \t]\+[0-9]\+/{
   s/^[ \t]\+[0-9]\+[ \t]\+[0-9A-Fa-f]\+[ \t]\+[0-9A-Fa-f]\+[ \t]\+\(.*\)/\1/p
 }
}
---end exports.sed---

the above should be saved as exports.sed (and make sure it uses linux line endings...vi exports.sed and check that there are no ^M at the end of the lines.  Shift-ZZ to get out of vi...).

now just put the generated msvcprt.lib and msvcprt.exp in your lib path: e.g. c:\program files\platform sdk\lib
(there's a similar trick to produce libmsvcrtp.a which gcc would need.  i just tried wxIFM with msvc toolkit since it had .sln stuff already.  google for the mingw exports.sed procedure it if needed)

5.  the demo outputs to c:\.  move c:\demo1.exe to wxIFM\samples\demo1 and launch it (copy wxmsw26_vc_cb.dll to the same directory or c:\windows\system32 if not already reachable somewhere in your path).


[attachment deleted by admin]
« Last Edit: August 28, 2005, 09:21:38 pm by grv575 »

Offline peso

  • Multiple posting newcomer
  • *
  • Posts: 12
    • Abalone on Wikipedia
Re: Docking library
« Reply #29 on: December 28, 2005, 10:21:12 pm »
Hi guys.

Have you checked wxAUI out?

http://wiki.wxwidgets.org/wiki.pl?WxAUI

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: Docking library
« Reply #30 on: December 28, 2005, 10:48:09 pm »
Hi guys.

Have you checked wxAUI out?

http://wiki.wxwidgets.org/wiki.pl?WxAUI


This looks nice and I haven't heard of it. But it lacks one of the main important features wxIFM already has: docking any window as a tab in another window.
Anyway, it will take a while until we could use wxIFM in C::B (it lacks some other important features - like save/load layout). If by then wxAUI has added the missing functionality, we could evaluate it too ;)
Be patient!
This bug will be fixed soon...

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: Docking library
« Reply #31 on: December 29, 2005, 03:51:13 am »
*Drool* Sugoi.... docking toolbars... *drools*

How long has this been around? Is it stable? Any bugs?

takeshimiya

  • Guest
Re: Docking library
« Reply #32 on: December 29, 2005, 04:49:59 am »
wxAUI, amazing, never heard of it before. It seems stable and very lightweight (current version 0.9).

It's being developed by a developer of Kirix, so it'll be used in the well know Kyrix Strata. I can guess it's well mantained and it'll continue to be.

It seems that wxAUI get the toolbar and native/coolness effects things right, while wxIFM gets the tear-able tabs and not-XOR rectangles things right.

Let's see which of both get's the features of the other docking library first. 8)

EDIT: I've contacted the wxAUI author. I'm posting the info here: http://forums.codeblocks.org/index.php?topic=1789.0.
« Last Edit: December 30, 2005, 05:32:14 am by Takeshi Miya »

Offline zkey

  • Single posting newcomer
  • *
  • Posts: 8
Re: Docking library
« Reply #33 on: February 17, 2006, 11:05:45 am »
Has anyone compiled wxIFM and a demo sample under linux (wxGTK)? I successfully compiled wxIFM and the demo on SuSe last night (wx 2.6.2 - static, unicode), but got a lot of gtk-asserts when i tried to launch it. I'm currently not at home so i can't copy the error-msg.

Is anyone using wxIFM under linux ? If yes, it would be great to see few sshots of it.  :)

zkey

Offline AkiraDev

  • Multiple posting newcomer
  • *
  • Posts: 71
Re: Docking library
« Reply #34 on: February 17, 2006, 11:15:08 am »
Quote
Has anyone compiled wxIFM and a demo sample under linux (wxGTK)? I successfully compiled wxIFM and the demo on SuSe last night (wx 2.6.2 - static, unicode), but got a lot of gtk-asserts when i tried to launch it. I'm currently not at home so i can't copy the error-msg.

Did you use the old makefiles it used to bring? Those were generated by MinGWStudio and tweaked in a rush, so there will likely be mistakes in them. Mea culpa.
When I have the time, I'll try to make them in a more thourough way.

Haven't ran it on SUSE on quite a while. What's your version of SUSE and GTK, btw?

Offline zkey

  • Single posting newcomer
  • *
  • Posts: 8
Re: Docking library
« Reply #35 on: February 17, 2006, 11:33:47 am »
Did you use the old makefiles it used to bring? Those were generated by MinGWStudio and tweaked in a rush, so there will likely be mistakes in them. Mea culpa.
yep, there were few mistakes; i added the icon/images-directory to the compiler include-path and made only little changes to interface.cpp (or something like that) where i packed "plain"-strings into wxT() then i built all fine.

Quote from: AkiraDev
When I have the time, I'll try to make them in a more thourough way.
It would be great. Thanks in advance.  :)

Quote from: AkiraDev
Haven't ran it on SUSE on quite a while. What's your version of SUSE and GTK, btw?

I'm using suse 10.x and gtk+ 2.8x

zkey