Re: [JPP-Devel] wishlist
No, the ability to specify readonly is currently only available programatically. My use case was that I wanted to prevent a user to making certain changes to a feature collection. I hadn't considered that a user may want to add this restriction themselves through a user interface. Do you think there is a need? -- Kevin On 9/7/2010 3:40 PM, Sunburned Surveyor wrote: > Kevin, > > This is probably a dumb question, but is there a way to tell OpenJUMP > that a feature attribute is not editable for a layer through the user > interface? > > I was trying to see how I could do this in the dialog that lets you > edit a layer schema in a build from SVN, but couldn't see it. Is this > functionality only accessible programatically right now? > > Thanks, > > The Sunburned Surveyor > > On Wed, Sep 1, 2010 at 8:37 PM, Kevin Neufeld > wrote: > >> That is the thing with opensource development, eh? :) Development >> resources are always tight. >> >> I just added a patch for review to the feature tracker for my primary issue. >> http://sourceforge.net/tracker/index.php?func=detail&aid=3057748&group_id=118054&atid=679909 >> >> The patch >> - adds a readonly attribute to a FeatureSchema attribute >> - uses the attribute in the LayerTableModel to set if a cell is editable >> - shades cells in the AttributeTablePanel that are non-editable to light >> gray. >> >> I don't know what OJ uses for a testing harness, but preliminary testing >> looks good. >> I programmatically added a layer and set one of the schema attributes as >> read-only. >> >> The other issues I mentioned are not a big concern for me at all (just a >> wishlist) and I no plans to address them any time soon. >> >> -- Kevin >> >> >> On 9/1/2010 1:34 PM, Michaël Michaud wrote: >> >>> Hi Kevin >>> >>> All your propositions seem reasonnable and valuable for OpenJUMP. >>> >>> As Stefan said, the main problem is development resources. >>> I cannot evaluate precisely the work to do without a deeper look, but it >>> concerns core classes and will need caution and tests. >>> Are you volonteer to develop these features ? >>> >>> Michaël >>> >>> >>> >>> Le 01/09/2010 20:15, Kevin Neufeld a écrit : >>> >>> >>>> Stefan mentioned that there isn't a road map for OJ, but is there a >>>> place to jot down improvement ideas? >>>> >>>> Here are a couple on my wishlist: >>>> >>>> 1) The ability to specify which columns are editable in an layer's >>>> attribute table. Right now, the FID and geometry column are hard-coded >>>> as being the only columns that are not editable. I would like to see >>>> this driven off the layer's FeatureSchema. Perhaps there could be a >>>> "isAttributeReadOnly(int attributeIndex)" method added to the >>>> FeatureSchema that could be used in LayerTableModel.isCellEditable(int >>>> rowIndex, int columnIndex). >>>> >>>> Primary key attributes that belong to a DynamicFeatureCollection driven >>>> off a database is one example of a non-editable column. >>>> >>>> >>>> 2) The ability to customize the tooltips for previously installed >>>> plugins on a layer's right click context menu. For example, I could >>>> have a custom implementation of a Layer that is backed by a custom >>>> FeatureCollection. If I mark the layer as readonly, the "Editable" menu >>>> item is correctly greyed-out. The tooltip says something like "This >>>> layer cannot be made editable." The menu item is greyed-out ... >>>> obviously it's not editable. I would like to change the tooltip to >>>> explain *why* the menu item is greyed-out ... which is particular to my >>>> custom FeatureCollection. >>>> >>>> IE. >>>> "No Primary Key found on the underlying database table" >>>> "Adhoc queries cannot be made editable" >>>> "SQL Server DataStores cannot currently be made editable" >>>> >>>> >>>> 3) A new UpdatablePlugIn interface with methods like getPluginVersion(), >>>> getPluginURL(). All implementations of the interface could be listed in >>>> the extensions tag in the About window. A user could choose to update a >>>> selected plugin where a new plugin jar a
Re: [JPP-Devel] System.out in code
Hi Landon,
I'm not sure I understand your question, sorry. I'm not suggesting to
expose any method to access logging functionality.
I hope this makes this more clear:
What I'm suggesting is that the 330 calls to System.out currently in src
get cleaned up, replaced with appropriate log4j calls.
ie.
System.out.println("Starting OpenJUMP");
logger.info("Starting OpenJUMP");
System.out.println("Entering my private method");
logger.debug("Entering my private method");
System.out.println("Should never reach here !!!");
logger.fatal("Should never reach here !!!", exception);
Log4j then needs a configuration defined so it knows where to output the
log statements, if at all. This can be done from an xml file specified
from the JVM (which is what is currently done):
-Dlog4j.configuration=file:etc/log4j.xml
or from an xml file specified as a application argument:
import com.foo.Bar;
import org.apache.log4j.Logger;
import org.apache.log4j.DOMConfigurator;
public class MyApp {
static Logger logger = Logger.getLogger(MyApp.class);
public static void main(String[] args) {
// Configure using log4j.xml file
DOMConfigurator.configure(args[0]);
logger.info("Entering application.");
Bar bar = new Bar();
bar.doIt();
logger.info("Exiting application.");
}
}
or programmatically, hard-coded:
import com.foo.Bar;
import org.apache.log4j.Logger;
import org.apache.log4j.BasicConfigurator;
public class MyApp {
static Logger logger = Logger.getLogger(MyApp.class);
public static void main(String[] args) {
// Set up a simple configuration that logs on the console.
// (not that OJ would do this)
BasicConfigurator.configure();
logger.info("Entering application.");
Bar bar = new Bar();
bar.doIt();
logger.info("Exiting application.");
}
}
A possibility exists that OJ could accept a log_level parameter. If not
specified, the default log4j.xml file could be used outputting "info"
and above statements to a log file. If specified, a different log4j.xml
file or hard-coded root logger could be used to output trace/debug log
statements and above to a log file. This could be useful for bug
reporting. As a plugin developer, I can specify my own configuration
file that ignores all log statements except those in my own java
package, writing them to my console.
I know OJ currently uses log4j. If the OJ team wants to fully go the
log4j route, then all I'm suggesting for now is that the 330 output
statements get cleaned up.
But, Landon, I think you made an excellent point earlier ... some of
these statements should also be reported to the user
(https://sourceforge.net/apps/mediawiki/jump-pilot/index.php?title=Displaying_Debug_Messages)
in addition to being logged.
Cheers,
Kevin
On 9/7/2010 8:43 AM, Sunburned Surveyor wrote:
> I'll have to take a look at log4J again. Did you imagine exposing a
> method to access the logging functionality through the plug-in
> context, or through some other mechanism?
>
> The Sunburned Surveyor
>
> On Tue, Sep 7, 2010 at 8:29 AM, Kevin Neufeld
> wrote:
>> On 9/7/2010 7:38 AM, Sunburned Surveyor wrote:
>>> Stefan,
>>>
>>> ... I have used Log4j before,
>>> and it seemed a little complicated.
>> I find the log4j.properties variant complicated as well. But the
>> log4j.xml [1] configuration variant I find fairly straight forward [2].
>> I can include/exclude log messages from particular java packages and log
>> priorities.
>>
>>> I wonder if just having the
>>> ability to write messages to a simple plain-text log file would
>>> suffice.
>>>
>> Which is one of many output appenders available to log4j :) I agree,
>> this is what I would recommend. From user's perspective, one can submit
>> the log file when posting a bug report. We can even include a parameter
>> in the JUMP launcher that would temporarily set the log priority to
>> debug or even verbose to help with bug reports.
>>
>> My 2 cents,
>> -- Kevin
>>
>>
>> [1] http://wiki.apache.org/logging-log4j/Log4jXmlFormat
>> [2] http://wiki.apache.org/logging-log4j/Log4jXmlFormat#Example_2
>>
>> --
>> This SF.net Dev2Dev email is sponsored by:
>>
>> Show off your parallel programming skills.
>> Enter the Intel(R) Threading Challenge 2010.
>> http://p.sf.net/sfu/intel-thread-sfd
>> ___
>>
Re: [JPP-Devel] System.out in code
On 9/7/2010 7:38 AM, Sunburned Surveyor wrote: > Stefan, > > ... I have used Log4j before, > and it seemed a little complicated. I find the log4j.properties variant complicated as well. But the log4j.xml [1] configuration variant I find fairly straight forward [2]. I can include/exclude log messages from particular java packages and log priorities. > I wonder if just having the > ability to write messages to a simple plain-text log file would > suffice. > Which is one of many output appenders available to log4j :) I agree, this is what I would recommend. From user's perspective, one can submit the log file when posting a bug report. We can even include a parameter in the JUMP launcher that would temporarily set the log priority to debug or even verbose to help with bug reports. My 2 cents, -- Kevin [1] http://wiki.apache.org/logging-log4j/Log4jXmlFormat [2] http://wiki.apache.org/logging-log4j/Log4jXmlFormat#Example_2 -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
[JPP-Devel] question about getUltimateWrappee()
The FeatureCollectionWrapper.getUltimateWrappee() looks like this:
public FeatureCollection getUltimateWrappee() {
FeatureCollection currentWrappee = fc;
while (currentWrappee instanceof FeatureCollectionWrapper) {
currentWrappee = ((FeatureCollectionWrapper) currentWrappee).fc;
}
return currentWrappee;
}
http://jump-pilot.svn.sourceforge.net/viewvc/jump-pilot/core/trunk/src/com/vividsolutions/jump/feature/FeatureCollectionWrapper.java?revision=859&view=markup#l66
Is there a reason line 66 references .fc directly instead of .getWrappee() ?
For me this currently returns the wrong answer. In the case of a
CachingFeatureCollection, there are actually two FeatureCollections: the
actual wrapped FC and a cached FC (a potentially small subset of the
wrapped FC). So, in this case, .fc references the cached FC, which is
not the FC I'm actually after.
I've overridden CachingFeatureCollection.getWrappee() in a custom
variant to return the actual wrapped FC, which in my case is a custom
DataStoreFeatureCollection that mimics a database table, not the cached
FC subset.
-- Kevin
--
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] wishlist
I'm programmatically invoking a refresh on the layer - any data currently in the bounding box of the viewport is reloaded from the datastore ... which includes the newly inserted feature. I suppose I could be smarter about this and reload all features whose bounding boxes match the bounding box of the feature just inserted. Then I'd filter all features already in the client's cache, thereby adding one new feature to the FeatureCollection ... but a complete layer refresh is far easier. :) -- Kevin On 9/6/2010 6:31 AM, Rahkonen Jukka wrote: > Hi, > > One further question: How are you going to get the ID of the newly inserted > feature back to OpenJUMP side? > > -Jukka- > -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] wishlist
Hi Jukka, Yes, inserts are more tricky than other modification types. However, IMHO, a properly modeled database will include sequence generators, rules, or triggers on database tables enforcing the primary key attribute. My first iteration through this will be to simply target the most common use case, that is, during an insert operation, specify all attributes except the primary key (whether single or multi-column key) and let the database populate the field(s) automatically. If the attempt fails, then there are options: 1) Do nothing, rollback the transaction and notify the user they are missing sequences on their primary key columns 2) Again, warn the user their database modeling needs work and try the commonly used max(ID) approach to guess the primary key entry (maybe in a confirmation dialog). However, this is definitely not recommended. What if the column is alphanumeric? What's the max(ID) then? What if it's, as you point out, a multiple-key column? Obviously we can't guess that. What if it was intentional that a sequence was not provided? Maybe the table is considered read-only. No, this approach makes assumptions about the datamodel that a viewing/editing tool really should not be making. I think for now, I'm going to stick with simply relying on the the fields to be auto-generated. Cheers, Kevin On 9/4/2010 1:41 AM, Rahkonen Jukka wrote: > Hi, > > How are you going to deal with inserts? And have you considered supporting > also other databases than PostGIS (Oracle, Spatialite)? I have been dealing > with WFS-T against Oracle and I know that inserts are the most tricky part, > especially with Oracle. But it may be tricky even with PostGIS if table has a > combined primary key. > > Perhaps the not-so-recommended Geoserver way could be used? Geoserver selects > max(ID) in the beginning of insert, and feeds in ID=(max(ID)+1). It is not > recommended because it is not reliable at all if there are many users doing > inserts at the same time. The better way is to use triggers but it goes more > complicated. > > -Jukka Rahkonen- > -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] wishlist
Hi Michael, good thoughts. Yes, I'm in process of implementing some datastore plugins that will permit the dynamic reading and writing to a database. I wrote a quick hacky plugin many years ago that does this for PostGIS. I want to release this to the community because it seems quite useful, but I'm first tackling a complete code rewrite with a nice UI. I'm currently using a Primary or Unique key to synchronize a database table and OJ's FeatureCollection. If a feature gets modified, I use the key to update the appropriate record in the database. Obviously, mayhem ensues if a user were to modify a feature and it's primary key attribute ... they'd be modifying the wrong record in the database. So, yes, I'm trying to prevent the modification of certain attributes. Preventing attribute writing through the LayerTable seemed like the easiest approach, but I'm definitely open to ideas on how we can make this rock solid. I hadn't considered adding a check to BasicFeature.setAttribute, but it does sound prudent. I'm not sure I understand your last comment, can you please elaborate? If the readonly attribute is not cloned, then a deep copy of a FeatureSchema object wouldn't have the same constraints as the original, no? -- Kevin On 9/3/2010 2:25 PM, Michaël Michaud wrote: >Hi, > > I just had a look at your patch which seems good to me. > > I have some questions about it : > > 1 - Do you plan to improve database connection plugins to prevent > modifications on some kinds of database attributes ? > > 2 - Do you just want to prevent attribute writing throught the LayerTable ? > Because if you want a stronger protection (preventing attribute writing > from attribute edition plugins, new plugins, scripts) , I think some > methods have to be added in the feature implementation > (AbstractBasicFeature.setAttribute ? BasicFeature.setAttribute ?) to > check if setting a new attribute value is authorized by the feature > schema. I'm not sure about setAttributes which is a low level method. > What do you think ? Checking before each setAttribute may slowdown the > whole process. > And if we go this way, I wonder if cloning attributeReadOnly property > with the FeatureSchema is necessary. > What do you think ? > > Michaël > > Le 02/09/2010 17:59, Kevin Neufeld a écrit : > >> Patch has been committed at r2034, no problems. Let me know if anyone >> has issues with the addition. >> >> Thanx all, >> -- Kevin >> >> On 9/2/2010 8:29 AM, Sunburned Surveyor wrote: >> >>> Kevin, >>> >>> You've been added to the Jump Pilot Project on Sourceforge and now >>> have write access to the SVN. You can commit your patch so we get the >>> changes in our nightly build. >>> >>> If you have trouble with the commit, please let me know. >>> >>> The Sunburned Surveyor >>> >>> >> -- >> This SF.net Dev2Dev email is sponsored by: >> >> Show off your parallel programming skills. >> Enter the Intel(R) Threading Challenge 2010. >> http://p.sf.net/sfu/intel-thread-sfd >> ___ >> Jump-pilot-devel mailing list >> Jump-pilot-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >> >> >> > > -- > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > ___ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] wishlist
Patch has been committed at r2034, no problems. Let me know if anyone has issues with the addition. Thanx all, -- Kevin On 9/2/2010 8:29 AM, Sunburned Surveyor wrote: > Kevin, > > You've been added to the Jump Pilot Project on Sourceforge and now > have write access to the SVN. You can commit your patch so we get the > changes in our nightly build. > > If you have trouble with the commit, please let me know. > > The Sunburned Surveyor > -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] wishlist
Hi Stefan, You're right, I once did have write access to the old JUMP ... that was a long time ago. I'm surprised you remembered :) Sure, if you're willing, I wouldn't mind having access again. I'm not planning on any major core contributions, but in my spare time as I'm working on various plugins, I occasionally come across some minor things that could get cleaned up. I agree that commits to the core should first have the eyes of those that know the code inside and out. So, if you're willing, my account is kdneufeld. Have a good trip, Stefan! -- Kevin On 9/1/2010 8:58 PM, Stefan Steiniger wrote: > Hei Kevin, > > do you want SVN write access? > so this way we do not need to sent patches around, and I think you did > already a couple of contributions (on the good old JUMP-cvs before it > was gone. So there would be no concern about your skills ;) > > However, if core features are concerned we usually have Larry or Michael > testing it before a commit is done. (sorry guys, but indeed Larry and > Michael are THOSE who know and have the skill ;) > > For giving you write access we (Michael, Landon or I) would need your > SourceForge account login name - thats all. > > stefan > > Kevin Neufeld schrieb: > >> That is the thing with opensource development, eh? :) Development >> resources are always tight. >> >> I just added a patch for review to the feature tracker for my primary issue. >> http://sourceforge.net/tracker/index.php?func=detail&aid=3057748&group_id=118054&atid=679909 >> >> The patch >> - adds a readonly attribute to a FeatureSchema attribute >> - uses the attribute in the LayerTableModel to set if a cell is editable >> - shades cells in the AttributeTablePanel that are non-editable to light >> gray. >> >> I don't know what OJ uses for a testing harness, but preliminary testing >> looks good. >> I programmatically added a layer and set one of the schema attributes as >> read-only. >> >> The other issues I mentioned are not a big concern for me at all (just a >> wishlist) and I no plans to address them any time soon. >> >> -- Kevin >> >> >> On 9/1/2010 1:34 PM, Michaël Michaud wrote: >> >>> Hi Kevin >>> >>> All your propositions seem reasonnable and valuable for OpenJUMP. >>> >>> As Stefan said, the main problem is development resources. >>> I cannot evaluate precisely the work to do without a deeper look, but it >>> concerns core classes and will need caution and tests. >>> Are you volonteer to develop these features ? >>> >>> Michaël >>> >>> >>> >>> Le 01/09/2010 20:15, Kevin Neufeld a écrit : >>> >>> >>>> Stefan mentioned that there isn't a road map for OJ, but is there a >>>> place to jot down improvement ideas? >>>> >>>> Here are a couple on my wishlist: >>>> >>>> 1) The ability to specify which columns are editable in an layer's >>>> attribute table. Right now, the FID and geometry column are hard-coded >>>> as being the only columns that are not editable. I would like to see >>>> this driven off the layer's FeatureSchema. Perhaps there could be a >>>> "isAttributeReadOnly(int attributeIndex)" method added to the >>>> FeatureSchema that could be used in LayerTableModel.isCellEditable(int >>>> rowIndex, int columnIndex). >>>> >>>> Primary key attributes that belong to a DynamicFeatureCollection driven >>>> off a database is one example of a non-editable column. >>>> >>>> >>>> 2) The ability to customize the tooltips for previously installed >>>> plugins on a layer's right click context menu. For example, I could >>>> have a custom implementation of a Layer that is backed by a custom >>>> FeatureCollection. If I mark the layer as readonly, the "Editable" menu >>>> item is correctly greyed-out. The tooltip says something like "This >>>> layer cannot be made editable." The menu item is greyed-out ... >>>> obviously it's not editable. I would like to change the tooltip to >>>> explain *why* the menu item is greyed-out ... which is particular to my >>>> custom FeatureCollection. >>>> >>>> IE. >>>> "No Primary Key found on the underlying database table" >>>> "Adhoc queries cannot be made editable" >>>> "SQL Serv
Re: [JPP-Devel] wishlist
That is the thing with opensource development, eh? :) Development resources are always tight. I just added a patch for review to the feature tracker for my primary issue. http://sourceforge.net/tracker/index.php?func=detail&aid=3057748&group_id=118054&atid=679909 The patch - adds a readonly attribute to a FeatureSchema attribute - uses the attribute in the LayerTableModel to set if a cell is editable - shades cells in the AttributeTablePanel that are non-editable to light gray. I don't know what OJ uses for a testing harness, but preliminary testing looks good. I programmatically added a layer and set one of the schema attributes as read-only. The other issues I mentioned are not a big concern for me at all (just a wishlist) and I no plans to address them any time soon. -- Kevin On 9/1/2010 1:34 PM, Michaël Michaud wrote: >Hi Kevin > > All your propositions seem reasonnable and valuable for OpenJUMP. > > As Stefan said, the main problem is development resources. > I cannot evaluate precisely the work to do without a deeper look, but it > concerns core classes and will need caution and tests. > Are you volonteer to develop these features ? > > Michaël > > > > Le 01/09/2010 20:15, Kevin Neufeld a écrit : > >> Stefan mentioned that there isn't a road map for OJ, but is there a >> place to jot down improvement ideas? >> >> Here are a couple on my wishlist: >> >> 1) The ability to specify which columns are editable in an layer's >> attribute table. Right now, the FID and geometry column are hard-coded >> as being the only columns that are not editable. I would like to see >> this driven off the layer's FeatureSchema. Perhaps there could be a >> "isAttributeReadOnly(int attributeIndex)" method added to the >> FeatureSchema that could be used in LayerTableModel.isCellEditable(int >> rowIndex, int columnIndex). >> >> Primary key attributes that belong to a DynamicFeatureCollection driven >> off a database is one example of a non-editable column. >> >> >> 2) The ability to customize the tooltips for previously installed >> plugins on a layer's right click context menu. For example, I could >> have a custom implementation of a Layer that is backed by a custom >> FeatureCollection. If I mark the layer as readonly, the "Editable" menu >> item is correctly greyed-out. The tooltip says something like "This >> layer cannot be made editable." The menu item is greyed-out ... >> obviously it's not editable. I would like to change the tooltip to >> explain *why* the menu item is greyed-out ... which is particular to my >> custom FeatureCollection. >> >> IE. >> "No Primary Key found on the underlying database table" >> "Adhoc queries cannot be made editable" >> "SQL Server DataStores cannot currently be made editable" >> >> >> 3) A new UpdatablePlugIn interface with methods like getPluginVersion(), >> getPluginURL(). All implementations of the interface could be listed in >> the extensions tag in the About window. A user could choose to update a >> selected plugin where a new plugin jar and all the jar's dependencies >> would automatically download, available upon application restart. I >> know, I know. This would require a huge framework and lots of developer >> time, but it sure would be nice to have. >> >> >> Cheers, >> -- Kevin >> >> -- >> This SF.net Dev2Dev email is sponsored by: >> >> Show off your parallel programming skills. >> Enter the Intel(R) Threading Challenge 2010. >> http://p.sf.net/sfu/intel-thread-sfd >> ___ >> Jump-pilot-devel mailing list >> Jump-pilot-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >> >> >> > > -- > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > ___ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] wishlist
Ah, great, thanx Stefan. I'll add the requests there so others can comment/poke holes/massage/scrap the ideas. Yeah, OJ is by far my preferred desktop GIS client. The fact that OJ is so tightly coupled with JTS (which is the backbone of PostGIS through GEOS) makes it great to work with. Cheers, Kevin On 9/1/2010 11:48 AM, Stefan Steiniger wrote: > Hei Kevin, > > thanks for you thoughts. Sounds all pretty reasonable to me - the only > issue is "developer time" ;) > > In general we have at SourceForge the Bug Tracker and Feature-Request > Tracker. So that would be the place to add your 3 wishes: > http://sourceforge.net/projects/jump-pilot/support > > > We actually had also a TODO.txt file in the trunk, but it is not used. > > thanks again, and its actually nice to know that Refractions-Folks > besides Martin is still interested in OJ development :) > > cheers from Calgary to Victoria > stefan > > Kevin Neufeld wrote: >>Stefan mentioned that there isn't a road map for OJ, but is there a >> place to jot down improvement ideas? >> >> Here are a couple on my wishlist: >> >> 1) The ability to specify which columns are editable in an layer's >> attribute table. Right now, the FID and geometry column are hard-coded >> as being the only columns that are not editable. I would like to see >> this driven off the layer's FeatureSchema. Perhaps there could be a >> "isAttributeReadOnly(int attributeIndex)" method added to the >> FeatureSchema that could be used in LayerTableModel.isCellEditable(int >> rowIndex, int columnIndex). >> >> Primary key attributes that belong to a DynamicFeatureCollection driven >> off a database is one example of a non-editable column. >> >> >> 2) The ability to customize the tooltips for previously installed >> plugins on a layer's right click context menu. For example, I could >> have a custom implementation of a Layer that is backed by a custom >> FeatureCollection. If I mark the layer as readonly, the "Editable" menu >> item is correctly greyed-out. The tooltip says something like "This >> layer cannot be made editable." The menu item is greyed-out ... >> obviously it's not editable. I would like to change the tooltip to >> explain *why* the menu item is greyed-out ... which is particular to my >> custom FeatureCollection. >> >> IE. >> "No Primary Key found on the underlying database table" >> "Adhoc queries cannot be made editable" >> "SQL Server DataStores cannot currently be made editable" >> >> >> 3) A new UpdatablePlugIn interface with methods like getPluginVersion(), >> getPluginURL(). All implementations of the interface could be listed in >> the extensions tag in the About window. A user could choose to update a >> selected plugin where a new plugin jar and all the jar's dependencies >> would automatically download, available upon application restart. I >> know, I know. This would require a huge framework and lots of developer >> time, but it sure would be nice to have. >> >> >> Cheers, >> -- Kevin >> >> -- >> This SF.net Dev2Dev email is sponsored by: >> >> Show off your parallel programming skills. >> Enter the Intel(R) Threading Challenge 2010. >> http://p.sf.net/sfu/intel-thread-sfd >> ___ >> Jump-pilot-devel mailing list >> Jump-pilot-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >> >> > -- > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > ___ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
[JPP-Devel] wishlist
Stefan mentioned that there isn't a road map for OJ, but is there a place to jot down improvement ideas? Here are a couple on my wishlist: 1) The ability to specify which columns are editable in an layer's attribute table. Right now, the FID and geometry column are hard-coded as being the only columns that are not editable. I would like to see this driven off the layer's FeatureSchema. Perhaps there could be a "isAttributeReadOnly(int attributeIndex)" method added to the FeatureSchema that could be used in LayerTableModel.isCellEditable(int rowIndex, int columnIndex). Primary key attributes that belong to a DynamicFeatureCollection driven off a database is one example of a non-editable column. 2) The ability to customize the tooltips for previously installed plugins on a layer's right click context menu. For example, I could have a custom implementation of a Layer that is backed by a custom FeatureCollection. If I mark the layer as readonly, the "Editable" menu item is correctly greyed-out. The tooltip says something like "This layer cannot be made editable." The menu item is greyed-out ... obviously it's not editable. I would like to change the tooltip to explain *why* the menu item is greyed-out ... which is particular to my custom FeatureCollection. IE. "No Primary Key found on the underlying database table" "Adhoc queries cannot be made editable" "SQL Server DataStores cannot currently be made editable" 3) A new UpdatablePlugIn interface with methods like getPluginVersion(), getPluginURL(). All implementations of the interface could be listed in the extensions tag in the About window. A user could choose to update a selected plugin where a new plugin jar and all the jar's dependencies would automatically download, available upon application restart. I know, I know. This would require a huge framework and lots of developer time, but it sure would be nice to have. Cheers, -- Kevin -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] broken trunk/pom.xml at 2015
Hi Stefan, Close, but not quite. Typically, the naming convention of files in a maven repository are of the form: -. In this case, you've declared as a dependency: org.math.plot jmathplot 20070905 compile So in the repository, maven is expecting to find the "jmathplot-20070905.jar", .pom, .md5, and .sha1 files in the "$repo\org\math\plot\jmathplot\20070905" directory. However, since you've named the file "jmathplot_sept2007_java1.5.jar", maven was unable to locate the dependency. I redeployed your jar file to http://lists.refractions.net/m2/org/math/plot/jmathplot/20070905/ using your modified tag. Everything is working again so it's all good. Cheers, Kevin On 8/29/2010 11:19 PM, Stefan Steiniger wrote: > Hei Kevin, > > ok I see that I missed to add the lib to the maven directory. > I added it, but I am not sure if made things right. > As I said, I have never used Maven up to now... so if you can check and > help I would be greatful. > > stefan > > Kevin Neufeld schrieb: > >>If it helps, I just uploaded an org.math.jmathplot-20100827 to >> lists.refractions.net/m2 >> >> http://lists.refractions.net/m2/org/math/jmathplot/20100827/jmathplot-20100827.pom >> >> -- Kevin >> >> On 8/27/2010 10:47 AM, Kevin Neufeld wrote: >> >>> FYI, >>> >>> The current revision of /core/trunk/pom.xml (2015) lists >>> org.math.jmathplot as a dependency: >>> >>> http://jump-pilot.svn.sourceforge.net/viewvc/jump-pilot/core/trunk/pom.xml?view=diff&r1=2015&r2=1886&diff_format=h >>> >>> >>> However, I'm pretty sure this dependency does not exist in any of the >>> listed repositories. >>> >>> Cheers, >>> Kevin >>> >> -- >> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program >> Be part of this innovative community and reach millions of netbook users >> worldwide. Take advantage of special opportunities to increase revenue and >> speed time-to-market. Join now, and jumpstart your future. >> http://p.sf.net/sfu/intel-atom-d2d >> ___ >> Jump-pilot-devel mailing list >> Jump-pilot-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >> >> >> > -- > Sell apps to millions through the Intel(R) Atom(Tm) Developer Program > Be part of this innovative community and reach millions of netbook users > worldwide. Take advantage of special opportunities to increase revenue and > speed time-to-market. Join now, and jumpstart your future. > http://p.sf.net/sfu/intel-atom-d2d > ___ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Versioning pom etc.
Hi Stefan, thanx for the reply, On 8/27/2010 3:47 PM, Stefan Steiniger wrote: > - tagging: > ok.. I may need to change something here w.r.t. the versioning/tagging. > I personally don't use the pom > just the ANT files for building. So I don't know. Any help would be > appreciated. > Ah, ok. Yeah, I use the pom quite heavily. I can develop a plugin and simply reference OJ's pom. All the jar dependencies (and their dependencies) needed to run OJ are automatically downloaded and added to my classpath. Maven is simply the best. > - on the jmathplot: > mhm.. probably I messed up the path? Should be org.math.plot > However, I committed yesterday some code that needs the jmathplot > library for the profile function on a sextante raster which initself > uses classes from org.openjump.core.ui.plot.* > And in future I want to add two more plot plugins that use the lib > (histogram& scatter plot) (currently only in my code base). I also > committed the lib to the lib folder. I actually use an old version as we > still compile with Java 1.5 and I think the newer JMath versions are for 1.6 > So not sure, what you think is wrong. I studied your pom-example but > can't match things to change the pom in the repository. > If you want you could change it locally and send me your version and I > commit it (but see below) > Ah, I didn't realize you had uploaded your version of jmathplot to the lib folder. Great. Yeah, don't try to upload pom stuff manually to a maven repo ... that's way too much work :) If you have maven installed, it's one statement from the command line to add a new pom/jar with all the pom versions and checksums, etc. I just uploaded your older jmathplot to lists.refractions.net/m2 and everything is working again. Thanx. > - versioning: > I was thinking that there will be no 1.3.2 release, and next should be > 1.4 as we added all the raster stuff. > I assign "version" more on subjective feeling not on objective criteria > as we don't have a road map. > Great. That's no problem at all. I just wouldn't mind seeing the pom versions updated to reflect the tagged releases. I realize that will change the release checksums, but I think it's worth it. > - system.out patches: > I hope I can commit the patches tomorrow (otherwise send me a reminder > the next days) > > anyway.. hints/tips/improvements are appreciated. If you want I can give > you write access to the repository for fixing it. > Wonderful. Thanx again Stephen. -- Kevin -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
[JPP-Devel] System.out in code
My I suggest that System.out lines be replaced with appropriate log4j
statements in OpenJUMP?
One of the purposes/advantages of using log4j is that I can filter
output generated by other people's plugins that don't pertain to my own
development.
Attached is a couple of example patches that I've had to make to
OpenJUMP so as to not clutter my console.
If someone wouldn't mind applying these small patches, that would be great!
Cheers,
Kevin
### Eclipse Workspace Patch 1.0
#P openjump-core
Index: src/com/vividsolutions/jump/workbench/imagery/ecw/ECWImageFactory.java
===
--- src/com/vividsolutions/jump/workbench/imagery/ecw/ECWImageFactory.java
(revision 2016)
+++ src/com/vividsolutions/jump/workbench/imagery/ecw/ECWImageFactory.java
(working copy)
@@ -31,6 +31,8 @@
* (250)385-6040
* www.vividsolutions.com
*/
+import org.apache.log4j.Logger;
+
import com.vividsolutions.jump.I18N;
import com.vividsolutions.jump.JUMPException;
import com.vividsolutions.jump.workbench.WorkbenchContext;
@@ -41,6 +43,8 @@
*/
public class ECWImageFactory implements ReferencedImageFactory {
+ private Logger logger = Logger.getLogger(ECWImageFactory.class);
+
public static final String TYPE_NAME = "ECW";
final static String
sNotInstalled=I18N.get("org.openjump.core.ui.plugin.layer.AddSIDLayerPlugIn.not-installed");
@@ -75,10 +79,10 @@
}catch(ClassNotFoundException e){
// eat it
- System.out.println("ECW loader class " +
JNCSRendererProxy.RENDERER_CLASS + " " + sNotInstalled);
+ logger.warn("ECW loader class " +
JNCSRendererProxy.RENDERER_CLASS + " " + sNotInstalled);
return false;
}
- System.out.println("found ECW loader class");
+ logger.trace("found ECW loader class");
return c != null;
}
Index:
src/com/vividsolutions/jump/workbench/imagery/mrsid/MrSIDImageFactory.java
===
--- src/com/vividsolutions/jump/workbench/imagery/mrsid/MrSIDImageFactory.java
(revision 2016)
+++ src/com/vividsolutions/jump/workbench/imagery/mrsid/MrSIDImageFactory.java
(working copy)
@@ -33,6 +33,8 @@
*/
import java.io.File;
+import org.apache.log4j.Logger;
+
import com.vividsolutions.jump.I18N;
import com.vividsolutions.jump.JUMPException;
import com.vividsolutions.jump.workbench.WorkbenchContext;
@@ -40,6 +42,9 @@
import com.vividsolutions.jump.workbench.imagery.ReferencedImageFactory;
public class MrSIDImageFactory implements ReferencedImageFactory {
+
+ private Logger logger = Logger.getLogger(MrSIDImageFactory.class);
+
//[sstein 19Apr2008] -- new
public static String WORKING_DIR;
public static String ETC_PATH;
@@ -102,7 +107,7 @@
//-- error messages can not be send, as the workbench does not
exist yet
//context.getWorkbench().getFrame().warnUser(sErrorSeeOutputWindow);
//context.getWorkbench().getFrame().getOutputFrame().addText(MRSIDDECODE + " "
+ sNotInstalled);
- System.out.println(MRSIDDECODE + " " + sNotInstalled);
+ logger.warn(MRSIDDECODE + " " + sNotInstalled);
return false;
}
@@ -111,10 +116,10 @@
//-- error messages can not be send, as the workbench does not
exist yet
//context.getWorkbench().getFrame().warnUser(sErrorSeeOutputWindow);
//context.getWorkbench().getFrame().getOutputFrame().addText(MRSIDINFO + " " +
sNotInstalled);
- System.out.println(MRSIDINFO + " " + sNotInstalled);
+ logger.warn(MRSIDINFO + " " + sNotInstalled);
return false;
}
- System.out.println("found Mrsid decode files");
+ logger.trace("found Mrsid decode files");
return true;
//-- end new stuff
// }catch(IOException e){
--
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users
worldwide. Take advantage of special opportunities to increase revenue and
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] broken trunk/pom.xml at 2015
If it helps, I just uploaded an org.math.jmathplot-20100827 to lists.refractions.net/m2 http://lists.refractions.net/m2/org/math/jmathplot/20100827/jmathplot-20100827.pom -- Kevin On 8/27/2010 10:47 AM, Kevin Neufeld wrote: > FYI, > > The current revision of /core/trunk/pom.xml (2015) lists > org.math.jmathplot as a dependency: > > http://jump-pilot.svn.sourceforge.net/viewvc/jump-pilot/core/trunk/pom.xml?view=diff&r1=2015&r2=1886&diff_format=h > > > > However, I'm pretty sure this dependency does not exist in any of the > listed repositories. > > Cheers, > Kevin -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
[JPP-Devel] broken trunk/pom.xml at 2015
FYI, The current revision of /core/trunk/pom.xml (2015) lists org.math.jmathplot as a dependency: http://jump-pilot.svn.sourceforge.net/viewvc/jump-pilot/core/trunk/pom.xml?view=diff&r1=2015&r2=1886&diff_format=h However, I'm pretty sure this dependency does not exist in any of the listed repositories. Cheers, Kevin -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
[JPP-Devel] Versioning
Can someone please clarify OpenJump's use of version tagging? It makes sense that the trunk version of OpenJump [1] is tagged with 1.3.2-SNAPSHOT, but I don't understand the versioning of the tagged releases. The static tag of 1.3.1 [2] has a pom version of 1.3-SNAPSHOT. The static tag of 1.3 [3] has a pom version of 1.2-SNAPSHOT. The static tag of 1.2 [4] has a pom version of 1.2-SNAPSHOT. Am I looking in the right spot for tagged releases? Was this a small oversight? Thanx so much! Cheers, Kevin [1] https://jump-pilot.svn.sourceforge.net/svnroot/jump-pilot/core/trunk/pom.xml [2] https://jump-pilot.svn.sourceforge.net/svnroot/jump-pilot/core/tags/1.3.1/pom.xml [3] https://jump-pilot.svn.sourceforge.net/svnroot/jump-pilot/core/tags/1.3/pom.xml [4] https://jump-pilot.svn.sourceforge.net/svnroot/jump-pilot/core/tags/1.2/pom.xml -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Tooltip display
Hi Michaël, Having a feature count readily available is a nice addition for a quick overview in the Jump environment, either as a tooltip or displayed in the status bar. If you prefer it as a layer tooltip, may I suggest you drop the layer name (since that's redundant information) and prefix the [#objects] with a description. Honestly, it took me a while to clue in to what the [#] was actually indicating as I was panning around and the number kept changing. Perhaps something like: Feature Count: [#objects] But, I do agree that this should only be used if there is no layer description. That way, ppl can override it if they want. If that works in the LayerNameRenderer class, that's great. Thanx for your efforts Michaël, it's appreciated. Cheers, Kevin Michael Michaud wrote: > Hi Kevin (and others for advice) > > Sorry for the annoyance, I realize that the ToolTipText content is > defined in the LayerNameRenderer class, and that I overrode the previous > behaviour, adding a method directly in the TreeLayerNamePanel. > I added the number of objects in the tooltip because I found it useful > to have a quick access to this information, but we have also this > information in the layer property (right click), so that it is not > absolutely necessary to have it in the tooltip > > By the way, I can move my code into LayerNameRenderer and add the number > (#objects) of objects only if there is no description, or in both cases, > or never : > > * layer name (never or only when there is no description = previous > behaviour) > * layer name [#objects] (only if there is no description or in both > cases = actual behaviour) > * layer name: description (never or only if there is no description = > overriden behaviour) > * layer name: description [#objects] (in both cases = possible bbehaviour) > > Just let me know your thought about your preferences > > Michaël > > Kevin Neufeld a écrit : >> On Aug10, michaudm committed a tooltip addition to the >> com\vividsolutions\jump\workbench\ui\TreeLayerNamePanel.java file >> (revision 1531 "Display the number of features after the layer name in >> the layer name tooltip"). >> >> It used to be that the Tooltip for a layer was derived by overriding >> com.vividsolutions.jump.workbench.model.Layer#getDescription(). >> >> This no longer works. >> >> I have a couple of custom Layers that retrieve features from a PostGIS >> database dynamically. The tooltip on these layers is used to display >> the current SQL query used in this DataStore, but this change in >> revision 1531 overrides that. >> >> Can someone please commit the attached patch, or alternatively, find a >> way to display michaudm's change to all Layers that don't return >> something useful when overriding >> com.vividsolutions.jump.workbench.model.Layer#getDescription(). >> >> Cheers, >> Kevin >> >> >> >> >> - >> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >> Build the coolest Linux based applications with Moblin SDK & win great prizes >> Grand prize is a trip for two to an Open Source event anywhere in the world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> >> >> ___ >> 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 Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ___ > 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 Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
[JPP-Devel] Tooltip display
On Aug10, michaudm committed a tooltip addition to the com\vividsolutions\jump\workbench\ui\TreeLayerNamePanel.java file
(revision 1531 "Display the number of features after the layer name in the layer name tooltip").
It used to be that the Tooltip for a layer was derived by overriding
com.vividsolutions.jump.workbench.model.Layer#getDescription().
This no longer works.
I have a couple of custom Layers that retrieve features from a PostGIS database dynamically. The tooltip on these
layers is used to display the current SQL query used in this DataStore, but this change in revision 1531 overrides that.
Can someone please commit the attached patch, or alternatively, find a way to display michaudm's change to all Layers
that don't return something useful when overriding com.vividsolutions.jump.workbench.model.Layer#getDescription().
Cheers,
Kevin
Index: TreeLayerNamePanel.java
===
--- TreeLayerNamePanel.java (revision 1583)
+++ TreeLayerNamePanel.java (working copy)
@@ -121,19 +121,10 @@
// Added by Michael Michaud on 2008-08-10
// This adds the number of features in tooltip
-public String getToolTipText(MouseEvent e) {
-Object tip = null;
-TreePath path = getPathForLocation(e.getX(), e.getY());
-if (path != null) {
-if (path.getLastPathComponent() instanceof Layer) {
-Layer layer = (Layer)path.getLastPathComponent();
-tip = layer.getName() + " [" +
- layer.getFeatureCollectionWrapper().size() + "]";
-}
-else tip = path.getLastPathComponent();
-}
-return tip == null ? null : tip.toString();
- }
+// Removed by Kevin Neufeld on 2008-10-31 since it interferes with
useful
+// tooltips that custom layers create when they override
+// com.vividsolutions.jump.workbench.model.Layer#getDescription().
+// public String getToolTipText(MouseEvent e) {}
};
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
