Re: [JPP-Devel] MultiInputDialog is a "jack of all trades device"

2012-02-13 Thread Benjamin Gudehus 
2012/2/13 Stefan Steiniger 

> btw. Not saying that shouldn't break backward compatibility.
> However, that would be then OJ 2.0 if we are going to clean up
> everything and really seperate GUI from api etc more strict. Though.. we
> have sooo many plugins...
>

If we go through all plugins that make use of MultiInputDialog (I count 63
plugins) and
prepare them systematically by writing unit tests and list all dialog
fields as class fields,
then I think it's the matter of one single commit to convert them all for a
new api.


> A dream of mine would be to come up then with a complete new
> browser-based & HTML 5 based GUI (on Firefox?). But that's a dream, and
> would need a year of development I guess... So I rather concentrate on
> writing documentation for now.
>

HTML5 guis are a bit overrated. First we would need to build a second API
between
the JTS and OpenJUMP API (Feature, Layer, LayerManager) and the HTML5 web
application. With second API I mean a RESTful web service.

I personally think the next gen OpenJUMP "desktop" gui could look like this:
http://www.maxon.net/uploads/pics/CINEMA_4D_Screenshot4_04.jpg

(Instead of Perpective => LayerViewPanel, Objects tab => Layers tab,
Structure tab => Selection tab, Attributes tag => Feature attributes tab,
Materials view => Layer styles view.)

And we need to split the toolbar into two toolbars (main toolbar and cursor
tools toolbar)!

There could be a classic view mode, too. With the simple LayerNamePanel on
the
left side and LayerViewPanel on the right side.

--Benjamin

Am 07.02.12 01:04, schrieb Michaël Michaud:
> > Hi
> >> Now I see that AbstractMultiInputDialog is accually a new class:
> >>
> >> Here are the complete changes to MultiInputDialog as of September,
> >> 2011 (big html file):
> >>
> https://github.com/hastebrot/openjump-core-rels/commit/2cb45edcf44e4b3c4e1c3ffa29c0ab742abce77f#diff-48
> >>
> >
> > Original MultiInputDialog was quite good from my point of view,
> > but not so easy to extend and I wanted to reuse the component
> > management facilities in a MultiTabInputDialog (see the new
> > Matching plugin).
> > That's why I tried to separate the component management logic
> > (AbstractMultiInputDialog) from the UI itself (implementation
> > class). Also a constraint for me was to keep all methods of the
> > class named "MultiInputDialog", not to have to rewrite plugins.
> >
> > I'm not saying this is the best way to go, just explain the background
> > as it maybe useful if you want to improve it ;-)
> >
> > Michaël
> >>
> >> 2012/1/26 Benjamin Gudehus  >> >
> >>
> >> MultiInputDialog uses GridBagLayout for mainComponent (see
> >> MultiInputDialog.java:109).
> >>
> >> My dialog currently uses JGoodies Forms layout, but I recently had
> >> a look at
> >> DesignGridLayout and this layout is pure awesomeness (it is only
> >> 84kb as class
> >> files and only one single package).
> >>
> >> 2012/1/26 Landon Blake  >> >
> >>
> >> I can see you have given this a lot of thought. I've been
> >> wanting to take a look at the code under discussion since
> >> Michael has done some of his work. Which layout class does the
> >> MultiInputDialog use?
> >>
> >> Landon
> >>
> >>
> >> On Wed, Jan 25, 2012 at 6:17 PM, Benjamin Gudehus
> >> mailto:hasteb...@googlemail.com>>
> >> wrote:
> >>
> >> Hi Landon,
> >>
> >> I think we should keep MultiInputDialog as simple as
> >> possible. It provides
> >> a simple dialog with some accessible fields, some buttons
> >> and an optional
> >> description with icons. And it does this well.
> >>
> >> *(1) Code interface concepts*
> >>
> >> Let's look at the classes. Here are some statistics:
> >>
> >> MultiInputDialog.java = 503 lines, 8 fields, 21 public
> >> methods, 8 private methods.
> >> AbstractMultiInputDialog.java = 867 lines, 12 fields, 41
> >> public methods, 6 private methods.
> >>
> >> 41 public methods (!!!), I don't think that's a good sign.
> >> And we should avoid inheritance
> >> here!
> >>
> >> As I mentioned it consist basically of three parts:
> >>
> >> * MainComponent (is row based with Labels and JComponents)
> >> * OkCancelPanel (Button bar with Ok and Cancel)
> >> * SideBarPanel (InfoPanel with Image and Description)
> >>
> >> The MainComponent has the labels with string text and the
> >> components. In
> >> the class these components are added to a HashMap:
> >>
> >> protected HashMap
> >> fieldNameToComponentMap = new HashMap();
> >>
> >> You can add new fields with the addRow method:
> >>
> >> addRow(String fieldName, J

Re: [JPP-Devel] osgeo-live

2012-02-13 Thread edgar . soldin 
On 13.02.2012 03:55, Stefan Steiniger wrote:
> yeah...thanks Ede!

stop it already ;)

