Posted by Eitan Suez
Thu, 05 Apr 2007 20:33:00 GMT
I believe I have on my hands a decent implementation of a subset of the CSS standard for Swing, and I've started integrating it into JMatter.
The integration is checked in to the JMatter subversion trunk.
In fact, I just finished documenting the feature. You'll find a new chapter (14) both in the online browsable html version of the documentation and the online version of the PDF (see here).
I plan to cut a new release of JMatter over the coming days. If you happen to be working against svn trunk, please play around with this if you have a chance and send me feedback.
I'm personally quite excited about this. I believe that CSS significantly simplifies styling and tweaking a swing UI, without having to touch the code. Also, it reuses knowledge that we already have.
Again, all the details are in the documentation, and please don't hesitate to post your questions to the mailing list.
Thanks, / eitan
2 comments
Posted by Eitan Suez
Thu, 22 Mar 2007 20:18:04 GMT
Check out this blog by Andres Almiray regarding the Desktop Matters conferences, and specifically JMatter (!).
no comments
Posted by Eitan Suez
Wed, 21 Mar 2007 20:52:00 GMT
It's been over a week since the Desktop Matters conference where I presented on JMatter. Although I did blog about general impressions of the conference on my java.net weblog, I'm not sure why I haven't really started collecting my thoughts of the conference as they apply to JMatter.
So here is a first post. Hopefully this will not be the last on this topic.
The Desktop Matters conference lasted approximately 1.5 days. It started on a Thursday afternoon and ended late on Friday. Throughout this time, we listened to various speakers talk about some aspect of Desktop development.
One particular session, given by Ben Galbraith, made some interesting points:
- It tried to summarize current pain points with Java Swing
- It tried to express visually the need for a framework for building applications with Swing
This was the list of pain points:
- GUI Creation and Maintenance
- Concurrency
- Binding and Validation
- Various API Problems
What I find interesting is trying to gauge JMatter against each of these points. Does JMatter help mitigate these problems?
JMatter completely does away with the first: "GUI Creation and Maintenance." With JMatter it's not even a question of how easy is it to create and maintain your GUI. GUI Creation and maintenance disappears.
The second pain point speaks to the fact that developers have to be very careful to perform UI-related operations on the event dispatch thread, and conversely to ensure that non-ui operations (particularly long-running ones) are performed off that thread. Again, in this respect, JMatter completely removes this burden from the plate of the application developer. Methods are exposed as actions using a simple convention. The framework ensures that the action is invoked off the edt and that the view for the object that the method returns is constructed back on the edt.
The third point is likewise addressed by the framework. Your model objects automatically bind to the framework's views. You don't even need to learn or concern yourself with an API for data binding. JMatter works at a higher level. Much of the burden of validation is lifted and custom validation can be added by overriding the validate() method.
The last point wasn't too clear to me. I assume it spoke to the fact that the Swing API in general is very large, very complex, and not very consistent in many respects. It may not apply at all to JMatter since you typically rarely even interface with Swing. You might for the purpose of creating and plugging in custom views for types. This task is by its very nature somewhat challenging, but nothing that an experienced Swing developer cannot tackle.
Let's discuss the second issue: Swing is by no means a framework for building business applications. It is nothing more than a toolkit for building user interfaces. No one is certain why in the web world we have dozens of higher level frameworks to choose from and yet in the Swing world, folks have only recently begun considering the development of such frameworks.
I propose that JMatter fills this void. JMatter addresses comprehensively the task of building business solutions. Furthermore, it does so at a much higher level than most other APIs.
I recall a claim that used to be made a long time ago about the difference between a mac (i'm talking about v6 or v7) and a pc (back in the days of windows 3.1). Whether justified or not, the claim pointed out that with a mac, users typically were able to focus on the task at hand. While with a pc (at least in those days) one fiddled a lot with dos, autoexec.bat and config.sys and for the most part one remained distracted from the job they had to accomplish.
This is a major lesson about usability. Folks such as Jef Raskin wrote about the locus of attention.
I believe that JMatter frees developers in an analogous manner. We're not talking about UIs here. I'm basically saying that this framework lets developers focus on the business domain and keeps the plumbing out of their way. An apt analogy?
no comments
Posted by Eitan Suez
Wed, 07 Mar 2007 23:10:00 GMT
We've all had to implement this feature as developers.
Today, many frameworks such as Tapestry for example,
will provide components out of the box that will automatically
take care of paging a listing on your behalf.
JMatter also provides paging out of the box. When I sat
down and started to think about this feature, I saw a
certain pattern. One's first, naive implementation of
paging might consist of a simple forward and back navigation
buttons:
< >
Shortly afterwards comes the request for the ability to navigate
to the first and last page in a listing, and so they are added:
<< < > >>
Then embellished, like so:
<< < [Page 3] > >>
Over time, paging has evolved to let you navigate to a number
of pages in the vicinity of the current page:
1 2 .. 7 [Page 8] 9 .. 13 14
This is what most web-based applications do today.
What I realized is that paging, taken to its eventual limit,
is essentially embodied in the behaviour of a scrollbar. Most
scrollbars provide continous scrolling. Whereas in the case of
paging, the scrolling is more discrete. The more pages there
are, the less this discrete behaviour is apparent. What's nice
about today's scrollbars is that their size is inversely proportional
to the length of the list. The larger the list, the smaller they
are. Scrollbars have the advantage of giving you more of a visual
perspective of where you are in the list. And you can simply drag
the scrollbutton to any location along its dimension.
JMatter's Swing-based view mechanism defines a view implementation:
a component named PageScrollBar which extends Swing's JScrollBar,
shown at the bottom of the following listing:
As usual, developers of JMatter applications need not concern themselves
with this at all. It's bundled into the framework and it just works.
If however you feel the need to customize the way this scrollbar looks
or behaves, it's easy enough with a little Swing experience to make
the desired revisions.
no comments
Posted by Eitan Suez
Wed, 07 Mar 2007 18:35:00 GMT
I have been working at implementing the codebase that I call
a framework that I named jmatter for quite some time.
Looking back, I realize that I have on very few
occasions actually expressed (or attempted to express)
what I have constructed. Most of the time, you may say that
I was not completely conscious of it.
UI
Part of JMatter is a user interface for business applications
that I wrote in Java Swing. With respect to the UI, the fundamental
design boils down to:
- essentially designing an ooui, a ui that mirrors the underlying
business object model
- mvc: views are listeners on model objects and as the model
objects change, the views reflect the change
Persistence
Another aspect of JMatter deals with persistence. I wanted transparent
persistence. Most of the work is delegated to Hibernate. Some of
the conveniences I developed included the automatic construction of
mapping files from the objects. This effort has in a sense been
nullified by the fact that JPA does this too, and perhaps they do
it better because a combination of reflection and interpreting of
annotations is translated to the underlying metamodel that Hibernate
uses at runtime. The xml mapping files are but a marshalled version
of this information.
Core
On to the heart of JMatter. I realize now that I have never
really written down what this heart is. In a sense it's a metaobject
protocol for Java. JMatter contains a number of classes that model
types (ComplexType), instances (EObject), fields (Field), and methods
(Command / EOCommand). Java of course has a reflective API. But by
writing my own, one that lives on top of the language, I was now in
a position to, in a sense, define my own language. If I wanted to give
commands special features, I could write them in. Take for example
the notion in JMatter that a command can be designated as "sensitive."
Another, that a field can be marked "Required" which has implications
in terms of the behaviour of CRUD operations. Another is the fact
that these types themselves are all EObjects which means they can
be persisted and manipulated directly from the UI. Though at the time
of writing, they cannot be created (yet).
I ended up defining all kinds of rules and conventions for constructing
business applications. And this system can in time adapt to all kinds
of situations. Now that JMatter is open source, it has a diverse and
growing community, with diverse needs. JMatter has changed over the last few
months to address not only bugs, but desires for this system to meet
these users' needs.
We still have many items on the drawing board, much of it has to do
with providing implementations for cross-cutting concerns that are not
yet addressed. Implementing reporting: defining, saving, editing,
and running reports that produce PDFs for example, all directly from
the UI. Finishing Authorization. I'm proud of the fact that the basic
design I have is very simple and clean. But this work is not yet
complete. Scheduling features could use a number of improvements.
Still, much is already in place, and the user interfaces of JMatter
applications, both in terms of their richness and simplicity, is something
that I am proud of.
Many things go into making
a project or a product successful. Trusting the community. Managing
the project with responsibility. Communicating with the community.
Integrating patches. Providing good documentation. Perseverence and
keeping the momentum going. Today we have more tools at our disposal
than ever to keep the momentum going, from blogs to mailing lists,
subversion repositories, great tools for producing documentation, content
management systems and much more.
no comments
Posted by Eitan Suez
Thu, 01 Feb 2007 21:37:00 GMT
Many of us take somewhat of a leap of faith when
we decide to open-source our work. With respect to JMatter,
I took some time to make that step, not knowing how things
would pan out.
One thing that indeed happens and happens quickly, is that
[once a tool for reporting issues was made available] approximately
100 issues were reported, perhaps 200 or more if you count informal
issues reported through the mailing list, over perhaps a period
of 3-4 months.
Today I took some time to look at and resolve some outstanding
defects/issues.
One thing that is obviously wonderful about sharing this framework
is that many of you have put this framework through paces and have
uncovered bugs (many of which I've fixed by now, though nothing is
perfect, and time is different when dealing with open source projects).
In retrospect, there's absolutely no way that I could have by myself
uncovered some of these bugs. Some are exhibited in very special
circumstances. I marvel at the nuances, and often tell myself: "wow,
I would have never thought to try that."
So, I would like to say publicly: thank you, all of you who took
the time to report these issues. I know I sometimes take time to
get to them (but hey, it's not like I'm getting paid for this).
This framework is improving as a consequence of your active participation.
One important note: when I asked the community what issue manager
they recommended, a number of you recommended trac, which I installed.
Since then, trac has gone through some upheaval as a consequence of
having no provisions (at the time) to prevent spam. The bug database
was trashed and it took quite some time to get it cleaned up, and back up
and running. Consequently, I am requiring that users obtain an account if
they're going to log issues (I hate to have to do this but I feel like I don't
have a choice). For those of you who do not wish to go through so much,
I would still very much appreciate to hear about your issues through the
jmatter mailing list.
21 comments
Posted by Eitan Suez
Thu, 01 Feb 2007 15:37:00 GMT
I'm excited about the upcoming Desktop Matters conference. The last couple of years have seen many topic-focused conferences, including ones on AJAX, Web2.0, and Rails.
And so it's time we've had a conference focus on Java Swing and related Desktop Client technologies.
I'm grateful to Jay Zimmerman and Ben Galbraith for making this event happen.
And.. I can't wait for the chance to speak on the project that is dearest to my heart: JMatter. I hope to see you there.
/ Eitan
no comments
Posted by Eitan Suez
Tue, 12 Dec 2006 16:05:00 GMT
The JMatter "to-do" list has had an item on it
that for a while I thought would never get done.
JMatter GUIs are inherently OO UIs. I like to make
the analogy to our operating systems' desktops. There
are a number of ways to make such UIs more effective.
Sometimes I look to these desktop systems for ideas
and features.
One such feature was Apple's "Expose" which has since
also been copied by the Beryl project on Linux: the
idea of scaling down and fanning out one's windows
temporarily for the purpose of easily switching focus
to a window that is otherwise hidden by other windows
that have a higher z-index. JMatter has such a feature.
Pressing the F12 key invokes the JExplose feature
which does precisely that (the desktop pane's context
menu also bears the option).
Another feature of desktop systems, one that has been around
longer, and is specifically related to the file manager,
is the idea of giving users options in terms of how to place
newly-created views. When navigating a folder hierarchy,
one can double click on a folder, which typically opens a
new window with the contents of that folder. Long ago, on
ms-windows I recall always turning on the option of "re-using
the existing window"; that is, replacing the existing view with
the new one. This can really help with an otherwise
rapid proliferation of windows on one's desktop.
Then, mozilla introduced us to another navigation option: a sort
of "middle of the road" option: don't create a new window, but
don't replace the existing view either: place the new view in a
new, separate tab. So mozilla gave birth to tabbed browsing. I
believe tabbed-browsing is not a feature that applies only to
the task of navigating web pages; it can be applied
more generally, including to applications such as a file manager.
Back to JMatter. I have recently finished implementing a number
of related enhancements. The first is extending slightly the model
for Users. A User now has a new aggregate property called
"Preferences." Its first and only option at the moment captures how a
user generally prefers to navigate in JMatter: should new views
be created by default:
- in a new window?
- in a new tab?
- in-place, replacing the existing view?
Setting your preference is all it takes to change JMatter's
default navigation behavior.
There are many situations where one will want to override the
default and, say, want to open a new view in a new tab even
though the default is in-place navigation. So a new gesture
has been introduced in JMatter. Holding down the Shift key while
invoking a command that produces a new view will cause a context
menu to popup near your mouse location, allowing you to select
how you'd like that particular view created. Choose "in a new
tab" and proceed.
In the screenshot below, you see me invoking the "Open" command.
I am holding down the Shift key.
In the next screenshot, you see the navigation option pop up.
I selected the "in new tab" option.
Next, you see the result of the view created in a new tab.
Finally, this last screenshot shows that, with tabs, you
have the option of detaching the view onto its own window
or closing the tab (Ctrl+w is the corresponding key binding).
This feature is for all practical purposes complete and checked
in to subversion, and will also be included in the next release.
I believe this to be an important feature, finally producing a
desktop with a number of effective navigation instruments:
- Fundamentally an OOUI
- DnD support
- An expose-like feature
- Tabbed, In-Place, or New-window view placement
The last item on the drawing board that in my mind will complete
the picture is support for docking views. I have looked at
flexdock, which is a terrific effort. But I'm looking for
something that is more transparent: effectively a layout
manager designed for JDesktopPane that transparently provides
docking support. Let me know if you know of or are working
on such a thing.
6 comments
Posted by Eitan Suez
Fri, 08 Dec 2006 23:13:00 GMT
JMatter takes a certain strategy relating to the placement
of new windows (internal frames) in its Graphical User
Interface.
I recall trying various window placement strategies and
then realizing something I was doing as a user of my
applications: after creating a new view, I'd quickly reach
for the window's title bar and place the window where I
really wanted it. I don't think there's an algorithm for guessing
the user's intent. So I started thinking about what might
be the next best thing.
The strategy was to minimize the amount of work I'd have
to do in moving the resulting window. What I do is
place new windows such that their title bars are near
the current mouse cursor location, thus minimizing the
distance one would have to move their mouse to reach for
it.
There's a somewhat hidden feature in JMatter which I
very much like and that I'd like to share. This feature
takes things one step further: it automatically puts
the newly created window in placement mode. Allow me
to explain..
This feature requires pressing a metakey to communicate
your intent to use it: when you're about to invoke a command
that creates a new view (e.g. the "Open" command) , hold
down the Control key.
The resulting window automatically "binds" to your
mouse location. That is, it will follow your mouse.
So, the way it works is you invoke the command with
the control key pressed and the new view is created
but it starts following your mouse around. Once you've
found that ideal spot, a single left-click is all you
need to do to pin it back down onto the desktop.
If you already know about this feature because you've
pored through the documentation meticulously, then
first of all: bravo! If not, go ahead and give this
feature a try. Either way, let me know whether if you
like it!
In my next blog entry (Part 2), I will discuss a major
enhancement to GUI Navigation in JMatter that I just
recently finished implementing, and that will be
included in the next release.
no comments
Posted by Eitan Suez
Wed, 06 Dec 2006 17:07:00 GMT
Reasons to license JMatter:
- Fee is per-developer: no royalties; can build as many apps as you like
- Free updates; no upgrade traps
- Excellent documentation
- No support fees; your questions answered in a
timely manner on the mailing list, by the framework's
author, and by others JMatter-savvy developers
- Comes with all the source code!
Cost-Benefit Analysis
Estimate how much time and effort you might save by using JMatter.
Perhaps one man-year? Now do the math: $500 / year for JMatter
compared to the cost of one man-year of development (perhaps
$100,000), with no promise that you'll have a workable product at
the end? That's a 2000:1 ratio.
Reasons to consider donating
- Do you like what you see?
- Do you want to see it thrive?
- Without your contribution, this project may not
be able to sustain further development indefinitely
7 comments
