mirror of
git://projects.qi-hardware.com/fped.git
synced 2024-11-25 20:07:32 +02:00
393c178a5f
- gui_status.h, gui_status.c (edit_*): edit functions now accept a tooltip - added tooltips for editable status area items - tooltips on setup_set_type_* looked strange. Show them only for the value field next to the type field. git-svn-id: http://svn.openmoko.org/trunk/eda/fped@5776 99fdad57-331a-0410-800a-d7fa5415bdb3
86 lines
3.9 KiB
Plaintext
86 lines
3.9 KiB
Plaintext
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 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)
|
|
- 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
|
|
- unbalanced parentheses in text throw off Postscript syntax
|
|
|
|
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: 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: holes
|
|
- 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
|
|
- instead of the awkward lock-switch-anchor process for frame references, we
|
|
could just drag the frame name into the canvas
|