Hi, I'm currently designing the Linux TabStrip. We have several options to pick from, one of which I am in favor of, but I will list all of the options on the table.
1) Port Views. This option keeps lingering in our minds, because while it would take a large effort to port, we would benefit from not having to re-implement the TabStrip model. The problem with this is that if we pull in tabs, we pull in the kitchen sink with it. pros: No re-implementation of TabStrip. cons: Total (?) implementation of the Views rendering layer. 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. pros: One window for all tabs. cons: Input handling, animation of tabs is more complex. 3) Redesigned TabStrip using a GtkFixed container and custom GtkButtons, input handled by Gtk. In this scenario, we use a GtkFixed container (a container where the widgets inside are controlled by the developer, set at the pixel level and not the layout level.) Each tab is a customized GtkButton. We override the drawing of the button to get our custom look. The implementation would use gdk_window_shape_combine_region and gdk_window_input_shape_combine_region which would allow for transparent tabs (which is required if we want to use buttons) and 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. 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. Any comments or suggestions? I'm interested in feedback devs from all three platforms. -- James Hawkins --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
