I want to toss around what's on my mind, and solicit feedback regarding the design decisions for context surrounding the elements.
First of all, let me clarify what the context is: it is everything that doesn't necessarily belong in the postscript representation of an element. Thus the context includes at least: - selection status - edit stack - transformation matrix stack - UI rendering and interaction settings (booleans in XCWindowData) - edit node (cycle) Currently the context is somewhat split between the XCWindowData structure, and the element itself. This split is arbitrary and I don't think it implies at all that we can have multiple independent windows onto the same page. By independent windows I mean that each window has its own selection list and edit context: you can edit things in one window, stop mid-task, do something in another window without interfering with the first one, then resume. Even though this might be a useful thing to have, it's still somewhat hard to implement (for sufficiently large value of somewhat). After all, one needs not only a per-window editing/selection context that overlays the elements, but also a notification system so that changes done in one window propagate to another. Qt has a versatile graphical scene system that covers notifications, indices via binary space partitioning, minimal repaints, and whatnot. The only thing it doesn't support is independent edit contexts: a QGraphicsItem has selection and other interaction as part of its state. While we of course won't save such context to the output file, it's still maintained within the QGraphicsItem class. There are also QGraphicsItems that represent rich text editing fields, and I think those can be tweaked to replace the current text editing machinery, after I figure out how to properly visually handle the parameter display. The way it's done now is a usability no-no: you don't want to move your gaze potentially far away from the focal point just to inspect the text element display in the lower right corner of the window! Note that you can still have multiple windows that view the same QGraphicsScene; with exception of view transformation, they display the same thing: if you see a text editing cursor in one of them, you'll see the same in the other, etc. The mirroring (repaint dispatch) is done behind the scenes. This at least mimics our current behavior as coded; I haven't actually tried multi-window XCircuit in action. I think that as tempting as a per-window selection/editing context would be, correctly implementing it from scratch is about as hard as implementing it by modifying the QGraphicsItem/QGraphicsScene. The benefit from the latter is that it would be generic code that could enjoy wider use, and could be potentially rolled into Qt. In other words: I won't be doing that anytime soon, but volunteers are welcome -- it'd be a nice, self contained project. The current plan is thus to use QGraphicsItem as-is, and to start moving the functionality over to it. My original plan was to do it piecemeal. So my first step was to delete the selected and selectlist members from XCWindowData and add it as a QList<generic*> selection in the UIContext class. As soon as I started touching all the now non-compiling code, it became obvious that the selection should track deleted objects, otherwise you have to remember everywhere you modify a plist to check the selection, and it's just very messy and bug prone, and presents a barrier to entry for hacking. And as tempting as it was at that point to sprinkle the code with smart pointers and smart pointer collections, it's obvious that this is just all replicating Qt code for the dubious benefit of working by small, almost mechanical changes. This won't do -- not for me, at least ;) So I have to move elements over to QGraphicsItems, change the Area widget to derive from a QGraphicsView, and work on getting all of the editing code in events.c to work with the event system implemented in QGraphicsItem. Incidentally, almost all of the data structure management code other than undo code will vanish. A lot of editing code will only implement what Qt doesn't, instead of the whole deal. And so on. At this point methinks there's no way around doing this big leap -- the more I delay it, the longer I keep Qt being used merely as a widget and basic data structure toolkit. If anyone wants to explore Qt code, the public repository is on gitorious; <http://qt.gitorious.org/qt/qt/trees/4.7/src/gui> The graphics item system is in <http://qt.gitorious.org/qt/qt/trees/4.7/src/gui/graphicsview> The path stroking API in <http://qt.gitorious.org/qt/qt/blobs/4.7/src/gui/painting/qpainterpath.h>, implemented in similarly named files. Cheers, Kuba _______________________________________________ Xcircuit-dev mailing list [email protected] http://www.opencircuitdesign.com/mailman/listinfo/xcircuit-dev
