Pictures would have helped, but they are difficult to get without writing the code. Let me see if I can explain it a little better.
In the first scenario I described previously each Task would be represented by a tabbed pane in a tabbed pane holder. The tab would have the name of the task, while the pane (or body of the tab) would look just like our current TaskFrame body, with the LayerNameView on the left side of a slider and the LayerViewPanel on the right side of the slider. In the second scenario I described the user interface will look very close to the way it does now. Tasks will be represented by InternalFrames. However, the TaskFrame will now also serve as a tabbed pane holder, and the LayerNameView and the LayerViewPanel will now become tabbed panes in this holder. The real difference between the two scenarios is how "supplemental" GUI components like dialogs and other internal frames would be handled. In the first scenario they would become tabbed panes in the WorkbenchFrame window. In the second scenario they would become tabbed panes in the TaskFrame window. I think the second scenario makes more sense, but I wanted to check with others. If I go with the second scenario any supplemental GUI components that apply to the program as a whole, and not to an individual task, will need to be displayed as internal frames. This is how we do it now anyways. I will also note the user will be able to move any of the tabbed panes I described above, or pop them out to a floating window, and then pop them back in. SS On Wed, Apr 1, 2009 at 8:55 AM, Larry Becker <becker.la...@gmail.com> wrote: > Hi SS, > > I'm not sure I am visualizing what you mean in the two options correctly. > Setting aside parent issues, what would you envision that the interface > would look like with two tasks open? Can you cobble a picture together that > gets the point across? > > regards, > Larry > > On Wed, Apr 1, 2009 at 10:09 AM, Sunburned Surveyor > <sunburned.surve...@gmail.com> wrote: >> >> I believe that OpenJUMP was originally designed with an "MDI" >> (Multiple Document Interface) architecture, where each "document" was >> a single Task. I was curious if our porgrammers and users felt that >> this was a useful concept that we should adhere to. Are supplemental >> views and dialogs (like the Output Window and the Feature Info Dialog) >> task centric? >> >> Does it ever make sense to display a window or dialog that isn't >> related to information in the active Task? >> >> I'm curious, because it will change how I choose to integrate a >> docking window framework into BizzJUMP. I'm thinking that the >> TaskFrame class is the appropriate parent of the docking window tree. >> It only makes sense to have the WorkbechFrame as the parent of the >> dociking window framework if we will be displaying child tabs in the >> Workbench Frame. >> >> There are basically two (2) ways I can approach the docking window >> framework integration: >> >> [1] Make the WorkbenchFrame the parent of the docking window tree. In >> this scenario tasks would be child tabs of the WorkBenchFrame, and >> other "views" related to all tasks (if any exist) would also be >> displayed as tabs. >> >> [2] Make the TaskFrame class the parent of the docking window tree. In >> this scenario tasks would remain in their current implementation as an >> InternalFrame. Each InternalFrame would be the parent of its own >> docking window tree. >> >> Thank you for your suggestions. >> >> The Sunburned Surveyor >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Jump-pilot-devel mailing list >> Jump-pilot-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > > > -- > http://amusingprogrammer.blogspot.com/ > > ------------------------------------------------------------------------------ > > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > ------------------------------------------------------------------------------ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