>> Works fine, great thanks to Ede for the hard work.

the installer was much harder in terms of effort.. ede

--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

[JPP-Devel] [ jump-pilot-Bugs-3486850 ] loading *.ecw on MacOSX with OJ 1.5.1 fails

2012-02-13 Thread SourceForge . net 
Bugs item #3486850, was opened at 2012-02-11 14:03
Message generated for change (Comment added) made by edso
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=679906&aid=3486850&group_id=118054

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: OpenJUMP - Menu - File 
Group: MacOSX
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: loading *.ecw on MacOSX with OJ 1.5.1 fails

Initial Comment:
When loading an ecw file I get the following error message:

java.lang.Exception: no jecw in java.library.path
at 
com.vividsolutions.jump.workbench.imagery.ecw.JNCSRendererProxy.throwAsException(JNCSRendererProxy.java:68)
at 
com.vividsolutions.jump.workbench.imagery.ecw.JNCSRendererProxy.(JNCSRendererProxy.java:60)
at 
com.vividsolutions.jump.workbench.imagery.ecw.ECWImage.init(ECWImage.java:75)
at 
com.vividsolutions.jump.workbench.imagery.ecw.ECWImage.(ECWImage.java:70)
at 
com.vividsolutions.jump.workbench.imagery.ecw.ECWImageFactory.createImage(ECWImageFactory.java:73)
at 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset.createImage(ImageryLayerDataset.java:77)
at 
org.openjump.core.ui.io.file.ReferencedImageFactoryFileLayerLoader.createFeature(ReferencedImageFactoryFileLayerLoader.java:215)
at 
org.openjump.core.ui.io.file.ReferencedImageFactoryFileLayerLoader.open(ReferencedImageFactoryFileLayerLoader.java:120)
at 
org.openjump.core.ui.plugin.file.open.OpenFileWizard.run(OpenFileWizard.java:131)
at 
org.openjump.core.ui.plugin.AbstractWizardPlugin.run(AbstractWizardPlugin.java:73)
at 
com.vividsolutions.jump.workbench.ui.task.TaskMonitorManager$TaskWrapper.run(TaskMonitorManager.java:152)
at java.lang.Thread.run(Thread.java:680)

stefan

--

>Comment By: ede (edso)
Date: 2012-02-13 03:14

Message:
this is expected behaviour. there is no ecw native support available. would
you rather like to have ecw disabled?

..ede

--

Comment By: mentaer (mentaer)
Date: 2012-02-11 14:24

Message:
Another note: With the error message the file dialog gets closed, but
somehow a second dialog instance is still lurking around that can not be
closed.

It might be this is related to my fix for data loading on MacOSX?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=679906&aid=3486850&group_id=118054

--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] OpenJUMP roadmap updates

2012-02-13 Thread edgar . soldin 
On 11.02.2012 16:38, Giuseppe Aruta wrote:
> Ede, maybe the 1.5 branch needs to be synchronized with r1730 before new 
> commits are made in the trunk.
> Ede, do we need to synchronize 1.5 with the trunk now or can we synchronize 
> at any time with any release?

