Dieter, I like the group idea, it shouldn't be too hard. I've always wanted to write a fast 2D metaball algorithm and now here's my chance (for the group outlines) :)
The hardest thing about the clusters is the behind-the-scenes-code. Once that has been rewritten from scratch (the current implementation really is horrific and goes counter to the whole idea of inheritance and encapsulation) we can try some different UIs and see which one works best (or have a simple UI and an expert-UI). I'll have a deeper look at graphviz, but I can't even find what language it was programmed in. -- David Rutten Robert McNeel & Associates On Aug 21, 7:36 pm, Dieter Toews <[EMAIL PROTECTED]> wrote: > David, > > First off thank you for creating this already amazing product! I’m > babbling on these forums so much because I am so excited about GH. > > Some more ideas - (maybe these are easy, maybe they’re for the 2035 > version or maybe they’re just plain bad – I’m just jamming): > > 1. Grouping > “. People group components in a way that makes sense to them, so we > definitely want to allow manual positioning of objects on the canvas, > which almost precludes auto-rearrangements when clusters are opened up/ > closed.” > > What you say is true but a way to hybridize the approaches might be to > say that instead of having individual objects locked to absolute > coordinates the idea of ‘position groups’ could be utilized. A > ‘position group’ (or perhaps simply ‘group’) would not collapse the > objects into a cluster but would instead lock there positions relative > to one another. They would maintain all of there pervious editablity > from the users point of view but know as far as the auto-layout would > then be concerned the components would move as a single block (& the > user could still manually move them as they do now to modify this > group.) When single (or multiple) objects are selected that are > members of a given group a visual queue could show other members (a > coloured outline, a glow behind, a transparent convex hull polygon > behind, something else, or a combination of these – I’m not sure). To > make a group the user could select a number of components and then > right click to “make position grouping” or use a new icon which could > be placed adjacent to the cluster icon. > > Summary: these groups would allow users to define areas which keep > there relationship to one another while still allowing things to move > out of the way as needed. > > 2. Opening Multiples > “I'd only allow a single cluster to be edited at any time, so there > would not be a profusion of floating windows.” > > Interesting, I hadn’t even considered being able to open more than one > at once, although I think you intuition is correct. I had thought (but > didn’t state) that by opening a cluster anything else that was open > would collapse. Although, come to think of it, it might make > comparison annoying, perhaps there could be a right click option to > “Open in a separate window” for this purpose. > > 3. Use of Libraries > “Using external libraries has not worked out for us so well in the > past” > > I hear you and I am sure that you know far more about this than I do. > I would, however, like to emphasize (for graphviz) that open source > projects have a tendency to be feature conservative, concerned with > legacy support, incremental, and focused on code cleanliness. The > licences can’t generally be revoked or expire & If the project takes a > direction not good for your project you can always fork a copy and do > the minimum maintenance required to keep it working well with your > project. > > 4. Implementation > “It also seems like it is currently more important to add new features > instead of polishing.” > > By all means – you’ve already answered my preverbal ‘make a wish > foundation’ by creating what you have so far – it’s only going to get > better. > > Cheers, Dieter Toews > > On Aug 20, 4:20 pm, David Rutten <[EMAIL PROTECTED]> wrote: > > > > > Hi Dieter, > > > I do think that using mnemonic queues in the interface is preferable > > to stuff blinking in and out of existence all the time, but having the > > canvas be auto-arranged all the time is unlikely to yield good > > results. People group components in a way that makes sense to them, so > > we definitely want to allow manual positioning of objects on the > > canvas, which almost precludes auto-rearrangements when clusters are > > opened up/closed. In my cluster-popup scheme, I'd only allow a single > > cluster to be edited at any time, so there would not be a profusion of > > floating windows. But instead of having a single popup window, I could > > also 'grey out' everything else and draw the expanded cluster directly > > onto the canvas, that is a minor change. > > > Using external libraries has not worked out for us so well in the > > past. Although sometimes it is unavoidable, I'd rather not depend on > > too much code I have no control over. It also seems like it is > > currently more important to add new features instead of polishing. > > Development seems to have slowed down a bit lately so I don't want to > > take on work that will cause large delays in the release cycle, and > > interface code is notoriously long-winding. > > > I'll put your comments on the do-this-when-there-are-no-more-gaping- > > holes-in-the-product-list. > > > Thanks for elaborating, > > David > > > -- > > David Rutten > > Robert McNeel & Associates > > Seattle, USA > > > On Aug 20, 10:37 am, Dieter Toews <[EMAIL PROTECTED]> wrote: > > > > Hi All, > > > - An Elaboration: > > > > Problem: > > > In a GUI how do I show an object which is a container for other > > > objects such that the blown-up version is still available for user > > > viewing & editing? > > > > Traditional (80’s solution): > > > Opening windows to view the contents of clusters/components/functions/ > > > objects is an easy way to deal with the problem of graphically > > > representing the Idea “hey you see all this stuff here, It all lives > > > in this little box in the main project over here” > > > > Problem With Traditional Solution: > > > As outlined in my previous posting in this tread the above solution > > > can quickly to millions of windows to manage and a difficult to track > > > data flow. > > > > To me what is really breaking here is the idea of working in context. > > > I believe this is coming to rhino 5 but for the sake of argument load > > > up skechup, create some clutter, and then drop a few instances of > > > component into the model. When you double click on a component to edit > > > it the default behaviour is to “dim” the context (the clutter), keep > > > the other instances normally lit but not highlighted and have a doted > > > bounding box around the instance you are now editing. > > > > Information implicitly-graphically represented in the above example > > > 1) I know what I am editing (other things are dimed) > > > 2) I know where there are other instances of the object (they are not > > > dimed but lack a bounding box) > > > > When there is a massive change in the visual information our brains > > > are presented with we need to adjust to this and during this period it > > > is easy to forget what you were doing (or a pertinent detail thereof). > > > In the physical world things always change smoothly (and appear to do > > > so 99.99% of the time) Think of it – we set a document on the table, > > > we turn a page, we draw a line. > > > > Finally the presence of context creates mnemonic queues so that if we > > > do forget what/why/how we were planning on doing something we can > > > recover more rapidly. > > > > Proposed Solution: > > > If we accepted that expert and novice alike benefit when an interface > > > is 1. smooth (animates between states) and 2. keeps context > > > information present - then we should apply it to our problem. > > > > Look again at the visual thesaurus. -www.visualthesaurus.com/ > > > Type in a word and then click on a related word; See how the visual > > > state of the information smoothly transitions from the presentation > > > one word to another. > > > > 1) How things would spring. Have a look at _aLinG_’s image for a data > > > splitting > > > idea:http://grasshopper3d.googlegroups.com/web/Wish_Data+splitting.jpg?gda... > > > This could be seen as an example of the “sprung” open state. When the > > > cluster is “sprung” open the objects around it would smoothly make > > > room and the internal workings would be presented inside a bounded > > > area. > > > > 2) Have two modes for clusters. Often one needs to open something just > > > because they need to understand what is going on inside (although > > > usually if the inputs and outputs are properly documented this > > > shouldn’t be necessary). > > > > Perhaps there could be something like the flipy triangle on > > > components:http://books.google.com/books?id=2uiGTSk9CFoC&pg=PA40&lpg=PA40&dq=mac... > > > > When the flipy triangle is clicked the cluster springs open for > > > viewing (everything remains similarly lit) > > > > When the cluster is double clicked the cluster springs open (and the > > > triangle automatically flips), other objects dim by some %, and other > > > instances of the same cluster remain normally lit but collapsed. > > > > Nested clusters could be handled by additive dimming (what ever the > > > current dim amount add % to the ojects current diming) > > > > I hope this helps. I’ll try to do a photoshop mock-up of the springing > > > process. > > > > Regards, Dieter Toews > > > > P.S. all this animation stuff and auto-layout stuff – I’m sure there > > > are libraries to take care of this so you only have to write glue > > > code. Does .net have an equivalent to OS X’s core animation? > > > OmniGraffle uses the graphviz library which is open source but under > > > the CPL so (I believe) it can be incorporated into commercial projects > > > -http://www.graphviz.org/. > > > > On Aug 19, 11:57 am, David Rutten <[EMAIL PROTECTED]> wrote: > > > > > Dieter, > > > > > I agree with those, I'd like to see all of those. At the moment the > > > > kernel of grasshopper is still in tatters due to a number of big > > > > changes (read: improvements) I made over the past few weeks. I need to > > > > get those fixed asap so I can get a new version out. Cluster instances > > > > are pretty high on my list, but they will take a lot of work. > > > > > I don't understand what you mean by components "springing" onto the > > > > canvas. Can you elaborate? > > > > > -- > > > > David Rutten > > > > Robert McNeel & Associates > > > > > On Jul 23, 7:03 am, dieter <[EMAIL PROTECTED]> wrote: > > ... > > read more »- Hide quoted text - > > - Show quoted text -
