[GUI] Mission Statement + Widgets

David Sankel camio@yahoo.com
Tue, 4 Mar 2003 12:58:46 -0800 (PST)


--0-1905740242-1046811526=:28863
Content-Type: text/plain; charset=us-ascii
Content-Id: 
Content-Disposition: inline


Note: forwarded message attached.

--0-1905740242-1046811526=:28863
Content-Type: message/rfc822

Received: from [208.186.62.126] by web40612.mail.yahoo.com via HTTP; Tue, 04 Mar 2003 12:57:48 PST
Date: Tue, 4 Mar 2003 12:57:48 -0800 (PST)
From: David Sankel <camio@yahoo.com>
Subject: Re: [GUI] Mission Statement + Widgets
To: Axel Simon <A.Simon@ukc.ac.uk>
In-Reply-To: <20030303235619.GJ27616@myrtle.ukc.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Length: 2416

--- Axel Simon <A.Simon@ukc.ac.uk> wrote:
> Hi,
> 
> I tried to formulate a Mission Statement and I
> invite people to review it. 
> It is Section 3 in the same document in which I
> gathered initial opinions:
> 
> http://www.cs.ukc.ac.uk/people/staff/as49/poll.pdf
> 

Hello,

  I would like to clarify my opinion.  I would
strongly suggest to _not_ use Qt as a backend
primarily to license issues.  I suggested using the Qt
feature-set as a goal feature-set.

  I've also been looking into binding c++ libraries to
haskell and it is not something that is too difficult
to be accomplished.  So I would further reccomend that
one should not discount c++ backends simply because
they are c++.

  I further believe that the item of primary
importance is the user's haskell api.  I could easily
write a backend using fltk, Qt, winapi, or whatever
and we'd probably see that once the specification is
finished.  The sample implimentation that is released
with the gui-haskell standard need not work on three
platforms, but only one.  Once it is released (if not
before) the other backends will come quickly.  I
suggest efforts are concentrated on the actual
haskell-interface document as that will give the most
bang for the buck.  Others can then impliment backends
according to their preferences (ncurses, CORBA, COM,
odbc?).

  I think that sound api should be of low priority
(aside from the simple windows asterix like sounds
when a dialogue pops up).  This is a very complex
subject with many layers in each target platform. 
This could be something to work on in a different
project at a different date.  For now, we sould
concentrate on gui.

  Regarding GIO, I am very interested and it seems
like the way to go.  I can't find it on the internet
though.  Can someone give me a link so I may review
it?

  I would suggest putting aside the MDI SDI questions
for now, and work on defining a widget set.

I'd suggest a common widget set to include (using Qt
as a reference):

Splitters = To seperate a frame into multiple frames.
They may be user moveable or not.

ListBox = A simple clickable list of items
(multiselect possible).  Note: a contextMenu handler
ought to be used instead of a rightclick method for
portability.

ListView = A more complex listbox that allows for
hierchies and different descriptor fields.  See
http://doc.trolltech.com/3.1/pictures.html if you want
to see what I mean.

IconView = The kinda thing one would see in the My
Computer link on windows.

MainWindow = To be defined later.  This would be
required for portability to a mac as it has menu items
an MDI view, etc.

MenuBar = Clickable menus.

MenuItem = String and list of (String, IO()), (String,
Icon, IO()), Spacer, or MenuItem

ToolBar = A specialized dialogue for holding tool
buttons and simple widgets.  Can be docked or held it
its own window with a usually smaller title bar.

ToolButtons = Specialized iconized buttons for
toolbars.

StatusBar = The little bar one sees at the bottom of a
lot of windows.  A function may set the text there and
another function can override it temorarily (tool
tips, etc).

FileDialog = A dialoge for getting the name of a file
with perhaps other operations (new folder).

Font = A font.  May be used for button captions, etc.

FontDialogue = A dialogue for the user to select a
Font for something.

ColorDialogue = Color chooser.

Printing = lets leave this alone for now.

MessageBox = Several constructors providing various
types perhaps providing different icons.
  Information
  Warning
  Critical
  Messagebox = Provide own icon or lack of
  
  And a list of buttons will be provided to the
constructor (if not, a simple okay).  Ok, Cancel, Yes,
No, Abort, Retry, Ignore

ProgressDialogue = A dialogue displaying progress with
a cancel button.

ProgressBar = A simple progress widget.

GroupBox = a simple optional(frame with title) that
holds widget.
VGroupBox
HGroupBox = Same as above except it places children
automatically vertically or horizontally.

LineEdit = Simple one line text edit

ComboBox = read only or not.  Selectable string from
list of strings.

PopupMenu = context menu sort of menu dialogue. 
Similar constructor to a MenuItem except it does not
have a string for the name of the menu.

ToggleGroup = Similar to a GroupBox but has a list of
toggle buttons where one is checked at a time.
HToggleGroup
VToggleGroup

CheckBox

TabWidget = widget with tab names (icons?).  Each tab
has it's own subwidgets.

SpinBox = a widget with a string and little up and
down arrow buttons

PushButton = self explanitory

MultiLineEdit = . . .

Anyway, this is just a small list.  I could define a
formal list after review, if wanted.

David J. Sankel

--0-1905740242-1046811526=:28863--