Future docking lib based on wxIFM or not ?

This forum can be used to talk about general design strategies, new ideas and questions in general related to wxWidgets. If you feel your questions doesn't fit anywhere, put it here.
Post Reply
romeo9423
Experienced Solver
Experienced Solver
Posts: 72
Joined: Mon Nov 08, 2004 3:36 pm

Future docking lib based on wxIFM or not ?

Post by romeo9423 » Wed Dec 14, 2005 7:28 pm

Hi,
I have started to develop an app using a docking bar interface. For that I have used wxdockit but before to go any further I would like to know if there will be a standard docking lib very soon in wxwidgets.
I have heard of wxIFM, what is the status ?
Will you start from it or will you rewrite something from scratch ?
I need to know

User avatar
tierra
Site Admin
Site Admin
Posts: 1343
Joined: Sun Aug 29, 2004 7:14 pm
Location: Salt Lake City, Utah, USA
Contact:

Post by tierra » Wed Dec 14, 2005 7:45 pm

Progress is being made to include wxIFM in the next major release of wxWidgets. I don't know where it's at though and don't have any details on when and how it's being done.

romeo9423
Experienced Solver
Experienced Solver
Posts: 72
Joined: Mon Nov 08, 2004 3:36 pm

Post by romeo9423 » Fri Dec 16, 2005 6:45 pm

