Re: [JPP-Devel] Question about MultiInputDialog

On 22.05.2017 12:40, Giuseppe Aruta wrote: > 1. open Project Properties > 2. enable Metadata Change checkbox (a "Cancel" button that is enabled > together with "Apply") > 3. change the comment > 4. ups, i erred, i want the old entry back > > As the GUI is defined (by MultiInputDialog) can see two

Re: [JPP-Devel] Question about MultiInputDialog

On 22.05.2017 12:43, Giuseppe Aruta wrote: > This solution doesn't take into account that user could modify metadata > more than once. Undo/redo probably solve this but I'd rather use undo/redo > only for editing. yupp.. definitely overkill. let's not go there. ..ede

Re: [JPP-Devel] Question about MultiInputDialog

Peppe, not to be misunderstood. consider this flow 1. open Project Properties 2. enable Metadata Change checkbox 3. change the comment 4. ups, i erred, i want the old entry back now the user has a UI that only allows hit APPLY and then OK (values are saved, user does not want that!) or

Re: [JPP-Devel] Question about MultiInputDialog

Peppe, one issue still remains though. if there is an APPLY button, there should be a CANCEL button to abort _and_ restore the previous state. i leave that to you in case you are interested. the needed method's to hide, en/disable are in place now. it's sunday, so i am being lazy.. ede On

Re: [JPP-Devel] Question about MultiInputDialog

ok, checked your code :).. ProjectInfoPlugIn.proj-metadata is the edit checkbox text, so that can stay as it is. another thing. editing the info comment only get's applied when apply is pressed before ok. that's creative but not intuitive. OK implies acknowledgement, so is essentially the same

[JPP-Devel] TaskFrame.getRealTitle() WAS:Re: (no subject)

hey Peppe, as usual ;), i would have implemented it a little different. but let's meet in the middle and simply not implement getRealTitle(). there should be no reason for any code to retrieve the task frames title and do something with it, as is merely decorative and the informations in it

Re: [JPP-Devel] Question about MultiInputDialog

Peppe, what about the translation strings for the user interface org.openjump.core.ui.plugin.file.ProjectInfoPlugIn.proj-metadata ? ..ede On 20.05.2017 10:42, Giuseppe Aruta wrote: > Hi Ede, > I renamed tag PROJECT_METADATA_KEY to PROJECT_COMMENT_KEY. > > Peppe > > 2017-05-11 17:46

Re: [JPP-Devel] Question about MultiInputDialog

On 11.05.2017 17:44, Giuseppe Aruta wrote: > No problem to rename it. > Actually I am out for a couple of weeks. Can you make that modification Ede? > Or we can make a list of modifications that I will do when I am back home. no stress.. the plugin is new and no release in sight. do it when you

Re: [JPP-Devel] Question about MultiInputDialog

hey All, without going into details, Peppe is right that there are scenarios where file time stamps may be altered reset. taking that into account there is no harm to have _both_ cration and last mod.time written to the project file. Peppe, would you mind renaming PROJ_METADATA to comment or

Re: [JPP-Devel] Question about MultiInputDialog

thx, so in general other GIS use the projects file last mod. time or a saved date value within the same? ..ede On 10.05.2017 16:52, Rahkonen Jukka (MML) wrote: > Hi, > > How could you tell what is the last update time of database layers, or image > layers? For shapefiles one could try to

Re: [JPP-Devel] SVN: [5442] core/trunk/src/com/vividsolutions/jump/workbench/model/ Task.java

On 10.05.2017 13:57, Giuseppe Aruta wrote: > Hi Ede, > sorry, I commit the plugin before reading your mail. > A) I preferred to have the tags on Tak class so can be easly find them in > case they can be used for other reasons (I am planning to work around Task > (=SRS) unit for the next

Re: [JPP-Devel] Question about MultiInputDialog

On 09.05.2017 17:12, Giuseppe Aruta wrote: > C. > wrt. Modification Time - how is this handled within other GIS (Jukka?), > especial wrt. changed datasets. i can imagine a scenario where only a dataset > is changed but the project as such is not changed, > - which date would be more important? >

Re: [JPP-Devel] SVN: [5442] core/trunk/src/com/vividsolutions/jump/workbench/model/ Task.java

hey Peppe, A. would it be possible to implement project tags without having to add static keys in OJ core? the idea is that each plugin could simply ask for a tag and get it. B. what is the reasoning behind a PROJECT_FILE_KEY? isn't that something that can be determined during runtime? C.

Re: [JPP-Devel] Question about MultiInputDialog

hey Peppe, A. can you point me to where the tags are currently written/read/managed in our Task code? i remember us talking about metadata and me opposing to add Getters/Setters for each and every field that might come along as handy, so i think (re)using Task tags saved to XML is the much

Re: [JPP-Devel] FW: Logo of OrbisGIs

that it is :).. ede On 04.05.2017 14:48, manf...@egger-gis.at wrote: > i have changed it to: "GIS-Software developed with Java" > > OK? > > -Original Message- > From: edgar.sol...@web.de > Sent: Thursday, May 4, 2017 8:33am > To: "manf...@egger-gis.at" > Subject:

