Hi Matthias, I just thought I'd remake a suggestion Andrea made to me when I was looking at org/geotools/gui/swing/Legend.java which was to build an sld editor using "a property editor like widget, maybe based on the l2fprod property sheet panel (http://www.l2fprod.com/software/l2fprod-common/index.php)". (Original email at http://sourceforge.net/mailarchive/message.php?msg_id=8240852).
I never got anywhere with this, I think it's a good idea but maybe the its fallen out of fashion now. Property sheets might help give you that modern, appealing design you desire, and also gives you a framework for associating types of property/attribute with types of editor. Incidently, the old sld editor resides in http://svn.geotools.org/geotools/branches/2.1.x/ext/legend/, as you probably know. Although quite badly bug ridden it's almost usable, but I'm not sure whether it would be worth trying to salvage stuff from it. You might get some ideas. Anyway, a couple more comments... > - Support different output formats, e.g. SLD or the styles > used by our company. IMHO, I would say if people want to store styles in non-standard formats then it's up to them to deal with converting SLD to and from that format. Given that geotools generally tries to stick to OGC specs I would restrict a style editor widget to working with SLD. > > I should note that I have come to the conclusion that SLD > alone is not sufficient as style definition - for following reason: > SLD defines drawing rules but it does not store information > about how these rules were defined in terms of a GUI. In > other words, if you get an SLD style it is hard to deduce the > correct GUI type to to edit it. Isn't deducing an appropriate gui from a Style precisely the problem the style widget needs to solve rather than a reason for not basing the widget on SLD? (If I am interpreting you correctly.) I think the information you need to decide the correct type of gui-component/editor to use is contained in SLD. Essentially, I think "reads/imports SLD" needs to be one of the requirements for the widget and it sounds like the design your suggesting won't allow this? (Rob Atkinson's point I think?) > - Style type must be remembered (i.e. if a style shall be > edited, the widget should show the very same page with which > the style was defined in the first place) IMHO it should work out what that page looked like by examing the Style/SLD, rather than by reading a stored mix of style and gui configuration information. (If the style was defined using a plain text view of the XML I don't think its all that important that this style gets reopened for editing in a plain XML view rather than the corresponding gui view.) >As a bonus, the widget could provide a legend image for the created style. But that is far future. yes, I currently still use the old sld editor for this. hope I've not misinterpreted your thoughts too badly, cheers, colin > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Matthias Basler > Sent: 16 December 2006 13:00 > To: [email protected] > Subject: [Geotools-devel] GeoWidgets: Styling widget plan > > Hi Geotools community, > > I've long been absent from my GeoWidgets project, but now I > have Christmas holidays, and this means around one week of > time for almost anything - such as programming a new widget. > Coincidential, a styling widget seems to be on the TODO list > of every project: My company wants one (Swing), I want one, > Geotools wants one (Swing) and uDig would benefit of an > improved SWT based one as well, afaik. > Well, I call this a good opportunity... > > That's why I have thought about a design for the last weeks > and would like to start programming now. > > My requirements are: > - Modern, appealing design (but nothing extraordinary) with > icons symbolizing the different style types. > - Supporting different style types and a registry for them > - Supporting a style library for each type > - Serialization of the style definitions for this style library > - Style type must be remembered (i.e. if a style shall be > edited, the widget should show the very same page with which > the style was defined in the first place) > - Support different output formats, e.g. SLD or the styles > used by our company. > > I should note that I have come to the conclusion that SLD > alone is not sufficient as style definition - for following reason: > SLD defines drawing rules but it does not store information > about how these rules were defined in terms of a GUI. In > other words, if you get an SLD style it is hard to deduce the > correct GUI type to to edit it. Therefore my idea is: > > Styling widget with several styling pages for different style types > v ^ > ... creates ... ... calls for editing ... > v ^ > Style definition > (a simple java bean, but knows which style page was used to create it) > v > ... adapter classes creates ... > v > Output style (such as SLD, proprietary ones) > > Does this make sense? > > > I would like to start building a Swing version of such widget > first, because this is what is easier and needed by more > people. If successful, we can think about how to transfer the > concept to uDig/SWT maybe... > > That's it for now. Ideas are welcome. > -- > Matthias Basler > [EMAIL PROTECTED] > > > -------------------------------------------------------------- > ----------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the > chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge > &CID=DEVDEV > _______________________________________________ > Geotools-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
