htoigo / cabinet-calc Goto Github PK

Add a desktop application GUI built with Qt.

Modify list of allowed materials and default thicknesses to

These are the default thicknesses of the materials. They must still be changeable to something else, as lots do vary in thickness. For example, gray melamine lots are often 0.74" thick.

I would like to add the toe kick or stainless steel leg placement in the full run drawing on the PDF 2nd page. Can we ask in the gui the following:

1.what toe kick fabrication is to be used? (Stainless Leggs with clip-on toekicks -or- plywood box frame)
2. what is the height of the toekick?

The GUI window has a input field for a bottom thickness, different from the other thicknesses specified. However, this is not used anywhere in the code.

The command line interface has no way to specify a different bottom thickness or use one.

A job with a full width of 155" and filler panels on left, right, or both ends will say that it needs one or two 0" fillers.

Another example: A job with a full width of 256" and fillers on either or both ends will come up with 0" fillers.

Fillers should be between 1 and 4 inches, generally. Or user specified.

Sometimes fillers are wanted to get some space from a wall for the cabinet door to open. 1" might be good in that case.

Should we add to the GUI a Filler Width: input field, which defaults to blank, and the user can leave it blank.

Investigate: If the job comes up with 0" filler(s) and the user wants filler(s), try different filler widths within the allowable 1-4" range, and see what cabinet width results. Then choose the nicest cabinet width.

For now, we will only allow 2 doors per cabinet, because layouts that include single-door cabinets are significantly more complicated. They would be upper cabinet runs, with varying cabinet widths and heights. Later, after release 1.0, we may add the ability to handle upper runs with varying heights, widths, and number of doors per cabinet.

Lock number of doors per cabinet at 2, but leave an indication of 2 doors per cabinet, so the user knows that is what they are getting.

On cutlist individual panel drawings, move the material string to a new line below the thickness, and possibly put it in all (small) caps. So instead of

3/4" Ply

we would have

3/4"
PLY

This will be narrower, and less likely to overflow the width of the panel.

If primary material thickness is changed to something other than the default 0.75 inches, the door thickness remains at 0.75 inches.

Add user choices to interface:

• Choose to base dimensions on countertop or cabinet bank.
• Specify countertop overhang on left, front, right. All default to 2.0".
• Specify countertop thickness (1 1/2" - laminate; 1 1/8" - stone)
• Toe kick fabrication style: plywood box frame or stainless steel legs with clip-on toe kicks.
• Specify height of toe kick: 4" or 6"; usually 6".

Add more unit tests. Automate running tests via a test runner.

Currently we have just one material choice. We need two:

Primary material should default to Plywood. Door material should default to Melamine.

The bottom panel material is always the same as the Primary material, right?

Depth dimension includes depth of door and gap, but doors are not on drawing.

Reduce depth dimension shown with arrow on cutlist isometric drawing by an amount equal to the depth of the door + gap.

In the cutlist isometric drawing of the single cabinet, the length of the depth lines, which are currently rendered at a 45-degree angle, is not to scale.

Currently there is only one way of drawing dimension arrows on the cutlist isometric drawing and individual panel drawings. When the width is too narrow, the arrow may not be completely visible.

Add two new styles for narrow spaces.

One, for when there is just enough space for the numerals and inches mark:

-->| 4" |<--

and one for when there is not enough space even for the numerals:

-->| |<--
^-- 4"

Reduce size of margins on all sides on cutlist pdf. Currently they are 1" on all sides. Try 1/2".

The back panel appears to be twice as thick as the side panels. Need to adjust.

The number of fillers determines whether the sides are open.

If one filler, we need to be able to specify which side / end it is for. That end will be closed / unfinished.

2 fillers: Both ends unfinished.
1 filler, Rt: Left end finished. Right end unfinished.
1 filler, Lt: Left end unfinished. Right end finished.
0 fillers: Both ends finished.

The job.summarln returns a string which ends with '\n', but other job sections return lists of lines which do not end in '\n' characters. This inconsistency unnecessarily complicates the wrapping function we define, text.wrap(). If we refactor this code to be more consistent, we should be able to do away with our custom wrap() function, and just use the standard library's textwrap.wrap or .fill.

Let's use Travis CI to start.

The output is not scrollable, so if the window is not big enough to display the entire output, there is no way to see it.