ges show that my changes of
> _gdk_event_queue_handle_motion_compression() is not the right
> solution, but the behavior shows (I believe) that the last motion
> event before the mouse click is available somewhere in GTK before the
> mouse is clicked.
> Den 2022-05-24 kl. 03:40, skrev
I have managed to cobble together a program in C which does the same
thing and confirmed that it is not a specific GTKMM problem at least.
On Tue, 2022-05-24 at 00:20 +, JLM via gtkmm-list wrote:
> Thanks. I took a look at the web page and I'm pretty sure that the
> described beha
ching things somehow).
On Mon, 2022-05-23 at 10:57 -0700, Andrew Potter via gtkmm-list wrote:
>
> On Mon, May 23, 2022 at 9:15 AM JLM via gtkmm-list
> wrote:
> > I have updated my test. Now you don't have to press a mouse button,
> > but
> > you can press a keyboar
Hi, thanks for taking the time.
I have updated my test. Now you don't have to press a mouse button, but
you can press a keyboard key instead. The problem isn't that I am
seeing extra events, the problem is that the extra event seems to be
hiding, or stuck in a backend/library queue. With the late
e original
glewInit() functions work correctly. I had incorrectly thought that
rendering context was automatically made current either after
instantiating the widget, or at least in it's on_realize() signal
handler.
On Sun, 2021-04-11 at 12:41 +, JLM via gtkmm-list wrote:
> So I found this e
poxy_gl_version() returns 0,
but the glArea->get_required_version() returns 4.5. I'll pretend it
doesn't matter for now and bug someone (else?) later if I'm again at my
wit's end.
On Sun, 2021-04-11 at 01:52 +, JLM via gtkmm-list wrote:
> I am trying to make use of
I am trying to make use of OpenGL 4.5 in a gtkGlArea. The code below
works. However, I have the OpenGL Programming Guide Ninth Edition, and
it uses this instead of glClearColor:
static const float black[] = { 0.0, 0.0, 0.0, 0.0 };
glClearBufferfv(GL_COLOR, 0, black);
When I try to use tha
