kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 10/8/2010 3:53 AM, jean-pierre charras wrote:
> Le 08/10/2010 04:11, Wayne Stambaugh a écrit :
>> On 10/7/2010 5:02 PM, Dick Hollenbeck wrote:
>>> On 10/07/2010 01:59 PM, Wayne Stambaugh wrote:
>>>> I'm getting ready to do some refactoring of the library object code and I
>>>> would
>>>> like to split the component library object file classes_body_items.cpp into
>>>> individual files per object.  This file is currently over 2000 lines long and
>>>> has become unwieldy to edit.  One thing I'm not particularly thrill about is
>>>> the current class_foo.cpp file naming scheme.  It seems redundant to me prefix
>>>> class_ to C++ source files.  Would any one object to them not be prefixed with
>>>> class_.  In other words lib_arc.cpp, lib_circle.cpp, lib_rectangle.cpp,
>>>> etc.  I
>>>> would like to get this complete before we create the branch for the new
>>>> library
>>>> stuff to prevent merge issues.  There is no formal policy on this so I thought
>>>> I would ask before I plow ahead.
>>>>
>>>> Wayne
>>>>
>>>
>>> I thought that was something dear to Jean Pierre.  For me the version
>>> control system support for renaming is a factor.  bzr says it handles
>>> it.  Mostly I don't care, because for the work I would do in a separate
>>> branch, I would not even start with any existing files.
>>
>> I think you are correct about JP liking the class prefix.  In fact I may
>> have been the one to ask this before.  It's hell getting old.  The
>> memory is the first thing to go.
> I used class_xxx as an easy way to find files relative to the xxx item
> a name like lib_item_xx (lib_item_arc.cpp, lib_item_arc.h) or sch_item_xxx is
> OK for me.

Thanks for the clarification.

> 
> We also must consider moving some files to a subdirectory.
> I am thinking mainly to *.fbp files and the automatically generated files by
> wxFormBuilder.
> But this can be made for some other files (all dialogs ?)

The .fbp and wxFormBuilder generated files would not be very difficult to move
but there is a lot of dialog code is mixed in with the main frame window code
that would require some pretty serious editing.  I agree with you that it
should be done as the number of files in the EESchema and PCBNew source
directories is getting rather large.  I may start moving moving some of the
easy stuff over to a dialog subdirectory as time permits.  I see this as an
incremental process that will take some time.

> 
>>
>>>
>>>
>>> They would be hand copied over one by one over but only if I needed
>>> them.  That branch might never make it to fully functional eeschema,
>>> just the lower level stuff only.  Then we'd have to park the GUI stuff
>>> on top of it, but until then I would not even want GUI stuff in the same
>>> directory, so that dependencies on the GUI do not crop in too early.
>>>
>>> This is an entire foundational restart in terms of the underlying datatrees.
>>>
>>> Once that is in place, then the GUI stuff is where most of the
>>> re-usability would come into play, and more files could come over, or we
>>> could bring the new files into the existing tree.
>>>
>>> It sounds good, untangling it is another thing, and it may be harder
>>> than it sounds.
>>
>>
>> This effectively means the new branch becomes EESchema as there would be
>> no way to merge it back into the testing branch without hand copying it
>> back over.  That could prove just as difficult as copying the UI parts
>> into tne new tree.  I'm not sure this it the way to go.  I'll sleep on
>> it.  Maybe I can see way more clearly tomorrow.
>>
>> Wayne
>>
> 
> Due to all changes, a new branch is reasonable.
> I assume the "new branch" is (in your mind) actually a new branch pushed to
> Launchpad,
> not a subtree of the current testing branch
> But (this is just an idea, I am not saying this is a good idea):
> Keep the testing branch, and just create a new tree like testing/eeschema2 in
> the current testing branch and keep the current version in testing/eeschema.
> In my mind, testing/eeschema2 is the new tree containing new files and subtree
> and can be seen as "the new branch"
> Compiling files in testing/eeschema2 could made on demand, using a build option
> for instance.
> testing/eeschema2 could contains only new files, an use files in
> testing/eeschema2 as long as they are compatible (if any).
> This is perhaps a convenient way to work on the old and new eeschema version
> and merge bug fixes or enhancements in common files.
> Common files can be updated (graphic functions, basic classes, dialogs for
> error reports ...) both for "old" and "new" eeschema versions more easily
> inside the same devel branch than if there are 2 branches.
> When eeschema2 becomes eeschema this switch will be more easy.

I like this idea.  It may get more people involved in building, testing, and
bug reporting if you do it this way.  When I wrote the wxGCDC code I thought
maybe one or two other people might give it a try.  I was surprised by the
number of people who tried it out and commented on it.  There was even a few
bug reports and fix commits on this code.  I doubt this would have happened if
I would have done this in a separate branch.  I'm wondering if Hueter would
have taken this route with his GAL code if we wouldn't be farther along the
path of having an improved graphics layer.  It may be worth the extra effort to
do it this way.

Wayne

>