The HobNoteBook code is a complex custom widget which adds maintenance overhead without buying us much. It was originally developed as gtk.Notebook was presumed lacking in API to meet the visual design, specifically the badges on a tab displaying an appropriate count/number and the search entry in-line with the tabs. The first can be addressed through gtk.Notebook's API to include a widget inside the tab. We can develop a custom widget which acts as the badge and then a container subclass with a label and badge child can be set as the tabs widget. The second is easily addressed using the gtk.Notebook.set_action_widget() API.
Created attachment 456 [details] Screenshot demonstrating a gtk.Notebook with badge and search entry
Created attachment 457 [details] Code implementing the prototype displayed in the screenshot. This short piece of code prototypes a badge widget and inline search entry using the standard gtk.Notebook.
Add Belen and Shane to CC: I think we should make this change before 1.2 release as it improves the consistency of the application with the rest of the users OS and further reduces the amount of custom complex code we need to maintain and bugfix in 1.2.
The implementation of the HobTabBar and HobNotebook classes which provide the custom API are ~430LOC (including whitespace). I believe strongly that replacing this large set of custom code with much smaller widget subclasses (less than 100LOC based on the attached prototype) and using the standard toolkit API will increase the maintainability of the code base and reduce the amount of potential bugs (when using the trusted method of inferring bug count by LOC). The severity of this issue is debatable and something I'd want design input on. The integration of the classes developed for the prototype into Hob would likely be 2D work so this change would be cutting it rather fine for 1.2.
Estimate 2D work for this. This should mean patch submission by EOD Thurs.
Sync with Shane and the consensus of the triage team is to have this fix in for 1.2 base on Josh's comments
Created attachment 465 [details] Current implementation
Created attachment 470 [details] Fixed version Here's a screenshot showing implementation with the boxes composited out. This is good to go!
Created attachment 471 [details] Showing the non-selected state
I've just realised that the API the patch relies on is too new for CentOS 6. It seems unlikely the patch can be merged at this point?
Joshua: this is excellent work. If it doesn't make for 1.2 I hope we can get it in for 1.3 Just a few (very small comments): 1. Increase the width of the search text field. Now that we have space, we should use it 2. I would take out the blue line in the selected tab. It seems to me the selected state is strong enough visually to do without it. If you feel you need to reinforce the selected state, we could use a higher font weight for the tab label (a little bolder). 3. Reinforce the table headings: they tend to blend with the table content. Increasing the font size slightly, increasing the heading height and some extra top margin to clearly separate them from the bottom of the tabs would probably help. 4. Recipe name column: this column has a different background colour. That seems unnecessary and undermines the zebra style, which tries to reinforce the visual relationship between content in the same row across different columns 5. Increasing slightly the height of the rows would give the table text some space and probably make it a bit easier to read 6. The search field 'clear' icon should only appear once there is something to clear (i.e. when I have typed a search query) 7. In the screenshot showing the Tasks tab selected, the tab label is enclosed in a blue box. I am not sure why this is. I am listing the above mainly for documentation purposes. Hopefully we'll have a visual designer for 1.3 work that will provide specifics to help implementation. Belen
I just wanted to explain why some of the raised details are that way. (In reply to comment #11) > 2. I would take out the blue line in the selected tab. It seems to me the > selected state is strong enough visually to do without it. If you feel you need > to reinforce the selected state, we could use a higher font weight for the tab > label (a little bolder). That's because It's the active row, I'd clicked it (and shown the persistent tooltip). We can remove highlighting of the selected/active row. > 4. Recipe name column: this column has a different background colour. That > seems unnecessary and undermines the zebra style, which tries to reinforce the > visual relationship between content in the same row across different columns This is to indicate that it's the active, sorted, column. If I click one of the other column headers to sort the table by that column it will have the different background colour. > 7. In the screenshot showing the Tasks tab selected, the tab label is enclosed > in a blue box. I am not sure why this is. This is to indicate that widget has focus. This is useful if I'm using a keyboard, or other input device, to move focus.
(In reply to comment #12) > I just wanted to explain why some of the raised details are that way. > > (In reply to comment #11) > > 2. I would take out the blue line in the selected tab. It seems to me the > > selected state is strong enough visually to do without it. If you feel you need > > to reinforce the selected state, we could use a higher font weight for the tab > > label (a little bolder). > > That's because It's the active row, I'd clicked it (and shown the persistent > tooltip). We can remove highlighting of the selected/active row. Sorry: I didn't mean the row, but the active tab (Included). It has a blue line along the top which I guess tries to indicate it is the active tab. Maybe it is brought in by the theme. > > > 4. Recipe name column: this column has a different background colour. That > > seems unnecessary and undermines the zebra style, which tries to reinforce the > > visual relationship between content in the same row across different columns > > This is to indicate that it's the active, sorted, column. If I click one of the > other column headers to sort the table by that column it will have the > different background colour. I suspected so, but it is the wrong approach to indicate the selected column for sorting. Using another cell colour dilutes the zebra approach in the table and creates visual noise. We are better off using the column heading. Currently an arrow indicates the selected sorted heading: we could reinforce it with a different visual style in the heading font. > > > 7. In the screenshot showing the Tasks tab selected, the tab label is enclosed > > in a blue box. I am not sure why this is. > > This is to indicate that widget has focus. This is useful if I'm using a > keyboard, or other input device, to move focus. Understood. Thanks!
(In reply to comment #13) > (In reply to comment #12) > > I just wanted to explain why some of the raised details are that way. > > > > (In reply to comment #11) > > > 2. I would take out the blue line in the selected tab. It seems to me the > > > selected state is strong enough visually to do without it. If you feel you need > > > to reinforce the selected state, we could use a higher font weight for the tab > > > label (a little bolder). > > > > That's because It's the active row, I'd clicked it (and shown the persistent > > tooltip). We can remove highlighting of the selected/active row. > > Sorry: I didn't mean the row, but the active tab (Included). It has a blue line > along the top which I guess tries to indicate it is the active tab. Maybe it is > brought in by the theme. Ah, yes. That's the theme's indication of the active tab.
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=44a40f7a569ac583a949a088f14f97f66b19af4f
Looking nice :)