Bugs - Infinite recursion - see fixme in "on_changed" - The whole "active slide" should be rethought. Probably we need to deal with an activate *range* of slides, in floating point. Thumbnail scrolling should be done whenever the integer rounding of that range changes. The thing we should keep at a fixed position as much as possible then is - top of first completely visible slide - of if that's not possible, top of first slide with a visible top - which reduces to "top of first slide with visible top" This location should survive all resizing. - Need to figure out how to deal with sizes. Clearly the desk should not know about viewports - it should just be passed a width when it needs it. - Slides should probably not know anything except be passed an appropriately transformed cairo_t. However, when items are tiny enough, they shouldn't be painted; also staffage may not make sense if it would just be a complete clutter, or if there simply isn't room for it. -=-=- - Think of a better name than oppress - Populist - Demagogue - Agitate - Vapour - Pep Talk - Deque - Features - Object Types - Text - Circles/ellipses - Arrows/Lines (or possibly distinct) - Rectangles - Polygons - Curves - Groups - Images - Helper lines - Mirror (references another item and paints it), changes to this item are reflected in the other. - Post-it notes - Trashcan - Objects draggable to screen - Objects should connect to each other, like in dia - "Mirror this object on all slides" - "Create animation from this object" - This will make a 'copy' of the object in such a way that when you change any properties of it, the new object will be animated into place. You can move sub-objects around for example, and an animation path will appear between an original 'ghost' and the new position. "Animate Onto Next Slide"? - Creates the copy on the next slide - If there is no next slide, then it creates one. "Create Animation target" "Duplicate slide with animations" - Templates - Is this more than 'mirror on all slides'? - Load/Save - Display full-screen - Deck has an associated screen size (1024x768 say), or it has a paper size. - Objects should be in a toolbar and be drag-and-droppable onto the canvas. - When you drag and drop a helper line and it gets close to the edges of a slide or to other helper lines, it should display the distance in pixels - or maybe it should display that all the time? - Lines and curves should auto-connect to circles and boxes, at first only to the drag points, but later to all of the stroke. - Curves should probably be automatically fitted to data points rather than making the user edit bezier control points. See An Algorithm for Automatically Fitting Digitized Curves from graphics gems. Google Scholar knows about a pdf, but the site is down. The autogenerated HTML is difficult to read. - UI - Objects can be selected by clicking on them. If more than one selection mode is available, you can iterate through them by clicking again. - Unfortunately, this probably won't work for text, where we need more than one selection mode: - select for resize (6 dots) - select for rotate (6 arrows) (Need this?) - select for move (note: drag is also selecting). - Editing the text could be seen as editing one property of the text, so double click to edit could be interesting. - Otherwise, there is a - toolbar should be on the left, and in maximized windows should stick to the edge. - A drawback of all this drag and drop is that it makes it more difficult to use on a laptops with a crappy pointing device. And making the slides on a laptop in a hotel room the night before is probably very common. - Image cropping. When an image is selected, a special selection mode available by clicking again. allows you to drag a crop rectangle around. A scissor is displayed next to it. - Staffage - Things that will not be visible in the final show will be shown in the same color, probably blue, maybe dashed. Post-it notes will have a light blue, translucent background, with a dark blue border. Or yellow, like tooltips? (There might be a reasonable distinction between temporary helper objects created by the app, and user created tings). - Implementation - Objects must be able to - Save themselves, plus generate an SFormat - Draw themselves, - in fullscreen mode - in edition mode - in thumbnail mode - Be selected - Edit themselves, probably - List properties - Draw themselves as a ghost - Paint their dnd source - When dnd begins, an object is created, and a grab is taken, but slide input areas are still active. slide_begin_drag (slide, new_object); The slide activates the grab and stores the new object. - on motion the object is invalidated, and has coordinates updated. Maybe there is a simple "move" method. - On release, the new object has "add to slide" called on it, and the object adds itself. - A Deck contains slides, which contain objects A deck can display itself at various size. It can tell its size given a width. It will call back when slides are added or removed, or when things like the page size changes. - When drawing an object, clip to the slide it belongs to. Staffage is not clipped - Raise/Lower of objects should follow this algorithm (lowering) (a) find all objects that are intersecting the object to be lowered (b) Of these, find the topmost one. (c) If one is found, lower the current item below it. - When forming a group, the objects within it retain their relative stacking order, but the new group item gets the position of the topmost of the constituent items. - Property box - One box to list all properties of an object? Impress has an impressive array of stuff: - fill (linear/radial/solid) - gradient editor (or can we put that in the canvas?) - stroke - all the same possibly? - arrows for lines (but they don't need fill) - Shadow - Gradient editor - Hatching - Only useful for presentations about x11perf There is no way I'm adding all that. - Can we drag and drop colors and bitmaps, like in nautilus? - Many of the properties can actually be done by adding a rectangle below it. With good snapping, this may be sufficient. - Can we take a group of items and drag it to the toolbar to make a template out of it? - An easter egg, but potentially very, very powerful. - Could be added to the menu as well to make it easier to find. - The simple combination of boxes and text may be a special case that interesting enough to be on by default - Or just adopt the ooffice convention of adding/edit text by double clicking. - Maybe the edge of a rectangle could be edited by clicking on it? That would possibly cut down on the number of widgets in the property window. - Objects can be cutted/copied/pasted of course - the serialization may simply be the sfile serialization (so sfile must grow the ability to serialize/read from memory, which it probably should have anyway). This means the natural way to do the object creation is to just have a prototype object that can be copied as necessary. The properties of that object is then the defaults. (An interesting thing here is that such serializations could be used desktop-wide if someone decides to actually write a worthwhile desktop some day). Ie., cut and paste of complex items, built from rectangles/circles/text etc. - Undo? - Update files in-place? - Undo manager. Whenever something changes about an item, an undo object is created and registered with an undo manager. An undo object contains a description, a callback and sufficient information to undo the operation - including a callback. undo_manager_add_undo (manager, const char *description, callback, data) When the callback is called, it generates another undo object, and adds it to the redo stack: undo_manager_add_redo (manager, desc, callback, data); The redo function will then add an undo object again. When something is added to the undo stack, the redo stack disappears. (Except if the redo function is adding the undo).