Changes between Version 6 and Version 7 of Maintenance and architecture list


Ignore:
Timestamp:
Aug 4, 2011, 11:50:29 AM (14 years ago)
Author:
tony@gonk.net
Comment:

Tweaked formatting.

Legend:

Unmodified
Added
Removed
Modified

  • Maintenance and architecture list

    v6 v7  
    33 - remove all uses of Deprecated classes and then remove the classes themselves
    44
    5  - finish renaming kjs_xxx files in WebCore/bindings/js to more sensible names
     5 - finish renaming `kjs_xxx` files in `WebCore/bindings/js` to more sensible names
    66 - move things defined in WebCore but in the KJS namespace into the WebCore namespace
    77
    … …  
    1212 - rename the KJS namespace to JavaScriptCore
    1313
    14  - finish code moves from Frame to other classes (documented with comments in Frame.h)
     14 - finish code moves from `Frame` to other classes (documented with comments in `Frame.h`)
    1515
    16  - change CompositeEditCommand and EditCommand to not be derived and base any more; just separate classes
     16 - change `CompositeEditCommand` and `EditCommand` to separate classes (not derived and base any more)
    1717 - restructure undo handling for edit commands so that the the number of different types of undoable steps is smaller and they have much smaller granularity; we can write more robust versions of them
    1818
    19  - eliminate raw pointer use in favor of RefPtr/PassRefPtr
    20  - move ref/deref classes to the "start with 1" rather than "start with 0" approach
     19 - eliminate raw pointer use in favor of `RefPtr`/`PassRefPtr`
     20 - move `ref`/`deref` classes to the "start with 1" rather than "start with 0" approach
    2121
    22  - fix config.h situation
     22 - fix `config.h` situation
    2323
    24  The config.h file really only exists for platforms that don't have a "prefix header" mechanism.
     24 The `config.h` file really only exists for platforms that don't have a "prefix header" mechanism.
    2525
    26   1) On platforms with a prefix header, it should only have enough contents to make sure you get an error if you forget to include it.
     26    1. On platforms with a prefix header, it should only have enough contents to make sure you get an error if you forget to include it.
     27    2. Common things that need to be included everywhere should be in a separate header, which should be included in the prefix header on platforms that have it, and in `config.h` on platforms that don't.
     28    3. We probably shouldn't have a shared cross-platform file named `config.h`. For example, people building with autotools will want to use it to create `config.h`.
    2729
    28   2) Common things that need to be included everywhere should be in a separate header, which should be included in the prefix header on platforms that have it, and in config.h on platforms that don't.
     30 - fix platform `ifdefs` that are sprinkled around instead of being concentrated in the platform directory
    2931
    30   3) We probably should not have a shared cross-platform file named config.h. For example, people building with autotools will want to use it to create config.h.
     32 It's okay to have platform-specific code anywhere there's a good reason, but `<canvas>` is a good example of how '''not''' to do it.
    3133
    32  - fix platform ifdefs that are sprinkled around instead of being concentrated in the platform directory
    33 
    34  It's OK to have platform-specific code anywhere if there's a good reason, but <canvas> is a good example of how not to do it.
    35 
    36  - rationalize the top-level platform names
     34 - rationalize top-level platform names
    3735
    3836 Need a name for the Windows CoreGraphics port and the Windows Cairo port.
    … …  
    4341
    4442 - apply style guidelines more consistently to existing code
    45  - fix all the header guards to match the filenames by running `clean-header-guards`
     43 - fix all header guards to match filenames by running `clean-header-guards`
    4644
    4745 - move Objective-C bindings generation into Mac WebKit
    … …  
    4947 - move code that doesn't belong in WebCore into Mac WebKit
    5048
    51  Make the core perl script modular enough that the Objective-C stuff can live in WebKit. Eliminate the scripts that copy all the headers.
     49 Make the core Perl script modular enough that the Objective-C stuff can live in WebKit. Eliminate the scripts that copy all the headers.
    5250 There's still a lot of crap in there that can be moved down. WebKit is for binding to the Mac API and to Objective-C.
    5351 Things like the Objective-C accessibility wrappers should be in WebKit, with a C++ version in WebCore.