Dockable toolbars and buttons

Byte-Welt - Projekte / Projects DockingFrames
1

I’m looking for a framework which handle dockable toolbars and buttons in a more complex way than what swing can do. Docking Frame is it able to do that?

By a toolbar, I mean a bar with several buttons inside grouped together. That is simply a component like a JToolbar in swing, but ideally I would like several things:

1, The toolbar has to be floatable and dockable.
[ul]
[li]Floatable : the user can move a toolbar and put them everywhere on the screen.[/INDENT]
[/li][li]Dockable :the user can dock the toolbar on one side or another of the screen. The user can dock one toolbar on another toolbar (e.g. side by side).
[/li][/ul]
2, The button can be move from one toolbar to another toolbar (dockable) or can be put anywhere on the screen (floatable)

The goal is to have a UI fully customizable by user.

Thank you for your answer!

Hervé GUILLAUME

2

What you search is not covered by this framework, DockingFrames has no support for toolbars and I do not plan to include toolbars (at least not in the near future).

It would be possible to use the framework as a basis to implement a toolbar - after all the framework does offer a drag and drop mechanism that is similar to the things needed by the toolbar. But that would require a lot time, I would guess this is a fulltime job for 1-2 weeks.

3

Hello,

After some investigations I could intend to develop this functionnalies in the Docking Framework. It would profit to the community.
Precision: I would do that as full time job at my work. But before I take this decision I have to know: how hard it’s to implement this functionnalities for a personn like me which not known yet the framework. How much time it would take?

To be clear on what functionnalities I would like, some explanations and a picture with annotations (my advice, look first at the picture):

  1. The user can move a toolbar and put it everywhere on the screen (docked on one side or floatable).
  2. Several independant toolbars can be docked on one side and be separate by empty space.
    • The toolbar can be docked everywhere on the side, so the empty space can have an arbitrary size.
  3. Inside a toolbar, buttons could be grouped together and separated by a separator.
  4. A button can be move from one toolbar to another toolbar (dockable) or can be put anywhere on the screen (floatable)

==> in conclusion, user can either move a toolbar everywhere, either move a group of buttons everywhere, either move a button everywhere!

  1. In addition a toolbar (not a group of button) should be retractable.

See the attached image for clearest explanation!

4

I was thinking some time on the list of things that would need to be done. I’m not sure whether my predictions are realistic… and I don’t know how fast you usually work…

Step 0: Branch
We would create a branch where you can play around in any way you’d like. Since the project is on Git this will be done very fast.
Your project would be implemented as an “extension” (like the glass extension). This means that you do not edit the main library directly but an independent project (it could even have a custom licence). We’ll add “extension points” to the framework, for other developers your library will magically start working as soon as it is in the classpath.
Of course I would help if I can. I just have to warn you that I cannot spend much time, and I will be able to answer questions only in the evening.

Step 1: Prototype
The prototype does not look good, not does it support the advanced features. It’s just enough to drag and drop Toolbars.

  • A Button is a child of a Toolbar. A Button can be moved around, hence a Button is a Dockable and a Toolbar is a DockStation
  • A Toolbar is a child of a some other container; hence a Toolbar is a Dockable as well
  • Ordinary (Default)Dockables can be a parent of a Toolbar; hence they are or contain a DockStation

Let’s assume you start with the Toolbar.

  • Understand the interface Dockable
  • Understand the interface DockStation
  • Understand the listeners
  • Copy some code from another station, e.g. from the ScreenDockStation
  • 2-3 days

[Edit: I missed that Buttons are grouped. So a group is a Dockable and a DockStation as well. A group is very much the same thing as a toolbar.

  • 1 day]

Then implement the Button.

  • There is not much to do here for a prototype
  • 1 day

Finally a parent DockStation for Toolbars.

  • Similar to Toolbar, you are doing things you already know
  • 2 days

** Week 1: prototype

Step 2: Support for persistent storage
There are several mechanisms that are needed to persistently store and load the layout.

  • Placeholders identify Dockables that are currently not available or somewhere else. They are optional.
  • DockableProperty describes the location of a Dockable in relation to its parent.
  • And there are factories to save the contents of a DockStations

If you want to use placeholders then you should add them early on.

  • There are some classes that help a lot (PlaceholderList, PlaceholderMap).
  • 1 day

DockableProperty would be the next step.

  • All existing DockableProperties are very small (containing 2-3 fields)
  • Also each DockableProperty is associated with a factory
  • 1 day, propably more like 1 hour

Then the factories for DockStations follow

  • Maybe need to store placeholder
  • Must be able to deal with cases like “there is a Button/Toolbar missing”
  • Otherwise much freedom, all you need to do is to convert the layout into xml.
  • 1 day

Step 3: Support perspectives
That is a completely optional step. Perspectives would allow clients to specify the location of buttons/toolbars without the need to actually create them.

  • really depends on how fast you understand the perspective API
  • important work was done in the previous step
  • 1-3 days

Step 4: Merge branches
That is work that I have to do.

  • One free weekend

** Week 2: all necessary features ready

Step 5: Supporting themes, properties, etc.
Finally you can spend as much time as you’d like on implementing additional features.

  • Using DockActions as Buttons might be a good idea. You would get several buttons with different behavior for free, and they could easily change their look depending on the current theme.
  • 1 day
  • FontManager, ColorManager and TextManager could be used to change the look and content of the Buttons at any time.
  • 1-2 days

** Week 3: making the thing look good

5

Thank you for your answer!
I will make a decision next week. I have to think about the working time involved.
I have another questions:

  • When you say it take 3 weeks, have you considered the fact that I do not know the framework (as you well know)
  • I want to put a preference on my application, so that the toolbars are specific to the precise location to be loaded when the application runs user. This configuration will be saved and loaded from XML files. Is it possible with this framework?

Thank you for your answer!

6
  • When you say it take 3 weeks, have you considered the fact that I do not know the framework (as you well know)

If I would be the one implementing toolbars I would guess:

  • 3-4 days for the prototype. There are no complex interfaces involved. But handling the mouse, calculating the location/size of the Buttons/Toolbars etc. just takes time.
  • Storing the location would take no longer than 2 days. It is not much code, but understanding the interfaces will take much time.
  • Making the thing look good: Maybe up to a week, but that’s because I would support all the features that framework offers. Tthis could be cut down to 2-3 days ignoring the usual features .

So that is about half the time compared to you. Since I put a lot effort in documenting the important interfaces I think that is realistic.

  • I want to put a preference on my application, so that the toolbars are specific to the precise location to be loaded when the application runs user. This configuration will be saved and loaded from XML files. Is it possible with this framework?

About the location: At the moment the location and size of all Dockables at a specific moment is referred to as „layout“. At any time a „layout“ can be stored in memory, or loaded from memory (existing Dockables are reused if possible). The framework offers methods to write a set of layouts into an xml file and there are also some methods to extract one layout and write it in an independent file. Each Dockable/DockStation is associated with a factory that can write/read anything it likes to/from that xml file.

So the answer to this question is probably yes. It may get more complex if you want a thing like „one xml file per toolbar“ (or perhaps not: a pointer if the big „layout“ xml to the „toolbar“ xml file should be an easy solution). I hope that answer helps, because I’m not sure if I understood the question correctly.