ANN: Clarity 0.5.1 - New GUI library

[Stathis Sideris]

Hello everyone,

I would like to announce the first release of Clarity (v0.5.1), a
Swing-based GUI library. It's available on github and through clojars:

https://github.com/stathissideris/clarity

[clarity "0.5.1"]

Also, here's an introductory talk (will only play as embedded
unfortunately):

http://skillsmatter.com/podcast/scala/lightening-talk-clarity-a-wrapper-for-swing

Finally, a couple of tutorial-style pages from the wiki:

https://github.com/stathissideris/clarity/wiki/Component

https://github.com/stathissideris/clarity/wiki/Forms

This is a new library and I coule really use some feedback on the
syntax, the features, and maybe even the code.

Thanks,

Stathis

[Doug South]

Hi Stathis,

Nice presentation and the library looks interesting. One question,
when do you think it will be ported to 1.3?

Regards,
Doug

> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com
> Note that posts from new members are moderated - please be patient with your first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

[Stathis Sideris]

Well, there isn't much preventing it from being 1.3. It used to be
blocked by the dependency to clojure.contrib.miglayout, but then
Stephen Gilardi released artem (https://github.com/scgilardi/artem)
which provided a way out. I think it's probably a matter of days
before I get a version that's compatible with Clojure 1.3, although
I'm investigating how it would be possible to have 1.2 and 1.3
compatibility from one codebase.

Thanks,

Stathis

On Dec 2, 7:21 pm, Doug South <doug.so...@gmail.com> wrote:
> Hi Stathis,
>
> Nice presentation and the library looks interesting. One question,
> when do you think it will be ported to 1.3?
>
> Regards,
> Doug
>
>
>
>
>
>
>
> On Fri, Dec 2, 2011 at 12:55 PM, Stathis Sideris <side...@gmail.com> wrote:
> > Hello everyone,
>
> > I would like to announce the first release of Clarity (v0.5.1), a
> > Swing-based GUI library. It's available on github and through clojars:
>
> >  https://github.com/stathissideris/clarity
>
> >   [clarity "0.5.1"]
>
> > Also, here's an introductory talk (will only play as embedded
> > unfortunately):
>

> >  http://skillsmatter.com/podcast/scala/lightening-talk-clarity-a-wrapp...

[Gary Trakhman]

Have you looked at seesaw?  What differences are there in the design and intent?

[Stathis Sideris]

Hello Gary,

Hello Gary,

To be honest I didn't look at seesaw much while developing Clarity, so
I didn't make any conscious decision to differentiate with seesaw.
It's very interesting to see that both me and Dave Ray came up with
similar solutions/features.

It seems that Seesaw is more concise in comparison to Clarity, and
from the project page it does look like a more mature project. On the
other hand, it seems to me (and I might be wrong) that Clarity has a
more complete solution when it comes to selectors because it supports
"categories" on top of the IDs, and the syntax caters for arbitrary
logic operations and custom selectors.

It seems that Seesaw uses binding for keeping GUI values and atoms/
refs in sync, and Clarity instead provides easy ways to retrieve all
the values of all components in a panel as a map (see the HasValue
interface). I like Clarity's approach better because it's more de-
coupled.

The other thing that I think differentiates Clarity is the live
preview of layouts using clarity.dev/watch-component.

Finally, let me repeat that all of the above are based on a
superficial reading of Seesaw's docs, I may as well be wrong!

Thanks,

Stathis

[Dave Ray]

Howdy,

I'll clarify some of Stathis' remarks about Seesaw below. Obviously,
I'm a little biased, but Clarity looks cool and I plan on "borrowing"
some of its features for Seesaw in the next release or two :) I think
it's great to have multiple projects like this to inspire each other
and keep everyone honest. Keep up the nice work!

Cheers,

Dave

more inline below ...

