PSwiki - User contributions [en]

Zhan August 15-August 21

2011-08-22T15:26:58Z

Zhanzhizheng: Created page with '* This week I finally finished the work on NPC dialog. It seems that this task has cost lots of my time. The reason is simple: I am only familiar with codes for the gui parts suc…'

* This week I finally finished the work on NPC dialog. It seems that this task has cost lots of my time. The reason is simple: I am only familiar with codes for the gui parts such as libpaws and libgui. When I have to do something with the help of other parts of PlaneShift, it will cost me lots of time reading corresponding code to learn how to use those parts. This week, I met another problem when dealing with enableing to show npc's response to player. The target is to get the npc's chat text and then display it in a bubble like widget. The displaying part is very easy for me to implement. The problem is to get the npc's chat text. I searched the entire solution many times and read lots of codes in order to find how to get these chat texts. In fact it is just in the psChatBubble.cpp file. But that cost lots of my time. I thought I should ask for help on IRC for this problem when I found it is so simple!

* Following is what I have done this week:
** Finished work on NPC dialog.
** Test the function of the new NPC dialog.
** Patch the code for NPC dialog and related files and submit.

* Plan for next week
** Solve the problems in chat window.

GSoC weekly reports

2011-08-22T15:26:35Z

Zhanzhizheng: /* August 15 - August 21 */

__NOTOC__

== May ==

Request of weekly reports was sent out the 8th of June, anyway if you have any progress report for May, please post it here.

[[Zhan 16-20]]

== June 6-12 ==

[[Landson June 6-12]]

[[Lucubro June 6-12]]

Zee no report.

== June 13-19 ==

[[Lucubro June 13-19]]

[[Landson June 13-19]]

[[Zhan June 13-19]]

[[Zee June 13-19]]

== June 20-26 ==

[[Lucubro June 20-26]]

[[Landson June 20-26]]

[[Zee June 20-26]]

[[Zhan June 20-26]]

== June 27-July 4 ==

[[Landson June 27-July 4]]

[[Lucubro June 27-July 4]]

[[Zee June 27-July 4]]

[[Zhan June 27-July 4]]

== July 5-11 ==
[[Landson July 5-11]]

[[Lucubro July 5-11]]

[[Zee July 5-11]]

[[Zhan July 5-11]]
== July 12-18 ==
[[Landson July 12-18]]

[[Zhan July 12-18]]

[[Zee July 12-18]]

[[Lucubro July 12-18]]

== July 18-25 ==
[[Landson July 18-25]]

[[Zhan July 18-25]]

[[Lucubro July 18-25]]

Zee no report.

== July 25-31 ==
[[Zhan July 25-31]]

[[Landson July 25-31]]

[[Zee July 25-31]]

Lucubro in vacation.

== July 31-August 7 ==
[[Zee July 31-August 7]]

[[Zhan July 31-August 7]]

[[Lucubro July 25-August 7]]

Landson no report (see next week for summary).

== August 8th - August 15 ==
[[Landson July 31-August 15]]

[[Lucubro August 8-15]]

[[Zee August 8-August 15]]

[[Zhan August 8-August 15]]

== August 15 - August 21 ==
[[Zee August 15-August 21]]

[[Zhan August 15-August 21]]

Zhan August 8-August 15

2011-08-22T15:12:59Z

Zhanzhizheng: Created page with '* The work on NPC dialog is continuing this week. Last week I have finished most of the interface issues and tested them. I was thinking everything will be ok soon until I found …'

* The work on NPC dialog is continuing this week. Last week I have finished most of the interface issues and tested them. I was thinking everything will be ok soon until I found the camera is not always at the first person mode when the NPC dialog pop out. Then I had to read code for camera mode control and got to know how to get the handle for the NPC that the player is interacting. That cost lots of my time because I am not very clearly about those parts. But finally I got all these problem solved. The left things are to enable NPC's response to display in a bubble style widget and some other details.

* Following is what I have done this week:
** Finished enabling first person mode camera when NPC dialog pops out.
** Enable control the target NPC to turn to player's avatar.

* Plan for next week
** Finishing NPC dialogs work and submmit patch.

GSoC weekly reports

2011-08-22T15:12:45Z

Zhanzhizheng: /* August 8th - August 15 */

Zhan July 31-August 7

