The Source for Java Technology Collaboration
User: Password:



Frederic Barachant's Blog

February 2008 Archives


Splines project on a good path

Posted by pepe on February 26, 2008 at 10:43 PM | Permalink | Comments (2)

Splines project is my latest contribution to oss.
It is aimed at helping people use, display and edit splines without too much hassle.

The main entity of the project is Curve, which is a list of CurseSection objects. Three types of sections can be added at the moment, but the system can accept new implementations anytime (you can already add yours).
Actually implemented CurveSection types are:


    • linear: a direct interpolation between previous section and current

      cubic: a cubic spline interpolation between previous section and current

      quadratic: a quadratic spline interpolation between previous section and current

  • Taken from the webstart Demo, here is how i created the Curve:


    Curve = new Curve( new LinearSection( 0, 0 ) ) );
    curve.addSection( new LinearSection( 1.0, 5.0 ) );
    curve.addSection( new QuadraticSection( 3.0, 4.0, 2, 4 ) );
    curve.addSection( new CubicSection( 6., 2., 4, 5, 5, 0 ) );

    Cannot be easier.

    and here is how i displayed the curve:


    this.curveViewControl.setCurve( curve )

    Once again, cannot be easier.

    Curve and its sections can be listened for modification, curve can be serialized (listeners will not) and the whole is easy to use and fits in a very small single jar.
    Sections can be replaced by others, and section objects can be modified externally. Library is totally threadsafe and a curve or its sections can be used and modified from multiple threads without collisions.

    Plans for the future are to enhance the swing component to enable pluggable editors for curves, pluggable renderers, and before all more complete refreshing after edit.



    Realtime Animations within matisse

    Posted by pepe on February 13, 2008 at 10:37 PM | Permalink | Comments (2)

    A bug corrected in latest netbeans 6.1 enables swash to display its animations realtime while you edit withing matisse. Great effect and good step ahead in productivity.

    Thanks goes to Tomas Pavek for that. Even if the bug report was a bit old, he fixed it as soon as he got his eyes on it and i admit i really waited for it.

    So, here is a little swik capture that shows how animated components are shown. Unfortunatly, swik goofed a bit and does not show animations correctly as they are perfectly smooth on my screen, but you will see them jerk. Bah, i'm so happy i do not really care.

    Fun thing is that you can edit, duplicate, add components over and under animations and matisse does not matter. Everyting just animates smoothly while you setup your UI.

    Lovely day. :)



    On the reuse side of things

    Posted by pepe on February 12, 2008 at 02:24 AM | Permalink | Comments (3)

    Swash already had part of its code split to a seperate project, one with a pretty infamous name: preciseInternalDate.

    Swash will see an other split: splines!

    While i was finishing the splines part of swash, i said to myself that this could easily be extracted to an external package that could be useful to other projects than swash. In fact, i have other projects that would benefit from it, so even within my own projects that would be fine.
    Then i thought of other parts that could be useful and could be extracted. But as i was thinking deeper on what could be externalized and reused i wondered about the burden of reuse.

    How much does it burden to be smart and fancy? When is it wrong to do it right?

    I mean, i -more than once- grumbled over the fact that i needed activation.jar to use javaMail. What if to use one API you suddenly need to add six or eight jars? Swash actually has two jars, soon three. We are all taught the wonderful advantages of object orientation like ease of reuse, but even if not pushed to an extreme, i see it as a burden. Is it acceptable? I don't know.

    Next thing i could export to an external lib is interpolation, but as i will soon support java3D canvases within my rendering pipeline, its jars will become somewhat a dependency of swash. (but no, i certainly do not intend to see everyone forced to install java3D. Not having it will simply not render that part of the graph). Only those two things add at least 4 jars (and native libs for java3d)
    Supporting inclusion of svg will also add its own pack of jars.

    Sure, JSR-277 could solve the problem and make it transparent for developers to include anything but it's not there. And until it is really everywhere and used by everyone -which imho means years- there will be a "legacy mode" to support.

    On an other hand, having no real central repository and no real way to handle dependencies makes it a harder decision to whether i should include the whole bang or handle their inexistence gracefully.
    Solution number two might turn in a coding nightmare, while solution number one will certainly add unwanted burden to swash.

    Bubonic plague or cholera?
    What could be the jar count to choose between one or the other?





    Powered by
    Movable Type 3.01D
     Feed java.net RSS Feeds