RFC: mouse context limitations

From: Tomas Frydrych <tomasfrydrych_at_yahoo.co.uk>
Date: Sat Jul 24 2004 - 16:07:30 CEST

Because mouse context is currently stored together with some other
event information in a single 32-bit word, the different context
constants are not or-able (we have 12 bits at our disposal, and
already 16 values). This imposes serious limitations on processing of
mouse context, and is, for example, the cause of 7085, 'Hyperlinks do
not work with document history on': currently the test for revisions
in FV_View::getMouseContext() preceeds the test for hyperlinks. I
could change the order of processing, but that does not solve the
real problem, mouse contexts stack up over each other, and so the
context constants should be or-able, and context menus should be
stackable (the spell checking context menu is another example).

As we already use 64-bit ints elsewhere, one possible step toward
solution would be to enlarage the event constants to 64-bits. Even if
at this stage it is IMO too late to redesign the whole menus
mechanism so as to make it possible to combine several context menus
into one, it would still make it possible to handle the context
processing more inteligently (at least the revisions context menu
could be redesigned to include hyperlink and spell-checker entries
when appropriate).

Does anyone have serious objections to changing the event contstants
to 64-bits?

Received on Sat Jul 24 15:54:42 2004

This archive was generated by hypermail 2.1.8 : Sat Jul 24 2004 - 15:54:42 CEST