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.
Created attachment 120799 [details] Tiling options There is only a minimal API to manipulate top component positions and sizes, even for simple needs. In my case, I want to provide a menu item/action that tiles all windows that are not floating. Tiling means reorganizing all windows in a way that they are all visible at once. There are three options (see attached file) - Tile All - Tile Vertically - Tile Horizontally If I understand correctly how top component work, I have to create a memory file system, write xml files describing each new mode, load those virtual files, and move each top component to their respective mode. This is overly complicated. The Swing JInternalFrames are much simpler in comparison. I would rather use top components and I'd like a simple API to do this.
https://blogs.oracle.com/geertjan/entry/tiling_of_editor_documents_in
The example provided by Geertjan uses XML files. Manipulating window states by loading and saving XML files is not a "simple API" in my opinion. I understand that the NetBeans community will not approve the introduction of a non-XML API for manipulating windows. Would it be possible to allow at least "in memory" XML documents, as opposed to files? The org.netbeans.core.WindowSystem interface assumes those files are in a well-known location on disk. Why not pass a org.openide.filesystems.FileSystem object instead? Instead of org.netbeans.core.WindowSystem.load(), we would have org.netbeans.core.WindowSystem.load(FileSystem fs) Instead of org.netbeans.core.WindowSystem.save(), we would have org.netbeans.core.WindowSystem.save(FileSystem fs) etc.