Invisble GtkEventBox vs cursor change - gtk

In my application, sometimes I need to disable most of the buttons and event boxes while a process is taking place (except the "cancel" button of course). Each event box contains a label which can be clicked. To make the user understand that these labels are clickable, I have underlined the texts and have made the cursor change when hovered over those labels.
The problem is that when I disable an event box (make it insensitive), you can see a rather ugly artifact:
So, I searched and found this function: gtk_event_box_set_visible_window. Note: I'm using (I have to, unfortunately) Gtk 2.22, but they just removed the documentation from their website. Anyway, the text of this function is the same.
According to this function, you can make the event box create a GDK_INPUT_ONLY window. If I do so, then disabling the event box doesn't make it ugly anymore.
However, since the event box now doesn't have an outputable window, the
gdk_window_set_cursor(event_box->window, cursor);
makes the cursor change for the whole window instead of just the event box.
I can somewhat see the contradiction between no visible window and cursor change over window, but my question is how, otherwise, can I have the cursor change over the event box, but don't see a visible artifact when the event box is disabled?

I tried different methods, such as changing the background of the event box to transparent etc, but all of them were quite complicated.
The simplest solution I found was the following:
static GdkCursor *_normal_cursor = NULL;
static GdkCursor *_hand_cursor = NULL;
/* in main */
_normal_cursor = gdk_window_get_cursor(widgets_to_remember->window->window);
_hand_cursor = gdk_cursor_new(GDK_HAND2);
/* create the event box */
gtk_event_box_set_visible_window(GTK_EVENT_BOX(event_box), FALSE);
gtk_widget_set_events(event_box, GDK_BUTTON_PRESS_MASK | GDK_ENTER_NOTIFY_MASK | GDK_LEAVE_NOTIFY_MASK);
_fix_event_box(event_box, window);
/* rest of main */
static gboolean _set_hand(GtkWidget *w, GdkEventCrossing *e, gpointer data)
{
gdk_window_set_cursor(w->window, _hand_cursor);
return TRUE;
}
static gboolean _set_normal(GtkWidget *w, GdkEventCrossing *e, gpointer data)
{
gdk_window_set_cursor(w->window, _normal_cursor);
return TRUE;
}
static void _fix_event_box(GtkWidget *eb, GtkWidget *window)
{
g_signal_connect_swapped(eb, "enter_notify_event", G_CALLBACK(_set_hand), window);
g_signal_connect_swapped(eb, "leave_notify_event", G_CALLBACK(_set_normal), window);
}
What this basically does is set the event box invisible, and then set its enter-notify-event and leave-notify-event signal handlers to change the window cursor when the mouse enters or leaves their window.

Related

How to change the mouse cursor icon type when mouse moves out of client area ( propertysheet)?

I got stuck with an issue in property sheet .I want to load different cursor when the mouse position is within the client area and load another when moves out of the client area.
In the porpetysheet I added four page. In the first page when I click next I am loading cursor of IDC_WAIT type and loading IDC_ARROW when the mouse moves out of the client area.
In the page class I triggered the event for WM_MOUSEMOVE as follow:
MESSAGE_HANDLER(WM_MOUSEMOVE, OnMouseMove)
LRESULT OnMouseMove(UINT /*uMsg*/, WPARAM /*wParam*/, LPARAM /*lParam*/, BOOL& /*bHandled*/)
{
if(TRUE == m_bIsNextBtnClicked)
::SetCursor(LoadCursor(NULL, IDC_WAIT));
else
::SetCursor(LoadCursor(NULL, IDC_ARROW));
return TRUE;
}
This event is getting triggered and absolutely had no issue with this. Similarly I tried adding MESSAGE_HANDLER(WM_MOUSELEAVE, OnMouseLeave) this event making an assumption that this will get triggered if the mouse moves out of the client area, but this event did not get triggered at all.If this is not the mouse event to be triggered for mouseleave which event should I trigger?
LRESULT OnMouseLeave(UINT /*uMsg*/, WPARAM /*wParam*/, LPARAM /*lParam*/, BOOL& /*bHandled*/)
{
::SetCursor(LoadCursor(NULL, IDC_ARROW));
return TRUE;
}
Now when I click Next button , I was actually calling a function which is taking sometime to return . Before to this function I am loading IDC_WAIT cursor i.e.,
::SetCursor(LoadCursor(NULL, IDC_WAIT)); .
Now when move the mouse cursor on to the non-client area I want to load IDC_ARROW cursor i.e.,
::SetCursor(LoadCursor(NULL, IDC_ARROW));
When the moves on to the non-client area I am handling the mouse event in sheet derived class as follows,
MESSAGE_HANDLER(WM_NCMOUSEMOVE, OnNCMouseMove)
LRESULT OnNCMouseMove(UINT /*uMsg*/, WPARAM /*wParam*/, LPARAM /*lParam*/, BOOL& /*bHandled*/)
{
::SetCursor(LoadCursor(NULL, IDC_ARROW));
return 0;
}
This event is not getting triggered until unless the function in the Next button event is executed.
I want both of them to be done in parallel i.e, click Next button now hover mouse on the client area, Busy icon should come and when mouse moves out of the client area then IDC_ARROW icon should come.
LRESULT OnWizardNext()
{
::SetCursor(LoadCursor(NULL, IDC_WAIT));
m_bIsNextBtnIsClicked = TRUE;
BOOL bRet = MyFun();
m_bIsNextBtnIsClicked = FALSE;
//Until this function is executed **WM_NCMOUSEMOVE**
//event is not getting triggered.But this event should get triggered and I
//should be able to see the change of cursor within and out of client area.
}
Can anyone kindly help me to solve this issue.
As stated on the MSDN version of this question # here it's not good design to involve the user interface thread in a long operation, a progress bar that is updated from another thread would give more feedback to the user.