On Sat, Dec 3, 2011 at 8:15 PM, Stathis Sideris <sid...@gmail.com> wrote:
> Hello Gary,
>
> Hello Gary,
>
> To be honest I didn't look at seesaw much while developing Clarity, so
> I didn't make any conscious decision to differentiate with seesaw.
> It's very interesting to see that both me and Dave Ray came up with
> similar solutions/features.
>
> It seems that Seesaw is more concise in comparison to Clarity, and
> from the project page it does look like a more mature project. On the
> other hand, it seems to me (and I might be wrong) that Clarity has a
> more complete solution when it comes to selectors because it supports
> "categories" on top of the IDs, and the syntax caters for arbitrary
> logic operations and custom selectors.

Seesaw selectors are basically Enlive selectors [1] ported to Swing.
So it supports all the usually CSS hierarchical stuff, ids and classes
(Clarity's categories). It can also select on Java class/sub-class
relationships. I left it at that since selector+filter seemed a
reasonable enough way to add custom predicates or whatever if
necessary.

[1] http://enlive.cgrand.net/syntax.html

> It seems that Seesaw uses binding for keeping GUI values and atoms/
> refs in sync, and Clarity instead provides easy ways to retrieve all
> the values of all components in a panel as a map (see the HasValue
> interface). I like Clarity's approach better because it's more de-
> coupled.

Yep. I like Clarity's (value) function as well, especially for forms
in dialogs. I'll be borrowing that. If you need to update one or more
aspects of the UI based on changes in a reference type or some aspect
of a widget, bindings (in the Seesaw sense) work nicely because they
provide that automatic propagation and fine granularity.

> The other thing that I think differentiates Clarity is the live
> preview of layouts using clarity.dev/watch-component.

I think that's very cool too. I approximate that workflow using
lazytest's watcher to re-run my code when it changes.

> Finally, let me repeat that all of the above are based on a
> superficial reading of Seesaw's docs, I may as well be wrong!
>
> Thanks,
>
> Stathis
>
>
> On Dec 3, 2:52 pm, Gary Trakhman <gary.trakh...@gmail.com> wrote:
>> Have you looked at seesaw?  What differences are there in the design and
>> intent?
>

[Stathis Sideris]

Hello Dave,

> I'll clarify some of Stathis' remarks about Seesaw below. Obviously,
> I'm a little biased, but Clarity looks cool and I plan on "borrowing"
> some of its features for Seesaw in the next release or two :)  I think
> it's great to have multiple projects like this to inspire each other
> and keep everyone honest. Keep up the nice work!

Thanks for your kind words, if you're borrowing I must be doing
something right! I too think that it's really cool to have multiple
projects, and it may help us learn from each other! We do have similar
problems after all.

> Seesaw selectors are basically Enlive selectors [1] ported to Swing.
> So it supports all the usually CSS hierarchical stuff, ids and classes
> (Clarity's categories). It can also select on Java class/sub-class
> relationships. I left it at that since selector+filter seemed a
> reasonable enough way to add custom predicates or whatever if
> necessary.
>
> [1]http://enlive.cgrand.net/syntax.html

OK that looks pretty powerful too, I retract my comments about being
able to do more with Clarity's selectors. :-)

> > The other thing that I think differentiates Clarity is the live
> > preview of layouts using clarity.dev/watch-component.
>
> I think that's very cool too. I approximate that workflow using
> lazytest's watcher to re-run my code when it changes.

I think that's a much better way. Currently, when watching a
component, Clarity bashes the JVM by creating the component every X
seconds (I did say it was an experimental feature!). I'll look into
lazytest's code to see how it detects the code changes. I suppose it
watches for changes in the class files, right?

Stathis

[Dave Ray]

Stathis,

I use the Lazytest watcher partly out of convenience. I happen to use
Lazytest for testing so it's usually already running anyway. However,
some work has already been done to extract the watch functionality
[1]. It might be fun to combine your viewer with it. Maybe have a
naming convention for the watch entry point of an app or component so
you can use it without editing the file.

[1] https://groups.google.com/group/clojure-dev/browse_thread/thread/32ab1a5e7f819196/dde7a347e7f56b0a

Cheers,

Dave