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. > 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? > cons: One X window per tab. > > I'm of the opinion that 3) is the best option in the long run, and > closely matches what is happening on the mac side. We do have the > drawback of having one X window per tab, but we also have the same > issue for all of the widgets in the renderer for example, and I'm at a > loss to provide a number for the memory requirement of each window. I don't think we have X windows for renderer widgets, but I think we shouldn't worry about that either way anyways. We should figure out the most maintainable and least-effort path is, and only stray from that if memory is a huge concern. --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
