Gsoc_Zhan_Proposal_v4.2 by cuiliqing


									GUI Improvements
By Zhan Zhizheng (gsoc_Zhan on nexus, gsoc_zzz on IRC), 2011

Personal Details
Name: Zhan Zhizheng
Location: China, Beijing
University: Graduate student University of Chinese Academy of Sciences (Institute of Software,
Chinese Academy of Sciences)
Mayor: HCI (Human and Computer Interaction)
C++ experience: 5+ years
Experience on game developing: one year developing experience on a 3D storytelling game
designed for children (using OGRE & CEGUI).
Cell Phone: +8615110214250

Planeshift GUI system is implemented in the PAWS which is mainly based on Crystal Space’s
iGraphics2D/iGraphics3D to draw all kinds of widgets. In PAWS, pawsmanager is a singleton to
manage the entire GUI library. With the help of pawsMainWidget, pawsmanager could load
configurable GUI interface from xml document of in CS’s virtual file system.
The main goal of GUI improvement is to make Planeshift’s current GUI interface more
configurable, more powerful, and user friendly.
In order to achieve this goal, I am going to do following improvements:
1. Improve the Help system.
    Add capability to incorporate pictures/3d objects. Make it more configurable and context

2. Improve chat window
    The problem with chat window now is that it needs restarting the system to perform
    changes in settings. Configurable tabs at runtime is going to be added into chat window.

3. Images in books
    Enable books to show text as well as images.

4. Color selector
   When we change color settings, we should assign numeric value manually. There is already a
   color input widget in plane shift. But there are still things to do such as adding this widget
   places need it, adding limitation support to color input widget to make it better.

5. Duplicate pawsWidget by copy constructor
   Currently, all paws widgets are load from xml files. Even if we want to duplicate a paws
   widget, xml parsing is also a must. That is inefficient. By adding copy construction methods to
   the base paws widget classes, we won’t need to parse xml any more.
6. Rendering widget by RTT
   It may be a little expensive to render windows by using RTT. But Planeshift will also benefit if
   we use it at the right place such rendering the paws sketch window. The first step for this
   idea is to enable drawing windows by RTT. The second step is to make the way of rendering
   windows configurable.

7. Improve crafting book
   Right now, the crafting books are full of texts that show all kinds of steps to complete crafting
   tasks. There are so many different crafting techniques that make the crafting books
   unreadable. So this idea is about to organize these crafting step list in a recipe-like way. From
   this recipe, players can quickly understand what they need, what to do first, and then what’s
   next, etc.

By making these improvements, it is certain that Planeshift will get a more configurable and
powerful GUI system.

Implementation ideas
1. Improve the Help system.
     Right now, Help system is based pawshelp class to load help information from XML
     document files. The help information is then organized to show in the helptree widget
     which is a pawsSimpleTrees class.       There is a helptext widget at the right side of the
     help window. The helptext widget is a pawsMultiLineTextBox class to show help content in
     a multiple lined style. When a node of the helptree is clicked, the helptext widget will
     display the node's corresponding help content.(See Figure 1)


         pawsControlledWindow                             pawsControllWindow


       pawsHelp                                   pawsChatWindow



                                 Figure 1 Some classes relationship

     In Planeshift, we have a class named pawsImageDrawable which is an implementation of
     the iPawsImage interface. By using the interface's Draw method, we could draw an image
     onto a frame with assigned size and position.
     Based on these two points above, a pawsDocumentViewBox could be implemented to
     display content with texts as well as pictures. Rough ideas are as following:
         Design a kind of XML definition which could incorporate text content and pictures.
          For example:
                    <Title ...>
                         <Picture file=”example.png” … />
                         <Text>...text content continue...</Text>
         In pawsDocumentViewBox, for those <Text> nodes, it can generally deal with them
          as pawsMultiLineTextBox does except for each <Text> node's first line and last line
          because it needs to determine these lines start X position and Y position inside a
          frame based on pictures' sizes before and after a <Text> node.
         This pawsDocumentViewBox could be implemented as a derived class of the
          pawsMultiLineTextBox. In this way, we could rarely modify the original code to realize
          displaying pictures in Help system.
         In order to incorporate 3D object into help system, I have a very basic idea: using
          RTT technique.

