← Back to team overview

kicad-developers team mailing list archive

Re: [PATCH] Patchlets

 

On 5/15/2012 7:31 AM, Lorenzo Marcantonio wrote:
At last I remade the work...

001     Warnings (let free to ignore the hashmap if it doesn't compile,
         for me it's a mystery!)

002     MIN_PAGE_SIZE/MAX_PAGE_SIZE into PAGE_INFO
         ON/OFF to true/false

003     Numeric timestamps of type time_t (instead of various
         long/unsigned long/int)

004     EDA_ITEM m_Flags and m_Status converted to enums

005     Unused constant defines in bitmaps.h

006     A couple of const

007     m_NumberOfScreen renamed to m_NumberOfScreens (to avoid
         confusion with ScreenNumber)

008     LastEditTime of time_t, too

009     The drawmode (GR_COPY, GR_OR...) coverted to an enum

010     Colors always represented as an EDA_COLOR_T, not ints
         (EDA_COLOR_T is a 'structured' enum)

011     Removed the SCH_POLYLINE class

012     Applied the ID_DRAWFRAME around
         Some const around
         SAFE_DELETE from preprocessor macro to template
         Removed EDA_MSG_ITEM copy constructor since it's doing nothing
         particular

013     Mostly const stuff
         Renamed NB_MAX_SHEET to NB_MAX_SHEETS (why the limit anyway?)

014     Converted MIN/MAX usage to the standard min/max functions

015     Converted trivial functional macros to inline (ABS, NEGATE,
         DEG2RAD, RAD2DEG, the angle normalizations). The EXCH was simply
         reimplemented without any need for typeof or similars

         Strange thing: I tried converting TO_UTF8 but it didn't work...
         maybe the duration of utf8_str() is soooo short? no idea

016     The layer number from int becomes LAYER_NUM (original name!)

017     Replaced all the ugly (1<<  layer) with GetLayerMask

018     Layer bitmaps (like visibles, enabled and so on) become
         LAYER_MSK (which aligns to LAYER_NUM!)

019     Another round of layer number/mask search and replace
         Route_Layer_BOTTOM, Route_Layer_TOP, DrcOn and other pcbnew
         globals renamed with the frontal g_

020     FMT_IU and FMT_ANGLE to inlines; DANGLING_END enumerations put
         inside the class; removed std:: qualifiers from string in
         sch_item_struct (since there is a using namespace directive at
         the top...)

021     Split SCH_BUS_ENTRY in SCH_BUS_WIRE_ENTRY and SCH_BUS_BUS_ENTRY
         with a common SCH_BUS_ENTRY_BASE abstract ancestor

022     Split SCH_LINE in SCH_WIRE, SCH_BUS, SCH_NOTE_LINE with
         SCH_LINE_BASE abstract ancestor

023     Refactored the GetPenSize functions. Now there are common
         functions for bus pen size (GetBusPenSize) and text pen size
         (GetTextPenSize). Also the libitem implementation was moved to
         the base since actually the choice for the member to use is done
         by GetWidth() (graphic items use m_Width, text items use
         m_Thickness)

024     Removed m_Layer from SCH_ITEM. IsTerminalPoint refactored by
         necessity from SCH_SCREEN to the SCH_LINE_BASE hierarchy. The
         'main' color for SCH_ITEM is returned by GetEntityColor.
         Not too satisfied about the solution for GetNetListItem in the
         SCH_TEXT hierarchy (SCH_TEXT doesn't do a thing in it, the
         derived classes do almost the same thing... for just one
         function a hierarchy rework is too much)

025     Complete removal of the 'layer' concept from eeschema. There was
         an issue with the MAX_LAYER/MAX_LAYERS constant (one enumeration
         and one define) which caused the spurious warning when changing
         colors: it was an array out of bound access, most probably.
         Also since all the members of g_LayerDescr were dead (the only
         live thing was the LayerColor array), I junked the whole class
         and only the global color array remains (g_EntityColors)

(remember, all of this started with a warning when changing color :P)


Lorenzo,

Do these need to be applied in order? I just committed patch 003 and tried to apply patch 004 and it failed. This was what I was afraid was going to happen. I don't have a lot of free time to track down the patch errors so I'm going to have to depend on you to keep them synched with the repo and feed them to me one a time until we get through them. Patch 004 failed to apply in at least 6 files. I didn't apply patch 001 because of the problem with hash map compiling and I didn't apply patch 002 because of Dick's comments. I will attempt to apply the remaining patches as time permits but my guess is as I get further down the list, more patches will fail. I'll keep you posted as I work my way through the list. Thank you in advance for your help.

Wayne


Follow ups

References