i am not sure about that. never used branches with svn before. but quite 
clearly as soon as we add unstable code to trunk we cannot automagically merge 
both trees anymore.
we will have to manually add bugfixes to both branches at all time then. that's 
why i am sceptical about svn branches, but let's give it a try. found an 
encouraging article here:
http://www.dehora.net/journal/2006/02/subversion_tips_dealing_with_branches.html

..ede

--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] OpenJUMP roadmap updates

2012-02-13 Thread Benjamin Gudehus 
If only branches was easy like in Git. "git rebase" for the win.

2012/2/13 

> On 11.02.2012 16:38, Giuseppe Aruta wrote:
> > Ede, maybe the 1.5 branch needs to be synchronized with r1730 before new
> commits are made in the trunk.
> > Ede, do we need to synchronize 1.5 with the trunk now or can we
> synchronize at any time with any release?
>
> i am not sure about that. never used branches with svn before. but quite
> clearly as soon as we add unstable code to trunk we cannot automagically
> merge both trees anymore.
> we will have to manually add bugfixes to both branches at all time then.
> that's why i am sceptical about svn branches, but let's give it a try.
> found an encouraging article here:
>
> http://www.dehora.net/journal/2006/02/subversion_tips_dealing_with_branches.html
>
> ..ede
>
>
> --
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] OpenJUMP roadmap updates

2012-02-13 Thread edgar . soldin 
On 13.02.2012 12:21, edgar.sol...@web.de wrote:
> On 11.02.2012 16:38, Giuseppe Aruta wrote:
>> Ede, maybe the 1.5 branch needs to be synchronized with r1730 before new 
>> commits are made in the trunk.
>> Ede, do we need to synchronize 1.5 with the trunk now or can we synchronize 
>> at any time with any release?
> 
> i am not sure about that. never used branches with svn before. but quite 
> clearly as soon as we add unstable code to trunk we cannot automagically 
> merge both trees anymore.
> we will have to manually add bugfixes to both branches at all time then. 
> that's why i am sceptical about svn branches, but let's give it a try. found 
> an encouraging article here:
> http://www.dehora.net/journal/2006/02/subversion_tips_dealing_with_branches.html
> 

ok, just merged stable_1.5 to the latest bugfix in trunk history, this means i 
excluded the north arrow as it is a new feature.

obviously it is easily possible to merge changesets from one branch to another, 
assuming they have no conflicting changes. 
http://svnbook.red-bean.com/en/1.6/svn.ref.svn.c.merge.html
i used subclipse though, it essentially just clicktoolizes the described above.
but this has still some back drafts:
- merging has to be done to a local checkout
- the afterwards commit then is like a sum up of all selected changesets for 
the merge, so we have to be a bit proper to include in the comments what 
revisions we merged
- commit messages should be prefixed with the branch name for easier 
distinction e.g. stable_1.5: ...

because i am skeptical of the effort of merging every bugfix into stable_1.5 i 
suggest we properly comment every trunk commit and select the bugfix changesets 
from time to time, should be done by a release maintainer (me for now).
i also suggest not to wait to long between bugfix releases. i'd say 10 bugs 
maximum or one severe bug are a good reason to release. especially as the 
routines are now fully automated.

..ede

--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] MultiInputDialog is a "jack of all trades device"

2012-02-13 Thread Stefan Steiniger 

Hei Benjamin,

I was actually not talking about the internal plugins but all the 
Extensions that we have in the plugin section listed... and I guess a 
couple of people also developed their own... like SkyJUMP & AdbToolbox ones.


Is Cinema4D browser-based? couldn't find anything on that when I shortly 
browsed.
Because I think if we do something new, then it should go towards a web 
browser-based application...

anyway.. no resources there for now ;)

stefan

On 13/02/2012 2:44 AM, Benjamin Gudehus wrote:

2012/2/13 Stefan Steiniger mailto:sst...@geo.uzh.ch>>

btw. Not saying that shouldn't break backward compatibility.
However, that would be then OJ 2.0 if we are going to clean up
everything and really seperate GUI from api etc more strict.
Though.. we
have sooo many plugins...


