DesignGridLayout support

[abp]

Would you add this one, too?

http://java.net/projects/designgridlayout/pages/Home

[daveray]

Interesting. I'd never see that before. Do you know if it's in Maven at all? If it's not, then I probably wouldn't add direct support because managing non-maven dependencies is a pain. Besides that, wrapping this should be pretty straightforward.

[abp]

Do you know if it's in Maven at all?

Yes, seems like it's only described on the old page: http://designgridlayout.java.net/maven.html

Besides that, wrapping this should be pretty straightforward.

That's what i think to. It has a nice API for a Java library. I would try to port it on my own, but I'm just getting started with Clojure.

[daveray]

Man Java.net is such a disaster :)

Anyway, this turned out to be more interesting than I thought. DGL's approach is way different from the normal "call add() with a constraint" that most layout managers use. Everything goes through DGL's API. So, what I did was take one of their examples, convert it to clojure, and then see what I could do in terms of fitting it into Seesaw.

Here's what I came up with (in commit d05ebe70e8542db22320ad57ad98b68e68c1b2f0):

https://github.com/daveray/seesaw/blob/feature%2Fdesign-grid/src/seesaw/examples/design_grid.clj

This is all on a feature branch at the moment, btw. Switch to the feature/design-grid branch, lein deps and then lein run -m seesaw.examples.design-grid to run it.

I made very simple wrappers around the grid, row, etc. calls. In a real implementation, we'd probably need to define some protocols to cover the full API, but this gets the gist of it. Those can easily be chained together (like in Java) using the -> thread macro. To clean it up a little more, I added a build macro which takes a list of "rows" and inserts the threading and everything and returns the panel.

The end result looks kind of nice I think, but there's definitely a reasonable chunk of work to do before it's fully "wrapped". I learned a few things along the way, so it was worth my time :)

What do you think?

[abp]

Yeah, it's a pain for all the guys who've got to migrate all their projects. Not a good use of ones time.

What do you think about the approach of DGL? I like it, but haven't tried it on very complex UIs by now. At work we use JGoodies FormLayout and JFormDesigner to let someone build the UIs visually. I dislike the constraint-based layout managers(like JGoodies FormLayout) because no one can make UI changes without learning how the constraints work.

I will try the sample as soon as i can. You are right, it looks really nice and concise for a sketch. :)

I'm just thinking about how i would build components to put into the grid, because for building the kind of swing applications I'm working on, i need a lot more than a pure Swing DSL. I would need to add components into the grid via selectors, or just instantiated with a selector, so that i can configure the component before or after i added it.

I would like to explain some requirements and ask questions on a Clojure-DSL for building fully flegded Swing applications with ease. But that's a topic for another issue and another day. I also need some more time to think about it. :)

Thanks for the effort so far.

[daveray]

It seems like a nice approach, especially in Java. With something like MigLayout, you have to learn the constraint mini-language without help from the IDE. In most of the Swing work I've done, I've somehow avoided complicated forms, so I generally get by fine with just border and box layout (for example, https://code.google.com/p/jsoar/wiki/JSoarDebugger). I've also never been a fan of visual builders, at least in Java. They always seem to disappear eventually :)

Play around with it and let me know what you think.

[abp]

Hi, before i bother you with a pull request for a feature branch, please have a look at:

https://github.com/abp/seesaw/commit/9116c028024751da3069b1634f65e63fb6741d7d

I ported a new example and modified the wrapper to add empty columns and grids without label. It isn't good to rename a method of the wrapped library to avoid shadowing a core function, is it? I wrapped the empty method in add, too.

Let me know what you think and i'll apply the changes.

[daveray]

At the beach now, but I can take a look later :) It will probably be simplest if you're merged with develop before sending the pull request.

Cheers

Dave

On Sunday, June 5, 2011, abp [email protected] wrote:

Hi, before i bother you with a pull request for a feature branch, please have a look at:

https://github.com/abp/seesaw/commit/9116c028024751da3069b1634f65e63fb6741d7d

I ported a new example and modified the wrapper to add empty columns and grids without label. It isn't good to rename a method of the wrapped library to avoid shadowing a core function, is it? I wrapped the empty method in add, too.

Let me know what you think and i'll apply the changes.

Reply to this email directly or view it on GitHub: https://github.com/daveray/seesaw/issues/5#comment_1305295

[abp]

At the beach now, but I can take a look later :)

Cool. :)

It will probably be simplest if you're merged with develop before sending the pull request.

Yes, sure, thought about that too. Do you intend to take it out of it's own branch?

[daveray]

"It isn't good to rename a method of the wrapped library to avoid shadowing a core function, is it? I wrapped the empty method in add, too."

I read this a few times, but I'm not sure what you mean. I don't see anything wrong with what you've done though.

I have no problem pulling it out of the branch into develop if someone will pay attention to it, especially if there are tests. My only reservation is the added dependency, but since it's isolated in its own namespace, it shouldn't be a big deal. If someone doesn't like it, they can omit the design-grid jar, or we can roll it into a separate sub-project.

[abp]

I read this a few times, but I'm not sure what you mean. I don't see anything wrong with what you've done though.

Ah, ok. I meant changing the semantics of the DGL-librabry in favor of shadowing clojure.core/empty. I wrapped the empty method (http://designgridlayout.java.net/apidocs/net/java/dev/designgridlayout/IGridRow.html#empty()) in the add-function.

I only wanted to know what your opinion is in general, when wrapping java libraries and you encounter such situations. I mean (add) is easily understandable as empty column. (add 2) should also be a no-brainer. But someone used to DGL (ok, that's not very likely), might wonder where his beloved (empty) is. :)

For what i solved via (cond ...) in (add), I miss an arity overloading that supports dispatch via type hints. :)

Btw: Thats my first piece of useful clojure code ever written.

I have no problem pulling...

Extracting it into a sub-project as a seesaw plugin sounds reasonable to me.

[daveray]

Ah. Got it. Well, I've heard (can't remember the source, maybe Fogus) that people worry too much about shadowing symbols and that it's really not a problem because :refer is so flexible and powerful. On the other hand, I find it a little disconcerting when I get that warning about shadowing a core function. So, I think using just (add) is probably fine until someone complains, which probably won't be anybody :)

You could always use a multi-method for the arity/type dispatch, but I think there's some complexity threshold you need to cross before it becomes worthwhile. My approach so far with Seesaw has been to try to get the API right and get it working in the dumbest way possible with tests. Then refine the implementation so it doesn't suck.

[daveray]

p.s. congrats on writing some useful clojure code :) seesaw is the first useful clojure code for me as well.

[jackrusher]

I'm nearly six years late to this party, but any chance this will become a part of Seesaw?