wxIFM issues

[toxicBunny]

First, this is a great and much needed addition to wxWidgets. I haven't had a chance to use it in an application yet, but I'm looking forward to it.

However, I noticed some odd behaviour with the precompiled win32 demo application. This can be seen simply by resizing the frame. It appears that some of the panels have a minimum size set that causes it to draw over the title bar of the panels below it. In the first shot, you can see that the entire text control from one panel appears on top of another panel. Is this normal or just a bug I happened to run across?





I'm running XP Pro SP1 if that makes any difference.

Thanks,

Scott

[SnakeChomp]

This is simply a "feature" and is not really a bug. The windows in the demo have minimum sizes, and if the frame is too small to respect those minimum sizes, things overlap. wxIFM does not try to prevent the frame from becoming too small. This has been explained many times before.

[Jorg]

Hi SnakeChomp,

As it might be a "feature" I want to propose something else. If the windows overlap, how hard is it, to resize the two lower windows so that the two windows on the left do not overlap?

What I mean is that when this happens (and I think you can detect it right?) you can give the left side of the window totally to the windows that are docked to the left, and expand them again. The windows on the bottom will become smaller and stay on the bottom side. This seems like a nicer solution then overlapping.

I would find it not so pretty to see this stay like this in wxIFM, the reason is that the user does not expect this to happen, even when the minimum size is a constraint. Another option is simply refuse the frame to resize beyond a minimum size.

Regards,
- Jorgen

[TanEk]

I agree with Jorg.

[TanEk]

Also one feature who doesn't exist and who have to be implemented is the resizing of a component of a wxIFM interface. Because I make dynamic interfaces (like a component who display the properties of an object wich his type change at runtime so the properties changes and so the component displaying the properties has to be resized...) and I need this feature. Because today we define the properties of a component at the creation but we don't have access to it after... I think wxIFM has to permit us this :

Code: Select all

wxInterfaceManager* manager;

wxIFMComponent* component = manager->AddChild(data);
component->SetDesiredSize(size);

I don't know why you don't permit this and if you can't do this because the conception of wxIFM doesn't permit that, perhaps you have to doubt to your conception...

Also the conception of wxIFM is not wxwidgets like (If i have understand a little how wxIFM works). And many times, you don't name things like wxwidgets. An Example :

For a component, the desired size is not the desired size of the component but the desired size of the area of the child of the component. wxwidgets call this size the client size.

If you want wxIFM to be integrated to wxwidgets, perhaps you have to change little things...

If i'm wrong, could you explain me why ? I'm curious .

[SnakeChomp]

Also one feature who doesn't exist and who have to be implemented is the resizing of a component of a wxIFM interface. Because I make dynamic interfaces (like a component who display the properties of an object wich his type change at runtime so the properties changes and so the component displaying the properties has to be resized...) and I need this feature. Because today we define the properties of a component at the creation but we don't have access to it after...

Reading documentation is always a good thing:

void wxInterfaceManager::SetChildSize ( wxWindow * child,
const wxSize & desired,
const wxSize & min = IFM_USE_CURRENT_SIZE,
const wxSize & max = IFM_USE_CURRENT_SIZE,
bool update = true
)


Change the minimum, maximum, and desired size of the given child window.

Note:
If the width or height value of any of the given sizes is IFM_USE_CURRENT_VALUE, the current min, max, or desired width or height will be used. Passing IFM_USE_CURRENT_SIZE for any of the sizes will not alter that given size.

Parameters:
child Window whos sizes to change
desired New desired size of the window. Note that the window is not gaurenteed to actually be this size after calling this function.
min New minimum size
max New maximum size
update If true, the interface will update immeditely. Otherwise, changes in window sizes will not be reflected until the next interface update.

http://www.snakesoft.net/wxifm/docs/htm ... 570892b5cf

[toxicBunny]