Re: [JPP-Devel] Registerlink to user group

sure, you can find it in our wiki http://ojwiki.soldin.de/index.php?title=OpenJUMP_Support#Mailing_Lists ..ede On 03.05.2017 14:00, manf...@egger-gis.at wrote: > Hi, > > I can not find the registration link to the user group. Can you send me the > correct link? > > Best regards > >

Re: [JPP-Devel] Email

hey Manfred, the "official" mail addresses currently and since i can remember are our mailing lists. http://ojwiki.soldin.de/index.php?title=OpenJUMP_Support#Mailing_Lists the info on http://www.openjump.org/contact.html seems to be quite outdated and i will have to replace them with more

[JPP-Devel] OpenJUMP 1.11 released

Dear kang-gurus, we prepared a tasty new OpenJUMP 1.11, just for you https://sourceforge.net/projects/jump-pilot/files/OpenJUMP/1.11 find the list of changes below. ..easterbunny ede Version 1.11 release rev.5434 (released on 13. April 2017) New features * Added CadTools extension to

Re: [JPP-Devel] graph-toolbox 0.5.0

On 10.04.2017 01:12, Michaël Michaud wrote: > @Ede, I don't mind adding it before or after 1.11 release. If you're > ready, go ahead. If you are not, maybe I'll update the extension before > (it depends if I can do more tests and/or get some feedback in the > meantime). noted.. ede

Re: [JPP-Devel] Small patch to correct proj decoding

hey All, 1.11 is quite delayed by now. everything Peppe suggests can be implemented after the release as well. are we agreed? ..ede On 07.04.2017 18:17, Giuseppe Aruta wrote: > Hi Michael, Ede > > I did a last changes on ProjUtils projection detection in order to exclude > temporary layers

Re: [JPP-Devel] Small patch to correct proj decoding

german translation is incomplete for a long time now. i can live with that. maybe i find some time some day ..ede On 07.04.2017 06:50, Giuseppe Aruta wrote: > Thanks MIchael, > we miss only few translation language codes for Finnic and German > Best regards > Peppe > > 2017-04-06 23:36

Re: [JPP-Devel] Error from Make valid with OpeJUMP 1.10

Jukka, Mike, obviously two issues here. Jukka's original one >>> java.lang.IllegalArgumentException: This method does not support >>> GeometryCollection arguments >>> at >>> com.vividsolutions.jts.geom.Geometry.checkNotGeometryCollection(Geometry.java:1781) >>> at >>>

Re: [JPP-Devel] Small patch to correct proj decoding

On 03.04.2017 09:28, Michaël Michaud wrote: > All this stuff is also related to #429. Let's try to improve this after 1.11 > release. hey Guys, totally agreed, i am sure we will find a flexible way to read and represent layer metadata eventually. for now we should focus on releasing what we've

Re: [JPP-Devel] Small patch to correct proj decoding

Mike, no problem, just tell me when. ..ede On 03.04.2017 09:38, Michaël Michaud wrote: > Hi Ede, > > I'll a need a few days more to fix MakeValid (on my top priority). > > For the code related to projections, I think we'll not get a perfect > solution so fast. > I let Peppe give the go for

Re: [JPP-Devel] Small patch to correct proj decoding

On 01.04.2017 13:00, Giuseppe Aruta wrote: > if Ede gives us few days more :( hey guys, just give me a go at some point :).. ede -- Check out the vibrant tech community on one of the world's most engaging tech sites,

Re: [JPP-Devel] Small patch to correct proj decoding

Mike, no probs.. am busy myself. simply give me a go some time.. ede On 30.03.2017 09:04, Michaël Michaud wrote: > Hi Ede, > > Thanks to let me check everythink is fine until the week-end. > I'll try to fix a small bug discovered this morning > and have a look at the regression found by Peppe,