2011-08-09T03:37:50Z

Zhanzhizheng: Created page with '* This week I have finished most of NPC's dialogue improvement work. As it listed http://planeshift.ezpcusa.com/pswiki/index.php?title=Improve_NPC_Dialogues, I should do lots of …'

* This week I have finished most of NPC's dialogue improvement work. As it listed http://planeshift.ezpcusa.com/pswiki/index.php?title=Improve_NPC_Dialogues, I should do lots of GUI interface rework. At first I read through the whole NPC dialogue code and got to know how this dialogue works. Then I started to do some images editing work following the guide of how to use xml file defining widgets. That's not an easy work for me I have tried many times to see the new interface, just trying to make the interface looking the same as requirement. Meanwhile, some code works are done to implement arrow clicking functions and so on. Now the work is almost done and is under testing. The code's and related files could be submitted this week.

* Following is what I have done this week:
** Finished the interface design work on NPC dialogue.
** Coding and testing on NPC new interface.

* Plan for next week
** Finish NPC dialogue improvement.
** Start to do work left undone in proposal (colour input widget related).

GSoC weekly reports

2011-08-09T02:25:38Z

Zhanzhizheng: /* July 31-August 7 */

__NOTOC__

== May ==

Request of weekly reports was sent out the 8th of June, anyway if you have any progress report for May, please post it here.

[[Zhan 16-20]]

== June 6-12 ==

[[Landson June 6-12]]

[[Lucubro June 6-12]]

Zee no report.

== June 13-19 ==

[[Lucubro June 13-19]]

[[Landson June 13-19]]

[[Zhan June 13-19]]

[[Zee June 13-19]]

== June 20-26 ==

[[Lucubro June 20-26]]

[[Landson June 20-26]]

[[Zee June 20-26]]

[[Zhan June 20-26]]

== June 27-July 4 ==

[[Landson June 27-July 4]]

[[Lucubro June 27-July 4]]

[[Zee June 27-July 4]]

[[Zhan June 27-July 4]]

== July 5-11 ==
[[Landson July 5-11]]

[[Lucubro July 5-11]]

[[Zee July 5-11]]

[[Zhan July 5-11]]
== July 12-18 ==
[[Landson July 12-18]]

[[Zhan July 12-18]]

[[Zee July 12-18]]

[[Lucubro July 12-18]]

== July 18-25 ==
[[Landson July 18-25]]

[[Zhan July 18-25]]

[[Lucubro July 18-25]]

Zee no report.

== July 25-31 ==
[[Zhan July 25-31]]

[[Landson July 25-31]]

[[Zee July 25-31]]

== July 31-August 7 ==
[[Zee July 31-August 7]]

[[Zhan July 31-August 7]]

Zhan July 25-31

2011-07-30T06:10:32Z

Zhanzhizheng: Created page with '* This week I have finished the main two tasks I listed last week. The chat window's improvement work was finally completed, code is submitted on subversion server and submitted …'

* This week I have finished the main two tasks I listed last week. The chat window's improvement work was finally completed, code is submitted on subversion server and submitted the patch to weltall. Another task is to finish the work for enabling displaying images in books. This work is alomst done after I implemented the pawsDocumentView widget. So this task is not so hard. The only problem whiling woring is to update database to give the character on my test game the right book. At first I didn't know the server cached all the data after it started. I just update the database but I didn't get the corresponding result in the client side. I tried serveral times and wasted lots of time until I finally realized that some data in the database is cached by the server and then the problem was solved. For the example thing, I have already had an example before. So I created a sample directory on subversion and uploaded two sample files and gave corresponding log info to introduce how to use the sample files.
* I have just checked my proposal timeline. According to the timeline, it's time for me to start to implement the idea of using RTT to render windows and improvie crafting books. But it seems that talad want me to focus more on GUI improvements. So I think I should discuss this problem with talad and weltall to get clear about what I need to do on the next stage.
* Following is what I have done this week:
** Finished the work on chat window.
** Finished the work on enabling books to show images.
** Commited codes to subversion server. Uploaded samples.

* Plan for next week
** Dicuss with talad and weltall to plan the next step.

GSoC weekly reports

2011-07-30T05:40:48Z

Zhanzhizheng: /* July 25-31 */

GSoC weekly reports

2011-07-30T05:40:13Z