If we go through all plugins that make use of MultiInputDialog (I 
count 63 plugins) and
prepare them systematically by writing unit tests and list all dialog 
fields as class fields,
then I think it's the matter of one single commit to convert them all 
for a new api.


A dream of mine would be to come up then with a complete new
browser-based & HTML 5 based GUI (on Firefox?). But that's a
dream, and
would need a year of development I guess... So I rather concentrate on
writing documentation for now.


HTML5 guis are a bit overrated. First we would need to build a second 
API between

the JTS and OpenJUMP API (Feature, Layer, LayerManager) and the HTML5 web
application. With second API I mean a RESTful web service.

I personally think the next gen OpenJUMP "desktop" gui could look like 
this:

http://www.maxon.net/uploads/pics/CINEMA_4D_Screenshot4_04.jpg

(Instead of Perpective => LayerViewPanel, Objects tab => Layers tab,
Structure tab => Selection tab, Attributes tag => Feature attributes tab,
Materials view => Layer styles view.)

And we need to split the toolbar into two toolbars (main toolbar and 
cursor tools toolbar)!


There could be a classic view mode, too. With the simple 
LayerNamePanel on the

left side and LayerViewPanel on the right side.




--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

[JPP-Devel] [ jump-pilot-Bugs-3486850 ] loading *.ecw on MacOSX with OJ 1.5.1 fails

2012-02-13 Thread SourceForge . net 
Bugs item #3486850, was opened at 2012-02-11 14:03
Message generated for change (Comment added) made by mentaer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=679906&aid=3486850&group_id=118054

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: OpenJUMP - Menu - File 
Group: MacOSX
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: loading *.ecw on MacOSX with OJ 1.5.1 fails

Initial Comment:
When loading an ecw file I get the following error message:

java.lang.Exception: no jecw in java.library.path
at 
com.vividsolutions.jump.workbench.imagery.ecw.JNCSRendererProxy.throwAsException(JNCSRendererProxy.java:68)
at 
com.vividsolutions.jump.workbench.imagery.ecw.JNCSRendererProxy.(JNCSRendererProxy.java:60)
at 
com.vividsolutions.jump.workbench.imagery.ecw.ECWImage.init(ECWImage.java:75)
at 
com.vividsolutions.jump.workbench.imagery.ecw.ECWImage.(ECWImage.java:70)
at 
com.vividsolutions.jump.workbench.imagery.ecw.ECWImageFactory.createImage(ECWImageFactory.java:73)
at 
com.vividsolutions.jump.workbench.imagery.ImageryLayerDataset.createImage(ImageryLayerDataset.java:77)
at 
org.openjump.core.ui.io.file.ReferencedImageFactoryFileLayerLoader.createFeature(ReferencedImageFactoryFileLayerLoader.java:215)
at 
org.openjump.core.ui.io.file.ReferencedImageFactoryFileLayerLoader.open(ReferencedImageFactoryFileLayerLoader.java:120)
at 
org.openjump.core.ui.plugin.file.open.OpenFileWizard.run(OpenFileWizard.java:131)
at 
org.openjump.core.ui.plugin.AbstractWizardPlugin.run(AbstractWizardPlugin.java:73)
at 
com.vividsolutions.jump.workbench.ui.task.TaskMonitorManager$TaskWrapper.run(TaskMonitorManager.java:152)
at java.lang.Thread.run(Thread.java:680)

stefan

--

>Comment By: mentaer (mentaer)
Date: 2012-02-13 13:11

Message:
yep - in that case it should be disabled because its not a a bug but a
"non-available feature".

But, how does it come that we can load ecw on Ubuntu then. Is the unix
underneath so different?

--

Comment By: ede (edso)
Date: 2012-02-13 03:14

Message:
this is expected behaviour. there is no ecw native support available. would
you rather like to have ecw disabled?

..ede

--

Comment By: mentaer (mentaer)
Date: 2012-02-11 14:24

Message:
Another note: With the error message the file dialog gets closed, but
somehow a second dialog instance is still lurking around that can not be
closed.

It might be this is related to my fix for data loading on MacOSX?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=679906&aid=3486850&group_id=118054

--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel