← 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!)

         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

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...)

         with a common SCH_BUS_ENTRY_BASE abstract ancestor

         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

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)

Mailing list: https://launchpad.net/~kicad-developers
Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


I should have been more specific when I asked you to break this into smaller patches. I was hoping you would submit them one at a time for comment and then if there are no objections I would commit each patch. It will be difficult to comment on all of these patchlets without this email thread spiraling out of control. The other problem I see is that by the time I get a few patches into it, the later patches may not apply cleanly. Hopefully that wont be the case.

I don't want to dampen your enthusiasm because you are doing some good work here but for future reference, please submit patches that fix a single issue and give everyone a chance to take a look at it. It just makes things easier for everyone involved.

I should start applying these patches over the next week or two so if anyone has any concerns, please let me know. Thanks again for your efforts.


Follow ups