I have tested wxIFM-1.0.5 (latest version on windows XP and wxWidgets-2.6.2 and while it seems very professional it's really too sensitive.
If you play with the sample app demo1.exe and if you click several times on tabs sometimes your window just undock. For now I will stick with wxDockit.


tierra wrote:Progress is being made to include wxIFM in the next major release of wxWidgets. I don't know where it's at though and don't have any details on when and how it's being done.

SnakeChomp
Filthy Rich wx Solver
Filthy Rich wx Solver
Posts: 235
Joined: Sun Oct 10, 2004 2:53 am
Contact:

Post by SnakeChomp » Sat Dec 17, 2005 3:07 pm

You're making a horrible mistake if you chose wxDockIt of wxIFM over this perception of sensitivity. If you double click things will undock. If you don't want them to undock, don't double click. If you think its too sensitive turn down the double click delay in your system settings. Discarding something without understanding it is never the best course of action.

romeo9423
Experienced Solver
Experienced Solver
Posts: 72
Joined: Mon Nov 08, 2004 3:36 pm

Post by romeo9423 » Sun Dec 18, 2005 5:13 pm

Actually it's worst than a bug it's a feature !!
Let me explain :
it seems that the problem is not related to the click delay but if you select a tab and you move it it undocks.
First I was shocked but I have checked with Visual Studio and it's the same
behaviour(I didn't know).
But the BIG difference is with Visual you really need to move it to undock whil with wxIFM it's too sensitive.
Sometimes you just want to select a tab(so you click on it and if in the same time you move slightly) it undocks but I repeat this is not what I want.






SnakeChomp wrote:You're making a horrible mistake if you chose wxDockIt of wxIFM over this perception of sensitivity. If you double click things will undock. If you don't want them to undock, don't double click. If you think its too sensitive turn down the double click delay in your system settings. Discarding something without understanding it is never the best course of action.

SnakeChomp
Filthy Rich wx Solver
Filthy Rich wx Solver
Posts: 235
Joined: Sun Oct 10, 2004 2:53 am
Contact:

Post by SnakeChomp » Sun Dec 18, 2005 10:55 pm

The drag threshold is 4 pixels of movement, based on the system configuration. You need to move the mouse more than 4 pixels away from where you clicked it for a drag to start. The reason why it seems less sensitive on visual studio is because visual studio lets you reorder the tabs by dragging them. The tabs only undock (and float in VS 2005) when you drag the mouse outside of the area of the component that has the tabs. wxIFM does not have tab reordering in this fashion, so as soon as a the mouse has moved farther than 4 pixels from where you clicked the tab will undock. I would gladly accept any patches adding tab reordering via dragging which would also fix this sensitivity issue.

romeo9423
Experienced Solver
Experienced Solver
Posts: 72
Joined: Mon Nov 08, 2004 3:36 pm

Post by romeo9423 » Tue Dec 20, 2005 5:19 pm

Ok thanks for this information.
finally I have solved the problem by using wxNotebook instead of wxIFM tabs, ite means that you cannot undock some tabs but that's not a problem for now.
I have another question regarding maximized size.
How can I start an application maximized because I have tried to pass wxMAXIMIZE inside wxFrame contructor in your sample code but it doesn't work. Actually if I launch it from my IDE (CodeBlocks with mingw) it works but if I double-click directly on it inside explor



SnakeChomp wrote:The drag threshold is 4 pixels of movement, based on the system configuration. You need to move the mouse more than 4 pixels away from where you clicked it for a drag to start. The reason why it seems less sensitive on visual studio is because visual studio lets you reorder the tabs by dragging them. The tabs only undock (and float in VS 2005) when you drag the mouse outside of the area of the component that has the tabs. wxIFM does not have tab reordering in this fashion, so as soon as a the mouse has moved farther than 4 pixels from where you clicked the tab will undock. I would gladly accept any patches adding tab reordering via dragging which would also fix this sensitivity issue.

User avatar
ABX
Can't get richer than this
Can't get richer than this
Posts: 810
Joined: Mon Sep 06, 2004 1:43 pm
Location: Poznan, Poland
Contact:

Re: Future docking lib based on wxIFM or not ?

Post by ABX » Tue Dec 20, 2005 8:23 pm

romeo9423 wrote:I would like to know if there will be a standard docking lib very soon in wxwidgets.
Define "soon". If you ask about release in weeks or a few months I doubt but if you are familar with using CVS probably earlier. There was some kind of "mistake" with taking wxFL in the past. Now we have wxFL, wxIFM, wxDockIt and wxAUI. Probably some more. Final decision about including one or another will be influenced by such factors like: how natively behave and look each candidate, how stable it is, how its API, coding standards and build routines follow wxWidgets own solution. In other words many factors which are not easy to answer. Most probably final decision will be discussed in development mailing list.

ABX
CVS Head, 2.8.X
wxMSW, wxWinCE, wxPalmOS, wxOS2, wxMGL, bakefile
gcc 3.2.3, bcc 5.51, dmc 8.48, ow 1.6, vc 7.1, evc 3/4, pods 1.2

spicerun
Earned a small fee
Earned a small fee
Posts: 24
Joined: Thu Aug 04, 2005 8:14 pm
Location: Dallas Texas

Re: Future docking lib based on wxIFM or not ?

Post by spicerun » Wed Dec 21, 2005 12:41 pm

romeo9423 wrote:Hi,
I have started to develop an app using a docking bar interface. For that I have used wxdockit but before to go any further I would like to know if there will be a standard docking lib very soon in wxwidgets.
...
I need to know
I'm also waiting to see. I know wxFL is buggy and appears to be dropped. I've been trying out wxDockIt, but I'm concerned as there doesn't seem to be any progress with it for some time (I would like to see wxDockit be able to compile into other builds that are choices of debug or nodebug images as well as static or dynamic library images....I've been working on the static library image but the bakefiles are getting in my way on my wxGTK development). I'm looking at the possibility of replacing wxFL in wxWorkshop as well.

As for wxIFM, I'm getting tired of being told it is in the wxWidgets repository, only to check out the latest wxWidgets and not finding it there. I figure I will try wxIFM when I get there.

romeo9423
Experienced Solver
Experienced Solver
Posts: 72
Joined: Mon Nov 08, 2004 3:36 pm

Re: Future docking lib based on wxIFM or not ?

Post by romeo9423 » Thu Dec 22, 2005 12:38 am

These few weeks I am playing with wxIFM and I think it's the best candidate as a docking lib even if I am not totally convinced.
In particular I don't know if it's a bug but I have an app with one Frame that is initialized with one docking bar on the left and one on the bottom.
If I dynamically change the content window and if my frame is not maximized when I resize it I can see some artefacts.
Actually it seems that my new content window doesn't change its size.
Besides when I dynamically change the content window, it's really changed once I have tried to resize my frame.

Do I need to do more than that :






// set a new content window
wxTextCtrl *content = new wxTextCtrl(m_root_panel, wxID_ANY, wxT("Zobby"),
wxPoint(), wxSize(), wxTE_MULTILINE | wxTE_WORDWRAP);

m_ifm->SetContentWindow( content );






spicerun wrote:
romeo9423 wrote:Hi,
I have started to develop an app using a docking bar interface. For that I have used wxdockit but before to go any further I would like to know if there will be a standard docking lib very soon in wxwidgets.
...
I need to know
I'm also waiting to see. I know wxFL is buggy and appears to be dropped. I've been trying out wxDockIt, but I'm concerned as there doesn't seem to be any progress with it for some time (I would like to see wxDockit be able to compile into other builds that are choices of debug or nodebug images as well as static or dynamic library images....I've been working on the static library image but the bakefiles are getting in my way on my wxGTK development). I'm looking at the possibility of replacing wxFL in wxWorkshop as well.

As for wxIFM, I'm getting tired of being told it is in the wxWidgets repository, only to check out the latest wxWidgets and not finding it there. I figure I will try wxIFM when I get there.

Post Reply