How to add an extra button above the TouchScreenKeyboard in UIInput NGUI?

My game uses a registration form scene in order to register a user. I've got several Textboxes(UIInput) on screen.
I would like to have Next/Previous Button over the keyboard which appears when i select a text box for input. this way i will be able to navigate on multiple textboxes in the registration form.
right now i am using HideInput=true so there is nothing over the keyboard
I am sure you have Box Collider "using UIInput",
Simple way would be to add UIButton To your InputBox.
Once you do that attach scene GameObject or PrefabObject, with a public method() to the UIButton OnClick Notify option, Select Method from the drop down.
Test Code:
Private Bool ShwNxtBtn = false;
Public Void MethodName(){
if (ShwNxtBtn != true){
ShwNxtBtn = true;
}else{
ShwNxtBtn = false;
}
Note: you could use Toggle, but I've had some issue with that and input Collider.

Programatically Detect window maximization/Minimization??? Eclipse RCP

As the title shows, I want to add a listener to my rcp user interface in order to detect maximization and minimization. Actually, it not that my real purpose, but I think it is a way to solve my problem. I have a view with some shapes in the center, and I wonna keep the drawing exactly in the center even if the window is resized. To do so, I used the following listener :
public void createPartControl(final Composite parent) {
display = parent.getDisplay();
white= display.getSystemColor(SWT.COLOR_WHITE);
parent.setLayout(new FillLayout(SWT.VERTICAL));
final ScrolledComposite sc = new ScrolledComposite(parent, SWT.H_SCROLL | SWT.V_SCROLL | SWT.BORDER);
sc.setExpandHorizontal(true);
sc.setExpandVertical(true);
sc.setMinHeight(100);
sc.setMinWidth(100);
sc.setSize(565, 305);
final Composite child = new Composite(sc,SWT.NONE);
child.setLayout(new FillLayout());
// Set child as the scrolled content of the ScrolledComposite
sc.setContent(child);
child.setBackground(white);
gc = new GC(child);
parent.addListener (SWT.Resize, new Listener () {
public void handleEvent (Event e) {
x = child.getBounds().width/2;
y = child.getBounds().height/2;
child.addPaintListener(new PaintListener() {
public void paintControl(PaintEvent event) {
dessin(gc); // draw my shapes
}
});
}
everything goes well except when I maximize the window and then minimize it, in this case I loose the drawing (it is in the corner).
Any idea please? I'm I thinking in the right way?
The two events to detect minimization and un-minimization (not necessarily maximization) are Iconify and Deiconify which only occur on the Shell. See the javadocs for Shell.
Consider moving the resize event is seen for the parent, as the child need not necessarily be resized yet.
In order to keep something in the center of something else all you need is the SWT.Resize event, so this question is a classic case of the XY Problem. (Except that the OP in this case seems to already suspect that this may be an XY Problem.)
However, many people arrive at this question with a legitimate need to programmatically detect window minimized / maximized / restored events, for the following reason:
If you want to be able to save the bounds of your application window on exit, you cannot just save whatever is returned by Shell.getBounds(), because your application may be terminated while minimized or maximized or fullscreen, in which case its bounds should not be persisted. What should be persisted is the minimized/normal/maximized/fullscreen state of the shell, (I call it "posture",) and the bounds of the shell last time its posture was "normal". So, essentially, you need to keep track of when the posture is "normal", and for that you need to have a "posture changed" event.
The problem is that when SWT issues the "deiconified" event, it has not calculated the bounds of the shell yet, so the value that you get in that case is bogus.
So, here is the solution to that:
You are going to need a method which recalculates the posture as follows:
private void recalculatePosture()
{
Posture posture = swtShell.getFullScreen()? Posture.FULLSCREEN
: swtShell.getMinimized()? Posture.MINIMIZED
: swtShell.getMaximized()? Posture.MAXIMIZED
: Posture.NORMAL;
if( posture != previousPosture )
{
issue event...
previousPosture = posture;
}
}
In order to generate the "maximized", "restored (from maximized)" and "fullscreen" events you can use Shell.addListener() to listen for the SWT.Move and SWT.Resize event, and invoke recalculatePosture() when they occur.
In order to generate the "minimized" event you can use the shellIconified() method of the ShellListener as #the.duckman said, and again, invoke recalculatePosture().
In order to generate the "restored (from minimized)" event, you need to do the following in your ShellListener:
#Override
protected void onShellDeiconified( ShellEvent e )
{
display.asyncExec( () -> recalculatePosture() );
}
This will cause the recalculation of posture a short time after the 'deiconified' event, at which point SWT will have gotten around to properly calculating the bounds of the shell.

I need to know when a VerticalPanel changes size

I'm using gwt-dnd to implement drag-and-drop functionality in my GWT program. To get scrolling to work right, I need
<ScrollPanel>
<AbsolutePanel>
<VerticalPanel>
<!-- lots of draggable widgets -->
</VerticalPanel>
</AbsolutePanel>
</ScrollPanel>
I have to manually set the size of the AbsolutePanel to be large enough to contain the VerticalPanel. When I add widgets to the VerticalPanel, though, the size reported by VerticalPanel.getOffsetHeight() isn't immediately updated - I guess it has to be rendered by the browser first. So I can't immediately update the AbsolutePanel's size, and it ends up being too small. Argh!
My stop-gap solution is to set up a timer to resize the panel 500ms later. By then, getOffsetHeight will usually be returning the updated values. Is there any way to immediately preview the size change, or anything? Or, alternatively, can I force a render loop immediately so that I can get the new size without setting up a timer that's bound to be error-prone?
This is a common problem with DOM manipulations. The offsetHeight doesn't update until a short time after components are added. I like to handle this using a recursive timer until a pre-condition is violated. E.g. In your case let there be a function which adds components and will be defined as below:
public void addComponent(Widget w)
{
final int verticalPanelHeight = verticalPanel.getOffsetHeight();
verticalPanel.add(w);
final Timer t = new Timer(){
public void run()
{
if(verticalPanelHeight != verticalPanel.getOffsetHeight())
absolutePanel.setHeight(verticalPanel.getOffsetHeight() + 10 + "px");
else
this.schedule(100);
}
};
t.schedule(100);
}

MouseDown events are not delivered until MouseUp when a Drag Source is present

I have a mouse listener. It has some code to respond to mouseUp and mouseDown events. This works correctly.
However, as soon as I add a DragSource, my mouseDown event is no longer delivered -- until I release the mouse button!
This is trivial to reproduce - below is a simple program which contains a plain shell with just a mouse listener and a drag listener. When I run this (on a Mac), and I press and hold the mouse button, nothing happens - but as soon as I release the mouse button, I instantly see both the mouse down and mouse up events delivered. If I comment out the drag source, then the mouse events are delivered the way they should be.
I've searched for others with similar problems, and the closest I've found to an explanation is this:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=26605#c16
"If you hook drag detect, the operating system needs to eat mouse events until it determines that you have either dragged or not."
However, I don't understand why that's true -- why must the operating system eat mouse events to determine if I have a drag or not? The drag doesn't start until I have a mouse -move- event with the button pressed.
More importantly: Can anyone suggest a workaround? (I tried dynamically adding and removing my drag source when the mouse is pressed, but then I couldn't get drag & drop to function properly since it never saw the initial key press - and I can't find a way to programmatically initiate a drag.)
Here's the sample program:
package swttest;
import org.eclipse.swt.dnd.DND;
import org.eclipse.swt.dnd.DragSource;
import org.eclipse.swt.dnd.DragSourceEvent;
import org.eclipse.swt.dnd.DragSourceListener;
import org.eclipse.swt.events.MouseEvent;
import org.eclipse.swt.events.MouseListener;
import org.eclipse.swt.widgets.Display;
import org.eclipse.swt.widgets.Shell;
public class SwtTest {
public static void main(String[] args) {
final Display display = new Display();
final Shell shell = new Shell(display);
shell.addMouseListener(new MouseListener() {
public void mouseUp(MouseEvent e) {
System.out.println("mouseUp");
}
public void mouseDown(MouseEvent e) {
System.out.println("mouseDown");
}
public void mouseDoubleClick(MouseEvent e) {
System.out.println("mouseDoubleClick");
}
});
DragSourceListener dragListener = new DragSourceListener() {
public void dragFinished(DragSourceEvent event) {
System.out.println("dragFinished");
}
public void dragSetData(DragSourceEvent event) {
System.out.println("dragSetData");
}
public void dragStart(DragSourceEvent event) {
System.out.println("dragStart");
}
};
DragSource dragSource = new DragSource(shell, DND.DROP_COPY | DND.DROP_MOVE);
dragSource.addDragListener(dragListener);
shell.pack();
shell.open();
while (!shell.isDisposed()) {
if (!display.readAndDispatch())
display.sleep();
}
display.dispose();
}
}
To answer your specific question about why this happens -- on Cocoa we don't consider a drag to have started until the mouse has moved a few pixels. This ensures against 'accidental' drags if you're sloppy with the clicks. On Linux and Win32 the window toolkit can do the drag detection. If you just hold down the button the detection times out and the mouse down is delivered. On Cocoa we have no time out, which is why nothing happens until the drag is detected or a mouse up happens.
That's a lot of detail, but the conclusion is that the behavior is inconsistent, and we should always be able to deliver the mouse down immediately, without waiting for the drag detection to complete.
I don't see a workaround, since this is happening before the Control sees the event.
See this bug which has patches for win32, gtk and cocoa SWT.
I had faced the same problem and found a solution. Once you attach a DragSource to your custom widget, the event loop will be blocked in that widget's mouse down hook and will eat mouse move events to detect a drag. (I've only looked into the GTK code of SWT to find this out, so it may work a little differently on other platforms, but my solution works on GTK, Win32 and Cocoa.) In my situation, I wasn't so much interested in detecting the mouse down event right when it happened, but I was interested in significantly reducing the drag detection delay, since the whole purpose of my Canvas implementation was for the user to drag stuff. To turn off the event loop blocking and built-in drag detection, all you have to do is:
setDragDetect(false);
In my code, I am doing this before attaching the DragSource. As you already pointed out, this will leave you with the problem that you can't initiate a drag anymore. But I have found a solution for that as well. Luckily, the drag event generation is pure Java and not platform specific in SWT (only the drag detection is). So you can just generate your own DragDetect event at a time when it is convenient for you. I have attached a MouseMoveListener to my Canvas, and it stores the last mouse position, the accumulated drag distance and whether or not it already generated a DragDetect event (among other useful things). This is the mouseMove() implementation:
public void mouseMove(MouseEvent e) {
if (/* some condition that tell you are expecting a drag*/) {
int deltaX = fLastMouseX - e.x;
int deltaY = fLastMouseY - e.y;
fDragDistance += deltaX * deltaX + deltaY * deltaY;
if (!fDragEventGenerated && fDragDistance > 3) {
fDragEventGenerated = true;
// Create drag event and notify listeners.
Event event = new Event();
event.type = SWT.DragDetect;
event.display = getDisplay();
event.widget = /* your Canvas class */.this;
event.button = e.button;
event.stateMask = e.stateMask;
event.time = e.time;
event.x = e.x;
event.y = e.y;
if ((getStyle() & SWT.MIRRORED) != 0)
event.x = getBounds().width - event.x;
notifyListeners(SWT.DragDetect, event);
}
}
fLastMouseX = e.x;
fLastMouseY = e.y;
}
And that will replace the built-in, blocking drag detection for you.