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

[Benjamin Gudehus]

Hi!

MultiInputDialog is what we call in germany an "eierlegende Wollmilchsau"
(lit. an egg laying wool-milk-sow, engl. jack of all trades device).

I really like the concept; and MultiInputDialog is very usable in terms of
creating dialogs for plugins easily. But it hides to much of the underlayout
Swing elements.

One year ago I started to rework some of the concepts for using it
in PlugIns. I'll present some of the aspects in a later post.

Regards
Benjamin
--
Keep Your Developer Skills Current with LearnDevNow!
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-d2d___
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"

[Michaël Michaud]

Hi,


MultiInputDialog is what we call in germany an "eierlegende Wollmilchsau"
(lit. an egg laying wool-milk-sow, engl. jack of all trades device).

I really like the concept; and MultiInputDialog is very usable in terms of
creating dialogs for plugins easily. But it hides to much of the 
underlayout

Swing elements.

One year ago I started to rework some of the concepts for using it
in PlugIns. I'll present some of the aspects in a later post.

Let's see !

I've significantly reworked the MultiInputDialog design about one year ago,
because I wanted to make it extendable to MultiTabInputDialog and to add
some other components like the one to choose a Layer's attribute.
I did not want to create a second framework and spent a considerable effort
to make it more extendable without breaking anything.

A long time before, I tried to introduce buoy ,which, I thought, had
a clever design for UI development (still used by simple query plugin),
but I used MultiInputDialog for all further developments.

Of course, there are probably other (better) ways to do, so I'm quite
interested into your proposition.

By the way, what is your use case ?

Michaël


Regards
Benjamin



--
Keep Your Developer Skills Current with LearnDevNow!
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-d2d


___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel


--
Keep Your Developer Skills Current with LearnDevNow!
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-d2d___
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"

[Benjamin Gudehus]

Hi Michaël!

2012/1/19 Michaël Michaud 

>  Hi,
>
> Let's see !
>

I will write something about the (1) code interface concepts and (2)
appealing
functional design in a later post.

I've significantly reworked the MultiInputDialog design about one year ago,
> because I wanted to make it extendable to MultiTabInputDialog and to add
> some other components like the one to choose a Layer's attribute.
> I did not want to create a second framework and spent a considerable
> effort
> to make it more extendable without breaking anything.
>

And it works well. One can even use the JCS Conflation Suite back from 2003
which makes use of MultiInputDialog and it works with newer versions of
OpenJUMP.


> A long time before, I tried to introduce buoy ,which, I thought, had
> a clever design for UI development (still used by simple query plugin),
> but I used MultiInputDialog for all further developments.
>
> Of course, there are probably other (better) ways to do, so I'm quite
> interested into your proposition.
>

> By the way, what is your use case ?
>

The use case is creating simple plugin configuration dialogs for scripting
enviroments, with the JComponents as fields in a class or with them
within a HashMap.


> Michaël
>

--Benjamin
--
Keep Your Developer Skills Current with LearnDevNow!
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-d2d___
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"

[Landon Blake]

It sounds like the MultiInputDialog class could evolve into a little
RCP framework for plug-ins?

Landon

On Wed, Jan 25, 2012 at 8:13 AM, Benjamin Gudehus
 wrote:
> Hi Michaël!
>
> 2012/1/19 Michaël Michaud 
>>
>> Hi,
>>
>> Let's see !
>
>
> I will write something about the (1) code interface concepts and (2)
> appealing
> functional design in a later post.
>
>> I've significantly reworked the MultiInputDialog design about one year
>> ago,
>> because I wanted to make it extendable to MultiTabInputDialog and to add
>> some other components like the one to choose a Layer's attribute.
>> I did not want to create a second framework and spent a considerable
>> effort
>> to make it more extendable without breaking anything.
>
>
> And it works well. One can even use the JCS Conflation Suite back from 2003
> which makes use of MultiInputDialog and it works with newer versions of
> OpenJUMP.
>
>>
>> A long time before, I tried to introduce buoy ,which, I thought, had
>> a clever design for UI development (still used by simple query plugin),
>> but I used MultiInputDialog for all further developments.
>>
>> Of course, there are probably other (better) ways to do, so I'm quite
>> interested into your proposition.
>>
>>
>> By the way, what is your use case ?
>
>
> The use case is creating simple plugin configuration dialogs for scripting
> enviroments, with the JComponents as fields in a class or with them
> within a HashMap.
>
>>
>> Michaël
>
>
> --Benjamin
>
>
> --
> Keep Your Developer Skills Current with LearnDevNow!
> 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-d2d
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>

--
Keep Your Developer Skills Current with LearnDevNow!
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-d2d
___
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"

[Michaël Michaud]

Hi Benjamin,
> 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).
Interesting,
It's always difficult to find layout managers which are both powerful 
and easy to use.
I hoped that inntroducing SpringLayout and GroupLayout would have 
helped, but I never
used them (maybe because they have been developped with builders in mind).

Michaël


--
Keep Your Developer Skills Current with LearnDevNow!
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-d2d
___
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"

[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...

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.

stefan

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, JComponent label, JComponent
>> component,
>> EnableCheck[] enableChecks, String toolTipText, int labelPos,
>> int fillMode)
>>
>> This method is overloaded with multiple methods.
>>
>> To add or get a centain typed component you may use
>> following methods:
>>
>> AbstractMultiInputDialog.getComboBox(String fieldName)
>> AbstractMultiInputDialog.addComboBox(String fieldName,
>> Object selectedItem,Collection items, String toolTipText)
>>
>> Many of the 41 public methods are just there, to handle
>> the components that
>> are stored in fieldNameToComponentMap.
>>
>> *(2) Appealing functional design*
>>
>> image.png
>>
>> If we pay attention on some design principles the dialogs
>> could look like this:
>> (I didn't include a description side bar, yet)
>>
>> image.png
>>
>> Some of the concept is found in the book Kevin Mullet, et
>> al.: "Designing Visual Interfaces", (1995).
>>
>> * I added a visual left column that only contains labels
>> (illustration 50 in the book)
>> 

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

[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] MultiInputDialog is a "jack of all trades device"

[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