2. Improve the chat window.
    When chat tabs configuration is changed, the chat window widget's definition file name is
    still the old one even if the system has already stored the new settings into “chat.xml” under
    the “planeshift/options/” directory which stores user data. For example, if we change
    configuration to full style, the <chatwidget> node's value in “planeshift/options/chat.xml” is
    then changed to “chat.xml” which means the system will load the full chat window at the
    next time. And at the right time, the chat window’s definition file is still “chat_basic.xml”. So
    the chat window won't change to full style even if it reloads.
    To solve this problem, following things could be done: (I have written some code to test the
    idea. Here is a simple demo:
     The system still stores user’s configuration for chat widget in
           “planeshift/options/chat.xml”. But we have the third choice for <chatWidget> node’s
           value besides chat.xml and chat_basic.xml. That’s to say, the system produces another
           GUI definition file for chat widget based on user’s choices. For example, this
           automatically produced file could be named “chat_user.xml”. If user cancels the basic
           chat widget style and choose “Chat”, ”NPC”, “Auction”, “Alliance”, then system will copy
           tab GUI definitions of these four tabs into “chat_user.xml”. And in
           “planeshift/options/chat.xml”, system will set the value for <chatWidget> to
     In order to enable change tab items at runtime, the system needs to reload the chat
           window after all configurations are saved properly. By calling chat window’s
          SetFileName method which is derived from the basic pawsWidget class, system could
          then reload chat window to change the chat tab items at runtime.
         If users don’t change the tabs configuration, the system still use the chat_basic.xml to
          draw the chat window.
         If users change the configuration from other styles back to basic style, the
          chat_basic.xml could be still used to draw the chat window.
         There are many parts of plane shift referencing the chat window object. A notification
          schema could be implemented to ensure those parts could get the message to renew
          their handles for the chat window object after the chat window is reloaded.

3. Images in books
    If the first idea is implemented properly, then the pawsDocumentViewBox could be also
    used by pawsBookReadingWindow to display images in books.

4. Color selector
    Add the current color input widget to places need it.
    Improve the color input widget to support limitations of changes for color’s value.

5. Duplicate pawsWidget by copy constructor
   Normally, a paws widget is constructed by parsing xml definition file, loading all of its
   attributes, loading the frame size and style (with/without border, etc.), loading all of its
   children widgets, loading all script events, etc. In order to duplicate paws widget by copy
   constructor, following things could be done:
     In pawsWidget class, a copy construction function should be add to copy the existing
         widget’s attributes, script events array, title, border, enter, close, context menu widgets
         and back ground image. And then using this copy construction function to construct
         children widgets.
     For other classes in libpaws, copy construction function should be added to correctly
         copy all the essential information to the new one if the default copy construction don’t
         work properly.

6. Rendering widget by RTT
   A simple way to implement rendering windows through RTT is as following:
   (Also, a corresponding simple demo is implemented. Here goes the video:
     In pawsWidget class, when the draw method is called, check the widget’s render to
         texture switch. If the switch is turned off, let the switch hold the value of its parent’s
         switch. This is to ensure a widget’s children draw itself the same way as its parent. That
         is to say, if a widget use RTT to render, then all of its children render themselves using
     Initialize a blank texture the same size as the widget’s size if render to texture switch is
         turned on. Then tell the iGraphics3D to render to this blank texture.
     Draw the widget as what the direct drawing method do.
     Save the result to the texture and turn off RTT. Finally, draw the texture at the same
         place with the same size of the widget.
      Add a function to enable turning the RTT switch on and off.
    Right now, this idea is too basic that many parts of the widget’s content could not be
    rendered properly. Some details are waiting to be checked to make the idea better.

7. Improve crafting book
   In Plane Shift, a crafting book’s content is originated from the game server. During the startup
   session, the server’s cache manager will preload all the craft messages based on several
   tables that store all kinds of item combination relations, transformation relations, patterns
   and processes to do transformations. The server will send player’s client with crafting
   content by referencing player’s character’s skill level. And the client will show the crafting
   messages in the client’s craft window finally. To make the crafting book readable, it is mainly
   a task of the server side. Here is the basic implementation plans for this idea:
     The server processes all the craft messages in a XML way. It sends craft messages to the
         client as the current way. In the client side, the craft window parsed the xml messages
         and turn them into recipe-like text.
     The messages could be roughly defined as following:
           <Crafting pattern=”pattern description”>
                    <NeedItems>a list of items that is needed</NeedItems>
                          <Prerequisites>prerequisite items</Prerequisites>
                          <Output>output item</Output>
                          <Description>description about this combination</Description>
                          <Prerequisites>prerequisite items</Prerequisites>
                          <Output>output item</Output>
                          <Description>description about this combination</Description>
                          <Process>process to do this transformation</Process>
           </Crafting Tech>
         In this way, the client could parsed a recipe of crafting some specific object.
     Considering the problem of network transfer, xml structured message may not a good
         choice. A more efficient but also structured message could be easily designed to
         achieve the same goal.

Proposal timeline
Before April 25
 To familiarize myself to the PAWS library, its main architecture and how to use this library to
    implement all kinds of windows in Planeshift.
 To study how to use Crystal Space 3D rendering engine, especially those details about
    rendering 2D objects on viewport.
April 25 – May 23 (Before official coding time)
 To doing some test coding stuff to further understand the usage of PAWS as well as CS.
 To discuss the details about my ideas with my future mentor to archive a final agreement.
     Based on the final agreement, I will be clear about all goals. Then I will see how to
     implement and do some documents work for those implementation details to further
     discuss with my mentor.

May 23 – June 18 (Official coding period starts)
 Start coding on improving help system by adding capability of showing pictures in the right
    window of the help widget.
 To implement the context sensitive help feature and make it configurable.
 Start to do coding works on improving chat window by testing to add tabs at runtime.

June 18 – July 5
 Finish the work on improving chat window, and test the whole work to ensure it can work
 Start to code on adding capability of incorporate pictures in books.

July 6 – July 15 (Mid-term)
 Finish the work on books widget and do some test work to ensure it could show pictures as
     well as text properly.
 Incorporate the current color input widget in to the system configuration window.
 Improve the current color input widget.
 Submit mid-term evaluation.

July 16– July 31
 Finish all my work on the GUI improvements and do bug fixing work and test.
 Implement to duplicate widgets by copy construction function.
 Start to implement the idea of using RTT to render windows and make it configurable.

August 1 – August 15
 Improve crafting books
 Redundant time for some unpredictable stuff to do.
 If it is possible, I could do some work on those ideas not mentioned by this proposal under
    GUI improvements project.
 Submit final evaluation.

To top