muppet <scott asofyet org> writes:
If you wanted to create your own container that uses CellLayout to contain a CellRenderer, then you could, but i don't really understand why you would.
Yes, I worded what I said badly, I'm looking at adding renderer(s) to my ticker widget using CellLayout style funcs. The ticker is a plain drawing widget, like a GtkCellView, not a GtkContainer as such. Work in progress code below, just for the sake of interest (POD at the end of the first file). It works, but you can't run it without more bits and pieces. The secret features are button1 to drag back and forward, and a button3 popup menu. The menu can be added to by further subclasses or apps, for example I add a Quit if it's a standalone program, or a Hide if it's an optional component in a GUI. I see I've ignored "visible" from the renderers that's in the code you posted. I also suspect I can do better on maintaining the current position in the model when rows are added/deleted (someone must have written code for that before, surely). The "draw_drawable" to copy an area when scrolling is an idea for reducing flashing and the amount asked of the renderers, but I'm unsure if its complexity is warranted. CellLayout::Base at the end is an idea for some base code actually implementing a basic CellLayout, maintaining a list of renderers and their attributes, though I'm thinking instead of an array of objects there, more like what GtkCellView and GtkTreeViewColumn do in their private "cell info" structs, but either way the base could offer bits like the _set_cell_data from your custom-cell-view.pl.
Attachment:
TickerView.pm
Description: Text Data
Attachment:
Base.pm
Description: Text Data