Root/
Source at commit 5fdea0e99a2e8543a59d508cf28e1f2ff3607f18 created 9 years 2 months ago. By Werner Almesberger, gui_canvas.c (key_press_event): make / rotate through packages as well | |
---|---|
1 | Major missing features: |
2 | - add postscript output (partially done) |
3 | - add option to include/omit helper vecs and frames (done for display, still |
4 | need postscript). Better idea: in PS, print the component 10x, 1x, and then |
5 | each individual frame 10x. |
6 | |
7 | Minor missing features: |
8 | - reorder variables in a frame (can use text editor) |
9 | - move items/vectors up and down the hierarchy |
10 | |
11 | Error detection: |
12 | - eliminate duplicate instances |
13 | |
14 | Style and usability: |
15 | - make column of entry field greedily consume all unallocated space |
16 | - make menu bar consume all unallocated space instead of sharing it evenly with |
17 | upper toolbar |
18 | - status area looks awful |
19 | - add button with GTK_STOCK_UNDELETE for "undelete" to menu bar |
20 | - maximizing pad name size creates uneven text sizes. Particularly "1" gets |
21 | excessively large. |
22 | - pango_layout_get_size doesn't seem to consider rotation, so we currently |
23 | don't properly size rotated text. |
24 | - when changing the part, we should automatically switch to a configuration |
25 | that generates any of its (non-global) elements |
26 | - add zoom controls to top toolbar |
27 | |
28 | Bugs: |
29 | - default silk width has no business being hard-coded in obj.c |
30 | - undelete only works if not much has changed since the deletion |
31 | - focus should return to canvas if nobody else wants it |
32 | - whenever we call parse_* for input parsing, we may leak lots of expressions |
33 | - can't edit measurement labels through the GUI |
34 | |
35 | Code cleanup: |
36 | - merge edit_unique with edit_name |
37 | - merge find_var_in_frame with similar mechanisms in expr.c and fpd.y |
38 | - add regression tests |
39 | - the drag logic is too complex. Better: let tool/instance just generate the |
40 | list of points at each stage, then handle the highlighting and hovering |
41 | inside a dragging module. |
42 | - code organization is very poor. E.g., functions belonging to the different |
43 | items (pads, silk objects, vectors, etc.) should be grouped by item, not by |
44 | type of function, similar to how some things are now with gui_meas.c |
45 | - eval_string_var should be merged into eval_var and the result should be a |
46 | struct num (?) that can contain both types. This also means changing all the |
47 | ops to handle/reject strings. |
48 | |
49 | Open decisions: |
50 | - Q: should loop be (start, last) or (start, iterations) ? or start ... last ? |
51 | - change vector circle color ? (also, highlight on hover ?) |
52 | - Q: allow reassignment of vector names ? |
53 | A1: no: would cause confusion in GUI (vectors could become orphaned) |
54 | A2: yes. but we don't change the linkage. |
55 | - Q: how do we handle stacks of objects ? |
56 | A1: we don't but we make it easy to avoid them, by giving a good zoom, |
57 | flexible selection, and by disallowing stacks of identical objects in the |
58 | first place. |
59 | A2: the current mechanism of selecting the next eligible object when clicking |
60 | on the same position repeatedly lets one cycle through stacks. |
61 | - Q: add frame arguments ? (e.g., .frame pad(pin_num_offset) ...) |
62 | A: we can already approximate this by introducing an intermediate table that |
63 | sets up the arguments (provided that we don't consider vectors as well) |
64 | - Q: should we make it a requirement to generate objects only once ? |
65 | A: yes. |
66 | |
67 | Future directions: |
68 | - future: consider using cairo instead of gdk |
69 | - live update of value when entering strings and expressions ? |
70 | - advanced: non-standard solder mask |
71 | - advanced: solder paste exceptions (subtractive, additive) |
72 | - advanced: silk line width |
73 | - future: consider editing non-canvas items (e.g., variable names/values) in |
74 | place |
75 | - add a means to cut&paste and copy&paste objects, and perhaps also variables |
76 | (to move objects, we need to make sure all references are included. besides |
77 | that, copy&paste should be a slight variation of delete/undelete) |
78 | - instead of blue screening, we could perhaps just skip the offending items and |
79 | replace them with a "here's a problem" marker that would still point to the |
80 | underlying object and allow repairs to be made |
81 |
Branches:
master