Skip to main content

Hyperlinks and JXFrame

40 replies [Last post]
Anonymous

Hi Everyone,
long time and no commit ;) I'm a bit too busy with some projects all coming
together...

Anyway I am writing a prototype for an application using SwingX mostly and
had a couple of minor issues:
1. The hyperlink doesn't respect enabled/disabled state correctly and
doesn't mutate when the action to which it is bound is modified. I looked
into the code and it seems to me that it is a mistake to base this widget on
a label rather than on an abstract button. So I placed into my incubator
directory (vprise/candy) a JHyperlink class that looks exactly the same but
is based on JButton and thus has better support for lots of the features
that abstract button brings to the table.
Is there a reason I can't see for choosing JLabel?

2. I complained about this ages ago but this has become really annoying.
Someone placed a pack() call is JXFrame setVisible... This is REALLY bad for
any application that wants to persist its size and position. Pack produces a
huge window with my UI... There has to be a way to remove this, I would just
avoid JXFrame but I want the status bar ;)
Anyway Richard I recall you had great code for persisting Window positions
and I see some of it in SwingX why not place the code to persist the Window
positions into the java.util.prefs repository into the WindowUtils class and
remove the pack() call?

Thanks.

--
Shai Almog
vPrise Consulting
http://www.vprise.com/
[att1.html]

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
evickroy
Offline
Joined: 2004-07-23

> In Java you use pointers to place panels in a
> hierarchy and you don't have a
> concept of location (URL) that you can use for links
> that are just embeded
> in. So there is no forward/back and history.

You could use a card layout for forward/back and history if you needed to. If you have requirements for forward/back and history, then your screens are probably bound to some workflow process. Wouldn't that normally imply the use of a wizard since there are required steps with a given order?

>
> Sure a rich client is much better than a web client
> (I did and still do a
> lot of web developement as well) but that doesn't
> mean there aren't nice
> things we can steal from the web right ;)

I'm not saying one is better than the other. It just sounded like you were asking for a web-style pageflow/navigation framework to be added to JDNC because buttons and the hyperlink component didn't do what you wanted.

Chaining pages, or panels, that are multiple levels deep usually confuses the heck out of the users from my experience, so a free-form, forward/back navigation style wouldn't normally be my first choice if there was a required workflow. Again, the wizard would be the most recognizable component for such navigational requirements I would think.

Are you really just wanting some object that can be conveniently attached to a hperlink, button, or whatever that will initiates some action when triggered?

Erik

Shai Almog

> You could use a card layout for forward/back and history if you needed to.
> If you have requirements for forward/back and history, then your screens are
> probably bound to some workflow process. Wouldn't that normally imply the
> use of a wizard since there are required steps with a given order?

Not really no...
A card layout would pretty much require me to have the entire UI composed in
memory... This is the same problem I have with a tab based UI: Startup time
is too slow.

You are trying to make the point that navigation is possible (and relatively
simple) with a component hierarchy, while this is accurate technically it is
still something that you need to reinvent and isn't standardized like it is
on web based applications. I would have to actually think (shudder) in order
to implement something like this. The problem with "thinking" is that most
people will do that differently and so my navigation code won't be able to
interact with yours without customization and wheel reinvention ;)

> I'm not saying one is better than the other. It just sounded like you were
> asking for a web-style pageflow/navigation framework to be added to JDNC
> because buttons and the hyperlink component didn't do what you wanted.

I wasn't so much asking for it, rather suggesting that if something like a
real hyperlink is desired then this needs to exist. There is no dispute in
my mind that the Swing approach of Component hierarchies is considerably
better than the web "everything is a document" approach.
I do however know that it is possible to bring the document approach into
Swing while maintaining the full set of advantages Swing has. Think about
your card layout code, wouldn't you rather have that exact same code
generalized and reused between projects? That's what we did in multiple
projects. Now if something like that would exist then adding navigation
related interfaces (as in the Java interface keyword and not as in UI) would
be rather easy... An interface like navigatable or something like that.
Once we have these things in place we can provide generic functionality such
as a generic logout Action that navigates to the application startup page.
An applications flow can be visualized more easily and controlled from a
single point (this is VERY powerful).

Chaining pages, or panels, that are multiple levels deep usually confuses
> the heck out of the users from my experience, so a free-form, forward/back
> navigation style wouldn't normally be my first choice if there was a
> required workflow. Again, the wizard would be the most recognizable
> component for such navigational requirements I would think.

In most cases, yes. But even opening something into a modal dialog is
navigation. Everything you do that causes new UI to show can be viewed as
navigation. The trick is not to burden Swing's excellent model with a clumsy
framework that will limit functionality.

Are you really just wanting some object that can be conveniently attached to
> a hperlink, button, or whatever that will initiates some action when
> triggered?

I just want a button that will look like a hyperlink ;)
But the discussion shifted to UI design and theory... I'm not necessarily
advocating the addition of a navigation framework, but since I'm right now
coding some navigation logic in my application I was interested in peoples
thoughts on the matter.

--
Shai Almog
vPrise Consulting
http://www.vprise.com/
[att1.html]

rbair
Offline
Joined: 2003-07-08

> You are trying to make the point that navigation is
> possible (and relatively
> simple) with a component hierarchy, while this is
> accurate technically it is
> still something that you need to reinvent and isn't
> standardized like it is
> on web based applications. I would have to actually
> think (shudder) in order
> to implement something like this. The problem with
> "thinking" is that most
> people will do that differently and so my navigation
> code won't be able to
> interact with yours without customization and wheel
> reinvention ;)

I really like this thought. This would be great to think of in terms of a broader application framework / rcp, I would think. In any case, as you said, something to talk about in detail (in perhaps another thread), but to avoid losing these thoughts, do you think filing an RFE in JDNC would be appropriate? At least it'd get lodged in my tasklist somewhere ;)

Richard

Shai Almog

> I really like this thought. This would be great to think of in terms of a
> broader application framework / rcp, I would think. In any case, as you
> said, something to talk about in detail (in perhaps another thread), but to
> avoid losing these thoughts, do you think filing an RFE in JDNC would be
> appropriate? At least it'd get lodged in my tasklist somewhere ;)

Thanks,
I just submitted an RFE to the incubator project. I assume its the best
project since this isn't essential functionality and I don't have anything
concrete in mind right now.

--
Shai Almog
vPrise Consulting
http://www.vprise.com/
[att1.html]

Patrick Wright

> What exactly is the difference between a web-style link that navigates to a different page and a rich-style button/tab that displays a different panel? Is there really a need for a web-style page navigation framework for a Swing application? NOT having to navigate using links and multiple pages is one of the many benefits of using a rich client IMO. If you really need that kind of page flow, wouldn't a re-entrant wizard component do the trick?
>

An example is: internal frame, collapsable task panels on the left,
main panel on the right. the task panels include navigation that
change the contents of the main panel, as well as "read more about..."
links. Click on a "read more about" link and an HTML page on the topic
comes up in the main panel.

When you load the HTML page, it's pretty straightforward to use either
the JEditorPane or an industry-leading, ground-breaking,
standards-compliant, fully operational battle station like Flying
Saucer **. Each of those can be associated with a single
HTMLDocumentAction, which calls setDocument() with a given URL as a
parameter. Having such an Action available out of the box makes it
easy to associate a JXHyperlink with a loadable page, and we can do
this since there are known APIs for loading HTML documents for
view....

IMO
Patrick

** Note: I'm one of the FS developers (though, truth be told, I work
on the boring stuff).

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

evickroy
Offline
Joined: 2004-07-23

> An example is: internal frame, collapsable task
> panels on the left,
> main panel on the right. the task panels include
> navigation that
> change the contents of the main panel, as well as
> "read more about..."
> links. Click on a "read more about" link and an HTML
> page on the topic
> comes up in the main panel.
>
Have you looked at the JTaskPane, JButtonBar, or JOutlookBar components from L2FProd? Those are very nice components that simplify the above task.
http://common.l2fprod.com/

I was just trying to point out that there isn't much difference between a link that causes a new page to be displayed as opposed to a button being pressed and a new panel being displayed.

Erik

evickroy
Offline
Joined: 2004-07-23

> I'm actually just working on this particular area
> since my application
> (obviously) needs some navigation. Since SwingX
> doesn't provide it I chose
> to use tabs for most of my UI (which is ok the UI
> isn't big) but I still
> have to navigate to additional windows.

What exactly is the difference between a web-style link that navigates to a different page and a rich-style button/tab that displays a different panel? Is there really a need for a web-style page navigation framework for a Swing application? NOT having to navigate using links and multiple pages is one of the many benefits of using a rich client IMO. If you really need that kind of page flow, wouldn't a re-entrant wizard component do the trick?

Just curious.
Erik

Shai Almog

> What exactly is the difference between a web-style link that navigates to
> a different page and a rich-style button/tab that displays a different
> panel? Is there really a need for a web-style page navigation framework for
> a Swing application? NOT having to navigate using links and multiple pages
> is one of the many benefits of using a rich client IMO. If you really need
> that kind of page flow, wouldn't a re-entrant wizard component do the trick?

In Java you use pointers to place panels in a hierarchy and you don't have a
concept of location (URL) that you can use for links that are just embeded
in. So there is no forward/back and history.

These things can be added to a higher level framework (which I suggested
that we can do in the future) but they aren't a part of Swing/JDNC and right
now they are probably not essential.

Sure a rich client is much better than a web client (I did and still do a
lot of web developement as well) but that doesn't mean there aren't nice
things we can steal from the web right ;)

