Popular @
Forum Controls
Spotlight Features
The Rich Engineering Heritage Behind Dependency Injection
Andrew McVeigh takes us on a tour of the rich heritage behind dependency injection, what it represents, and tells us why its here to stay.
NetBeans 6: Matisse Updates
NetBeans 6 delivers great updates to the Matisse GUI builder. Spend a few minutes with Roman Strobl and get an expert briefing on what's new and what has changed. (sponsored)
Introduction to Groovy Part 3
In this, the third and final installation of Andres' Introduction to Groovy series, you learn about how Groovy handles variable numbers of arguments, named parameters, currying, and more about Groovy operators. Including, some new operators.
Easier Custom Components with Swing Fuse
Swing Fuse (actually just Fuse), is a framework designed to make it easier to create your own custom desktop components. In this article, Daniel Spiewak shows you how to get started and provides sample source code you can download.
Benchmark Analysis: Guice vs Spring
Willam Louth shows how he uses JXInsight Probes to investigate probable performance issues with code bases that he is not familiar with. He also highlights possible pitfalls in creating a benchmark, as well as in the analysis of results.
Replies:
9 -
Pages:
1
What do you expect from the "Feel" part of the Look and Feel?
URL: Look and Feel repository
At 7:32 AM on Apr 26, 2006, Kirill Grouchnikov wrote:
Fresh Jobs for Developers Post a job opportunity
On one hand, it's nice to take a LAF and get not only the "look" that you and your customers are comfortable with. On the other hand, what about the "feel" part? Many complain that Java desktop applications are far from the native (mostly Windows) applications in many areas. These include file choosers, context menus on text controls, non-rectangular windows (not much that can be done in third-party LAFs except using Robot) and so on. In addition, we constantly see new UI ideas in the native applications (one especially rich source is Firefox extensions).
So, after adding some nice (in my view) "feel" stuff to Substance, such as auto-completion on editable comboboxes, menu search panel [1], heap status panel [2], close buttons on tabs [3], tab overview and tab preview [4] and some more, i find myself thinking about the positive and negative sides.
One positive side (for developers that decide using Substance) is that they get well-tested features for free. Just put some client properties / API calls in your application, and you enrich your application. You can code them yourself, you can use some third-party code, or you can get it from your look-and-feel. This is about it for the positive side. What about the negative side?
* The runtime jar size grows up considerably (and i hear about this quite a lot). The only thing i have to say (i mention it in the FAQ [5]) - if you want these features, you will have to either code them yourself or take them from other libraries. In any case the application will contain this code.
* Since these features are not present in other LAFs, this can be viewed as a lock-in of some kind. Not that i mind, but it may alienate some developers.
* Most of the features need to be turned on using client properties on the components / UIManager (since i don't want to add unwanted UI components to the applications). This introduces explicit dependency on Substance. Once again, this may alienate some developers.
So, what do you think? Is it a good thing to add to the "feel" part?
[1] https://substance.dev.java.net/release-info/2.0/menu-search.png
[2] https://substance.dev.java.net/release-info/2.1/heap-status.png
[3] https://substance.dev.java.net/release-info/2.1/tab-close-unselected-active.png
[4] http://weblogs.java.net/blog/kirillcool/archive/2006/04/spicing_up_your_3.html
[5] http://substance.dev.java.net/docs/faq.html
9 replies so far (
Post your own)
Re: What do you expect from the "Feel" part of the Look and Feel?
All you say is true.Of course that the JAR grows as you add more Feel features and it is normal that some people complain about it.
Of course that theses news Feel features can be seen as a lock-in of some kind.
In my opinion both these "problems" have an easy solution: like java and javax, split the substance code base into 2 parts. From what I see you have already started doing that with the lite version. You should just push the concept a little bit more and remove from the lite version all no standard stuff, all lock-ins.
> So, what do you think? Is it a good thing to add to the "feel" part?
Yes. If someone wants to benefit from the Feel features and be dependant on the Substance L&F there is nothing wrong with it.
There is nothing wrong either to just want the Look and not the extra Feel things of Substance. Refactor your code so that it becomes possible.
Re: What do you expect from the "Feel" part of the Look and Feel?
Substance is very impressive. However, as a matter of personal preference I don't like having components in the LNF. I'd prefer to use Swing components that can be reused with other LNFs.I realize your "feel" components are written with Substance in mind and they look great, but an element of reuse is lost.
Re: What do you expect from the "Feel" part of the Look and Feel?
I don't see the drwabacks you talk about as critical. For a long time Swing LookAndFeels have been relegated to change only "look" and to fulfill a common "feel", which I think is enpoverishing what they can give the user. Even the look, for some people, is not worth to be different from the look popular OS's give us. Why?I see perfectly good the existence of common, OS related L'N'Fs, but this technology in Swing gives us much more possibilities: my opinion is that Substance is a great product, which is taking java applications capabilities beyond what Microsoft or Apple offer us. Don't see any reason to change that. Jar size is not a problem today, and for the "lock-in" matter, it's just a consequence of being ahead other products. If you had been careful to not have this lock-in, Substance would be just one more, not really different look and feel.
Thanks for your job and congratulations, Kirill!
Re: What do you expect from the "Feel" part of the Look and Feel?
bangs-oneself-on-the-foreheadFinally a good reason for the major version (3.0 instead of 2.4). Thanks for the excellent suggestion. Of course, i'll have to be careful and not break the existing API, but i think it can be done. One thing though bugs me.
Now the lite version is the same as full minus the custom color chooser panels. If i decide to remove all additional "feel" parts from the lite version, people may start asking "Can i have the lite version but with tab close buttons?" Already there are about 10-15 such features that are provided as one "pack". What if people will start asking for an arbitrary combination of such features?
This brings me to another question - perhaps this refactoring should result in a LAF-agnostic code that can be plugged into any third-party / core LAF? This can be a little more challenging but will allow other LAFs to contribute their own widgets? I need to think about this for a few days - perhaps come up with a "laf-widget" project.
Thanks for pointing me to this direction.
Re: What do you expect from the "Feel" part of the Look and Feel?
> What if people will start asking for an arbitrary combination of such features?You can't please everyone. If you code is nicely organized you could tell them: erase the directories (each package would represent a feature) within the jar that you don't need or want. So if getting ride of some features only implies deleting some (easy to identify) classes in a jar, everyone can get their dream configuration.
> perhaps this refactoring should result in a LAF-agnostic code that can be plugged into any third-party / core LAF?
I don't know if this is doable but if it is, it sounds like a great idea.
Re: What do you expect from the "Feel" part of the Look and Feel?
I always thought the "feel" in "LAF" mean the behavior of components, as opposed to their look. A button looks "pressed" when you click and goes back to normal when released.So by that definition, the autocomplete feature is indeed a "feel", but the other 3 are new widgets, not a "feel" for an existing widget. The heap size thingy isn't associated with any widget, and I think calling the "menu search" thing just a "feel" of the MenuBar to be a stretch.
Anyway, these look fine, but I have to throw in my usual comment: it's the end user's perception that matters, not the developer's. So here:
> i have struggled to find the right balance between adding useful (mostly to myself) "feel" features and not alienating the developers (see the list below).
my response is "don't worry about alienating the developers, just don't alienate their users".
Re: What do you expect from the "Feel" part of the Look and Feel?
> my response is "don't worry about alienating the> developers, just don't alienate their users".
If only i could go directly to the users ...:) First i need to please the developers so that they'll graciously show it to their users.
Re: What do you expect from the "Feel" part of the Look and Feel?
Well, most LAFs concentrate on either a) matching an existing platform's aesthetics and behaviour; or b) creating something "pretty". Substance seems to be doing (b) and a third thing, (c), which is adding new functionality not available in the default LAFs or the native operating system.In this respect, I think the "Feel" side of Substance should probably be made seperate from the "Look". After all, why shouldn't the features you mention (menu search, auto-complete, ...) be available in other LAFs? A Mac-style filechooser would look wrong on Windows because Windows already has it's own method of achieving the task. In constrast, the features you mention have no existing implementations in current OS's and therefore are going to look novel whether they're on a Substance, Metal, Quanga, WinLAF or JGoodies application.
In summary (sorry for rambling): "Feel" components that (re-)implement existing functionality (filechoosers, buttons, etc) should be part of the respective LAF, but completely new functionality should be made available as seperate components (like your ribbon bar) even if they utilise the pluggable LAF structures as a means of implementation.
Does this make sense?
Re: What do you expect from the "Feel" part of the Look and Feel?
Following the idea given by James, the "feel" part of Substance has been refactored to a separate project at [1]. See the project site for the details (more to come) how these widgets are available bot only in Substance but in a variety of other LAFs (Looks, Squareness, Pagosoft, Napkin, Liquid).[1] https://laf-widget.dev.java.net