Open Bug 367843 Opened 18 years ago Updated 2 years ago

wanted multi column for richlistbox

Categories

(Toolkit :: XUL Widgets, defect)

defect

Tracking

()

People

(Reporter: surkov, Unassigned)

References

(Blocks 2 open bugs)

Details

Attachments

(3 files, 3 obsolete files)

Richlistbox should have multicolumns like original listbox has.
Attached patch patch (obsolete) (deleted) — Splinter Review
Assignee: nobody → surkov.alexander
Status: NEW → ASSIGNED
Attachment #253072 - Flags: first-review?(mano)
Attachment #253072 - Flags: second-review?(enndeakin)
I'm undecided whether mutliple columns in a richlistbox is needed. In the patch, you're adding a pile of new tags yet not using them for any purpose. Did you want them to be unstyled? +richlistbox > scrollbox > box { + display: -moz-grid; +} + What is this for?
(In reply to comment #2) > I'm undecided whether mutliple columns in a richlistbox is needed. My point is richlistbox should be powerful not less than listbox. Probably multicolumn richlistbox haven't usecases for firefox/thunderbird but I believe it is very helpful for 3d party applications, so I has been asked by such firm to support this feature. > In the > patch, you're adding a pile of new tags yet not using them for any purpose. Did > you want them to be unstyled? I missed this point. I'll put new patch with the fix if multicolumn richlistbox idea will be approved. > +richlistbox > scrollbox > box { > + display: -moz-grid; > +} > + > > What is this for? > To force richlistbox look like grid. Richlistbox has anonymous content "scrollbox > box", -moz-grid style needs to have -moz-grid-... styled children.
(In reply to comment #3) > My point is richlistbox should be powerful not less than listbox I personally don't think that listbox should support multiple columns either. I don't think that having yet another way to create partially useful multi-column lists is a good idea. > To force richlistbox look like grid. Richlistbox has anonymous content > "scrollbox > box", -moz-grid style needs to have -moz-grid-... styled children. > But there isn't a box inside the richlistbox's scrollbox.
(In reply to comment #4) > (In reply to comment #3) > > My point is richlistbox should be powerful not less than listbox > > I personally don't think that listbox should support multiple columns either. > I don't think that having yet another way to create partially useful > multi-column > lists is a good idea. What is analogue for listbox there? xul:tree? But I can't see an analogue for richlistbox. > > To force richlistbox look like grid. Richlistbox has anonymous content > > "scrollbox > box", -moz-grid style needs to have -moz-grid-... styled children. > > > > But there isn't a box inside the richlistbox's scrollbox. > There is due to http://lxr.mozilla.org/mozilla/source/toolkit/content/widgets/scrollbox.xml#21
Attachment #253072 - Flags: first-review?(mano)
Does anyone have a XUL testcase for use with this patch?
Attached file testcase (deleted) —
Attached patch patch2 (obsolete) (deleted) — Splinter Review
added styles for headers
Attachment #253072 - Attachment is obsolete: true
Attachment #261101 - Flags: first-review?(enndeakin)
Attachment #253072 - Flags: second-review?(enndeakin)
Attachment #261101 - Flags: first-review?(enndeakin) → review?(enndeakin)
Comment on attachment 261101 [details] [diff] [review] patch2 Although I still don't think richlistbox should support multiple columns, I think we should just use the existing list* tags rather than creating new ones. Bug 376815 added support for listheader inside for instance. The only change that should be necessary is the richlistbox <content> block and perhaps a few minor changes to xul.css
Comment on attachment 261101 [details] [diff] [review] patch2 clearing review flag
Attachment #261101 - Flags: review?(enndeakin)
Attached patch patch3 (obsolete) (deleted) — Splinter Review
something like this?
Attachment #261101 - Attachment is obsolete: true
Attachment #264075 - Flags: review?(enndeakin)
Comment on attachment 264075 [details] [diff] [review] patch3 >Index: toolkit/content/xul.css >-listcols, listcol { >- -moz-binding: url("chrome://global/content/bindings/listbox.xml#listbox-base"); >-} >- Why this change? >- <children includes="listheader"/> >+ <children includes="listhead"/> ask mano about this change, as he added the listheader reference recently. I'm also a bit concerned about changing to using a grid for layout. This doesn't cause any download manager and extension manager regressions?
Neil: I limited the children to listheader in the other bug given comment 9 here (which I kinda agree with). I'm fine with changing this to listhead if we add multi-column support for richlistbox after all. Still, I would like to see better reasoning for this complexity (as in, use cases which wouldn't need a tree).
(In reply to comment #12) > (From update of attachment 264075 [details] [diff] [review]) > >Index: toolkit/content/xul.css > >-listcols, listcol { > >- -moz-binding: url("chrome://global/content/bindings/listbox.xml#listbox-base"); > >-} > >- > > Why this change? > Neither listcols nor listcol should implement nsIDOMXULMultiSelectControlElement, listbox-base is base binding for listbox/richlistbox elements.
Attached patch patch4 (deleted) — Splinter Review
(In reply to comment #12) > I'm also a bit concerned about changing to using a grid for layout. This > doesn't cause any download manager and extension manager regressions? > I do not see any regressions with the patch.
Attachment #264075 - Attachment is obsolete: true
Attachment #264715 - Flags: review?(enndeakin)
Attachment #264075 - Flags: review?(enndeakin)
Yes, i think this should not be supported. I plan on implementing support for other types of content in trees during the Mozilla2 timeframe, so see no reason to add extra complexity to richlistbox. Unless you have a specific usecase in mind.
Alex, Allan, did you ever get need to have multicolumn richlistbox or can you suppose it would be helpful for your xul applications?
I don't see a need for it in my own projects yet. I think screenshots might help if we absolutely need it for 1.9.
Attached image Multicolumn RichListBox (deleted) —
We develop mozilla-based applications for medicine. There we need richlistbox to display worklist for certain medicine department. The worklist contains information about patient, doctor, medicine service and so on (please see a screenshot). Originally we intended to use xul:listbox but listbox's rows have equal height and it's not suitable for our worklist. Therefore we created own binding that extends richlistbox to support multicolumn feature. But it's always pain to keep our binding and original richlistbox synchronized. So we'd like to see multicolumn richlistbox inside toolkit. Also, visually download manager has two columns (the first column is downloaded file name, the second column is 'open', 'remove' commands). Just we have usecase when we need more than two columns in richlistbox.
If I get right multicolumn feature is not performance issue for richlistbox and it doesn't lead to complexity of its implementation or usage. If multicolumn richlistbox might be used successfuly by 3d party applications based on mozilla then it's great thing. Asaf, Enn is there any chance to get this in toolkit in timeframe of firefox 3?
This would be useful for bug 377784 given the mockup of the new UI in attachment 269761 [details].
I could also use this for bug #399664 to avoid some of seriously ugly width hackery I'm doing there. I'm going to try out alexanders patch and see what it buys me.
(In reply to comment #16) > Yes, i think this should not be supported. I plan on implementing support for > other types of content in trees during the Mozilla2 timeframe, so see no reason > to add extra complexity to richlistbox. Unless you have a specific usecase in > mind. Arbitrary content in trees would be great, but how many years will pass, until the regular users will have that feature in stable Firefox version ? Having good enough table-like functionality for end users for the next 3 years is important usecase.
(In reply to comment #23) > Arbitrary content in trees would be great, but how many years will pass, until > the regular users will have that feature in stable Firefox version ? Having > good enough table-like functionality for end users for the next 3 years is > important usecase. Seconded. There are at least two specific use cases: the Applications prefpane and the location bar autocomplete dropdown, both of which employ hackery to get around the absence of columns.
I don't have problem with version Mozilla/5.0 (Windows; U; Windows NT 5.0; ru; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 I have problem with version SeaMonkey 1.1.10 Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.15) Gecko/20080621 SeaMonkey/1.1.10
Sorry, I made mistake, I post in invalid number bug
Blocks: 427966
Flags: wanted1.9.1?
Flags: wanted1.9.2?
Attachment #264715 - Flags: review?(enndeakin)
Comment on attachment 264715 [details] [diff] [review] patch4 OK, after thinking about this a lot, I changed my mind and think supporting multi-coloumns would be a good idea. However, I think this should be implemented more fully. I have a better plan that involves improving the grid code such that we can properly support multi-column lists with tree-like headers while supporting column dragging, reordering, etc.
(In reply to comment #27) > However, I think this should be implemented more fully. I have a better plan > that involves improving the grid code such that we can properly support > multi-column lists with tree-like headers while supporting column dragging, > reordering, etc. Ok, reassigning to default asignee then.
Assignee: surkov.alexander → nobody
Status: ASSIGNED → NEW
Flags: wanted1.9.2?
Flags: wanted1.9.1?
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: