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.

Bug 214154 - Simple API to manipulate top component positions and sizes
Summary: Simple API to manipulate top component positions and sizes
Status: NEW
Alias: None
Product: platform
Classification: Unclassified
Component: Window System (show other bugs)
Version: 7.1.2
Hardware: All All
: P3 normal with 4 votes (vote)
Assignee: Stanislav Aubrecht
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-06-13 21:00 UTC by tdanard
Modified: 2015-01-02 17:58 UTC (History)
1 user (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments
Tiling options (20.60 KB, image/png)
2012-06-13 21:00 UTC, tdanard
Details

Note You need to log in before you can comment on or make changes to this bug.
Description tdanard 2012-06-13 21:00:58 UTC
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.
Comment 2 tdanard 2015-01-02 17:58:33 UTC
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.