CEGUI (Crazy Eddie's GUI) Forums

This would be useful in a chat window where links to items could be displayed. When clicking on a link a window would pop up detailing the item. Here's how I think it could be implemented and before I start coding, I'd like comments on whether I'm on the right track or completely off.

First the tools available:

ListboxItem * CEGUI::Listbox::getItemAtPoint ( const Point & pt ) const
Return the ListboxItem under the given window local pixel co-ordinate.

const String& CEGUI::ListboxItem::getText ( void )
return the text string set for this list box item.

const Font * ListboxTextItem::getFont (void) const
Return a pointer to the font being used by this ListboxTextItem.

size_t CEGUI::Font::getCharAtPixel ( const String & text, float pixel, float x_scale = 1.0f )
Return the index of the closest text character in String text that corresponds to pixel location pixel if the text were rendered.

void * d_itemData
Pointer to some client code data. This has no meaning within the GUI system.

Text links require two features. The first is to change the mouse cursor when hovering a link and the second feature is to trigger an event when clicking the mouse button over a link.

getItemAtPoint() would return the listbox item under the cursor. From that listbox item are obtained the text with getText() and the font with getFont(). Finally getCharAtPixel() would use the x coordinate of the mouse to find the character position under the mouse. From that position I can find the word and determine if it is part of a link. This link information would be stored in d_itemData. As an optimization step this process would only be started if d_itemData contained a flag that a link does indeed exist.

If getFont() does not contain the coordinates of the text then I would need to transform the mouse world coordinate into local coordinates (local to the region where the text of the listbox item is rendered).

This functionality would be packaged into a function that would return the ID of the link. But a better approach would be to return a class. Only returning an ID requires that every ID is unique. It also means that should we want to open different dialogs (when clicking on the link) we'd have to test the link (lots of IFs or a big switch) and open the appropriate dialog (ie IDs 1-1000 are for armor and 1001-2000 are for weapons). If instead a class was returned then that class would call up the appropriate dialog through a function like OnLinkClicked().

This first implementation would only work for listbox items. But hopefully it could be implemented in a more general manner such that any text can be clickable.

So, is this plausible or completely wacky?

P.S. I know that I have not talked about displaying the link as underlined text.

wow, good idea

According to this thread, post #13, the listbox window will be completly revamped, so i suggest to look in CVS HEAD to make you'r job compatible.

From that position I can find the word and determine if it is part of a link

how do you pla to do this ?



maybe a more component approach (but less documented):

first, you create a link widget with asentialy a onClicked() methode or all the behavor for displaing his content.

after that, a container widget (listbox or other) managing some child components and these child are links widgets.

like that, you'll let all the hard work (events, link detection...) to CEGUI already existing fonctionnality.
the rest is to cleverly mix you'r link component with text or whatever you want.

>>From that position I can find the word and determine if it is part of a link

>>how do you pla to do this ?

[font=Courier]
This is a link!
123456789012345
[/font]

Letter positions 11 to 14 are part of a link and represent word 4 (using the space as the separating character). Thus a link could be defined by a word number or two letter positions, for the start and the end of the link. These two methods are compatible with the idea that multiple words could be part of the link, such as:

[font=Courier]
This is a longer link!!
123456789012345678901
[/font]

with the link defined as the letter positions 11 to 21 or words 4 to 5.

>>maybe a more component approach

If I'm not mistaken there currently are listbox items with text or images. Maybe I could simply create a new type such as a listbox with multiple objects, such as text and image objects. Each object would draw itself and respond to events. And since they draw themselves, these text objects could contain different display properties than the other objects such as the font used, attributes (bold, italic, underline, strikethrough) and *gasp* colors.

Maybe it'd be simpler to override the draw() function so I could draw anything in that listbox cell. Time to go look through the source code and see what could be done.

Like martiganesse wrote, the next release will feature a fully rewritten listbox widget that uses windows for items.
The work on the "normal" listbox is 99% done (though not yet committed).

This will enable you to create properties etc. via falagard, and the whole event system is at you disposal. It should make your task alot easier...