On Tue, Feb 10, 2009 at 11:36 AM, Evan Martin <[email protected]> wrote: > On Tue, Feb 10, 2009 at 11:22 AM, James Hawkins <[email protected]> wrote: >> 2) Redesigned TabStrip using one GtkDrawArea, handling drawing and >> input to the tabs ourselves. >> >> Evan M. proposed that we use one GtkDrawArea for the entire TabStrip >> area of the window (a GtkDrawArea is just a container in which you can >> draw in.) We would have to handle placement and drawing of the tabs. >> We would also have to handle input for the tabs, i.e. calculating if a >> mouse click is within the bounds of a particular tab. > > Part of my argument is that the placement/drawing/mouse-clicking are > parts of the code we should share. >
TabStripModel = good, will use in any design. TabStrip depends on views::View and views::Button, so we'd need to implement that much of Views unless I'm mistaken. >> automatic input handling. Tab depth is controlled by ordering the >> drawing of the buttons. Since we're using a GtkFixed container, we >> can overlap the buttons/tabs to achieve the Chrome look. >> >> pros: Input handling is automatic, animation is simpler. > > It's not clear to me how animation plays into this. Could you elaborate? > In the case where each tab is a widget, the animation is achieved solely by moving the widget within the container. The difference is subtle, but to me it's simpler because the re-drawing is done for us and our custom drawing is abstracted away from the animation. --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