Zhanzhizheng:

Zhan July 18-25

2011-07-24T06:51:20Z

Zhanzhizheng: Created page with '* The chat window's patch has some problems by discussing with weltall. Weltall pointed two big problem in the patch and we discussed the possible solutions to get rid of these p…'

* The chat window's patch has some problems by discussing with weltall. Weltall pointed two big problem in the patch and we discussed the possible solutions to get rid of these problems. Then I read the code for planeshift's skin system to get an overview and search solutions. I tried to design a method to write user's configuration to user data directory as the game currently does. While loading chat window, these configuration could then be loaded and processed by code to adjust the widgets in chat window. Another part of my work for this week is to study RTT and continue the work I did before. Talad asked me to place other ideas in my proposal to a higher priority. So I think I should change my plan for next week. Following is the work I did this week:
** Discussed the problems in my patch with weltall. Looking for solution to those two problems changing my code.
** Working on enabling books to show texts and images. Not finished.
** Read the current widget rendering code and continue the work I did before on RTT.
** Read the code of the skin system as well as the part for style system to get clear about skin and style and ensure the modification work on the previous patch is valid.

* Plan for next week
** Finishing work for modifying patch for chat window.
** Finishing work for enableing books to show images.

GSoC weekly reports

2011-07-24T06:23:24Z

Zhanzhizheng: /* July 18-25 */

Zhan July 12-18

2011-07-18T03:41:10Z

Zhanzhizheng: Created page with '* Last week I submitted my code for copy constructor things and continued to improve it by discussing with weltall. For chat window, I found a method to avoid reloading a chat wi…'

* Last week I submitted my code for copy constructor things and continued to improve it by discussing with weltall. For chat window, I found a method to avoid reloading a chat window. As what I planed to do before, I have to trace all objects that hold pointer to this chat window object. That's not so easy to do and not safe. So I tried to recreate children of chat window to achieve the same goal. In this way, chat window could be configured at runtime. In order to enable user select whatever tabs he/she wants to display, a function was added to chat window class to modify chat.xml. By reloading the modified chat.xml, tabs could be displayed at any combination. Following is what I did last week.
** Finished enableing user to configure chat window and to display the configured result at runtime.
** Finished enableing user to select those tabs to display on chat window.
** Commited codes to subversion server. Create patch for the chat window improvement and send to wetall. Modifies the code for copy constructor. Start to work on enable to display images in book.

* Plan for next week
** Finishing work on enabling books to show texts as well as images.
** Start to implement using RTT to render windows.

GSoC weekly reports

2011-07-18T02:11:51Z

Zhanzhizheng: /* July 12-18 */

Zhan July 5-11

2011-07-11T03:10:38Z

Zhanzhizheng: Created page with '* The work for copy constructor is finally finished. I have done a lot of test to ensure the cloned widget could be correctly constructed and destroyed. Most of the testing is do…'

* The work for copy constructor is finally finished. I have done a lot of test to ensure the cloned widget could be correctly constructed and destroyed. Most of the testing is done by cloning gui windows implemented in libgui. I have captured some screen shots while I was testing. I have to say most of my time is spending on debuging not on coding itself. Especially for fixing the bugs in destructions, lots of time is cost on looking for which attribute is not correctly cloned that leads crashing when the application is about to quit. Another part of my work for this week is continue the work for improving chat window. As weltall says, I should be carefal about those classes hold the pointer to chat window. For I changed my apart last weekend, I didn't appear on IRC in last two days.Ok, here is what I have done this week:
** Finished all the coding work for copy constructor.
** Do testing work by cloning windows defined in /data/gui/ and debuging. Fixing the crashing bug in destruction process.
** Start to continue my work on improving chat window. Tracing windows that may hold pointer to chat window in order to ensure they always hold correct pointer to chat window.

* Plan for next week
** Finishing work on chat window and send patch.
** Finishing work on enabling books to show texts as well as images (Most of the work are done by implementing pawsDocumentView widget. Only some detail work to do).

GSoC weekly reports

2011-07-11T03:09:36Z

Zhanzhizheng: /* July 5-11 */

Zhan June 27-July 4

2011-07-05T08:27:39Z

Zhanzhizheng: Created page with '* This week I almost paid all my time on coding for using copy constructor to clone widgets. Following is what I have done: ** Continue the work I have done the last week and tes…'

