Difference between revisions of "Improved UI 2013"

From PSwiki
Jump to navigation Jump to search
Line 25: Line 25:
* General: fixes to the interface (focus issues for example, support for animated textures, render to texture), support to copy constructor in all the classes in order to create duplicate objects in paws easily without parsing again the xml each time, conversion to plugin. (easy to hard depending on the parts which are picked up)
* General: fixes to the interface (focus issues for example, support for animated textures, render to texture), support to copy constructor in all the classes in order to create duplicate objects in paws easily without parsing again the xml each time, conversion to plugin. (easy to hard depending on the parts which are picked up)
* Container System: Generalize the code so it's possible for the client to request to the server to be listening to a set of containers arbitrarily big and allow moving objects from the various open able container windows (medium to hard)
* Container System: Generalize the code so it's possible for the client to request to the server to be listening to a set of containers arbitrarily big and allow moving objects from the various open able container windows (medium to hard)
== Design ==
# 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.
#: 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:
#::: <HelpDoc>
#:::: <Title ...>
#::::: <Text>....</Text>
#::::: <Picture file=”example.png” … />
#::::: <Text>...text content continue...</Text>
#::::  ......
#:::: </Title>
#:::</HelpDoc>
#::* 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.
# 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:
#::* 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 “chat_user.xml”.
#::* 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.
# Images in books
#: If the first idea is implemented properly, then the pawsDocumentViewBox could be also used by pawsBookReadingWindow to display images in books.
# 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.
# 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.
# Rendering widget by RTT
#: A simple way to implement rendering windows through RTT is as following:
#::* 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 RTT.
#::* 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.
# 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 to player’s client with crafting content by referencing player’s character’s skill level. And the client will display 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 an 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>
#::::: <Combination>
#:::::: <Prerequisites>prerequisite items</Prerequisites>
#:::::: <Output>output item</Output>
#:::::: <Description>description about this combination</Description>
#::::: </Combination>
#:::::: ……
#::::: <Transformation>
#:::::: <Prerequisites>prerequisite items</Prerequisites>
#:::::: <Output>output item</Output>
#:::::: <Description>description about this combination</Description>
#:::::: <Process>process to do this transformation</Process>
#::::: </Transformation>
#:::: ……
#::: </Crafting>
#::* 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.


== Implementation Detail ==
== Implementation Detail ==

Revision as of 18:28, 4 February 2012

(Go back to the main GSoC 2012 page)

UI In PlaneShift : PAWS

The UI in PlaneShift is managed by a library called PAWS (PlaneShift Alternate Windowing System or PlaneShift Acraig Windowing System), where acraig is the creator of the system.

The library is made of C++ classes to define a widget and an associated XML file which describes the layout and formatting.

Read more about the syntax and usage here.

Skills needed

For this project C++ knowledge is needed, and basic knowledge of XML. No MySQL knowledge is required.

Improvements needed

  • Help system: add capability to incorporate 3d objects in the help widget, make it more configurable, context sensitive and allow links.(easy)
  • Duplicate pawsWidget by copy constructor: During the last year GSOC copy constructors have been added to all classes. Now they will need to be put in use for example in the pawslistbox and be verified to be working correctly (easy)
  • Active magic window: today whenever you cast a buff spell on yourself, or when someone casts a debuff spell on you, the magic window opens showing all the buffs and debuffs, that's very annoying and clutters the screen. We want to remove this window and just have a series of icons on the top right corner with all the active buff and debuffs. This is a kind of toolbar, but just with the icon. Mouse-overing on the icons will tell you the type of spell and the duration.
  • Crafting books: Today the crafting techniques are special items which you can read like a book. Those allow you to complete crafting tasks, so for example to smelt and refine iron you need the "working with stock" crafting book. When you read this special book, the text displayed is the list of all possible combinations and transformations you can do with stocks. Even if it's simple to generate by the code, it's very hard to read and very hard to understand. We should show the books as ordered recipes and not only as a bunch of operations without any connection (needs to resolve a graph, also this needs to be cached somehow)(medium, graph algorithm knowledge is suggested)
  • Chat window: The last GSOC the chat window was improved to allow adding and removing tabs but the style of tabs was forced upon a specific positioning of tabs. It would be good to be able to add more options for positioning or even make it scriptable somehow, so skin makers can decide precisely how they want the tabs to show. An additional idea is to make the tabs configurable at runtime through in game event: For example adding the guilds tab when a player belongs to a guild.(easy)
  • 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. (medium to hard)
  • Hot bar for spells and items, with support for multiple rows, which can be resized and hidden.(medium)
  • General: fixes to the interface (focus issues for example, support for animated textures, render to texture), support to copy constructor in all the classes in order to create duplicate objects in paws easily without parsing again the xml each time, conversion to plugin. (easy to hard depending on the parts which are picked up)
  • Container System: Generalize the code so it's possible for the client to request to the server to be listening to a set of containers arbitrarily big and allow moving objects from the various open able container windows (medium to hard)

