Hello!
I am now beginning to see what is happening here. You are refactoring
out the job handling code.
Once the infrastructure for this (i.e. the new subsystem) is in place,
we should then move the job handling part from the Critics to this too.
Please make sure that the new API will work well with the Eclipse job
handling/progress monitor things so that it will become an easy adaptor
in that case.
/Linus
> -----Original Message-----
> From: Luis Sergio Oliveira [mailto:[EMAIL PROTECTED]
> Sent: den 29 april 2007 00:25
> To: [email protected]
> Subject: Re: [argouml-dev] In which package does ProgressMonitor
belong?
> GUI?
>
> Hello Michiel,
>
> Michiel van der Wulp wrote:
> > Hi Luis,
> >
> > Thanks for this explanation. You are right, ProgressMonitor does not
> > belong in the GUI subsystem.
> >
> > Instead, is adds some functionality that may be used by any other
> > subsystem of ArgoUML.
> > Hence it belongs in a subsystem where others can use it, IIUC a low
> > level subsystem (since it does not depend on any other ArgoUML
> > subsystem).
> >
> > We do currently not have a low level subsystem suitable for the
> > ProgressMonitor, the nearest thing is org.argouml.swingext.
> > (Remember, a low level subsystem is defined in the cookbook as a
> > subsystem that does not depend on any other ArgoUML subsystem.)
> >
> > So, either (A) I make a new low level subsystem
> > org.argouml.progressmonitor, or (B) rename its current package
> > (org.argouml.swingext) to something like org.argouml.lowlevel.
> >
> > Any thoughts?
> > My vote is on A.
> Hmmm, I think the abstraction were talking about here is related to
> monitoring the progress of a long running
> task. This kind of thing is normally related to the concept of Task,
Job
> or Request [my preference is for task].
>
> Normally we have several concepts and utilities associated with it:
> Task
> TaskQueue
> ProgressMonitor
> TaskManager
> related exceptions - TaskFailure, TaskTimeout
>
> So, I propose org.argouml.taskmgmt for TaskManagement. But, maybe I'm
> thinking way on advance of the current evolution
> of the code/concept.
>
> If you don't like my idea, I'm for A.
>
> Regards,
>
> Luis
> >
> > Regards,
> > Michiel
> >
> >
> > ----- Original Message ----- From: "Luis Sergio Oliveira"
> > <[EMAIL PROTECTED]>
> > To: <[email protected]>
> > Sent: Saturday, April 28, 2007 4:32 PM
> > Subject: Re: [argouml-dev] In which package does ProgressMonitor
> > belong? GUI?
> >
> >
> > Hello Michiel,
> >
> > Michiel van der Wulp wrote:
> >> Hi Tom, et al.,
> >>
> >> Tom said:
> >> < Having the ProgressMonitor interface reside in the
> >> org.argouml.swingext
> >> package is very misleading since it's entire purpose in life is to
> >> decouple
> >> ArgoUML from a hard dependency on javax.swing.ProgressMonitor
(which
> >> is what was used originally). It is specifically intended to be
> >> independent of Swing and SWT.>
> >>
> >> Agreed - I did not know this.
> >> My intention was to rename org.argouml.swingext to something
broader,
> >> e. g. org.argouml.javaext - but I am not so happy with this name.
> >> Maybe the ProgressMonitor stuff belongs in the GUI subsystem (if
you
> >> follow the cookbook) - but I fear that the description of this
> >> subsystem in the cookbook is not correct - it should not be placed
as
> >> a "low level subsystem", since then it may not depend on other "low
> >> level" subsystems, which it does.
> >>
> > I see a ProgressMonitor as part of something which isn't necessarily
> > part of a GUI concept.
> >
> > Consider:
> > SomethingA needs a long running service from SomethingB. So,
SomethingA
> > decides to ask
> > for it in a different Thread of execution and to monitor the
progress of
> > the task in its main
> > thread.
> >
> > The reason why it monitors the progress could be because it wants to
> > show feedback to the
> > user via the GUI, but, it could be in order to decide that if there
is
> > no progress, it should give up
> > by interrupting its other Thread.
> >
> > Besides, even if this is only something useful for the user it
doesn't
> > necessarily needs to be GUI.
> > We might want to reuse the reveng functionalities of ArgoUML some
day
> > without any GUI, simply
> > as batch task automated from an Ant file.
> >
> > Regards,
> >
> > Luis
> >> Regards,
> >> Michiel
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
