Due to my E-Mail address giving me a hard time (*why* is it virtually
impossible to maintain a working permanent e-mail address?!?) I can't
reply to the messages directly, but I'll piece this one together with
the help of the archives :)
DigiGod wrote:
> how about: org.jos.tools.actionmanager. I say this because we seem to have
> beans that arent applications and are to big to be called utilities (and
> would only be used by apps
> anyway), so we should put them in tools.
I'm not sure. "Tools" makes me think of user tools, not tools used to build
programs. But maybe that's just me? :) (I'd be happy with it)
>Or you could put it in:
> org.jos.apps.util.actionmanager (or apps.tools)
I'd prefer util.apps in that case (because it's a utility used to build apps).
org.jos.apps should only house actual application IMO, which the
ActionManager isn't.
>. But ui.event.actionmanager
> makes me think of event and listner classes,
> not a toolbar builder
I agree.
Al wrote:
> Yeah, but if it's part of the system really, then is should be in the system
> packages. I would assume that ActionManager would be used by system classes,
> too, right?
As DigiGod correctly pointed out, the ActionManager is not at that "level".
It builds menubars, toolbars and buttons (not, buttons are yet to be
implemented) from a text-based definition. It doesn't do any event handling,
except for those actions created by the action manager (it allows chaning of
event handling code during runtime for example).
Al also wrote:
> Ah, then maybe it should be renamed to GUIGenerator or GUITools or something
> like that?
I'd be happy with an alternative name. I was never satisfied with
"ActionManager", but I couldn't come up with a better name. ActionUtility,
which is pretty good IMO, is already taken :)
As for GUIGenerator or GUITools... Hmm. I'd prefer the former over the
latter, although I don't think neither of them are right on target. But
they're probably better than ActionManager...
Any other suggestions?
I think it would be a good idea of have the name include "action", because
the whole thing is centered around the actions (not the toolbars/menus). It
produces menus, but it's all primarily defined as a collection of actions.
It *could* be extended to support non-graphical user interfaces too. The only
Swing based class that is really *needed*, because of the interface, is the
Action class. The dependency on JMenuBar, JToolBar etc could easily be made
optional (in fact, it already is - you just don't define a MenuBar, and don't
define any icons for the actions).
--
/ Peter Schuller
---
PGP userID: 0x5584BD98 or 'Peter Schuller <[EMAIL PROTECTED]>'
E-Mail: [EMAIL PROTECTED] Web: http://hem.passagen.se/petersch
Help create a free Java based operating system - www.jos.org.
PGP signature