Re: [JPP-Devel] Small patch to correct proj decoding

On 28.03.2017 13:05, Giuseppe Aruta wrote: > Ede, > CadTools: we made the right corrections on the toolset but we didin't add a > new Cadtools version to OJ NB. > I give a look and make some test and add the new version today right, just thought about that yesterday, but it slipped my mind.

Re: [JPP-Devel] Small patch to correct proj decoding

On 28.03.2017 07:17, Giuseppe Aruta wrote: >> i had a look and saw that >> NewLayerPropertiesPlugIn$InfoPanel.setInfoProjection() tries to determine >> the projection, which is wrong! instead it should rely on the (if) set >> SRIDStyle and read that. > > I corrected that Ede. That was easy as

Re: [JPP-Devel] Small patch to correct proj decoding

Peppe, lets delay this bug for the next release. i had a look and saw that NewLayerPropertiesPlugIn$InfoPanel.setInfoProjection() tries to determine the projection, which is wrong! instead it should rely on the (if) set SRIDStyle and read that. the image readers obviously do not set it right

Re: [JPP-Devel] Small patch to correct proj decoding

go ahead.. i plan to release by the end of the week. ..ede On March 27, 2017 4:02:46 PM GMT+02:00, Giuseppe Aruta wrote: >Hi Ede, Michael >I found a small bug on reading auxiliary raster files with projection >info. >I want to correct it before new OJ 1.11 >Peppe

[JPP-Devel] editing toolbox / cad - icons

hey All, i had a short look and found these icons (see screenshot) in the fugue icon set. any objection into making them permanent? they look more elegant and refined than the current ones. in the future both icons should probably be placed side by side in the toolbar. will do that when i come

Re: [Duplicity-team] [Question #581020]: RFE: Yandex.disk backend support?

On 22.03.2017 14:47, Aleksei Kovura wrote: > New question #581020 on Duplicity: > https://answers.launchpad.net/duplicity/+question/581020 > > They support REST and WebDAV: https://tech.yandex.com/disk/ > any problems using webdav:// with yandex? ..ede/duply.net

[JPP-Devel] Matching Extension in PLUS - WAS:Re: next release options

Mike, fine by me.. don't forget to update readme.txt ..ede On 25.03.2017 10:57, Michaël Michaud wrote: > Hi all, > > As everytime I change my OpenJUMP PLUS version, I reinstall the > "Matching" extension, > > I submit the proposition to include this extension into the PLUS > distribution. >

Re: [JPP-Devel] SVN: [5392] plug-ins/CADExtension/trunk/src/org/openjump/advancedtools

ok, read it again. and yes we could do that, but *no* it is very dirty. we should rather copy the translation for the few generic translations we will add initially from keys where english or your own language suggests it is _really_ used generically contextwise. ..ede On 22.03.2017 15:22,

Re: [JPP-Devel] SVN: [5392] plug-ins/CADExtension/trunk/src/org/openjump/advancedtools

found it com.vividsolutions.jump.workbench.ui.GenericNames is an Interface and uses the translations ui.GenericNames.* i mentioned previously to Pepe. i don't feel we should continue this line of coding. it makes sense for a very limited amount of fixed strings, like menu names, but not for a

Re: [JPP-Devel] SVN: [5392] plug-ins/CADExtension/trunk/src/org/openjump/advancedtools

Stefan, what do you mean by class? com.vividsolutions.jump.workbench.ui.MenuNames ? deals only with menu names. ..ede On 22.03.2017 15:23, Stefan Steiniger wrote: > Hi Ede, > > > > we have a class for generic strings already - since the beginning, i think. > > > > cheers, > > stefan

Re: [JPP-Devel] SVN: [5392] plug-ins/CADExtension/trunk/src/org/openjump/advancedtools

On 22.03.2017 13:04, Giuseppe Aruta wrote: > I will anyhow give a look to "jump" files to find a possible list of "general > terminology" string list that can be used for the future - and maybe write a > page on our wiki that won't hurt.. we have already some strings under ui.GenericNames.*

Re: [JPP-Devel] CAD draw (aux) parallel line

ic.. thx ede On 22.03.2017 11:49, Rahkonen Jukka (MML) wrote: > One tool makes a parallel copy of the line (keeps the length) while the other > extents it to the limits of the visible map view. Difference is easier to > notice with short lines, with polygons (linear rings) it is not so clear to

Re: [JPP-Devel] CAD draw (aux) parallel line

On 22.03.2017 11:53, Giuseppe Aruta wrote: > Draw aux parallel line draws a parallel segment to a selected geometry > 1a) In the case of a selected linestring the parallel new linestrig length is > extended to the view > 2a) In the case of a selected polygon are proportionally longer except first

