Re: Fluid Application Environment 3.0.alpha1 Released!

new topic     » goto parent     » topic index » view thread      » older message » newer message
eukat said...
jimcbrown said...
mattlewis said...
jimcbrown said...

You seem to be asking for FluidAE to also be a preprocessor. There's nothing wrong with this, though this is typically outside the remit of a GUI toolkit. Still, I know that ryanj has plans to make FluidAE special, and maybe this is just one more method to make it stand out.

I must admit, I'm totally lost. I can't figure out what her requests have to do with FAE. They seem like another round of dynamic code execution ideas that would require a lot of changes to the guts of euphoria, regardless of what other libraries were involved.

Matt

Agreed. The only, and I mean _ONLY_, way I could see this last piece being vaguely related to FluidAE is if FluidAE was to include a preprocessor that simulated or emulated some of this stuff. Otherwise, it's a complete non sequitur.

FluidAE is a gui. How is using FluidAE to provide gui functions to an app a non sequitur? FluidAE handles what's onscreen and routes the keybd and mouse events, and handles message passing between the widgets, how is that not related to handling what's onscreen and routing the keybd and mouse events, and handling message passing between the parts of a program? Because you say so? Because you want to shut me up?

FluidAE providing gui functions to an app is not a non sequitur. FluidAE providing dynamic execution to an app is a non sequitur.

eukat said...
jimcbrown said...

The goalposts seem to keep moving also - at first it seemed like the request was the ability to make minor tweaks to the library, then to add custom widgets, then to be able to deal with custom signals/messages, and now dynamic execution.

The goals are the same, the methodology of making it happen changes as you keep saying this or that method won't work.

In that case, let's change the methodology slightly more by taking a look at a version of the code that doesn't appear as if it is using dynamic execution:

procedure do_user(sequence what) 
  if length(what) < 1 then return end if 
  call_proc(what[1], what[2..$]) 
end procedure 

Now, instead of passing in the name of the function as a string into the first element of the variable named 'what', the routine_id() from that string is passed instead.

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu