Re: Scripting approach for a splittable window?
Hi David, I guess not too many Revers are heavily into drawing applications. Several months ago I started to do pretty much what you're describing, but got discouraged because I knew I had already done something similar to it years ago using FutureBasic, and it wasn't nearly as difficult. More direct. It was the drawing tools that gave me the most problems. Instead of using panes, if I remember correctly, I had the master (whole) drawing off-screen, but had trouble efficiently moving around the drawing with scrolling, panning or zooming. Basically, I wanted to duplicate MacDraft in Rev, so I could give it features MD doesn't have and probably never will. Unless you have a very large monitor, as I do, dividing it into 4 panes seems to be not very useful, since it would be, perhaps, more useful to merely be able to zoom or pan portions of the master-page to the full screen. Good luck. I look forward to your progress. Joe Wilkins On Sep 8, 2009, at 4:51 PM, David Epstein wrote: Has anybody tried to build a scrollable, horizontally and vertically splittable window interface that allows a user to create and freely add, delete, and edit graphic objects or fields in any pane of the window? The true page size might be much bigger than can be shown in the window at any one time, but the objective is to let the user split his view and inspect any 2 vertical regions and any 2 horizontal regions (as in a spreadsheet). I can think of various ways this might be approached, and wondered if anyone has experience or advice. Should we make 4 groups with identical content, adjust their scroll properties appropriately, and when a user edits one group automatically change all the others (and, in that case, should this be done by copying a created or modified object, or by replacing each entire group with a copy of the changed one)? Should we maybe keep a master page off screen entirely, and copy objects from that master page to the appropriate pane by checking the rect of each object against the pane's intended scroll position? Or should the master set of objects be alternately hidden, shown in a pane, or cloned in several panes, based on a list of their logical locations that gets compared with the intended pane scroll positions? Or should we maybe construct each pane from an image of a rect of the master page, and when the user tries to edit a pane swap in the real objects, or a scrolled view of the master page? Or something else entirely? Many thanks. David Epstein ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Scripting approach for a splittable window?
Joe Lewis Wilkins wrote: I guess not too many Revers are heavily into drawing applications. Several months ago I started to do pretty much what you're describing, but got discouraged because I knew I had already done something similar to it years ago using FutureBasic, and it wasn't nearly as difficult. More direct. Coming from many years with SuperCard, this is one of the very few areas where I've been disappointed with the Rev experience. The design philosophy with SC was that all tools are available to the scripter for use in their apps, and because the pointer tool is used in a very different context from the browse tool is has its own set of messages (pointerDown, pointerUp, pointerDoubleUp, etc.). For many years Rev the philosophy seemed to be that the pointer tool, while available to developers to use if they can, exists primarily for the benefit of layout tasks within the IDE. There is some merit to this approach, but also some compromises. The upside is that the arrow tool was really only useful for working with native primitives (buttons, fields, etc.), and modern drawing apps like MacDraft need more complex objects anyway so historically the thinking was that if you need complex objects use the browse tool and emulate all of the pointer tool behaviors. The downside was that it sounds simple enough, but ask anyone who's done it just how simple it is to maintain each object in a nested group which contains a group of control handles for indicating selection and resizing. It's a lot of work to set up, adds a tremendous amount of complexity to your code, and noticeable lags when you work with it relative to the snappy performance and ease of implementation with the pointer tool, where selection handles just naturally come along for the ride. Rev took a giant leap forward toward supporting the crafting of modern drawing environments with v3.5, which now allows groups to have their own selectGroupedControls property settable independently of the global property of the same name. In conjunction with 3.5's new group-specific messages, and with Behaviors so you can manage any number of custom control instances from a single script, you can now craft custom controls which work gracefully with the pointer tool in many circumstances. But there are still a few weaknesses: Line and polygon objects still cannot be interactively resized to be perfectly horizontal or vertical. It's not merely that it doesn't support the conventional convenience of doing this automatically when dragging with the Shift key, it simply can't be done at all without the new editMode property, which carries subtle but important implications that make it suboptimal for end-user drawing environments, as Ken notes here: http://quality.runrev.com/qacenter/show_bug.cgi?id=7706 Also, some mouse messages are only sent to controls when the pointer tool is active, while they're also sent to the card when the browse tool is active, such as dragEnter, making it difficult for a drawing pane to respond to some events. We might consider using a graphic object at the back of the drawing pane to catch such messages, and with the cantSelect property settable so that the object will always behave as though the browse tool is active that will indeed get the message. But the downside is that it then prevents drag-selecting around objects with a marquee. Another challenge is not being able to interactively create controls within groups. If your app provides a way for a user to add a shape, you must use drag-and-drop to do so (trapping mouseMove to compensate for the absence of dragEnter, as noted above), because there's currently no tool mode specific to groups. http://quality.runrev.com/qacenter/show_bug.cgi?id=623 Alternatively you could let the user create the control above the group and copy it into the group on newGraphic, newButton, etc., but if the new control overlaps the scrollbar it just looks wonky. Another benefit to having tool modes being specific to groups is that you could then easily have a single window with multiple panes in which some of those panes are tools and others are the drawing region. This is as common in modern apps as using palettes for tools has been historically, and in Rev can only be done if you set the selectGroupedControls of every object outside of your drawing pane to true (and also suspend the IDE when you're working on such things, as most mouse messages are trapped by the IDE when the pointer tool is active). Scaling the drawing region can be done in script, but is very cumbersome and error-prone. A strong nice-to-have would be the ability to scale the display of stacks and groups: http://quality.runrev.com/qacenter/show_bug.cgi?id=6589 All that said, Rev 3.5's new behaviors, and group-specific messages and properties, took the engine a giant leap forward for making drawing apps. With a few more enhancements to
Re: Scripting approach for a splittable window?
After my long-winded rant I felt I at least owed it to David to answer his original question - David Epstein wrote: Has anybody tried to build a scrollable, horizontally and vertically splittable window interface that allows a user to create and freely add, delete, and edit graphic objects or fields in any pane of the window? There are a good many ways to do this, but hopefully this example will be at least a little helpful: go url http://fourthworldlabs.com/rev/splitter-experiment.rev; It's a very rudimentary four-pane layout I threw together in just a couple minutes for you, so it's missing a lot of the finishing touches like cursor changes, resize limits, etc., but may help you get started working with multi-pane layouts. With the Dictionary pointers at the end of my long message earlier, you should be able to add support for adding and manipulating objects within those groups. Keep us posted on how it works out. -- Richard Gaskin Fourth World Revolution training and consulting: http://www.fourthworld.com Webzine for Rev developers: http://www.revjournal.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Scripting approach for a splittable window?
Has anybody tried to build a scrollable, horizontally and vertically splittable window interface that allows a user to create and freely add, delete, and edit graphic objects or fields in any pane of the window? The true page size might be much bigger than can be shown in the window at any one time, but the objective is to let the user split his view and inspect any 2 vertical regions and any 2 horizontal regions (as in a spreadsheet). I can think of various ways this might be approached, and wondered if anyone has experience or advice. Should we make 4 groups with identical content, adjust their scroll properties appropriately, and when a user edits one group automatically change all the others (and, in that case, should this be done by copying a created or modified object, or by replacing each entire group with a copy of the changed one)? Should we maybe keep a master page off screen entirely, and copy objects from that master page to the appropriate pane by checking the rect of each object against the pane's intended scroll position? Or should the master set of objects be alternately hidden, shown in a pane, or cloned in several panes, based on a list of their logical locations that gets compared with the intended pane scroll positions? Or should we maybe construct each pane from an image of a rect of the master page, and when the user tries to edit a pane swap in the real objects, or a scrolled view of the master page? Or something else entirely? Many thanks. David Epstein ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