Implementation Detail

  1. Help System
    • The current help system loads help information from “/data/help.xml” and then the content of that is parsed in pawsHelp::PostSetup by using the system’s xml parser. The tree view widget is initialized based on the nodes after parsing. When a tree node in this view is selected, the node’s corresponding help information is retrieved and displayed in the text displaying widget. This widget is a kind of pawsMultiLineTextBox which support display plain multi-lined text.
    • In order to enable displaying help information with pictures, we could implement a new widget derived from the pawsMultiLineTextBox. Some member functions of pawsMultiLineTextBox will be override and a new function named OrganizeContent should be added in order to manage the positions of lines and pictures correctly. We call the new widget “pawsDocumentView” which will be declared as following:
    Struct pictureInfo
    {
    Unsigned int width, height;
    Char * srcstring;
    Unsigned int align;
    Unsigned int lines;//how many lines this picture spans
    };
    Class pawsDocumentView: public pawsMultiLineTextBox
    {
    Public:
    pawsDocumentView();
    virtual ~pawsDocumentView();
    void SetText(const char * text); //override
    void Resize();//override
    void Draw();//override
    bool Setup(iDocumentNode* node);//override
    protected:
    void OrganizeContent(const char * text);//this function is a new one
    csArray<pictureInfo> pics;// hold all the information parsed from xml
    };
    • In help.xml, the content in “<topic></topic>” should be defined as following:
    <Contents>
    <Content type=”text”>text text text </Content>
    <Content type=”pic” width=”64” height=”64” align=”left” padding=”5 5 5 5” src=”pic source location; pic source location; pic source location;……” />
    ……
    </Contents>
    Note: The pictures “src “ attribute may contains more than one picture source location which means the view widget could display more than one picture in one row with the same scale and align.
    • The content in <topic> node is sent to the view as plain string. Then we could still use setText method to set the content that will be displayed. In setText, the most important thing is to call the OrganizeContent to manage all the text content and pictures. We don’t override the OrganizeText method because OrganizeContent still needs it to format text contents. The following flow chart shows what will be done in OrganizeContent method.H1.jpg
    Note: “#pic#1,2,3” means those lines in the “lines” array are pictures. The digitals are indices pointing to the corresponding picture information in the “pics” array. These information is used in Draw method to draw pictures correctly.
    • After the content is organized, we could then draw all the text and pictures in Draw method. A little changes will be introduced into Draw function in order to draw text content as well as pictures. The following flow chart shows what will Draw do:H2.jpg
    • After this pawsDocumentView is implemented, a corresponding pawsDocumentViewFactory will be implemented using the macro “CREATE_PAWS_FACTORY” which will enable automatically create this widget by pawsmanager. The GUI definition file for the help system should be modified to load pawsDocumentView instead of pawsMultiLineTextBox. In pawsHelp, almost nothing will be changed and it will work fine if everything has been considered correctly :P.

Additional ideas

  • Improve NPC Dialogues
  • allow changing of skin from in game
  • allow changing of language from in game
  • New spell casting widget
  • making all windows resizable without glitches, and more configurable
  • Split the items in the options window in game to be divided in basic and advanced. This will simplify readability.

Progress