ANNOUNCE: Swank 3.0.0 alpha 2
Bruce Johnson
http://kenai.com/projects/swank/downloads
Or find out more information at the Swank website:
------------------------------------------------------------------------
- Swank - A Tk-like interface to the Java Swing Widgets
Swank is an implementation of the Tk GUI Toolkit written in Java. Swank implements a large extent of the Tk 8.4 syntax and commands, plus some additional widgets. Swank is a companion project to, and requires code from, the JTcl Project, which itself is based on Jacl. Together JTcl and Swank are analagous to Tcl and Tk.
The Swank distribution includes the latest JTcl (as of 3 Jan 2011) bundled into the Jar file. JTcl itself bundles ITcl, the TJC Tcl to Java compiler, and much of Tcllib. Also included is a Swank version of the Extended Tk Console (TkCon) and JFreeChart ( http://www.jfree.org/jfreechart/) libraries to support Swank's canvas based charts.
INSTALLING Swank
Swank requires a Java JVM 1.5 or higher (Java 1.6 is recommended). You may have to install Java if you don't already have it installed.
Swank is distributed as a ZIP archive. Download the latest swank-{version}.zip file from the Swank website, and unzip into a directory of your choice. Unix/Linux/Mac OSX shell script (`wisk') and Windows batch file (`wisk.bat') are included.
wisk (the Swank equivalent of wish) supports three startup options
-swkcon (to startup with the Swank version of TkCon)
-console (to startup with a simple console)
-demo (to startup showing a demonstration based on the Tk widget demo).
SOURCE CODE
Swank uses the Mercurial distributed source code control system. Install Mercurial using your OS distribution package manager or get executables from the Mercurial site:
http://mercurial.selenic.com/
Browse Swank source code:
http://kenai.com/projects/swank/sources.
Clone the Swank repository:
hg clone https://hg.kenai.com/hg/swank~swank-main
DOCUMENTATION
Please refer to the Swank web site.
MAILING LIST and BUG REPORTING
Please subscribe and use the Swank mailing list for questions and to share information. The Swank Bug tracker should be used to report bugs.
Mailing lists: http://kenai.com/projects/swank/lists
Bug reporting:
http://kenai.com/jira/browse/SWANK
Arndt Roger Schneider
[snip]
The source code sample for the swank canvas items
does not display the tcl code generating these items
--it's the code for the original tk canvas items.
I am most curious about these items:
The presented graphics do almost match
tkpath 0.2 functionality...
option database:
You should think about an alternative method for
the option database. Using the odb has an immediate
effect on the performace of a tcl/tk gui--using the odb
may improve your tk 8.4 gui by a factor of 2 or more.
The odb counterpart does not have to be implemented
in tcl though, java would be fine.
-class: The class attribute is not only important
for the odb, but also for event handling. class
also creates a bindgroup; if it's possible than
add class to all window classes (including button, listbox etc.).
binding onto
the <Destroy> event raises an exception:
bind xxx <Destroy> aaa;
I've tested swank under OSX/10.4 ppc: there are
serious refresh problems with it.
So far I am impressed: the generated gui is
closer to the aqua platform than tk/carbon.
Swank uses the wrong button shape and size.
good work!
-roger
Bruce Johnson
I checked out the canvas demos and indeed the source code shown doesn't match the code used to generate the demo. This is now fixed (I hope to do another release within a few days).
Yes, it would be very useful to have something like the option database. Obviously the Tk trend with the new ttk widgets is to use "styles" rather than the option database. For one thing, I'd like to give a Tcl type access to setting the Swing look and feel. Also, there has been some work on using CSS to style Swing widgets. This could be another approach. There was some chance that CSS styling was going to make it into Java 7, but it doesn't look like it will.
Not sure what you mean by the "-class" attribute. There doesn't seem to be such a configuration option for the Tk widgets. But all Swank widgets, like Tk widgets, have a class accessible through "winfo class".
I'll check out the exception with Destroy events. I don't think I've written any code to explicitly handle Destroy events, but there should be.
Sorry about troubles with OSX/10.4 ppc. I'll fire up my PPC Mac and check it out. At some point I may start requiring Java 6, though, and that unfortunately would preclude running it on these Macs.
As to button sizes on the Mac, Java on the Mac has a set of properties that can be used to set things like the button size so that one can make a more native like app. I'd like to add support for setting these properties, but haven't decided exactly what the best command style to use is (for example, should it be a widget configuration option, a widget sub-command, or a new "property" command).
Thanks again,
Bruce
Bruce Johnson
Bruce
Arndt Roger Schneider
[snipv]
> Yes, it would be very useful to have something like the option database.
The critcal point is performance. The odb in Tk prior to 8.5
had large if.. else switches for parsing the command line. So the
amount of command line options decreases the performance of a Tk gui
(performance is somewhat better in 8.5). Furthermore the odb decouples
presentation from functional aspects, and allows to support new
properties without breaking backward compability...
As for java/tcl/swing: The major issue is performance!
You could provide a java-only counterpart to the odb; it
doesn't have to follow the odb syntax. Albeit "option get"
would be nice.
> Obviously the Tk trend with the new ttk widgets is to use "styles"
> rather than the option database.
Both tk and ttk use the odb. The odb is the only way
to support both window sets within the same tcl-code.
The odb more important than ever.
> For one thing, I'd like to give a Tcl type access to setting the
> Swing look and feel.
Ttk themes are implemented in C, there is no way to keep
compatibillity.
My personal observation is: Application designers
primary wish to integrate their application within
its desktop environment: gnome, kde, windows and aqua.
tilegtk, tileqt provide these integration under X11 and
ttk itself under windows --Native Integration.
Native Integration was what Tk 8.0 promised and were Tk 8.4 failed.
Just follow the Tk 8 road for desktop integration for colors and fonts,
only:
Create symbolic colors and fonts for kde, if kde is the present
desktop and gnome colors and fonts when gnome is the current desktop.
example:
gnomeAppWindow -- color of a gnome main window.
gnomeMenubarFont -- font in a gnome menu.
Of course, the symbolic names should be follow the gnome and kde
convention.
It would be nice to have something like "tk desktop".
Shapes, pattern, gradients are of very little importance.
--Well drop BLACK_PIXEL and introduce a new property "borderColor"
for a solid relief.
> Also, there has been some work on using CSS to style Swing widgets.
> This could be another approach.
> There was some chance that CSS styling was going to make it into Java 7,
> but it doesn't look like it will.
>
CSS is clearly the best possible approach to separate presentation
and functional --on the command line-- properties. CSS shares
the declarative syntax with the odb and xrdb.
However, performance is critical.
[snip]
>
> Sorry about troubles with OSX/10.4 ppc.
> I'll fire up my PPC Mac and check it out.
> At some point I may start requiring Java 6, though,
> and that unfortunately would preclude running it on these Macs.
Well, change is inevitable. I will cross-check with intel/osx.
>
> As to button sizes on the Mac, Java on the Mac has
> a set of properties that can be used to set things
> like the button size so that one can make a more native like app.
> I'd like to add support for setting these properties,
> but haven't decided exactly what the best command
> style to use is (for example, should it be a widget configuration option,
> a widget sub-command, or a new "property" command).
The button radius is wrong; under aqua a text button features
10px rounded corners, swank's were 4px --4px are
used for menubuttons. Tk handles radius implicitly under aqua,
for images there is no radius and for text it's 10px.
I suggest you do introduce a radius property which follows tk's
implicit rule, but also to allow overwriting it.
Vector icons(font glyphs) should have the same radius as an image
button, but are technically text.
Also nice to have are left and right radius values;
-radius 10p -- 10 point left and right radius
-radius {10 0} -- 10 pixel left radius and 0 pixel right radius,
as within a group.
[snip]
I would very much like to look into swank again, once you have a
solution for the presentation properties, -class and <Destroy>.
Then I will try to port the runtime library and gestalt items
--without gstripes--
(http://gestaltitems.sourceforge.net). So please keep me informed about
your progress.
thanks
-roger