New build is posted and online docs updated.

Java Support

The previous build 1.0.69 was compiled to target Java 1.5+, but in this build we are targeting 1.7+ or higher. So you will need to run with at least Java 1.7 now (we recommend Java 1.8). Hopefully this should not be a problem since 1.6 is over a decade old now. We'll probably upgrade to require 1.8+ sometime in 2018.

Also note that Java FFI is not going to work with 1.9 because they reworked jars and classpath for project Jigsaw. That will be a significant development effort to fix. In the meantime you will need to use JDK 1.8 when compiling Fantom code which uses Java FFI.

UI Toolkit Strategy

We have spend most of the last two years on development of a new suite of APIs for UI development:

• graphics: replaces gfx for low level graphical APIs
• dom: continue to enhance DOM APIs
• domkit: UI toolkit to render via DOM

This strategy is unapologetically browser-technology focused (DOM, CSS, JS, SVG, etc). The original FWT strategy for a single toolkit that targets desktop using both SWT and DOM doesn't really make sense anymore. At this point we will not be doing anymore development on gfx and fwt. Probably eventually we will move those pods and SWT support out of the core distribution/repo.

Dom and Domkit

Improvements most everywhere; see changelog for details

Notable changes:

• Measurement classes (Pos, Size) are now Float based and use types from graphics pod
• Formalize Elem attr vs prop
  • get/set now always routes to attr
  • trap always routes to prop
  • new invoke() method for FFI
• Redesigned domkit::Tree API for simpler use
• New domkit::FilePicker and dom::DomFile API
• Lots of work to make domkit themeable
• The dom::EventTypes was removed in favor of using string literals; the docs are still available in dom::Event

Notable new features:

• New manual docDomkit
• Added Java peers for core dom types (Elem,Style,Event) for use server-side
• Domkit is now themeable using pure css overrides; see docDomkit for details

Graphics

We are introducing a new pod named graphics in this build. Graphics is a replacement for gfx. It has a couple design goals different than gfx:

• Measurements are Float based for vector based graphics
• Its designed to be easily used outside of a browser/SWT environment to generate SVG, PDFs, etc
• It uses a predefined set of font metrics to achieve previous goal (we call these the normalized fonts)
• APIs are designed to adhere strongly to DOM, CSS, and SVG conventions

Change Log

Build 1.0.70 (8 Nov 2017)

• Require Java 1.7
• js: Node.js-based NodeRunner now default js runtime for fant -js
• graphics: new graphics API
• New util::Macro API
• dom: remove dom::Size; convert to float-based graphics::Size
• dom: remove dom::Pos; convert to float-based graphics::Point; Move Pos.rel -> Elem.relPos
• dom: formalize Elem attr vs prop; get/set routes to attr; trap to prop
• dom: remove Elem.draggable (use elem->draggable)
• dom: Win.confirm
• dom: Win.scrollPos, scrollTo, scrollBy
• dom: Doc.activeElem, Doc.head
• dom: Doc.elem -> elemById
• dom: Doc.exec
• dom: Elem.attrs,attr/setAttr, Elem.prop/setProp
• dom: Elem.clone, Elem.hasChildren, Elem.ns
• dom: Elem.fromNative
• dom: Event.get,set,trap
• dom: HttpReq.withCredentials
• dom: DomFile support
• dom: Style.addPseudoClass
• dom: Doc/Elem support for creating namespaced elements
• dom: add Java peers for Elem,Style,Event
• domkit: DragTarget.onEnd, DropTarget.onOver
• domkit: add GridBox.removeRow, removeAllRows
• domkit: change GridBox cell key "all" -> "*"
• domkit: add Link.target
• domkit: fix SashPane.sizes setter to update style
• domkit: add WellBox
• domkit: add ButtonGroup.enabled, inheritEnabled, onBeforeSelect
• domkit: add Table.onHeaderPopup
• domkit: add Checkbox.indeterminate
• domkit: add TreeNode.parent,isExpanded methods
• domkit: make TreeNode abstract; remove Obj field/ctor arg
• domkit: add TreeNode.onTreeEvent support
• New docDomkit manual
• Add options to Zip deflate in/out methods
• Fandoc support for explicit img size
• Float.isNegZero, normNegZero
• compiler: fix to check invalid coercion with shortcut assignments
• fandoc: add support for horizontal rules
• Make sys::TestErr public
• concurrent: add Future waitFor and waitForAll
• 1386: js: dynamic invocation of a slot inherited from a mixin
• 1421: js: equality operators compile like assignments
• 1986: Fanr pod cache out of sync with the FileRepo
• 1988: Nullability problems with facet
• 2090: JS: Abstract class creation
• 2357: URI Encoding / Decoding
• 2388: fandoc: Wrapping an image in a link
• 2457: super.trap() in Javascript
• 2483: Method.func.typeof is not parameterized
• 2499: Compiler check for shortcut with Int to Float implicit cast
• 2511: Check null safe chaining with shortcuts
• 2519: Date/Time toLocale support for single quote literal
• 2540: Edge cases and java.lang.VerifyError
• 2551: New line char after Markdown links
• 2577: js: missing Uri.hash implementation
• 2592: VerifyError for value based null check in it-block ctor
• 2620: Err.trace dump to stderr
• 2629: Javascript: List.unique() throws NotImmutableErr

Congratulations on the new release! And well done Andy on the dom / domkit revamp - it looks great!

Thank you for sharing your work!

For the macOS-ers -- homebrew is now updated to 1.0.70

And the Windows Installer has also been updated to 1.0.70!

-=> Fantom Windows Installer 1.0.70 <=-

Can I upgrade it by fanr? I don't want to configure it again.

The core pods are available on the Fantom fanr server:

> fanr query -r http://fantom.org/fanr/ "* 1.0.70"

You'll also need the new %FAN_HOME%/lib/java/sys.jar to complement sys.pod.

The config files in %FAN_HOME%/etc/ are largely the same, but you can see this commit (in Fantom Windows Installer) to see what actually did change.

Ok, thank you

About the new UI Toolkit...

This strategy is unapologetically browser-technology focused (DOM, CSS, JS, SVG, etc). The original FWT strategy for a single toolkit that targets desktop using both SWT and DOM doesn't really make sense anymore. At this point we will not be doing anymore development on gfx and fwt. Probably eventually we will move those pods and SWT support out of the core distribution/repo.

...does this mean that Fantom won't be suitable for developing desktop applications anymore? That would be a shame because creating desktop apps with FWT was a breeze.

does this mean that Fantom won't be suitable for developing desktop applications anymore

We aren't going to get rid of the FWT - its all solid working code. Maybe at some point we might stop including the SWT jars though in the distro zip. But it will also be interesting to see how desktop apps develop via web technology (such as Electron)