I've been working on a base view in our tooling that would allow for drop down elements. What I mean by this is that if there is an error in the view, then a label will drop down and let you know, or if you want to search the view for something, then hit a key combination and a search box will drop down. There may be other stuff that I can put in at a later date, but for now I am focusing on those two. I'm doing this because I think it's a good way of getting rid of some of the dialogs that pop up in our tool.
The Eclipse layouts though, don't seem to think that this is a good idea. They want to layout my hidden area. They want to lay it out in an unhidden sort of way. Now to be fair, I haven't told the layout that I don't want hidden widget laid out. The layout is just doing what it was written to do. There are two ways that I can think of to get around this. One is that I don't create the hidden widget area until it is needed and then drop it down. The other is that I create some layout data for the hidden widget and then tell that layout data that I want to exclude this widget from laying out. Don't worry, my widget has no issues with being excluded. It has a very high self esteem.
The first solution makes for a cleaner API because the class doesn't have to know anything about layouts. However, once that widget is created, if a layout happens in it's parent while it exists, I have to handle that somehow, or I am back to square one with the layout managing my widget. I think that this will lead to a lot of suspect code as I try and listen for events and stop them from affecting my hidden area that is now shown.
The second solution will probably give me a better result as I will be using the Layout API and it will be doing what it thinks it is supposed to be doing. However, my class will now have to figure out what the layout of the parent is, in order to create a layout data instance for my widget. This means that I have to have a call to set the layout data, or I need to modify my creation function to take a layout data class in. Also, because the layout data classes are not sub-classed off of a superclass, I have to handle each possible type of layout data independently, which is a bit cumbersome.
For some reason I am not too crazy about either solution. It's not that there is anything glaringly wrong with either solution, but this just feels as though it's something that I shouldn't have to do. At least not in an object orientated language. Ideally I think there should be a create data type call within the layout classes. This call could return a layout data instance that is proper for their particular type of layout. The layout data base class could contain all the generic stuff like width hint, height hint, and whether or not this particular widget should be excluded, and therefore I could at least manipulate some of the layout attributes on my widget without having to know specifically how the parent it going to request it's children to layout.
I'm going to continue to research and think about this, but first I think I need to lay down. I may not be able to though, as my children are not hidden.
-Rodney