Locking mouse image for drag between windows

[thumperj]

I'm implementing some dragging code that lets the user drag something from one window to other places on the screen. However, since each window sets it's own image when the mouse is over it, when I change the mouse to be my drag image it is always replaced when I move around on the screen. I don't want it replaced before I actually do a "drop."

Any suggestions how I can "lock" the mouse image during my drag?

Thanks,
Chris

[CrazyEddie]

Hmmm, this is something I did not previously consider

You might try capturing inputs to the 'start' window, this effectively means that the mouse never leaves that window (even when it does, though you may encounter the child window issue that I have still to fix), when you handle the 'drop', release inputs again, and you should be able to find out which window the mouse in now in. This is just a quick idea of the top of my head, and may not work how you want.

Possibly a better idea is if I implement something properly for this

CE.

[thumperj]

Yeah, that's about how I've done it so far: When I start a drag in the first window I captureInput and also fire an event EventDragStarted. Then, when the mouse button comes up I releaseInput and fire a EventDragEnded event.

The problem comes in when I want to be able to detect what window I'm over and 1) if it accepts drags, and 2) if it does, to change some aspect of the window and cursor.

It's like I need to have a function in the base class Window that I can call to check to see if it knows how to accept dropped items. That way I could set it properly from my app, then in my control I can safely query that property to see it accepts drops.

Hmmm....

Cheers,
Chris

[CrazyEddie]

Is the item you're dragging Window based? I have a generic drag/drop feature that I'm supposed to be adding as some stage, so I could probably rough out most of this and add the lower-level parts which would facilitate what you need.

Basically there would be a simple draggable Window class (this would do no rendering and serves mainly as a container, and as a means to drag other content). CEGUI::Window would get some means of detecting when a draggable object has been dragged over it, and also when it is finally dropped (I intended to use the events system for this). Anyhow, all of this would allow control over the mouse cursor as it never leaves the draggable Window.

I could try and get some (or all) of this in over the next week if that would be useful to you Oh, which version are you using, since any additions would be against HEAD.

CE.

[thumperj]

Those changes would be useful to me, actually. I'm dragging an item out of a list box, a StaticImage, but I'll bet I can make it work as long as the Window class has a way to report if it is drag aware.

This will also give me an excuse to get back to the HEAD. I'd like to get your new timer stuff. I've currently hacked in my own version in an early morning desperate demo prep episode. I've been wanting to go back and fix that. It's ugly.

Thanks very much,
Chris

[CrazyEddie]

Okay, I'll try by best to get the initial drag and drop support implemented over the next two or three days.

You may also be interested to hear that I have some changes coming up which will make ListboxItems CEGUI::Window based; this will allow virtually anything to be placed into a Listbox (or Combobox or Grid, as well as the upcoming Treeview, and Menus). It will also then be possible to have drag/drop from any of these. I have no ETA for this, but it should be fairly soon (This will be a breaking change, but is well worth it, as it should also give the ability to specify list contents in xml layout files).

CE.

[gcarlton]

You may also be interested to hear that I have some changes coming up which will make ListboxItems CEGUI::Window based; this will allow virtually anything to be placed into a Listbox (or Combobox or Grid, as well as the upcoming Treeview, and Menus).

That will be very useful!

[CrazyEddie]

gcarlton wrote:

You may also be interested to hear that I have some changes coming up which will make ListboxItems CEGUI::Window based; this will allow virtually anything to be placed into a Listbox (or Combobox or Grid, as well as the upcoming Treeview, and Menus).

That will be very useful!

When I wrote the first Listbox, I thought about whether this would be a good idea, but ultimately decided upon the approach we have now. After living with it for a few months, I realise that it was almost certainly the wrong choice I do still have a few doubts about how feasable it all is, but I guess I'll not know for sure until I try it...

[CrazyEddie]

Most of the drag & drop stuff has been added to CVS (at least a first draft attempt anyway)...

There is a new widget DragContainer which is a basic type available natively in the system (that is, you don't load it from a module, it's always available as "DragContainer" ). This new class handles most of everything related to drag and drop (there are a few wrinkles to iron out, but generally things work quite well).

Basically the idea is that you can attach other widgets to DragContainer and when the container is dragged, the attached widgets get taken along for the ride; an important thing to note is that if the attached widget consumes certain events, then this will override the dragging (Static based widgets are ideal for testing this out as they do no input handling at all, but a button for example still behaves as normal).

