This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Based on requests on [nbdev] enhance windows API do allow following: 1) Allow to choose type of container used for newly created mode. Currently the MultiTabbedContainerImpl is used as default and there is no way to specify to use Split... one. 2) Allow to dock TopComponent into mode under container specific constraints. Currently even the mode using the SplittedContanerImpl is used, there is no possibility to add TopComponent e.g. to the NORTH part of it. 3) Allow to maximize, minimize etc, modes. Note: The above subtassk could be devided to more RFE's, do it if more convenient.
Yes, it's not the first time our clients requested such or similar feature. CCing architecture team. There are couple of problems connected with design and impl of such API extension: - extension tends to be big, if you allow container types to be part of API, bunch of other things will follow. So in the end, this tends to be huge amount of work - but that's ok I think. - we mustn't forgot backward compatibility and make API flexible, so that it's maintainable. It wouldn't be good for example to hard code existing types of containers, frames etc., because they will change for sure. All gui is changing frequently nowadays. I vote for "hashtable like" type of API for this, if we decide to go for it.
This is more desirable for Platform developers than you may think. We are often creating Modes "on-the-fly" where we don't know the Modes at compile time, and can not declare the type, effectively making the MDI useless, and SDI a hazzle. Our sort-term solution (not good) is to declare a large set of "generic" Modes, that are "tailored" to the need in runtime, e.g. "Mode24" is currently used for "Colorimetric Compares", put the newly created MultiCompare window there, while the "SF600-4392" Measurement panel goes into Mode07, where the "SF600-4392" related stuff is placed. Becomes messy. A "hashtable" solution, similar to CloneableTopComponents (also TC?) putClientProperty( "Persistence", "Never" ) kind of thing.
Set target milestone to TBD
Niclas, can you describe situations under which you may need to create new mode dynamically and declare its type on the fly ? It would help us to recognize what we didn't think of, thanks. Passing to winsys guys.
As requested, here is a brief of what we want to do; We have a fairly large number of generic panels (TCs), that works against an ExplorerManager.Provider. Each present a different view of the same data selected in the explorer manager that they are connected to. These are, in our case, used for analysis of Reflectance objects (colors, sort of). When the OpenDetailedCompareAction is invoked, it docks the TC into the active TCs Mode, so that the relationship is maintained (although the user can break that out, but our users are not that advanced, and if they were, they would know what they are doing). We then have another set of TCs that implements the ExplorerManager.Provider interface, primarily different sources of these Reflectance objects. The most apparent case; The user has one or more Spectro Photometers, which measures Reflectance, and he creates a Spectro object (Data/FileObject) for each physical spectro, and perhaps even a few for different configurations (Specular inclusion, Aperture size etc). Now, when he right-click on the Spectro object, and invoke the MeasureAction, we open a Mode (create it if necessary) for THAT particular spectro. The MeasurePanel contains an ExplorerPanel/Manager which is populated for each measurement being made, prior to saving them, and the user have the choice to shoot up ANY of the analysis panels, which will dock into the same Mode, maintaining the relationship. All this works, EXCEPT I can not make the custom mode, e.g. "Measure - DCI SF600/SCI/MAV",to have '<frame type="internal">', as it is declared in XML, in runtime. This issue is outstanding in our application, and makes it rather confusing at the moment.
Btw, the issue is so urgent for us, that we will probably hack the NB source for a solution soon.
Seems it is really important issue, unfortunatelly (I think) we can't introduce new API to 3.4 yet. Increasing priority and settinng target milestone to 4.0.
Yes Peter, agreed. Niclas' example shows one of weaknesses of current winsys API - inability to dynamically maintain visual relationship of group of components in terms of their layout. I'm wondering now - what if we follow awt constraint model (TopComponent=awt.Component, Mode=awt.Container)?
As I said; I am aware of the 3.4 freeze, and we will investigate our options outside that path, as we are doing with other parts of Core. I also think that this is part of a much greater debate; What is Core's responsibility and what is OpenAPI's?? and the subsequent discussion of the break-out of compiler and debugger (maybe even Editor) related stuff from OpenAPI.
To Dafe, yes I'd like that AWT constrained model. But there is also necessary to figure out the setting of frame type for mode.
Niclas: see issue #17815 for all unrelated stuff re. breakup of APIs etc. In principle it should be possible, though clumsy, to do the requested handling in 3.4: open the TC programmatically into some anonymous mode, find the mode, find its XML description on disk, and modify the XML to control its appearance. Does this not work, and if not, why not (since the WinSys API seems to say it will)?
Yes. The way Jesse suggested is possible in principle but not very good for runtime.
...because besides the annoyance of parsing/generating XML, there is no specification of when different parts of the system will actually be updated or written to disk, and the implementation behavior is probably near-random due to the complexity of the Filesys + Datasys + WinSys combination. So module code would need a lot of timeouts, pauses, etc., which are hard to write and inherently buggy. Right?
Yes right. When you add new XML for mode first it is detected by filesystem -> data folder generates PROP_CHILDREN -> new mode is added to workspace. All these steps can be and usualy are asynchronous.
Well, so the new winsys won't be introduced, but the API is needed. To sum it up again: 1) specifying of contraint in mode (container) 2) specifying container type 3) maximize, unmaximize etc modes. are there some more things needed? So what are the concrete solutions? 1) Overload Mode.dockInto(TopComponent) method with Mode.dockInto(TopComponent, Object constraint) 2) I guess this could be avoided, since we probably don't want to support more container types in the future, anyway, possible solution overload Workspace.createMode with additional parameter of int type 3) ?? Mode.maxmize etc? What do you think about it?
*** Issue 20224 has been marked as a duplicate of this issue. ***
FYI: Mode is interface.
Oh, I'm sorry, yes, you are right, I was tired. (Anyway I still prefer interfaces, but the good ones). So here is the problem how to introduce the new API, e.g enhance the interfaces and introduce new ones, or make those methods utility ones and add them somewhere else?
I guess this is already fixed, isn't it ?
Yes I believe this was fixed already in 3.6, where winsys rewrite did happen. All 1) 2) and 3) original requests seems to be supported, closing as fixed.