123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081 |
- Major missing features:
- - add postscript output (partially done)
- - add option to include/omit helper vecs and frames (done for display, still
- need postscript). Better idea: in PS, print the component 10x, 1x, and then
- each individual frame 10x.
- Minor missing features:
- - reorder variables in a frame (can use text editor)
- - move items/vectors up and down the hierarchy
- Error detection:
- - eliminate duplicate instances
- Style and usability:
- - make column of entry field greedily consume all unallocated space
- - make menu bar consume all unallocated space instead of sharing it evenly with
- upper toolbar
- - status area looks awful
- - add button with GTK_STOCK_UNDELETE for "undelete" to menu bar
- - maximizing pad name size creates uneven text sizes. Particularly "1" gets
- excessively large.
- - pango_layout_get_size doesn't seem to consider rotation, so we currently
- don't properly size rotated text.
- - when changing the part, we should automatically switch to a configuration
- that generates any of its (non-global) elements
- - add zoom controls to top toolbar
- Bugs:
- - default silk width has no business being hard-coded in obj.c
- - undelete only works if not much has changed since the deletion
- - focus should return to canvas if nobody else wants it
- - whenever we call parse_* for input parsing, we may leak lots of expressions
- - can't edit measurement labels through the GUI
- Code cleanup:
- - merge edit_unique with edit_name
- - merge find_var_in_frame with similar mechanisms in expr.c and fpd.y
- - add regression tests
- - the drag logic is too complex. Better: let tool/instance just generate the
- list of points at each stage, then handle the highlighting and hovering
- inside a dragging module.
- - code organization is very poor. E.g., functions belonging to the different
- items (pads, silk objects, vectors, etc.) should be grouped by item, not by
- type of function, similar to how some things are now with gui_meas.c
- - eval_string_var should be merged into eval_var and the result should be a
- struct num (?) that can contain both types. This also means changing all the
- ops to handle/reject strings.
- Open decisions:
- - Q: should loop be (start, last) or (start, iterations) ? or start ... last ?
- - change vector circle color ? (also, highlight on hover ?)
- - Q: allow reassignment of vector names ?
- A1: no: would cause confusion in GUI (vectors could become orphaned)
- A2: yes. but we don't change the linkage.
- - Q: how do we handle stacks of objects ?
- A1: we don't but we make it easy to avoid them, by giving a good zoom,
- flexible selection, and by disallowing stacks of identical objects in the
- first place.
- A2: the current mechanism of selecting the next eligible object when clicking
- on the same position repeatedly lets one cycle through stacks.
- - Q: add frame arguments ? (e.g., .frame pad(pin_num_offset) ...)
- A: we can already approximate this by introducing an intermediate table that
- sets up the arguments (provided that we don't consider vectors as well)
- - Q: should we make it a requirement to generate objects only once ?
- A: yes.
- Future directions:
- - future: consider using cairo instead of gdk
- - live update of value when entering strings and expressions ?
- - advanced: non-standard solder mask
- - advanced: solder paste exceptions (subtractive, additive)
- - advanced: silk line width
- - future: consider editing non-canvas items (e.g., variable names/values) in
- place
- - add a means to cut&paste and copy&paste objects, and perhaps also variables
- (to move objects, we need to make sure all references are included. besides
- that, copy&paste should be a slight variation of delete/undelete)
- - instead of blue screening, we could perhaps just skip the offending items and
- replace them with a "here's a problem" marker that would still point to the
- underlying object and allow repairs to be made
|