[JPP-Devel] CAD draw (aux) parallel line

hey All, can someone tell me the difference? they seem to work identically. ..ede -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot

Re: [JPP-Devel] SVN: [5392] plug-ins/CADExtension/trunk/src/org/openjump/advancedtools

On 21.03.2017 21:42, Michaël Michaud wrote: > Hi, > > You're right, there are many duplicates (and I must admit I recognize several > plugins of mine). > > Removing all duplicates would be a very big effort. bad idea. we've got enough on our plates as it is. > But as a first step, we could

Re: [JPP-Devel] SVN: [5392] plug-ins/CADExtension/trunk/src/org/openjump/advancedtools

On 21.03.2017 20:26, Giuseppe Aruta wrote: > Sorry Ede. no biggie > Looking for "source" string, I just noted that in OJ language files we have > some strings which look like duplicates: > for instance: > org.openjump.core.ui.plugin.tools.JoinAttributesSpatiallyPlugIn.source-layer >

Re: [JPP-Devel] SVN: [5392] plug-ins/CADExtension/trunk/src/org/openjump/advancedtools

On 21.03.2017 19:39, Giuseppe Aruta wrote: > - Cadtools check codes: yes there must be already into Jump language files: > yes there are. This is what remains of a previous version of Cad tools > (where I didn't use OJ check system). I did a clean up before to add to > repository but I forgot to

Re: [JPP-Devel] SVN: [5392] plug-ins/CADExtension/trunk/src/org/openjump/advancedtools

Peppe, On 21.03.2017 17:32, Giuseppe Aruta wrote: > On 21.03.2017 17:08, Giuseppe Aruta wrote: >> Hi Ede >> 1) Thanks. I packed all german Kosmo language codes into a file. Very > welcome if you can complete it > > will do can you do me a favour and check if strings/checks already exist in OJ

Re: [JPP-Devel] Just small language fix

can you point to where it is used in the UI? ..ede On 21.03.2017 17:51, Giuseppe Aruta wrote: > Hi All > I need to add another language code to Cad Tool extension > org.openjump.core.ui.utils.CoordinateListMetrics.source > which is referred to source coordinates. > Can you confirm or correct

Re: [JPP-Devel] SVN: [5392] plug-ins/CADExtension/trunk/src/org/openjump/advancedtools

Peppe, 1. the german file is missing strings. do you want me create a proper one? 2. what is the purpopse of the minor fix? why don't you use the proper number formatting? ..ede On 21.03.2017 16:47, jump-pilot-...@lists.sourceforge.net wrote: > Revision: 5392 >

Re: [JPP-Devel] Build process broken

yeah, ignore that.. i am pretty sure it says _Warning_ not Error ;) ..ede On 21.03.2017 12:57, Giuseppe Aruta wrote: > Uhm! > You are right. I misread log file about orange-extensions.jar > Peppe > > 2017-03-21 12:52 GMT+01:00 >: > > how do

Re: [JPP-Devel] Build process broken

how do you figure? the latest commit r5391 was successfully built and uploaded https://sourceforge.net/projects/jump-pilot/files/OpenJUMP_snapshots/ ..ede On 21.03.2017 12:43, Giuseppe Aruta wrote: > Hi > It seems tha the build process is broken > Peppe > > >

Re: [JPP-Devel] next release options

On 20.03.2017 13:03, Giuseppe Aruta wrote: > Hi > 1) I still have to finish Spanish translation for Cad toolbox and > 2) there is still the COGO issue pointed out by Michael. > I can work on 1) on next WE. For 2) I ask a help to minimize the time. wrt. 2. i can't reproduce it. Mike? > Apart

Re: [JPP-Devel] next release options

On 20.03.2017 08:35, Rahkonen Jukka (MML) wrote: > use the Locationtech version of JTS if it makes sense. what's that:) and why would it make sense? ..ede -- Check out the vibrant tech community on one of the world's

[JPP-Devel] next release options

hey All, we fixed some crucial bugs which warrant a new release. we have two options here A. go directly to 1.11, as we have a new feature CAD tools B. disable CAD tools for the release, keep it in snapshots and release a v1.10.1 i'd vote for A. (release early, release often :) ..ede

Re: [JPP-Devel] Fwd: SVN: [5384] plug-ins/CADExtension/trunk/src/org/openjump/advancedtools/ language/I18NPlug.java

yeahaahh :)) thanks for reporting.. ede On 19.03.2017 19:10, Michaël Michaud wrote: > Yeah ! > > Fixed for me, both wfs and cadtool, thanks ;-) > > Michaël > > > Le 19/03/2017 à 16:08, edgar.sol...@web.de a écrit : >> On 19.03.2017 15:26, Michaël Michaud wrote: >>> In OpenJUMP I18N, there are

Re: [JPP-Devel] Fwd: SVN: [5384] plug-ins/CADExtension/trunk/src/org/openjump/advancedtools/ language/I18NPlug.java

On 19.03.2017 15:26, Michaël Michaud wrote: > In OpenJUMP I18N, there are two ways to initialize I18N : from a File or from > a name. > If a File is passed as the argument, I think it will look for the file and > will not find it if it is embedded in the jar. close but not quite. i found the

Re: [JPP-Devel] Fwd: SVN: [5384] plug-ins/CADExtension/trunk/src/org/openjump/advancedtools/ language/I18NPlug.java

On 19.03.2017 13:05, Michaël Michaud wrote: > Hi, > > I use a JRE 1.8 (but it worked before your change) and as I told you, I > included language files in the CADExtension jar file (I'm pretty sure > this is the difference between our environments). ic, you built your own extension jar. i

Re: [JPP-Devel] Fwd: SVN: [5384] plug-ins/CADExtension/trunk/src/org/openjump/advancedtools/ language/I18NPlug.java

hey Mike, works for me. let me investigate. 1. what's your jre? 2. how do you include the CadExtension in your IDE? ..ede On 19.03.2017 11:39, Michaël Michaud wrote: > Hi Ede, > > This commit breaks the extension initialization for me. I now get the > following message : > (my jar

Re: [JPP-Devel] Language files

On 19.03.2017 11:55, Michaël Michaud wrote: > Ede, > > I just noticed that WFS extension was broken in 1.10 (I18N problem) but > has been fixed since then. looks like it. > > You probably fixed the problem but I did not see the commit wher it has > been repaired. > well i didn't! just

Re: [JPP-Devel] Feedback from CAD tools

btw, i cannot replicate that.. ede On 18.03.2017 08:47, Giuseppe Aruta wrote: > Hi Michael I was aware of that but I cannot find a solution right now (I > probably spent more time on it than on the other toos). I still didn't find > a way to finalize related tool when the panel is close. I am

Re: [JPP-Devel] OJ & java9

On 06.03.2017 22:46, Giuseppe Aruta wrote: > Good Job Ede! >>PLUS throws some exceptions... sounds like the plugins indeed. ..ede -- Announcing the Oxford Dictionaries API! The API offers world-renowned dictionary

[JPP-Devel] OJ & java9

ok, OJ snapshot r5359 now officially starts with an early access java 9 sdk. PLUS throws some exceptions but the workbench comes up. we can now look for further incompatibilities and start to solve them in a java 8 compatible way, if possible. if not the next major release will probably an

Re: [JPP-Devel] How to test Java 9 interoperability?

Jukka, i spent yesterday to enable eclipse integration build w/ java 9 support beta, to have at least an IDE sporting java9. run from that w/ my patches it starts fine. the snapshot from yesterday however does not when run from the batch file. will have to investigate. what you can do is get

Re: [Duplicity-team] [Merge] lp:~mwilck/duplicity/0.7-series into lp:duplicity/0.7-series

Martin, afaiu gpg2+ _always_ uses the agent if input is necessary. that's why the manpage contained, auntil you removed " GnuPG 2 and newer ignore this option and will always use a running .B gpg-agent if no passphrase was delivered. " this is because the passphrase input routines got moved from

Re: [JPP-Devel] org.openjump.* vs com.vividsolutions.* WAS: Duplicate code for WMS

Mike, On 03.02.2017 18:52, Michaël Michaud wrote: > I agree that related code should stay together, but "related" is "vague". i am talking about obvious relations, like eg. Wizard framework and the new SaveWizard belong into one package. or the GeoJSON reader ended up where the other io

Re: [JPP-Devel] trunk ready for releasing OJ 1.10?

Brian, tried it myself on OSGeo Live 10.5 alpha. seemed to work fine. whatcha mean by " Maybe some small problems with plugins?" ? the log output looks fine for me, nothing unexpected there. ..ede On 02.02.2017 20:18, Brian M Hamlin wrote: > > second install, and a test launch, terminal

[JPP-Devel] org.openjump.* vs com.vividsolutions.* WAS: Duplicate code for WMS

we should probably talk about placing classes in general. i prefer to have code that belongs together in one place. i don't recall an instance that i placed code under org.openjump , because when i added eg. something to wms and that was placed under com.vividsolutions, the additions went there

Re: [JPP-Devel] Duplicate code for WMS

On 02.02.2017 13:29, Michaël Michaud wrote: > AddWMSQueryPlugIn > No more used ? > let's keep that for reference. we can deprecate it though. ..ede -- Check out the vibrant tech community on one of the

Re: [JPP-Devel] SVN: [5345] core/trunk

hey Mike, Peppe, can you explain why these two files > > core/trunk/src/com/vividsolutions/jump/workbench/ui/plugin/wms/WMSScaleStylePanel.java > > core/trunk/src/com/vividsolutions/jump/workbench/ui/plugin/wms/WMSStylePlugIn.java were deleted? the commit message does not mention it.

Re: [JPP-Devel] what is the usage of SnapVerticesToolsOptionsPanel (Snap vertices tool on Option panel))?

