Revision as of 21:29, 3 October 2007 by Wolfgang Jeltsch (talk | contribs) (addition of answer regarding screenshots)
Which are the main differences between Grapefruit and wxFruit? -- ARG 14:40, 3 May 2007 (UTC)
- Hello ARG,
- sorry that I didn’t answer earlier but it was problematic for me to do so.
- My following statements about wxFruit are based on the paper “wxFruit: A Practical GUI Toolkit for Functional Reactive Programming” by Bart Robinson. Is there any newer information about wxFruit? Or did wxFruit die after Bart had written his paper?
- Now the differences:
- Implementation and efficiency
- The implementation of Grapefruit differs notably from wxFruit’s implementation. Grapefruits implementation doesn’t use Yampa. It is very similar to FranTk’s “data-driven” approach instead. Internally, a GUI description is an action which builds the GUI and does any necessary event handler registration. The registered event handlers do the necessary updates and notifications of other components autonomously. Grapefruit’s approach is probably much more efficient than wxFruit’s one. I still have to have a closer look at wxFruit’s and Yampa’s source code to give a more detailed comparison.
- Signals are implicit in wxFruit but explicit in Grapefruit. While explicitness of signals makes Grapefruit not as declarative as I would like, it might be necessary for efficiency. Implicit signals may lead to unnecessary updates. Consider the arrows
pure $ \(a,b) -> (b,a)in wxFruit. Both have type
Arrow arrow => arrow (a,a) -> arrow (a,a). If only the first component of the input changes, only consumers of one of the output components have to react. In the first case, these are the consumers of the first component, in the second case, these are the consumers of the second component. Since you cannot analyse a function in Haskell, the GUI library cannot know upon GUI construction time which components have to be updated. So it might have to unnecessarily update all components which depend on the output of the pure arrow. Checking for actual changes at runtime might help but I’m currently not sure about the consequences.
- Event streams
- In wxFruit, event streams are basically just signals with values of a
Maybetype. However, this is too broad. Dense event streams are actually forbidden but I cannot see a way to enforce this restriction via Haskell’s type system. In Grapefruit, event streams are not special signals but different from signals. This seems much more reasonable to me. It is another reason for the expliciteness of signals (and event streams) since this expliciteness enables you to distinguish between signals and event streams via their types.
- Graphics and animations
- Graphics are currently not supported by Grapefruit but they hopefully will after some months. The same holds for animations.
- Dynamic user interfaces
- Support for dynamic user interfaces is under development. wxFruit has no support for them and adding this support to wxFruit is difficult.
- Event cascades
- If an event causes several other events, Grapefruit handles those other events one after another, whereby each handling can cause new events which are handled immediately. wxFruit probably behaves different here and its behavior might be better.
- -- Wolfgang Jeltsch 17:07, 11 May 2007 (UTC)
- Thanks for the detailed reply. ARG 12:13, 12 May 2007 (UTC)
Hi Wolfgang, could you post some screenshots of Grapefruit. Thanks. --Falcon 23:31, 30 September 2007 (UTC)
- Hello Falcon, I have done so. :-) -- Wolfgang Jeltsch 21:29, 3 October 2007 (UTC)