BTW - Are GtkDrawAreas native widgets underneath? Can they be transparently rendered over others?
On Tue, Feb 10, 2009 at 11:22 AM, James Hawkins <[email protected]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