On 31.01.2017 17:50, Giuseppe Aruta wrote: > Greetings > I wonder what is the usage of SnapVerticesToolsOptionsPanel. > I didn't find any, right now, at least on OJ base setup. Is there any > plugin that is using this option? > It seems to be a quite old class. the ConstraintDrawingTools? ..ede

[JPP-Devel] OpenJUMP 1.10 released

Greetings fellow jumping jacks, without further ado here comes OpenJUMP 1.10 https://sourceforge.net/projects/jump-pilot/files/OpenJUMP/1.10 read below for some highlights in the new version or check the Changes.txt that comes with the release for a complete list of new features, improvements

Re: [JPP-Devel] OpenKLEM

On 27.01.2017 09:35, Alberto De Luca wrote: > Hi Michaël and Ede, hey Alberto > the repository for OpenKLEM is luckily just one, the one on bitbucket that > you already now. You can discuss with Roberto Rossi (who is also reading this > reply) about the option of using SVN. Roberto, I don't

Re: [JPP-Devel] OpenKLEM

hey Mike, if you value that component, how about suggesting to add it to the OJ svn and giving him an account. this way you could work on it together and maybe eventually add it to PLUS? ..ede On 25.01.2017 09:48, Alberto De Luca wrote: > Hey Michaël, > > sure I'm still monitoring this list,

