Javascript Framework Review

Recently I had to do a Javascript Framework evaluation for a client.

Prerequisites for the frameworks was that the framework should have sophisticated tables (aka Grids) and sophisticated dialogs. Also of interest in our evaluation was if the framework could do treetables.

The things we were interested in for a grid were standard functionality that you would expect in a grid widget; sorting, filtering, cell editing, and also some less common features such as ‘column picker’ – that is, being able to choose which columns to display using a palette. We were also looking at column manipulation (resize, position), and file export.

What we were looking for in a dialog/window, was ability to display as modal dialog, and also dialog manipulation, ie moving, resizing.

These are the results of our research (click on image for better quality) :



The four yellow highlighted columns are the shortlist of candidates (we eventually went with extjs). Y=Feature is offered, N=Not offered, and we also have question marks in our analysis, where it wasn’t clear if it was offered or not. It would have been possible to dig deeper had we more time.

The bottom row is Stackoverflow References (SOR). Which is an indication of popularity and adoptability.

We also looked at cost, but that was not so much of an issue.

The frameworks can be broadly divided into those that are grid-only (SlickGrid, Flexigrid, Ingrid, Datatables and jqGrid), and those that offer a complete GUI framework (jQueryUI, extjs, yUI, DHTMLX, qooxdoo, Smartclient, Wakanda, Webix).

Some of these can also be lumped into a category as ‘framework for plugins’. jQuery and Dojo offer a foundation framework, on top of which plugins can be developed. In hindsight I guess AngularJS/Ember/Bootstrap and friends could also be lumped into that category.

A few words on some of the technologies :

jQueryUI – disappointing. Only really offers a pop-up dialog.

ExtJS – very comprehensive, high adoption, not exactly cheap.

yUI – fairly inconsistent, and has now been discontinued.

DHTMLX – simlar somewhat to extjs

qooxdoo – comprehensive and suprisingly free. The only thing that put us off was the low adoption rate, but hopefully that will change in the future.

SmartClient – Powerful rich components that costs money. Suffers from low adoption rate.

Dojo – Looks quite good. I think we didn’t go for this because of its plugin architecture.



Posted in Uncategorized | Leave a comment

What is a Tree Table?

One of the most advanced GUI Components is the treetable. It looks really fancy, but what exactly is it and what scenarios can it be used with?

As the name suggests a treetable is a melding of a table and tree. The left side behaves like a tree component, nodes can be expanded or collapsed, and the right side behaves somewhat like a table with columns and rows of data.

To understand a treetable lets first have a look at a standard tree component.


A tree component is probably most famously known from Windows Explorer. Visually it is a series of indented nodes that may or may not be expandable.

There are two main ways of using a tree to represent a data structure, and then there is everything in between.

(1) Hierarchy

First it can represent a hierarchical structure. This is very evident in Windows Explorer. A folder can contain many folders, which can also contain many folders, and so on.

As a class diagram it would look like this:



This is a classic Composite Pattern. Each object instance can contain a number of instances of itself.

(2) One-to-Many

A tree component can be used to represent a one to many relationship. For example the Devices Manager in Windows lists a number of devices for a computer:



This model will only expand to one level.

More than one one-to-many relationships can also be represented. Each entity that contains a further entity can be expanded:




(Make sure to use icons judiciously to clearly illustrate to the end user the different entities. In the above example the device nodes should use a different icon).

(3) Combination

The previous two structures can be combined :



As you can see each folder can contain an instance of itself, however a file cannot, and can only be a leaf node.


A treetable supplies extra columns to the right of the tree. The intention is to illustrate that all the nodes and leafs in the tree share properties represented by the columns.

The below example shows how things might look using the ‘combined structure’ example above.


The property ‘type’ is common across all entities. However the property ‘size’ is common only to the file entity. Notice the empty space in the ‘size’ column for the folders.


A disadvantage of a treetable is that you can’t sort over all rows like in a normal table.

If you were to sort all the rows, then you would break the tree.

In Treetables you can only sort groups of children in nodes. For example in our previous example performing a sort on ‘size’ would only have an effect on a group of children belonging to a node like so :



Filtering a treetable presents the same issues as filtering a standard tree.

In a traditional table, performing a filter operation simply removes rows from the table. However when filtering a tree, the structure needs to be maintained all the way down to the root.

This maintaining of nodes in a filtering operation can create a lot of visual fluff.

For example :

Final Points

