After about 1.5 years working on version 1.1.1, I’ve decided to call 1.1.1 stable. The reason for this step is simple: there have not been any drastic API changes in the past months (except the new Toolbar-extension), and the amount of bug-reports has been decreasing since a long time.
For Version 1.1.2 I plan to do the following:
[ul]
[li]There are many “TODOs” concerning deletion and renaming of old, unnecessary functions, classes and interfaces. The very first step will be to perform these pending tasks.
[/li][li]There is still the open question about a DockTheme that looks like Eclipse 4.x. I’ve been working with Eclipse 4 for a while now, and I don’t like the look of Eclipse 4.x. Actually I hate it. There is no point in going to the details, but… Eclipse is not a web-site and it should not look like one. So this feature does not have a high priority on my list, I’m not even certain if I will add this theme.
[/li][li]What I would like to add is a new good looking, easily customizable theme. Perhaps something that is generated from some CSS files. I’ll have to think a little bit about the design, but the idea would be that the existing themes get obsolete.
[/li][/ul]
Finally there is the question about the future of this community. The simple truth is, that supporting you guys in this forum eats up a lot of my time. You see: there are about 2-3 questions per week, and each question requires a lot of back and forth to find out where issues are and how to fix them. So in the future I might reduce my time spent in this forum, and hope/expect that you guys help each other a little bit.
Just some little improvements. I started on a CSS-theme, but there is nothing useful yet available.
[ul]
[li] ! API: Added method “isEnabled” to ExpandableToolbarItem and all associated listeners.
[/li][li] - API: ToolbarItemDockable.isEnabled now returns false if there is no ToolbarItem to show in some state
[/li][li] - API: Toolbar/ToolbarContainer/ToolbarGroupDockStation now all support custom background painting (with keys ThemeManager.BACKGROUND_PAINT + “.station.toolbar”/".station.toolbar.container"/".station.toolbar.group")
[/li][li] - Bugfix: Sometimes a child of a ScreenDockStation could not be moved by the WindowMover because the DockRelocator consumed the MouseEvents.
[/li][/ul]
Beni, again thanks for everything. DF just got better! Good work!
About Eclipse 4 theme - there are people who do not share your opinion about it (including myself). I think Eclipse 4 L&F is definitely better than the Eclipse 3 one. But there is no point discussing the taste, right? Both are useful and I would really like to have both as options, if possible.
Anyway, what I wanted to ask is - do you have any plans on uploading 1.1.1 to the Maven repository please? For that matter, the 1.1.2 as well?
I’ve given up on maven… not because maven is a bad thing, more because it is not a feature that must be done. But if someone feels like publishing and maintaining the lib on maven go ahead, but I won’t do anything more than accept required git-requests to achieve that goal.
Eclipse 4.x: well… if the CSS-theme is going to work (I did not have much time in the past few weeks, still working on the infra structure) then creating an Eclipse 4.x theme should be a matter of hours. At least that is my goal
[ul]
[li] - API: when removing a Dockable from a StackDockStation, the station tries to be more intelligent with selecting the next focused Dockable: it uses the FocusHistory instead of just selecting the “index+1’th” tab.
[/li][li] - Bugfix: When a DockStation with children was put onto another DockStation at a location where a placeholder-map was available, that map could have been applied to the new child station. This was wrong: the station already had a layout, it did not need a new one.
[/li][li] - Bugfix: Made the arch of the Eclipse-tab a bit more smooth
[/li][/ul]
[v1.1.2p1c]
[ul]
[li] - Bugfix: GlassedPane could throw exception when mouse was moved at the wrong time
[/li][/ul]
[v1.1.2p1d]
[ul]
[li] - Bugfix: Fixed a bug where CControl could no longer read layouts stored in the binary format
[/li][/ul]
[v1.1.2p1e]
[ul]
[li] - API: The “toFront” method of AbstractCDockable is more powerful now: it even requests the focus if the application is not visible (yet).
[/li][li] - Bugfix: If a Dockable on a CombinedStackDockStation is shown on a tab and a menu, changes of the Dockable (like the icon) were only forwarded to the tab.
[/li][li] - Bugfix: DockController uses the ClassLoader of “DockController” and not of “this” to load resource files. This resolves an issue when using the framework with OSGi.
[/li][li] - Bugfix: Toolbar extension: an expanded ToolbarDockStation could no longer be shrunk.
[/li][li] - API: SplitDockStation now better supports Components with a minimum size. The minimum size of a node no longer depends on the current location of the divider, and if a Dockable hits its minimum size the other Dockables must shrink until they hit their minimum size too.
[/li][li] - Bugfix: CWorkingArea.show is now more intelligent, if a Dockable in the history is not a child of the working-area, yet still associated, then its location is used to place the new Dockable (instead of ignoring the history).
[/li][li] - Bugfix: Normalizing a maximized Dockable associated with a working-area now more often produces good results (instead of placing the normalized Dockables randomly and not on the working-area)
[/li][/ul]
Version 1.1.2p2 brings an important update in form of 3 new methods, all part of CDockable. All these new methods have similar names starting with “setLocationsAside…”. Why are these methods important? Because they solve the long standing issue of showing a new dockable close (=as neighbor) of an existing dockable. Each of these methods will copy the entire history of locations of one dockable, modify that history, and apply it to another dockable. They will also modify the layout directly, by adding placeholders for the new dockable.
As a result, the method “CLocation.aside” is now deprecated and should no longer be used.
This update also includes some bugfixes, and removal of some old API that has been marked deprecated a long time ago.
[v1.1.2p1f]
[ul]
[li] - API[Common]: It is no longer possible to stack CDockables with differnt working-areas. This keeps actions like “normalize” more consistent.
[/li][li] - Bugfix[Common]: Maximization mode is more intelligent: when unmaximzing Dockables all instead the top level elements are scanned for known old locations, and if maximizing the stored old location is not deleted unless the new maximized Dockable is known to have a location.
[/li][li] - API[Common]: The action “ensureBasicModes” now also uses group-movement, so calling this method behaves very much like clicking all the “normalize” buttons of all Dockables
[/li][li] - API[Common]: After hiding a CDockable the extended-mode of all Dockables that were not in a baisc mode is restored in the order of the focus history.
[/li][/ul]
[v1.1.2p1g]
[ul]
[li] - Bugfix[Toolbar]: Code for reading the layout of a toolbar and creating a ToolbarContainerDockPerspective was using an outdated format.
[/li][/ul]
[v1.1.2p1h]
[ul]
[li] - Bugfix: Arch could throw an exception if too small
[/li][li] - API: CGridPerspective offers a new method “unpack”, making sure there is no stack of dockables in the grid.
[/li][/ul]
[v1.1.2p2]
[ul]
[li] - API: ToolbarItemDockable now features a BackgroundComponent and thus supports things like true transparency
[/li][li] - API: DockStation and Combiner now offer methods to add a placeholder “aside” some given location
[/li][li] - API: CDockable now offers methods to automatically set the location close to the focused Dockable (CDockable.setLocationsAside…)
[/li][li] - API: Moving a maximized CDockable (moving means the parent does not change) does no longer normalize the Dockable
[/li][li] - Bugfix: SplitDockStation.removePlaceholder did not work properly, the placeholders were not removed from leafs or nodes
[/li][li] - API: Added methods to CMenu and CDropDownButton for getting the CActions that were added to the menu
[/li][li] ! API: EclipseDockableDisplayer removed, and EclipseDockableDisplayer2 renamed to EclipseDockableDisplayer
[/li][li] ! API: Removed NoTitleDisplayer
[/li][li] ! API: Removed several methods from CControl, CDockable and CPerspective which were marked deprecated since a long time
[/li][/ul]
Version 1.1.2p3 adds the possibility to set the shape of a ScreenDockWindow. This can be nice if the framework is used in an environment that supports transparency, but not translucency (where pixels can have any alpha value between 0 and 1).
The shape of the window is set with help of the class “WindowConfiguration”.
And I worked a bit on the CSS-theme (the only missing feature of the engine is now to select more than one css-rule at once).
[v1.1.2p2a]
[ul]
[li] - Bugfix: when removing a child station from a SplitDockPerspective, the placeholders were not stored properly
[/li][li] - Bugfix: when dropping a Dockable on a SplitDockStation the location was not always read correctly (caused by a change when implementing the “aside” feature)
[/li][li] ! API: CloseableDockableMenuPiece now sorts its items
[/li][li] - Bugfix: Replacing a “Placeholder” with a “Leaf” does no longer delete the PlaceholderMap
[/li][li] - Bugfix: SplitDockStation is more careful when removing placeholders from PlaceholderMaps
[/li][li] - Bugfix: SplitDockStation does no longer move Dockables after combining if said Dockables have a placeholder
[/li][/ul]
[v1.1.2p2b]
[ul]
[li] - Bugfix: fixed an issue where the “InternalDockDialog” could not be dragged properly when its parent window was not at position 0/0.
[/li][li] ! API: Removed unnecessary parameter from “ScreenDockWindow.setWindowBounds”
[/li][/ul]
[v1.1.2p2c]
[ul]
[li] - Bugfix: StackDockStation did not properly add a listener to its StackDockComponent when the component was set and the station already had children. As a result using the overflow-menu for selecting a Dockable did not trigger a focus change.
[/li][li] - Bugfix: Fixed an issue where the insets of the EclipseBorder was ignored when calculating the minimum/preferred size of a Dockable.
[/li][/ul]
[v1.1.2p2d]
[ul]
[li] - API: Made ListSpanStrategy more resilient against early calls to its methods (it did throw an NPE)
[/li][li] - Bugfix: ListSpanStrategy did not respect the parameter “spanFactoryId” in its constructor
[/li][li] - API: InternalScreenDockWindowFactory supports setting the layer of the newly created dialogs
[/li][li] - Bugfix: Made ScreenDockStation aware of extensions when calling the drop(Dockable) method
[/li][li] - Bugfix: Made ToolbarGroupDockStation searching for a DockController by its parents when missing one
[/li][/ul]
[v1.1.2p3]
[ul]
[li] ! API: The border of a ScreenDockWindow can now be used to move the window, while resizing is not allowed. In previous versions the border simply was removed if resizing was disabled.
[/li][li] - Bugfix: CToolbarContentArea made minimized Dockables invisible (actually their size was always close to 0/0)
[/li][li] - API: If a focused Dockable is put onto a FlapDockStation, the station does open its window
[/li][li] ! API: Workarounds for Java 6 and 7 now make a distinction between transparency and translucency, opening the path for better transparency support.
[/li][li] - API: WindowConfiguration supports a new property: shape. Shape tells which parts of a ScreenDockWindow are visible, and which are not.
[/li][/ul]
Nothing interesting to report other than a few bugfixes.
[v1.1.2p4]
[ul]
[li] - API: Implemented all the “aside” methods in the toolbar extension
[/li][li] - API: AbstractCDockable.setLocationAside no longer sets a generic CLocation but a CExtendedModeLocation, which will make the LocationManager to access the original DockableProperty. This makes the method using placeholders more efficiently.
[/li][li] - API: Border of FlapWindow is now customizeable
[/li][/ul]
[v1.1.2p5]
[ul]
[li] - Bugfix: the glass extension could produce a NullPointerException when using only the Core API.
[/li][li] - API: Added an annoying dialog that pops up when using the Core API, warning the developer that the much better Common API is available.
[/li][li] - Bugfix: If a dockable was already marked as the “focused dockable”, but the event of registering the dockable was delayed, then the already present DockTitles of said Dockable were not informed about the focus-state.
[/li][li] ! API: The way in which LayerPriorities are merged has been changed - clients should not be affected by this change.
[/li][li] - API: Default background color of ToolbarContainerDockStation is now “null”, but clients can also set a custom color.
[/li][/ul]
[v1.1.2p6]
[ul]
[li] - API: added a new feature where clients can change the behavior of externalized CDockables: they are no longer stacked, but splitted.
[/li][li] - API: added a tutorial explaining the new feature of externalized CDockables.
[/li][li] ! API: several changes to the API of CGridArea and ModeArea in order to implement the new feature (see above)
[/li][li] - API: new ExternalizingCGridArea, includes some factories.
[/li][li] ! API: added property “isNormalizeable” to CDockable and listeners, this property should not be used by clients however.
[/li][/ul]
[ul]
[li] - API: ToolbarDockStation is no longer transparent per default, clients can make it transparent with the ThemeManager, the constant BackgroundPaint.TRANSPARENT and the key ‘ThemeManager.BACKGROUND_PAINT + “.station.toolbar”’
[/li][li] - API: If a ScreenDockWindow is not resizeable, but has a border and is moveable, then the border appears on the same side as the DockTitle
[/li][/ul]
Version 1.1.2p12
[ul]
[li] ! Bugfix: if a MultipleCDockable was stored as child of another MultipleCDockable, storing and loading the layout failed. The reason for that was a feature in DockFrontend.addDockable, where the layout of any new Dockable was updated if an old layout was stored in the frontend. In the case of a MultipleCDockable there is an old layout stored, because they are “missing” at the time when the layout-file is read. The solution is to be more careful about applying old layouts when loading a new layout at the same time.
[/li][/ul]
[ul]
[li]- API: drag and drop operation can be cancelled by pressing CControl.KEY_CANCEL_OPERATION (default is ESCAPE)[/li][li]- API: refined behavior of ActionContentModifier, if a modifier represents many properties (e.g. disabled and vertical) then it can have many backup modifiers (e.g. just ‘disabled’ or just ‘vertical’)[/li][li]- Bugfix: many small fixes by Karl-Philipp Richter[/li][li]- Bugfix: DockStations having width or height smaller or equal to 0 do no longer support drag and drop (because they are invisible to the user)[/li][li]- API: Added DockStationDropLayerFactory, a way for clients to define which areas of the screen can be targets for drag-and-drop operations[/li][/ul]
Version 1.1.2p18
[ul]
[li]- API: New method AbstractCDockable.toFront allows clients to focus a Dockable, and a child Component of that Dockable with only one method call [/li][/ul]
Some new bugfixes, and actions may now listen to global key events (global = on any Dockable).
[v1.1.2p18a]
[ul]
[li] Bugfix: Tabs of the Flat-theme did not respect the foreground color that was set by the client.[/li][/ul]
[v1.1.2p19]
[ul]
[li] Bugfix: An exception was thrown when a CDockable was externalized, the eclipse-theme was selected, and someone was calling CControl.destroy[/li][li] API: added “setAcceleratorIsGlobal” to CDecoratableAction, allowing actions to monitor all key events of the application.[/li][/ul]
Good work!