1 / 50

“Easy” GUI Toolkits

“Easy” GUI Toolkits. Peter Centgraf 05-830 Advanced UI Software Fall 2004. Introduction to the Problem(s). How do we define “Easy”? Low developer learning curve? Maps well to some metaphor? Low working memory load? Low configuration/setup overhead? No code?

heatherd
Télécharger la présentation

“Easy” GUI Toolkits

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. “Easy” GUI Toolkits Peter Centgraf 05-830 Advanced UI Software Fall 2004

  2. Introduction to the Problem(s) • How do we define “Easy”? • Low developer learning curve? • Maps well to some metaphor? • Low working memory load? • Low configuration/setup overhead? • No code? • Usable by ... non-developers? ... children?

  3. Types of “Easy” UI Development • Visual Prototyping • Used in early design iteration • Simulates, rather than implements • Limited interactivity and computation • Sometimes bridged into RAD systems

  4. Types of “Easy” UI Development • Rapid Application Development • Buzzword Alert! • Design priority on high turnaround rather than unique and complex applications. • "Real" development => complete applications • Often focused on corporate IT/database apps

  5. Types of “Easy” UI Development • End User Programming • "The document is the program“ • Simple interactive documents and tools • Excel spreadsheets are EUP • ... but so are Access forms! • ... and Flash animations! • ... and Alice 3D worlds!

  6. Are these problems distinct? • Yes … No … Sometimes • Different domains, similar issues • Complexity/power tradeoffs at different scales • Remember this? <http://www-2.cs.cmu.edu/~NatProg/projectoverview.html>

  7. Everybody Wants to Rule the World • Many systems address these problems • (Developers love to write developer tools!) • Common design themes are often repeated • The remainder of this talk will discuss: • The most common approaches • (Many) systems that exemplify them

  8. 1…2…3… “Easy” • 1. Edit Visually • 2. Simplify the Model • 3. Use a High-Level Language

  9. 1. Edit Visually • We’ve seen this all before… • See Lecture 9 for more details • Editing graphical layouts with a graphical tool • It just makes sense • It provides great productivity improvements • It has been reimplemented ad nauseum

  10. 1. Edit Visually • Some are stand-alone tools • Glade • UI Builder for GTK+ Toolkit • Code generators for many languages • Dynamic interface from XML description • http://glade.gnome.org/ • wxGlade • UI Builder for wxWidgets Toolkit • Popular among Python developers • http://wxglade.sourceforge.net/

  11. 1. Edit Visually: Glade

  12. 1. Edit Visually: wxGlade

  13. 1. Edit Visually • Some have additional development features • Mac OS X Interface Builder • Apple Cocoa or Carbon Toolkits • Tied to AppleScript or Objective-C code objects • Visual elements described in “nib” resource file • Component interactions via generated code • Some auto-generation of database access forms • “Test Mode” preview from user’s perspective

  14. 1. Edit Visually: Interface Builder

  15. 1. Edit Visually • Some are part of complete IDEs • Eclipse Visual Editor Project • Sponsored by IBM • Supports Swing and SWT • Bi-directional code and visual editing • http://www.eclipse.org/vep/ • NetBeans IDE • Sponsored by Sun • Supports Swing, JSP, mobile Java • http://www.netbeans.org

  16. 1. Edit Visually: Eclipse Visual Editor

  17. 1. Edit Visually: NetBeans IDE

  18. 1. Edit Visually • And many more… • Visual Basic • Visual Studio .NET • Java Studio Creator • Borland Delphi, Kylix, JBuilder • IntelliJ IDEA • Need I go on?

  19. 2. Simplify the Model • “Model” here refers to the program structure • A broad class of solutions • Move toward lower complexity and power

  20. 2. Simplify the Model • Work with primarily static forms • Match program to capabilities of visual designer • Dynamic elements limited to widget contents • Visual Basic is most prominent example • Sufficient for a wide variety of business apps • Most successful implementations allow extension via languages with more dynamic capabilities

  21. 2. Simplify the Model: Visual Basic • Visual Basic <= 6 • Second-highest google hit rate of all languages according to http://www.dedasys.com/articles/language_popularity.html • Visual “forms” and pure-code “modules” • Uses event-based language to script widgets • Extensive library of COM/ActiveX components • Common dialog types (OK-Cancel, Yes-No, etc.) • Web browser • Database-backed table and tree controls

  22. 2. Simplify the Model • Layout containers • Adds automatic continuous resizing to forms • A simple but important upgrade • More gracefully supports dynamic components • Also used in more complex toolkits, e.g. Swing

  23. 2. Simplify the Model: Tk • Tk • Created by John Ousterhout, 1988 • Intended to be paired with his TCL script • Three simple layout managers • Pack – places widgets in a vertical or horizontal group • Grid – aligns widgets in columns and rows • Place – manual absolute positioning • Nested “frames” with different layout managers • Complex layouts possible with simple combination

  24. 2. Simplify the Model: Tk

  25. 2. Simplify the Model: WindowsForms • .NET Windows.Forms • Used with Visual Basic.NET, C#, etc. • Adds dynamic layout via “dock” and “anchor” • “Docked” widgets snap to edge of frame • When edge moves, widget resizes • “Anchored” widgets are fixed relative to edge • When edge moves, widget moved an equal distance

  26. 2. Simplify the Model: WindowsForms

  27. 2. Simplify the Model: WindowsForms

  28. 2. Simplify the Model • Stack of Cards Metaphor • Pioneered by Apple HyperCard • … SuperCard, MetaCard, PythonCard, Dreamcard • Emphasis on data navigation and persistence • “Stack” can take different forms • Each card has a different layout, different functionality • Each card has the same layout, different data • Easily navigate forward/back or follow links • Persist all data in widgets with a single command

  29. 2. Simplify the Model: Revolution • Runtime Revolution • Cross-platform development environment • “Professional” version of Dreamcard • Combines stack metaphor with dynamic OO scripting

  30. 2. Simplify the Model • Use High-Level Components • Provide complex functionality in discrete units • Isolate intensely graphical or interactive code • Embed major portions of other applications • Best used in combination with: • Visual Layout • Event-based Languages • Object-Oriented Languages

  31. 2. Simplify the Model: Mozilla Control • Provides a full web rendering component • Similar to MS Internet Explorer control • Exposes events and methods • Respond to user action • Manipulate HTML DOM

  32. 2. Simplify the Model: PDFKit • Provides a full PDF rendering view • Exposes document structure via methods • Table of Contents • Bookmarks • PDFView no-code viewer w/ printing, etc. • Separate projects for: • Mac OS X 10.4 • GNUstep

  33. 2. Simplify the Model • Address a highly-specific domain • Limit the scope of the toolkit • Support a particular niche • Database editing forms • 2D animations for children

  34. 2. Simplify the Model: Access Forms • MS Access • Visual form builder tool • Similar to VB layout tool • No scripting required • Widgets populated from a database or query

  35. 2. Simplify the Model: HANDS • HANDS • Programming for children • Cards represent data • Scripts animate objects • Language innovations • Aggregate operators • Tabular queries

  36. Quick Break – 5 Minutes

  37. 3. Use a High-Level Language • Simplified languages for simplified toolkits • Reduce complexity • Increase code readability • Code in terms of user mental model • Encourage “fast and loose” development • Provide a structured, graphical code editor

  38. 3. Use a High-Level Language • Wrapper libraries • Expose a friendlier API to an existing toolkit • Hide some features, automate others • EasyGTK • Dramatically reduces initialization code • Provides sane defaults for complex components • Simple “Hello World” from 30 lines to < 10

  39. 3. Use a High-Level Language: EasyGTK • #include "easygtk.h" • GtkWidget *win, *box, *text, *button; • void main(int argc, char *argv[]) • { • gtk_init(&argc, &argv); • win e_window_create("Hello World", 400, 200, 100, 100, exit); • box e_box_create(win, E_VERTICAL, 2); • text e_text_create(box, FALSE, "Hello World!", E_NO_FUNC); • button e_button_create(box, "Close", exit); • gtk_main(); • }

  40. 3. Use a High-Level Language • “English-like” syntax • Intends to emulate natural language • No special symbols • Optional articles, prepositions – “a”, “the”, “of”, “to” • Enhances readability • Statements are imperative verb clauses • Most code has direct spoken equivalent

  41. 3. Use a High-Level Language:AppleScript • AppleScript • Designed by Apple as end user scripting language • Send messages via “tell” block • Respond to events via “on” block • Handle errors with “try … on error” blocks on clicked theObject tell window of the object try set theRate to the contents of text field "rate" as number set theAmount to contents of text field "amount" as a number set the contents of text field "total" to 0

  42. 3. Use a High-Level Language: Transcript • Native language of Runtime Revolution • Provides high-level facilities • Events • Aggregate operators • Regular expression matching if workQueue is not empty then send "doWork" to me in .0001 seconds put the result into gWorkMessage else close file gLogFile enable group "optionalControlGroup" end if

  43. 3. Use a High-Level Language • Event-based languages • Almost all languages support this style • Some make events and handlers first-class • VB – Event handlers are primary code entry points • AppleScript – “on” and “tell” blocks • Transcript – “send” command • EasyGTK – callback functions • SUIT – “Interest procedures” • Maps to stimulus-response mental model

  44. 3. Use a High-Level Language • Dynamic typing and conversion • Common among scripting languages • Automatically converts data types when needed • Encourages focus on action rather than data • Examples: • VB “Variant” type • All AppleScript variables • Global variables • All AppleScript variables • Tk components in TCL container heirarchy • .window.frame.button.label = “Click Me!”

  45. 3. Use a High-Level Language • Structured, graphical code editors • Replace code with graphical blocks and menus • Syntax errors are impossible! • Can reduce semantic errors via static analysis • Visibility of options is extremely high • Slows down fast typists

  46. 3. Use a High-Level Language: Alice • Alice • Interactive 3D programming • Targeted to beginning programmers (early teens) • Supports: • Events • Concurrency • Functional abstraction • Visual, guided debugging

  47. 3. Use a High-Level Language: Alice

  48. 3. Use a High-Level Language: AgentSheets • AgentSheets • Sets of dynamic, interacting agents • Combines spreadsheet metaphor and productions • Spreadsheet organizes agents • Productions provide behavior • Similar to events, provides explicit stimulus-response • Block editor for productions • Less rigid than Alice • Allows typing of expressions and values

  49. 3. Use a High-Level Language: AgentSheets

  50. Conclusions • “Easy” is not a simple thing • Tradeoffs between power and simplicity • Different target audiences with different skills • Common issues and related solutions • Multiple Approaches • Simplify the framework’s capabilities • Simplify the development language • Many ways to do both

More Related