* This week I almost paid all my time on coding for using copy constructor to clone widgets. Following is what I have done:
** Continue the work I have done the last week and test the base pawsWidget's copy constructor. Make sure it could correctly create all children widgets using the right widget factory.
** Adding copy constructor for other widget classes in libpaws. And test those copy constructors to ensure they work.
** Solving the problem I met in adding constructor for pawsTree, pawsTreeNode. At first I didn't see clearly the relationship between pawsTree and pawsTreeNode that only one tree node would show in the cloned window. After debuging step by step I figure that the root tree node's children are all added into pawsTree widget but in pawsTreeNode's copy constructor you don't know who is the current tree node's parent tree. The problem was finally solved in pawsTree's copy constructor by recursively loop through the root tree node to add every children into their parent tree.

* Plan for next week
** Finishing copy constructor work and submit patch.
** Finishing the work for chat window improvement.

GSoC weekly reports

2011-07-05T08:12:39Z

Zhanzhizheng: /* June 27-July 4 */

Zhan 16-20

2011-07-01T07:27:35Z

Zhanzhizheng: /* May 16-20 */

== May 16-20 ==

* Monday
** Reading the code of pawsHelp and pawsMultiLineTextBox. Do some redesigning work on my previous proposal on help system part.
** Reading the code of pawsColorPromptWindow to get clear about how this widget work and what can be improved.
* Tuesday
** Continue the redesigning work, designing the help content organization algorithm and drawing corresponding flow chart.
** Design the work flow for the Draw method of the new widget and draw corresponding flow chart.
* Wednesday
** Reading the code of pawsWidget, writing simple code to test using copy constructor to duplicate widget.
** Start to implement pawsDocumentView widget.
* Thursday
** Continue implementing pawsDocumentView widget and writing some testing code.
* Friday
** Update wiki page of the help system part.
** Modify the help system’s GUI definition file and test the pawsDocumentView widget.
* Plan for next week
** Finishing the implementation design for duplicating widget by copy constructor, rendering widget by RTT and improving crafting book.
** Finishing the improvement work on pawsHelp and pawsDocumentView and submit my code.

Zhan 16-20

2011-07-01T07:26:48Z

Zhanzhizheng: Created page with '== May 16-20 == * Monday ** Reading the code of pawsHelp and pawsMultiLineTextBox. Do some redesigning work on my previous proposal on help system part. ** Reading the code of…'

== May 16-20 ==

* Monday
** Reading the code of pawsHelp and pawsMultiLineTextBox. Do some redesigning work on my previous proposal on help system part.
** Reading the code of pawsColorPromptWindow to get clear about how this widget work and what can be improved.
* Tuesday
** Continue the redesigning work, designing the help content organization algorithm and drawing corresponding flow chart.
** Design the work flow for the Draw method of the new widget and draw corresponding flow chart.
* Wednesday
** Reading the code of pawsWidget, writing simple code to test using copy constructor to duplicate widget.
** Start to implement pawsDocumentView widget.
* Thursday
** Continue implementing pawsDocumentView widget and writing some testing code.
* Friday
** Update wiki page of the help system part.
** Modify the help system’s GUI definition file and test the pawsDocumentView widget.(Still in progress)
* Plan for next week
** Finishing the implementation design for duplicating widget by copy constructor, rendering widget by RTT and improving crafting book.
** Finishing the improvement work on pawsHelp and pawsDocumentView and submit my code.

GSoC weekly reports

2011-07-01T07:23:10Z

Zhanzhizheng: /* May */

Zhan June 20-26

2011-06-30T13:05:01Z

Zhanzhizheng: Created page with '== 20-26 June == * Monday ** Add copy constructor to the base pawsWidget class to copy all the base attributes of widgets and do the same thing to widget’s children. When com…'

== 20-26 June ==

* Monday
** Add copy constructor to the base pawsWidget class to copy all the base attributes of widgets and do the same thing to widget’s children. When compiling, a lot of unexpected errors came. Many classes derived from pawsWidget could not correctly compile because of the new copy constructor in pawsWidget. I traced all the errors and fixed them to make the project correctly compiled finally.
* Tuesday
** In order to clone a window, the base widgets in libpaws should all be added copy constructors. I tried to do this to the text box widgets and buttons and multiline text box. And then tested clone the chat window by using copy constructor. But there was just a semitransparent background with the same size as the chat window to display on screen. If I tried to move the “window”, the client crashed.
* Wednesday
** Debug in the copy constructor step by step to see what is wrong while cloning chat window. Finally I found that the base copy constructor called in any derived class’s copy constructor is actually called but with no change on the base widget’s attributes. The cloned window was actually constructed and all its children widgets were created but no children widgets would be displayed. At last, the problem got solved by calling the base copy constructor in derived classes’ copy constructor’s initialization list. In this way, the base copy constructor worked finally.
* Thursday
** Discuss some issues about the copy constructor with weltall and show him the current work I had done.
** Continue adding other copy constructor to classes in libpaws and test them.
* Friday
** Continue adding other copy constructor to classes in libpaws and test them.
* Plan for next week
** Tasks for this week are not totally finished. Works should be finished next week.
** Start to design using RTT rendering widgets.

GSoC weekly reports

2011-06-30T13:01:10Z

Zhanzhizheng: /* June 20-26 */

__NOTOC__

== May ==

Request of weekly reports was sent out the 8th of June, anyway if you have any progress report for May, please post it here.

== June 6-12 ==

[[Landson June 6-12]]

Zee no report.

== June 13-19 ==

[[Lucubro June 13-19]]

[[Landson June 13-19]]

[[Zhan June 13-19]]

[[Zee June 13-19]]

== June 20-26 ==

[[Lucubro June 20-26]]

[[Landson June 20-26]]

[[Zee June 20-26]]

[[Zhan June 20-26]]

Zhan June 13-19

2011-06-30T01:19:27Z

Zhanzhizheng: /* 5.16-5.20 (????) */

== Weekly Report ==

== 13-19 June ==

* Monday
** Start to design the function of clone widgets by using copy constructor.
** Finishing the work for improving the implementation of pawsDocumentView.
* Tuesday
** Continue designing work on copy constructor for cloning widgets.
** Study the widget creating process; Test adding a copy constructor to the base widget class and do clone work.
* Wednesday
** Make a patch for pawsDocumentView and send to weltall.
** Continue implementing on copy constructor.
* Thursday
** Reading doxygen document; Polishing the code for pawsDocumentView; Making patches for pawsDocumentView until weltall thought it was ok.
** Replace the work on my computer in our lab to my own laptop for my graduation day is coming.
* Friday
** Continue implementing work on copy constructor. Modifying my initial design.
* Plan for next week
** Finishing the implementation copy constructor.
** Start to design using RTT rendering widgets.
* Things need to report
** There is a short trip on this Sunday, next week’s Monday and Tuesday. I could not be on IRC all day. I know I am already behind my plan. So I will try to keep on progress to work even if I am on my trip.

Improved UI 2011

2011-05-20T05:39:53Z

Zhanzhizheng: /* Implementation Detail */

(Go back to the main [[GSoC_2011|GSoC 2011]] 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 [http://planeshift.ezpcusa.com/pswiki/index.php?title=GUI 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 pictures/3d objects in the help widget, make it more configurable and context sentitive.(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. Mouseovering 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 knownledge is suggested)
* '''Chat window''': today the chat window has 2 settings: basic and full. The basic is used for new players to avoid showing elements like alliance or guild, since they will not use it for some time. The issue is that the chat window cannot change at runtime, and so when we want to switch between the basic and the full, we need to ask a restart of the client. The idea is to make the tabs configurable at runtime, so we can drive with an in game event the addition and removal of certain tabs. For example adding the guilds tab only when a player belongs to a guild. The list of tabs visible should be configurable in the options menu.
* '''Images in books''': Add the ability to include images in books, for example, an image of a creature could be included in the bestiary books.
* '''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.
* '''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.
* Hot bar for spells and items, with support for multiple rows, which can be resized and hidden.

* 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)

== 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 ==
# 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.[[File: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:[[File: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 ==
* 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 ==

File:H2.jpg

2011-05-20T05:36:44Z

Zhanzhizheng:

File:H1.jpg

2011-05-20T05:34:29Z

Zhanzhizheng: Figure 1

Figure 1

Improved UI 2011

2011-05-20T05:33:46Z

Zhanzhizheng: /* Implementation Detail */

(Go back to the main [[GSoC_2011|GSoC 2011]] 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 [http://planeshift.ezpcusa.com/pswiki/index.php?title=GUI 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 pictures/3d objects in the help widget, make it more configurable and context sentitive.(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. Mouseovering 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 knownledge is suggested)
* '''Chat window''': today the chat window has 2 settings: basic and full. The basic is used for new players to avoid showing elements like alliance or guild, since they will not use it for some time. The issue is that the chat window cannot change at runtime, and so when we want to switch between the basic and the full, we need to ask a restart of the client. The idea is to make the tabs configurable at runtime, so we can drive with an in game event the addition and removal of certain tabs. For example adding the guilds tab only when a player belongs to a guild. The list of tabs visible should be configurable in the options menu.
* '''Images in books''': Add the ability to include images in books, for example, an image of a creature could be included in the bestiary books.
* '''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.
* '''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.
* Hot bar for spells and items, with support for multiple rows, which can be resized and hidden.

* 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)

== 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 ==
# 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.
[[File: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:
#:*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 ==
* 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 ==

Improved UI 2011

2011-05-20T05:30:13Z

Zhanzhizheng:

(Go back to the main [[GSoC_2011|GSoC 2011]] 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 [http://planeshift.ezpcusa.com/pswiki/index.php?title=GUI 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 pictures/3d objects in the help widget, make it more configurable and context sentitive.(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. Mouseovering 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 knownledge is suggested)
* '''Chat window''': today the chat window has 2 settings: basic and full. The basic is used for new players to avoid showing elements like alliance or guild, since they will not use it for some time. The issue is that the chat window cannot change at runtime, and so when we want to switch between the basic and the full, we need to ask a restart of the client. The idea is to make the tabs configurable at runtime, so we can drive with an in game event the addition and removal of certain tabs. For example adding the guilds tab only when a player belongs to a guild. The list of tabs visible should be configurable in the options menu.
* '''Images in books''': Add the ability to include images in books, for example, an image of a creature could be included in the bestiary books.
* '''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.
* '''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.
* Hot bar for spells and items, with support for multiple rows, which can be resized and hidden.

* 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)

== 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 ==
# 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.
#::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:
#:*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 ==
* 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 ==

Improved UI 2011

2011-05-03T01:30:09Z

Zhanzhizheng: /* Design */

(Go back to the main [[GSoC_2011|GSoC 2011]] 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 [http://planeshift.ezpcusa.com/pswiki/index.php?title=GUI 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 pictures/3d objects in the help widget, make it more configurable and context sentitive.(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. Mouseovering 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 knownledge is suggested)
* '''Chat window''': today the chat window has 2 settings: basic and full. The basic is used for new players to avoid showing elements like alliance or guild, since they will not use it for some time. The issue is that the chat window cannot change at runtime, and so when we want to switch between the basic and the full, we need to ask a restart of the client. The idea is to make the tabs configurable at runtime, so we can drive with an in game event the addition and removal of certain tabs. For example adding the guilds tab only when a player belongs to a guild. The list of tabs visible should be configurable in the options menu.
* '''Images in books''': Add the ability to include images in books, for example, an image of a creature could be included in the bestiary books.
* '''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.
* '''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.
* Hot bar for spells and items, with support for multiple rows, which can be resized and hidden.

* 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)

== 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.

== Additional ideas ==
* 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 ==

Improved UI 2011

2011-05-03T00:50:28Z

Zhanzhizheng: /* Design a kind of XML definition which could incorporate text content and pictures. For example: */

Improved UI 2011

2011-05-03T00:48:17Z

Zhanzhizheng: /* Design */

Improved UI 2011

2011-05-03T00:46:51Z

Zhanzhizheng: /* Design */

Improved UI 2011

2011-05-03T00:45:06Z

Zhanzhizheng: /* Design */

Improved UI 2011

2011-05-03T00:44:30Z

Zhanzhizheng:

Improved UI 2011

2011-04-29T01:48:07Z

Zhanzhizheng: /* Improvements needed */

Improved UI 2011

2011-04-29T01:47:31Z

Zhanzhizheng: /* Improvements needed */

Improved UI 2011

2011-04-29T01:47:10Z

Zhanzhizheng: /* Improvements needed */

Improved UI 2011

2011-04-29T01:43:02Z

Zhanzhizheng: