Hobby-hacking Eric

2008-03-15

XTC on hackage

Just a quick note to say that XTC (XTC: eXtended & Typed Controls for wxHaskell) is available on hackage.

the haddock


The XTC library provides a typed interface to several wxHaskell controls.
  • radio view (typed radio box)
  • single-selection list view (typed single-selection list box)
  • multiple-selection list view (typed multiple-selection list box)
  • choice view (typed choice box)
  • value entry (typed text entry)
XTC controls keep track of typed values and items, rather than being string based. Selections in XTC controls consist of actual values instead of indices.

my notes

XTC library was developed in Utrecht University, and has been used to develop Dazzle, a Bayesian Network toolbox, and very much a "real world" application. You can read more about XTC and Dazzle in their Haskell Workshop paper from 2005.

If you're using wxhaskell, XTC could make your code a bit cleaner, without imposing a steep learning curve. Here is a quick example of the library in action.




And here is the source code. Notice how we work directly with the Fruit type, eschewing any intermediary strings:
import Graphics.UI.WX
import Graphics.UI.XTC

data Fruit = Apple | Banana | Orange deriving Show

instance Labeled Fruit where
toLabel = show

main :: IO ()
main = start $
do f <- frame []
txt <- staticText f [ text := "pick a fruit and I will give you a slogan" ]
radioV <- mkRadioView f Vertical [Apple, Banana, Orange] []
--
set radioV [ on select :=
do mf <- get radioV typedSelection
set txt [ text := slogan mf ]]
set f [ layout := margin 5 $ column 1
[ hfill $ widget txt, widget radioV ] ]

slogan :: Fruit -> String
slogan Orange = "orange you glad I didn't say 'orange'?"
slogan Apple = "an apple a day keeps, well you know"
slogan Banana = "buh-naaaaa-naaa"


If you like this kind of thing, be sure to also check out AutoForms and Phooey


8 comments:

Mads Lindstrøm said...

I looked at your source code and found that your class TypedValued is defined as:

class TypedValued x w | w -> x where
typedValue :: Attr w (Maybe x)

Is it really a good idea to use Maybe here?

Sometimes widgets are initialized from creation time and cannot be un-initialized. E.g. radio-buttons are commonly used this way. In this case you would be forcing Maybe where it is not necessary.


Greetings,

Mads Lindstrøm

kowey said...

That's a good question. I'm actually not working on XTC, by the way, just packaging it up to make it (a little bit) nicer to use wxhaskell. So it may be worth asking Martijn.

One thought is that it would be useful for things like the textEntry widget. Maybe there ought to be two kinds of typed values?

kowey said...

By the way, I think you may have also noticed that they have some code they would like us to integrate into wxhaskell.

kowey said...

Oh, and one more thing. I think that TypedSelection does not use Maybe...

Mads Lindstrøm said...

With "typedValue :: Attr w x" we can still define x as "Maybe something" and I therefore see no reason to make two TypedValue type classes.

As a follow-up on my previous post I did a little experiment. I opened GEdit's (Gnome's default text editor) preferences dialog. Non of the widgets could be left in a "Nothing" state. Mainly because the widgets were mostly check boxes, which simply is either true or false - no "Nothing" state. There were also some integer widgets. I could delete all the numbers, but then it would just revert to some default value. Again I could not put the widget in a "Nothing" state.

Mads Lindstrøm said...

I will email martijn about the issue. He properly have a good explanation of why he uses Maybe.

Anonymous said...

The typed values have a maybe type to account for parse errors in the value entry. For example, if you have a value entry of type Int and you enter characters, get typedValue returns Nothing. For the other widgets, only ListView and ChoiceView use a maybe (i.e. typedMaybeSelection), since their selections may be empty. RadioViews indeed cannot be uninitialized, and therefore use typedSelection (without a maybe).

What might be confusing is that in order to avoid duplicating code, the implementations of RadioView, ListView and ChoiceView all use viewGet/SetTypedMaybeSelection just But radioView removes the maybe type and gives an error in case of an empty selection (which will not occur).

Cheers,
Martijn

kowey said...

Thanks for the clarifications, Martijn.

By the way, if you have any improvements you would like to see in wxHaskell, we'd love to hear about them, either on our mailing list or on our tracker http://sourceforge.net/tracker/?group_id=73133