When to use:

· Hierarchical relationship with properties that need to be shown
· One-To-Many or Combination where the entities share a lot of properties.

When not to use:

· A full sort is required of rows.
· Small number of leafs, of which properties to be shown do not exist in the hierarchy entity. Ie A lot of real estate on the widget is not used. See below:



Framework Examples:

Posted in Usability | Tagged , , | Leave a comment

Loading Spinner with jQuery Promises

In your website you want to call a web service that performs some long running task. It may be loading a large set of data or performing a complex calculation on the server, so you want to animate a spinner or a loading indicator over the screen or component.

You can achieve this effect using jQuery promises.

Assume your web service call looks like this :

Because your function returns an AJAX object it can be used with the $.when function in jQuery.

If you start your spinner, then place your function in the $.when function, and then disabling the spinner in the always block, you will get seamless spinner activity.

All I am using for the spinner is an extjs loading panel using the call window.setLoading(true). However most frameworks have some kind of a spinner, or progress bar. Eg. angular has .

Promises tidy things up by not needing to have the callback method inside the ‘always’ block in the ajax code, making the method more reusable.

Posted in JavaScript | Tagged , , | Leave a comment

Layouts in Extjs

This is a quick overview of layouts in ExtJS.







The absolute layout positions an element using x,y coordinates.

This type of layout should be avoided, as resizing the panel will not resize the components. Only use it if you know what you are doing, and you know why you are doing it.





Allows slider layout. Most famously used in Microsoft Outlook.

A number of other options like ‘animate’ and ‘activeOnTop’ offer some interesting effects.





This layout anchors components to the edge of a container. Useful for forms. Takes string of two values that can be percent or offset pixels (as a negative number). For example, anchor: ‘50% -400’ will always be 50% wide from the left and -400 pixels from the bottom.

All components are anchored to the top left corner.

It is best used in conjunction with a hbox layout. The hbox defines a number of columns, and the anchor layout can lay out the components inside each of these columns.

Appears to ignore sizing of non-container components like labels.





For java developers very similar to BorderLayout in Swing. Useful for your application foundation, where you have a footer on the bottom, a navigation tree on the left, a header on top, and an editor in the middle.

If no width or height is defined for a container, then it will go down the hierarchy to find the widest element. In the above example, the west panel will have a width of 90 because a child element has its width set to 90. If another element is defined in this panel that is wider, then the panel will be set to the width of that element.

This layout is great, and should be the foundation for all your applications.

collapsable and split modes are a couple of interesting options.





For java developers, it’s just like Cardlayout in Swing.

Extjs has two flavours: wizard and tab. A tabbed panel is just a panel with a navigation tool above the panel. A wizard is a panel with ‘next’ and ‘back’ buttons usually on the bottom of the panel.





A Column layout defines a number of columns using percent or fixed width. Fixed width is calculated first, then percent.

Percentage values are calculated from the remainder after the fixed width elements have been added.

I wouldn’t bother too much with this layout. It is more or less deprecated as the hbox layout can fulfill everything that it does plus some more.

More info here.




This layout is very simple. It just fits component into container. It is basically the same as border layout, but with only the center part.




All elements are stretched across horizontally from top to bottom. If a fieldLabel exists, then a label will be added to the left of the component. The label will not be stretched, but the corresponding component will be stretched until reaching the labels minimum width.

A large number of forms can be done using this layout.




Aligns components along the horizontal axis. Used with the flex attribute. Flex is a ratio but represented as an integer number. The below example puts a next to b, but b will take up 75% of the space.

Fixed height items can also be added. Use align : ‘stretch’ or the components will anchor themselves to the left of the container.





Starts at top left corner and lays out component left to right based on the column value.

The table layout is not a sizing layout. Its cells expand depending on the components added. The cells ‘push out’ if you will. A layout like column or hbox will explicitly set the column widths, however this layout will not.

The attributes colspan and rowspan can be used to make cells stretch over more than one cell.


same as hbox but vertical! That’s all there is to say about this one.


Posted in extjs | Tagged | Leave a comment

Creating a simple RCP app with Netbeans and Maven

Netbeans offers a powerful way of modularising a desktop application. In this tutorial we will be creating a simple application. While this tutorial does not showcase many benefits of the netbeans rich client platform (more to come in other tutorials!), it should be enough to get someone started.

Create A New Project

In the file menu select ‘New Project’, then navigate to the Maven folder and choose Netbeans Application :