Re: [Duplicity-team] [Question #445667]: Duplicity and Mega backend

On 24.01.2017 13:22, Jorman Franzini wrote: > File "/opt/lib/python2.7/site-packages/duplicity/backend.py", line 209, in > get_backend_object > return factory(pu) > File "/opt/lib/python2.7/site-packages/duplicity/backends/megabackend.py", > line 36, in __init__ > from mega import

Re: [JPP-Devel] trunk ready for releasing OJ 1.10?

thanks.. but no need. if you look inside those, you'll see that the logic for a new version is already outsourced to our sf.net files space where we host a osgeo.conf and the files itself https://sourceforge.net/projects/jump-pilot/files/OpenJUMP/osgeo/ testing the changes would be

Re: [JPP-Devel] trunk ready for releasing OJ 1.10?

On 22.01.2017 18:02, Michaël Michaud wrote: > Hi Ede, > > Nice. I would not have thought about delegating line wrapping to swing > html renderer. Works fine. actually me neither. i tried everything form using textarea/pane and wrapping into panels, but in the end this was the easiest to

Re: [JPP-Devel] trunk ready for releasing OJ 1.10?

hey Mike, please try r5334 wrt. to the wizard group list issue.. ede On 17.01.2017 17:19, edgar.sol...@web.de wrote: > comments inline below > > On 17.01.2017 15:50, Michaël Michaud wrote: >> Hi, >> >> Sorry for the delay, I've been offline a few days. >> >> I've just two points : >> >> - I'd

Re: [Duplicity-team] Python 3

hey Aaron, On 19.01.2017 10:59, Aaron wrote: > Hello all, > > I have been doing a bit of work to support python 3 in the codebase. Broadly, > I have been following: > https://docs.python.org/3/howto/pyporting.html > and using Futurize: http://python-future.org/automatic_conversion.html > For

Re: [JPP-Devel] trunk ready for releasing OJ 1.10?

comments inline below On 17.01.2017 15:50, Michaël Michaud wrote: > Hi, > > Sorry for the delay, I've been offline a few days. > > I've just two points : > > - I'd like to commit a new version of graph extension (should be ready today). go ahead > - I'm not convinced by the last change to

[JPP-Devel] trunk ready for releasing OJ 1.10?

hey All, from my side i'd say we are ready. what do you guys say? ..ede -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel

Re: [JPP-Devel] plus/lib/ & CTS plugin

On 04.01.2017 22:54, edgar.sol...@web.de wrote: >> Is it the same for the base classes ? Would there be any benefit to load >> libraries like batik or >> postgresql only when called by a plugin ? Is it already the case ? > > nope, just for jars in lib/ext/ in distros > reread your question. and

Re: [JPP-Devel] SVN: [5314] core/trunk/etc/readme.txt

Mike, On 05.01.2017 00:16, Michaël Michaud wrote: > Hi Ede, > > Does it mean that we cannot include CTS in OJ distribution or does it only > mean that we can include CTS but that CTS-PlugIn must be GPL ? jupp, GPL is viral, but LGPL is not. the Plugin and OJ binding code is based on GPL'd OJ

Re: [JPP-Devel] plus/lib/ & CTS plugin

On 04.01.2017 21:19, Michaël Michaud wrote: > Hi Ede, > > Thanks to take care of all this stuff. nP > Just understood the rational of separating jars containing extensions > from others. yeah.. should have explained it sooner > Is it the same for the base classes ? Would there be any benefit

Re: [JPP-Devel] SVN: [5314] core/trunk/etc/readme.txt

Mike, that won't work! OJ is GPL and your extension is based on OJ interfaces so the license for the extension at least has to be GPL compatible.. ede On 04.01.2017 21:05, jump-pilot-...@lists.sourceforge.net wrote: > Revision: 5314 > http://sourceforge.net/p/jump-pilot/code/5314 >

Re: [JPP-Devel] Add the 5 color coloring plugin into OpenJUMP Plus

done in trunk, will be in the upcoming OJ 1.10.. ede On 04.01.2017 12:56, Giuseppe Aruta wrote: > I agree to add it - or at least to the first OJ NB > > Il 04/Gen/2017 12:30, "Rahkonen Jukka (MML)" > > ha

[JPP-Devel] aggregation extension WAS:Fwd: SVN: [5310] core/trunk

hey Mike, didn't see a change in the svn. where is the source of this extension located? ..ede Forwarded Message Subject: [JPP-Devel] SVN: [5310] core/trunk Date: Tue, 3 Jan 2017 18:43:43 + From: jump-pilot-...@lists.sourceforge.net Reply-To: OpenJump develop and use

Re: [JPP-Devel] Transformation in OpenJump ...

go for it ;).. ede On 03.01.2017 18:01, Giuseppe Aruta wrote: > We should clean up the page: there are many links which are no more active. > Peppe > > 2017-01-03 11:35 GMT+01:00 >: > > works for me.. ede > > On 03.01.2017 07

Re: [JPP-Devel] Transformation in OpenJump ...

works for me.. ede On 03.01.2017 07:59, manf...@egger-gis.at wrote: > Hello, > > i added on your WÍKI a link to my website: > > http://ojwiki.soldin.de/index.php?title=Related_Websites_and_Blogs > > I hope that is OK? > > Best regards, > > Manfred > > -Original Message- > From:

Re: [JPP-Devel] Transformation in OpenJump ...

Manfred, experience shows that links tend to disappear after a while. why don't you find a proper place in the wiki, create a paragraph and link to the pdf, which can as well be uploaded to the wiki. and yes, the wiki is english only, but no reason to ignore german material if it is

[JPP-Devel] Fwd: SVN: [4400] core/trunk/src/com/vividsolutions/jump/workbench/ui/ AbstractMultiInputDialog.java

hey Peppe, just found that you added getWMSLayer(), getWFSLayer() to MultiInputDialog. that is a bad idea as those are optional layer types, that might not be available during runtime. are these methods used anywhere? when those are needed you should use getLayerable() and deal with what kind

