Thursday, June 23, 2005

Why a quick reference tool?

To me having a quick reference tool is just a very nice thing when you're programming as you can very quickly get some quick information--often just to jog your memory--and do so without a lot of effort, like waiting for some big program to load, or being forced to follow some template or have some auto-sense shadowing whatever you type.

I got excited about Class Viewer, the prototype, way before I had a SourceForge project, when I thought about the case insensitive search on methods, where I could just put in a bit of a method name, or put in something like "char" to pull out all methods that had "char" in them, whether they took chars or returned chars, or whatever, as I just hadn't seen that yet in other tools.

And javadocs, for some reason, as important as javadocs are, and despite Sun having produced a nice generic framework for accessing javadocs to the method, it can be a pain keeping up with them.

But if you're doing a quick reference, get a method, but are not sure that it's exactly the method you want, don't you want immediately to see the javadocs to clear that up?

Why should it not be a fluid process that follows the developer's needs?

Well, it can be, and that's what you get with Class Viewer.

It encapsulates a special problem space for the Java developer--quickly looking up basic information about a class, searching on methods, and then, if necessary, getting immediately to javadocs, and that's the problem space.

I used two big windows so that you could easily see the methods to one side as a constant, and get results on the other side, as well as get to, if you need them, constructors and fields.

A tool like Class Viewer by making it easy for people to get to javadocs gives developers greater reason to write them and write them well knowing that people are going to be using them, as it's so easy.

So that's a lot of the concept. Ease of use, quickness and functionality are the ideas behind Class Viewer, where it's supposed to be lightweight, useable in a wide variety of areas, without forcing you to have to get a manual to figure out how to use it fully.


Tuesday, June 14, 2005

Class Viewer Basics

Class Viewer is made to be run from the command line, so you can put the ClassViewer.jar in the classpath, or compile the source and put that in the classpath, and run from the command line with something like:

java com.jstevh.viewer.ClassViewer String

which will open up with the class java.lang.String, or you can just use:

java com.jstevh.viewer.ClassViewer

to open up the GUI that I also call a UEI (User Enabling Interface) blank and type in a class name there.

When not ran as an applet, ClassViewerConfig.xml needs to be in the folder from which you are operating, which means you can have the jar file wherever you want, and different ClassViewerConfig.xml files in folders from which you run the program.

For instance, if you are in /home/research/myresearch and you run Class Viewer from there, you'd need a ClassViewerConfig.xml file in that myresearch folder.

If you run Class Viewer as an applet or directly from the executable jar, you won't be able to select your own classes as they won't be in the classpath.

You can double-click on methods in the left big window to do a search on them, which shows up in the "Results" big window to the right, and then you can double-click on a method there to go to javadocs to that method.

To get inherited methods you have to do a search from the search box in the lower right, and double-clicking on them will just bring you to javadocs at the top of the class.

All searches are case insensitive, and the search from the search box is space delimited.


Edited to change packagedirectory.xml to ClassViewerConfig.xml on 7/29/2015, ___JSH

Thursday, June 02, 2005

Considering the GUI

One the things I did deliberately with Class Viewer--which is why open source is such a nice paradigm as you can try new things--is get away from the "File", "Edit", "View" type of menu at the top. So I have "Help" first, and then "Links", and for when it's not in applet mode, "ClassPath".

To me that's just a more natural way for the menu to go, and I like to think that I managed a fairly decent design for a program I long thought of as a prototype.

The design of Class Viewer is meant to lead you to using it intuitively, without needing a lot of instruction or lots of menu items, as you can type in a class, and then just use the the mouse, and get all the way to javadocs to a particular method.

I decided to call it a User Enabling Interface, or UEI.

The way Class Viewer is designed, there just isn't much configuration, and it gets all of its changeable information, like where packages are, or what browser you're using, from packagedirectory.xml, so the program is fairly static.

I like to say that as long as the format for getting javadocs doesn't change, and the Reflections api isn't broken with previous versions, Class Viewer can be used indefinitely, as you can simply change the xml file, which means that I could stop development now, and feel confident that several years from now, Class Viewer could still be used.

My design focus is on an easy to use design that doesn't force me to keep fiddling with things to do something, and which doesn't make me go through a lot of options, as I think a proper design, for a properly encapsulated problem solution, will not require a lot of effort just figuring out how to get it all to work.

If you need a lot of options, I think you need a separate module or another program that might be called by your app (and I'm considering what else to add to Class Viewer where it would call another program), versus forcing people to spend time understanding a particular design.