Select ‘Next’ and enter in a name and location for your project. Other Maven properties may also be entered such as Group Id and version.


In the last screen leave everything as it is :


Select ‘Finish’.
Netbeans should have created three new projects. They all should have the same name, but are appended differently with –app, -branding and –parent.


This is not actually a flat structure. If you expand the HappyDog-parent, you will see that the other two projects are defined as modules.


This is also reflected in the directory structure :


This is classic Maven inheritance in action. The two sub projects have the parent project defined in the tag. All Maven plugins and dependencies defined in the super project can also be accessed in the sub projects. Also, the parent POM file has the two sub projects listed as modules. Thus the association between parent and children is two way.

Clean and build the parent maven project HappyDog-parent (Right click HappyDog-parent and select ‘Clean and Build’). This action will also do the same to the sub modules.
You will often get an error when you first do this. This is because the RCP Archetype includes a Junit test that fails.


Just delete the file ‘’

Run Project

To compile, ‘clean and build’ on the parent HappyDog-parent.

To run, right click on HappyDog-app and select ‘Run’

If everything is set up right, then you should see this :


This is the basic frame for your application. All that is missing is modules you need to create, which we will look at in another tutorial.

Splash Screen

We want out own splash screen instead of the default blue Netbeans spash screen that always pops up. To do this, we need an image, and we need to save it somewhere in the src/main/resources folder in the branding project :


Now If you right click the branding project you should see a ‘Branding’ option listed in the context menu. Select this menu item.

A number of branding related features are presented. Select ‘Splash Screen’. In this tab you can browse to the image you want for the splash screen, as well as customize other graphical features.



In upcoming tutorials we will be looking at creating additional modules for your application.

Thanks to Luann Snawder Photography for the dog image



Posted in Netbeans RCP | Tagged , | Leave a comment

ExtJS Filter Across All Grid Cells

ExtJS offers the ability to filter rows based on a column. By setting filters features in grid like so :

and defining filters on your columns like so :

You can get some pretty cool filtering functionality in your grids by clicking on the column drop down

However what if you wanted to filter grid rows globally (Ie. not restricted on a column) ?

The best way would be to add a textfield to your toolbar, or somewhere above your grid, and then have some method that filters across all rows based on the text you input.

The following code filters rows based on a text string.

Notes :

  1. To get all visible columns the codes uses the Ext.ComponentQuery functionality. This allows us to query components in the grid. Don’t ask me how it works, but the following returns just the columns that are visible : grid.query(‘gridcolumn:not([hidden])’);
  2. we need to iterate over each row, and then each cell so we have two loops here
  3. this function gets a column for a given field ID. We need this column later.
  4. A field may not be associated with a column. In extJS your store’s table of data may include additional columns that are not visible in the extjs grid.
  5. Now we check if the column has a renderer. With our filter function we can only filter on string values. Because column types may vary, the only way we can filter across strings is to get the rendered value. So we get the render function and pass our rec data value through it to get the string value.
  6. comparison
  7. set filterMeOut flag
  8. call the filterBy method on the store, passing in a custom function which does the comparison on our filterMeOut flag.

You can then call the method through a text field like this.

Posted in extjs | Tagged , | Leave a comment

Using JSDoc

Enhancing Javascript with JSDoc and JSDoc-checking IDEs

JSDoc is a way of documentating Javascript much like JavaDoc and Java annotations for Java. JSDoc does pretty much the same thing. It documents and annotates Javascript elements. However given that Javascript has much looser language rules than Java, these annotations can be leveraged to tighten parts of the code that may appear ambiguous particularly in a large project.

Probably the most useful features of JSDoc is the ability to sprinkle annotations amongst Javascript code which can then give semantic meaning to a function or variable. Using an advanced Javascript IDE, these annotations can be interpreted at compile time, and provide a kind of compile time checking, while also aiding in code-completion.

As of writing, the only IDE that can interpret JSDoc to any reasonable level is Webstorm. So all examples in this article are using the Webstorm IDE.

Simple Type Checking

Parameters types can be defined in the comments of the function. In this example we are annotating the x value being passed into the popup() method :


Now we are passing in a number :


Notice the squiggly line underneath the number 12345?

If we hover our mouse over the squiggly line, we should see a tooltip telling us what the problem is :







That’s pretty neat! Type checking at last! 

