On Thu, 2008-10-09 at 11:15 -0400, Max Bandazian wrote:
> Hi Jeremy,
>
> Thanks for taking the time to look at this. My comments are inlined.
>
> On Thu, Oct 9, 2008 at 9:39 AM, Jeremy Moles <[EMAIL PROTECTED]>
> wrote:
> On Tue, 2008-10-07 at 15:17 -0400, Max Bandazian wrote:
> > Hi,
>
> Hello! This is all mostly good stuff, but the diff I'm
> generating based
> on your files is over 6000 lines long. I know for sure there
> aren't that
> many changes--it has mostly to do with indentation
> inconsistencies with
> what is in SVN and what you worked against.
>
> Is there any way you could submit just the output of "svn
> diff"?
> Otherwise, I will try and integrate as much as I can pick out,
> but no
> promises. :)
>
>
> Does your diff tool have an ignore whitespace changes option? It looks
> like VC7 converted all the spaces to tabs, but at least in
> TortoiseMerge there's an option under View>Settings to ignore them.
diff -b
Yeah, that trimmed it up a bit. :)
> > I've been using osgWidget quite a bit, and run into a few
> issues. The
> > attached code addresses some of them. Here's a quick list:
> >
> >
> > - Windows can't live in more than one window manager
>
>
> This was by design. I knew it would be something people needed
> though,
> so I tried to make it easy to clone windows using the now OSG
> integrated
> osg::clone() template function. I could be wrong though, can
> you tell me
> a bit more why you'd want this?
>
>
> More or less to save memory. The project I'm working on can
> potentially have 100s of widgets and several views of the scene with
> different subsets of the widgets visible in them.
I'm afraid that osgWidget just wasn't designed--and perhaps this was an
error on my part--to support having the same object in different
WindowManagers at once.
>
> > - Mouse buttons don't work right (left vs. right click etc.)
>
>
> This has always worked for me using
> WindowManager::getMouseKeysDown(),
> along with a number of other methods such
> isLeftMouseButtonDown(). Is
> this not the case for you?
>
>
>
> As a side effect of having widgets in multiple WMs, I can't know which
> WindowManager to query,
>
>
> > - Mouse events don't have modifiers (alt, shift, etc.)
> associated with
> > them
>
>
> Well, true--but this is a keyboard event, and those events are
> generated
> separately by a different (and optional) EventHandler object.
> I
> certainly see the need for this, but it couldn't be
> information passed
> with every mouse event. Similar to mouse events, it would need
> to be
> something queried from the WindowManager object.
>
> (Something to remember here is that osgWidget is made to be
> event-agnostic, and I've been able to get it working just fine
> by
> feeding it events from SDL--not just the ones detected by the
> EventHandler objects included by default.)
>
>
> I'm using my own event handler, so I didn't notice the different
> keyboard/mouse handlers in the default setup. The situation I'm
> concerned about is where, say, a user holds down ctrl in some other
> app, then clicks on a widget in my app. The issue above about not
> knowing which WM to ask also applies here.
>
>
>
> > - WindowManager::childRemoved misinterprets its second
> parameter (it's
> > # children removed, not end index)
>
>
> Whoops, good catch here. :)
>
> > - Layers seem to be global across all windows, so it seems
> impossible
> > to use layers within two windows and then have all of one
> window draw
> > on top of the other
>
>
> Can you explain this a bit more? The resultant z value
> assocated with
> the Layer setting is calculated during Window::update(), and
> should be
> transformed by the Window's Z value--which is set by it's
> WindowManager.
> I will try and test this more, but I'm not entirely sure I
> follow...
>
>
>
> It may be that I'm misunderstanding what a Layer is in osgWidget. Can
> you explain what the intent is? In particular I'm interested in the
> case where you have two Boxes B and C, and four widgets W,X,Y, and Z,
> where W and X are in box B, Y and Z are in box C, W is layered on top
> of X, and Y is layered on top of Z. If the boxes overlap, I want the
> widgets to be rendered W>X>Y>Z, but I had a hard time getting that to
> happen (I kept getting things like W>Y>X>Z). I also had some issues
> with draw order where antialiased text was getting blended with the
> scene behind the widget, which was pretty weird looking.
No, you have the right idea. :) I'm going to whip up an example testing
this more thoroughly and I will send it to you. I'll try and come up
with a supremely contrived layering example, to really push its
boundaries.
It should work like this (though there may be bugs):
1. The WindowManager defines 3 "stratas": Foreground, Background, and
everything else.
2. Each Window in the WindowManager is given a range of Z values
(during setFocused()) depending on it's strata; first the background
Windows, then the foreground, then everything else. (It should be noted
that each Window in these strata levels is assigned a Z range equal to
1/Nth the number of total Windows in the same strata.)
3. Each Window has it's update() method called, which uses the Z value
ranges set by the WindowManager to position itself and any children.
4. Widget Layers, then, are some offset between the unique base Z value
of the parent Window and Widgets Z value. Right now there are 5 LAYER
enum's spanning the integer range 0-20, but this is just a convenience;
technically, any values should work.
> Also, in my current project I have two sets of Windows, and I want one
> set to always be on top of the other set. My understanding is that all
> the bg/fg windows get the same z-range, so this isn't possible in the
> current osgWidget. My Z implementation deals with all of the above
> stuff correctly for my app, but breaks all the examples :)
Unfortunately, I'm just not sure I can integrate any of these API
changes. Having the same Window in more than one WindowManager at a time
is bound to break things (well, at least in the current code), and I'm
guessing a lot of the weirdness you might be seeing stems from that.
Because of the way osg::Group works, I can't make sure a Window is
"managerless" before it gets inserted (without adding a method to hide
addChild(), which I may do). However, this may be something I need to do
to emphasize the shenanigans that are bound to ensue when this
happens. :)
> Thanks,
> Max Bandazian
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
