> What I believe we need is a true composite so groups can be put underneath > groups, not just one level with foreground and background., i.e. we would > like to nest the composite controls. > > >
That is what the community module "table of contents" did. In generally I have seen developers try two approaches: - folders - "tags" It really depends what you are trying to communicate which way you go? Are you trying to organise information by some kind of categories (to make finding it easier?). Or are you trying to hide information so you can focus on a few layers? > > I was thinking of making a group be “named” and a > manifestation/exposure/association of a Composite Renderer – but I see your > point about not doing so. > > > Gak; I am not sure I followed you. I am a bit rusty on composite renderer .. catching up. That would actually be really fun - you may be able to set one composite renderer up (as like a "folder") and configure it to record the result with a bit more caching (such as "tileset" for smooth panning and so forth). And then let some normal layers draw themselves on top of it ... I would prefer (but this is just a preference) to focus on the how the user would like to use the layer view; and sort out things like where to put a composite renderer based on use at runtime. > > Grouping in a Legend view makes a lot of sense because it is separate from > Z-order and we can surely write code to turn the composite children on and > off. The children of the composite in this view being either another > composite or a layer. Thanks for the suggestion. > > > No worries. > > We will have to dig into the table of contents view in the community section, > and do some evaluation and perhaps explore these ideas and suggestions > further. > > > Cool let me know; I cannot join you this month but I think I will have scope to collaborate depending on your timeline. > > We have also been developing for 18 months now and have some code changes > that we would like to contribute back to the udig code-base, so we are > wondering what is the process we should go through to have them evaluated for > inclusion? > > > Well answering that should be the job of the admin docs. - http://udig.refractions.net/confluence/display/ADMIN/Home - http://udig.refractions.net/confluence/display/ADMIN/How+to+take+part At a pragmatic level we are coming to terms with the "pull request" workflow, but usually for bug fixes we work from Jira issue+patch. After a few rounds of code reviews - you should find the project pretty relaxed about getting commit access etc.... But the basic thing is to have a balance of email, jira issues for the change logs. One thing I try to be good at is: - any change to the user interface should be reflected in the user guide - any change to the api should be reflected in the developers guide Cheers, Jody
_______________________________________________ User-friendly Desktop Internet GIS (uDig) http://udig.refractions.net http://lists.refractions.net/mailman/listinfo/udig-devel
