Re: [JPP-Devel] Question about TaskMonitorDialog, ThreadedPlugIn, and Threads in OpenJUMP
For customizing the TaskMonitorDialog the source code of a plugin could look
like this:
class HelloProgressPlugIn extends AbstractPlugIn implements ThreadedPlugIn {
void initialize(PlugInContext pluginContext) {}
boolean execute(PlugInContext pluginContext) {
return true
}
void run(TaskMonitor monitor, PlugInContext context) {
Thread.sleep(2000)
}
TaskMonitorDialog getTaskMonitorDialog() {
// return customized taskmonitordialog.
}
}
Then in TaskMonitorManager.execute() it asks HelloProgressPlugIn for a
TaskMonitorDialog using HelloProgressPlugIn.getTaskMonitorDialog() and sends
it to the constructor of TaskWrapper.
TaskWrapper itself calls the run()-method of plugin (i.e. HelloPressPlugIn).
This is my basic idea. Have to test this, whether it's feasible. Maybe I
have some time later this week.
Here again an excerpt of the call hierarchy for AbstractPlugIn.
=== AbstractPlugIn.toActionListener() ===
boolean executeComplete = plugIn.execute(plugInContext);
if (plugIn instanceof ThreadedPlugIn executeComplete) {
taskMonitorManager.execute((ThreadedPlugIn) plugIn, plugInContext);
}
=== TaskMonitorManager.execute() ===
final TaskWrapper taskWrapper = new TaskWrapper(plugIn, context,
progressDialog);
=== TaskWrapper.run() ===
plugIn.run(dialog, context);
--Benjamin
2009/12/30 Sunburned Surveyor sunburned.surve...@gmail.com
It's been a while since I posted that thread, and I'm afraid I don't
remember all of the details that made me ask the questions. I know I
definitely had concerns about adding layers inside a thread. It still
seems to me that this would trigger painting of the LayerViewPanel.
When this repainting is triggered, does it occur on the AWT Event
Dispatch Thread, or withing the thread that added the layer? If the
latter is true, we could run into threading problems.
I never did get a good solution to my problem. I think I ended up not
displaying a progress bar. I would like to revisit the issue at some
point.
Benjamin: Did you find a solution for your particular case? If not, I
would be interested in discussing the situation with you so I could
explore some solutions.
The Sunburned Surveyor
On Thu, Dec 10, 2009 at 10:27 AM, Stefan Steiniger sst...@geo.uzh.ch
wrote:
Hei
Benjamin Gudehus wrote:
Hi!
PS: Who send the first message? I did not get it.
I found the first message here:
http://www.mail-archive.com/jump-pilot-devel@lists.sourceforge.net/msg06770.html
aha.. thanks. I was traveling in August - that's why I did not know it.
But its quite funny that Landon asked that. because the plugins I write
contain text from Jon, which says what is happening, and the wiki has
those infos too.
you know that this is possible using
* monitor.report(computing feature + count + of +
numFeatures);
I already implemented my plugin using monitor.report(). But after run()
finished the dialog disappears. I also want to customize it, to show a
nice progress bar (JProgressBar).
Maybe I try to make TaskMonitorManager more flexible, thus one can use
customized dialogs for run(). I have some experience with testing
threads and swing. I suppose some tests would be very useful.
ah good.. go ahead! Useful extensions are always welcome.
my experiences are rather in GIS algorithms. Threading is a black box to
me :) Though Sascha Teichman did know quite a bit, but he hasn't written
since they got this new project a year ago.
--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and
easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev ___
Jump-pilot-devel mailing list
Re: [JPP-Devel] Question about TaskMonitorDialog, ThreadedPlugIn, and Threads in OpenJUMP
I forgot to mention, that if no getTaskMonitorDialog() is provided by the
PlugIn, the default TaskMonitorDialog is used.
2010/1/12 Benjamin Gudehus hasteb...@googlemail.com
For customizing the TaskMonitorDialog the source code of a plugin could
look like this:
class HelloProgressPlugIn extends AbstractPlugIn implements ThreadedPlugIn
{
void initialize(PlugInContext pluginContext) {}
boolean execute(PlugInContext pluginContext) {
return true
}
void run(TaskMonitor monitor, PlugInContext context) {
Thread.sleep(2000)
}
TaskMonitorDialog getTaskMonitorDialog() {
// return customized taskmonitordialog.
}
}
Then in TaskMonitorManager.execute() it asks HelloProgressPlugIn for a
TaskMonitorDialog using HelloProgressPlugIn.getTaskMonitorDialog() and sends
it to the constructor of TaskWrapper.
TaskWrapper itself calls the run()-method of plugin (i.e.
HelloPressPlugIn).
This is my basic idea. Have to test this, whether it's feasible. Maybe I
have some time later this week.
Here again an excerpt of the call hierarchy for AbstractPlugIn.
=== AbstractPlugIn.toActionListener() ===
boolean executeComplete = plugIn.execute(plugInContext);
if (plugIn instanceof ThreadedPlugIn executeComplete) {
taskMonitorManager.execute((ThreadedPlugIn) plugIn, plugInContext);
}
=== TaskMonitorManager.execute() ===
final TaskWrapper taskWrapper = new TaskWrapper(plugIn, context,
progressDialog);
=== TaskWrapper.run() ===
plugIn.run(dialog, context);
--Benjamin
2009/12/30 Sunburned Surveyor sunburned.surve...@gmail.com
It's been a while since I posted that thread, and I'm afraid I don't
remember all of the details that made me ask the questions. I know I
definitely had concerns about adding layers inside a thread. It still
seems to me that this would trigger painting of the LayerViewPanel.
When this repainting is triggered, does it occur on the AWT Event
Dispatch Thread, or withing the thread that added the layer? If the
latter is true, we could run into threading problems.
I never did get a good solution to my problem. I think I ended up not
displaying a progress bar. I would like to revisit the issue at some
point.
Benjamin: Did you find a solution for your particular case? If not, I
would be interested in discussing the situation with you so I could
explore some solutions.
The Sunburned Surveyor
On Thu, Dec 10, 2009 at 10:27 AM, Stefan Steiniger sst...@geo.uzh.ch
wrote:
Hei
Benjamin Gudehus wrote:
Hi!
PS: Who send the first message? I did not get it.
I found the first message here:
http://www.mail-archive.com/jump-pilot-devel@lists.sourceforge.net/msg06770.html
aha.. thanks. I was traveling in August - that's why I did not know it.
But its quite funny that Landon asked that. because the plugins I write
contain text from Jon, which says what is happening, and the wiki has
those infos too.
you know that this is possible using
* monitor.report(computing feature + count + of +
numFeatures);
I already implemented my plugin using monitor.report(). But after run()
finished the dialog disappears. I also want to customize it, to show a
nice progress bar (JProgressBar).
Maybe I try to make TaskMonitorManager more flexible, thus one can use
customized dialogs for run(). I have some experience with testing
threads and swing. I suppose some tests would be very useful.
ah good.. go ahead! Useful extensions are always welcome.
my experiences are rather in GIS algorithms. Threading is a black box to
me :) Though Sascha Teichman did know quite a bit, but he hasn't written
since they got this new project a year ago.
--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and
easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app
Re: [JPP-Devel] Question about TaskMonitorDialog, ThreadedPlugIn, and Threads in OpenJUMP
It's been a while since I posted that thread, and I'm afraid I don't remember all of the details that made me ask the questions. I know I definitely had concerns about adding layers inside a thread. It still seems to me that this would trigger painting of the LayerViewPanel. When this repainting is triggered, does it occur on the AWT Event Dispatch Thread, or withing the thread that added the layer? If the latter is true, we could run into threading problems. I never did get a good solution to my problem. I think I ended up not displaying a progress bar. I would like to revisit the issue at some point. Benjamin: Did you find a solution for your particular case? If not, I would be interested in discussing the situation with you so I could explore some solutions. The Sunburned Surveyor On Thu, Dec 10, 2009 at 10:27 AM, Stefan Steiniger sst...@geo.uzh.ch wrote: Hei Benjamin Gudehus wrote: Hi! PS: Who send the first message? I did not get it. I found the first message here: http://www.mail-archive.com/jump-pilot-devel@lists.sourceforge.net/msg06770.html aha.. thanks. I was traveling in August - that's why I did not know it. But its quite funny that Landon asked that. because the plugins I write contain text from Jon, which says what is happening, and the wiki has those infos too. you know that this is possible using * monitor.report(computing feature + count + of + numFeatures); I already implemented my plugin using monitor.report(). But after run() finished the dialog disappears. I also want to customize it, to show a nice progress bar (JProgressBar). Maybe I try to make TaskMonitorManager more flexible, thus one can use customized dialogs for run(). I have some experience with testing threads and swing. I suppose some tests would be very useful. ah good.. go ahead! Useful extensions are always welcome. my experiences are rather in GIS algorithms. Threading is a black box to me :) Though Sascha Teichman did know quite a bit, but he hasn't written since they got this new project a year ago. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Question about TaskMonitorDialog, ThreadedPlugIn, and Threads in OpenJUMP
Hi! PS: Who send the first message? I did not get it. I found the first message here: http://www.mail-archive.com/jump-pilot-devel@lists.sourceforge.net/msg06770.html you know that this is possible using * monitor.report(computing feature + count + of + numFeatures); I already implemented my plugin using monitor.report(). But after run() finished the dialog disappears. I also want to customize it, to show a nice progress bar (JProgressBar). Maybe I try to make TaskMonitorManager more flexible, thus one can use customized dialogs for run(). I have some experience with testing threads and swing. I suppose some tests would be very useful. 2009/12/9 Stefan Steiniger sst...@geo.uzh.ch BTW: I'm currently trying to modify the TaskMonitorDialog to show a progressbar with addional information. you know that this is possible using * monitor.report(computing feature + count + of + numFeatures); I also use often the following option to send messages during processing (though not the best way - but ok for my purposes): * context.getWorkbenchFrame().warnUser(no point dataset); * context.getWorkbenchFrame().setTimeMEssage(blabla); stefan PS: Who send the first message? I did not get it. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Question about TaskMonitorDialog, ThreadedPlugIn, and Threads in OpenJUMP
Hei Benjamin Gudehus wrote: Hi! PS: Who send the first message? I did not get it. I found the first message here: http://www.mail-archive.com/jump-pilot-devel@lists.sourceforge.net/msg06770.html aha.. thanks. I was traveling in August - that's why I did not know it. But its quite funny that Landon asked that. because the plugins I write contain text from Jon, which says what is happening, and the wiki has those infos too. you know that this is possible using * monitor.report(computing feature + count + of + numFeatures); I already implemented my plugin using monitor.report(). But after run() finished the dialog disappears. I also want to customize it, to show a nice progress bar (JProgressBar). Maybe I try to make TaskMonitorManager more flexible, thus one can use customized dialogs for run(). I have some experience with testing threads and swing. I suppose some tests would be very useful. ah good.. go ahead! Useful extensions are always welcome. my experiences are rather in GIS algorithms. Threading is a black box to me :) Though Sascha Teichman did know quite a bit, but he hasn't written since they got this new project a year ago. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Question about TaskMonitorDialog, ThreadedPlugIn, and Threads in OpenJUMP
OK, I figured out this call hierarchy for
* execute() (in AbstractPlugIn.toActionListener()) and
* run() (in TaskWrapper.run()).
=== FeatureInstaller.addMainMenuItem() ===
public void addMainMenuItem(PlugIn executable, String[] menuPath,
String menuItemName, boolean checkBox, Icon icon, EnableCheck
enableCheck) {}
=== FeatureInstaller.associate() ===
private void associate(JMenuItem menuItem, PlugIn plugIn) {
menuItem.addActionListener(AbstractPlugIn.toActionListener(plugIn,
workbenchContext, taskMonitorManager));
}
=== AbstractPlugIn.toActionListener() ===
boolean executeComplete = plugIn.execute(plugInContext);
if (plugIn instanceof ThreadedPlugIn executeComplete) {
taskMonitorManager.execute((ThreadedPlugIn) plugIn, plugInContext);
}
=== TaskMonitorManager.execute() ===
final TaskWrapper taskWrapper = new TaskWrapper(plugIn, context,
progressDialog);
=== TaskWrapper.run() ===
plugIn.run(dialog, context);
2009/12/9 Benjamin Gudehus hasteb...@googlemail.com
Hi!
I'm trying to figure out how to separate the code by putting the one
task in the execute method and the other task in the run method, but I
can't find a solution yet. (I need to determine the relationship
between the execute and run method. The Javadoc doesn't seem to
indicate when the two methods are invoked in relation to each other.
Is execute called first, and followed immediately by the run method?
Must I call explicitly call the run method from within the execute
method?)
If execute() returns true, the run() method is called in a separate
thread.
Some plugins use the execute() method to show a dialog and if the user
clicks
on ok, true is returned from execute() and run() method is called.
class HelloProgressPlugIn extends AbstractPlugIn implements ThreadedPlugIn
{
void initialize(PlugInContext pluginContext) {}
boolean execute(PlugInContext pluginContext) {
println execute
return true
}
void run(TaskMonitor monitor, PlugInContext context) {
println run
Thread.sleep(2000)
}
}
During the execution of run() a dialog (TaskMonitorDialog) is displayed,
one can send
progress messages using monitor.progress() to the dialog. Only if the
plugin is implementing
ThreadedPlugIn (i.e. the run() method) this dialog is displayed.
BTW: I'm currently trying to modify the TaskMonitorDialog to show a
progressbar with addional information.
An optional message dialog, displayed after run() is finished, would also
be great. StandardPirolPlugIn
is implementing something like that.
Some code snippets are welcome! This also fits with [JPP-Devel] More
code-examples? ;)
I have no clue about changing the taskmonitor within run(). So I trying to
find the class, which
calls execute() and run().
Greetings from Hanover!
--Benjamin
--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
[JPP-Devel] Question about TaskMonitorDialog, ThreadedPlugIn, and Threads in OpenJUMP
Hi!
I'm trying to figure out how to separate the code by putting the one
task in the execute method and the other task in the run method, but I
can't find a solution yet. (I need to determine the relationship
between the execute and run method. The Javadoc doesn't seem to
indicate when the two methods are invoked in relation to each other.
Is execute called first, and followed immediately by the run method?
Must I call explicitly call the run method from within the execute
method?)
If execute() returns true, the run() method is called in a separate thread.
Some plugins use the execute() method to show a dialog and if the user
clicks
on ok, true is returned from execute() and run() method is called.
class HelloProgressPlugIn extends AbstractPlugIn implements ThreadedPlugIn {
void initialize(PlugInContext pluginContext) {}
boolean execute(PlugInContext pluginContext) {
println execute
return true
}
void run(TaskMonitor monitor, PlugInContext context) {
println run
Thread.sleep(2000)
}
}
During the execution of run() a dialog (TaskMonitorDialog) is displayed, one
can send
progress messages using monitor.progress() to the dialog. Only if the plugin
is implementing
ThreadedPlugIn (i.e. the run() method) this dialog is displayed.
BTW: I'm currently trying to modify the TaskMonitorDialog to show a
progressbar with addional information.
An optional message dialog, displayed after run() is finished, would also be
great. StandardPirolPlugIn
is implementing something like that.
Some code snippets are welcome! This also fits with [JPP-Devel] More
code-examples? ;)
I have no clue about changing the taskmonitor within run(). So I trying to
find the class, which
calls execute() and run().
Greetings from Hanover!
--Benjamin
--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Question about TaskMonitorDialog, ThreadedPlugIn, and Threads in OpenJUMP
BTW: I'm currently trying to modify the TaskMonitorDialog to show a progressbar with addional information. you know that this is possible using * monitor.report(computing feature + count + of + numFeatures); I also use often the following option to send messages during processing (though not the best way - but ok for my purposes): * context.getWorkbenchFrame().warnUser(no point dataset); * context.getWorkbenchFrame().setTimeMEssage(blabla); stefan PS: Who send the first message? I did not get it. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
[JPP-Devel] Question about TaskMonitorDialog, ThreadedPlugIn, and Threads in OpenJUMP
Last week I was in the process of wrapping-up my plug-in that allows the user to import survey point data in a text delimited format. I wanted to show the user a progress bar as the data was being loaded. I first attempted to use the TaskMonitorDialog directly, which didn't work very well. (The dialog displayed, but never went away. This was due to an error in my code, no doubt.) So I started digging around to figure out the best way to use the TaskMonitorDialog when loading data into OpenJUMP. The deeper I dug, the more questions I got. I could just write the plug-in without the TaskMonitorDialog, but I would really like to figure this out so I can do things properly. Have you written a plug-in that used the TaskMonitorDialog? Did this plug-in load data into OpenJUMP? Then maybe you can halp me with a couple of questions: When is it OK to use the TaskMonitorDialog class directly? (It looks like existing plug-ins that load data don't do this. Instead, they use an implementation of the ThreadedPlugIn interface. I believe the LoadDataSetPlugIn is an example of this.) I wonder if it is appropriate to use an implementation of ThreadedPlugIn to load data into OpenJUMP in this way. Here is why: Loading data (like the data stored in a shapefile) into OpenJUMP usually involves adding a layer to the active Task and repainting the LayerViewPanel. When we use a ThreadedPlugIn to do this, are we trying to repaint the LayerViewPanel outside of the main Swing thread? In my case it would seem better to load the data from the delimited text file in a separate thread, and then to add the data in a new Layer in part of the main application thread, so as not to mess with Swing. Can I separate the reading of the data from the file and adding the layer by putting separate code in the run and execute methods of the ThreadedPlugIn interface? I'm trying to figure out how to separate the code by putting the one task in the execute method and the other task in the run method, but I can't find a solution yet. (I need to determine the relationship between the execute and run method. The Javadoc doesn't seem to indicate when the two methods are invoked in relation to each other. Is execute called first, and followed immediately by the run method? Must I call explicitly call the run method from within the execute method?) I'm not any good at using Java threads, so I appreciate any suggestions. I will keep digging in the code in an attempt to get some answers. Hopefully I can update the Javadoc comments when I am done. Landon -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
