This file contains some possible things to do in future versions of xfig. make xfig understand and use different file resolutions (e.g. 1200dpi) allow rotated boxes (not just polygons) reduce number of grid lines (if necessary) when zooming < 1.0 fix grid rounding problems at 0.75 zoom factor allow printing of grid in figure make the rulers understand the real screen resolution according to the server add the concept of "layers" for each depth. That way a user may work on certain layers at one time, masking out or overlaying the other layers as desired. make middle mouse button DELETE previous points just created during create POLYobject/ARC/Ellipse etc. That way, one may backup when creating objects. create resource for "print" command (e.g. lp, lpr, whatever) which uses meta- notation to place filename (e.g. print_command: "lpr -P%p %f" where %p is the printer string and %f is the filename) make line counter update correctly when reading multiple-line POLYLINES and SPLINES from input file allow vertically-aligned text "top" would mean the insertion point specifies the line over the top of the text "middle" would mean that it specifies the midline of the text (I'm not sure how this is defined, perhaps the average of top and base or top and bottom. "base" would mean the line under all letters which do not hang down. For example, g and j extend below the baseline. "bottom" would mean the time under the bottom of the text including descenders. have arc sub-type 2 for pie wedge-type arcs have common edit popup for all four splines to allow conversion between all save modified_flag before file operations and restore if undo used Should arrow size change in update mode when linewidth changes? investigate whether eps objects that don't have a preview bitmap are scaled correctly change eps_bitmaps so that background is transparent (needs to work in normal and reverse-video modes). Make popup windows come up so that they don't overlap the figure (if possible). An edit popup window should at least not overlap the object being edited (again only if possible). Use fill pattern (grey-shading) to mimic color objects on monochrome systems. Extend smart links to work for SCALE, MOVEPT and perhaps EDIT, UPDATE. Could also extend them to work for arc-type links and for ellipse/circle objects and objects inside compound objects. Also, at the moment smart-links only work for one end of a link if both ends of the link happen to touch the object being operated on. To fix this would require changing the F_linkinfo structure to have left_endpt, left_prevpt, right_endpt, right_prevpt fields instead of the current endpt, prevpt and two_pts fields. Make xfig resources more consistent with normal use of resources in X clients. e.g. provide support to allow each command button (say) to be a different color. Ditto for mode buttons, etc. investigate if we should be setting initialResourcesPersistent to false for widgets that are created and destroyed as required. Still need to think about how point positioning should be utilized with many of the editing commands, e.g. if point positioning is set to large grid and you are trying to move an object, should: a) it be ignored, b) you can pick up an object anywhere but you must put the 'pick-up' point back on a grid posn, c) you have to pick up and put down objects at grid posns, d) you can pick up and place an object anywhere but when you place it, the point on the object closest the pickup point is automatically rounded to the nearest grid posn, e) you can pick up objects anywhere and movement is multiples of the grid size. The current behaviour is c) and b) can be mimicked by changing the point posn indicator mid-move. It has the disadvantage that you may not be able to pick up an object which isn't on the grid points. I think e) is the next best but it won't let you mimick b). Use clipping rectangles in more places: use the redisplay_* routines as necessary. allow popup menus to be pinned? have a resource which can be set to keep backups during a save, instead of prompting the user about overwrite etc. make a keypad label: This should popup in the mousefun window whenever a panel for entering text is entered. The kbd_ic icon is already there. zooming of text is still a kludge. (It doesn't work properly yet) make arcs use pw_curve to speed them up. add bounding box to every F_object definition, useful for: 1) faster drawing of rubber objects 2) handling the selective redrawing of figures better after they become the innocent victim during an expose or erasure of another object things like pan/zoom/resize/iconify will still leave junk on the screen or mess up the figure if you are in the middle of drawing it: One solution is to call canvas_rightbut_proc whenever the action_on flag is set and one of the above functions is called. This forces the operation being performed to be cancelled - probably not a good idea for panning - we might be trying to pan a little bit to place the last point in a large object. Another solution is to have a big case statement which performs a single elastic draw of whatever object is being drawn/moved etc. The function would need to be called before an iconify (or whatever) and again after the operation was completed. This would allow drawing operations to be continued after window functions had been performed. A third solution is to use a canvas_elasticdraw_save parameter instead of using a case statement - it would need to be set prior to every elastic draw operation. Generalize align mode (like glue mode) to allow arbitrary tagged objects to be aligned rather than just compounds. Additional align mode options for distributing objects evenly within a compound or abutting them together: abutT, abutB, abutL, abutR, distH, distV Some facility to provide better support for small screens. e.g. scrollable mode button list or automatic resizing to have several rows as needed. A good test is to limit the total space to 640x480 so that it is still useable on an IBM-PC VGA screen. Make a raise/lower depth feature: the raise_ic icon is already in w_icons.c Make xfig understand depth better: If you set the depth using the object edit panels, xfig will redraw them correctly, however it would be nice if as you entered new filled objects that they were automatically given an appropriate depth. This would involve finding the depth of all overlapping (filled?) objects and setting the depth to be one less. What about support for negative depth values? -------------------------------------------------------------------- The following items would require a change to the Fig file protocol: -------------------------------------------------------------------- extend color model to include 24-bit color use floating point coordinates for objects (at least internally to xfig if not in the figure file) super/subscripts for text objects allow background color for figure and store in fig file - also requires that fig2dev knows about this background color allow fractional text sizes (float) possibly make extension to Fig protocol to handle several line cap/join styles (e.g. round, butt, miter) write 8-bit characters as (e.g.) \341\321 -------------------------------------------------------------------- What really needs to be done is a major rework of the list structures used to store xfig objects. Here are some comments involving the change. -------- note about restructuring xfig data structures ------------- Rather than having a depth attribute for objects, you can use the order in which objects are entered to determine their depth: later objects appear on the top. A raise/lower depth operation would allow you to change the ordering. The consequences to the current implementation of converting totally to this scheme are non-trivial. Instead of having separate lists for each object type, you need to have a single list which has a union of all the different objects as its type. This will require changes in many places in the code. At the moment there are many places where each of the lists are traversed separately. In many cases the code can be simplified dramatically if there was only a single list. For example, to perform a move on an object there are separate routines (one for each object type) to start/cancel/place the object. You could replace this by a single routine for start/cancel and place which worked no matter what type you had. (Who says you can't use object-orientation in C :-)). Another advantage is that the current caching scheme for redrawing would no longer be needed (i.e. redrawing would be greatly simplified). Also undo would become simpler (I think). If we want to make a smooth transition from the current scheme to the one described above (and I do), here is how I propose we do it: We need to change every direct access to the current lists to use functions. i.e. something like for (a=objects.arc; a!=NULL; a=a->next) ... to be something like for (a=first_arc(); a!=NULL; a=next_arc(a)) ... At the moment these routines would be simple to implement. Once all occurrences had been changed, it would simply be a matter of changing the underlying list structure and changing the first_arc, next_arc routines. Then as we had time we could replace whichever sets of six loops by a single loop which did for (o=first_obj(); o!=NULL; o=next_obj(o)) ... -------- end of note about restructuring xfig data structures -------------