1
0
mirror of git://projects.qi-hardware.com/fped.git synced 2024-06-30 22:42:17 +03:00
fped/TODO
werner e65d90947c - put hbox around frame table so that it doesn't grow when we give it more
space than it needs
- dump.c: separated ordering function from actual printing
- added list of vectors and object (on the right side of the variables)



git-svn-id: http://svn.openmoko.org/trunk/eda/fped@5423 99fdad57-331a-0410-800a-d7fa5415bdb3
2009-08-12 10:45:52 +00:00

75 lines
3.3 KiB
Plaintext

Major missing features:
- populate input area (still needed: mm/mil, rezoom)
- add default unit (combine with grid unit selection ?)
- consider adding auto/mm/mil selection for each dimension
- 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 frames (can use text editor)
- reorder rows in a table (can use text editor)
- reorder columns in a table
- reorder variables in a frame (can use text editor)
Error detection:
- eliminate duplicate instances
Style:
- 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
- edit names/values/etc. in place if possible
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
- when in uninstantiated mode, objects can be changed and then manipulated
through the unchanged instance. Tricky to fix without an alternate means to
access the object list. (Getting there.)
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 ?
A: 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.
- Q: add frame arguments ? (e.g., .frame pad(pin_num_offset) ...)
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: almost certainly 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: when encountering an error after a change, we could try to find the
same element in the old instance, and select it
- future: consider editing non-canvas items in place
- near future: treat part name as pattern