So the first step to do now is to reorganize the views. The separation between the View and the Model since both of them exist in the same file. I always wondered why they are not separated, but now it kinda makes sense. For example lets look at the autocomplete_edit.cc: It consists of AutocompleteEditView and AutocompleteEditModel, would it make more sense to to create separate files called autocomplete_edit_model, autocomplete_edit_view_win, autocomplete_edit_view_mac, etc And refactor the current AutocompleteEditView and AutocompleteEditModel out of autocomplete_edit to platform specific classes? So we will have AutocompleteEditViewWin, AutocompleteEditViewMac etc That is why it would be nice to see what Adam has done so we could attempt doing one view and see if it passes the way chromium wants to port.
On Tue, Dec 16, 2008 at 12:18 PM, Amanda Walker <[email protected]> wrote: > On Tue, Dec 16, 2008 at 12:10 PM, Scott Violet <[email protected]> wrote: >> >> I believe the original thinking was that we would have view specific >> implementations per platform and the code would change to go through a >> factory for creating the leaf node views instead of using >> constructors. > > > Yes--this is why most of the view classes have associated "model" classes > that encapsulate the state and behavior. This way, view classes can use > platform facilities for drawing (GTK, GDI, Cocoa, etc.), but the bulk of the > logic behind the view can be platform neutral. > > I don't think that any of the current Windows view classes were ever > intended to be "ported" per se. > > --Amanda > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Chromium-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~----------~----~----~----~------~----~------~--~---