Re: [JPP-Devel] SVN: [5296] core/trunk/src/com/vividsolutions/jump/workbench/ui/zoom/ ZoomToCoordinatePlugIn.java

is r5301 better? ..ede On 29.12.2016 21:02, Michaël Michaud wrote: > Hi Ede, > > I don't know what you changed, but the plugin has a strange behaviour. > > When the dialog is get from the menu, clicking on OK just reset the > coordinates without zooming to it. > > When the dialog is get from

[JPP-Devel] duplicated code in WorkbenchFrame

hey Peppe, i cleaned up some code you duplicated while adding plugin functions to the statusbar. for future reference please check how i did it and try to do it similarily next time. you have a tendency to copy/paste ;) when you can simply call the code from where it is already. regards ..ede

[JPP-Devel] next OJ release (warming up)

hey All, i am going to start to condense Changelog into Changes.txt. how is the state with the topics you guys wanted to fix/add before that? here's the list from Mike a while ago with some statuses added OPEN (let's release anyway) #430 and #444 : Image reader - Probably hard to tackle,

Re: [JPP-Devel] New

should be fixed in r5285 ..ede On 27.12.2016 22:40, edgar.sol...@web.de wrote: > hey Peppe, > > do you know which setting would that be from the top of your dead? > > ..ede > > On 27.12.2016 22:25, Giuseppe Aruta wrote: >> Hi Ede, >> I gave a look to your new changes on Sextante. There is a

Re: [JPP-Devel] New

hey Peppe, do you know which setting would that be from the top of your dead? ..ede On 27.12.2016 22:25, Giuseppe Aruta wrote: > Hi Ede, > I gave a look to your new changes on Sextante. There is a small regression: > The algorithms help pages don't show the images anymore. > I did a test

[JPP-Devel] Fwd: Re: SVN: [5270] core/trunk

Mike, your fix looks good :).. the whole class was a mix of tabs/spaces. just reformatted & committed it. ..ede Forwarded Message Subject: Re: [JPP-Devel] SVN: [5270] core/trunk Date: Mon, 19 Dec 2016 10:48:31 +0100 From: edgar.sol...@web.de To:

Re: [JPP-Devel] SVN: [5270] core/trunk

hey Mike, yeah had that still in my inbox, like so much else ;(.. will work through it over the holidays.. btw. indention of your additions looks wrong (tabs?).. ede On 19.12.2016 10:37, jump-pilot-...@lists.sourceforge.net wrote: > Revision: 5270 >

Re: [JPP-Devel] String attrib line breaks

Mike, you wanna go ahead and check the table's properties? probably it's just a setting that needs to be enabled. i still got sextante and some other issues i want to tackle. ..ede On 17.12.2016 23:05, Michaël Michaud wrote: > Hi, > > I we introduce a linebreak in an attribute (I did it with

Re: [JPP-Devel] String attrib line breaks

i have the feeling that the table by default does not allow line breaks and we have to enable line breaks for the table fields. didn't research it so far though. ..ede On 17.12.2016 17:20, Michaël Michaud wrote: > Hi, > > I also noticed that a few days ago. > > I suppose (but I'm not sure)

Re: [JPP-Devel] String attrib line breaks

On 17.12.2016 22:22, Michaël Michaud wrote: > Adding a whole library for a single function is quite expensive, but > xml-escaping is probably secure now, and maybe we'll find other benefits > to use commons-lang. well, actually there are already some references in core to commons-lang. most by

Re: [JPP-Devel] String attrib line breaks

On 17.12.2016 17:20, Michaël Michaud wrote: > Anyway, if some formats does not support line breaks, the problem should > probably handled by their driver not in the copy/paste plugin ;-) that's what i would have expected. please check out the "new" escaping in GMLWriter, it should survive

[JPP-Devel] String attrib line breaks

hey All, is there a specific reason why i cannot copy/paste line breaks into a string attribute? ..ede -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org!

Re: [JPP-Devel] SVN: [5262] core/trunk

right, another route to go would be automatically xml escaping the characters (eg. '\n' becomes '') and leaving it to the reader to interpret them or not. ..ede On 16.12.2016 13:35, Michaël Michaud wrote: > Hi Ede, > > Whoops, thanks ! > > Yes, GML writer is somewhat archaic. But changing

<    4   5   6   7   8   9   10   11   12   13   >