The @param JSDoc annotation allows us to say what we want passed into a function. We can also use this annotation on other primitive types such as number and boolean. Let’s have a look at how we can use the @param annotation on some more interesting objects.


Arrays and the Type Annotation

Javascript also has arrays and objects which can be considered types.

In the following example we are passing an array into a function :


In the above we create two types of fruit, and make an array for each of them. By using angular brackets, we can define the type of the array being passed in (Array.<Apple> )

Using the @type annotation we can annotate a variable. In our array example we are stating that we want out element to be of type Banana. As the second array being passed in is of type Apple, our JSDoc annotation is being infringed and we get the squiggly gray line again.

At the time of writing Webstorm does not support the JSDoc checking of the inner type of an array when being passed to a function (See the comments).

Parameter annotations on arrays can also help in code completion.


The JS compiler knows the element in an array is of type apple and shows the apple elements in the drop down list. This is unbelievably helpful!

Object Literals

Javascript objects can be very arbitrary objects. There is no real sense of type .

In the following example we are using the @param tag annotation again. Here we are annotating an object literal with two fields: name, and email which are both strings :








In the method body, a variable is assigned to the This variable has to be of type string, and matches up with the name type being passed into the method.

The following two examples show where the IDE complains and the squiggly gray lines start appearing again :








The @param annotation expects a number but we are passing in an array. Our @type annotation declares a variable to be string, but out @param says our user object can only be number.

In this case we are trying to treat one of the string fields as a number :









We can even document an array of literals.











In the following example the IDE will complain about the variable i being assigned to a string :












Again, code completion is enhanced. The IDE deals with the fields in an object literal :





Return Types

Returns can be annotated too.

In this example the IDE indicates there is a problem on the line where x is assigned the return value.








In this example the assignment is correct, however there is now a problem with the return statement. The IDE picks up on what is happening inside the function is incorrect.







Finally this example has everything working correctly :


Mixed Type

Because Javascript is duck typed, methods can accepted objects of various types. Sometimes you want to document a function and tell it that it can only accept objects of these ‘types’.












The IDE will complain at exactly this line : processFruit(new Orange())

Wrapping up..

I hope this introduction to JSDoc was useful. I don’t believe in strictly enforcing JSDoc across a whole project, but I do feel that JSDoc with a JSDoc-checking IDE becomes necessary as the project grows bigger. It allows one to treat javascript functions as black boxes, and prevents lots of picking around inside a function to try and understand what is going wrong.

This is particularly useful when you have Javascript project modules, ie. Common projects that are used across other javascript projects. A typical real world implementation I have come across is a table component that is used across many projects. It has a setModel(..) method, where the table model is passed into the component (Just like in Swing J ). Using a JSDoc-checking IDE, the developer would be notified that this object being passed in requires an array of columns, an array of entities, and a method getValueAt among other things.

Posted in JavaScript | Tagged , , , | Leave a comment

Bar Chart in Java Swing

Update !

This bar chart compoment has now been moved into the Iceberg Charts project . Please use Iceberg Charts for a more complete charting experience.

I’ve created a little Java component which creates bar graphs. It only displays bars along the Y axis, however the component is very versatile and configurable. You can change its size, fonts, ticks on the Y-axis, and bar width.

Here are some examples of using it :





The code is below. It’s basically three classes: BarChart, Bar and Axis.
A few things to note :

  • It is highly customizable. All the package level fields in BarChart can modified.
  • The Y-Axis can have up to 3 categories of ticks. In the Axis constructor, you just need to set the second and third to zero if you don’t want to used them (See my examples).
  • It is geometrically relative, however you can have problems with it. The key things to know are width and height, and leftOffset, rightOffset, topOffset and bottomOffset. The offsets need to be big enough to accomodate a title with a very large font (again see my examples).

Please let me know if this component has been useful to you. I spent a lot of time creating it, so a little feedback would be very important to me 

Posted in Swing, Uncategorized | Tagged , , | Leave a comment

Maven Tutorial

..FOR dummys, duffers and the perpetually confused.

Maven is a system for building software; a build automation tool that helps you ship out your software. If you have the vaguest understanding of Maven, you will also know that there is this thing called a POM file (pom.xml) which looks something like this :

Maven attempts to treat projects in an object oriented fashion, and one of the central tenants in Maven is that a project is an object. This project only needs to be described once, in one XML file called the POM file.

The project has a primary key, and this is defined by its coordinates: groupId, artifactId, and version. Effectively its package root, a name, and a version number.