I agree with Jorg as well. I love the fact that wxIFM is so flexible. However, it's like the old saying that "if you give someone enough rope, he'll hang himself." It's a similar story with options in programming. If you give someone too many options they'll eventually end up with something similar to the images above. It seems that there should be some sort of logic to prevent things such as this. Either enforce a minimum size of the parent window if the panels have minimum sizes, or enforce some sort of z-order so that what is drawn still makes sense. It seems to me that a panel at the bottom of the frame should never be overdrawn by a panel above it. If this were the case, some of the panels would be hidden or partially obscured, but the overall appearance would still be acceptable. Essentially, never draw over a title bar.

Of course, I don't really know much about the inner workings of wxIFM and yield to your greater knowledge on the subject. However, either the library or the developer of the end application will need to do something to prevent this because you wouldn't want your users to see this.

I hope this doesn't sound like criticism. I really do appreciate all of your hard work.

-Scott

[SnakeChomp]

As it might be a "feature" I want to propose something else. If the windows overlap, how hard is it, to resize the two lower windows so that the two windows on the left do not overlap?

It would be quite hard, and inefficient, because the bottom container is positioned before the left container. The algorithm works by having a list of containers, and the order in which they appear in the list effects their positioning within the final layout. The first container in the list will be right against the edge of the frame. In the case of the demo, the first container in the list is along the bottom of the frame. The second container is along the left. I calculate the size remaining for each container by subtracting the size that the container I just placed took up from the total size that was available during that step. This process repeats until all containers are placed. See the algorithm code in this function: void wxIFMDefaultInterfacePlugin::OnUpdate(wxIFMUpdateEvent &event) definterface.cpp line 488.

What I mean is that when this happens (and I think you can detect it right?) you can give the left side of the window totally to the windows that are docked to the left, and expand them again. The windows on the bottom will become smaller and stay on the bottom side. This seems like a nicer solution then overlapping.

Nuts to anybody who doesn't have a 4GHz processor! This process would be excruciatingly slow. If there are N containers in the interface, and while positioning the Nth one, a minimum size constraint is violated, the previous N-1 containers must be sized over again. This involves sizing all of the children of these containers over again. Simply sizing the containers now becomes an N^2 operation, hiding a constant which is something like N*M where M is the number of children in N. Each child in N can also have children, so sizing every container is N^2. Here, N is the number of children in that container. Containers can have children that are containers themselves, and those containers are also N^2. Its impossible to generalize how long this process would take when all is said and done, but lets just call it "slow".

Note however that sizing containers is already an N^2 operation. The algorithm which places the top level containers into the final layout is currently linear, so it may not be that much more overhead to what already exists. Changing the algorithm which lays out the containers to function like the container sizing algorithm does would mostly entail a complete rewrite of the function I mentioned above.

Of course, if there are no minimum (or maximum) size values at all, the entire thing is really linear time dependant on the number of children and the number of components required to lay them out. If the demo didn't use minimum sizes, no one would even be reporting the fact that windows overlap.

Another option is simply refuse the frame to resize beyond a minimum size.

I would appreciate any insight as to how to calculate this minimum size value. I can't think of a way to do it, which is why it is not done.

[TanEk]

Reading documentation is always a good thing:

I have done that but without any effect (it's why I posted this request... i'm not stupid...) The SetChildSize simply does nothing. Similar to m_hideable. This variable does nothing...

A remark : SetChildSize logically set the size of the child of the component and not the size of the component... Another illogic naming method... This method should be called SetComponentSize... I would like you reply entirely to my post (and my others...) :

