The latest build is posted and the online docs are updated.
Flux
This build contains the first prototype of Flux which is a finder/browser/editor all written in Fan. See Flux Prototype for an overview and a screen shot. There are also two new chapters on Flux in the docs:
docTools: using flux as a development tool, setting up your options, how to write tool scripts
docLibs working with the Flux APIs to write your own views, sidebars, and plugins
FWT
There has been a huge amount of work on the FWT to support the Flux development. FWT is moving out of its development phase into its "alpha release". We'll be adding features here and there and polishing things up as we continue work on Flux. But overall, it is pretty much feature complete for what most applications need. The APIs should be fairly stable moving forward. Note there are a couple APIs we still have plans to modify - but they are clearly spelled out in the Fandoc (some of the Dialog methods, BorderPane, and GridPane).
Command now makes it really easy to use localization
New Display and Monitor APIs for accessing the desktop configuration
Eventing is now supported across the entire widget toolkit
Dialog class with standard option dialogs (still need file/dir open dialogs)
Finish Graphics: clip, translate, push, pop
Font now supports metrics
Text and RichText refactored with TextWidget superclass
Clipboard support in text widgets
Tons of little convenience methods to make building professional UIs easier
Naming
I've implemented a large new chunk of functionality in the naming subsystem as proposed in a previous discussion. Summary of changes:
Uri.get is used to resolve any resource
You can use the @uriScheme facet to plug in custom Uri handlers
The "fan:" scheme can now be used to resolve all sorts of useful things in the VM
One of the really nice things you can do now is pass around a Uri to a file bundled inside your pod. For example:
fan:/sys/pod/icons/x48/flux.png
That is a Uri which will resolve a sys::File and can be used anywhere a file Uri is expected. So you can uniformly treat files as just files (simple stuff like that is a huge pain in the ass in Java and in .NET).
A new chapter in docLang covers all these new features.
Editor Support
The adm/tools directory contains files which I've received for configuration files for working with Fan. So far we've got:
textpad
jedit
vim
If you have config files for other editors please send them my way.
Misc
There are lots of new methods to some of the sys classes, especially with regard to naming and localization. This build also contains oodles of fixes for bugs submitted over the last month.
Change Log
Build 1.0.32 (20 Sep 08)
Remove support for old type literal syntax
Add adm/tools with fan support for various editors
Remove haven pod
Fix thread queue notify bug
Fix infinite loop in compiler bug
Fix race condition loading $Pod class
Fix win32 launchers to not require .NET
Fix compiler handling of unparameterized generic types like List
Fix adm/unixsetup script (mostly)
Breaking change to Uri.get (inserted base parameter before checked)
Breaking change Locale.prop -> get
Process API enhanced: join, out, err, in, mergeErr, and env
Int.equalsIgnoreCase
Str.indexIgnoreCase, indexrIgnoreCase
List.eachBreak, flatten
Map.eachBreak
Uri.sliceToPathAbs, isPathOnly
Pod.uri, loc
Type.loc
File.normalize now includes file: scheme
Require Namespace uris to be path only
New UriScheme naming design
New docLang chapters: Naming, Conventions
New docTool chapters: Flux
New docLib chapters: Flux
Refactor native methods in fwt
fwt::Command localization
fwt::Font metrics
New fwt::Dialog API
New fwt::Desktop and Monitor APIs
New fwt::TextWidget base class for Text and RichText
New fwt text selection and clipboard APIs
Flux prototype!
katoxSun 21 Sep 2008
Great news, Brian!
A lot changed under the cover since the last build. Flux looks cool -- indeed quite basic but seems to be stable. I like the URL concept, good job.
Note: the BuildGroup seems to have problems: When I bootstrap fan 1.0.32, the ./buildpods script breaks the fwt installation. For instance running flux gives this error:
I played with it a bit more and I found out that the build outputs differ depending on the method I use. When I directly run ./fwt/build.fan, everything is okay. If I try to build with
using build
class Build : BuildGroup
{
override Void setup()
{
childrenScripts =
[
`fwt/build.fan`
]
}
}
I get the error above. Running ./fwt/build.fan however fixes the build.
brianSun 21 Sep 2008
katox - if you build using a group script, then you need to specify an explicit "full" target (which will get passed to the sub-scripts). If you just run buildpods with no targets it will only recompile the Fan targets (not the Java targets), which is why you are missing your fwt peer classes. I typically do "buildall full test" after a checkout.
I changed the default targets for inet and fwt to be "full" - might need to rethink how that relates to groups. Run a build script with "-help" to see which target is the default (marked with an asterisk).
katoxSun 21 Sep 2008
I see, thanks. I am still not used to Fan build system. I didn't realize that I had to change the parameters for fwt. Copying rel libs didn't help for some reason (unlike full recompile) and everything else seemed to work just fine...
brian Sun 21 Sep 2008
The latest build is posted and the online docs are updated.
Flux
This build contains the first prototype of Flux which is a finder/browser/editor all written in Fan. See Flux Prototype for an overview and a screen shot. There are also two new chapters on Flux in the docs:
FWT
There has been a huge amount of work on the FWT to support the Flux development. FWT is moving out of its development phase into its "alpha release". We'll be adding features here and there and polishing things up as we continue work on Flux. But overall, it is pretty much feature complete for what most applications need. The APIs should be fairly stable moving forward. Note there are a couple APIs we still have plans to modify - but they are clearly spelled out in the Fandoc (some of the Dialog methods, BorderPane, and GridPane).
Naming
I've implemented a large new chunk of functionality in the naming subsystem as proposed in a previous discussion. Summary of changes:
@uriSchemefacet to plug in custom Uri handlersOne of the really nice things you can do now is pass around a Uri to a file bundled inside your pod. For example:
That is a Uri which will resolve a
sys::Fileand can be used anywhere a file Uri is expected. So you can uniformly treat files as just files (simple stuff like that is a huge pain in the ass in Java and in .NET).A new chapter in docLang covers all these new features.
Editor Support
The adm/tools directory contains files which I've received for configuration files for working with Fan. So far we've got:
If you have config files for other editors please send them my way.
Misc
There are lots of new methods to some of the sys classes, especially with regard to naming and localization. This build also contains oodles of fixes for bugs submitted over the last month.
Change Log
Build 1.0.32 (20 Sep 08)
katox Sun 21 Sep 2008
Great news, Brian!
A lot changed under the cover since the last build. Flux looks cool -- indeed quite basic but seems to be stable. I like the URL concept, good job.
Note: the BuildGroup seems to have problems: When I bootstrap fan 1.0.32, the ./buildpods script breaks the fwt installation. For instance running flux gives this error:
I played with it a bit more and I found out that the build outputs differ depending on the method I use. When I directly run
./fwt/build.fan, everything is okay. If I try to build withusing build class Build : BuildGroup { override Void setup() { childrenScripts = [ `fwt/build.fan` ] } }I get the error above. Running
./fwt/build.fanhowever fixes the build.brian Sun 21 Sep 2008
katox - if you build using a group script, then you need to specify an explicit "full" target (which will get passed to the sub-scripts). If you just run buildpods with no targets it will only recompile the Fan targets (not the Java targets), which is why you are missing your fwt peer classes. I typically do "buildall full test" after a checkout.
I changed the default targets for inet and fwt to be "full" - might need to rethink how that relates to groups. Run a build script with "-help" to see which target is the default (marked with an asterisk).
katox Sun 21 Sep 2008
I see, thanks. I am still not used to Fan build system. I didn't realize that I had to change the parameters for fwt. Copying rel libs didn't help for some reason (unlike full recompile) and everything else seemed to work just fine...