That is basically the only prerequisite. Then you can just build your project, through your IDE most typically, or by using the Maven command line:

mvn clean install

which executes the clean lifecycle, and all phases up to the install phase in the default lifecycle. This is most commonly considered “building” a project.

A look at dependencies

The easiest thing to understand about Maven is also the most beautiful thing about Maven. Rather than managing a number of libraries across a number of projects, everything is tied to this thing called a maven reactor, a type of super library that contains all your libraries that you are using. You can see it in an .m2 directory under your user profile usually (It doesn’t really have a sexy name because it is best to be hidden. ‘Out of sight out of mind’ as they say).


The above example is from when I was working on my multi level pie chart project. It’s not too hard to see what was going on here. My pom.xml file looked like

As I was working on it I incremented the version number to 1.1, and after I did a build on the project, a new folder appeared called 1.1 with the file multi_level_pie_chart.jar in it.

The older versions are not deleted. There still hang around in the reactor. Who knows what other projects use these old versions?

Maven also allows you to point to the projects you need. As your own project is shipped to your .m2 directory, your own project is free to use whatever is in the .m2 directory. You just place in your dependency tags like so :

Maven will look for it in your .m2 directory. If it is not there then it will try and find the dependency on the web, and if it exists, download it to your .m2 directory. So in fact your dependency doesn’t have to exist in the .m2 directory. As long as you have an internet connection, it can exist as any Maven project in the internet.

As you work on multiple projects the maven reactor collates libraries that are needed as dependencies. On one project you may need JUnit1.4, but on another project you can only use JUnit1.3. The maven reactor neatly orders them based on version number.


If you hate configuration, Maven is for you.

Your project is its own source definition. There is no longer the hassle of faffing about with JAR files to make your project work, you no longer need to monkey around with pages and pages of configuration documents.

It’s all about the POM file. That’s what’s so cool about Maven!!

The configuration battles trying to get projects running across different IDEs, are no longer fought in the setups of IDEs. The battle front has been reduced to tinkering with the POM XML file.

Maven also allows for transitive dependencies. This dependency would only exists in the test phase:

A further five scopes are available, which describe a number of scenarios, such as having a dependency only at runtime, or that the dependency is provided by the application container.

A look at LifeCycles and Phases.

A lifecycle can contain many phases, and a phase contains many goals


Maven has 3 built in lifecycles.

Lifecycles contain a number of goals, grouped in phases. Maven has these lifecycles pre-configured for you to use, rather than offer an ad-hoc environment for you to chain them together as you please.

The clean :

Clean is what you would expect it to be. It blows away the target directory and that is about it. The reason that clean is not included in the default lifecycle is because a ‘clean’ is a time expensive activity. Once the target folder has been cleaned out, everything needs to be generated again (all the class files etc.). If clean were to be part of the default life cycle things would be slow because it would not be possible to build iterative changes. That is why the clean has been separated out of the default lifecycle.

The default :

The default life cycle is the main lifecycle that is used when building a project. I have enlargened the phases that you will encounter more often, and which are more important to understand.


Three of these phases should be familiar to most developers:

Compile – the software is compiled. Nothing too complicated here. Java code is converted to binary classes and put in the binary directory.

Test – All the unit tests are run. That’s all your JUnit tests that are sitting in your Test folder!

Package – after everything checks out as OK, the software needs to be bundled up ready for consumption. Ear file for JEE project, War file for Web project etc.

A couple of other commonly used phases

Validate – This checks all the directory structure is correction, that the conventions have been followed. Maven can’t work if people don’t follow the rules. The directory structure should look like this.


Install – (and his cousin deploy). These two are very similar. Install puts your packaged file, be it JAR, war, ear in the maven reactor (your .m2 directory). We have discussed this before. Doing an ‘install’ is usually considered doing a ‘build’

Deploy – takes this one step further, and moves your finished product to an internet location where it can be accessed from anywhere in the world.

[One word of warning, do not confuse the install and deploy phases with the actual deploying of your application. For example, these phases have nothing to do with the actual deploying of your web application to your server.]

Site :

Generates Documentation. We won’t cover this.

A look at Goals :

Goals describe actions. They are the atomic parts of Maven and are analogous to tasks in ANT. How they are accessed and manipulated is one of the hardest things to understand about Maven.

If you are familiar with ANT, ANT has tasks that are organized in a dependency tree. When one task executes, all the lower branches of the tree need to execute first. Well Maven is kind of similar, except that the tasks (the goals) are organized in a linear fashion.

So under the hood, Maven actually looks something like this :


It really is just a series of goals with no branching. Where ANT is tree-like, Maven is linear.

Plugins are a way that you can mess with this chain of goals, by attaching custom goals in certain phases.

A plugin, for example the wsimport plugin

If you visit the website you will see that it binds to the “generate-sources” phase. If you run a clean install, then the goal of this plugin, wsimport, will execute along with along the other goals in the generate-source phase.

Goals in plugins can also be executed independently:

mvn [plugin]:[goal]

In the above wsimport example, you would execute :

mvn jaxws:wsimport

While it is not advisable to change the phase in which a plugin executes, the phase can be overridden by modifying the execution XML like so :

So in summary, it is hard to understand what goals exist in Maven, and it is also hard to control where a goal executes in Maven. It is all under the hood stuff that only the plugins really know about. There really is little information about what goals exist in the default lifecycle.



A look at Project inheritance and project aggregation

All POMs inherit from the super pom. The super POM contains a lot of default configuration values. (eg. build.sourceDirectory = src/main/java) as well as other folder structures/properties that belong in the maven convention. You can look at the ‘effective pom’ which shows the merging of the pom files.


It is also possible to make your projects inherit from other projects that you have created. Common configuration can be refactored out into the parent making maintenance much easier.


Projects can also reference sub projects. This is called project aggregation.
This example shows how you might aggregate a number of child projects (called modules) in the parent project. When the parent project is built, all the modules will be built.

This example is a common pattern in JEE. It is a web application which is a packaging of a WAR and an EJB (as JAR) file, into an EAR file.

Note: you still need to define dependencies between projects, if order is important. For example, in the above, the WAR and JAR modules need to build before the EAR. In the EAR project I would expect to see something like this in the POM-file:

Anyway, I hope this tutorial was useful to some. It hasn’t covered everything, but I have tried to present the core concepts that people need to understand.

Posted in Uncategorized | Tagged , , | Leave a comment

Multi Level Pie Chart in Java


Update !

This pie chart compoment has now been moved into the Iceberg Charts project . Please use Iceberg Charts for a more complete charting experience.

Pie charts are pretty boring. I hadn’t found anything out there which resembled a multi level pie chart. A multi level pie chart, is basically a pie chart with a number of levels. Each level is in effect an expansion of the slice below it. A multi level pie chart basically represents a tree structure, where each node has a magnitude.

The component I have written requires a tree structure of Segment objects. A typical real world scenario where you would use a multi level pie chart would be to view the disk usage on a computer. A simplistic example I created is shown below.


The code I needed to generate the above chart is just this :

In order for it to not look like a multi colored mess, I have applied a gradient-like effect, by darkening the colors sequentially after the initial color is set for a segment. My darken method is simply :

I think this is quite effective, but there may be other ways or algorithms to implement a set of related colors. You could experiment with incrementally adjusting the hue, saturation or a rgb value.

A bit about the design of this component :

For a simple pie chart there are really only three things to consider for a pie slice. They are

  1. the starting angle (calculated from what slices have previously been drawn),
  2. the magnitude (if it is a percent it needs to be converted to an angle)
  3. and of course the color.


This is simple enough to implement. However for a multi level pie slice there are many other things to consider :

  • Relative start angle.The start angle needs to be converted, because this pie slice may not be the first level, and therefore a scaling would need to be applied.
  • Parent. The slice will have a parent, if it is not on the first level.
  • Relative magnitude. The angle, or percent, needs to be scaled based on what its parent is. If the parent represents 50% and the parents parent is on the first level and represents 50%, then the scalings would have to be combined to 25%. This 25% would then have to be applied to the original magnitude.



Also to consider would be

  • Circle1 – a circle that represents the outer rim of the slice.
  • Circle2 – a circle that would need to be subtracted from the arch created from circle1.

These circles would need to be calculated depending on a number of factors. The extend and starting point would of course need to be taken into account, and the number of circles needed would also depend on the total depth of the tree structure.

Given all these things to consider, the segment is a special type of object. Omitting the getters and setters for clarity, here is the class I came up with for a segment. A lot of the values need to be calculated.

(jar file is here)

If you would like to use this component in a project, or would like to look at the source code, please contact me 

Posted in Swing | Tagged , , , | Leave a comment