_ Why m_hideable do nothing (it's a feature ?) ?
_ Why SetChildSize do nothing (it's a feature ?) ?
_ Why we cannot have access to the components (wxIFMComponent*) ? It's also a feature ?
_ Why a component is not destroyed when the user close it ? An object wish is not used has to be destroyed !

Thank you very much.

And sorry if my post is too agressive... But wxIFM is not finished (many features doesn't works) and should be reviewed in some points. And the documentation should be much completed. IMHO.

[SnakeChomp]

I have done that but without any effect (it's why I posted this request... i'm not stupid...) The SetChildSize simply does nothing.

What are you expecting this function to do? What this function does is modify the data.m_desiredSize member for the child window. It does not physically resize the child to the exact size you specify. You can change how big you would like the child to be. It is equivilant to changing the proportion of a wxWindow being managed in a wxSizer. If you need a window to absolutely be a certain size, you need to change that windows minimum size, in which case the window will never become smaller than the size you need it to be, and will be resize appropriately.

A remark : SetChildSize logically set the size of the child of the component and not the size of the component... Another illogic naming method... This method should be called SetComponentSize...

Again, you simply lack understand of what this function really does. You want it to do something which it will not, and cannot do. The name it is currently given is appropriate.

I would like you reply entirely to my post (and my others...)

I would like you to use a more appropriate attitude when you post and maybe I be more willing to have a discussion with you about the parts of the wxIFM API which are lacking.

Why m_hideable do nothing (it's a feature ?) ?

As I have stated before, in response to one of your posts as a matter of fact, if m_hideable is not working, it is a bug, and should be reported. I believe you have already done this, so there is no further need to "sound the alarm" that this feature is not working.

Why SetChildSize do nothing (it's a feature ?)

As stated above, I think you have the wrong impression as to what this function actually does. Being misleaded in this way shows that you clearly lack knowledge about how wxIFM truely functions. This may simply be because you did not write it yourself and the documentation does not explain everything adequately, and by no means is an indication that I think you are stupid.

Why we cannot have access to the components (wxIFMComponent*) ? It's also a feature ?

Do any other libraries let you have direct access to internal implementation details? I surely don't think so. wxWindow has private data members for a reason and wxIFMComponent is wxIFM's private data member. If you want access to this data structure, write a plugin.

Why a component is not destroyed when the user close it ? An object wish is not used has to be destroyed !

And I believe that using the close button should hide the child instead of completely destroying it. Why? How are you going to specify a new wxWindow* to wxIFM to represent the newly created window when you want to display the window again? The answer is that you can't. I will be the first to admit that wxIFM could use improvements to its API. I have already proposed an improvement (it is posted to wx-dev) that will actually allow the "destroying and creating" of windows to function as compared to simply hiding and then showing them again.

And sorry if my post is too agressive... But wxIFM is not finished (many features doesn't works) and should be reviewed in some points. And the documentation should be much completed. IMHO.

I am but one man, and I have put countless hours into this project, during my free time, which I could have easily spent doing something else. To sit here and listen to you claim that my project is simply not done, ill designed, and full of flaws, is not the best way to spend an afternoon. If the attitude of your posts was different, I might me more willing to actually answer what you have said in a less frustrated manner. I realize the API can be improved. Ranting about it in this manner however is not the best way to motivate me to implement such improvements.

[SnakeChomp]

Note however that sizing containers is already an N^2 operation.

I have lied. The algorithm is O(N!) in the worst case where N is the number of children in the container. The worst case is where every child has a minimum size, and when trying to size all children, all minimum sizers were violated. In the best case (no minimum sizes, or no minimum sizes were violated) the algorithm is O(N).

[TanEk]

If you need a window to absolutely be a certain size, you need to change that windows minimum size, in which case the window will never become smaller than the size you need it to be, and will be resize appropriately.

And if I need a window to absolutely be a certain size but without minimum size, how can I resize it ?

A remark : SetChildSize logically set the size of the child of the component and not the size of the component... Another illogic naming method... This method should be called SetComponentSize...

Again, you simply lack understand of what this function really does. You want it to do something which it will not, and cannot do. The name it is currently given is appropriate.

I'm sorry it's simply a wrong explanation . For me it's illogic to create this method to set the size of the wxWindow because it's like this :

Code: Select all

ifm->SetChildSize(windowChild,size);

If I really need to resize my child window, simply I have to do this :

Code: Select all

windowChild->SetSize(size);

It's more logic and simple. But if I need to size my component to a certain size, how can I do ?

I think my way is not permit by wIFM because it can't do that, no ? This is why I say : you have to doubt with your conception. It's because you have done a system parallel to wxwidgets no ? I'm not sure about my explanations . I don't understand all the logic of wxifm .

And I have used SetSize without any effect. I'm using wxScrolledWindow has child and the component has not been resized (to permit the scrolled window to be resized...). I can try with a classic panel if you want...

I would like you to use a more appropriate attitude when you post and maybe I be more willing to have a discussion with you about the parts of the wxIFM API which are lacking.

I'm sorry.

As I have stated before, in response to one of your posts as a matter of fact, if m_hideable is not working, it is a bug, and should be reported. I believe you have already done this, so there is no further need to "sound the alarm" that this feature is not working.

And were can I report a bug ?

This may simply be because you did not write it yourself and the documentation does not explain everything adequately.

The little I understood the logic of wxIFM is reading the sources, I think a little effort has to be made to explain the mechanisms of wxIFM... And the reasons of the conception (to understand why you did that and not other thing).

Do any other libraries let you have direct access to internal implementation details? I surely don't think so. wxWindow has private data members for a reason and wxIFMComponent is wxIFM's private data member. If you want access to this data structure, write a plugin.

It's because i think it's more logic to have the access. A component is simply a frame (or a panel) for wxIFM. Like wxwidgets. And wxwidgets give us the access to this components... Because all the properties of a component should be accessible and modifiable all time...

And I believe that using the close button should hide the child instead of completely destroying it. Why? How are you going to specify a new wxWindow* to wxIFM to represent the newly created window when you want to display the window again?

A dialog with wxwidgets is destroyed allways (or not... the choice is let to the user...) when it is closed. And how to display it again ? Simply create a new.

The answer is that you can't. I will be the first to admit that wxIFM could use improvements to its API. I have already proposed an improvement (it is posted to wx-dev) that will actually allow the "destroying and creating" of windows to function as compared to simply hiding and then showing them again.

I don't read wx-dev so I can't be informed... And I search with google and I found nothing.

[TanEk]

About the algorithm of containers... wxwidgets can draw without problem a very little window with many widgets. So it's possible to do that no ? And on thoose screenshots, it's not a problem of min size, it's just a bug. It's easy to see that the components can be more little (IMHO).

A container sizes a widget, but it's the widget who decides to be recised or not. If the container request the widget to be more little than this min size, it decides to not be resized, and give the result to the container. And the container work with it. But we can use a different way. When we create a container, it can know this minimum size (because it knows the minsize of this childs). So let calculate this min size for all the containers (it's simply run throug with the tree of widgets...). Then, if the frame is resized, we can know this min size ! So we can block the resize. And it's not necessary to run throug the tree...). Also when a resized is down, if the algorithm is good, it's simply a complexity of O(N), where N is the number of widgets and containers, the number of node of the tree. I can give you more details if you want.

[SnakeChomp]

It's because you have done a system parallel to wxwidgets no ? I'm not sure about my explanations . I don't understand all the logic of wxifm .

Parrellel to wxWidgets? What? You admit to not understanding wxIFM and I suggest that you do some research of your own.

And were can I report a bug ?

You've told me about it already, that is enough.

It's because i think it's more logic to have the access. A component is simply a frame (or a panel) for wxIFM. Like wxwidgets. And wxwidgets give us the access to this components... Because all the properties of a component should be accssible and modifiable all time...

And here is where you demonstrate your complete lack of understand about wxIFM works. Components are not simply a frame or a panel. They never have been. wxIFMComponent doesn't inherit from anything as its simply a data structure which provides facilities for plugins to add additional information to each component. There is no reason why the application should have direct access to this internal information.

A dialog with wxwidgets is destroyed allways (or not... the choice is let to the user...) when it is closed. And how to display it again ? Simply create a new.

Yet again, you simply don't understand wxIFM. When the pointer for the wxWindow is deleted, wxIFM is unaware of this. It still holds a pointer to the deleted window and thinks that the window is still valid. It will try to do stuff with the window and this will crash. You would need to be able to tell wxIFM what the new window pointer is. That is what is not possible at this current point in time.

I don't read wx-dev so I can't be informed... And I search with google and I found nothing.

Google doesn't really find things posted within the last few days. http://article.gmane.org/gmane.comp.lib ... evel/68130

A container sizes a widget, but it's the widget who decides to be recised or not. If the container request the widget to be more little than this min size, it decides to not be resized, and give the result to the container. And the container work with it.

Wrong.

But we can use a different way. When we create a container, it can know this minimum size (because it knows the minsize of this childs).

This is already how things work.

So let calculate this min size for all the containers (it's simply run throug with the tree of widgets...).

This already happens too. Containers know what their minimum sizers are, its calculated base on the minimum sizes of their children.

Then, if the frame is resized, we can know this min size!

Again, you are almost purposfully ignoring what I have said in previous posts. You obviously do not know anything about the algorithm used to resize the children within containers, and you don't know anything about the algorithm which finally places those top level containers in the interface. You probably don't even know what top level containers are.

So we can block the resize. And it's not necessary to run throug the tree...). Also when a resized is down, if the algorithm is good, it's simply a complexity of O(N), where N is the number of widgets and containers, the number of node of the tree. I can give you more details if you want.

The child resizing algorithm is O(N!) in the worst case. Why? Because I wrote it, I can look at the code, and I can tell you its O(N!). I highly suggest that you actually look at the current code before making more suggestions. Furthermore, I have already explained in previous posts what would be involved in determining whether the placement of a toplevel container has violated a minimum size of another top level container. It would not be O(N), because when a minimum size is violated, all other containers must be sized over again. Why? You can't just simply assume you are able to shrink the container which violated the minimum size. What if shrinking it violates its own minimum size? Then you need to find something else to shrink. This is accomplished by simply sizing all the containers again (except the ones whos minimum size was violated, as they will simply be set to their minimum size and not sized again).

You have already explained that you don't know much about wxIFM. You make assumptions about how wxIFM works and then make arguments which you back up with your assumptions. Your assumptions thus far have all been incorrect. You claim that an API, whos implementation you know nothing about, is poorly designed. This is what makes talking to you such an ordeal. If you want to discuss wxIFM design and implementation with me intelligently, I suggest you take the time to understand how the implementation of wxIFM works before making more false assumptions.

I had originally responded to each of your points when I wrote this message, but I was so frustrated telling you the same thing over and over again that I ignored the simple fact that wxIFM is already capable of resizing a component to be a specific size. It doesnt expose that feature to the programmer, only to the user. If you give me a good reason why it should be exposed instead of saying wxIFM is poorly designed, maybe there will be reason to expose it.

[SnakeChomp]

TanEk, I just remembered that you had previously talked to me about dealing with your wxScrolledWindow. Here is what I have to say about that: Your deisgn sucks. You have a Notebook with some buttons below it, placed into a wxScrolledWindow, and you are complaining that the design of wxIFM sucks because it makes your wxScrolledWindow too small and scrollbars show up. Why are you using a scrolled window? It is impossible to effectively or efficiently use this notebook or its buttons if you constantly have to scroll around to view the entire notebook. As a user of your application, I expect that Windows which do not have resizable contents should not be allowed to be resized. I want to see all of the notebook, all of its options, and all of the buttons, at all times. This is done by not using a wxScrolledWindow and instead setting a minimum size for your panel so that the entire notebook and all of its buttons will always be visible.

I really don't know why you won't just drop the wxSrolledWindow and use a minimum size. Just because you have chosen a poor design which the wxIFM won't let you work around the way you want to does not mean that wxIFM is poorly designed. It means that your application is poorly designed. You want a panel with a minimum size to let the user see all of the notebook at once. Seeing anything less than the whole notebook is pointless and illogical. It makes sense to have a textbox be scrollable, but not a notebook. I will not modify wxIFM's API to suit poor application design.