[Bf-funboard] Command Line

[Tom Musgrove]

Tom,

>that sounds good. I vote for 'long term solution'.

The short term solution is an incremental approach to a long term solution.  
First step for any solution has to be seperation.

>oh. so you are making #define for each of those commands?

Yes, for the first iteration.  A file command_definitions.h that is just 
assigning the keybinding to the key combinations.


>forces every keybinding to have SPACE_TYPE defined for all keybindings.
>Which is not always true (like general keybindings).

?? I think you must have misunderstood.  Only the keybindings that are in 
the SPACE_TYPE scope are defined within that scope.  If it isn't within 
scope, then it drops through the switch, the flag is set to UNHANDLED, and 
it calls the next broader scope.

If is entirely possible to have absoultely NO keybindings for a particular 
space type if so desired.

By my method, If a keybinding has global scope, then unless it is overriden 
by a local scope keybinding it will be handled at the global level.

I really think you need to look at the current code to see where we are 
starting from. We have around 400 key/mouse combinations not including those 
that are related to modifying button events.  (Perhaps 800 in total?)

There are many functions that are not unified (at the iterface level is what 
I'm refering to...) even though they are often analogous.  (For instance 
Perspoeten, View2d, zoom2d, mouseview, mousezoom, functions, etc.  Or 
extrusion - ie different fuction if it is a mesh, nurbs curve, nurbs 
surface, etc.)

Many functions currently also have their private event ques to check for 
their own modifiers, cancel conditions, etc.

I plan to switch to a lookup table shortly after I get the basic 
functionality in place.  However, that still doesn't eliminate the need for 
a scope check.

I'm not really sure what you have against Switch statements.  The need for a 
lookup table/dictionary/etc. is because switches have to use constants, a 
lookup table isn't particularly more elegant for our intentions, but it does 
allow dynamic definition of keybindings (because of the switch restriction 
on constants).  From a developers perspective things will look largely the 
same.

I really don't see how you are 'getting rid of countless switches' - my 
method has about a dozen or so which is a fairly small number (a typical 
command I think will pass through 2, and probably have 6 as a worst case 
scenario...).  I suspect your method needs many many hundereds of if else if 
statements, with probably 10 being a typical scenario and worst case being 
about 20.  Even if you used switch statements for your proposal (which would 
be far more efficient).  You'd have to have the same number of switches per 
key combinatation that are in my proposal for the grand total. (Say 1*60*9 = 
540 (or if you just want the used key combos, 1*60*2 = 240) in addition to 
the if else ifs.

As far as I can tell your proposal would leave us in the same maintenance 
and modification problems we have now (but much larger....), and doesn't 
seem to gain us much?

LetterRip

_________________________________________________________________
Watch the online reality show Mixed Messages with a friend and enter to win 
a trip to NY 
http://www.msnmessenger-download.click-url.com/go/onm00200497ave/direct/01/