alfkil wrote: Status: I am working on some annoying problems with GLWidgets. When that is done I will try and build the Assistant and the Designer apps. Give me a week, and I will have a fresh release .
How about native menus btw ?:) Now all looks good, and works as should, all collects/reacts fine, etc ? Just in interest to know how all of this now works/looks like. And how menus itself looks like now: like a buttons, or visually its the same QT menu, but when you press on it, it spawn reaction menu ?
Everything looks good and works as it should It's just a standard Amiga menu, nothing too exiting.
The new "hot news" is, that suddenly the opengl doesn't crash anymore with the public minigl. I don't know how it happened, for sure I didn't really change anything. Just so you know: For next release, get rid of the custom minigl build!
Great! This was the main thing putting me off from installing & trying QT. It also sounds like you've managed to solve most crashes, and are now more on the "polishing" phase?
@kas1e Quote:
You mean than RMB not works when you try to press it over QT window, but work only when you navigate the menu ?
I think this is quite normal when you use WFLG_RMBTRAP to allow menus, and I don't know any way to avoid it :(
If you need to capture right mouse events in a window, you need to set WFLG_RMBTRAP when you open the window.
Then when you get you idcmp events you will get a message of type IDCMP_MOUSEBUTTONS when a right mouse button click occurs. (assuming you've set the IDCMP_MOUSEBUTTONS flag)
the two codes for the right mouse button are MENUUP and MENUDOWN
So when in your event checking loop you will have something like
switch(msg->Class)
{
case: IDCMP_MOUSEBUTTONS:
switch->(msg->Code)
{
case: SELECTUP:
// left mouse button
case MENUUP:
//right mouse button up
case MENUDOWN:
// right mouse button down
etc etc
}
}
The thing I can't quite remember is what you need to do to stop intuition triggering the intuition menu after you've finished with the event.
The thing I can't quite remember is what you need to do to stop intuition triggering the intuition menu after you've finished with the event.
Rather the problem is, that when I set WFLG_RMBTRAP, I cannot get it to open the menu at all. There _must_ be some way to tell Intuition to defer the rmbtrap thing on command, but how? EDIT: For instance in Deluxe Paint you have an example of using both menus and rmb, so it _is_ indeed possible!
Scrambling through the pages of the RKM I found an article about a member called IDCMP_MENUVERIFY, which is probably what I want to use. Now all I need is a _working example_ of how to use it...
Apparently what it does is it delays menu drawing until the message has been ReplyMsg'ed to. So what do I do, if I don't want the menu? Just NOT respond, or do I need to set something in the message before responding??? That is not answered in the RKM.
What you need to do is set and unset WFLG_RMBTRAP depending on where your mouse is.
So you need code to keep track of the mouse pointer location, and when it is over an area where you want the menus supressed then you set the flag and clear it when the mouse leaves the area.
You set it by manipulating
do something like window->Flags = window->Flag | WFLG_RMBTRAP
AWeb wil set it when the mouse is over certain objects (links / images) and the prefs are set to use the RMB as qualifier or when input elements etc are active.
Since the active window can cancel menu operations, the application may need to determine if its window is the active window. The application can do this by examining the IntuiMessage.Code field of the menu verify message. If that field is equal to MENUWAITING (defined in <intuition/intuition.h>) the window is not active. However, if that field is equal to MENUHOT (defined in <intuition/intuition.h>) the window is active and can cancel the menu operation by changing the Code field of the menu verify message to MENUCANCEL (also defined in <intuition/intuition.h>). If the application cancels the menu operation, Intuition will send the active window an IDCMP_MOUSEBUTTONS event about the right mouse button.
It's described in the same document I quoted from above quoted below, the only modification I might make if I were writing new code is to see whether using SetWindowAttr() can set the WA_RMBTRAP flag. It is listed in the setable attributes so it probably does work, and might be considered cleaner then fidling with bitmasks and bitwise OR etc to set the individual flags in th Window->Flag field.
Quote:
Some people may think one potential use for menu verify is to assign an alternative meaning to the right mouse button. For example, when the pointer is not within the title bar of a screen, some paint packages use the right mouse button to paint using the background color. Using menu verify, it is possible for a application to intercept the menu verify event, checking to see if the pointer is within the title bar. If it isn't, the application cancels the menu event. After cancelling the menu event, Intuition will send a right button down event, which the application can interpret.
This mechanism may work, but it is not very efficient. There is a better way to do this using WFLG_RMBTRAP. This flag is from the Flags field in the Window structure. When set, this flag disables menu operations for the window. When the user hits the menu button, Intuition sends the window IDCMP_MOUSEBUTTONS events instead of menu events.
To use WFLG_RMBTRAP as an alternative to menu verify, the application tracks mouse movement using IDCMP_MOUSEMOVE. While the pointer is outside of the screen's title bar, the application makes sure the WFLG_RMBTRAP flag is set. If the user hits the right mouse button while WFLG_RMBTRAP is set, Intuition sends the application a mouse button event. While the pointer is inside the screen's title bar, the application makes sure the WFLG_RMBTRAP flag is clear. If the user hits the right mouse button while WFLG_RMBTRAP is clear, Intuition generates a normal menu event for the window.
@alkfil That sounds very cool ! So now all the menus, rmb and context stuff works just as native ? (yeah !). Together with all that stuff, fixed opengl crashes, and new prefs app : its all make really big interest to test new version :) Step by step, and everything will be perfect with qt port.