KTurtle moving forward...
cies
yesterday i have commited a truck load of changes. not really nice to
do it this way (i rather commit small, atomic commits) but because of
a lack of internet access, the freeze and lack of understanding of
svn, it turned out to be like this. here a copy of the tada list:
* add no-highlighting run mode (speed things up drastically)
* F2 context help works now (still have to update the handbook pages)
* antialiassing for export to PNG, like on Canvas itseelf
* export to SVG added.. turtle not exported into the picture (have to
wait for later Qt, or very ugly, or someones clever workaround)
* row/col statusbar bug fixed
* when looking at errors tab and running again switch back to canvas
automatically
* added html export for code
* shuffled the menu items around a bit. new: Canvas and Run menus;
moved View action sinto Settings
* added printing of the canvas
* replaced commandline execution mode with DBUS interface
* added RSpec some initial unittests (in Ruby) that make use of the
DBUS interface
* made a syntax highlighting nicer (more style categories)
probably there is more (small) things, yet this is a proper overview
of the bigger changes.
the TODO file in the kturtle's project root on svn:
https://svn.kde.org/home/kde/trunk/KDE/kdeedu/kturtle/TODO
http://websvn.kde.org/trunk/KDE/kdeedu/kturtle/TODO
is the place where is keep lists of outstanding issues and plans for
kturtle's future.
ofcourse there are also bugs as filed on bugs.kde.org.
the context help (F2) working is a major step forward. yet i am most
excited about the unittest suite. the unittests are run using a rake
and rspec from the ruby front. they provide a nice framework. the
unittests connect to a dbus-only instance of kturtle (kturtle --dbus),
in this mode kturtle only acts on dbus calls. currently only the
interpreter is exposed to dbus, so the test are limited to that
aspect, yet in the future we might also expose the canvas to dbus for
more test coverage.
the aim is to give kturtle a full language specification (like java
and ruby have). this specification, written in a tests, covers all the
features of the turtlescript language, so makes sure kturtle behaves
properly. currently many tests have yet to be written, and there are
also some tests failing (which mean that kturtle behaves badly, or the
specification is lacking).
to run the tests you need to have ruby, rubygems, and the rspec and
rbus gems installed. the test script currently expects your kturtle
binary to be at: ./src/kturtle
then there is the documentation. i revised the programming
terminology. i regreted making up some terminology trying to simplify
(followin some logo interpretation), but looking back i dont think it
got much simpler. so right now i use more standard programming
terminology. i hope to commit my doc changes tomorrow (_after_ i do
the spellcheck)...
one outstanding issue on programming terminology the word "command".
we could continue to use "command", yet "instruction" or "statement",
or even "function" are also possible contenders.. please share your
ideas on this one.
long mail, thanks for reading.. looking forward to hear form you on this list.
ciao!
_cies.
cies
there.