There are methods (and properties) to change the mouse cursor when dragging, and also the alpha value (plus a few other bits). These settings can also be changed mid-drag to relay any relevant info to the user (in response to some event or something). I forgot to document the public interface methods, these are pretty self explanatory, but I'll get to documenting them tomorrow hopefully.

The Window class has been extended such that it gets notified whenever a DragContainer is dragged into it, when a DragContainer is dragged out of it, and when a DragContainer is dropped in it. A new DragDropEventArgs object is used for these events which holds the target Window and also the DragContainer pointer; this facilitates the possibility to use generic handlers which can extract the target window as required and do something useful with the DragContainer.

I'm sure there's loads of issues still to resolve, a couple I know about are that the dragged item doesn't appear over "always on top" windows, and playing around with the position of a DragContainer while it's being dragged can seriously mess things up.

I'll see if I can get around to making a demo of this new functionality some time, but it may not be for a little while...

CE.

[gcarlton]

Actually, if the listboxes (etc) become more like window containers, then it would be very easy to add new sorts of containers.

For instance, we could have lots of "layout" window classes that merely arrange the order (position & size) of their children windows. For instance, HorizStack, VertStack, Grid, even a circular pattern. The children could be Windows, Buttons, ListBoxes, even other layouts. That way you could easily get a vertical stack of things, and have one thing in the stack actually be, say, a 3x3 grid of buttons. Would be much better than manually aligning things, and would also make it quite easy to generate a dynamic interface, since the widgets would align themselves.

You could even have window classes that expect a single window child and modify that child's position, sort of like a mutator on an existing window that could make it move up and down, change its alpha, etc.

In short,

[spannerman]

Gaah... who wants a draggable pane, wheres the Scrollable Pane widget !??

Hehe no only joking Eddie, this sounds really cool

[CrazyEddie]

@gcarlton:
Some of those advanced container classes are certainly a possibility (what you describe is kind of like what gtk has).

@spannerman:
Behave!

I can inform you that the scrollable pane is very close to being started; closer than you may think...

My current plan of action is something like this:
<ul>
<li>Prepare release 0.2.0 (Today)
<li>Tooltip widget (Friday / Saturday)
<li>Scrollable Pane (Next week, whoo hoo!)
-- Technically what follows should be the start of the 0.3.0 code as it has breaking changes.
<li>Reworking of ListboxItem to be Window based, updates to current list based widgets.
<li>Treeview widget
<li>Pop-up menu system
<li>Updates to font class for markup support
</ul>

Obviously I will not be able to help myself and will probably add other things in while doing the above. Plus my support role will probably delay everything as usual (though I may disappear for a few days to ensure I get something done!)

CE.

[spannerman]

Woohoo! That looks like a mighty fine list of ToDo's. Fantastic

[gcarlton]

I'd like a listbox of complex items. I've got in mind a list of panels, each of which with some image on the left hand side, and a text label on the right hand side. When selected, the whole panel would light up.

This seems feasible once the listbox owns Windows, although I'm unsure what the plans are to support highlighting. Ideally, it would be general, so you can tell a widget to highlight (or "select" ), and it does whatever (glow, spin around, etc). On the other hand, it may be nice to have a general support for normal background colour and a separate highlight colour to some widget types.

That way, you can create a panel by creating one of these windows and just tell it "blue background colour for normal, yellow background colour when selected, thanks". Come to think about it, it may also be nice to propogate that "highlight" status to the children windows - this in turn would allow any images as part of the panel to have a tint applied to them. That would be nice because then a complex panel would highlight in very interesting ways.. the background could change, icons could change, things could start animating, etc.

What I'm suggesting here is actually converging on some of the ideas for Falagard, since its pretty similar. Whether its a button changing appearance when pushed, or an image changing colour when selected, it seems pretty much the same thing. Probably best to have avoid having duplication on this point, although it depends on whats in store for this Falagard anyway...

Is this the sort of thing you imagined for the "highlight" of windows, or am I off base here?

[CrazyEddie]

What you describe in the first paragraph is technically already possible by deriving from ListboxItem. What is obviously lacking at the moment is the ability to put interactive elements into lists.

The idea about propogating highlight states (and what have you) to child windows is good; this could be useful in other scenarios too. Something to refactored into the Window base class I think

Falagard will be immense. No amount of hardship on my part will be spared in order to make this as flexible and configurable as possible. I intend to start some very early test work on this shortly.

CE