[sldev] [viewer] adding a simple outline list class, aka "stuck between a rock and a hard place..."

Lawson English lenglish5 at cox.net
Thu Sep 20 18:49:52 PDT 2007


OK, this "simple" project is getting beyond ludicrous.

I've analyzed things enough to understand what I need to do (I think):

First, I have to refactor the header and .cpp files for LLScrollListCtrl 
so that the various classes are arranged in such a way that I can add a 
new cell type for LLScrollListCtrl to use.

The problem is that not only are LLScrollListCell and its sub-classes 
declared in the LLSrollListCtr.h file, but those classes are also at 
least partially defined there as well, immediately followed by the 
declaration and partial definition of LLScrollListItem and the 
declaration and partial definition of LLScrollListCtrl itself.


In order to add my LLScrollListOutlinerCell class, I have to separate 
all those definitions and declarations into the relevant .h and .cpp 
files, and then test to make sure I didn't goof.

THEN I can start coding. The problem is, however, that each possible 
LLScrollListCell subclass is tested for within the LLScrollLIstCtrl 
and/or LLScrollListItem class methods, and the approrpriate calls are 
made from there. No LLScrollListCellFactory class exists, so I gotta 
change methods in each of those.

Due to the interesting nature of the XML factory class, I can't derive a 
new LLScrollListCtrl subclass without losing the ability to use the xml 
factory, so I have to add new capabilities there as well.


Keep in mind that this isn't a REAL hierarchy class, but only something 
that adds a conditional arrow icon that can't be clocked on  separately 
from the name of the category. The show stopper for me is comletely 
refactoring the existing class files just to add something new in the 
first place.


My NEW strategy is to just use the existing LLScrollList classes, with a 
minor modification to the LLScrollListText cell-subclass :

LLScrollListText::handleClick


which evokes a callback to my floater.

I'll just RECREATE the entire hierarchy list with each possible 
selection within the floater, and use old school text-based indentation 
and + - signs to indicate the state of the hierarchy of categories. 
Wonky logic, but straightfoward compared to the alternative. And the 
scripters I've asked say they would prefer to see the old-school text 
hierarchy, however, ugly, rather than not see the floater exist at all.




This GUI framework is a total mess, BTW. It only took me two weeks of 
hair-pulling to arrive at this conclusion. :-/


Double BTW, the mouse handling of the GUI, at least on the Mac, appears 
to be shot. As I pointed out earlier, handleMouseDown evokes 
LLScrollListCtrl::itemSelect anywhere from 5-15 times on a single mouse 
click with identical coordinates. There are various bits of information 
about the mouse coordinates created at the event handler level which 
appear to be ignored, at least on the Mac, because the first level 
LLViewerWindow::handleMouseDown gets called a 5-15 or more times from 
that single click, even though the mouse coordinates apparently never 
change, even at the lowest level of the Mac OS X event handler.

#0    0x006bbf88 in LLScrollListText::handleClick at 
llscrolllistctrl.cpp:313
#1    0x006c3068 in LLScrollListCtrl::selectItemAt at 
llscrolllistctrl.cpp:1701
#2    0x006c3328 in LLScrollListCtrl::handleMouseDown at 
llscrolllistctrl.cpp:1735
#3    0x00656e94 in LLView::childrenHandleMouseDown at llview.cpp:1273
#4    0x006570d8 in LLView::handleMouseDown at llview.cpp:1089
#5    0x00656e94 in LLView::childrenHandleMouseDown at llview.cpp:1273
#6    0x006570d8 in LLView::handleMouseDown at llview.cpp:1089
#7    0x00656e94 in LLView::childrenHandleMouseDown at llview.cpp:1273
#8    0x006570d8 in LLView::handleMouseDown at llview.cpp:1089
#9    0x000ddb18 in LLViewerWindow::handleMouseDown at 
llviewerwindow.cpp:666
#10    0x00a578d0 in LLWindowMacOSX::eventHandler at 
llwindowmacosx.cpp:2210


L.












More information about the SLDev mailing list