[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