IMO you would only lose flexibility when not having items as widgets. If they are widgets, you have unified calls for drawing, drag&drop, input handling, etc.; just make sure that the concept of a "widget" doesn't become a CPU-intensive monstrosity.

List views are usually handled something like this:

1. Determine visible items from viewport and backing model (gives a list of visible items with data relevant to positioning, item sizes, etc.)


2. Draw all visible items to the list view's "content" viewport (determined by styling elements such as borders, scroll controls, etc.)


3. Draw view styling elements (done last to ensure overlay effects work properly)

A similar thing goes for input handling. If the user clicks inside the list view, and doesn't hit a control element, the list determines visibility and positioning of the contents, and hands off handling to the child widget.

The problem here is in the details, and without knowing the exact way you bind your GUI together it's hard to give a decent answer.

If the problem is passing some sort of context through to associate a given widget with a given game item, then you can either do it explicitly or implicitly.

Explicitly - the extra data can form part of the interface.

- Example 1: have an arbitrary 'tag' field on every Widget. Your code can use this for whatever you like, but in this case, set the tag to the item ID. When you get the callback saying the image has been clicked, you can read the tag from the widget to see which item it corresponds to. (If the source widget isn't in your GUI::Event, maybe it needs changing so that it is.)

- Example 2: bake it into the callback itself. Using boost::bind you can transform a function that takes a GUI::Event and an integer into one that looks like it takes just a a GUI::Event, by providing that integer yourself at creation time. So your callbacks would look slightly different, but they would get the item ID passed directly in.

Implicitly - the extra data can be divined from the context.

- Example: You have 16 inventory slots. Create 16 widgets and bind them to 16 callbacks. (Probably thin wrappers for a single callback which takes a number from 1-16, or use the boost::bind thing above to point them all at a single callback.) The callback knows about your inventory and can look up which item is which from that 1-16.

Note that I've assumed the callback knows about your game data. It doesn't matter if that is not the case, due to separation of concerns, MVC, etc. The callback has the context now, whether it understands it or not - it can just forward that to the controller and from there to the model, where it gets acted upon accordingly.