Document based solutions and views are a very powerful tool. When we build a
huge GUI design we start by designing the flow of the application and how
the user will navigate between types of functionality. Since most
applications allow a user to navigate between forms/documents/screens
(whatever you want to call them) this sort of funcitonality should be
generic. I personally think that something like a link is much simpler than:
myPanel.removeAll();
myPanel.add("Center", myOtherUI);
myPanel.revalidate();
myPanel.repaint();

And this is a simple case ;)

--
Shai Almog
vPrise Consulting
http://www.vprise.com/
[att1.html]

Kleopatra

Shai Almog wrote:
>
>
> One thing I think we both agree on but wasn't clear from your mail. The
> link in the text package is completely different from JXHyperlink in
> concept. While they should look the same externally document (html)
> navigation is completely different from navigation within the
> application.

Hmm, I'm not so sure we agree on that What I'm trying is to find
similarities, if there are any. From the discussion in the javalobby
thread (Fred mentioned it) it looks like "web-like" navigation is very
much in the center of it - what exactly happens on "going somewhere" is
up to the developer, with reasonable defaults.

> That is why I think a button would be the best approach.
> However, since a button has no idea about its usage it can't tell
> whether the visit to the next page was successful since any one of N
> action listeners can cause the actual navigation and they don't have any
> way to indicate failure (other than an exception which IMO will break
> some of the event handling contract so its probably not a good idea).
>

"visited" is not for the view to decide - all the view can tell is
"tried-to-triggered-a-visit" ;-) The "visited" is a property of the Link
class, we can make it more intelligent - instead of letting out-siders
fiddle with its internal state we can move the "visit" inside of the
Link and let it decide for itself. A Hyperlink component might pass-over
a visit request and update itself according to a change notification on
the visited.

Something like:

[code]
class Link {

void visit(VisitingHandler);
// bound property
boolean isVisited();
}

interface VisitingHandler {
void showDocument(URL, target) throws IOException
}

class HyperLinkView {
void setLink(Link) {
setAction(createLinkAction(link));
}
void setVisitingHandler(..) { .. }

class LinkAction ... {
// configure itself from link props
// guarantees to keep synched with link props
void setLink(Link) {...}
void setVisitingHandler(...)
void actionPerformed(...) {
link.visit(vistingHandler)
}
}

// exposed to trigger rollover effects by renderer controllers
// this is similar to the editorKit.LinkController
// but more direct - the latter fires HyperlinkEvents
void enterLink()

void exitLink()

}

[/code]

Now the configuring action is specialized on Links, the link (button)
view is driven by exactly one Link and other actionListeners are free to
do whatever they like. The VisitingHandler can be implemented by
delegating to a JEditorPane, to ApplicationContext or anything else a
developer can think of. Hmm, ...

> In my earlier frameworks I played with many concepts and most of the
> frameworks formed a hybrid of document based applications together with
> typical Swing MVC. So I had the concept of a set of documents (which is
> a "Form"/"Page" in the application) through which I can navigate and
> into which I can embed elements. JDNC has some of these concepts but I
> didn't notice anything regarding navigation between documents. This will
> probably be very useful for the XML based UI since these concepts work
> very well together, but I digress ;)

Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Shai Almog

> Hmm, I'm not so sure we agree on that What I'm trying is to find
> similarities, if there are any. From the discussion in the javalobby
> thread (Fred mentioned it) it looks like "web-like" navigation is very
> much in the center of it - what exactly happens on "going somewhere" is
> up to the developer, with reasonable defaults.

There is a major difference in the way links are treated in the text package
and in how they might be in JDNC. The text package links are designed to
trigger a jump within a page or document navigation, since the link knows
its parent the implementation is completely generic.
However, this is not the case with Swing buttons. If we would create a Swing
button for navigation the implementation is very specific since Swing (and
AFAIK JDNC) doesn't have a concept of a document and thus there is no
concept of navigation in Swing/JDNC.

So having an HTML link work in a way within a document makes sense but in
the current structure of JDNC/SwingX the HTML link is a generic entity that
extracts its data from the component and the Swing button is a generic
entity that extracts event handing code from the program class data. Worse
still there might be a lot of replicated data within the code of the button
since navigation isn't generic in JDNC/SwingX.

I'm actually just working on this particular area since my application
(obviously) needs some navigation. Since SwingX doesn't provide it I chose
to use tabs for most of my UI (which is ok the UI isn't big) but I still
have to navigate to additional windows.
It would be great if we had something like a "screen layout" chart that
would indicate the flow between application document views this is rather
complicated though. If something like this existed then it would make sense
to merge concepts from the text package link, otherwise I don't see the
benefit.

If I understood your suggestion correctly it was for an interface that would
allow the user to define navigation. I considered that earlier but dismissed
that since this would require Swing developers to implement YAI (Yet Another
Interface) rather than rely on the generic nature of Swing. If this is the
route taken I would suggest an actual navigation framework that would allow
the programmer to design the application flow and control it and thus
provide benefit beyond coloring the links in different colors ;)

--
Shai Almog
vPrise Consulting
http://www.vprise.com/
[att1.html]

Patrick Wright

> There is a major difference in the way links are treated in the text
> package and in how they might be in JDNC. The text package links are
> designed to trigger a jump within a page or document navigation, since the
> link knows its parent the implementation is completely generic.
> However, this is not the case with Swing buttons. If we would create a
> Swing button for navigation the implementation is very specific since Swing
> (and AFAIK JDNC) doesn't have a concept of a document and thus there is no
> concept of navigation in Swing/JDNC.

IMO, the whole JDNC (all subprojects) are building components on top
of components. I think in this case we agree we have some base-level
functionality, which for a Link, isn't all that interesting, but is
nice to have: namely, our button has a rollover effect (defaulting to
underline) and a coloring effect (on visited-triggered). Other than
that, it's a button that is triggering an Action.

But we can build on top of that once we have a goal. Windows XP has a
number of panels that group actions and activities contextually--so I
have ones related to wireless networking, one related to networking,
and so on. On the left hand side are collapsable panels with
hyperlinks in them. The panels provided lower-level categorization;
the links, in some cases, switch the active panel on the right, and in
other cases open up another window.

All of that we can build if we think it's useful. These are just
panels that can be swapped in when an action is triggered. I can
imagine a use for this in a properties editor, or places where there
are many views related to a single context.

Point being--we don't need to agree in this thread about those
larger-level components. They can be built out of the smaller
components. It seems we're pretty close with the hyperlink spec, with
maybe one caveat--that we should plan on having some useful default
Actions that the hyperlink can use, one of which may be HTML-URL
related.

Patrick

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Shai Almog

> Point being--we don't need to agree in this thread about those
> larger-level components. They can be built out of the smaller
> components. It seems we're pretty close with the hyperlink spec, with
> maybe one caveat--that we should plan on having some useful default
> Actions that the hyperlink can use, one of which may be HTML-URL
> related.

Patrick, you and me are exactly on the same page ;)
This is exactly the point I was trying to make but I lacked your eloquence.

--
Shai Almog
vPrise Consulting
http://www.vprise.com/
[att1.html]

rbair
Offline
Joined: 2003-07-08

Hey Jeanette,

I just read your list, very nice summary. The question I have is: is Link really necessary? Couldn't JXHyperlink (the more general component) supplant it? With a modified form for use as a cell renderer, I think you wouldn't need the Link object anymore. It'd be nice if we consolidated our story a little bit, and just had links in the text package and JXHyperlink.

What do you think?
Richard

Amy Fowler

jdnc-interest@javadesktop.org wrote:

>Hey Jeanette,
>
>I just read your list, very nice summary. The question I have is: is Link really necessary? Couldn't JXHyperlink (the more general component) supplant it? With a modified form for use as a cell renderer, I think you wouldn't need the Link object anymore. It'd be nice if we consolidated our story a little bit, and just had links in the text package and JXHyperlink.
>
>
Link exists to supply a ui-independent type for this sort of think in a
data model.
We created this type in one of our very early demos because we had HREF as
one of the columns in our tabular data model and needed a structure to
represent
its parts.

Aim

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

rbair
Offline
Joined: 2003-07-08

> Link exists to supply a ui-independent type for this
> sort of think in a
> data model.
> We created this type in one of our very early demos
> because we had HREF as
> one of the columns in our tabular data model and
> needed a structure to
> represent
> its parts.

So... the Link might act as a model for JXHyperlink?

Richard

Amy Fowler

>
>So... the Link might act as a model for JXHyperlink?
>
>Richard
>
>
Exactly.
And ideally table/form component code would install a JXHyperlink
as the renderer/control by default when encountering this type.

Aim

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

dhall
Offline
Joined: 2006-02-17

welcome back, Amy

Amy Fowler

jdnc-interest@javadesktop.org wrote:

>welcome back, Amy
>
>
I snuck back in here :-)
I've been a looky-loo on the forum while on leave, but I'm still
getting up to speed on all the progress in the code.

Aim

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Patrick Wright

Jeanette

Very nice overview of what is available.

I agree that an "interactive element that triggers an action to take
us places", by changing a view is a good way to define it. On the
other hand, in HTML, an anchor can have its standard behavior
overridden by assigning an onClick handler, which could do anything,
not just change the view.

So, I'd approach it a little differently, as a sort of 'standard
hyperlink' and 'generalized hyperlink' behavior.

Standard
- single-click triggers the action
- action is related to changing a view component (does this mean
swapping a view, or changing a model? not clear)
- link shows some sort of highlighting behavior on hover, standard is
underlining for text, borders for images (not sure about images...)
- a hyperlink triggers change to a new URL, the target; if the
visitedURLList.contains(targetURL), then we say the target has been
visited. standard hyperlink changes color for visited URLs
- triggered action is immediate, with no prompt for user
- target URL is shown in status bar on hover
- examples: HTML anchors, Windows XP Active Desktop línks

Generalized
- single click trigger
- any Action can be triggered, either changing a view or running some process
- highlighting behavior is customizable
- 'visited' is up to the developer to define; might mean "URL has been
seen before", might mean "action has been triggered already"
- triggered action may prompt the user
- example: hyperlink controls in Norton Antivirus--for example, a scan
can be launched using a hyperlink

The Standard HL might have some interface for triggering a change to a
view--you could pass in an interface, the target URL, and some other
(optional) interface for visited links. But not sure how we generalize
"change the view contents".

I would probably approach this by having a Generalized HL with more
configurable behavior (for rollover, for visited()), maybe as an
abstract subclass of AbstractButton, and then a StandardHL that
auto-underlines, takes a URL as a parameter...

Sorry, thoughts aren't complete.
Patrick

---------------------------------------------------------------------
To unsubscribe, e-mail:
jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Kleopatra

Patrick,

[..thoughts ..]
>
> Sorry, thoughts aren't complete.

Thanks, every single piece fill's the puzzle ;-) Just want to let you
know, that I will have a very close look later on, don't have the time
right now, sorry.

Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Kleopatra

Wow, the thread is getting interesting - moving from technicalities to
functionality ;-)

Thinking aloud - there are new aspects:

a) a hyperlink is a interactive component (most likely but not
necessarily a special kind of button) which triggers "take us places" -
showing/opening other views.

b) there's already some support for treating hyperlinks in the text
package (of all places, sigh...)

Trying to summarize what we have:

Link - a dumb data class wrapping properties
* text - the description appearing in the clickable item
* url - the "place" to take us
* target - additional info about how/where to show the "place"
* visited - a flag to mark if we have been there

LinkHandler - a Mouse/Motion/Listener massaging a Link
* detects Link objects in observed components
* (cell) entered/exited behaviour for JXTable
* tries to show the "place" described by a Link - currently delegates to
Application.showDocument
* marks the Link as visited - doesn't care if the visit was successful
or not

JXTable.LinkRenderer - a renderer for showing Link objects in a table,
aware of
* visited - used for setting the color
* url - used for tooltip
* text - used for showing in cell, the text is underlined unconditionally

Application.showDocument - a method to view the "place"
* takes an Url and a target and tries to delegate to AppletContext,
WebbrowserContext or default platform browser, depending on context
* does not return success (?)

J(X)Hyperlink - a component to visually mimic a hyperlink and triggering
an arbitrary action
* text, icon, tooltip
* mouseEntered/Exited behaviour (cursor, underline)
* visited - unconditionally set after mouseClicked/actionPerformed
* hidden - flag to hide underline

JXHyperlinkDemo - a demo to showcase how to add actionListeners to go
"places" - using external components. In those actionListeners clients
have to provide
* the url to go to
* the component (JEditorPane, JOptionDialog) to show the target content

HtmlEditorKit.LinkController - a Mouse/Motion/Listener on a JEdtiorPane,
creating HyperlinkEvents on enter/exit/activate of an anchor element

HyperLinkEvent/-Listener - transporting events with properties
* type - entered/exited/activated
* url - the "place" to go
* description - ?

Anything I missed?

Even it not, there are quite a lot of differences: visuals, dynamics and
behaviour distributed all over the code. Trying some grouping:

Visual properties driven by Link properties: text, icon, url (=
tooltip), visited
Visual properties driven by user interaction: rollover effects
behaviour: recognize a "activating" user gesture, visit the new "place"

Some additional requirements:
* all low-level user interaction events (mouse, keyboard, alternative
input devices) must be covered,
* the "visit" behaviour should be customizable, pluggable
* the "visited" property should depend on success of the visit
* the hyperlink component should be usable both standalone and as a
renderer
* ??

Okay, back to coding - thanks for listening to my musing

Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Shai Almog

I agree with everything and mostly with these points you mentioned:

>
> Some additional requirements:
> * all low-level user interaction events (mouse, keyboard, alternative
> input devices) must be covered,
> * the "visit" behaviour should be customizable, pluggable
> * the "visited" property should depend on success of the visit
> * the hyperlink component should be usable both standalone and as a
> renderer
> * ??
>

One thing I think we both agree on but wasn't clear from your mail. The link
in the text package is completely different from JXHyperlink in concept.
While they should look the same externally document (html) navigation is
completely different from navigation within the application. That is why I
think a button would be the best approach.
However, since a button has no idea about its usage it can't tell whether
the visit to the next page was successful since any one of N action
listeners can cause the actual navigation and they don't have any way to
indicate failure (other than an exception which IMO will break some of the
event handling contract so its probably not a good idea).

In my earlier frameworks I played with many concepts and most of the
frameworks formed a hybrid of document based applications together with
typical Swing MVC. So I had the concept of a set of documents (which is a
"Form"/"Page" in the application) through which I can navigate and into
which I can embed elements. JDNC has some of these concepts but I didn't
notice anything regarding navigation between documents. This will probably
be very useful for the XML based UI since these concepts work very well
together, but I digress ;)

--
Shai Almog
vPrise Consulting
http://www.vprise.com/
[att1.html]

Patrick Wright

Shai

> However, since a button has no idea about its usage it can't tell whether
> the visit to the next page was successful since any one of N action
> listeners can cause the actual navigation and they don't have any way to
> indicate failure (other than an exception which IMO will break some of the
> event handling contract so its probably not a good idea).

I'm now starting to wonder if this visited behavior is necessary for
non-HTML contexts. Does anyone have an example of a UI that uses
hyperlinks for navigation in a rich client, and which shows visited
links differently? Windows XP doesn't do this, neither does Norton
(two UIs easy for me to reference at the moment).

If we have a method wasTriggered(Action), defaulting to true, then the
default behavior could be to show no change for 'visited' locations.

We could also make it act like a toggle, as Jeanette seemed to
suggest--the first time the user uses it, it flips to 'visited' (or
'triggered')--but this doesn't preserve tracking across application
invocations.

Anyway, this could be treated more along the lines of a standard
button or menu item, which just launch some action; except, in this
case, there's a specific UI rollover effect that is interesting.

Patrick

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Shai Almog

I like the visited funcitionality ;)
Its very powerful and it doesn't need to be persistent across application
invocations. It allows me to immediately see where I've been in an
application and to where I'm going... By the time I invoke the application
the second time I'm already familiar with it and I don't need the "visited"
to learn the application but with my terrible memory it helps me recall what
I did.

Even if others didn't do it I still think its a good idea to incorporate
something like this.

--
Shai Almog
vPrise Consulting
http://www.vprise.com/
[att1.html]

Kleopatra

Richard Bair wrote:
>
> Not that I remember. I made that decision about 1 1/2 - 2 years ago, and
> don't really remember all of the reasoning. Probably because at the time I
> didn't grok UI delegates and so getting the right LAF for different
> platforms was a non-issue by using a JLabel, whereas with a JButton I'd have
> to remove borders, change depress behavior, etc.
>
> It seemed like a tossup -- by Extending JLabel I'd have to add features, by
> extending JButton I'd have to remove features.
>

Yeah, I don't like to tweak UI delegates - but on the other hand a
hyperlink has the functionality and the feel of a button. And we don't
have to do the ui details ourselves - I think for divers lfs they are
basically already done in the JLinkButton.

Frederic, would it be possible (or better: at what costs) to make the
JLinkButton optionally look like a "real" hyperlink? With that
un-ergonomic blue text?

Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Patrick Wright

Has someone written up a description of the desired behavior for the
hyperlinks? In traditional hyperlinks, in early HTML and still on many
web pages, there is
- underline in a given color if visited and not visited
- no change on rollover or hover
- some action that takes place on click

Second generation hyperlinks added some effects on rollover--change of
background color, border, appearance is sunk or raised, etc.

What are we trying to achieve? We need an action associated with the
thing on single-click, to be sure, and maybe some way to track "I've
been clicked once already", plus maybe a disabled state (although in
HTML this is not really possible, you just don't make the text an
anchor).

Buttons have a 'raised' and 'depressed' look, but what else? What
advantages do they give us? It seems if you're going to use a button
you basically want some effect on rollover, maybe a default underlined
style, and maybe a state of "visited" or "not visited" and color
change to match.

Either a label or a button can have an icon, so that's not the
distinguishing feature.

What's the goal here?
Patrick

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Kleopatra

Patrick,

I agree that we need some kind of spec for this (or every other)
component - ideally

To me the striking difference between a Label and a Button is that the
former is not designed for user-interaction whereas interaction is the
very essence of the latter. A hyperlink as well is meant for interaction
- starting from a label we would have to add behaviour and in the end be
very near to a button.

Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Patrick Wright

Jeanette

On 5/13/05, Kleopatra wrote:
> Patrick,
>
> I agree that we need some kind of spec for this (or every other)
> component - ideally

I wonder what the low-overhead way of accomplishing that is. Wiki?
Would be nice to use or paste the 'final' specs into the JavaDocs
somehow.

>
> To me the striking difference between a Label and a Button is that the
> former is not designed for user-interaction whereas interaction is the
> very essence of the latter. A hyperlink as well is meant for interaction
> - starting from a label we would have to add behaviour and in the end be
> very near to a button.

That makes sense--but in the default case, we need to remove both the
button's border and the button's "animation" (for lack of a better
word) when it is depressed. Then it seems more like a label.

But I think you're right. One can make a label listen to events, but
it's a little bit weird; seems to make more sense that a label is just
an inactive, non-interactive element.

Should this be an AbstractButton or a JButton?

Patrick

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Kleopatra

Patrick Wright wrote:
>
> I wonder what the low-overhead way of accomplishing that is. Wiki?
> Would be nice to use or paste the 'final' specs into the JavaDocs
> somehow.

good points - currently the few we have are scattered: Hans has started
a nice J*Table spec in his incubator doc section, and the other one is a
the TreeTable spec in swingx. Hmm ...

>
> That makes sense--but in the default case, we need to remove both the
> button's border and the button's "animation" (for lack of a better
> word) when it is depressed. Then it seems more like a label.
>
> But I think you're right. One can make a label listen to events, but
> it's a little bit weird; seems to make more sense that a label is just
> an inactive, non-interactive element.
>
> Should this be an AbstractButton or a JButton?
>

Currently there are two implementations extending JButton in the
incubator - JHyperlink from Shai and JLinkButton from Frederick (which
is not exactly designed as a "hyper" link - but maybe can be configured
as such, don't know for sure).

Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Richard Bair

>>That makes sense--but in the default case, we need to remove both the
>>button's border and the button's "animation" (for lack of a better
>>word) when it is depressed. Then it seems more like a label.
>>
>>But I think you're right. One can make a label listen to events, but
>>it's a little bit weird; seems to make more sense that a label is just
>>an inactive, non-interactive element.
>>
>>Should this be an AbstractButton or a JButton?
>>
>
>Currently there are two implementations extending JButton in the incubator
>- JHyperlink from Shai and JLinkButton from Frederick (which is not exactly
>designed as a "hyper" link - but maybe can be configured as such, don't
>know for sure).

Note: Not defending "my baby" -- real technical questions follow ;)

I talked with Scott about this, his take was that extending JLabel felt
cleaner to him since the AbstractButton had functionality (and a
ButtonModel) that you probably didn't really want. This was just his first
impression. The idea was that we wanted some button-like functionality, but
not really a button.

My take would be that a good look should be taken at AbstractButton. If it
has functionality that doesn't apply to hyperlinks, then it makes sense to
extend JLabel. Otherwise, we should extend AbstractButton. I don't think we
should extends Button (borders, ui delegates and all that nonsense :)).

Richard

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Kleopatra

Morning, Richard

>
> Note: Not defending "my baby" -- real technical questions follow ;)

>
> I talked with Scott about this, his take was that extending JLabel felt
> cleaner to him since the AbstractButton had functionality (and a
> ButtonModel) that you probably didn't really want. This was just his first
> impression. The idea was that we wanted some button-like functionality, but
> not really a button.
>

I see the point - only I don't follow it: besides being designed for
interaction a button is Action-aware out-of-the box. That is, it will
configure itself from the action set (you duplicated that in your code)
_and_ guarantees to stay synched with Action properties -
enable/disable or localized text synch will be for free. Plus we could
enhance the synch with custom properties like visited - that's Link
model state which is not for the view to decide

Have a nice day, I'm hungry as a wolf
Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

l2fprod
Offline
Joined: 2003-06-10

Extending AbstractButton/JButton looks more natural than adding action listener capability to JLabel. JButton has all of JLabel plus the action mechanism, rollover,...

One comment though. In one forum post about JXHyperlink, there was a reference to Eclipse and how its developers have started to use hyperlinks instead of buttons (http://www.javalobby.org/java/forums/m91832981.html). But in Eclipse, these hyperlinks are inline with the text. If I'm correct we already have this in Swing, this is the JEditorPane and its hyperlinklistener. One can use html text and react when "a" tags are clicked. Something to consider when working on the JXHyperlink, no?

-fred

Shai Almog

Didn't check GMail for a day and the thread is just huge ;)

I thought about this further and extending AbstractButton seems to me to be
the most sensible approach. Since menu items, radio buttons, checkboxes,
toggle buttons and regular buttons are all AbstractButton and all very
different from one another I don't see a reason for hyperlink to become
something else. This maintains consistency with the way Swing chose to
implement these things, there are many functions for accessibility/keyboard
navigation and i18n that might not be immediately apparent with the JLabel.

BTW the way in which the hyperlink line is drawn under the text doesn't work
well on my machine (even in the original JLable button) so I'm not really
concerned about L&F related issues... They will bite us regardless of the
implementation ;(
Since neither JLabel nor JButton have true support for underlining (I toyed
with the idea of using HTML to do the underlining but it would screw up the
fonts on the button), then the only solution is to write a UI class to
handle this class only and prevent the PLAF from changing the look and feel
(so the UI should "know" some existing looks).

--
Shai Almog
vPrise Consulting
http://www.vprise.com/
[att1.html]

Kleopatra

>
> 2. I complained about this ages ago but this has become really annoying.
> Someone placed a pack() call is JXFrame setVisible... This is REALLY bad
> for any application that wants to persist its size and position. Pack
> produces a huge window with my UI... There has to be a way to remove
> this, I would just avoid JXFrame but I want the status bar ;)

removed (could not find a complaint in the form of an issue, though ;-)

Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

rbair
Offline
Joined: 2003-07-08

> Anyway Richard I recall you had great code for
> persisting Window positions
> and I see some of it in SwingX why not place the code
> to persist the Window
> positions into the java.util.prefs repository into
> the WindowUtils class and
> remove the pack() call?

That would be a really good idea. One problem I have yet to resolve is that a key for preferences cannot exceed 80 characters, but the algorithm I was using for the keys was to, for example with JXFrame, do this;

key = org.jdesktop.JXFrame.width
value = 100

etc. This breaks down for big component hierarchies. The better (though more difficult to navigate with a viewer) solution is to create a key for each part of the package name and then at the very end have a series of prefs.

Anyway, the point is that it should be very, very easy to move this stuff into SwingX and would give us a lot of bang for the buck, I think.

Jeanette, have you had a looksee at this code? I'll post some here if you'd like to discuss it.

Richard

Kleopatra

Hi Richard,

overlooked this message until now ...

>
> Jeanette, have you had a looksee at this code?

"this" being the WindowUtils? No, it's nowhere near my priority list ;-)

Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Kleopatra

Shai Almog wrote:

> 1. The hyperlink doesn't respect enabled/disabled state correctly and
> doesn't mutate when the action to which it is bound is modified. I
> looked into the code and it seems to me that it is a mistake to base
> this widget on a label rather than on an abstract button. So I placed
> into my incubator directory (vprise/candy) a JHyperlink class that looks
> exactly the same but is based on JButton and thus has better support for
> lots of the features that abstract button brings to the table.

I have been slightly wondering about the same - my preference would be
to start with JButton. Will check your version soon. Note that there's a
JLinkButton in the l2fprod section of the incubator - comming very
nicely with an uidelegate, that's how I like lf specifics to be handled.

> Is there a reason I can't see for choosing JLabel?

good question - Richard?

>
> 2. I complained about this ages ago but this has become really annoying.
> Someone placed a pack() call is JXFrame setVisible... This is REALLY bad
> for any application that wants to persist its size and position. Pack
> produces a huge window with my UI... There has to be a way to remove
> this, I would just avoid JXFrame but I want the status bar ;)

I absolutely agree - pack has nothing to do in setVisible, probably an
oversight ;-)

Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Richard Bair

>>1. The hyperlink doesn't respect enabled/disabled state correctly and
>>doesn't mutate when the action to which it is bound is modified. I looked
>>into the code and it seems to me that it is a mistake to base this widget
>>on a label rather than on an abstract button. So I placed into my
>>incubator directory (vprise/candy) a JHyperlink class that looks exactly
>>the same but is based on JButton and thus has better support for lots of
>>the features that abstract button brings to the table.
>
>I have been slightly wondering about the same - my preference would be to
>start with JButton. Will check your version soon. Note that there's a
>JLinkButton in the l2fprod section of the incubator - comming very nicely
>with an uidelegate, that's how I like lf specifics to be handled.
>
>>Is there a reason I can't see for choosing JLabel?
>
>good question - Richard?

Not that I remember. I made that decision about 1 1/2 - 2 years ago, and
don't really remember all of the reasoning. Probably because at the time I
didn't grok UI delegates and so getting the right LAF for different
platforms was a non-issue by using a JLabel, whereas with a JButton I'd have
to remove borders, change depress behavior, etc.

It seemed like a tossup -- by Extending JLabel I'd have to add features, by
extending JButton I'd have to remove features.

Richard

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Shai Almog

I guess this makes sense, I didn't verify my implementation under all
conditions and currently only tested it on Linux with ocean. If my
implementation isn't as robust as I hope is it possible to combine an
implementation that is still based on an abstract button but uses the JLabel
for rendering?

Not that I remember. I made that decision about 1 1/2 - 2 years ago, and
> don't really remember all of the reasoning. Probably because at the time I
> didn't grok UI delegates and so getting the right LAF for different
> platforms was a non-issue by using a JLabel, whereas with a JButton I'd
> have
> to remove borders, change depress behavior, etc.
>
> It seemed like a tossup -- by Extending JLabel I'd have to add features,
> by
> extending JButton I'd have to remove features.
>
> Richard
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>
>

--
Shai Almog
vPrise Consulting
http://www.vprise.com/
[att1.html]

Richard Bair

>I guess this makes sense, I didn't verify my implementation under all
>conditions and currently only tested it on Linux with ocean. If my
>implementation isn't as robust as I hope is it possible to combine an
>implementation that is still based on an abstract button but uses the
>JLabel
>for rendering?

I think it would be easier to add the functionality to JLabel rather than
try to merge the two. What functionality is currently missing?
Enabled/disable, i18n, etc? It should be really easy to add that stuff since
it is not LAF dependent.

Richard

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net