Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2013/FINAL PROJECT E736 UNDO DELIVERABLE

2013-04-23T18:19:55Z

Ctsui: /* List of Items Now Supported by Undo Functionality */

= E736. Undo Functionality for Expertiza =
*Contacts: Ed Gehringer (efg@ncsu.edu) and Andrew Kofink (ajkofink@ncsu.edu)
*[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/FINAL_PROJECT_E736_UNDO Design Document]
*[https://docs.google.com/a/ncsu.edu/document/d/11YTjxFXFR13vJ769yFBbqn9qOueK2Ktz0Pd-gyS2W5U/ Project Description Doc]
== Team Members ==
*Chun Sing Tsui (ctsui@ncsu.edu)
*Kenny Yarboro (kbyarbor@ncsu.edu)
*Meng Cao (mcao2@ncsu.edu)
*Travis Folsom (twfolsom@ncsu.edu)

== Project Deliverables ==

=== Screencast Video Overview ===
A video overview of the project was created via [http://www.screencast-o-matic.com/ Screencast-O-Matic] and can be found [http://www.youtube.com/watch?v=1DYS5InjBOk here].

=== Overview of Undo Functionality ===
*Undo allows the user to undo their most recent actions for any items that offer the undo functionality.
*The undo of file submissions was not required; it is not implemented in this project.
*If an undo is attempted on an item already modified by another user, a message is displayed stating why undo cannot be performed. Otherwise, the user is able to undo any changes to an item with the undo functionality.
*When multiple actions are performed in one step, the undo functionality groups all of the changes together for the purposes of restoring all items affected by the action previously performed.

=== List of Items Now Supported by Undo Functionality ===
*Add Signup Sheet
**Delete Topic
**Edit Topic
**New Topic
*Assignments
**Add/Remove Participants
**Inherit Participants from Course
**Copy Participants to Course
**Copy
**Create
**Delete
**Edit
*Courses
**Add Participants
**Copy
**Create
**Delete
**Edit
**Toggle Private/Public
*Import
**Import Participants
**Import Teams
**Import Users
*Student Actions
**Create Team
**Edit Team Name
**Leave Team
**Submit Hyperlink
*Questions
**Copy
**Create
**Delete
**Edit
*Questionnaires
**Copy
**Create
**Delete
**Edit
*Teams
**Add
**Create (Manual)
**Create (Random)
**Delete
**Delete All Teams
**Edit

=== Redo Functionality ===
In addition to the Undo functionality being added, the ability to Redo an undone action is also implemented. Whenever an Undo is performed, the user is given an option to Redo the action that was undone. Whenever a Redo is performed, the user is given an option to Undo the action again.

=== Design Patterns and Designs ===
*DRY
**"Don't Repeat Yourself" practice was followed.
**The app/controllers/application_controller.rb file contains all of the Undo functionality code for Expertiza. All other controllers are able to call the necessary undo-related methods to enable the Undo functionality.

=== Framework Leveraged & Enhanced ===
*Paper Trail(https://github.com/airblade/paper_trail)
**Paper Trail allows for tracking changes to model data.
***Good for auditing or versioning.
**Offers many functionalities including:
****Viewing a model at any stage in its lifecycle.
****Reverting a model to any version.
****Undeleting items after they have been destroyed.
**Compatible with Rails-2.3.15, which is the version Expertiza uses.
**There is a [http://railscasts.com/episodes/255-undo-with-paper-trail Railscast] showing how to implement the undo feature with Paper Trail.
**Ranked as the most popular framework for Active Record versioning feature in [https://www.ruby-toolbox.com/categories/Active_Record_Versioning here]
*Enhancement
**Paper Trail only supported undo of the most recent action and did not restore associations.
**Paper Trail customized to add support for restoring associations within the Expertiza system.
***Database transactions paired with timestamps and user ids to group them together.

=== Classes Modified ===
*apps/
**controllers/
***application_controller.rb
***assignment_controller.rb
***course_controller.rb
***import_file_controller.rb
***participants_controller.rb
***sign_up_sheet_controller.rb
***student_team_controller.rb
***team_controller.rb
***teams_users_controller.rb
***versions_controller.rb
**models/
***assignment_participant.rb
***course.rb
***participant.rb
***sign_up_topic.rb
***ta_mapping.rb
***team_node.rb
***teams_user.rb

=== Unit & Functional Tests ===
The implementation of the Undo functionality did not afford any testing opportunities applicable to unit or functional tests.

=== Bug Fixes & Other Improvements ===
The following bugs were found within Expertiza and fixed:
*ApplicationController enhanced to rescue from ActiveRecord::RecordNotFound errors and redirect to tree display.
*Copy of Assignment opened Edit page for the original Assignment and now correctly opens the Edit page for the copy of the assignment.

The following general improvements were made:
*Explicitly declared the has_one association between each object and its tree node to eliminate the manual deletion of a related tree node with the object.
*Edited the Copy of Course flash message to be more clear that the copy had already been created and to resolve a misspelling.

=== Problem Areas with Expertiza ===
There were some areas of functionality within Expertiza that did not work. There were some cases in which the undo functionality could not be added due to the inherent problems. These problem areas were:
*Assigning surveys in an assignment.
*Dates in assignments do not show up when the assignment is edited.
*Unable to assign random reviewers.
*Unable to edit advice for questions in questionnaire.
*Unable to remove participants from a course.
*Unable to inherit team from a course

=== Future Recommendations ===
*Add integration tests.
*Add undo functionality to other areas of Expertiza (especially student actions such as review responses)
*Determine appropriate methodology for cleaning up Versions table.

=== Template to Implement Undo Functionality ===
* Install paper_trail gem. Please follow the steps listed on its [https://github.com/airblade/paper_trail official webpage ].
* Add ''has_paper_trail'' to the model you want to have undo functionality
class Foo < ActiveRecord::Base
has_paper_trail
...
end

* Call ''undo_link'' method in the corresponding controller. The argument is a string, which you want to show along with the undo link in flash[:note]. The following is code snippet shows how the undo functionality is implemented for the delete method of FoosController
class FoosController < ApplicationController
def delete
@foo = Foo.find(params[:id])
@foo.destroy
undo_link("Foo \"#{@foo.name}\" has been deleted successfully. ")
redirect_to :back
end
end

CSC/ECE 517 Spring 2013/FINAL PROJECT E736 UNDO DELIVERABLE

2013-04-23T00:20:30Z

Ctsui: /* Future Recommendations */

= E736. Undo Functionality for Expertiza =
*Contacts: Ed Gehringer (efg@ncsu.edu) and Andrew Kofink (ajkofink@ncsu.edu)
*[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/FINAL_PROJECT_E736_UNDO Design Document]
*[https://docs.google.com/a/ncsu.edu/document/d/11YTjxFXFR13vJ769yFBbqn9qOueK2Ktz0Pd-gyS2W5U/ Project Description Doc]
== Team Members ==
*Chun Sing Tsui (ctsui@ncsu.edu)
*Kenny Yarboro (kbyarbor@ncsu.edu)
*Meng Cao (mcao2@ncsu.edu)
*Travis Folsom (twfolsom@ncsu.edu)

== Project Deliverables ==

=== Screencast Video Overview ===
A video overview of the project was created via [http://www.screencast-o-matic.com/ Screencast-O-Matic] and can be found [http://www.youtube.com/watch?v=1DYS5InjBOk here].

=== Overview of Undo Functionality ===
*Undo allows the user to undo their most recent actions for any items that offer the undo functionality.
*The undo of file submissions was not required; it is not implemented in this project.
*If an undo is attempted on an item already modified by another user, a message is displayed stating why undo cannot be performed. Otherwise, the user is able to undo any changes to an item with the undo functionality.
*When multiple actions are performed in one step, the undo functionality groups all of the changes together for the purposes of restoring all items affected by the action previously performed.

=== List of Items Now Supported by Undo Functionality ===
*Add Signup Sheet
**Delete Topic
**Edit Topic
**New Topic
*Assignments
**Add/Remove Participants
**Copy
**Create
**Delete
**Edit
*Courses
**Add Participants
**Copy
**Create
**Delete
**Edit
**Toggle Private/Public
*Import
**Import Participants
**Import Teams
**Import Users
*Student Actions
**Create Team
**Edit Team Name
**Leave Team
**Submit Hyperlink
*Questions
**Copy
**Create
**Delete
**Edit
*Questionnaires
**Copy
**Create
**Delete
**Edit
*Teams
**Add
**Create (Manual)
**Create (Random)
**Delete
**Delete All Teams
**Edit

=== Redo Functionality ===
In addition to the Undo functionality being added, the ability to Redo an undone action is also implemented. Whenever an Undo is performed, the user is given an option to Redo the action that was undone. Whenever a Redo is performed, the user is given an option to Undo the action again.

=== Design Patterns and Designs ===
*DRY
**"Don't Repeat Yourself" practice was followed.
**The app/controllers/application_controller.rb file contains all of the Undo functionality code for Expertiza. All other controllers are able to call the necessary undo-related methods to enable the Undo functionality.

=== Framework Leveraged & Enhanced ===
*Paper Trail(https://github.com/airblade/paper_trail)
**Paper Trail allows for tracking changes to model data.
***Good for auditing or versioning.
**Offers many functionalities including:
****Viewing a model at any stage in its lifecycle.
****Reverting a model to any version.
****Undeleting items after they have been destroyed.
**Compatible with Rails-2.3.15, which is the version Expertiza uses.
**There is a [http://railscasts.com/episodes/255-undo-with-paper-trail Railscast] showing how to implement the undo feature with Paper Trail.
**Ranked as the most popular framework for Active Record versioning feature in [https://www.ruby-toolbox.com/categories/Active_Record_Versioning here]
*Enhancement
**Paper Trail only supported undo of the most recent action and did not restore associations.
**Paper Trail customized to add support for restoring associations within the Expertiza system.
***Database transactions paired with timestamps and user ids to group them together.

=== Classes Modified ===
*apps/
**controllers/
***application_controller.rb
***assignment_controller.rb
***course_controller.rb
***import_file_controller.rb
***participants_controller.rb
***sign_up_sheet_controller.rb
***student_team_controller.rb
***team_controller.rb
***teams_users_controller.rb
***versions_controller.rb
**models/
***assignment_participant.rb
***course.rb
***participant.rb
***sign_up_topic.rb
***ta_mapping.rb
***team_node.rb
***teams_user.rb

=== Unit & Functional Tests ===
The implementation of the Undo functionality did not afford any testing opportunities applicable to unit or functional tests.

=== Bug Fixes & Other Improvements ===
The following bugs were found within Expertiza and fixed:
*ApplicationController enhanced to rescue from ActiveRecord::RecordNotFound errors and redirect to tree display.
*Copy of Assignment opened Edit page for the original Assignment and now correctly opens the Edit page for the copy of the assignment.

The following general improvements were made:
*Explicitly declared the has_one association between each object and its tree node to eliminate the manual deletion of a related tree node with the object.
*Edited the Copy of Course flash message to be more clear that the copy had already been created and to resolve a misspelling.

=== Problem Areas with Expertiza ===
There were some areas of functionality within Expertiza that did not work. There were some cases in which the undo functionality could not be added due to the inherent problems. These problem areas were:
*Assigning surveys in an assignment.
*Dates in assignments do not show up when the assignment is edited.
*Unable to assign random reviewers.
*Unable to edit advice for questions in questionnaire.
*Unable to remove participants from a course.
*Unable to inherit team from a course

=== Future Recommendations ===
*Add integration tests.
*Add undo functionality to other areas of Expertiza (especially student actions such as review responses)
*Determine appropriate methodology for cleaning up Versions table.

=== Template to Implement Undo Functionality ===
* Install paper_trail gem. Please follow the steps listed on its [https://github.com/airblade/paper_trail official webpage ].
* Add ''has_paper_trail'' to the model you want to have undo functionality
class Foo < ActiveRecord::Base
has_paper_trail
...
end

* Call ''undo_link'' method in the corresponding controller. The argument is a string, which you want to show along with the undo link in flash[:note]. The following is code snippet shows how the undo functionality is implemented for the delete method of FoosController
class FoosController < ApplicationController
def delete
@foo = Foo.find(params[:id])
@foo.destroy
undo_link("Foo \"#{@foo.name}\" has been deleted successfully. ")
redirect_to :back
end
end

CSC/ECE 517 Spring 2013/FINAL PROJECT E736 UNDO DELIVERABLE

2013-04-23T00:17:28Z

Ctsui: /* Overview of Undo Functionality */

= E736. Undo Functionality for Expertiza =
*Contacts: Ed Gehringer (efg@ncsu.edu) and Andrew Kofink (ajkofink@ncsu.edu)
*[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/FINAL_PROJECT_E736_UNDO Design Document]
*[https://docs.google.com/a/ncsu.edu/document/d/11YTjxFXFR13vJ769yFBbqn9qOueK2Ktz0Pd-gyS2W5U/ Project Description Doc]
== Team Members ==
*Chun Sing Tsui (ctsui@ncsu.edu)
*Kenny Yarboro (kbyarbor@ncsu.edu)
*Meng Cao (mcao2@ncsu.edu)
*Travis Folsom (twfolsom@ncsu.edu)

== Project Deliverables ==

=== Screencast Video Overview ===
A video overview of the project was created via [http://www.screencast-o-matic.com/ Screencast-O-Matic] and can be found [http://www.youtube.com/watch?v=1DYS5InjBOk here].

=== Overview of Undo Functionality ===
*Undo allows the user to undo their most recent actions for any items that offer the undo functionality.
*The undo of file submissions was not required; it is not implemented in this project.
*If an undo is attempted on an item already modified by another user, a message is displayed stating why undo cannot be performed. Otherwise, the user is able to undo any changes to an item with the undo functionality.
*When multiple actions are performed in one step, the undo functionality groups all of the changes together for the purposes of restoring all items affected by the action previously performed.

=== List of Items Now Supported by Undo Functionality ===
*Add Signup Sheet
**Delete Topic
**Edit Topic
**New Topic
*Assignments
**Add/Remove Participants
**Copy
**Create
**Delete
**Edit
*Courses
**Add Participants
**Copy
**Create
**Delete
**Edit
**Toggle Private/Public
*Import
**Import Participants
**Import Teams
**Import Users
*Student Actions
**Create Team
**Edit Team Name
**Leave Team
**Submit Hyperlink
*Questions
**Copy
**Create
**Delete
**Edit
*Questionnaires
**Copy
**Create
**Delete
**Edit
*Teams
**Add
**Create (Manual)
**Create (Random)
**Delete
**Delete All Teams
**Edit

=== Redo Functionality ===
In addition to the Undo functionality being added, the ability to Redo an undone action is also implemented. Whenever an Undo is performed, the user is given an option to Redo the action that was undone. Whenever a Redo is performed, the user is given an option to Undo the action again.

=== Design Patterns and Designs ===
*DRY
**"Don't Repeat Yourself" practice was followed.
**The app/controllers/application_controller.rb file contains all of the Undo functionality code for Expertiza. All other controllers are able to call the necessary undo-related methods to enable the Undo functionality.

=== Framework Leveraged & Enhanced ===
*Paper Trail(https://github.com/airblade/paper_trail)
**Paper Trail allows for tracking changes to model data.
***Good for auditing or versioning.
**Offers many functionalities including:
****Viewing a model at any stage in its lifecycle.
****Reverting a model to any version.
****Undeleting items after they have been destroyed.
**Compatible with Rails-2.3.15, which is the version Expertiza uses.
**There is a [http://railscasts.com/episodes/255-undo-with-paper-trail Railscast] showing how to implement the undo feature with Paper Trail.
**Ranked as the most popular framework for Active Record versioning feature in [https://www.ruby-toolbox.com/categories/Active_Record_Versioning here]
*Enhancement
**Paper Trail only supported undo of the most recent action and did not restore associations.
**Paper Trail customized to add support for restoring associations within the Expertiza system.
***Database transactions paired with timestamps and user ids to group them together.

=== Classes Modified ===
*apps/
**controllers/
***application_controller.rb
***assignment_controller.rb
***course_controller.rb
***import_file_controller.rb
***participants_controller.rb
***sign_up_sheet_controller.rb
***student_team_controller.rb
***team_controller.rb
***teams_users_controller.rb
***versions_controller.rb
**models/
***assignment_participant.rb
***course.rb
***participant.rb
***sign_up_topic.rb
***ta_mapping.rb
***team_node.rb
***teams_user.rb

=== Unit & Functional Tests ===
The implementation of the Undo functionality did not afford any testing opportunities applicable to unit or functional tests.

=== Bug Fixes & Other Improvements ===
The following bugs were found within Expertiza and fixed:
*ApplicationController enhanced to rescue from ActiveRecord::RecordNotFound errors and redirect to tree display.
*Copy of Assignment opened Edit page for the original Assignment and now correctly opens the Edit page for the copy of the assignment.

The following general improvements were made:
*Explicitly declared the has_one association between each object and its tree node to eliminate the manual deletion of a related tree node with the object.
*Edited the Copy of Course flash message to be more clear that the copy had already been created and to resolve a misspelling.

=== Problem Areas with Expertiza ===
There were some areas of functionality within Expertiza that did not work. There were some cases in which the undo functionality could not be added due to the inherent problems. These problem areas were:
*Assigning surveys in an assignment.
*Dates in assignments do not show up when the assignment is edited.
*Unable to assign random reviewers.
*Unable to edit advice for questions in questionnaire.
*Unable to remove participants from a course.
*Unable to inherit team from a course

=== Future Recommendations ===
*Add integration tests.
*Add undo functionality to other areas of Expertiza.
*Determine appropriate methodology for cleaning up Versions table.

=== Template to Implement Undo Functionality ===
* Install paper_trail gem. Please follow the steps listed on its [https://github.com/airblade/paper_trail official webpage ].
* Add ''has_paper_trail'' to the model you want to have undo functionality
class Foo < ActiveRecord::Base
has_paper_trail
...
end

* Call ''undo_link'' method in the corresponding controller. The argument is a string, which you want to show along with the undo link in flash[:note]. The following is code snippet shows how the undo functionality is implemented for the delete method of FoosController
class FoosController < ApplicationController
def delete
@foo = Foo.find(params[:id])
@foo.destroy
undo_link("Foo \"#{@foo.name}\" has been deleted successfully. ")
redirect_to :back
end
end

CSC/ECE 517 Spring 2013/FINAL PROJECT E736 UNDO DELIVERABLE

2013-04-23T00:14:58Z

Ctsui: /* Overview of Undo Functionality */

= E736. Undo Functionality for Expertiza =
*Contacts: Ed Gehringer (efg@ncsu.edu) and Andrew Kofink (ajkofink@ncsu.edu)
*[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/FINAL_PROJECT_E736_UNDO Design Document]
*[https://docs.google.com/a/ncsu.edu/document/d/11YTjxFXFR13vJ769yFBbqn9qOueK2Ktz0Pd-gyS2W5U/ Project Description Doc]
== Team Members ==
*Chun Sing Tsui (ctsui@ncsu.edu)
*Kenny Yarboro (kbyarbor@ncsu.edu)
*Meng Cao (mcao2@ncsu.edu)
*Travis Folsom (twfolsom@ncsu.edu)

== Project Deliverables ==

=== Screencast Video Overview ===
A video overview of the project was created via [http://www.screencast-o-matic.com/ Screencast-O-Matic] and can be found [http://www.youtube.com/watch?v=1DYS5InjBOk here].

=== Overview of Undo Functionality ===
*Undo allows the user to undo their most recent actions for any items that offer the undo functionality.
*The undo of file submissions was not required
*If an undo is attempted on an item already modified by another user, a message is displayed stating why undo cannot be performed. Otherwise, the user is able to undo any changes to an item with the undo functionality.
*When multiple actions are performed in one step, the undo functionality groups all of the changes together for the purposes of restoring all items affected by the action previously performed.

=== List of Items Now Supported by Undo Functionality ===
*Add Signup Sheet
**Delete Topic
**Edit Topic
**New Topic
*Assignments
**Add/Remove Participants
**Copy
**Create
**Delete
**Edit
*Courses
**Add Participants
**Copy
**Create
**Delete
**Edit
**Toggle Private/Public
*Import
**Import Participants
**Import Teams
**Import Users
*Student Actions
**Create Team
**Edit Team Name
**Leave Team
**Submit Hyperlink
*Questions
**Copy
**Create
**Delete
**Edit
*Questionnaires
**Copy
**Create
**Delete
**Edit
*Teams
**Add
**Create (Manual)
**Create (Random)
**Delete
**Delete All Teams
**Edit

=== Redo Functionality ===
In addition to the Undo functionality being added, the ability to Redo an undone action is also implemented. Whenever an Undo is performed, the user is given an option to Redo the action that was undone. Whenever a Redo is performed, the user is given an option to Undo the action again.

=== Design Patterns and Designs ===
*DRY
**"Don't Repeat Yourself" practice was followed.
**The app/controllers/application_controller.rb file contains all of the Undo functionality code for Expertiza. All other controllers are able to call the necessary undo-related methods to enable the Undo functionality.

=== Framework Leveraged & Enhanced ===
*Paper Trail(https://github.com/airblade/paper_trail)
**Paper Trail allows for tracking changes to model data.
***Good for auditing or versioning.
**Offers many functionalities including:
****Viewing a model at any stage in its lifecycle.
****Reverting a model to any version.
****Undeleting items after they have been destroyed.
**Compatible with Rails-2.3.15, which is the version Expertiza uses.
**There is a [http://railscasts.com/episodes/255-undo-with-paper-trail Railscast] showing how to implement the undo feature with Paper Trail.
**Ranked as the most popular framework for Active Record versioning feature in [https://www.ruby-toolbox.com/categories/Active_Record_Versioning here]
*Enhancement
**Paper Trail only supported undo of the most recent action and did not restore associations.
**Paper Trail customized to add support for restoring associations within the Expertiza system.
***Database transactions paired with timestamps and user ids to group them together.

=== Classes Modified ===
*apps/
**controllers/
***application_controller.rb
***assignment_controller.rb
***course_controller.rb
***import_file_controller.rb
***participants_controller.rb
***sign_up_sheet_controller.rb
***student_team_controller.rb
***team_controller.rb
***teams_users_controller.rb
***versions_controller.rb
**models/
***assignment_participant.rb
***course.rb
***participant.rb
***sign_up_topic.rb
***ta_mapping.rb
***team_node.rb
***teams_user.rb

=== Unit & Functional Tests ===
The implementation of the Undo functionality did not afford any testing opportunities applicable to unit or functional tests.

=== Bug Fixes & Other Improvements ===
The following bugs were found within Expertiza and fixed:
*ApplicationController enhanced to rescue from ActiveRecord::RecordNotFound errors and redirect to tree display.
*Copy of Assignment opened Edit page for the original Assignment and now correctly opens the Edit page for the copy of the assignment.

The following general improvements were made:
*Explicitly declared the has_one association between each object and its tree node to eliminate the manual deletion of a related tree node with the object.
*Edited the Copy of Course flash message to be more clear that the copy had already been created and to resolve a misspelling.

=== Problem Areas with Expertiza ===
There were some areas of functionality within Expertiza that did not work. There were some cases in which the undo functionality could not be added due to the inherent problems. These problem areas were:
*Assigning surveys in an assignment.
*Dates in assignments do not show up when the assignment is edited.
*Unable to assign random reviewers.
*Unable to edit advice for questions in questionnaire.
*Unable to remove participants from a course.
*Unable to inherit team from a course

=== Future Recommendations ===
*Add integration tests.
*Add undo functionality to other areas of Expertiza.
*Determine appropriate methodology for cleaning up Versions table.

=== Template to Implement Undo Functionality ===
* Install paper_trail gem. Please follow the steps listed on its [https://github.com/airblade/paper_trail official webpage ].
* Add ''has_paper_trail'' to the model you want to have undo functionality
class Foo < ActiveRecord::Base
has_paper_trail
...
end

* Call ''undo_link'' method in the corresponding controller. The argument is a string, which you want to show along with the undo link in flash[:note]. The following is code snippet shows how the undo functionality is implemented for the delete method of FoosController
class FoosController < ApplicationController
def delete
@foo = Foo.find(params[:id])
@foo.destroy
undo_link("Foo \"#{@foo.name}\" has been deleted successfully. ")
redirect_to :back
end
end

CSC/ECE 517 Spring 2013/FINAL PROJECT E736 UNDO

2013-04-02T00:57:16Z

Ctsui: /* E736. Undo Functionality for Expertiza */

= E736. Undo Functionality for Expertiza =
*Contacts: Ed Gehringer (efg@ncsu.edu) and Andrew Kofink (ajkofink@ncsu.edu)
*Begin implementing SQL transactions (ActiveRecord:Transactions). This should let the user "roll back" any creation or update of a SQL table (assignments, rubrics, etc.) Several issues arise, that you should discuss with me.
**Should students be able to roll back, e.g., submissions or reviews?
**Suppose an instructor is trying to roll back and a TA is editing the same assignment? How can conflicts be presented?
**Do rollbacks affect only what's in the db, or do they also affect submitted files?
*[https://docs.google.com/a/ncsu.edu/document/d/11YTjxFXFR13vJ769yFBbqn9qOueK2Ktz0Pd-gyS2W5U/ Project Description Doc]
== Team Members ==
*Chun Sing Tsui (ctsui@ncsu.edu)
*Kenny Yarboro (kbyarbor@ncsu.edu)
*Meng Cao (mcao2@ncsu.edu)
*Travis Folsom (twfolsom@ncsu.edu)

== Design Document ==

=== Overview of Undo Functionality ===
*Undo should cover any edit functionalities and any submissions of links. File submissions do not need to be included for the scope of this project.
*User should be able to undo any changes to an item (such as course or assignment) as long as no other user has edited that same item within the user's current session.
*If undo is attempted on an item already modified by another user, display a message stating why undo cannot be done.

=== List of Items to be Supported by Undo Functionality ===
*Assignments
*Courses
*More items may be covered if time allows.

=== Design Patterns and Designs ===
*DRY
**"Don't Repeat Yourself" practice will be followed.
*Memento
**The Memento pattern will be followed through open-source Ruby gems leveraged by the project.

=== Frameworks to Leverage ===
*Paper Trail(https://github.com/airblade/paper_trail)
**PaperTrail allows for tracking changes to model data.
***Good for auditing or versioning.
**Offers many functionalities including:
****Viewing a model at any stage in its lifecycle.
****Reverting a model to any version.
****Undeleting items after they have been destroyed.
**Compatible with Rails-2.3.15, which is the version Expertiza uses.
**There is a [http://railscasts.com/episodes/255-undo-with-paper-trail Railscast] showing how to implement the undo feature with Paper Trail.
**Ranked as the most popular framework for Active Record versioning feature in [https://www.ruby-toolbox.com/categories/Active_Record_Versioning here]
**Alternative Frameworks are listed [https://www.ruby-toolbox.com/categories/Active_Record_Versioning here].

=== Expected Classes to be Modified ===
*Assignment-related Classes
*Course-related Classes
*More classes may be covered as time allows.

=== Unit Testing Plans ===
*Every class method modified will be tested via unit test.
*Every new method added will be tested via at least one unit test.
*All test methods shall be named with an appropriately descriptive name that is not too long.

=== Functional Testing Plans ===
*The following functional test plans will be followed for all items enhanced with the Undo functionality:
**Test that an item may be changed, then undo performed successfully.
**Test that a sequence of changes may be performed by one user, then undo performed successfully for each action from the sequence.
**Test that an item may be changed by one user, changed again by another user, then undo performed by the original user will display a failure message with description.

CSC/ECE 517 Spring 2013/OSS E605B

2013-03-21T02:00:18Z

Ctsui: /* Highlights of Project */

=Testing - questionnaire=
[https://docs.google.com/a/ncsu.edu/document/d/1SVNx7Eh6dUdrz2a9rGSgBxLkxAmuBUm8eu08nHEdjIg/edit# Project Description]

== QuestionnaireController Functional Tests ==

The majority of the tests implemented in this project are functional tests of the questionnaire controller. The test cases were written using the [http://api.rubyonrails.org/classes/ActionController/TestCase.html ActionController::TestCase] framework provided by Rails.

=== Modifications to Existing QuestionnaireController Test ===

There were a few tests already written for the Questionnaire controller, but they were not passing initially. We had to modify several things in the test and questionnaire fixture in order to get things up and running. The setup method contained login code that was outdated, and thus each test would result in a redirect due to the invalid login credential. So we looked through other more up to date functional test files and found the correct way to login as a particular user. We also put this code in a helper method so we can call it more easily in different tests if we so choose (more on this in the "Helper Methods" section).

In addition, we added new fixtures to help with our testing. Through debugging the test error messages, we saw that an additional required column called "section" has been added to the "Questionnaire" model, which was contributing to the failures. We added the additional column accordingly in our new fixures.

=== Helper Methods ===

There are two methods that assist in setting up and running the tests:

*The setup method
*The login_user method

The setup method assigns three special instance variables that are associated with the ActionController::TestCase (@controller, @request, and @response). In addition to setting these, the @Questionnaire variable is assigned to id of the :questionnaire5 fixture. This is the default questionnaire fixture that is used in a lot of the test cases. You will also notice that the fixture :admin is being logged in as the default user. This is done so that you don't have explicitly log into a user account for each test case. The only time you would need to call the method to log in for a particular test case is if you needed to test something specifically in another user type's account (for example a student account as is done in test_create_questionnaire_with_student.

def setup
@controller = QuestionnaireController.new
@request = ActionController::TestRequest.new
@response = ActionController::TestResponse.new
@Questionnaire = questionnaires(:questionnaire5).id
login_user(:admin)
end

The login_user method was created to "DRY out" the code associated with logging a user in. The method signature is:

def login_user(userType)

If you pass a symbol of the user type you would like to use for a test, it will log in as that user type for the particular test. The parameter name is userType and assumes that there is a fixture with the name of the user type. There seem to be sufficient fixtures for all of the different user types currently, but additional fixtures may need to be created in the future if new user types are added to the system.

=== Test Coverage ===

There are three main types of tests that we created.

* Happy path tests of the controller's public methods. There is a test for every method. (ex: test_new)
* Sad path tests that passed invalid parameters. (ex: test_edit_questionnaire_with_lower_max_score_than_min)
* Sad path tests that tried to do things with insufficient access level. (ex: test_create_questionnaire_with_student)

We tried to cover as many types of useful cases as possible according to the project requirements. We used assertions that checked counts after create and delete, as well as asserted redirects. We also tested against invalid inputs that could cause errors. All of the tests are self-explanatory based on their method names, and there really is no need to further provide explanations here.

We also attempted to test the private methods of the controller as well at the beginning of the project. However, we couldn't find a way to test many of them due to the fact that they reference the params[] hash in the methods, and we can't isolate the testing of those methods without calling some controller action. Since these private methods are only used by the public controller action methods, we did the next best thing by creating tests for the action methods that would use these private methods to test them indirectly.

=== How to Run Controller Test ===

All of the QuestionnaireController tests are in the questionnaire_controller_test.rb file and can be run as a standard functional test. In Rubymine, this can be done by right clicking the test file and selecting "Run <filename>". Individual tests inside each test file can also be run by right clicking on the test method name and selecting "Run <method_name>". If the command line is preferred, the following command can be used:

ruby -Itest test/functional/questionnaire_controller_test.rb

== Questionnaire Subclass Unit Tests ==

The original assignment was to write unit tests for the Questionnaire subclasses:
* author_feedback_questionnaire.rb
* metareview_questionnaire.rb
* review_questionnaire.rb
* teammate_review_questionnaire.rb

As we reviewed the tests, it was found that most of the methods were trivial (ex: the method "symbol" only only returns a hardcoded symbol). The only method that was found to be worth testing was the get_weighted_score method. Upon further review, however, we found that testing this method in each of the four subclasses violated the DRY principle. Therefore, we moved the test to the superclass (questionnaire.rb) to test the "get_weighted_score" method.

=== Modifications to Existing Questionnaire Subclass Tests ===

There was only one test in the existing unit test for AuthorFeedbackQuestionnaire for testing the "get_weighted_score" method. Even though the test could be run, we found that it was not making assertions as it should. The files for the other 3 questionnaire subclasses were created to complete the testing on them. As stated earlier, we then found that testing the "get_weighted_score" method was redundant, violating the DRY principle, so it was moved to the superclass (Questionnaire). The tests in the subclasses were deleted (since they were redundant) but the test files were kept for future testing of the subclass if/when needed.

=== Test Coverage ===

The method "compute_weighted_score" from the the base class was the only thing that needed to be tested (due to the above reason). Based on an average, it was asserted that the value was not nil and that the value was computed correctly.

=== How to Run Unit Tests ===

The "compute_weighted_score" test can be found in the Questionnaire Unit Test file. Same as directions for the functional test, this can be run in either Rubymine or the command line. In Rubymine, this can be done by right clicking the test file and selecting "Run <filename>". Individual tests inside each test file can also be run by right clicking on the test method name and selecting "Run <method_name>". If the command line is preferred, the following command can be used:

ruby -Itest test/unit/questionnaire_test.rb

== General Information ==

=== Members ===
*Jonathan Wills - jrwills2
*Chun Sing Tsui - ctsui
*Travis Folsom - twfolsom

=== Highlights of Project ===
* Added unit test for questionnaire class
* Added functional tests for questionnaire controller
* 24 total tests
* The test that uses the "delete" action in the controller was failing due to a potential bug in the questionnaire.rb model class (refer to ''Potential Bug'' section)

=== List of files changed ===
*test/fixtures/assignment_questionnaires.yml
*test/fixtures/question_types.yml
*test/fixtures/questionnaires.yml
*test/fixtures/questions.yml
*test/functional/questionnaire_controller_test.rb
*test/unit/questionnaire_test.rb
*test/unit/author_feedback_questionnaire_test.rb
*test/unit/metareview_questionnaire_test.rb
*test/unit/review_questionnaire_test.rb
*test/unit/teammate_review_questionnaire_test.rb

= Potential Bug =
The Questionnaire model class contains a ''has_many :assignment_questionnaire'' that should be ''has_many :assignment_questionnaire'''s''' '' according to convention. Because of this, our "delete" action test fails since it doesn't match the convention. If it is indeed incorrect, then in the "compute_weighted_score" method, the ''self.assignemnt_questionnaire...'' call also needs to be changed to ''self.assignment_questionnaires...''. This most likely needs to be refactored, but we did not want to do a refactor without testing its effects on the system thoroughly.

CSC/ECE 517 Spring 2013/OSS E605B

2013-03-21T01:59:48Z

Ctsui: /* Potential Bug */

=Testing - questionnaire=
[https://docs.google.com/a/ncsu.edu/document/d/1SVNx7Eh6dUdrz2a9rGSgBxLkxAmuBUm8eu08nHEdjIg/edit# Project Description]

== QuestionnaireController Functional Tests ==

The majority of the tests implemented in this project are functional tests of the questionnaire controller. The test cases were written using the [http://api.rubyonrails.org/classes/ActionController/TestCase.html ActionController::TestCase] framework provided by Rails.

=== Modifications to Existing QuestionnaireController Test ===

There were a few tests already written for the Questionnaire controller, but they were not passing initially. We had to modify several things in the test and questionnaire fixture in order to get things up and running. The setup method contained login code that was outdated, and thus each test would result in a redirect due to the invalid login credential. So we looked through other more up to date functional test files and found the correct way to login as a particular user. We also put this code in a helper method so we can call it more easily in different tests if we so choose (more on this in the "Helper Methods" section).

In addition, we added new fixtures to help with our testing. Through debugging the test error messages, we saw that an additional required column called "section" has been added to the "Questionnaire" model, which was contributing to the failures. We added the additional column accordingly in our new fixures.

=== Helper Methods ===

There are two methods that assist in setting up and running the tests:

*The setup method
*The login_user method

The setup method assigns three special instance variables that are associated with the ActionController::TestCase (@controller, @request, and @response). In addition to setting these, the @Questionnaire variable is assigned to id of the :questionnaire5 fixture. This is the default questionnaire fixture that is used in a lot of the test cases. You will also notice that the fixture :admin is being logged in as the default user. This is done so that you don't have explicitly log into a user account for each test case. The only time you would need to call the method to log in for a particular test case is if you needed to test something specifically in another user type's account (for example a student account as is done in test_create_questionnaire_with_student.

def setup
@controller = QuestionnaireController.new
@request = ActionController::TestRequest.new
@response = ActionController::TestResponse.new
@Questionnaire = questionnaires(:questionnaire5).id
login_user(:admin)
end

The login_user method was created to "DRY out" the code associated with logging a user in. The method signature is:

def login_user(userType)

If you pass a symbol of the user type you would like to use for a test, it will log in as that user type for the particular test. The parameter name is userType and assumes that there is a fixture with the name of the user type. There seem to be sufficient fixtures for all of the different user types currently, but additional fixtures may need to be created in the future if new user types are added to the system.

=== Test Coverage ===

There are three main types of tests that we created.

* Happy path tests of the controller's public methods. There is a test for every method. (ex: test_new)
* Sad path tests that passed invalid parameters. (ex: test_edit_questionnaire_with_lower_max_score_than_min)
* Sad path tests that tried to do things with insufficient access level. (ex: test_create_questionnaire_with_student)

We tried to cover as many types of useful cases as possible according to the project requirements. We used assertions that checked counts after create and delete, as well as asserted redirects. We also tested against invalid inputs that could cause errors. All of the tests are self-explanatory based on their method names, and there really is no need to further provide explanations here.

We also attempted to test the private methods of the controller as well at the beginning of the project. However, we couldn't find a way to test many of them due to the fact that they reference the params[] hash in the methods, and we can't isolate the testing of those methods without calling some controller action. Since these private methods are only used by the public controller action methods, we did the next best thing by creating tests for the action methods that would use these private methods to test them indirectly.

=== How to Run Controller Test ===

All of the QuestionnaireController tests are in the questionnaire_controller_test.rb file and can be run as a standard functional test. In Rubymine, this can be done by right clicking the test file and selecting "Run <filename>". Individual tests inside each test file can also be run by right clicking on the test method name and selecting "Run <method_name>". If the command line is preferred, the following command can be used:

ruby -Itest test/functional/questionnaire_controller_test.rb

== Questionnaire Subclass Unit Tests ==

The original assignment was to write unit tests for the Questionnaire subclasses:
* author_feedback_questionnaire.rb
* metareview_questionnaire.rb
* review_questionnaire.rb
* teammate_review_questionnaire.rb

As we reviewed the tests, it was found that most of the methods were trivial (ex: the method "symbol" only only returns a hardcoded symbol). The only method that was found to be worth testing was the get_weighted_score method. Upon further review, however, we found that testing this method in each of the four subclasses violated the DRY principle. Therefore, we moved the test to the superclass (questionnaire.rb) to test the "get_weighted_score" method.

=== Modifications to Existing Questionnaire Subclass Tests ===

There was only one test in the existing unit test for AuthorFeedbackQuestionnaire for testing the "get_weighted_score" method. Even though the test could be run, we found that it was not making assertions as it should. The files for the other 3 questionnaire subclasses were created to complete the testing on them. As stated earlier, we then found that testing the "get_weighted_score" method was redundant, violating the DRY principle, so it was moved to the superclass (Questionnaire). The tests in the subclasses were deleted (since they were redundant) but the test files were kept for future testing of the subclass if/when needed.

=== Test Coverage ===

The method "compute_weighted_score" from the the base class was the only thing that needed to be tested (due to the above reason). Based on an average, it was asserted that the value was not nil and that the value was computed correctly.

=== How to Run Unit Tests ===

The "compute_weighted_score" test can be found in the Questionnaire Unit Test file. Same as directions for the functional test, this can be run in either Rubymine or the command line. In Rubymine, this can be done by right clicking the test file and selecting "Run <filename>". Individual tests inside each test file can also be run by right clicking on the test method name and selecting "Run <method_name>". If the command line is preferred, the following command can be used:

ruby -Itest test/unit/questionnaire_test.rb

== General Information ==

=== Members ===
*Jonathan Wills - jrwills2
*Chun Sing Tsui - ctsui
*Travis Folsom - twfolsom

=== Highlights of Project ===
* Added unit test for questionnaire class
* Added functional tests for questionnaire controller
* 24 total tests
* The test that uses the "delete" action in the controller was failing due to a potential bug in the questionnaire.rb model class

=== List of files changed ===
*test/fixtures/assignment_questionnaires.yml
*test/fixtures/question_types.yml
*test/fixtures/questionnaires.yml
*test/fixtures/questions.yml
*test/functional/questionnaire_controller_test.rb
*test/unit/questionnaire_test.rb
*test/unit/author_feedback_questionnaire_test.rb
*test/unit/metareview_questionnaire_test.rb
*test/unit/review_questionnaire_test.rb
*test/unit/teammate_review_questionnaire_test.rb

= Potential Bug =
The Questionnaire model class contains a ''has_many :assignment_questionnaire'' that should be ''has_many :assignment_questionnaire'''s''' '' according to convention. Because of this, our "delete" action test fails since it doesn't match the convention. If it is indeed incorrect, then in the "compute_weighted_score" method, the ''self.assignemnt_questionnaire...'' call also needs to be changed to ''self.assignment_questionnaires...''. This most likely needs to be refactored, but we did not want to do a refactor without testing its effects on the system thoroughly.

CSC/ECE 517 Spring 2013/OSS E605B

2013-03-21T01:50:56Z

Ctsui: /* NOTE */

=Testing - questionnaire=
[https://docs.google.com/a/ncsu.edu/document/d/1SVNx7Eh6dUdrz2a9rGSgBxLkxAmuBUm8eu08nHEdjIg/edit# Project Description]

== QuestionnaireController Functional Tests ==

The majority of the tests implemented in this project are functional tests of the questionnaire controller. The test cases were written using the [http://api.rubyonrails.org/classes/ActionController/TestCase.html ActionController::TestCase] framework provided by Rails.

=== Modifications to Existing QuestionnaireController Test ===

There were a few tests already written for the Questionnaire controller, but they were not passing initially. We had to modify several things in the test and questionnaire fixture in order to get things up and running. The setup method contained login code that was outdated, and thus each test would result in a redirect due to the invalid login credential. So we looked through other more up to date functional test files and found the correct way to login as a particular user. We also put this code in a helper method so we can call it more easily in different tests if we so choose (more on this in the "Helper Methods" section).

In addition, we added new fixtures to help with our testing. Through debugging the test error messages, we saw that an additional required column called "section" has been added to the "Questionnaire" model, which was contributing to the failures. We added the additional column accordingly in our new fixures.

=== Helper Methods ===

There are two methods that assist in setting up and running the tests:

*The setup method
*The login_user method

The setup method assigns three special instance variables that are associated with the ActionController::TestCase (@controller, @request, and @response). In addition to setting these, the @Questionnaire variable is assigned to id of the :questionnaire5 fixture. This is the default questionnaire fixture that is used in a lot of the test cases. You will also notice that the fixture :admin is being logged in as the default user. This is done so that you don't have explicitly log into a user account for each test case. The only time you would need to call the method to log in for a particular test case is if you needed to test something specifically in another user type's account (for example a student account as is done in test_create_questionnaire_with_student.

def setup
@controller = QuestionnaireController.new
@request = ActionController::TestRequest.new
@response = ActionController::TestResponse.new
@Questionnaire = questionnaires(:questionnaire5).id
login_user(:admin)
end

The login_user method was created to "DRY out" the code associated with logging a user in. The method signature is:

def login_user(userType)

If you pass a symbol of the user type you would like to use for a test, it will log in as that user type for the particular test. The parameter name is userType and assumes that there is a fixture with the name of the user type. There seem to be sufficient fixtures for all of the different user types currently, but additional fixtures may need to be created in the future if new user types are added to the system.

=== Test Coverage ===

There are three main types of tests that we created.

* Happy path tests of the controller's public methods. There is a test for every method. (ex: test_new)
* Sad path tests that passed invalid parameters. (ex: test_edit_questionnaire_with_lower_max_score_than_min)
* Sad path tests that tried to do things with insufficient access level. (ex: test_create_questionnaire_with_student)

We tried to cover as many types of useful cases as possible according to the project requirements. We used assertions that checked counts after create and delete, as well as asserted redirects. We also tested against invalid inputs that could cause errors. All of the tests are self-explanatory based on their method names, and there really is no need to further provide explanations here.

We also attempted to test the private methods of the controller as well at the beginning of the project. However, we couldn't find a way to test many of them due to the fact that they reference the params[] hash in the methods, and we can't isolate the testing of those methods without calling some controller action. Since these private methods are only used by the public controller action methods, we did the next best thing by creating tests for the action methods that would use these private methods to test them indirectly.

=== How to Run Controller Test ===

All of the QuestionnaireController tests are in the questionnaire_controller_test.rb file and can be run as a standard functional test. In Rubymine, this can be done by right clicking the test file and selecting "Run <filename>". Individual tests inside each test file can also be run by right clicking on the test method name and selecting "Run <method_name>". If the command line is preferred, the following command can be used:

ruby -Itest test/functional/questionnaire_controller_test.rb

== Questionnaire Subclass Unit Tests ==

The original assignment was to write unit tests for the Questionnaire subclasses:
* author_feedback_questionnaire.rb
* metareview_questionnaire.rb
* review_questionnaire.rb
* teammate_review_questionnaire.rb

As we reviewed the tests, it was found that most of the methods were trivial (ex: the method "symbol" only only returns a hardcoded symbol). The only method that was found to be worth testing was the get_weighted_score method. Upon further review, however, we found that testing this method in each of the four subclasses violated the DRY principle. Therefore, we moved the test to the superclass (questionnaire.rb) to test the "get_weighted_score" method.

=== Modifications to Existing Questionnaire Subclass Tests ===

There was only one test in the existing unit test for AuthorFeedbackQuestionnaire for testing the "get_weighted_score" method. Even though the test could be run, we found that it was not making assertions as it should. The files for the other 3 questionnaire subclasses were created to complete the testing on them. As stated earlier, we then found that testing the "get_weighted_score" method was redundant, violating the DRY principle, so it was moved to the superclass (Questionnaire). The tests in the subclasses were deleted (since they were redundant) but the test files were kept for future testing of the subclass if/when needed.

=== Test Coverage ===

The method "compute_weighted_score" from the the base class was the only thing that needed to be tested (due to the above reason). Based on an average, it was asserted that the value was not nil and that the value was computed correctly.

=== How to Run Unit Tests ===

The "compute_weighted_score" test can be found in the Questionnaire Unit Test file. Same as directions for the functional test, this can be run in either Rubymine or the command line. In Rubymine, this can be done by right clicking the test file and selecting "Run <filename>". Individual tests inside each test file can also be run by right clicking on the test method name and selecting "Run <method_name>". If the command line is preferred, the following command can be used:

ruby -Itest test/unit/questionnaire_test.rb

== General Information ==

=== Members ===
*Jonathan Wills - jrwills2
*Chun Sing Tsui - ctsui
*Travis Folsom - twfolsom

=== Highlights of Project ===
* Added unit test for questionnaire class
* Added functional tests for questionnaire controller
* 24 total tests
* The test that uses the "delete" action in the controller was failing due to a potential bug in the questionnaire.rb model class

=== List of files changed ===
*test/fixtures/assignment_questionnaires.yml
*test/fixtures/question_types.yml
*test/fixtures/questionnaires.yml
*test/fixtures/questions.yml
*test/functional/questionnaire_controller_test.rb
*test/unit/questionnaire_test.rb
*test/unit/author_feedback_questionnaire_test.rb
*test/unit/metareview_questionnaire_test.rb
*test/unit/review_questionnaire_test.rb
*test/unit/teammate_review_questionnaire_test.rb

= Potential Bug =
The Questionnaire model class contains a ''has_many :assignment_questionnaire'' that should be ''has_many :assignment_questionnaire'''s''' '' according to convention. If this is the case, then in the "compute_weighted_score" method, the ''self.assignemnt_questionnaire...'' call also needs to be changed to ''self.assignment_questionnaires...''. This most likely needs to be refactored, but we did not want to do a refactor without testing its effects on the system thoroughly.

CSC/ECE 517 Spring 2013/OSS E605B

2013-03-21T01:50:12Z

Ctsui: /* How to Run Unit Tests */

=Testing - questionnaire=
[https://docs.google.com/a/ncsu.edu/document/d/1SVNx7Eh6dUdrz2a9rGSgBxLkxAmuBUm8eu08nHEdjIg/edit# Project Description]

== QuestionnaireController Functional Tests ==

The majority of the tests implemented in this project are functional tests of the questionnaire controller. The test cases were written using the [http://api.rubyonrails.org/classes/ActionController/TestCase.html ActionController::TestCase] framework provided by Rails.

=== Modifications to Existing QuestionnaireController Test ===

There were a few tests already written for the Questionnaire controller, but they were not passing initially. We had to modify several things in the test and questionnaire fixture in order to get things up and running. The setup method contained login code that was outdated, and thus each test would result in a redirect due to the invalid login credential. So we looked through other more up to date functional test files and found the correct way to login as a particular user. We also put this code in a helper method so we can call it more easily in different tests if we so choose (more on this in the "Helper Methods" section).

In addition, we added new fixtures to help with our testing. Through debugging the test error messages, we saw that an additional required column called "section" has been added to the "Questionnaire" model, which was contributing to the failures. We added the additional column accordingly in our new fixures.

=== Helper Methods ===

There are two methods that assist in setting up and running the tests:

*The setup method
*The login_user method

The setup method assigns three special instance variables that are associated with the ActionController::TestCase (@controller, @request, and @response). In addition to setting these, the @Questionnaire variable is assigned to id of the :questionnaire5 fixture. This is the default questionnaire fixture that is used in a lot of the test cases. You will also notice that the fixture :admin is being logged in as the default user. This is done so that you don't have explicitly log into a user account for each test case. The only time you would need to call the method to log in for a particular test case is if you needed to test something specifically in another user type's account (for example a student account as is done in test_create_questionnaire_with_student.

def setup
@controller = QuestionnaireController.new
@request = ActionController::TestRequest.new
@response = ActionController::TestResponse.new
@Questionnaire = questionnaires(:questionnaire5).id
login_user(:admin)
end

The login_user method was created to "DRY out" the code associated with logging a user in. The method signature is:

def login_user(userType)

If you pass a symbol of the user type you would like to use for a test, it will log in as that user type for the particular test. The parameter name is userType and assumes that there is a fixture with the name of the user type. There seem to be sufficient fixtures for all of the different user types currently, but additional fixtures may need to be created in the future if new user types are added to the system.

=== Test Coverage ===

There are three main types of tests that we created.

* Happy path tests of the controller's public methods. There is a test for every method. (ex: test_new)
* Sad path tests that passed invalid parameters. (ex: test_edit_questionnaire_with_lower_max_score_than_min)
* Sad path tests that tried to do things with insufficient access level. (ex: test_create_questionnaire_with_student)

We tried to cover as many types of useful cases as possible according to the project requirements. We used assertions that checked counts after create and delete, as well as asserted redirects. We also tested against invalid inputs that could cause errors. All of the tests are self-explanatory based on their method names, and there really is no need to further provide explanations here.

We also attempted to test the private methods of the controller as well at the beginning of the project. However, we couldn't find a way to test many of them due to the fact that they reference the params[] hash in the methods, and we can't isolate the testing of those methods without calling some controller action. Since these private methods are only used by the public controller action methods, we did the next best thing by creating tests for the action methods that would use these private methods to test them indirectly.

=== How to Run Controller Test ===

All of the QuestionnaireController tests are in the questionnaire_controller_test.rb file and can be run as a standard functional test. In Rubymine, this can be done by right clicking the test file and selecting "Run <filename>". Individual tests inside each test file can also be run by right clicking on the test method name and selecting "Run <method_name>". If the command line is preferred, the following command can be used:

ruby -Itest test/functional/questionnaire_controller_test.rb

== Questionnaire Subclass Unit Tests ==

The original assignment was to write unit tests for the Questionnaire subclasses:
* author_feedback_questionnaire.rb
* metareview_questionnaire.rb
* review_questionnaire.rb
* teammate_review_questionnaire.rb

As we reviewed the tests, it was found that most of the methods were trivial (ex: the method "symbol" only only returns a hardcoded symbol). The only method that was found to be worth testing was the get_weighted_score method. Upon further review, however, we found that testing this method in each of the four subclasses violated the DRY principle. Therefore, we moved the test to the superclass (questionnaire.rb) to test the "get_weighted_score" method.

=== Modifications to Existing Questionnaire Subclass Tests ===

There was only one test in the existing unit test for AuthorFeedbackQuestionnaire for testing the "get_weighted_score" method. Even though the test could be run, we found that it was not making assertions as it should. The files for the other 3 questionnaire subclasses were created to complete the testing on them. As stated earlier, we then found that testing the "get_weighted_score" method was redundant, violating the DRY principle, so it was moved to the superclass (Questionnaire). The tests in the subclasses were deleted (since they were redundant) but the test files were kept for future testing of the subclass if/when needed.

=== Test Coverage ===

The method "compute_weighted_score" from the the base class was the only thing that needed to be tested (due to the above reason). Based on an average, it was asserted that the value was not nil and that the value was computed correctly.

=== How to Run Unit Tests ===

The "compute_weighted_score" test can be found in the Questionnaire Unit Test file. Same as directions for the functional test, this can be run in either Rubymine or the command line. In Rubymine, this can be done by right clicking the test file and selecting "Run <filename>". Individual tests inside each test file can also be run by right clicking on the test method name and selecting "Run <method_name>". If the command line is preferred, the following command can be used:

ruby -Itest test/unit/questionnaire_test.rb

== General Information ==

=== Members ===
*Jonathan Wills - jrwills2
*Chun Sing Tsui - ctsui
*Travis Folsom - twfolsom

=== Highlights of Project ===
* Added unit test for questionnaire class
* Added functional tests for questionnaire controller
* 24 total tests
* The test that uses the "delete" action in the controller was failing due to a potential bug in the questionnaire.rb model class

=== List of files changed ===
*test/fixtures/assignment_questionnaires.yml
*test/fixtures/question_types.yml
*test/fixtures/questionnaires.yml
*test/fixtures/questions.yml
*test/functional/questionnaire_controller_test.rb
*test/unit/questionnaire_test.rb
*test/unit/author_feedback_questionnaire_test.rb
*test/unit/metareview_questionnaire_test.rb
*test/unit/review_questionnaire_test.rb
*test/unit/teammate_review_questionnaire_test.rb

= NOTE =
The Questionnaire model class contains a ''has_many :assignment_questionnaire'' that should be ''has_many :assignment_questionnaire'''s''' '' according to convention. If this is the case, then in the "compute_weighted_score" method, the ''self.assignemnt_questionnaire...'' call also needs to be changed to ''self.assignment_questionnaires...''. This most likely needs to be refactored, but we did not want to do a refactor without testing its effects on the system thoroughly.

CSC/ECE 517 Spring 2013/OSS E605B

2013-03-21T01:48:31Z

Ctsui: /* How to Run Controller Test */

=Testing - questionnaire=
[https://docs.google.com/a/ncsu.edu/document/d/1SVNx7Eh6dUdrz2a9rGSgBxLkxAmuBUm8eu08nHEdjIg/edit# Project Description]

== QuestionnaireController Functional Tests ==

The majority of the tests implemented in this project are functional tests of the questionnaire controller. The test cases were written using the [http://api.rubyonrails.org/classes/ActionController/TestCase.html ActionController::TestCase] framework provided by Rails.

=== Modifications to Existing QuestionnaireController Test ===

There were a few tests already written for the Questionnaire controller, but they were not passing initially. We had to modify several things in the test and questionnaire fixture in order to get things up and running. The setup method contained login code that was outdated, and thus each test would result in a redirect due to the invalid login credential. So we looked through other more up to date functional test files and found the correct way to login as a particular user. We also put this code in a helper method so we can call it more easily in different tests if we so choose (more on this in the "Helper Methods" section).

In addition, we added new fixtures to help with our testing. Through debugging the test error messages, we saw that an additional required column called "section" has been added to the "Questionnaire" model, which was contributing to the failures. We added the additional column accordingly in our new fixures.

=== Helper Methods ===

There are two methods that assist in setting up and running the tests:

*The setup method
*The login_user method

The setup method assigns three special instance variables that are associated with the ActionController::TestCase (@controller, @request, and @response). In addition to setting these, the @Questionnaire variable is assigned to id of the :questionnaire5 fixture. This is the default questionnaire fixture that is used in a lot of the test cases. You will also notice that the fixture :admin is being logged in as the default user. This is done so that you don't have explicitly log into a user account for each test case. The only time you would need to call the method to log in for a particular test case is if you needed to test something specifically in another user type's account (for example a student account as is done in test_create_questionnaire_with_student.

def setup
@controller = QuestionnaireController.new
@request = ActionController::TestRequest.new
@response = ActionController::TestResponse.new
@Questionnaire = questionnaires(:questionnaire5).id
login_user(:admin)
end

The login_user method was created to "DRY out" the code associated with logging a user in. The method signature is:

def login_user(userType)

If you pass a symbol of the user type you would like to use for a test, it will log in as that user type for the particular test. The parameter name is userType and assumes that there is a fixture with the name of the user type. There seem to be sufficient fixtures for all of the different user types currently, but additional fixtures may need to be created in the future if new user types are added to the system.

=== Test Coverage ===

There are three main types of tests that we created.

* Happy path tests of the controller's public methods. There is a test for every method. (ex: test_new)
* Sad path tests that passed invalid parameters. (ex: test_edit_questionnaire_with_lower_max_score_than_min)
* Sad path tests that tried to do things with insufficient access level. (ex: test_create_questionnaire_with_student)

We tried to cover as many types of useful cases as possible according to the project requirements. We used assertions that checked counts after create and delete, as well as asserted redirects. We also tested against invalid inputs that could cause errors. All of the tests are self-explanatory based on their method names, and there really is no need to further provide explanations here.

We also attempted to test the private methods of the controller as well at the beginning of the project. However, we couldn't find a way to test many of them due to the fact that they reference the params[] hash in the methods, and we can't isolate the testing of those methods without calling some controller action. Since these private methods are only used by the public controller action methods, we did the next best thing by creating tests for the action methods that would use these private methods to test them indirectly.

=== How to Run Controller Test ===

All of the QuestionnaireController tests are in the questionnaire_controller_test.rb file and can be run as a standard functional test. In Rubymine, this can be done by right clicking the test file and selecting "Run <filename>". Individual tests inside each test file can also be run by right clicking on the test method name and selecting "Run <method_name>". If the command line is preferred, the following command can be used:

ruby -Itest test/functional/questionnaire_controller_test.rb

== Questionnaire Subclass Unit Tests ==

The original assignment was to write unit tests for the Questionnaire subclasses:
* author_feedback_questionnaire.rb
* metareview_questionnaire.rb
* review_questionnaire.rb
* teammate_review_questionnaire.rb

As we reviewed the tests, it was found that most of the methods were trivial (ex: the method "symbol" only only returns a hardcoded symbol). The only method that was found to be worth testing was the get_weighted_score method. Upon further review, however, we found that testing this method in each of the four subclasses violated the DRY principle. Therefore, we moved the test to the superclass (questionnaire.rb) to test the "get_weighted_score" method.

=== Modifications to Existing Questionnaire Subclass Tests ===

There was only one test in the existing unit test for AuthorFeedbackQuestionnaire for testing the "get_weighted_score" method. Even though the test could be run, we found that it was not making assertions as it should. The files for the other 3 questionnaire subclasses were created to complete the testing on them. As stated earlier, we then found that testing the "get_weighted_score" method was redundant, violating the DRY principle, so it was moved to the superclass (Questionnaire). The tests in the subclasses were deleted (since they were redundant) but the test files were kept for future testing of the subclass if/when needed.

=== Test Coverage ===

The method "compute_weighted_score" from the the base class was the only thing that needed to be tested (due to the above reason). Based on an average, it was asserted that the value was not nil and that the value was computed correctly.

=== How to Run Unit Tests ===

The "compute_weighted_score" test can be found in the Questionnaire Unit Test file.

== General Information ==

=== Members ===
*Jonathan Wills - jrwills2
*Chun Sing Tsui - ctsui
*Travis Folsom - twfolsom

=== Highlights of Project ===
* Added unit test for questionnaire class
* Added functional tests for questionnaire controller
* 24 total tests
* The test that uses the "delete" action in the controller was failing due to a potential bug in the questionnaire.rb model class

=== List of files changed ===
*test/fixtures/assignment_questionnaires.yml
*test/fixtures/question_types.yml
*test/fixtures/questionnaires.yml
*test/fixtures/questions.yml
*test/functional/questionnaire_controller_test.rb
*test/unit/questionnaire_test.rb
*test/unit/author_feedback_questionnaire_test.rb
*test/unit/metareview_questionnaire_test.rb
*test/unit/review_questionnaire_test.rb
*test/unit/teammate_review_questionnaire_test.rb

= NOTE =
The Questionnaire model class contains a ''has_many :assignment_questionnaire'' that should be ''has_many :assignment_questionnaire'''s''' '' according to convention. If this is the case, then in the "compute_weighted_score" method, the ''self.assignemnt_questionnaire...'' call also needs to be changed to ''self.assignment_questionnaires...''. This most likely needs to be refactored, but we did not want to do a refactor without testing its effects on the system thoroughly.

CSC/ECE 517 Spring 2013/OSS E605B

2013-03-21T01:41:14Z

Ctsui: /* Test Coverage */

=Testing - questionnaire=
[https://docs.google.com/a/ncsu.edu/document/d/1SVNx7Eh6dUdrz2a9rGSgBxLkxAmuBUm8eu08nHEdjIg/edit# Project Description]

== QuestionnaireController Functional Tests ==

The majority of the tests implemented in this project are functional tests of the questionnaire controller. The test cases were written using the [http://api.rubyonrails.org/classes/ActionController/TestCase.html ActionController::TestCase] framework provided by Rails.

=== Modifications to Existing QuestionnaireController Test ===

There were a few tests already written for the Questionnaire controller, but they were not passing initially. We had to modify several things in the test and questionnaire fixture in order to get things up and running. The setup method contained login code that was outdated, and thus each test would result in a redirect due to the invalid login credential. So we looked through other more up to date functional test files and found the correct way to login as a particular user. We also put this code in a helper method so we can call it more easily in different tests if we so choose (more on this in the "Helper Methods" section).

In addition, we added new fixtures to help with our testing. Through debugging the test error messages, we saw that an additional required column called "section" has been added to the "Questionnaire" model, which was contributing to the failures. We added the additional column accordingly in our new fixures.

=== Helper Methods ===

There are two methods that assist in setting up and running the tests:

*The setup method
*The login_user method

The setup method assigns three special instance variables that are associated with the ActionController::TestCase (@controller, @request, and @response). In addition to setting these, the @Questionnaire variable is assigned to id of the :questionnaire5 fixture. This is the default questionnaire fixture that is used in a lot of the test cases. You will also notice that the fixture :admin is being logged in as the default user. This is done so that you don't have explicitly log into a user account for each test case. The only time you would need to call the method to log in for a particular test case is if you needed to test something specifically in another user type's account (for example a student account as is done in test_create_questionnaire_with_student.

def setup
@controller = QuestionnaireController.new
@request = ActionController::TestRequest.new
@response = ActionController::TestResponse.new
@Questionnaire = questionnaires(:questionnaire5).id
login_user(:admin)
end

The login_user method was created to "DRY out" the code associated with logging a user in. The method signature is:

def login_user(userType)

If you pass a symbol of the user type you would like to use for a test, it will log in as that user type for the particular test. The parameter name is userType and assumes that there is a fixture with the name of the user type. There seem to be sufficient fixtures for all of the different user types currently, but additional fixtures may need to be created in the future if new user types are added to the system.

=== Test Coverage ===

There are three main types of tests that we created.

* Happy path tests of the controller's public methods. There is a test for every method. (ex: test_new)
* Sad path tests that passed invalid parameters. (ex: test_edit_questionnaire_with_lower_max_score_than_min)
* Sad path tests that tried to do things with insufficient access level. (ex: test_create_questionnaire_with_student)

We tried to cover as many types of useful cases as possible according to the project requirements. We used assertions that checked counts after create and delete, as well as asserted redirects. We also tested against invalid inputs that could cause errors. All of the tests are self-explanatory based on their method names, and there really is no need to further provide explanations here.

We also attempted to test the private methods of the controller as well at the beginning of the project. However, we couldn't find a way to test many of them due to the fact that they reference the params[] hash in the methods, and we can't isolate the testing of those methods without calling some controller action. Since these private methods are only used by the public controller action methods, we did the next best thing by creating tests for the action methods that would use these private methods to test them indirectly.

=== How to Run Controller Test ===

All of the QuestionnaireController tests are in the questionnaire_controller_test.rb file and can be run as a standard functional test.

== Questionnaire Subclass Unit Tests ==

The original assignment was to write unit tests for the Questionnaire subclasses:
* author_feedback_questionnaire.rb
* metareview_questionnaire.rb
* review_questionnaire.rb
* teammate_review_questionnaire.rb

As we reviewed the tests, it was found that most of the methods were trivial (ex: the method "symbol" only only returns a hardcoded symbol). The only method that was found to be worth testing was the get_weighted_score method. Upon further review, however, we found that testing this method in each of the four subclasses violated the DRY principle. Therefore, we moved the test to the superclass (questionnaire.rb) to test the "get_weighted_score" method.

=== Modifications to Existing Questionnaire Subclass Tests ===

There was only one test in the existing unit test for AuthorFeedbackQuestionnaire for testing the "get_weighted_score" method. Even though the test could be run, we found that it was not making assertions as it should. The files for the other 3 questionnaire subclasses were created to complete the testing on them. As stated earlier, we then found that testing the "get_weighted_score" method was redundant, violating the DRY principle, so it was moved to the superclass (Questionnaire). The tests in the subclasses were deleted (since they were redundant) but the test files were kept for future testing of the subclass if/when needed.

=== Test Coverage ===

The method "compute_weighted_score" from the the base class was the only thing that needed to be tested (due to the above reason). Based on an average, it was asserted that the value was not nil and that the value was computed correctly.

=== How to Run Unit Tests ===

The "compute_weighted_score" test can be found in the Questionnaire Unit Test file.

== General Information ==

=== Members ===
*Jonathan Wills - jrwills2
*Chun Sing Tsui - ctsui
*Travis Folsom - twfolsom

=== Highlights of Project ===
* Added unit test for questionnaire class
* Added functional tests for questionnaire controller
* 24 total tests
* The test that uses the "delete" action in the controller was failing due to a potential bug in the questionnaire.rb model class

=== List of files changed ===
*test/fixtures/assignment_questionnaires.yml
*test/fixtures/question_types.yml
*test/fixtures/questionnaires.yml
*test/fixtures/questions.yml
*test/functional/questionnaire_controller_test.rb
*test/unit/questionnaire_test.rb
*test/unit/author_feedback_questionnaire_test.rb
*test/unit/metareview_questionnaire_test.rb
*test/unit/review_questionnaire_test.rb
*test/unit/teammate_review_questionnaire_test.rb

= NOTE =
The Questionnaire model class contains a ''has_many :assignment_questionnaire'' that should be ''has_many :assignment_questionnaire'''s''' '' according to convention. If this is the case, then in the "compute_weighted_score" method, the ''self.assignemnt_questionnaire...'' call also needs to be changed to ''self.assignment_questionnaires...''. This most likely needs to be refactored, but we did not want to do a refactor without testing its effects on the system thoroughly.

CSC/ECE 517 Spring 2013/OSS E605B

2013-03-21T01:32:29Z

Ctsui: /* Modifications to Existing QuestionnaireController Test */

=Testing - questionnaire=
[https://docs.google.com/a/ncsu.edu/document/d/1SVNx7Eh6dUdrz2a9rGSgBxLkxAmuBUm8eu08nHEdjIg/edit# Project Description]

== QuestionnaireController Functional Tests ==

The majority of the tests implemented in this project are functional tests of the questionnaire controller. The test cases were written using the [http://api.rubyonrails.org/classes/ActionController/TestCase.html ActionController::TestCase] framework provided by Rails.

=== Modifications to Existing QuestionnaireController Test ===

There were a few tests already written for the Questionnaire controller, but they were not passing initially. We had to modify several things in the test and questionnaire fixture in order to get things up and running. The setup method contained login code that was outdated, and thus each test would result in a redirect due to the invalid login credential. So we looked through other more up to date functional test files and found the correct way to login as a particular user. We also put this code in a helper method so we can call it more easily in different tests if we so choose (more on this in the "Helper Methods" section).

In addition, we added new fixtures to help with our testing. Through debugging the test error messages, we saw that an additional required column called "section" has been added to the "Questionnaire" model, which was contributing to the failures. We added the additional column accordingly in our new fixures.

=== Helper Methods ===

There are two methods that assist in setting up and running the tests:

*The setup method
*The login_user method

The setup method assigns three special instance variables that are associated with the ActionController::TestCase (@controller, @request, and @response). In addition to setting these, the @Questionnaire variable is assigned to id of the :questionnaire5 fixture. This is the default questionnaire fixture that is used in a lot of the test cases. You will also notice that the fixture :admin is being logged in as the default user. This is done so that you don't have explicitly log into a user account for each test case. The only time you would need to call the method to log in for a particular test case is if you needed to test something specifically in another user type's account (for example a student account as is done in test_create_questionnaire_with_student.

def setup
@controller = QuestionnaireController.new
@request = ActionController::TestRequest.new
@response = ActionController::TestResponse.new
@Questionnaire = questionnaires(:questionnaire5).id
login_user(:admin)
end

The login_user method was created to "DRY out" the code associated with logging a user in. The method signature is:

def login_user(userType)

If you pass a symbol of the user type you would like to use for a test, it will log in as that user type for the particular test. The parameter name is userType and assumes that there is a fixture with the name of the user type. There seem to be sufficient fixtures for all of the different user types currently, but additional fixtures may need to be created in the future if new user types are added to the system.

=== Test Coverage ===

There are three main types of tests that we created.

* Happy path tests of the controller's public methods. There is a test for every method. (ex: test_new)
* Sad path tests that passed invalid parameters. (ex: test_edit_questionnaire_with_lower_max_score_than_min)
* Sad path tests that tried to do things with insufficient access level. (ex: test_create_questionnaire_with_student)

=== How to Run Controller Test ===

All of the QuestionnaireController tests are in the questionnaire_controller_test.rb file and can be run as a standard functional test.

== Questionnaire Subclass Unit Tests ==

The original assignment was to write unit tests for the Questionnaire subclasses:
* author_feedback_questionnaire.rb
* metareview_questionnaire.rb
* review_questionnaire.rb
* teammate_review_questionnaire.rb

As we reviewed the tests, it was found that most of the methods were trivial (ex: the method "symbol" only only returns a hardcoded symbol). The only method that was found to be worth testing was the get_weighted_score method. Upon further review, however, we found that testing this method in each of the four subclasses violated the DRY principle. Therefore, we moved the test to the superclass (questionnaire.rb) to test the "get_weighted_score" method.

=== Modifications to Existing Questionnaire Subclass Tests ===

There was only one test in the existing unit test for AuthorFeedbackQuestionnaire for testing the "get_weighted_score" method. Even though the test could be run, we found that it was not making assertions as it should. The files for the other 3 questionnaire subclasses were created to complete the testing on them. As stated earlier, we then found that testing the "get_weighted_score" method was redundant, violating the DRY principle, so it was moved to the superclass (Questionnaire). The tests in the subclasses were deleted (since they were redundant) but the test files were kept for future testing of the subclass if/when needed.

=== Test Coverage ===

The method "compute_weighted_score" from the the base class was the only thing that needed to be tested (due to the above reason). Based on an average, it was asserted that the value was not nil and that the value was computed correctly.

=== How to Run Unit Tests ===

The "compute_weighted_score" test can be found in the Questionnaire Unit Test file.

== General Information ==

=== Members ===
*Jonathan Wills - jrwills2
*Chun Sing Tsui - ctsui
*Travis Folsom - twfolsom

=== Highlights of Project ===
* Added unit test for questionnaire class
* Added functional tests for questionnaire controller
* 24 total tests
* The test that uses the "delete" action in the controller was failing due to a potential bug in the questionnaire.rb model class

=== List of files changed ===
*test/fixtures/assignment_questionnaires.yml
*test/fixtures/question_types.yml
*test/fixtures/questionnaires.yml
*test/fixtures/questions.yml
*test/functional/questionnaire_controller_test.rb
*test/unit/questionnaire_test.rb
*test/unit/author_feedback_questionnaire_test.rb
*test/unit/metareview_questionnaire_test.rb
*test/unit/review_questionnaire_test.rb
*test/unit/teammate_review_questionnaire_test.rb

= NOTE =
The Questionnaire model class contains a ''has_many :assignment_questionnaire'' that should be ''has_many :assignment_questionnaire'''s''' '' according to convention. If this is the case, then in the "compute_weighted_score" method, the ''self.assignemnt_questionnaire...'' call also needs to be changed to ''self.assignment_questionnaires...''. This most likely needs to be refactored, but we did not want to do a refactor without testing its effects on the system thoroughly.

CSC/ECE 517 Spring 2013/OSS E605B

2013-03-21T01:31:14Z

Ctsui: /* Testing - questionnaire */

=Testing - questionnaire=
[https://docs.google.com/a/ncsu.edu/document/d/1SVNx7Eh6dUdrz2a9rGSgBxLkxAmuBUm8eu08nHEdjIg/edit# Project Description]

== QuestionnaireController Functional Tests ==

The majority of the tests implemented in this project are functional tests of the questionnaire controller. The test cases were written using the [http://api.rubyonrails.org/classes/ActionController/TestCase.html ActionController::TestCase] framework provided by Rails.

=== Modifications to Existing QuestionnaireController Test ===

There were a few tests already written for the Questionnaire controller, but they were not passing initially. We had to modify several things in the test and questionnaire fixture in order to get things up and running. The setup method contained login code that was outdated, and thus each test would result in a redirect due to the invalid login credential. So we looked through other more up to date functional test files and found the correct way to login as a particular user. We also put this code in a helper method so we can call it more easily in different tests if we so choose (more on this in the "Helper Methods" section).

In addition, we added a new questionnaire fixture (:questionnaire5) to help with our testing. Through debugging the test error messages, we saw that an additional required column called "section" has been added to the "Questionnaire" model, which was contributing to the failures. We added the additional column accordingly in :questionnaire5.

=== Helper Methods ===

There are two methods that assist in setting up and running the tests:

*The setup method
*The login_user method

The setup method assigns three special instance variables that are associated with the ActionController::TestCase (@controller, @request, and @response). In addition to setting these, the @Questionnaire variable is assigned to id of the :questionnaire5 fixture. This is the default questionnaire fixture that is used in a lot of the test cases. You will also notice that the fixture :admin is being logged in as the default user. This is done so that you don't have explicitly log into a user account for each test case. The only time you would need to call the method to log in for a particular test case is if you needed to test something specifically in another user type's account (for example a student account as is done in test_create_questionnaire_with_student.

def setup
@controller = QuestionnaireController.new
@request = ActionController::TestRequest.new
@response = ActionController::TestResponse.new
@Questionnaire = questionnaires(:questionnaire5).id
login_user(:admin)
end

The login_user method was created to "DRY out" the code associated with logging a user in. The method signature is:

def login_user(userType)

If you pass a symbol of the user type you would like to use for a test, it will log in as that user type for the particular test. The parameter name is userType and assumes that there is a fixture with the name of the user type. There seem to be sufficient fixtures for all of the different user types currently, but additional fixtures may need to be created in the future if new user types are added to the system.

=== Test Coverage ===

There are three main types of tests that we created.

* Happy path tests of the controller's public methods. There is a test for every method. (ex: test_new)
* Sad path tests that passed invalid parameters. (ex: test_edit_questionnaire_with_lower_max_score_than_min)
* Sad path tests that tried to do things with insufficient access level. (ex: test_create_questionnaire_with_student)

=== How to Run Controller Test ===

All of the QuestionnaireController tests are in the questionnaire_controller_test.rb file and can be run as a standard functional test.

== Questionnaire Subclass Unit Tests ==

The original assignment was to write unit tests for the Questionnaire subclasses:
* author_feedback_questionnaire.rb
* metareview_questionnaire.rb
* review_questionnaire.rb
* teammate_review_questionnaire.rb

As we reviewed the tests, it was found that most of the methods were trivial (ex: the method "symbol" only only returns a hardcoded symbol). The only method that was found to be worth testing was the get_weighted_score method. Upon further review, however, we found that testing this method in each of the four subclasses violated the DRY principle. Therefore, we moved the test to the superclass (questionnaire.rb) to test the "get_weighted_score" method.

=== Modifications to Existing Questionnaire Subclass Tests ===

There was only one test in the existing unit test for AuthorFeedbackQuestionnaire for testing the "get_weighted_score" method. Even though the test could be run, we found that it was not making assertions as it should. The files for the other 3 questionnaire subclasses were created to complete the testing on them. As stated earlier, we then found that testing the "get_weighted_score" method was redundant, violating the DRY principle, so it was moved to the superclass (Questionnaire). The tests in the subclasses were deleted (since they were redundant) but the test files were kept for future testing of the subclass if/when needed.

=== Test Coverage ===

The method "compute_weighted_score" from the the base class was the only thing that needed to be tested (due to the above reason). Based on an average, it was asserted that the value was not nil and that the value was computed correctly.

=== How to Run Unit Tests ===

The "compute_weighted_score" test can be found in the Questionnaire Unit Test file.

== General Information ==

=== Members ===
*Jonathan Wills - jrwills2
*Chun Sing Tsui - ctsui
*Travis Folsom - twfolsom

=== Highlights of Project ===
* Added unit test for questionnaire class
* Added functional tests for questionnaire controller
* 24 total tests
* The test that uses the "delete" action in the controller was failing due to a potential bug in the questionnaire.rb model class

=== List of files changed ===
*test/fixtures/assignment_questionnaires.yml
*test/fixtures/question_types.yml
*test/fixtures/questionnaires.yml
*test/fixtures/questions.yml
*test/functional/questionnaire_controller_test.rb
*test/unit/questionnaire_test.rb
*test/unit/author_feedback_questionnaire_test.rb
*test/unit/metareview_questionnaire_test.rb
*test/unit/review_questionnaire_test.rb
*test/unit/teammate_review_questionnaire_test.rb

= NOTE =
The Questionnaire model class contains a ''has_many :assignment_questionnaire'' that should be ''has_many :assignment_questionnaire'''s''' '' according to convention. If this is the case, then in the "compute_weighted_score" method, the ''self.assignemnt_questionnaire...'' call also needs to be changed to ''self.assignment_questionnaires...''. This most likely needs to be refactored, but we did not want to do a refactor without testing its effects on the system thoroughly.

CSC/ECE 517 Spring 2013/OSS E605B

2013-03-21T01:25:52Z

Ctsui: /* Highlights of Project */

=Testing - questionnaire=

== QuestionnaireController Functional Tests ==

The majority of the tests implemented in this project are functional tests of the questionnaire controller. The test cases were written using the [http://api.rubyonrails.org/classes/ActionController/TestCase.html ActionController::TestCase] framework provided by Rails.

=== Modifications to Existing QuestionnaireController Test ===

There were a few tests already written for the Questionnaire controller, but they were not passing initially. We had to modify several things in the test and questionnaire fixture in order to get things up and running. The setup method contained login code that was outdated, and thus each test would result in a redirect due to the invalid login credential. So we looked through other more up to date functional test files and found the correct way to login as a particular user. We also put this code in a helper method so we can call it more easily in different tests if we so choose (more on this in the "Helper Methods" section).

In addition, we added a new questionnaire fixture (:questionnaire5) to help with our testing. Through debugging the test error messages, we saw that an additional required column called "section" has been added to the "Questionnaire" model, which was contributing to the failures. We added the additional column accordingly in :questionnaire5.

=== Helper Methods ===

There are two methods that assist in setting up and running the tests:

*The setup method
*The login_user method

The setup method assigns three special instance variables that are associated with the ActionController::TestCase (@controller, @request, and @response). In addition to setting these, the @Questionnaire variable is assigned to id of the :questionnaire5 fixture. This is the default questionnaire fixture that is used in a lot of the test cases. You will also notice that the fixture :admin is being logged in as the default user. This is done so that you don't have explicitly log into a user account for each test case. The only time you would need to call the method to log in for a particular test case is if you needed to test something specifically in another user type's account (for example a student account as is done in test_create_questionnaire_with_student.

def setup
@controller = QuestionnaireController.new
@request = ActionController::TestRequest.new
@response = ActionController::TestResponse.new
@Questionnaire = questionnaires(:questionnaire5).id
login_user(:admin)
end

The login_user method was created to "DRY out" the code associated with logging a user in. The method signature is:

def login_user(userType)

If you pass a symbol of the user type you would like to use for a test, it will log in as that user type for the particular test. The parameter name is userType and assumes that there is a fixture with the name of the user type. There seem to be sufficient fixtures for all of the different user types currently, but additional fixtures may need to be created in the future if new user types are added to the system.

=== Test Coverage ===

There are three main types of tests that we created.

* Happy path tests of the controller's public methods. There is a test for every method. (ex: test_new)
* Sad path tests that passed invalid parameters. (ex: test_edit_questionnaire_with_lower_max_score_than_min)
* Sad path tests that tried to do things with insufficient access level. (ex: test_create_questionnaire_with_student)

=== How to Run Controller Test ===

All of the QuestionnaireController tests are in the questionnaire_controller_test.rb file and can be run as a standard functional test.

== Questionnaire Subclass Unit Tests ==

The original assignment was to write unit tests for the Questionnaire subclasses:
* author_feedback_questionnaire.rb
* metareview_questionnaire.rb
* review_questionnaire.rb
* teammate_review_questionnaire.rb

As we reviewed the tests, it was found that most of the methods were trivial (ex: the method "symbol" only only returns a hardcoded symbol). The only method that was found to be worth testing was the get_weighted_score method. Upon further review, however, we found that testing this method in each of the four subclasses violated the DRY principle. Therefore, we moved the test to the superclass (questionnaire.rb) to test the "get_weighted_score" method.

=== Modifications to Existing Questionnaire Subclass Tests ===

There was only one test in the existing unit test for AuthorFeedbackQuestionnaire for testing the "get_weighted_score" method. Even though the test could be run, we found that it was not making assertions as it should. The files for the other 3 questionnaire subclasses were created to complete the testing on them. As stated earlier, we then found that testing the "get_weighted_score" method was redundant, violating the DRY principle, so it was moved to the superclass (Questionnaire). The tests in the subclasses were deleted (since they were redundant) but the test files were kept for future testing of the subclass if/when needed.

=== Test Coverage ===

The method "compute_weighted_score" from the the base class was the only thing that needed to be tested (due to the above reason). Based on an average, it was asserted that the value was not nil and that the value was computed correctly.

=== How to Run Unit Tests ===

The "compute_weighted_score" test can be found in the Questionnaire Unit Test file.

== General Information ==

=== Members ===
*Jonathan Wills - jrwills2
*Chun Sing Tsui - ctsui
*Travis Folsom - twfolsom

=== Highlights of Project ===
* Added unit test for questionnaire class
* Added functional tests for questionnaire controller
* 24 total tests
* The test that uses the "delete" action in the controller was failing due to a potential bug in the questionnaire.rb model class

=== List of files changed ===
*test/fixtures/assignment_questionnaires.yml
*test/fixtures/question_types.yml
*test/fixtures/questionnaires.yml
*test/fixtures/questions.yml
*test/functional/questionnaire_controller_test.rb
*test/unit/questionnaire_test.rb
*test/unit/author_feedback_questionnaire_test.rb
*test/unit/metareview_questionnaire_test.rb
*test/unit/review_questionnaire_test.rb
*test/unit/teammate_review_questionnaire_test.rb

= NOTE =
The Questionnaire model class contains a ''has_many :assignment_questionnaire'' that should be ''has_many :assignment_questionnaire'''s''' '' according to convention. If this is the case, then in the "compute_weighted_score" method, the ''self.assignemnt_questionnaire...'' call also needs to be changed to ''self.assignment_questionnaires...''. This most likely needs to be refactored, but we did not want to do a refactor without testing its effects on the system thoroughly.

CSC/ECE 517 Spring 2013/OSS E605B

2013-03-21T01:24:17Z

Ctsui: /* Questionnaire Subclass Unit Tests */

=Testing - questionnaire=

== QuestionnaireController Functional Tests ==

The majority of the tests implemented in this project are functional tests of the questionnaire controller. The test cases were written using the [http://api.rubyonrails.org/classes/ActionController/TestCase.html ActionController::TestCase] framework provided by Rails.

=== Modifications to Existing QuestionnaireController Test ===

There were a few tests already written for the Questionnaire controller, but they were not passing initially. We had to modify several things in the test and questionnaire fixture in order to get things up and running. The setup method contained login code that was outdated, and thus each test would result in a redirect due to the invalid login credential. So we looked through other more up to date functional test files and found the correct way to login as a particular user. We also put this code in a helper method so we can call it more easily in different tests if we so choose (more on this in the "Helper Methods" section).

In addition, we added a new questionnaire fixture (:questionnaire5) to help with our testing. Through debugging the test error messages, we saw that an additional required column called "section" has been added to the "Questionnaire" model, which was contributing to the failures. We added the additional column accordingly in :questionnaire5.

=== Helper Methods ===

There are two methods that assist in setting up and running the tests:

*The setup method
*The login_user method

The setup method assigns three special instance variables that are associated with the ActionController::TestCase (@controller, @request, and @response). In addition to setting these, the @Questionnaire variable is assigned to id of the :questionnaire5 fixture. This is the default questionnaire fixture that is used in a lot of the test cases. You will also notice that the fixture :admin is being logged in as the default user. This is done so that you don't have explicitly log into a user account for each test case. The only time you would need to call the method to log in for a particular test case is if you needed to test something specifically in another user type's account (for example a student account as is done in test_create_questionnaire_with_student.

def setup
@controller = QuestionnaireController.new
@request = ActionController::TestRequest.new
@response = ActionController::TestResponse.new
@Questionnaire = questionnaires(:questionnaire5).id
login_user(:admin)
end

The login_user method was created to "DRY out" the code associated with logging a user in. The method signature is:

def login_user(userType)

If you pass a symbol of the user type you would like to use for a test, it will log in as that user type for the particular test. The parameter name is userType and assumes that there is a fixture with the name of the user type. There seem to be sufficient fixtures for all of the different user types currently, but additional fixtures may need to be created in the future if new user types are added to the system.

=== Test Coverage ===

There are three main types of tests that we created.

* Happy path tests of the controller's public methods. There is a test for every method. (ex: test_new)
* Sad path tests that passed invalid parameters. (ex: test_edit_questionnaire_with_lower_max_score_than_min)
* Sad path tests that tried to do things with insufficient access level. (ex: test_create_questionnaire_with_student)

=== How to Run Controller Test ===

All of the QuestionnaireController tests are in the questionnaire_controller_test.rb file and can be run as a standard functional test.

== Questionnaire Subclass Unit Tests ==

The original assignment was to write unit tests for the Questionnaire subclasses:
* author_feedback_questionnaire.rb
* metareview_questionnaire.rb
* review_questionnaire.rb
* teammate_review_questionnaire.rb

As we reviewed the tests, it was found that most of the methods were trivial (ex: the method "symbol" only only returns a hardcoded symbol). The only method that was found to be worth testing was the get_weighted_score method. Upon further review, however, we found that testing this method in each of the four subclasses violated the DRY principle. Therefore, we moved the test to the superclass (questionnaire.rb) to test the "get_weighted_score" method.

=== Modifications to Existing Questionnaire Subclass Tests ===

There was only one test in the existing unit test for AuthorFeedbackQuestionnaire for testing the "get_weighted_score" method. Even though the test could be run, we found that it was not making assertions as it should. The files for the other 3 questionnaire subclasses were created to complete the testing on them. As stated earlier, we then found that testing the "get_weighted_score" method was redundant, violating the DRY principle, so it was moved to the superclass (Questionnaire). The tests in the subclasses were deleted (since they were redundant) but the test files were kept for future testing of the subclass if/when needed.

=== Test Coverage ===

The method "compute_weighted_score" from the the base class was the only thing that needed to be tested (due to the above reason). Based on an average, it was asserted that the value was not nil and that the value was computed correctly.

=== How to Run Unit Tests ===

The "compute_weighted_score" test can be found in the Questionnaire Unit Test file.

== General Information ==

=== Members ===
*Jonathan Wills - jrwills2
*Chun Sing Tsui - ctsui
*Travis Folsom - twfolsom

=== Highlights of Project ===
* Added unit test for questionnaire class
* Added functional tests for questionnaire controller
* 24 total tests
* Delete test in functional testing was failing due to a potential bug in the questionnaire controller

=== List of files changed ===
*test/fixtures/assignment_questionnaires.yml
*test/fixtures/question_types.yml
*test/fixtures/questionnaires.yml
*test/fixtures/questions.yml
*test/functional/questionnaire_controller_test.rb
*test/unit/questionnaire_test.rb
*test/unit/author_feedback_questionnaire_test.rb
*test/unit/metareview_questionnaire_test.rb
*test/unit/review_questionnaire_test.rb
*test/unit/teammate_review_questionnaire_test.rb

= NOTE =
The Questionnaire model class contains a ''has_many :assignment_questionnaire'' that should be ''has_many :assignment_questionnaire'''s''' '' according to convention. If this is the case, then in the "compute_weighted_score" method, the ''self.assignemnt_questionnaire...'' call also needs to be changed to ''self.assignment_questionnaires...''. This most likely needs to be refactored, but we did not want to do a refactor without testing its effects on the system thoroughly.

CSC/ECE 517 Spring 2013/OSS E605B

2013-03-21T01:22:38Z

Ctsui: /* Test Coverage */

=Testing - questionnaire=

== QuestionnaireController Functional Tests ==

The majority of the tests implemented in this project are functional tests of the questionnaire controller. The test cases were written using the [http://api.rubyonrails.org/classes/ActionController/TestCase.html ActionController::TestCase] framework provided by Rails.

=== Modifications to Existing QuestionnaireController Test ===

There were a few tests already written for the Questionnaire controller, but they were not passing initially. We had to modify several things in the test and questionnaire fixture in order to get things up and running. The setup method contained login code that was outdated, and thus each test would result in a redirect due to the invalid login credential. So we looked through other more up to date functional test files and found the correct way to login as a particular user. We also put this code in a helper method so we can call it more easily in different tests if we so choose (more on this in the "Helper Methods" section).

In addition, we added a new questionnaire fixture (:questionnaire5) to help with our testing. Through debugging the test error messages, we saw that an additional required column called "section" has been added to the "Questionnaire" model, which was contributing to the failures. We added the additional column accordingly in :questionnaire5.

=== Helper Methods ===

There are two methods that assist in setting up and running the tests:

*The setup method
*The login_user method

The setup method assigns three special instance variables that are associated with the ActionController::TestCase (@controller, @request, and @response). In addition to setting these, the @Questionnaire variable is assigned to id of the :questionnaire5 fixture. This is the default questionnaire fixture that is used in a lot of the test cases. You will also notice that the fixture :admin is being logged in as the default user. This is done so that you don't have explicitly log into a user account for each test case. The only time you would need to call the method to log in for a particular test case is if you needed to test something specifically in another user type's account (for example a student account as is done in test_create_questionnaire_with_student.

def setup
@controller = QuestionnaireController.new
@request = ActionController::TestRequest.new
@response = ActionController::TestResponse.new
@Questionnaire = questionnaires(:questionnaire5).id
login_user(:admin)
end

The login_user method was created to "DRY out" the code associated with logging a user in. The method signature is:

def login_user(userType)

If you pass a symbol of the user type you would like to use for a test, it will log in as that user type for the particular test. The parameter name is userType and assumes that there is a fixture with the name of the user type. There seem to be sufficient fixtures for all of the different user types currently, but additional fixtures may need to be created in the future if new user types are added to the system.

=== Test Coverage ===

There are three main types of tests that we created.

* Happy path tests of the controller's public methods. There is a test for every method. (ex: test_new)
* Sad path tests that passed invalid parameters. (ex: test_edit_questionnaire_with_lower_max_score_than_min)
* Sad path tests that tried to do things with insufficient access level. (ex: test_create_questionnaire_with_student)

=== How to Run Controller Test ===

All of the QuestionnaireController tests are in the questionnaire_controller_test.rb file and can be run as a standard functional test.

== Questionnaire Subclass Unit Tests ==

The original assignment was to write unit tests for the Questionnaire subclasses:
* author_feedback_questionnaire.rb
* metareview_questionnaire.rb
* review_questionnaire.rb
* teammate_review_questionnaire.rb

As we reviewed the tests, it was found that most of the methods were trivial (ex: the method "symbol" only only returns a hardcoded symbol). The only method that was found to be worth testing was the get_weighted_score method. Upon further review, however, we found that testing this method in each of the four subclasses violated the DRY principle. Therefore, we moved the test to the superclass (Questionnaire) to test the "get_weighted_score" method.

=== Modifications to Existing Questionnaire Subclass Tests ===

There was only one test in the existing unit test for AuthorFeedbackQuestionnaire for testing the "get_weighted_score" method. Even though the test could be run, we found that it was not making assertions as it should. The files for the other 3 questionnaire subclasses were created to complete the testing on them. As stated earlier, we then found that testing the "get_weighted_score" method was redundant, violating the DRY principle, so it was moved to the superclass (Questionnaire). The tests in the subclasses were deleted (since they were redundant) but the test files were kept for future testing of the subclass if/when needed.

=== Test Coverage ===

The method "compute_weighted_score" from the the base class was the only thing that needed to be tested (due to the above reason). Based on an average, it was asserted that the value was not nil and that the value was computed correctly.

=== How to Run Unit Tests ===

The "compute_weighted_score" test can be found in the Questionnaire Unit Test file.

== General Information ==

=== Members ===
*Jonathan Wills - jrwills2
*Chun Sing Tsui - ctsui
*Travis Folsom - twfolsom

=== Highlights of Project ===
* Added unit test for questionnaire class
* Added functional tests for questionnaire controller
* 24 total tests
* Delete test in functional testing was failing due to a potential bug in the questionnaire controller

=== List of files changed ===
*test/fixtures/assignment_questionnaires.yml
*test/fixtures/question_types.yml
*test/fixtures/questionnaires.yml
*test/fixtures/questions.yml
*test/functional/questionnaire_controller_test.rb
*test/unit/questionnaire_test.rb
*test/unit/author_feedback_questionnaire_test.rb
*test/unit/metareview_questionnaire_test.rb
*test/unit/review_questionnaire_test.rb
*test/unit/teammate_review_questionnaire_test.rb

= NOTE =
The Questionnaire model class contains a ''has_many :assignment_questionnaire'' that should be ''has_many :assignment_questionnaire'''s''' '' according to convention. If this is the case, then in the "compute_weighted_score" method, the ''self.assignemnt_questionnaire...'' call also needs to be changed to ''self.assignment_questionnaires...''. This most likely needs to be refactored, but we did not want to do a refactor without testing its effects on the system thoroughly.

CSC/ECE 517 Spring 2013/OSS E605B

2013-03-21T01:19:54Z

Ctsui: /* NOTE */

=Testing - questionnaire=

== QuestionnaireController Functional Tests ==

The majority of the tests implemented in this project are functional tests of the questionnaire controller. The test cases were written using the [http://api.rubyonrails.org/classes/ActionController/TestCase.html ActionController::TestCase] framework provided by Rails.

=== Modifications to Existing QuestionnaireController Test ===

There were a few tests already written for the Questionnaire controller, but they were not passing initially. We had to modify several things in the test and questionnaire fixture in order to get things up and running. The setup method contained login code that was outdated, and thus each test would result in a redirect due to the invalid login credential. So we looked through other more up to date functional test files and found the correct way to login as a particular user. We also put this code in a helper method so we can call it more easily in different tests if we so choose (more on this in the "Helper Methods" section).

In addition, we added a new questionnaire fixture (:questionnaire5) to help with our testing. Through debugging the test error messages, we saw that an additional required column called "section" has been added to the "Questionnaire" model, which was contributing to the failures. We added the additional column accordingly in :questionnaire5.

=== Helper Methods ===

There are two methods that assist in setting up and running the tests:

*The setup method
*The login_user method

The setup method assigns three special instance variables that are associated with the ActionController::TestCase (@controller, @request, and @response). In addition to setting these, the @Questionnaire variable is assigned to id of the :questionnaire5 fixture. This is the default questionnaire fixture that is used in a lot of the test cases. You will also notice that the fixture :admin is being logged in as the default user. This is done so that you don't have explicitly log into a user account for each test case. The only time you would need to call the method to log in for a particular test case is if you needed to test something specifically in another user type's account (for example a student account as is done in test_create_questionnaire_with_student.

def setup
@controller = QuestionnaireController.new
@request = ActionController::TestRequest.new
@response = ActionController::TestResponse.new
@Questionnaire = questionnaires(:questionnaire5).id
login_user(:admin)
end

The login_user method was created to "DRY out" the code associated with logging a user in. The method signature is:

def login_user(userType)

If you pass a symbol of the user type you would like to use for a test, it will log in as that user type for the particular test. The parameter name is userType and assumes that there is a fixture with the name of the user type. There seem to be sufficient fixtures for all of the different user types currently, but additional fixtures may need to be created in the future if new user types are added to the system.

=== Test Coverage ===

There are three main types of tests that we created.

* Happy path tests of the controller's public methods. There is a test for every method. (ex: test_new)
* Sad path tests that passed invalid parameters. (ex: test_edit_questionnaire_with_lower_max_score_than_min)
* Sad path tests that tried to do things with insufficient access level. (ex: test_create_questionnaire_with_student)

=== How to Run Controller Test ===

All of the QuestionnaireController tests are in the questionnaire_controller_test.rb file and can be run as a standard functional test.

== Questionnaire Subclass Unit Tests ==

The original assignment was to write unit tests for the Questionnaire subclasses:
* author_feedback_questionnaire.rb
* metareview_questionnaire.rb
* review_questionnaire.rb
* teammate_review_questionnaire.rb

As we reviewed the tests, it was found that most of the methods were trivial (ex: the method "symbol" only only returns a hardcoded symbol). The only method that was found to be worth testing was the get_weighted_score method. Upon further review, however, we found that testing this method in each of the four subclasses violated the DRY principle. Therefore, we moved the test to the superclass (Questionnaire) to test the "get_weighted_score" method.

=== Modifications to Existing Questionnaire Subclass Tests ===

There was only one test in the existing unit test for AuthorFeedbackQuestionnaire for testing the "get_weighted_score" method. Even though the test could be run, we found that it was not making assertions as it should. The files for the other 3 questionnaire subclasses were created to complete the testing on them. As stated earlier, we then found that testing the "get_weighted_score" method was redundant, violating the DRY principle, so it was moved to the superclass (Questionnaire). The tests in the subclasses were deleted (since they were redundant) but the test files were kept for future testing of the subclass if/when needed.

=== Test Coverage ===

Tested the one method "compute_weighted_score" from the subclasses that was not trivial. Based on an average, it was asserted that the value was not nil and that the value was computed correctly.

=== How to Run Unit Tests ===

The "compute_weighted_score" test can be found in the Questionnaire Unit Test file.

== General Information ==

=== Members ===
*Jonathan Wills - jrwills2
*Chun Sing Tsui - ctsui
*Travis Folsom - twfolsom

=== Highlights of Project ===
* Added unit test for questionnaire class
* Added functional tests for questionnaire controller
* 24 total tests
* Delete test in functional testing was failing due to a potential bug in the questionnaire controller

=== List of files changed ===
*test/fixtures/assignment_questionnaires.yml
*test/fixtures/question_types.yml
*test/fixtures/questionnaires.yml
*test/fixtures/questions.yml
*test/functional/questionnaire_controller_test.rb
*test/unit/questionnaire_test.rb
*test/unit/author_feedback_questionnaire_test.rb
*test/unit/metareview_questionnaire_test.rb
*test/unit/review_questionnaire_test.rb
*test/unit/teammate_review_questionnaire_test.rb

= NOTE =
The Questionnaire model class contains a ''has_many :assignment_questionnaire'' that should be ''has_many :assignment_questionnaire'''s''' '' according to convention. If this is the case, then in the "compute_weighted_score" method, the ''self.assignemnt_questionnaire...'' call also needs to be changed to ''self.assignment_questionnaires...''. This most likely needs to be refactored, but we did not want to do a refactor without testing its effects on the system thoroughly.

CSC/ECE 517 Spring 2013/OSS E605B

2013-03-21T01:19:35Z

Ctsui: /* NOTE */

=Testing - questionnaire=

== QuestionnaireController Functional Tests ==

The majority of the tests implemented in this project are functional tests of the questionnaire controller. The test cases were written using the [http://api.rubyonrails.org/classes/ActionController/TestCase.html ActionController::TestCase] framework provided by Rails.

=== Modifications to Existing QuestionnaireController Test ===

There were a few tests already written for the Questionnaire controller, but they were not passing initially. We had to modify several things in the test and questionnaire fixture in order to get things up and running. The setup method contained login code that was outdated, and thus each test would result in a redirect due to the invalid login credential. So we looked through other more up to date functional test files and found the correct way to login as a particular user. We also put this code in a helper method so we can call it more easily in different tests if we so choose (more on this in the "Helper Methods" section).

In addition, we added a new questionnaire fixture (:questionnaire5) to help with our testing. Through debugging the test error messages, we saw that an additional required column called "section" has been added to the "Questionnaire" model, which was contributing to the failures. We added the additional column accordingly in :questionnaire5.

=== Helper Methods ===

There are two methods that assist in setting up and running the tests:

*The setup method
*The login_user method

The setup method assigns three special instance variables that are associated with the ActionController::TestCase (@controller, @request, and @response). In addition to setting these, the @Questionnaire variable is assigned to id of the :questionnaire5 fixture. This is the default questionnaire fixture that is used in a lot of the test cases. You will also notice that the fixture :admin is being logged in as the default user. This is done so that you don't have explicitly log into a user account for each test case. The only time you would need to call the method to log in for a particular test case is if you needed to test something specifically in another user type's account (for example a student account as is done in test_create_questionnaire_with_student.

def setup
@controller = QuestionnaireController.new
@request = ActionController::TestRequest.new
@response = ActionController::TestResponse.new
@Questionnaire = questionnaires(:questionnaire5).id
login_user(:admin)
end

The login_user method was created to "DRY out" the code associated with logging a user in. The method signature is:

def login_user(userType)

If you pass a symbol of the user type you would like to use for a test, it will log in as that user type for the particular test. The parameter name is userType and assumes that there is a fixture with the name of the user type. There seem to be sufficient fixtures for all of the different user types currently, but additional fixtures may need to be created in the future if new user types are added to the system.

=== Test Coverage ===

There are three main types of tests that we created.

* Happy path tests of the controller's public methods. There is a test for every method. (ex: test_new)
* Sad path tests that passed invalid parameters. (ex: test_edit_questionnaire_with_lower_max_score_than_min)
* Sad path tests that tried to do things with insufficient access level. (ex: test_create_questionnaire_with_student)

=== How to Run Controller Test ===

All of the QuestionnaireController tests are in the questionnaire_controller_test.rb file and can be run as a standard functional test.

== Questionnaire Subclass Unit Tests ==

The original assignment was to write unit tests for the Questionnaire subclasses:
* author_feedback_questionnaire.rb
* metareview_questionnaire.rb
* review_questionnaire.rb
* teammate_review_questionnaire.rb

As we reviewed the tests, it was found that most of the methods were trivial (ex: the method "symbol" only only returns a hardcoded symbol). The only method that was found to be worth testing was the get_weighted_score method. Upon further review, however, we found that testing this method in each of the four subclasses violated the DRY principle. Therefore, we moved the test to the superclass (Questionnaire) to test the "get_weighted_score" method.

=== Modifications to Existing Questionnaire Subclass Tests ===

There was only one test in the existing unit test for AuthorFeedbackQuestionnaire for testing the "get_weighted_score" method. Even though the test could be run, we found that it was not making assertions as it should. The files for the other 3 questionnaire subclasses were created to complete the testing on them. As stated earlier, we then found that testing the "get_weighted_score" method was redundant, violating the DRY principle, so it was moved to the superclass (Questionnaire). The tests in the subclasses were deleted (since they were redundant) but the test files were kept for future testing of the subclass if/when needed.

=== Test Coverage ===

Tested the one method "compute_weighted_score" from the subclasses that was not trivial. Based on an average, it was asserted that the value was not nil and that the value was computed correctly.

=== How to Run Unit Tests ===

The "compute_weighted_score" test can be found in the Questionnaire Unit Test file.

== General Information ==

=== Members ===
*Jonathan Wills - jrwills2
*Chun Sing Tsui - ctsui
*Travis Folsom - twfolsom

=== Highlights of Project ===
* Added unit test for questionnaire class
* Added functional tests for questionnaire controller
* 24 total tests
* Delete test in functional testing was failing due to a potential bug in the questionnaire controller

=== List of files changed ===
*test/fixtures/assignment_questionnaires.yml
*test/fixtures/question_types.yml
*test/fixtures/questionnaires.yml
*test/fixtures/questions.yml
*test/functional/questionnaire_controller_test.rb
*test/unit/questionnaire_test.rb
*test/unit/author_feedback_questionnaire_test.rb
*test/unit/metareview_questionnaire_test.rb
*test/unit/review_questionnaire_test.rb
*test/unit/teammate_review_questionnaire_test.rb

= NOTE =
The Questionnaire model class contains a ''has_many :assignment_questionnaire'' that should be ''has_many :assignment_questionnaire'''s''' '' according to convention. If this is the case, then in the "compute_weighted_score" method, the ''self.assignemnt_questionnaire...'' call also needs to be changed to ''self.assignment_questionnaires...''. This most likely needs to be refactored, but we did not want to do a refactor without testing its effects on the system throughly.

CSC/ECE 517 Spring 2013/OSS E605B

2013-03-21T01:14:18Z

Ctsui: /* List of files changed */

=Testing - questionnaire=

== QuestionnaireController Functional Tests ==

The majority of the tests implemented in this project are functional tests of the questionnaire controller. The test cases were written using the [http://api.rubyonrails.org/classes/ActionController/TestCase.html ActionController::TestCase] framework provided by Rails.

=== Modifications to Existing QuestionnaireController Test ===

There were a few tests already written for the Questionnaire controller, but they were not passing initially. We had to modify several things in the test and questionnaire fixture in order to get things up and running. The setup method contained login code that was outdated, and thus each test would result in a redirect due to the invalid login credential. So we looked through other more up to date functional test files and found the correct way to login as a particular user. We also put this code in a helper method so we can call it more easily in different tests if we so choose (more on this in the "Helper Methods" section).

In addition, we added a new questionnaire fixture (:questionnaire5) to help with our testing. Through debugging the test error messages, we saw that an additional required column called "section" has been added to the "Questionnaire" model, which was contributing to the failures. We added the additional column accordingly in :questionnaire5.

=== Helper Methods ===

There are two methods that assist in setting up and running the tests:

*The setup method
*The login_user method

The setup method assigns three special instance variables that are associated with the ActionController::TestCase (@controller, @request, and @response). In addition to setting these, the @Questionnaire variable is assigned to id of the :questionnaire5 fixture. This is the default questionnaire fixture that is used in a lot of the test cases. You will also notice that the fixture :admin is being logged in as the default user. This is done so that you don't have explicitly log into a user account for each test case. The only time you would need to call the method to log in for a particular test case is if you needed to test something specifically in another user type's account (for example a student account as is done in test_create_questionnaire_with_student.

def setup
@controller = QuestionnaireController.new
@request = ActionController::TestRequest.new
@response = ActionController::TestResponse.new
@Questionnaire = questionnaires(:questionnaire5).id
login_user(:admin)
end

The login_user method was created to "DRY out" the code associated with logging a user in. The method signature is:

def login_user(userType)

If you pass a symbol of the user type you would like to use for a test, it will log in as that user type for the particular test. The parameter name is userType and assumes that there is a fixture with the name of the user type. There seem to be sufficient fixtures for all of the different user types currently, but additional fixtures may need to be created in the future if new user types are added to the system.

=== Test Coverage ===

There are three main types of tests that we created.

* Happy path tests of the controller's public methods. There is a test for every method. (ex: test_new)
* Sad path tests that passed invalid parameters. (ex: test_edit_questionnaire_with_lower_max_score_than_min)
* Sad path tests that tried to do things with insufficient access level. (ex: test_create_questionnaire_with_student)

=== How to Run Controller Test ===

All of the QuestionnaireController tests are in the questionnaire_controller_test.rb file and can be run as a standard functional test.

== Questionnaire Subclass Unit Tests ==

The original assignment was to write unit tests for the Questionnaire subclasses:
* author_feedback_questionnaire.rb
* metareview_questionnaire.rb
* review_questionnaire.rb
* teammate_review_questionnaire.rb

As we reviewed the tests, it was found that most of the methods were trivial (ex: the method "symbol" only only returns a hardcoded symbol). The only method that was found to be worth testing was the get_weighted_score method. Upon further review, however, we found that testing this method in each of the four subclasses violated the DRY principle. Therefore, we moved the test to the superclass (Questionnaire) to test the "get_weighted_score" method.

=== Modifications to Existing Questionnaire Subclass Tests ===

There was only one test in the existing unit test for AuthorFeedbackQuestionnaire for testing the "get_weighted_score" method. Even though the test could be run, we found that it was not making assertions as it should. The files for the other 3 questionnaire subclasses were created to complete the testing on them. As stated earlier, we then found that testing the "get_weighted_score" method was redundant, violating the DRY principle, so it was moved to the superclass (Questionnaire). The tests in the subclasses were deleted (since they were redundant) but the test files were kept for future testing of the subclass if/when needed.

=== Test Coverage ===

Tested the one method "compute_weighted_score" from the subclasses that was not trivial. Based on an average, it was asserted that the value was not nil and that the value was computed correctly.

=== How to Run Unit Tests ===

The "compute_weighted_score" test can be found in the Questionnaire Unit Test file.

== General Information ==

=== Members ===
*Jonathan Wills - jrwills2
*Chun Sing Tsui - ctsui
*Travis Folsom - twfolsom

=== Highlights of Project ===
* Added unit test for questionnaire class
* Added functional tests for questionnaire controller
* 24 total tests
* Delete test in functional testing was failing due to a potential bug in the questionnaire controller

=== List of files changed ===
*test/fixtures/assignment_questionnaires.yml
*test/fixtures/question_types.yml
*test/fixtures/questionnaires.yml
*test/fixtures/questions.yml
*test/functional/questionnaire_controller_test.rb
*test/unit/questionnaire_test.rb
*test/unit/author_feedback_questionnaire_test.rb
*test/unit/metareview_questionnaire_test.rb
*test/unit/review_questionnaire_test.rb
*test/unit/teammate_review_questionnaire_test.rb

= NOTE =
Questionnaire class, has_many :assignment_questionnaire needs to be :assignment_questionnaires. Also needs to be changed on the next line: through: => "assignment_questionnaires" (we were told that this was convention to be plural). If this is the case, then in the "compute_weighted_score" method, assignemnt_questionnaire also needs to be changed to assignment_questionnaires. This most likely needs to be refactored, but we did not want to do a refactor without testing its effects on the system.

CSC/ECE 517 Spring 2013/OSS E605B

2013-03-21T01:10:44Z

Ctsui: /* Highlights of Project */

=Testing - questionnaire=

== QuestionnaireController Functional Tests ==

The majority of the tests implemented in this project are functional tests of the questionnaire controller. The test cases were written using the [http://api.rubyonrails.org/classes/ActionController/TestCase.html ActionController::TestCase] framework provided by Rails.

=== Modifications to Existing QuestionnaireController Test ===

There were a few tests already written for the Questionnaire controller, but they were not passing initially. We had to modify several things in the test and questionnaire fixture in order to get things up and running. The setup method contained login code that was outdated, and thus each test would result in a redirect due to the invalid login credential. So we looked through other more up to date functional test files and found the correct way to login as a particular user. We also put this code in a helper method so we can call it more easily in different tests if we so choose (more on this in the "Helper Methods" section).

In addition, we added a new questionnaire fixture (:questionnaire5) to help with our testing. Through debugging the test error messages, we saw that an additional required column called "section" has been added to the "Questionnaire" model, which was contributing to the failures. We added the additional column accordingly in :questionnaire5.

=== Helper Methods ===

There are two methods that assist in setting up and running the tests:

*The setup method
*The login_user method

The setup method assigns three special instance variables that are associated with the ActionController::TestCase (@controller, @request, and @response). In addition to setting these, the @Questionnaire variable is assigned to id of the :questionnaire5 fixture. This is the default questionnaire fixture that is used in a lot of the test cases. You will also notice that the fixture :admin is being logged in as the default user. This is done so that you don't have explicitly log into a user account for each test case. The only time you would need to call the method to log in for a particular test case is if you needed to test something specifically in another user type's account (for example a student account as is done in test_create_questionnaire_with_student.

def setup
@controller = QuestionnaireController.new
@request = ActionController::TestRequest.new
@response = ActionController::TestResponse.new
@Questionnaire = questionnaires(:questionnaire5).id
login_user(:admin)
end

The login_user method was created to "DRY out" the code associated with logging a user in. The method signature is:

def login_user(userType)

If you pass a symbol of the user type you would like to use for a test, it will log in as that user type for the particular test. The parameter name is userType and assumes that there is a fixture with the name of the user type. There seem to be sufficient fixtures for all of the different user types currently, but additional fixtures may need to be created in the future if new user types are added to the system.

=== Test Coverage ===

There are three main types of tests that we created.

* Happy path tests of the controller's public methods. There is a test for every method. (ex: test_new)
* Sad path tests that passed invalid parameters. (ex: test_edit_questionnaire_with_lower_max_score_than_min)
* Sad path tests that tried to do things with insufficient access level. (ex: test_create_questionnaire_with_student)

=== How to Run Controller Test ===

All of the QuestionnaireController tests are in the questionnaire_controller_test.rb file and can be run as a standard functional test.

== Questionnaire Subclass Unit Tests ==

The original assignment was to write unit tests for the Questionnaire subclasses:
* author_feedback_questionnaire.rb
* metareview_questionnaire.rb
* review_questionnaire.rb
* teammate_review_questionnaire.rb

As we reviewed the tests, it was found that most of the methods were trivial (ex: the method "symbol" only only returns a hardcoded symbol). The only method that was found to be worth testing was the get_weighted_score method. Upon further review, however, we found that testing this method in each of the four subclasses violated the DRY principle. Therefore, we moved the test to the superclass (Questionnaire) to test the "get_weighted_score" method.

=== Modifications to Existing Questionnaire Subclass Tests ===

There was only one test in the existing unit test for AuthorFeedbackQuestionnaire for testing the "get_weighted_score" method. Even though the test could be run, we found that it was not making assertions as it should. The files for the other 3 questionnaire subclasses were created to complete the testing on them. As stated earlier, we then found that testing the "get_weighted_score" method was redundant, violating the DRY principle, so it was moved to the superclass (Questionnaire). The tests in the subclasses were deleted (since they were redundant) but the test files were kept for future testing of the subclass if/when needed.

=== Test Coverage ===

Tested the one method "compute_weighted_score" from the subclasses that was not trivial. Based on an average, it was asserted that the value was not nil and that the value was computed correctly.

=== How to Run Unit Tests ===

The "compute_weighted_score" test can be found in the Questionnaire Unit Test file.

== General Information ==

=== Members ===
*Jonathan Wills - jrwills2
*Chun Sing Tsui - ctsui
*Travis Folsom - twfolsom

=== Highlights of Project ===
* Added unit test for questionnaire class
* Added functional tests for questionnaire controller
* 24 total tests
* Delete test in functional testing was failing due to a potential bug in the questionnaire controller

=== List of files changed ===
*test/fixtures/question_types.yml
*test/fixtures/questionnaires.yml
*test/fixtures/questions.yml
*test/functional/questionnaire_controller_test.rb
*test/unit/author_feedback_questionnaire_test.rb
*test/unit/metareview_questionnaire_test.rb
*test/unit/review_questionnaire_test.rb
*test/unit/teammate_review_questionnaire_test.rb

= NOTE =
Questionnaire class, has_many :assignment_questionnaire needs to be :assignment_questionnaires. Also needs to be changed on the next line: through: => "assignment_questionnaires" (we were told that this was convention to be plural). If this is the case, then in the "compute_weighted_score" method, assignemnt_questionnaire also needs to be changed to assignment_questionnaires. This most likely needs to be refactored, but we did not want to do a refactor without testing its effects on the system.

CSC/ECE 517 Spring 2013/OSS E605B

2013-03-21T01:10:07Z

Ctsui: /* Questionnaire Subclass Unit Tests */

=Testing - questionnaire=

== QuestionnaireController Functional Tests ==

The majority of the tests implemented in this project are functional tests of the questionnaire controller. The test cases were written using the [http://api.rubyonrails.org/classes/ActionController/TestCase.html ActionController::TestCase] framework provided by Rails.

=== Modifications to Existing QuestionnaireController Test ===

There were a few tests already written for the Questionnaire controller, but they were not passing initially. We had to modify several things in the test and questionnaire fixture in order to get things up and running. The setup method contained login code that was outdated, and thus each test would result in a redirect due to the invalid login credential. So we looked through other more up to date functional test files and found the correct way to login as a particular user. We also put this code in a helper method so we can call it more easily in different tests if we so choose (more on this in the "Helper Methods" section).

In addition, we added a new questionnaire fixture (:questionnaire5) to help with our testing. Through debugging the test error messages, we saw that an additional required column called "section" has been added to the "Questionnaire" model, which was contributing to the failures. We added the additional column accordingly in :questionnaire5.

=== Helper Methods ===

There are two methods that assist in setting up and running the tests:

*The setup method
*The login_user method

The setup method assigns three special instance variables that are associated with the ActionController::TestCase (@controller, @request, and @response). In addition to setting these, the @Questionnaire variable is assigned to id of the :questionnaire5 fixture. This is the default questionnaire fixture that is used in a lot of the test cases. You will also notice that the fixture :admin is being logged in as the default user. This is done so that you don't have explicitly log into a user account for each test case. The only time you would need to call the method to log in for a particular test case is if you needed to test something specifically in another user type's account (for example a student account as is done in test_create_questionnaire_with_student.

def setup
@controller = QuestionnaireController.new
@request = ActionController::TestRequest.new
@response = ActionController::TestResponse.new
@Questionnaire = questionnaires(:questionnaire5).id
login_user(:admin)
end

The login_user method was created to "DRY out" the code associated with logging a user in. The method signature is:

def login_user(userType)

If you pass a symbol of the user type you would like to use for a test, it will log in as that user type for the particular test. The parameter name is userType and assumes that there is a fixture with the name of the user type. There seem to be sufficient fixtures for all of the different user types currently, but additional fixtures may need to be created in the future if new user types are added to the system.

=== Test Coverage ===

There are three main types of tests that we created.

* Happy path tests of the controller's public methods. There is a test for every method. (ex: test_new)
* Sad path tests that passed invalid parameters. (ex: test_edit_questionnaire_with_lower_max_score_than_min)
* Sad path tests that tried to do things with insufficient access level. (ex: test_create_questionnaire_with_student)

=== How to Run Controller Test ===

All of the QuestionnaireController tests are in the questionnaire_controller_test.rb file and can be run as a standard functional test.

== Questionnaire Subclass Unit Tests ==

The original assignment was to write unit tests for the Questionnaire subclasses:
* author_feedback_questionnaire.rb
* metareview_questionnaire.rb
* review_questionnaire.rb
* teammate_review_questionnaire.rb

As we reviewed the tests, it was found that most of the methods were trivial (ex: the method "symbol" only only returns a hardcoded symbol). The only method that was found to be worth testing was the get_weighted_score method. Upon further review, however, we found that testing this method in each of the four subclasses violated the DRY principle. Therefore, we moved the test to the superclass (Questionnaire) to test the "get_weighted_score" method.

=== Modifications to Existing Questionnaire Subclass Tests ===

There was only one test in the existing unit test for AuthorFeedbackQuestionnaire for testing the "get_weighted_score" method. Even though the test could be run, we found that it was not making assertions as it should. The files for the other 3 questionnaire subclasses were created to complete the testing on them. As stated earlier, we then found that testing the "get_weighted_score" method was redundant, violating the DRY principle, so it was moved to the superclass (Questionnaire). The tests in the subclasses were deleted (since they were redundant) but the test files were kept for future testing of the subclass if/when needed.

=== Test Coverage ===

Tested the one method "compute_weighted_score" from the subclasses that was not trivial. Based on an average, it was asserted that the value was not nil and that the value was computed correctly.

=== How to Run Unit Tests ===

The "compute_weighted_score" test can be found in the Questionnaire Unit Test file.

== General Information ==

=== Members ===
*Jonathan Wills - jrwills2
*Chun Sing Tsui - ctsui
*Travis Folsom - twfolsom

=== Highlights of Project ===
* Added unit test for questionnaire class
* Added functional tests for questionnaire controller
* 24 total tests
* Delete test was failing due to a potential bug in the questionnaire controller

=== List of files changed ===
*test/fixtures/question_types.yml
*test/fixtures/questionnaires.yml
*test/fixtures/questions.yml
*test/functional/questionnaire_controller_test.rb
*test/unit/author_feedback_questionnaire_test.rb
*test/unit/metareview_questionnaire_test.rb
*test/unit/review_questionnaire_test.rb
*test/unit/teammate_review_questionnaire_test.rb

= NOTE =
Questionnaire class, has_many :assignment_questionnaire needs to be :assignment_questionnaires. Also needs to be changed on the next line: through: => "assignment_questionnaires" (we were told that this was convention to be plural). If this is the case, then in the "compute_weighted_score" method, assignemnt_questionnaire also needs to be changed to assignment_questionnaires. This most likely needs to be refactored, but we did not want to do a refactor without testing its effects on the system.

CSC/ECE 517 Spring 2013/OSS E605B

2013-03-21T01:08:36Z

Ctsui: /* Questionnaire Subclass Unit Tests */

=Testing - questionnaire=

== QuestionnaireController Functional Tests ==

The majority of the tests implemented in this project are functional tests of the questionnaire controller. The test cases were written using the [http://api.rubyonrails.org/classes/ActionController/TestCase.html ActionController::TestCase] framework provided by Rails.

=== Modifications to Existing QuestionnaireController Test ===

There were a few tests already written for the Questionnaire controller, but they were not passing initially. We had to modify several things in the test and questionnaire fixture in order to get things up and running. The setup method contained login code that was outdated, and thus each test would result in a redirect due to the invalid login credential. So we looked through other more up to date functional test files and found the correct way to login as a particular user. We also put this code in a helper method so we can call it more easily in different tests if we so choose (more on this in the "Helper Methods" section).

In addition, we added a new questionnaire fixture (:questionnaire5) to help with our testing. Through debugging the test error messages, we saw that an additional required column called "section" has been added to the "Questionnaire" model, which was contributing to the failures. We added the additional column accordingly in :questionnaire5.

=== Helper Methods ===

There are two methods that assist in setting up and running the tests:

*The setup method
*The login_user method

The setup method assigns three special instance variables that are associated with the ActionController::TestCase (@controller, @request, and @response). In addition to setting these, the @Questionnaire variable is assigned to id of the :questionnaire5 fixture. This is the default questionnaire fixture that is used in a lot of the test cases. You will also notice that the fixture :admin is being logged in as the default user. This is done so that you don't have explicitly log into a user account for each test case. The only time you would need to call the method to log in for a particular test case is if you needed to test something specifically in another user type's account (for example a student account as is done in test_create_questionnaire_with_student.

def setup
@controller = QuestionnaireController.new
@request = ActionController::TestRequest.new
@response = ActionController::TestResponse.new
@Questionnaire = questionnaires(:questionnaire5).id
login_user(:admin)
end

The login_user method was created to "DRY out" the code associated with logging a user in. The method signature is:

def login_user(userType)

If you pass a symbol of the user type you would like to use for a test, it will log in as that user type for the particular test. The parameter name is userType and assumes that there is a fixture with the name of the user type. There seem to be sufficient fixtures for all of the different user types currently, but additional fixtures may need to be created in the future if new user types are added to the system.

=== Test Coverage ===

There are three main types of tests that we created.

* Happy path tests of the controller's public methods. There is a test for every method. (ex: test_new)
* Sad path tests that passed invalid parameters. (ex: test_edit_questionnaire_with_lower_max_score_than_min)
* Sad path tests that tried to do things with insufficient access level. (ex: test_create_questionnaire_with_student)

=== How to Run Controller Test ===

All of the QuestionnaireController tests are in the questionnaire_controller_test.rb file and can be run as a standard functional test.

== Questionnaire Subclass Unit Tests ==

The original assignment was to write unit tests for the Questionnaire Subclasses. As we reviewed the tests, it was found that most of the methods were trivial (ex: the method "symbol" only only returns a hardcoded symbol). The only method that was found to be worth testing was the get_weighted_score method. Upon further review, however, we found that testing this method in each of the four subclasses violated the DRY principle. Therefore, we moved the test to the superclass (Questionnaire) to test the "get_weighted_score" method.

=== Modifications to Existing Questionnaire Subclass Tests ===

There was only one test in the existing unit test for AuthorFeedbackQuestionnaire for testing the "get_weighted_score" method. Even though the test could be run, we found that it was not making assertions as it should. The files for the other 3 questionnaire subclasses were created to complete the testing on them. As stated earlier, we then found that testing the "get_weighted_score" method was redundant, violating the DRY principle, so it was moved to the superclass (Questionnaire). The tests in the subclasses were deleted (since they were redundant) but the test files were kept for future testing of the subclass if/when needed.

=== Test Coverage ===

Tested the one method "compute_weighted_score" from the subclasses that was not trivial. Based on an average, it was asserted that the value was not nil and that the value was computed correctly.

=== How to Run Unit Tests ===

The "compute_weighted_score" test can be found in the Questionnaire Unit Test file.

== General Information ==

=== Members ===
*Jonathan Wills - jrwills2
*Chun Sing Tsui - ctsui
*Travis Folsom - twfolsom

=== Highlights of Project ===
* Added unit test for questionnaire class
* Added functional tests for questionnaire controller
* 24 total tests
* Delete test was failing due to a potential bug in the questionnaire controller

=== List of files changed ===
*test/fixtures/question_types.yml
*test/fixtures/questionnaires.yml
*test/fixtures/questions.yml
*test/functional/questionnaire_controller_test.rb
*test/unit/author_feedback_questionnaire_test.rb
*test/unit/metareview_questionnaire_test.rb
*test/unit/review_questionnaire_test.rb
*test/unit/teammate_review_questionnaire_test.rb

= NOTE =
Questionnaire class, has_many :assignment_questionnaire needs to be :assignment_questionnaires. Also needs to be changed on the next line: through: => "assignment_questionnaires" (we were told that this was convention to be plural). If this is the case, then in the "compute_weighted_score" method, assignemnt_questionnaire also needs to be changed to assignment_questionnaires. This most likely needs to be refactored, but we did not want to do a refactor without testing its effects on the system.

CSC/ECE 517 Spring 2013/OSS E605B

2013-03-20T17:13:41Z

Ctsui:

=Testing - questionnaire=

== QuestionnaireController Functional Tests ==

The majority of the tests implemented in this project are functional tests of the questionnaire controller. The test cases were written using the [http://api.rubyonrails.org/classes/ActionController/TestCase.html ActionController::TestCase] framework provided by Rails.

=== Modifications to Existing QuestionnaireController Test ===

There were a few tests already written for the Questionnaire controller, but they were not passing initially. We had to modify several things in the test and questionnaire fixture in order to get things up and running. The setup method contained login code that was outdated, and thus each test would result in a redirect due to the invalid login credential. So we looked through other more up to date functional test files and found the correct way to login as a particular user. We also put this code in a helper method so we can call it more easily in different tests if we so choose (more on this in the "Helper Methods" section).

In addition, we added a new questionnaire fixture (:questionnaire5) to help with our testing. Through debugging the test error messages, we saw that an additional required column called "section" has been added to the "Questionnaire" model, which was contributing to the failures. We added the additional column accordingly in :questionnaire5.

=== Helper Methods ===

There are two methods that assist in setting up and running the tests:

*The setup method
*The login_user method

The setup method assigns three special instance variables that are associated with the ActionController::TestCase (@controller, @request, and @response). In addition to setting these, the @Questionnaire variable is assigned to id of the :questionnaire5 fixture. This is the default questionnaire fixture that is used in a lot of the test cases. You will also notice that the fixture :admin is being logged in as the default user. This is done so that you don't have explicitly log into a user account for each test case. The only time you would need to call the method to log in for a particular test case is if you needed to test something specifically in another user type's account (for example a student account as is done in test_create_questionnaire_with_student.

def setup
@controller = QuestionnaireController.new
@request = ActionController::TestRequest.new
@response = ActionController::TestResponse.new
@Questionnaire = questionnaires(:questionnaire5).id
login_user(:admin)
end

The login_user method was created to "DRY out" the code associated with logging a user in. The method signature is:

def login_user(userType)

If you pass a symbol of the user type you would like to use for a test, it will log in as that user type for the particular test. The parameter name is userType and assumes that there is a fixture with the name of the user type. There seem to be sufficient fixtures for all of the different user types currently, but additional fixtures may need to be created in the future if new user types are added to the system.

=== Test Coverage ===

There are three main types of tests that we created.

* Happy path tests of the controller's public methods. There is a test for every method. (ex: test_new)
* Sad path tests that passed invalid parameters. (ex: test_edit_questionnaire_with_lower_max_score_than_min)
* Sad path tests that tried to do things with insufficient access level. (ex: test_create_questionnaire_with_student)

=== How to Run Controller Test ===

All of the QuestionnaireController tests are in the questionnaire_controller_test.rb file and can be run as a standard functional test.

== Questionnaire Subclass Unit Tests ==

=== Modifications to Existing Questionnaire Subclass Tests ===

There was only one test in the exiting unit test for AuthorFeedbackQuestionnaire for testing the get_weighted_score method. Even though the test can be run, we found that it was not making assertions as it should, and therefore chose to rewrote test instead.

=== Test Coverage ===

=== How to Run Unit Tests ===

== General Information ==

=== Members ===
*Jonathan Wills - jrwills2
*Chun Sing Tsui - ctsui
*Travis Folsom - twfolsom

=== Highlights of Project ===
* Added unit tests for questionnaire subclasses
* Added functional tests for questionnaire controller
* 24 total tests
* Delete test was failing due to a potential bug in the questionnaire controller

=== List of files changed ===
*test/fixtures/question_types.yml
*test/fixtures/questionnaires.yml
*test/fixtures/questions.yml
*test/functional/questionnaire_controller_test.rb
*test/unit/author_feedback_questionnaire_test.rb
*test/unit/metareview_questionnaire_test.rb
*test/unit/review_questionnaire_test.rb
*test/unit/teammate_review_questionnaire_test.rb

CSC/ECE 517 Spring 2013/OSS E605B

2013-03-20T16:49:51Z

Ctsui:

CSC/ECE 517 Spring 2013/OSS E605B

2013-03-20T16:48:52Z

Ctsui: /* QuestionnaireController Functional Tests */

CSC/ECE 517 Spring 2013/OSS E605B

2013-03-20T15:00:43Z

Ctsui:

CSC/ECE 517 Spring 2013/OSS E605B

2013-03-20T14:59:53Z

Ctsui:

CSC/ECE 517 Spring 2013/OSS E605B

2013-03-20T14:59:04Z

Ctsui:

CSC/ECE 517 Spring 2013/ch1a c ct

2013-02-15T18:00:58Z

Ctsui: /* References */

__TOC__

= Introduction =
[https://docs.google.com/a/ncsu.edu/document/d/1czn14Zpte-kVHdcb5BUIkpI6wRcABH246jGCg9vncQA/edit#heading=h.8hxo5kudhpn2 Topic Writeup]

Ruby as a programming language has gained popularity in recent years (mainly due to the Rails web framework). There exists quite a few graphical user interface toolkits/frameworks for Ruby so that desktop GUI applications can be created. Most are simply bindings to existing GUI framework API's like Qt and GTK+, so they may seem awkward and unfitting to the Ruby language's style. Shoes, on the other hand, is written for Ruby specifically. Two previous articles have made detailed comparisons between different toolkits by looking at various factors such as ease of installation, documentation, look and feel, and difficulty of usage.[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH][http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_MM] This article will give updates on GUI toolkits that has developed since the previous articles were written, as well as discuss other toolkits that were not present in the previous articles.

= Current State of GUI Toolkits for Ruby =

There is a number of Ruby GUI toolkits to choose from to create a desktop application. In one of the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH#Projects_developed_in_wxRuby previous] articles, an official 2008 Ruby GUI Survey was referenced to discuss the popularity of available GUI toolkits. For a quick recap, here is the result for the question "''Which of the GUI toolkits do you currently use, and which do you think it's likely you'll use in the future?''"

[[File:Survey_results1.jpg|thumb|Survey Results]]

#Shoes
#Ruby-GNOME2/GTK
#wxRuby
#Ruby-Tk
#Ruby Cocoa/MacRuby
#QtRuby
#JRuby + Swing
#FxRuby
#JRuby + SWT

[https://www.ruby-toolbox.com/categories/GUI_Frameworks The Ruby Toolbox], a website that tracks the popularity of Ruby related tools by usage in open source projects, has a list of several toolkits under its "GUI Frameworks" category. The ranking in current popularity (Feb 2013) of GUI toolkits is as follows:

#Shoes
#FxRuby
#wxRuby
#QtBindings
#Ruby/GTK
#monkeybars
#FFI::Tk

Although this list is not as scientific as the official survey result, it does reflect current project usage quite well, and it shows the general acceptance of a particular toolkit. We can see by comparing the two lists that the most popular toolkits (Shoes, FxRuby, wxRuby, Ruby/GTK) are still relevant today. Shoes has proven to be a popular choice since its creation in 2007. Most of the other toolkits remain stable, judging by the dates of code commits of their respective repository. One main exception is wxRuby. wxRuby has not seen a release since September of 2009 even though wxWidgets, the C++ GUI library which wxRuby is based, is still in active development.

However, even though most of these projects are being maintained, there has not been much growth to the GUI community for Ruby. There's still a very low number of applications that are built using GUI toolkits for Ruby, and many of them are personal projects. A simply Google search for Ruby GUI toolkits will return results that mostly predates 2010.

= Overview of other GUI toolkits =
This section will not attempt to cover the same toolkits that were discussed in the previous articles, as there are simply not enough advancements to them to warrant further discussions. The following toolkits are not the most popular choices for Ruby GUI development, according to [https://www.ruby-toolbox.com/categories/GUI_Frameworks The Ruby Toolbox]. However, by reviewing what theses toolkits have to offer, comparisons can then be made with more popular options by examining their advantages and disadvantages.

== Visual Ruby ==
[http://visualruby.net/ Visual Ruby] is designed to simplify the process of adding a GTK+ windows to Ruby applications. It is also designed to completely integrate with the Glade user interface designer.

=== Installation ===
# Install Ruby 1.9.3
# Install Glade and GTK
# Install
>> gem install visualruby

=== Up and Running ===
To run Visual Ruby, simply run the following command
>> vr

After starting up VR, you will see a list of example projects that you can open and run.

[[File:Visual_ruby_1.png]]

[[File:Visual_ruby_2.png]]

To create a brand new project, simply follow the instructions below:

#Runs Visual Ruby if not already running
#Press "Select Folder" button at the bottom of the project selector ("Open project" if VR is already running to get to the project selector)
#Navigate to the directory to your choice, and press "Create Folder" on the top right with the project name of your choice
#Press "Open", and an new default "Hello World" application will appear

=== Pros and Cons ===
*Pros
**Very easy to set up.
**Available on all three major platforms (Windows, Linux, Mac)
**Integration with Glade visual designer provides another easy option to create layouts

*Cons
**Although it is available on all three platforms, it is obvious that it was made with Linux in mind. Launching anything from VR is essentially running a command, and those commands may not be available on Windows (e.g. selecting a Glade file and launching Glade did not work from within VR. Glade had to run manually).

== Monkeybars ==
[https://github.com/monkeybars/monkeybars-core Monkeybars] is a library that enables the use of [http://en.wikipedia.org/wiki/Swing_%28Java%29 Swing] from [http://en.wikipedia.org/wiki/JRuby JRuby]. JRuby is the Java implementation of the Ruby interpreter. This means Ruby code is executed in the JVM. As you'd expect, JRuby is tightly integrated with Java, and it has the ability to invoke classes of the Java platform. As a result, Swing, the Java GUI toolkit, can be used with JRuby.

Monkeybars aims to allow you to continue using the GUI editing tools (e.g. Netbeans) you are used to but makes it easy to write all your application logic in pure Ruby. It utilizes the Model, View, Controller (MVC) design pattern to separate view logic and user interface components from application logic.[http://monkeybars.rubyforge.org/] It should be noted, however, that Monkeybars should not be the first choice if you're looking to quickly create a GUI application from scratch. The overhead of getting one of these projects up and running will be relatively higher than most of the other libraries.

Monkeybars excels at building large and complex GUI applications since it is based on the mature Java language and Swing libraries. This will be a big advantage if creating non-trivial Swing applications with the logic written in Ruby is what you're looking for.[http://www.ibm.com/developerworks/library/j-monkeybars/index.html]

=== Installation ===
# Install Java and JRuby
# Install Monkeybars

>> gem install rawr
>> gem install monkeybars

=== Up and Running ===
To create a new project directory

>> monkeybars test_project

After creating a new monkeybars project, follow the detailed tutorials [http://monkeybars.org/tutorials.html here] to configure your project.

=== Pros and Cons ===
*Pros
**Easy to install
**Project structure is better suited for large and complex applications

*Cons
**Creating a new project has high overhead
**Requires too much effort for simple GUI applications

== FFI-Tk ==
[https://github.com/manveru/ffi-tk FFI-Tk] is a pure Ruby FFI (foreign funciton interface) wrapper for the Tk GUI toolkit. Since it uses [https://github.com/ffi/ffi/wiki/Why-use-FFI FFI], it is meant to be provided as an extension that doesn't need compilation and is multi-platformed.[https://github.com/ffi/ffi/wiki/Why-use-FFI]

=== Installation ===

gem install ffi-tk

=== Up and Running ===
# Sample code taken from https://github.com/manveru/ffi-tk
require 'ffi-tk'
Tk.init
Tk::Button.new('.', text: 'Press me'){
Tk.message_box(message: 'Hello, World!')
}.pack
Tk.mainloop

=== Pros and Cons ===
*Pros
**Easy to use for simple applications
**Eliminates different ways of coding to achieve the same result

*Cons
**Still uses the TK GUI styling, which is the main complain about TK anyways

= Conclusion =
Although there are many toolkits available for building GUI applications with Ruby, there hasn't been much growth in this area relative to 2010. One possible explanation is that the popularity of desktop application develop has yielded to web applications, which Ruby is most well known for due to its Rails framework. By looking at the several toolkits examined above, we can also see why some of them remain to be less popular than others. Monkeybars, for example, has too much overhead just to get an application up and running. The more dependencies, the heavier the toolkit feels. FFI::TK, on the other hand, does not offer any more features than others to warrant popular use. It does seem, however, several of the most popular options will continue to be stable projects. One example is Shoes. Shoes is currently at version 3, and a new version is coming soon. Shoes 4 will be the next version of Shoes[https://github.com/shoes/shoes4]. Perhaps this is why the [http://shoesrb.com/downloads download] page for Shoes is currently void of any content.

= External Links =
*[https://www.ruby-toolbox.com/categories/GUI_Frameworks The Ruby Toolbox GUI Frameworks]
*[http://visualruby.net/ Visual Ruby Homepage]
*[https://github.com/monkeybars/monkeybars-core Monkeybars GitHub Page]
*[https://github.com/manveru/ffi-tk FFI-Tk GitHub Page]

= References =
[1] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH Previous Submission 1] 
[2] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_MM Previous Submission 2] 
[3] [http://monkeybars.rubyforge.org/ Monkeybars Homepage] 
[4] [http://www.ibm.com/developerworks/library/j-monkeybars/index.html The monkeybars library] 
[5] [https://github.com/ffi/ffi/wiki/Why-use-FFI Why use FFI] 
[6] [http://shoesrb.com/downloads Shoes 4 Github Page]

CSC/ECE 517 Spring 2013/ch1a c ct

2013-02-15T17:59:43Z

Ctsui:

__TOC__

= Introduction =
[https://docs.google.com/a/ncsu.edu/document/d/1czn14Zpte-kVHdcb5BUIkpI6wRcABH246jGCg9vncQA/edit#heading=h.8hxo5kudhpn2 Topic Writeup]

Ruby as a programming language has gained popularity in recent years (mainly due to the Rails web framework). There exists quite a few graphical user interface toolkits/frameworks for Ruby so that desktop GUI applications can be created. Most are simply bindings to existing GUI framework API's like Qt and GTK+, so they may seem awkward and unfitting to the Ruby language's style. Shoes, on the other hand, is written for Ruby specifically. Two previous articles have made detailed comparisons between different toolkits by looking at various factors such as ease of installation, documentation, look and feel, and difficulty of usage.[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH][http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_MM] This article will give updates on GUI toolkits that has developed since the previous articles were written, as well as discuss other toolkits that were not present in the previous articles.

= Current State of GUI Toolkits for Ruby =

There is a number of Ruby GUI toolkits to choose from to create a desktop application. In one of the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH#Projects_developed_in_wxRuby previous] articles, an official 2008 Ruby GUI Survey was referenced to discuss the popularity of available GUI toolkits. For a quick recap, here is the result for the question "''Which of the GUI toolkits do you currently use, and which do you think it's likely you'll use in the future?''"

[[File:Survey_results1.jpg|thumb|Survey Results]]

#Shoes
#Ruby-GNOME2/GTK
#wxRuby
#Ruby-Tk
#Ruby Cocoa/MacRuby
#QtRuby
#JRuby + Swing
#FxRuby
#JRuby + SWT

[https://www.ruby-toolbox.com/categories/GUI_Frameworks The Ruby Toolbox], a website that tracks the popularity of Ruby related tools by usage in open source projects, has a list of several toolkits under its "GUI Frameworks" category. The ranking in current popularity (Feb 2013) of GUI toolkits is as follows:

#Shoes
#FxRuby
#wxRuby
#QtBindings
#Ruby/GTK
#monkeybars
#FFI::Tk

Although this list is not as scientific as the official survey result, it does reflect current project usage quite well, and it shows the general acceptance of a particular toolkit. We can see by comparing the two lists that the most popular toolkits (Shoes, FxRuby, wxRuby, Ruby/GTK) are still relevant today. Shoes has proven to be a popular choice since its creation in 2007. Most of the other toolkits remain stable, judging by the dates of code commits of their respective repository. One main exception is wxRuby. wxRuby has not seen a release since September of 2009 even though wxWidgets, the C++ GUI library which wxRuby is based, is still in active development.

However, even though most of these projects are being maintained, there has not been much growth to the GUI community for Ruby. There's still a very low number of applications that are built using GUI toolkits for Ruby, and many of them are personal projects. A simply Google search for Ruby GUI toolkits will return results that mostly predates 2010.

= Overview of other GUI toolkits =
This section will not attempt to cover the same toolkits that were discussed in the previous articles, as there are simply not enough advancements to them to warrant further discussions. The following toolkits are not the most popular choices for Ruby GUI development, according to [https://www.ruby-toolbox.com/categories/GUI_Frameworks The Ruby Toolbox]. However, by reviewing what theses toolkits have to offer, comparisons can then be made with more popular options by examining their advantages and disadvantages.

== Visual Ruby ==
[http://visualruby.net/ Visual Ruby] is designed to simplify the process of adding a GTK+ windows to Ruby applications. It is also designed to completely integrate with the Glade user interface designer.

=== Installation ===
# Install Ruby 1.9.3
# Install Glade and GTK
# Install
>> gem install visualruby

=== Up and Running ===
To run Visual Ruby, simply run the following command
>> vr

After starting up VR, you will see a list of example projects that you can open and run.

[[File:Visual_ruby_1.png]]

[[File:Visual_ruby_2.png]]

To create a brand new project, simply follow the instructions below:

#Runs Visual Ruby if not already running
#Press "Select Folder" button at the bottom of the project selector ("Open project" if VR is already running to get to the project selector)
#Navigate to the directory to your choice, and press "Create Folder" on the top right with the project name of your choice
#Press "Open", and an new default "Hello World" application will appear

=== Pros and Cons ===
*Pros
**Very easy to set up.
**Available on all three major platforms (Windows, Linux, Mac)
**Integration with Glade visual designer provides another easy option to create layouts

*Cons
**Although it is available on all three platforms, it is obvious that it was made with Linux in mind. Launching anything from VR is essentially running a command, and those commands may not be available on Windows (e.g. selecting a Glade file and launching Glade did not work from within VR. Glade had to run manually).

== Monkeybars ==
[https://github.com/monkeybars/monkeybars-core Monkeybars] is a library that enables the use of [http://en.wikipedia.org/wiki/Swing_%28Java%29 Swing] from [http://en.wikipedia.org/wiki/JRuby JRuby]. JRuby is the Java implementation of the Ruby interpreter. This means Ruby code is executed in the JVM. As you'd expect, JRuby is tightly integrated with Java, and it has the ability to invoke classes of the Java platform. As a result, Swing, the Java GUI toolkit, can be used with JRuby.

Monkeybars aims to allow you to continue using the GUI editing tools (e.g. Netbeans) you are used to but makes it easy to write all your application logic in pure Ruby. It utilizes the Model, View, Controller (MVC) design pattern to separate view logic and user interface components from application logic.[http://monkeybars.rubyforge.org/] It should be noted, however, that Monkeybars should not be the first choice if you're looking to quickly create a GUI application from scratch. The overhead of getting one of these projects up and running will be relatively higher than most of the other libraries.

Monkeybars excels at building large and complex GUI applications since it is based on the mature Java language and Swing libraries. This will be a big advantage if creating non-trivial Swing applications with the logic written in Ruby is what you're looking for.[http://www.ibm.com/developerworks/library/j-monkeybars/index.html]

=== Installation ===
# Install Java and JRuby
# Install Monkeybars

>> gem install rawr
>> gem install monkeybars

=== Up and Running ===
To create a new project directory

>> monkeybars test_project

After creating a new monkeybars project, follow the detailed tutorials [http://monkeybars.org/tutorials.html here] to configure your project.

=== Pros and Cons ===
*Pros
**Easy to install
**Project structure is better suited for large and complex applications

*Cons
**Creating a new project has high overhead
**Requires too much effort for simple GUI applications

== FFI-Tk ==
[https://github.com/manveru/ffi-tk FFI-Tk] is a pure Ruby FFI (foreign funciton interface) wrapper for the Tk GUI toolkit. Since it uses [https://github.com/ffi/ffi/wiki/Why-use-FFI FFI], it is meant to be provided as an extension that doesn't need compilation and is multi-platformed.[https://github.com/ffi/ffi/wiki/Why-use-FFI]

=== Installation ===

gem install ffi-tk

=== Up and Running ===
# Sample code taken from https://github.com/manveru/ffi-tk
require 'ffi-tk'
Tk.init
Tk::Button.new('.', text: 'Press me'){
Tk.message_box(message: 'Hello, World!')
}.pack
Tk.mainloop

=== Pros and Cons ===
*Pros
**Easy to use for simple applications
**Eliminates different ways of coding to achieve the same result

*Cons
**Still uses the TK GUI styling, which is the main complain about TK anyways

= Conclusion =
Although there are many toolkits available for building GUI applications with Ruby, there hasn't been much growth in this area relative to 2010. One possible explanation is that the popularity of desktop application develop has yielded to web applications, which Ruby is most well known for due to its Rails framework. By looking at the several toolkits examined above, we can also see why some of them remain to be less popular than others. Monkeybars, for example, has too much overhead just to get an application up and running. The more dependencies, the heavier the toolkit feels. FFI::TK, on the other hand, does not offer any more features than others to warrant popular use. It does seem, however, several of the most popular options will continue to be stable projects. One example is Shoes. Shoes is currently at version 3, and a new version is coming soon. Shoes 4 will be the next version of Shoes[https://github.com/shoes/shoes4]. Perhaps this is why the [http://shoesrb.com/downloads download] page for Shoes is currently void of any content.

= External Links =
*[https://www.ruby-toolbox.com/categories/GUI_Frameworks The Ruby Toolbox GUI Frameworks]
*[http://visualruby.net/ Visual Ruby Homepage]
*[https://github.com/monkeybars/monkeybars-core Monkeybars GitHub Page]
*[https://github.com/manveru/ffi-tk FFI-Tk GitHub Page]

= References =
[1] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH Previous Submission 1] 
[2] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_MM Previous Submission 2] 
[3] [http://monkeybars.rubyforge.org/ Monkeybars Homepage] 
[4] [http://www.ibm.com/developerworks/library/j-monkeybars/index.html The monkeybars library] 
[5] [http://shoesrb.com/downloads Shoes 4 Github Page]

CSC/ECE 517 Spring 2013/ch1a c ct

2013-02-15T17:54:49Z

Ctsui: /* Conclusion */

__TOC__

== Introduction ==
[https://docs.google.com/a/ncsu.edu/document/d/1czn14Zpte-kVHdcb5BUIkpI6wRcABH246jGCg9vncQA/edit#heading=h.8hxo5kudhpn2 Topic Writeup]

Ruby as a programming language has gained popularity in recent years (mainly due to the Rails web framework). There exists quite a few graphical user interface toolkits/frameworks for Ruby so that desktop GUI applications can be created. Most are simply bindings to existing GUI framework API's like Qt and GTK+, so they may seem awkward and unfitting to the Ruby language's style. Shoes, on the other hand, is written for Ruby specifically. Two previous articles have made detailed comparisons between different toolkits by looking at various factors such as ease of installation, documentation, look and feel, and difficulty of usage.[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH][http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_MM] This article will give updates on GUI toolkits that has developed since the previous articles were written, as well as discuss other toolkits that were not present in the previous articles.

== Current State of GUI Toolkits for Ruby ==

There is a number of Ruby GUI toolkits to choose from to create a desktop application. In one of the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH#Projects_developed_in_wxRuby previous] articles, an official 2008 Ruby GUI Survey was referenced to discuss the popularity of available GUI toolkits. For a quick recap, here is the result for the question "''Which of the GUI toolkits do you currently use, and which do you think it's likely you'll use in the future?''"

[[File:Survey_results1.jpg|thumb|Survey Results]]

#Shoes
#Ruby-GNOME2/GTK
#wxRuby
#Ruby-Tk
#Ruby Cocoa/MacRuby
#QtRuby
#JRuby + Swing
#FxRuby
#JRuby + SWT

[https://www.ruby-toolbox.com/categories/GUI_Frameworks The Ruby Toolbox], a website that tracks the popularity of Ruby related tools by usage in open source projects, has a list of several toolkits under its "GUI Frameworks" category. The ranking in current popularity (Feb 2013) of GUI toolkits is as follows:

#Shoes
#FxRuby
#wxRuby
#QtBindings
#Ruby/GTK
#monkeybars
#FFI::Tk

Although this list is not as scientific as the official survey result, it does reflect current project usage quite well, and it shows the general acceptance of a particular toolkit. We can see by comparing the two lists that the most popular toolkits (Shoes, FxRuby, wxRuby, Ruby/GTK) are still relevant today. Shoes has proven to be a popular choice since its creation in 2007. Most of the other toolkits remain stable, judging by the dates of code commits of their respective repository. One main exception is wxRuby. wxRuby has not seen a release since September of 2009 even though wxWidgets, the C++ GUI library which wxRuby is based, is still in active development.

However, even though most of these projects are being maintained, there has not been much growth to the GUI community for Ruby. There's still a very low number of applications that are built using GUI toolkits for Ruby, and many of them are personal projects. A simply Google search for Ruby GUI toolkits will return results that mostly predates 2010.

= Overview of other GUI toolkits =
This section will not attempt to cover the same toolkits that were discussed in the previous articles, as there are simply not enough advancements to them to warrant further discussions. The following toolkits are not the most popular choices for Ruby GUI development, according to [https://www.ruby-toolbox.com/categories/GUI_Frameworks The Ruby Toolbox]. However, by reviewing what theses toolkits have to offer, comparisons can then be made with more popular options by examining their advantages and disadvantages.

== Visual Ruby ==
[http://visualruby.net/ Visual Ruby] is designed to simplify the process of adding a GTK+ windows to Ruby applications. It is also designed to completely integrate with the Glade user interface designer.

=== Installation ===
# Install Ruby 1.9.3
# Install Glade and GTK
# Install
>> gem install visualruby

=== Up and Running ===
To run Visual Ruby, simply run the following command
>> vr

After starting up VR, you will see a list of example projects that you can open and run.

[[File:Visual_ruby_1.png]]
[[File:Visual_ruby_2.png]]

To create a brand new project, simply follow the instructions below:

#Runs Visual Ruby if not already running
#Press "Select Folder" button at the bottom of the project selector ("Open project" if VR is already running to get to the project selector)
#Navigate to the directory to your choice, and press "Create Folder" on the top right with the project name of your choice
#Press "Open", and an new default "Hello World" application will appear

=== Pros and Cons ===
*Pros
**Very easy to set up.
**Available on all three major platforms (Windows, Linux, Mac)
**Integration with Glade visual designer provides another easy option to create layouts

*Cons
**Although it is available on all three platforms, it is obvious that it was made with Linux in mind. Launching anything from VR is essentially running a command, and those commands may not be available on Windows (e.g. selecting a Glade file and launching Glade did not work from within VR. Glade had to run manually).

== Monkeybars ==
[https://github.com/monkeybars/monkeybars-core Monkeybars] is a library that enables the use of [http://en.wikipedia.org/wiki/Swing_%28Java%29 Swing] from [http://en.wikipedia.org/wiki/JRuby JRuby]. JRuby is the Java implementation of the Ruby interpreter. This means Ruby code is executed in the JVM. As you'd expect, JRuby is tightly integrated with Java, and it has the ability to invoke classes of the Java platform. As a result, Swing, the Java GUI toolkit, can be used with JRuby.

Monkeybars aims to allow you to continue using the GUI editing tools (e.g. Netbeans) you are used to but makes it easy to write all your application logic in pure Ruby. It utilizes the Model, View, Controller (MVC) design pattern to separate view logic and user interface components from application logic.[http://monkeybars.rubyforge.org/] It should be noted, however, that Monkeybars should not be the first choice if you're looking to quickly create a GUI application from scratch. The overhead of getting one of these projects up and running will be relatively higher than most of the other libraries.

Monkeybars excels at building large and complex GUI applications since it is based on the mature Java language and Swing libraries. This will be a big advantage if creating non-trivial Swing applications with the logic written in Ruby is what you're looking for.[http://www.ibm.com/developerworks/library/j-monkeybars/index.html]

=== Installation ===
# Install Java and JRuby
# Install Monkeybars

>> gem install rawr
>> gem install monkeybars

=== Up and Running ===
To create a new project directory

>> monkeybars test_project

After creating a new monkeybars project, follow the detailed tutorials [http://monkeybars.org/tutorials.html here] to configure your project.

=== Pros and Cons ===
*Pros
**Easy to install
**Project structure is better suited for large and complex applications

*Cons
**Creating a new project has high overhead
**Requires too much effort for simple GUI applications

== FFI-Tk ==
[https://github.com/manveru/ffi-tk FFI-Tk] is a pure Ruby FFI (foreign funciton interface) wrapper for the Tk GUI toolkit. Since it uses [https://github.com/ffi/ffi/wiki/Why-use-FFI FFI], it is meant to be provided as an extension that doesn't need compilation and is multi-platformed.[https://github.com/ffi/ffi/wiki/Why-use-FFI]

=== Installation ===

gem install ffi-tk

=== Up and Running ===
# Sample code taken from https://github.com/manveru/ffi-tk
require 'ffi-tk'
Tk.init
Tk::Button.new('.', text: 'Press me'){
Tk.message_box(message: 'Hello, World!')
}.pack
Tk.mainloop

=== Pros and Cons ===
*Pros
**Easy to use for simple applications
**Eliminates different ways of coding to achieve the same result

*Cons
**Still uses the TK GUI styling, which is the main complain about TK anyways

== Conclusion ==
Although there are many toolkits available for building GUI applications with Ruby, there hasn't been much growth in this area relative to 2010. One possible explanation is that the popularity of desktop application develop has yielded to web applications, which Ruby is most well known for due to its Rails framework. By looking at the several toolkits examined above, we can also see why some of them remain to be less popular than others. Monkeybars, for example, has too much overhead just to get an application up and running. The more dependencies, the heavier the toolkit feels. FFI::TK, on the other hand, does not offer any more features than others to warrant popular use. It does seem, however, several of the most popular options will continue to be stable projects. One example is Shoes. Shoes is currently at version 3, and a new version is coming soon. Shoes 4 will be the next version of Shoes[https://github.com/shoes/shoes4]. Perhaps this is why the [http://shoesrb.com/downloads download] page for Shoes is currently void of any content.

== External Links ==
*[https://www.ruby-toolbox.com/categories/GUI_Frameworks The Ruby Toolbox GUI Frameworks]
*[http://visualruby.net/ Visual Ruby Homepage]
*[https://github.com/monkeybars/monkeybars-core Monkeybars GitHub Page]
*[https://github.com/manveru/ffi-tk FFI-Tk GitHub Page]

== References ==
[1] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH Previous Submission 1] 
[2] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_MM Previous Submission 2] 
[3] [http://monkeybars.rubyforge.org/ Monkeybars Homepage] 
[4] [http://www.ibm.com/developerworks/library/j-monkeybars/index.html The monkeybars library] 
[5] [http://shoesrb.com/downloads Shoes 4 Github Page]

CSC/ECE 517 Spring 2013/ch1a c ct

2013-02-15T17:42:00Z

Ctsui: /* Overview of other GUI toolkits */

__TOC__

== Introduction ==
[https://docs.google.com/a/ncsu.edu/document/d/1czn14Zpte-kVHdcb5BUIkpI6wRcABH246jGCg9vncQA/edit#heading=h.8hxo5kudhpn2 Topic Writeup]

Ruby as a programming language has gained popularity in recent years (mainly due to the Rails web framework). There exists quite a few graphical user interface toolkits/frameworks for Ruby so that desktop GUI applications can be created. Most are simply bindings to existing GUI framework API's like Qt and GTK+, so they may seem awkward and unfitting to the Ruby language's style. Shoes, on the other hand, is written for Ruby specifically. Two previous articles have made detailed comparisons between different toolkits by looking at various factors such as ease of installation, documentation, look and feel, and difficulty of usage.[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH][http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_MM] This article will give updates on GUI toolkits that has developed since the previous articles were written, as well as discuss other toolkits that were not present in the previous articles.

== Current State of GUI Toolkits for Ruby ==

There is a number of Ruby GUI toolkits to choose from to create a desktop application. In one of the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH#Projects_developed_in_wxRuby previous] articles, an official 2008 Ruby GUI Survey was referenced to discuss the popularity of available GUI toolkits. For a quick recap, here is the result for the question "''Which of the GUI toolkits do you currently use, and which do you think it's likely you'll use in the future?''"

[[File:Survey_results1.jpg|thumb|Survey Results]]

#Shoes
#Ruby-GNOME2/GTK
#wxRuby
#Ruby-Tk
#Ruby Cocoa/MacRuby
#QtRuby
#JRuby + Swing
#FxRuby
#JRuby + SWT

[https://www.ruby-toolbox.com/categories/GUI_Frameworks The Ruby Toolbox], a website that tracks the popularity of Ruby related tools by usage in open source projects, has a list of several toolkits under its "GUI Frameworks" category. The ranking in current popularity (Feb 2013) of GUI toolkits is as follows:

#Shoes
#FxRuby
#wxRuby
#QtBindings
#Ruby/GTK
#monkeybars
#FFI::Tk

Although this list is not as scientific as the official survey result, it does reflect current project usage quite well, and it shows the general acceptance of a particular toolkit. We can see by comparing the two lists that the most popular toolkits (Shoes, FxRuby, wxRuby, Ruby/GTK) are still relevant today. Shoes has proven to be a popular choice since its creation in 2007. Most of the other toolkits remain stable, judging by the dates of code commits of their respective repository. One main exception is wxRuby. wxRuby has not seen a release since September of 2009 even though wxWidgets, the C++ GUI library which wxRuby is based, is still in active development.

However, even though most of these projects are being maintained, there has not been much growth to the GUI community for Ruby. There's still a very low number of applications that are built using GUI toolkits for Ruby, and many of them are personal projects. A simply Google search for Ruby GUI toolkits will return results that mostly predates 2010.

= Overview of other GUI toolkits =
This section will not attempt to cover the same toolkits that were discussed in the previous articles, as there are simply not enough advancements to them to warrant further discussions. The following toolkits are not the most popular choices for Ruby GUI development, according to [https://www.ruby-toolbox.com/categories/GUI_Frameworks The Ruby Toolbox]. However, by reviewing what theses toolkits have to offer, comparisons can then be made with more popular options by examining their advantages and disadvantages.

== Visual Ruby ==
[http://visualruby.net/ Visual Ruby] is designed to simplify the process of adding a GTK+ windows to Ruby applications. It is also designed to completely integrate with the Glade user interface designer.

=== Installation ===
# Install Ruby 1.9.3
# Install Glade and GTK
# Install
>> gem install visualruby

=== Up and Running ===
To run Visual Ruby, simply run the following command
>> vr

After starting up VR, you will see a list of example projects that you can open and run.

[[File:Visual_ruby_1.png]]
[[File:Visual_ruby_2.png]]

To create a brand new project, simply follow the instructions below:

#Runs Visual Ruby if not already running
#Press "Select Folder" button at the bottom of the project selector ("Open project" if VR is already running to get to the project selector)
#Navigate to the directory to your choice, and press "Create Folder" on the top right with the project name of your choice
#Press "Open", and an new default "Hello World" application will appear

=== Pros and Cons ===
*Pros
**Very easy to set up.
**Available on all three major platforms (Windows, Linux, Mac)
**Integration with Glade visual designer provides another easy option to create layouts

*Cons
**Although it is available on all three platforms, it is obvious that it was made with Linux in mind. Launching anything from VR is essentially running a command, and those commands may not be available on Windows (e.g. selecting a Glade file and launching Glade did not work from within VR. Glade had to run manually).

== Monkeybars ==
[https://github.com/monkeybars/monkeybars-core Monkeybars] is a library that enables the use of [http://en.wikipedia.org/wiki/Swing_%28Java%29 Swing] from [http://en.wikipedia.org/wiki/JRuby JRuby]. JRuby is the Java implementation of the Ruby interpreter. This means Ruby code is executed in the JVM. As you'd expect, JRuby is tightly integrated with Java, and it has the ability to invoke classes of the Java platform. As a result, Swing, the Java GUI toolkit, can be used with JRuby.

Monkeybars aims to allow you to continue using the GUI editing tools (e.g. Netbeans) you are used to but makes it easy to write all your application logic in pure Ruby. It utilizes the Model, View, Controller (MVC) design pattern to separate view logic and user interface components from application logic.[http://monkeybars.rubyforge.org/] It should be noted, however, that Monkeybars should not be the first choice if you're looking to quickly create a GUI application from scratch. The overhead of getting one of these projects up and running will be relatively higher than most of the other libraries.

Monkeybars excels at building large and complex GUI applications since it is based on the mature Java language and Swing libraries. This will be a big advantage if creating non-trivial Swing applications with the logic written in Ruby is what you're looking for.[http://www.ibm.com/developerworks/library/j-monkeybars/index.html]

=== Installation ===
# Install Java and JRuby
# Install Monkeybars

>> gem install rawr
>> gem install monkeybars

=== Up and Running ===
To create a new project directory

>> monkeybars test_project

After creating a new monkeybars project, follow the detailed tutorials [http://monkeybars.org/tutorials.html here] to configure your project.

=== Pros and Cons ===
*Pros
**Easy to install
**Project structure is better suited for large and complex applications

*Cons
**Creating a new project has high overhead
**Requires too much effort for simple GUI applications

== FFI-Tk ==
[https://github.com/manveru/ffi-tk FFI-Tk] is a pure Ruby FFI (foreign funciton interface) wrapper for the Tk GUI toolkit. Since it uses [https://github.com/ffi/ffi/wiki/Why-use-FFI FFI], it is meant to be provided as an extension that doesn't need compilation and is multi-platformed.[https://github.com/ffi/ffi/wiki/Why-use-FFI]

=== Installation ===

gem install ffi-tk

=== Up and Running ===
# Sample code taken from https://github.com/manveru/ffi-tk
require 'ffi-tk'
Tk.init
Tk::Button.new('.', text: 'Press me'){
Tk.message_box(message: 'Hello, World!')
}.pack
Tk.mainloop

=== Pros and Cons ===
*Pros
**Easy to use for simple applications
**Eliminates different ways of coding to achieve the same result

*Cons
**Still uses the TK GUI styling, which is the main complain about TK anyways

== Conclusion ==
Although there are many toolkits available for building GUI applications with Ruby, there hasn't been much growth in this area relative to 2010. One possible explanation is that the popularity of desktop application develop has yielded to web applications, which Ruby is most well known for due to it's Rails framework. By looking at the several toolkits examined above, we can also see why some of them remain to be less popular than others. Monkeybars, for example, has too much overhead just to get an application up and running. The more dependencies that are necessary, the heavier the toolkit feels. It does seem, however, that the more popular options will continue to be stable projects. One example is Shoes. Shoes is currently at version 3, and a new version is coming soon. Shoes 4 will be the next version of Shoes[https://github.com/shoes/shoes4]. Perhaps this is why the [http://shoesrb.com/downloads download] page for Shoes is currently void of any content.

== External Links ==
*[https://www.ruby-toolbox.com/categories/GUI_Frameworks The Ruby Toolbox GUI Frameworks]
*[http://visualruby.net/ Visual Ruby Homepage]
*[https://github.com/monkeybars/monkeybars-core Monkeybars GitHub Page]
*[https://github.com/manveru/ffi-tk FFI-Tk GitHub Page]

== References ==
[1] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH Previous Submission 1] 
[2] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_MM Previous Submission 2] 
[3] [http://monkeybars.rubyforge.org/ Monkeybars Homepage] 
[4] [http://www.ibm.com/developerworks/library/j-monkeybars/index.html The monkeybars library] 
[5] [http://shoesrb.com/downloads Shoes 4 Github Page]

CSC/ECE 517 Spring 2013/ch1a c ct

2013-02-15T17:28:25Z

Ctsui: /* FFI-Tk */

__TOC__

== Introduction ==
[https://docs.google.com/a/ncsu.edu/document/d/1czn14Zpte-kVHdcb5BUIkpI6wRcABH246jGCg9vncQA/edit#heading=h.8hxo5kudhpn2 Topic Writeup]

Ruby as a programming language has gained popularity in recent years (mainly due to the Rails web framework). There exists quite a few graphical user interface toolkits/frameworks for Ruby so that desktop GUI applications can be created. Most are simply bindings to existing GUI framework API's like Qt and GTK+, so they may seem awkward and unfitting to the Ruby language's style. Shoes, on the other hand, is written for Ruby specifically. Two previous articles have made detailed comparisons between different toolkits by looking at various factors such as ease of installation, documentation, look and feel, and difficulty of usage.[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH][http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_MM] This article will give updates on GUI toolkits that has developed since the previous articles were written, as well as discuss other toolkits that were not present in the previous articles.

== Current State of GUI Toolkits for Ruby ==

There is a number of Ruby GUI toolkits to choose from to create a desktop application. In one of the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH#Projects_developed_in_wxRuby previous] articles, an official 2008 Ruby GUI Survey was referenced to discuss the popularity of available GUI toolkits. For a quick recap, here is the result for the question "''Which of the GUI toolkits do you currently use, and which do you think it's likely you'll use in the future?''"

[[File:Survey_results1.jpg|thumb|Survey Results]]

#Shoes
#Ruby-GNOME2/GTK
#wxRuby
#Ruby-Tk
#Ruby Cocoa/MacRuby
#QtRuby
#JRuby + Swing
#FxRuby
#JRuby + SWT

[https://www.ruby-toolbox.com/categories/GUI_Frameworks The Ruby Toolbox], a website that tracks the popularity of Ruby related tools by usage in open source projects, has a list of several toolkits under its "GUI Frameworks" category. The ranking in current popularity (Feb 2013) of GUI toolkits is as follows:

#Shoes
#FxRuby
#wxRuby
#QtBindings
#Ruby/GTK
#monkeybars
#FFI::Tk

Although this list is not as scientific as the official survey result, it does reflect current project usage quite well, and it shows the general acceptance of a particular toolkit. We can see by comparing the two lists that the most popular toolkits (Shoes, FxRuby, wxRuby, Ruby/GTK) are still relevant today. Shoes has proven to be a popular choice since its creation in 2007. Most of the other toolkits remain stable, judging by the dates of code commits of their respective repository. One main exception is wxRuby. wxRuby has not seen a release since September of 2009 even though wxWidgets, the C++ GUI library which wxRuby is based, is still in active development.

However, even though most of these projects are being maintained, there has not been much growth to the GUI community for Ruby. There's still a very low number of applications that are built using GUI toolkits for Ruby, and many of them are personal projects. A simply Google search for Ruby GUI toolkits will return results that mostly predates 2010.

== Overview of other GUI toolkits ==
This section will not attempt to cover the same toolkits that were discussed in the previous articles, as there are simply not enough advancements to them to warrant further discussions. The following toolkits are not the most popular choices for Ruby GUI development, according to [https://www.ruby-toolbox.com/categories/GUI_Frameworks The Ruby Toolbox]. However, by reviewing what theses toolkits have to offer, comparisons can then be made with more popular options by examining their advantages and disadvantages.

=== Visual Ruby ===
[http://visualruby.net/ Visual Ruby] is designed to simplify the process of adding a GTK+ windows to Ruby applications. It is also designed to completely integrate with the Glade user interface designer.

==== Installation ====
# Install Ruby 1.9.3
# Install Glade and GTK
# Install
>> gem install visualruby

==== Up and Running ====
To run Visual Ruby, simply run the following command
>> vr

After starting up VR, you will see a list of example projects that you can open and run.

[[File:Visual_ruby_1.png]]
[[File:Visual_ruby_2.png]]

To create a brand new project, simply follow the instructions below:

#Runs Visual Ruby if not already running
#Press "Select Folder" button at the bottom of the project selector ("Open project" if VR is already running to get to the project selector)
#Navigate to the directory to your choice, and press "Create Folder" on the top right with the project name of your choice
#Press "Open", and an new default "Hello World" application will appear

==== Pros and Cons ====
*Pros
**Very easy to set up.
**Available on all three major platforms (Windows, Linux, Mac)
**Integration with Glade visual designer provides another easy option to create layouts

*Cons
**Although it is available on all three platforms, it is obvious that it was made with Linux in mind. Launching anything from VR is essentially running a command, and those commands may not be available on Windows (e.g. selecting a Glade file and launching Glade did not work from within VR. Glade had to run manually).

=== Monkeybars ===
[https://github.com/monkeybars/monkeybars-core Monkeybars] is a library that enables the use of [http://en.wikipedia.org/wiki/Swing_%28Java%29 Swing] from [http://en.wikipedia.org/wiki/JRuby JRuby]. JRuby is the Java implementation of the Ruby interpreter. This means Ruby code is executed in the JVM. As you'd expect, JRuby is tightly integrated with Java, and it has the ability to invoke classes of the Java platform. As a result, Swing, the Java GUI toolkit, can be used with JRuby.

Monkeybars aims to allow you to continue using the GUI editing tools (e.g. Netbeans) you are used to but makes it easy to write all your application logic in pure Ruby. It utilizes the Model, View, Controller (MVC) design pattern to separate view logic and user interface components from application logic.[http://monkeybars.rubyforge.org/] It should be noted, however, that Monkeybars should not be the first choice if you're looking to quickly create a GUI application from scratch. The overhead of getting one of these projects up and running will be relatively higher than most of the other libraries.

Monkeybars excels at building large and complex GUI applications since it is based on the mature Java language and Swing libraries. This will be a big advantage if creating non-trivial Swing applications with the logic written in Ruby is what you're looking for.[http://www.ibm.com/developerworks/library/j-monkeybars/index.html]

==== Installation ====
# Install Java and JRuby
# Install Monkeybars

>> gem install rawr
>> gem install monkeybars

==== Up and Running ====
To create a new project directory

>> monkeybars test_project

After creating a new monkeybars project, follow the detailed tutorials [http://monkeybars.org/tutorials.html here] to configure your project.

==== Pros and Cons ====
*Pros
**Easy to install
**Project structure is better suited for large and complex applications

*Cons
**Creating a new project has high overhead
**Requires too much effort for simple GUI applications

=== FFI-Tk ===

[https://github.com/manveru/ffi-tk FFI-Tk] is a pure Ruby FFI (foreign funciton interface) wrapper for the Tk GUI toolkit.

==== Installation ====

gem install ffi-tk

==== Up and Running ====
# Sample code taken from https://github.com/manveru/ffi-tk
require 'ffi-tk'
Tk.init
Tk::Button.new('.', text: 'Press me'){
Tk.message_box(message: 'Hello, World!')
}.pack
Tk.mainloop

==== Pros and Cons ====
*Pros
**Easy to use for simple applications

*Cons
**Has no real advantage over default TK toolkit

== Conclusion ==
Although there are many toolkits available for building GUI applications with Ruby, there hasn't been much growth in this area relative to 2010. One possible explanation is that the popularity of desktop application develop has yielded to web applications, which Ruby is most well known for due to it's Rails framework. By looking at the several toolkits examined above, we can also see why some of them remain to be less popular than others. Monkeybars, for example, has too much overhead just to get an application up and running. The more dependencies that are necessary, the heavier the toolkit feels. It does seem, however, that the more popular options will continue to be stable projects. One example is Shoes. Shoes is currently at version 3, and a new version is coming soon. Shoes 4 will be the next version of Shoes[https://github.com/shoes/shoes4]. Perhaps this is why the [http://shoesrb.com/downloads download] page for Shoes is currently void of any content.

== External Links ==
*[https://www.ruby-toolbox.com/categories/GUI_Frameworks The Ruby Toolbox GUI Frameworks]
*[http://visualruby.net/ Visual Ruby Homepage]
*[https://github.com/monkeybars/monkeybars-core Monkeybars GitHub Page]
*[https://github.com/manveru/ffi-tk FFI-Tk GitHub Page]

== References ==
[1] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH Previous Submission 1] 
[2] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_MM Previous Submission 2] 
[3] [http://monkeybars.rubyforge.org/ Monkeybars Homepage] 
[4] [http://www.ibm.com/developerworks/library/j-monkeybars/index.html The monkeybars library] 
[5] [http://shoesrb.com/downloads Shoes 4 Github Page]

CSC/ECE 517 Spring 2013/ch1a c ct

2013-02-15T17:17:33Z

Ctsui: /* Up and Running */

__TOC__

== Introduction ==
[https://docs.google.com/a/ncsu.edu/document/d/1czn14Zpte-kVHdcb5BUIkpI6wRcABH246jGCg9vncQA/edit#heading=h.8hxo5kudhpn2 Topic Writeup]

Ruby as a programming language has gained popularity in recent years (mainly due to the Rails web framework). There exists quite a few graphical user interface toolkits/frameworks for Ruby so that desktop GUI applications can be created. Most are simply bindings to existing GUI framework API's like Qt and GTK+, so they may seem awkward and unfitting to the Ruby language's style. Shoes, on the other hand, is written for Ruby specifically. Two previous articles have made detailed comparisons between different toolkits by looking at various factors such as ease of installation, documentation, look and feel, and difficulty of usage.[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH][http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_MM] This article will give updates on GUI toolkits that has developed since the previous articles were written, as well as discuss other toolkits that were not present in the previous articles.

== Current State of GUI Toolkits for Ruby ==

There is a number of Ruby GUI toolkits to choose from to create a desktop application. In one of the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH#Projects_developed_in_wxRuby previous] articles, an official 2008 Ruby GUI Survey was referenced to discuss the popularity of available GUI toolkits. For a quick recap, here is the result for the question "''Which of the GUI toolkits do you currently use, and which do you think it's likely you'll use in the future?''"

[[File:Survey_results1.jpg|thumb|Survey Results]]

#Shoes
#Ruby-GNOME2/GTK
#wxRuby
#Ruby-Tk
#Ruby Cocoa/MacRuby
#QtRuby
#JRuby + Swing
#FxRuby
#JRuby + SWT

[https://www.ruby-toolbox.com/categories/GUI_Frameworks The Ruby Toolbox], a website that tracks the popularity of Ruby related tools by usage in open source projects, has a list of several toolkits under its "GUI Frameworks" category. The ranking in current popularity (Feb 2013) of GUI toolkits is as follows:

#Shoes
#FxRuby
#wxRuby
#QtBindings
#Ruby/GTK
#monkeybars
#FFI::Tk

Although this list is not as scientific as the official survey result, it does reflect current project usage quite well, and it shows the general acceptance of a particular toolkit. We can see by comparing the two lists that the most popular toolkits (Shoes, FxRuby, wxRuby, Ruby/GTK) are still relevant today. Shoes has proven to be a popular choice since its creation in 2007. Most of the other toolkits remain stable, judging by the dates of code commits of their respective repository. One main exception is wxRuby. wxRuby has not seen a release since September of 2009 even though wxWidgets, the C++ GUI library which wxRuby is based, is still in active development.

However, even though most of these projects are being maintained, there has not been much growth to the GUI community for Ruby. There's still a very low number of applications that are built using GUI toolkits for Ruby, and many of them are personal projects. A simply Google search for Ruby GUI toolkits will return results that mostly predates 2010.

== Overview of other GUI toolkits ==
This section will not attempt to cover the same toolkits that were discussed in the previous articles, as there are simply not enough advancements to them to warrant further discussions. The following toolkits are not the most popular choices for Ruby GUI development, according to [https://www.ruby-toolbox.com/categories/GUI_Frameworks The Ruby Toolbox]. However, by reviewing what theses toolkits have to offer, comparisons can then be made with more popular options by examining their advantages and disadvantages.

=== Visual Ruby ===
[http://visualruby.net/ Visual Ruby] is designed to simplify the process of adding a GTK+ windows to Ruby applications. It is also designed to completely integrate with the Glade user interface designer.

==== Installation ====
# Install Ruby 1.9.3
# Install Glade and GTK
# Install
>> gem install visualruby

==== Up and Running ====
To run Visual Ruby, simply run the following command
>> vr

After starting up VR, you will see a list of example projects that you can open and run.

[[File:Visual_ruby_1.png]]
[[File:Visual_ruby_2.png]]

To create a brand new project, simply follow the instructions below:

#Runs Visual Ruby if not already running
#Press "Select Folder" button at the bottom of the project selector ("Open project" if VR is already running to get to the project selector)
#Navigate to the directory to your choice, and press "Create Folder" on the top right with the project name of your choice
#Press "Open", and an new default "Hello World" application will appear

==== Pros and Cons ====
*Pros
**Very easy to set up.
**Available on all three major platforms (Windows, Linux, Mac)
**Integration with Glade visual designer provides another easy option to create layouts

*Cons
**Although it is available on all three platforms, it is obvious that it was made with Linux in mind. Launching anything from VR is essentially running a command, and those commands may not be available on Windows (e.g. selecting a Glade file and launching Glade did not work from within VR. Glade had to run manually).

=== Monkeybars ===
[https://github.com/monkeybars/monkeybars-core Monkeybars] is a library that enables the use of [http://en.wikipedia.org/wiki/Swing_%28Java%29 Swing] from [http://en.wikipedia.org/wiki/JRuby JRuby]. JRuby is the Java implementation of the Ruby interpreter. This means Ruby code is executed in the JVM. As you'd expect, JRuby is tightly integrated with Java, and it has the ability to invoke classes of the Java platform. As a result, Swing, the Java GUI toolkit, can be used with JRuby.

Monkeybars aims to allow you to continue using the GUI editing tools (e.g. Netbeans) you are used to but makes it easy to write all your application logic in pure Ruby. It utilizes the Model, View, Controller (MVC) design pattern to separate view logic and user interface components from application logic.[http://monkeybars.rubyforge.org/] It should be noted, however, that Monkeybars should not be the first choice if you're looking to quickly create a GUI application from scratch. The overhead of getting one of these projects up and running will be relatively higher than most of the other libraries.

Monkeybars excels at building large and complex GUI applications since it is based on the mature Java language and Swing libraries. This will be a big advantage if creating non-trivial Swing applications with the logic written in Ruby is what you're looking for.[http://www.ibm.com/developerworks/library/j-monkeybars/index.html]

==== Installation ====
# Install Java and JRuby
# Install Monkeybars

>> gem install rawr
>> gem install monkeybars

==== Up and Running ====
To create a new project directory

>> monkeybars test_project

After creating a new monkeybars project, follow the detailed tutorials [http://monkeybars.org/tutorials.html here] to configure your project.

==== Pros and Cons ====
*Pros
**Easy to install
**Project structure is better suited for large and complex applications

*Cons
**Creating a new project has high overhead
**Requires too much effort for simple GUI applications

=== FFI-Tk ===

[https://github.com/manveru/ffi-tk FFI-Tk] is a pure Ruby FFI (foreign funciton interface) wrapper for the Tk GUI toolkit.

==== Installation ====

gem install ffi-tk

==== Up and Running ====
# Sample code taken from https://github.com/manveru/ffi-tk
require 'ffi-tk'
Tk.init
Tk::Button.new('.', text: 'Press me'){
Tk.message_box(message: 'Hello, World!')
}.pack
Tk.mainloop

== Conclusion ==
Although there are many toolkits available for building GUI applications with Ruby, there hasn't been much growth in this area relative to 2010. One possible explanation is that the popularity of desktop application develop has yielded to web applications, which Ruby is most well known for due to it's Rails framework. By looking at the several toolkits examined above, we can also see why some of them remain to be less popular than others. Monkeybars, for example, has too much overhead just to get an application up and running. The more dependencies that are necessary, the heavier the toolkit feels. It does seem, however, that the more popular options will continue to be stable projects. One example is Shoes. Shoes is currently at version 3, and a new version is coming soon. Shoes 4 will be the next version of Shoes[https://github.com/shoes/shoes4]. Perhaps this is why the [http://shoesrb.com/downloads download] page for Shoes is currently void of any content.

== External Links ==
*[https://www.ruby-toolbox.com/categories/GUI_Frameworks The Ruby Toolbox GUI Frameworks]
*[http://visualruby.net/ Visual Ruby Homepage]
*[https://github.com/monkeybars/monkeybars-core Monkeybars GitHub Page]
*[https://github.com/manveru/ffi-tk FFI-Tk GitHub Page]

== References ==
[1] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH Previous Submission 1] 
[2] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_MM Previous Submission 2] 
[3] [http://monkeybars.rubyforge.org/ Monkeybars Homepage] 
[4] [http://www.ibm.com/developerworks/library/j-monkeybars/index.html The monkeybars library] 
[5] [http://shoesrb.com/downloads Shoes 4 Github Page]

CSC/ECE 517 Spring 2013/ch1a c ct

2013-02-15T17:16:59Z

Ctsui: /* Monkeybars */

__TOC__

== Introduction ==
[https://docs.google.com/a/ncsu.edu/document/d/1czn14Zpte-kVHdcb5BUIkpI6wRcABH246jGCg9vncQA/edit#heading=h.8hxo5kudhpn2 Topic Writeup]

Ruby as a programming language has gained popularity in recent years (mainly due to the Rails web framework). There exists quite a few graphical user interface toolkits/frameworks for Ruby so that desktop GUI applications can be created. Most are simply bindings to existing GUI framework API's like Qt and GTK+, so they may seem awkward and unfitting to the Ruby language's style. Shoes, on the other hand, is written for Ruby specifically. Two previous articles have made detailed comparisons between different toolkits by looking at various factors such as ease of installation, documentation, look and feel, and difficulty of usage.[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH][http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_MM] This article will give updates on GUI toolkits that has developed since the previous articles were written, as well as discuss other toolkits that were not present in the previous articles.

== Current State of GUI Toolkits for Ruby ==

There is a number of Ruby GUI toolkits to choose from to create a desktop application. In one of the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH#Projects_developed_in_wxRuby previous] articles, an official 2008 Ruby GUI Survey was referenced to discuss the popularity of available GUI toolkits. For a quick recap, here is the result for the question "''Which of the GUI toolkits do you currently use, and which do you think it's likely you'll use in the future?''"

[[File:Survey_results1.jpg|thumb|Survey Results]]

#Shoes
#Ruby-GNOME2/GTK
#wxRuby
#Ruby-Tk
#Ruby Cocoa/MacRuby
#QtRuby
#JRuby + Swing
#FxRuby
#JRuby + SWT

[https://www.ruby-toolbox.com/categories/GUI_Frameworks The Ruby Toolbox], a website that tracks the popularity of Ruby related tools by usage in open source projects, has a list of several toolkits under its "GUI Frameworks" category. The ranking in current popularity (Feb 2013) of GUI toolkits is as follows:

#Shoes
#FxRuby
#wxRuby
#QtBindings
#Ruby/GTK
#monkeybars
#FFI::Tk

Although this list is not as scientific as the official survey result, it does reflect current project usage quite well, and it shows the general acceptance of a particular toolkit. We can see by comparing the two lists that the most popular toolkits (Shoes, FxRuby, wxRuby, Ruby/GTK) are still relevant today. Shoes has proven to be a popular choice since its creation in 2007. Most of the other toolkits remain stable, judging by the dates of code commits of their respective repository. One main exception is wxRuby. wxRuby has not seen a release since September of 2009 even though wxWidgets, the C++ GUI library which wxRuby is based, is still in active development.

However, even though most of these projects are being maintained, there has not been much growth to the GUI community for Ruby. There's still a very low number of applications that are built using GUI toolkits for Ruby, and many of them are personal projects. A simply Google search for Ruby GUI toolkits will return results that mostly predates 2010.

== Overview of other GUI toolkits ==
This section will not attempt to cover the same toolkits that were discussed in the previous articles, as there are simply not enough advancements to them to warrant further discussions. The following toolkits are not the most popular choices for Ruby GUI development, according to [https://www.ruby-toolbox.com/categories/GUI_Frameworks The Ruby Toolbox]. However, by reviewing what theses toolkits have to offer, comparisons can then be made with more popular options by examining their advantages and disadvantages.

=== Visual Ruby ===
[http://visualruby.net/ Visual Ruby] is designed to simplify the process of adding a GTK+ windows to Ruby applications. It is also designed to completely integrate with the Glade user interface designer.

==== Installation ====
# Install Ruby 1.9.3
# Install Glade and GTK
# Install
>> gem install visualruby

==== Up and Running ====
To run Visual Ruby, simply run the following command
>> vr

After starting up VR, you will see a list of example projects that you can open and run.

[[File:Visual_ruby_1.png]]
[[File:Visual_ruby_2.png]]

To create a brand new project, simply follow the instructions below:

#Runs Visual Ruby if not already running
#Press "Select Folder" button at the bottom of the project selector ("Open project" if VR is already running to get to the project selector)
#Navigate to the directory to your choice, and press "Create Folder" on the top right with the project name of your choice
#Press "Open", and an new default "Hello World" application will appear

==== Pros and Cons ====
*Pros
**Very easy to set up.
**Available on all three major platforms (Windows, Linux, Mac)
**Integration with Glade visual designer provides another easy option to create layouts

*Cons
**Although it is available on all three platforms, it is obvious that it was made with Linux in mind. Launching anything from VR is essentially running a command, and those commands may not be available on Windows (e.g. selecting a Glade file and launching Glade did not work from within VR. Glade had to run manually).

=== Monkeybars ===
[https://github.com/monkeybars/monkeybars-core Monkeybars] is a library that enables the use of [http://en.wikipedia.org/wiki/Swing_%28Java%29 Swing] from [http://en.wikipedia.org/wiki/JRuby JRuby]. JRuby is the Java implementation of the Ruby interpreter. This means Ruby code is executed in the JVM. As you'd expect, JRuby is tightly integrated with Java, and it has the ability to invoke classes of the Java platform. As a result, Swing, the Java GUI toolkit, can be used with JRuby.

Monkeybars aims to allow you to continue using the GUI editing tools (e.g. Netbeans) you are used to but makes it easy to write all your application logic in pure Ruby. It utilizes the Model, View, Controller (MVC) design pattern to separate view logic and user interface components from application logic.[http://monkeybars.rubyforge.org/] It should be noted, however, that Monkeybars should not be the first choice if you're looking to quickly create a GUI application from scratch. The overhead of getting one of these projects up and running will be relatively higher than most of the other libraries.

Monkeybars excels at building large and complex GUI applications since it is based on the mature Java language and Swing libraries. This will be a big advantage if creating non-trivial Swing applications with the logic written in Ruby is what you're looking for.[http://www.ibm.com/developerworks/library/j-monkeybars/index.html]

==== Installation ====
# Install Java and JRuby
# Install Monkeybars

>> gem install rawr
>> gem install monkeybars

==== Up and Running ====
To create a new project directory

>> monkeybars test_project

After creating a new monkeybars project, follow the detailed tutorials [http://monkeybars.org/tutorials.html here] to configure your project.

==== Pros and Cons ====
*Pros
**Easy to install
**Project structure is better suited for large and complex applications

*Cons
**Creating a new project has high overhead
**Requires too much effort for simple GUI applications

=== FFI-Tk ===

[https://github.com/manveru/ffi-tk FFI-Tk] is a pure Ruby FFI (foreign funciton interface) wrapper for the Tk GUI toolkit.

==== Installation ====

gem install ffi-tk

==== Up and Running ====
require 'ffi-tk'
Tk.init
Tk::Button.new('.', text: 'Press me'){
Tk.message_box(message: 'Hello, World!')
}.pack
Tk.mainloop

== Conclusion ==
Although there are many toolkits available for building GUI applications with Ruby, there hasn't been much growth in this area relative to 2010. One possible explanation is that the popularity of desktop application develop has yielded to web applications, which Ruby is most well known for due to it's Rails framework. By looking at the several toolkits examined above, we can also see why some of them remain to be less popular than others. Monkeybars, for example, has too much overhead just to get an application up and running. The more dependencies that are necessary, the heavier the toolkit feels. It does seem, however, that the more popular options will continue to be stable projects. One example is Shoes. Shoes is currently at version 3, and a new version is coming soon. Shoes 4 will be the next version of Shoes[https://github.com/shoes/shoes4]. Perhaps this is why the [http://shoesrb.com/downloads download] page for Shoes is currently void of any content.

== External Links ==
*[https://www.ruby-toolbox.com/categories/GUI_Frameworks The Ruby Toolbox GUI Frameworks]
*[http://visualruby.net/ Visual Ruby Homepage]
*[https://github.com/monkeybars/monkeybars-core Monkeybars GitHub Page]
*[https://github.com/manveru/ffi-tk FFI-Tk GitHub Page]

== References ==
[1] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH Previous Submission 1] 
[2] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_MM Previous Submission 2] 
[3] [http://monkeybars.rubyforge.org/ Monkeybars Homepage] 
[4] [http://www.ibm.com/developerworks/library/j-monkeybars/index.html The monkeybars library] 
[5] [http://shoesrb.com/downloads Shoes 4 Github Page]

CSC/ECE 517 Spring 2013/ch1a c ct

2013-02-15T17:12:47Z

Ctsui: /* Visual Ruby */

__TOC__

== Introduction ==
[https://docs.google.com/a/ncsu.edu/document/d/1czn14Zpte-kVHdcb5BUIkpI6wRcABH246jGCg9vncQA/edit#heading=h.8hxo5kudhpn2 Topic Writeup]

Ruby as a programming language has gained popularity in recent years (mainly due to the Rails web framework). There exists quite a few graphical user interface toolkits/frameworks for Ruby so that desktop GUI applications can be created. Most are simply bindings to existing GUI framework API's like Qt and GTK+, so they may seem awkward and unfitting to the Ruby language's style. Shoes, on the other hand, is written for Ruby specifically. Two previous articles have made detailed comparisons between different toolkits by looking at various factors such as ease of installation, documentation, look and feel, and difficulty of usage.[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH][http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_MM] This article will give updates on GUI toolkits that has developed since the previous articles were written, as well as discuss other toolkits that were not present in the previous articles.

== Current State of GUI Toolkits for Ruby ==

There is a number of Ruby GUI toolkits to choose from to create a desktop application. In one of the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH#Projects_developed_in_wxRuby previous] articles, an official 2008 Ruby GUI Survey was referenced to discuss the popularity of available GUI toolkits. For a quick recap, here is the result for the question "''Which of the GUI toolkits do you currently use, and which do you think it's likely you'll use in the future?''"

[[File:Survey_results1.jpg|thumb|Survey Results]]

#Shoes
#Ruby-GNOME2/GTK
#wxRuby
#Ruby-Tk
#Ruby Cocoa/MacRuby
#QtRuby
#JRuby + Swing
#FxRuby
#JRuby + SWT

[https://www.ruby-toolbox.com/categories/GUI_Frameworks The Ruby Toolbox], a website that tracks the popularity of Ruby related tools by usage in open source projects, has a list of several toolkits under its "GUI Frameworks" category. The ranking in current popularity (Feb 2013) of GUI toolkits is as follows:

#Shoes
#FxRuby
#wxRuby
#QtBindings
#Ruby/GTK
#monkeybars
#FFI::Tk

Although this list is not as scientific as the official survey result, it does reflect current project usage quite well, and it shows the general acceptance of a particular toolkit. We can see by comparing the two lists that the most popular toolkits (Shoes, FxRuby, wxRuby, Ruby/GTK) are still relevant today. Shoes has proven to be a popular choice since its creation in 2007. Most of the other toolkits remain stable, judging by the dates of code commits of their respective repository. One main exception is wxRuby. wxRuby has not seen a release since September of 2009 even though wxWidgets, the C++ GUI library which wxRuby is based, is still in active development.

However, even though most of these projects are being maintained, there has not been much growth to the GUI community for Ruby. There's still a very low number of applications that are built using GUI toolkits for Ruby, and many of them are personal projects. A simply Google search for Ruby GUI toolkits will return results that mostly predates 2010.

== Overview of other GUI toolkits ==
This section will not attempt to cover the same toolkits that were discussed in the previous articles, as there are simply not enough advancements to them to warrant further discussions. The following toolkits are not the most popular choices for Ruby GUI development, according to [https://www.ruby-toolbox.com/categories/GUI_Frameworks The Ruby Toolbox]. However, by reviewing what theses toolkits have to offer, comparisons can then be made with more popular options by examining their advantages and disadvantages.

=== Visual Ruby ===
[http://visualruby.net/ Visual Ruby] is designed to simplify the process of adding a GTK+ windows to Ruby applications. It is also designed to completely integrate with the Glade user interface designer.

==== Installation ====
# Install Ruby 1.9.3
# Install Glade and GTK
# Install
>> gem install visualruby

==== Up and Running ====
To run Visual Ruby, simply run the following command
>> vr

After starting up VR, you will see a list of example projects that you can open and run.

[[File:Visual_ruby_1.png]]
[[File:Visual_ruby_2.png]]

To create a brand new project, simply follow the instructions below:

#Runs Visual Ruby if not already running
#Press "Select Folder" button at the bottom of the project selector ("Open project" if VR is already running to get to the project selector)
#Navigate to the directory to your choice, and press "Create Folder" on the top right with the project name of your choice
#Press "Open", and an new default "Hello World" application will appear

==== Pros and Cons ====
*Pros
**Very easy to set up.
**Available on all three major platforms (Windows, Linux, Mac)
**Integration with Glade visual designer provides another easy option to create layouts

*Cons
**Although it is available on all three platforms, it is obvious that it was made with Linux in mind. Launching anything from VR is essentially running a command, and those commands may not be available on Windows (e.g. selecting a Glade file and launching Glade did not work from within VR. Glade had to run manually).

=== Monkeybars ===
[https://github.com/monkeybars/monkeybars-core Monkeybars] is a library that enables the use of [http://en.wikipedia.org/wiki/Swing_%28Java%29 Swing] from [http://en.wikipedia.org/wiki/JRuby JRuby]. JRuby is the Java implementation of the Ruby interpreter. This means Ruby code is executed in the JVM. As you'd expect, JRuby is tightly integrated with Java, and it has the ability to invoke classes of the Java platform. As a result, Swing, the Java GUI toolkit, can be used with JRuby.

Monkeybars aims to allow you to continue using the GUI editing tools (e.g. Netbeans) you are used to but makes it easy to write all your application logic in pure Ruby. It utilizes the Model, View, Controller (MVC) design pattern to separate view logic and user interface components from application logic.[http://monkeybars.rubyforge.org/]

It should be noted, however, that Monkeybars should not be the first choice if you're looking to quickly create a GUI application from scratch. The overhead of getting one of these projects up and running will be relatively higher than most of the other libraries.

Monkeybars excels at building large and complex GUI applications since it is based on the mature Java language and Swing libraries. This will be a big advantage if creating non-trivial Swing applications with the logic written in Ruby is what you're looking for.[http://www.ibm.com/developerworks/library/j-monkeybars/index.html]

==== Installation ====
# Install Java and JRuby
# Install Monkeybars

>> gem install rawr
>> gem install monkeybars

==== Up and Running ====
To create a new project directory

>> monkeybars test_project

After creating a new monkeybars project, follow the detailed tutorials [http://monkeybars.org/tutorials.html here] to configure your project.

=== FFI-Tk ===

[https://github.com/manveru/ffi-tk FFI-Tk] is a pure Ruby FFI (foreign funciton interface) wrapper for the Tk GUI toolkit.

==== Installation ====

gem install ffi-tk

==== Up and Running ====
require 'ffi-tk'
Tk.init
Tk::Button.new('.', text: 'Press me'){
Tk.message_box(message: 'Hello, World!')
}.pack
Tk.mainloop

== Conclusion ==
Although there are many toolkits available for building GUI applications with Ruby, there hasn't been much growth in this area relative to 2010. One possible explanation is that the popularity of desktop application develop has yielded to web applications, which Ruby is most well known for due to it's Rails framework. By looking at the several toolkits examined above, we can also see why some of them remain to be less popular than others. Monkeybars, for example, has too much overhead just to get an application up and running. The more dependencies that are necessary, the heavier the toolkit feels. It does seem, however, that the more popular options will continue to be stable projects. One example is Shoes. Shoes is currently at version 3, and a new version is coming soon. Shoes 4 will be the next version of Shoes[https://github.com/shoes/shoes4]. Perhaps this is why the [http://shoesrb.com/downloads download] page for Shoes is currently void of any content.

== External Links ==
*[https://www.ruby-toolbox.com/categories/GUI_Frameworks The Ruby Toolbox GUI Frameworks]
*[http://visualruby.net/ Visual Ruby Homepage]
*[https://github.com/monkeybars/monkeybars-core Monkeybars GitHub Page]
*[https://github.com/manveru/ffi-tk FFI-Tk GitHub Page]

== References ==
[1] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH Previous Submission 1] 
[2] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_MM Previous Submission 2] 
[3] [http://monkeybars.rubyforge.org/ Monkeybars Homepage] 
[4] [http://www.ibm.com/developerworks/library/j-monkeybars/index.html The monkeybars library] 
[5] [http://shoesrb.com/downloads Shoes 4 Github Page]

CSC/ECE 517 Spring 2013/ch1a c ct

2013-02-15T17:04:34Z

Ctsui: /* Up and Running */

__TOC__

== Introduction ==
[https://docs.google.com/a/ncsu.edu/document/d/1czn14Zpte-kVHdcb5BUIkpI6wRcABH246jGCg9vncQA/edit#heading=h.8hxo5kudhpn2 Topic Writeup]

Ruby as a programming language has gained popularity in recent years (mainly due to the Rails web framework). There exists quite a few graphical user interface toolkits/frameworks for Ruby so that desktop GUI applications can be created. Most are simply bindings to existing GUI framework API's like Qt and GTK+, so they may seem awkward and unfitting to the Ruby language's style. Shoes, on the other hand, is written for Ruby specifically. Two previous articles have made detailed comparisons between different toolkits by looking at various factors such as ease of installation, documentation, look and feel, and difficulty of usage.[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH][http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_MM] This article will give updates on GUI toolkits that has developed since the previous articles were written, as well as discuss other toolkits that were not present in the previous articles.

== Current State of GUI Toolkits for Ruby ==

There is a number of Ruby GUI toolkits to choose from to create a desktop application. In one of the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH#Projects_developed_in_wxRuby previous] articles, an official 2008 Ruby GUI Survey was referenced to discuss the popularity of available GUI toolkits. For a quick recap, here is the result for the question "''Which of the GUI toolkits do you currently use, and which do you think it's likely you'll use in the future?''"

[[File:Survey_results1.jpg|thumb|Survey Results]]

#Shoes
#Ruby-GNOME2/GTK
#wxRuby
#Ruby-Tk
#Ruby Cocoa/MacRuby
#QtRuby
#JRuby + Swing
#FxRuby
#JRuby + SWT

[https://www.ruby-toolbox.com/categories/GUI_Frameworks The Ruby Toolbox], a website that tracks the popularity of Ruby related tools by usage in open source projects, has a list of several toolkits under its "GUI Frameworks" category. The ranking in current popularity (Feb 2013) of GUI toolkits is as follows:

#Shoes
#FxRuby
#wxRuby
#QtBindings
#Ruby/GTK
#monkeybars
#FFI::Tk

Although this list is not as scientific as the official survey result, it does reflect current project usage quite well, and it shows the general acceptance of a particular toolkit. We can see by comparing the two lists that the most popular toolkits (Shoes, FxRuby, wxRuby, Ruby/GTK) are still relevant today. Shoes has proven to be a popular choice since its creation in 2007. Most of the other toolkits remain stable, judging by the dates of code commits of their respective repository. One main exception is wxRuby. wxRuby has not seen a release since September of 2009 even though wxWidgets, the C++ GUI library which wxRuby is based, is still in active development.

However, even though most of these projects are being maintained, there has not been much growth to the GUI community for Ruby. There's still a very low number of applications that are built using GUI toolkits for Ruby, and many of them are personal projects. A simply Google search for Ruby GUI toolkits will return results that mostly predates 2010.

== Overview of other GUI toolkits ==
This section will not attempt to cover the same toolkits that were discussed in the previous articles, as there are simply not enough advancements to them to warrant further discussions. The following toolkits are not the most popular choices for Ruby GUI development, according to [https://www.ruby-toolbox.com/categories/GUI_Frameworks The Ruby Toolbox]. However, by reviewing what theses toolkits have to offer, comparisons can then be made with more popular options by examining their advantages and disadvantages.

=== Visual Ruby ===
[http://visualruby.net/ Visual Ruby] is designed to simplify the process of adding a GTK+ windows to Ruby applications. It is also designed to completely integrate with the Glade user interface designer.

==== Installation ====
# Install Ruby 1.9.3
# Install Glade and GTK
# Install
>> gem install visualruby

==== Up and Running ====
To run Visual Ruby, simply run the following command
>> vr

After starting up VR, you will see a list of example projects that you can open and run.

[[File:Visual_ruby_1.png]]
[[File:Visual_ruby_2.png]]

To create a brand new project, simply follow the instructions below:

#Runs Visual Ruby if not already running
#Press "Select Folder" button at the bottom of the project selector ("Open project" if VR is already running to get to the project selector)
#Navigate to the directory to your choice, and press "Create Folder" on the top right with the project name of your choice
#Press "Open", and an new default "Hello World" application will appear

=== Monkeybars ===
[https://github.com/monkeybars/monkeybars-core Monkeybars] is a library that enables the use of [http://en.wikipedia.org/wiki/Swing_%28Java%29 Swing] from [http://en.wikipedia.org/wiki/JRuby JRuby]. JRuby is the Java implementation of the Ruby interpreter. This means Ruby code is executed in the JVM. As you'd expect, JRuby is tightly integrated with Java, and it has the ability to invoke classes of the Java platform. As a result, Swing, the Java GUI toolkit, can be used with JRuby.

Monkeybars aims to allow you to continue using the GUI editing tools (e.g. Netbeans) you are used to but makes it easy to write all your application logic in pure Ruby. It utilizes the Model, View, Controller (MVC) design pattern to separate view logic and user interface components from application logic.[http://monkeybars.rubyforge.org/]

It should be noted, however, that Monkeybars should not be the first choice if you're looking to quickly create a GUI application from scratch. The overhead of getting one of these projects up and running will be relatively higher than most of the other libraries.

Monkeybars excels at building large and complex GUI applications since it is based on the mature Java language and Swing libraries. This will be a big advantage if creating non-trivial Swing applications with the logic written in Ruby is what you're looking for.[http://www.ibm.com/developerworks/library/j-monkeybars/index.html]

==== Installation ====
# Install Java and JRuby
# Install Monkeybars

>> gem install rawr
>> gem install monkeybars

==== Up and Running ====
To create a new project directory

>> monkeybars test_project

After creating a new monkeybars project, follow the detailed tutorials [http://monkeybars.org/tutorials.html here] to configure your project.

=== FFI-Tk ===

[https://github.com/manveru/ffi-tk FFI-Tk] is a pure Ruby FFI (foreign funciton interface) wrapper for the Tk GUI toolkit.

==== Installation ====

gem install ffi-tk

==== Up and Running ====
require 'ffi-tk'
Tk.init
Tk::Button.new('.', text: 'Press me'){
Tk.message_box(message: 'Hello, World!')
}.pack
Tk.mainloop

== Conclusion ==
Although there are many toolkits available for building GUI applications with Ruby, there hasn't been much growth in this area relative to 2010. One possible explanation is that the popularity of desktop application develop has yielded to web applications, which Ruby is most well known for due to it's Rails framework. By looking at the several toolkits examined above, we can also see why some of them remain to be less popular than others. Monkeybars, for example, has too much overhead just to get an application up and running. The more dependencies that are necessary, the heavier the toolkit feels. It does seem, however, that the more popular options will continue to be stable projects. One example is Shoes. Shoes is currently at version 3, and a new version is coming soon. Shoes 4 will be the next version of Shoes[https://github.com/shoes/shoes4]. Perhaps this is why the [http://shoesrb.com/downloads download] page for Shoes is currently void of any content.

== External Links ==
*[https://www.ruby-toolbox.com/categories/GUI_Frameworks The Ruby Toolbox GUI Frameworks]
*[http://visualruby.net/ Visual Ruby Homepage]
*[https://github.com/monkeybars/monkeybars-core Monkeybars GitHub Page]
*[https://github.com/manveru/ffi-tk FFI-Tk GitHub Page]

== References ==
[1] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH Previous Submission 1] 
[2] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_MM Previous Submission 2] 
[3] [http://monkeybars.rubyforge.org/ Monkeybars Homepage] 
[4] [http://www.ibm.com/developerworks/library/j-monkeybars/index.html The monkeybars library] 
[5] [http://shoesrb.com/downloads Shoes 4 Github Page]

CSC/ECE 517 Spring 2013/ch1a c ct

2013-02-15T17:02:16Z

Ctsui: /* Up and Running */

__TOC__

== Introduction ==
[https://docs.google.com/a/ncsu.edu/document/d/1czn14Zpte-kVHdcb5BUIkpI6wRcABH246jGCg9vncQA/edit#heading=h.8hxo5kudhpn2 Topic Writeup]

Ruby as a programming language has gained popularity in recent years (mainly due to the Rails web framework). There exists quite a few graphical user interface toolkits/frameworks for Ruby so that desktop GUI applications can be created. Most are simply bindings to existing GUI framework API's like Qt and GTK+, so they may seem awkward and unfitting to the Ruby language's style. Shoes, on the other hand, is written for Ruby specifically. Two previous articles have made detailed comparisons between different toolkits by looking at various factors such as ease of installation, documentation, look and feel, and difficulty of usage.[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH][http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_MM] This article will give updates on GUI toolkits that has developed since the previous articles were written, as well as discuss other toolkits that were not present in the previous articles.

== Current State of GUI Toolkits for Ruby ==

There is a number of Ruby GUI toolkits to choose from to create a desktop application. In one of the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH#Projects_developed_in_wxRuby previous] articles, an official 2008 Ruby GUI Survey was referenced to discuss the popularity of available GUI toolkits. For a quick recap, here is the result for the question "''Which of the GUI toolkits do you currently use, and which do you think it's likely you'll use in the future?''"

[[File:Survey_results1.jpg|thumb|Survey Results]]

#Shoes
#Ruby-GNOME2/GTK
#wxRuby
#Ruby-Tk
#Ruby Cocoa/MacRuby
#QtRuby
#JRuby + Swing
#FxRuby
#JRuby + SWT

[https://www.ruby-toolbox.com/categories/GUI_Frameworks The Ruby Toolbox], a website that tracks the popularity of Ruby related tools by usage in open source projects, has a list of several toolkits under its "GUI Frameworks" category. The ranking in current popularity (Feb 2013) of GUI toolkits is as follows:

#Shoes
#FxRuby
#wxRuby
#QtBindings
#Ruby/GTK
#monkeybars
#FFI::Tk

Although this list is not as scientific as the official survey result, it does reflect current project usage quite well, and it shows the general acceptance of a particular toolkit. We can see by comparing the two lists that the most popular toolkits (Shoes, FxRuby, wxRuby, Ruby/GTK) are still relevant today. Shoes has proven to be a popular choice since its creation in 2007. Most of the other toolkits remain stable, judging by the dates of code commits of their respective repository. One main exception is wxRuby. wxRuby has not seen a release since September of 2009 even though wxWidgets, the C++ GUI library which wxRuby is based, is still in active development.

However, even though most of these projects are being maintained, there has not been much growth to the GUI community for Ruby. There's still a very low number of applications that are built using GUI toolkits for Ruby, and many of them are personal projects. A simply Google search for Ruby GUI toolkits will return results that mostly predates 2010.

== Overview of other GUI toolkits ==
This section will not attempt to cover the same toolkits that were discussed in the previous articles, as there are simply not enough advancements to them to warrant further discussions. The following toolkits are not the most popular choices for Ruby GUI development, according to [https://www.ruby-toolbox.com/categories/GUI_Frameworks The Ruby Toolbox]. However, by reviewing what theses toolkits have to offer, comparisons can then be made with more popular options by examining their advantages and disadvantages.

=== Visual Ruby ===
[http://visualruby.net/ Visual Ruby] is designed to simplify the process of adding a GTK+ windows to Ruby applications. It is also designed to completely integrate with the Glade user interface designer.

==== Installation ====
# Install Ruby 1.9.3
# Install Glade and GTK
# Install
>> gem install visualruby

==== Up and Running ====
To run Visual Ruby, simply run the following command
>> vr

After starting up VR, you will see a list of example projects that you can open and run.

[[File:Visual_ruby_1.png]]
[[File:Visual_ruby_2.png]]

To create a new project, simply follow the instructions below:

#Runs Visual Ruby if not already running
#Press "Select Folder" button at the bottom of the project selector ("Open project" if VR is already running to get to the project selector)
#Navigate to the directory to your choice, and press "Create Folder" on the top right with the project name of your choice
#Press "Open", and an new default "Hello World" application will appear

=== Monkeybars ===
[https://github.com/monkeybars/monkeybars-core Monkeybars] is a library that enables the use of [http://en.wikipedia.org/wiki/Swing_%28Java%29 Swing] from [http://en.wikipedia.org/wiki/JRuby JRuby]. JRuby is the Java implementation of the Ruby interpreter. This means Ruby code is executed in the JVM. As you'd expect, JRuby is tightly integrated with Java, and it has the ability to invoke classes of the Java platform. As a result, Swing, the Java GUI toolkit, can be used with JRuby.

Monkeybars aims to allow you to continue using the GUI editing tools (e.g. Netbeans) you are used to but makes it easy to write all your application logic in pure Ruby. It utilizes the Model, View, Controller (MVC) design pattern to separate view logic and user interface components from application logic.[http://monkeybars.rubyforge.org/]

It should be noted, however, that Monkeybars should not be the first choice if you're looking to quickly create a GUI application from scratch. The overhead of getting one of these projects up and running will be relatively higher than most of the other libraries.

Monkeybars excels at building large and complex GUI applications since it is based on the mature Java language and Swing libraries. This will be a big advantage if creating non-trivial Swing applications with the logic written in Ruby is what you're looking for.[http://www.ibm.com/developerworks/library/j-monkeybars/index.html]

==== Installation ====
# Install Java and JRuby
# Install Monkeybars

>> gem install rawr
>> gem install monkeybars

==== Up and Running ====
To create a new project directory

>> monkeybars test_project

After creating a new monkeybars project, follow the detailed tutorials [http://monkeybars.org/tutorials.html here] to configure your project.

=== FFI-Tk ===

[https://github.com/manveru/ffi-tk FFI-Tk] is a pure Ruby FFI (foreign funciton interface) wrapper for the Tk GUI toolkit.

==== Installation ====

gem install ffi-tk

==== Up and Running ====
require 'ffi-tk'
Tk.init
Tk::Button.new('.', text: 'Press me'){
Tk.message_box(message: 'Hello, World!')
}.pack
Tk.mainloop

== Conclusion ==
Although there are many toolkits available for building GUI applications with Ruby, there hasn't been much growth in this area relative to 2010. One possible explanation is that the popularity of desktop application develop has yielded to web applications, which Ruby is most well known for due to it's Rails framework. By looking at the several toolkits examined above, we can also see why some of them remain to be less popular than others. Monkeybars, for example, has too much overhead just to get an application up and running. The more dependencies that are necessary, the heavier the toolkit feels. It does seem, however, that the more popular options will continue to be stable projects. One example is Shoes. Shoes is currently at version 3, and a new version is coming soon. Shoes 4 will be the next version of Shoes[https://github.com/shoes/shoes4]. Perhaps this is why the [http://shoesrb.com/downloads download] page for Shoes is currently void of any content.

== External Links ==
*[https://www.ruby-toolbox.com/categories/GUI_Frameworks The Ruby Toolbox GUI Frameworks]
*[http://visualruby.net/ Visual Ruby Homepage]
*[https://github.com/monkeybars/monkeybars-core Monkeybars GitHub Page]
*[https://github.com/manveru/ffi-tk FFI-Tk GitHub Page]

== References ==
[1] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH Previous Submission 1] 
[2] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_MM Previous Submission 2] 
[3] [http://monkeybars.rubyforge.org/ Monkeybars Homepage] 
[4] [http://www.ibm.com/developerworks/library/j-monkeybars/index.html The monkeybars library] 
[5] [http://shoesrb.com/downloads Shoes 4 Github Page]

CSC/ECE 517 Spring 2013/ch1a c ct

2013-02-14T23:17:25Z

Ctsui: /* Overview of other GUI toolkits */

__TOC__

== Introduction ==
[https://docs.google.com/a/ncsu.edu/document/d/1czn14Zpte-kVHdcb5BUIkpI6wRcABH246jGCg9vncQA/edit#heading=h.8hxo5kudhpn2 Topic Writeup]

Ruby as a programming language has gained popularity in recent years (mainly due to the Rails web framework). There exists quite a few graphical user interface toolkits/frameworks for Ruby so that desktop GUI applications can be created. Most are simply bindings to existing GUI framework API's like Qt and GTK+, so they may seem awkward and unfitting to the Ruby language's style. Shoes, on the other hand, is written for Ruby specifically. Two previous articles have made detailed comparisons between different toolkits by looking at various factors such as ease of installation, documentation, look and feel, and difficulty of usage.[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH][http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_MM] This article will give updates on GUI toolkits that has developed since the previous articles were written, as well as discuss other toolkits that were not present in the previous articles.

== Current State of GUI Toolkits for Ruby ==

There is a number of Ruby GUI toolkits to choose from to create a desktop application. In one of the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH#Projects_developed_in_wxRuby previous] articles, an official 2008 Ruby GUI Survey was referenced to discuss the popularity of available GUI toolkits. For a quick recap, here is the result for the question "''Which of the GUI toolkits do you currently use, and which do you think it's likely you'll use in the future?''"

[[File:Survey_results1.jpg|thumb|Survey Results]]

#Shoes
#Ruby-GNOME2/GTK
#wxRuby
#Ruby-Tk
#Ruby Cocoa/MacRuby
#QtRuby
#JRuby + Swing
#FxRuby
#JRuby + SWT

[https://www.ruby-toolbox.com/categories/GUI_Frameworks The Ruby Toolbox], a website that tracks the popularity of Ruby related tools by usage in open source projects, has a list of several toolkits under its "GUI Frameworks" category. The ranking in current popularity (Feb 2013) of GUI toolkits is as follows:

#Shoes
#FxRuby
#wxRuby
#QtBindings
#Ruby/GTK
#monkeybars
#FFI::Tk

Although this list is not as scientific as the official survey result, it does reflect current project usage quite well, and it shows the general acceptance of a particular toolkit. We can see by comparing the two lists that the most popular toolkits (Shoes, FxRuby, wxRuby, Ruby/GTK) are still relevant today. Shoes has proven to be a popular choice since its creation in 2007. Most of the other toolkits remain stable, judging by the dates of code commits of their respective repository. One main exception is wxRuby. wxRuby has not seen a release since September of 2009 even though wxWidgets, the C++ GUI library which wxRuby is based, is still in active development.

However, even though most of these projects are being maintained, there has not been much growth to the GUI community for Ruby. There's still a very low number of applications that are built using GUI toolkits for Ruby, and many of them are personal projects. A simply Google search for Ruby GUI toolkits will return results that mostly predates 2010.

== Overview of other GUI toolkits ==
This section will not attempt to cover the same toolkits that were discussed in the previous articles, as there are simply not enough advancements to them to warrant further discussions. The following toolkits are not the most popular choices for Ruby GUI development, according to [https://www.ruby-toolbox.com/categories/GUI_Frameworks The Ruby Toolbox]. However, by reviewing what theses toolkits have to offer, comparisons can then be made with more popular options by examining their advantages and disadvantages.

=== Visual Ruby ===
[http://visualruby.net/ Visual Ruby] is designed to simplify the process of adding a GTK+ windows to Ruby applications. It is also designed to completely integrate with the Glade user interface designer.

==== Installation ====
# Install Ruby 1.9.3
# Install Glade and GTK
# Install
>> gem install visualruby

==== Up and Running ====
To run Visual Ruby, simply run the following command
>> vr

After starting up VR, you will see a list of example projects that you can open and run.

[[File:Visual_ruby_1.png]]

[[File:Visual_ruby_2.png]]

=== Monkeybars ===
[https://github.com/monkeybars/monkeybars-core Monkeybars] is a library that enables the use of [http://en.wikipedia.org/wiki/Swing_%28Java%29 Swing] from [http://en.wikipedia.org/wiki/JRuby JRuby]. JRuby is the Java implementation of the Ruby interpreter. This means Ruby code is executed in the JVM. As you'd expect, JRuby is tightly integrated with Java, and it has the ability to invoke classes of the Java platform. As a result, Swing, the Java GUI toolkit, can be used with JRuby.

Monkeybars aims to allow you to continue using the GUI editing tools (e.g. Netbeans) you are used to but makes it easy to write all your application logic in pure Ruby. It utilizes the Model, View, Controller (MVC) design pattern to separate view logic and user interface components from application logic.[http://monkeybars.rubyforge.org/]

It should be noted, however, that Monkeybars should not be the first choice if you're looking to quickly create a GUI application from scratch. The overhead of getting one of these projects up and running will be relatively higher than most of the other libraries.

Monkeybars excels at building large and complex GUI applications since it is based on the mature Java language and Swing libraries. This will be a big advantage if creating non-trivial Swing applications with the logic written in Ruby is what you're looking for.[http://www.ibm.com/developerworks/library/j-monkeybars/index.html]

==== Installation ====
# Install Java and JRuby
# Install Monkeybars

>> gem install rawr
>> gem install monkeybars

==== Up and Running ====
To create a new project directory

>> monkeybars test_project

After creating a new monkeybars project, follow the detailed tutorials [http://monkeybars.org/tutorials.html here] to configure your project.

=== FFI-Tk ===

[https://github.com/manveru/ffi-tk FFI-Tk] is a pure Ruby FFI (foreign funciton interface) wrapper for the Tk GUI toolkit.

==== Installation ====

gem install ffi-tk

==== Up and Running ====
require 'ffi-tk'
Tk.init
Tk::Button.new('.', text: 'Press me'){
Tk.message_box(message: 'Hello, World!')
}.pack
Tk.mainloop

== Conclusion ==
Although there are many toolkits available for building GUI applications with Ruby, there hasn't been much growth in this area relative to 2010. One possible explanation is that the popularity of desktop application develop has yielded to web applications, which Ruby is most well known for due to it's Rails framework. By looking at the several toolkits examined above, we can also see why some of them remain to be less popular than others. Monkeybars, for example, has too much overhead just to get an application up and running. The more dependencies that are necessary, the heavier the toolkit feels. It does seem, however, that the more popular options will continue to be stable projects. One example is Shoes. Shoes is currently at version 3, and a new version is coming soon. Shoes 4 will be the next version of Shoes[https://github.com/shoes/shoes4]. Perhaps this is why the [http://shoesrb.com/downloads download] page for Shoes is currently void of any content.

== External Links ==
*[https://www.ruby-toolbox.com/categories/GUI_Frameworks The Ruby Toolbox GUI Frameworks]
*[http://visualruby.net/ Visual Ruby Homepage]
*[https://github.com/monkeybars/monkeybars-core Monkeybars GitHub Page]
*[https://github.com/manveru/ffi-tk FFI-Tk GitHub Page]

== References ==
[1] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH Previous Submission 1] 
[2] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_MM Previous Submission 2] 
[3] [http://monkeybars.rubyforge.org/ Monkeybars Homepage] 
[4] [http://www.ibm.com/developerworks/library/j-monkeybars/index.html The monkeybars library] 
[5] [http://shoesrb.com/downloads Shoes 4 Github Page]

CSC/ECE 517 Spring 2013/ch1a c ct

2013-02-14T23:10:55Z

Ctsui: /* Monkeybars */

__TOC__

== Introduction ==
[https://docs.google.com/a/ncsu.edu/document/d/1czn14Zpte-kVHdcb5BUIkpI6wRcABH246jGCg9vncQA/edit#heading=h.8hxo5kudhpn2 Topic Writeup]

Ruby as a programming language has gained popularity in recent years (mainly due to the Rails web framework). There exists quite a few graphical user interface toolkits/frameworks for Ruby so that desktop GUI applications can be created. Most are simply bindings to existing GUI framework API's like Qt and GTK+, so they may seem awkward and unfitting to the Ruby language's style. Shoes, on the other hand, is written for Ruby specifically. Two previous articles have made detailed comparisons between different toolkits by looking at various factors such as ease of installation, documentation, look and feel, and difficulty of usage.[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH][http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_MM] This article will give updates on GUI toolkits that has developed since the previous articles were written, as well as discuss other toolkits that were not present in the previous articles.

== Current State of GUI Toolkits for Ruby ==

There is a number of Ruby GUI toolkits to choose from to create a desktop application. In one of the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH#Projects_developed_in_wxRuby previous] articles, an official 2008 Ruby GUI Survey was referenced to discuss the popularity of available GUI toolkits. For a quick recap, here is the result for the question "''Which of the GUI toolkits do you currently use, and which do you think it's likely you'll use in the future?''"

[[File:Survey_results1.jpg|thumb|Survey Results]]

#Shoes
#Ruby-GNOME2/GTK
#wxRuby
#Ruby-Tk
#Ruby Cocoa/MacRuby
#QtRuby
#JRuby + Swing
#FxRuby
#JRuby + SWT

[https://www.ruby-toolbox.com/categories/GUI_Frameworks The Ruby Toolbox], a website that tracks the popularity of Ruby related tools by usage in open source projects, has a list of several toolkits under its "GUI Frameworks" category. The ranking in current popularity (Feb 2013) of GUI toolkits is as follows:

#Shoes
#FxRuby
#wxRuby
#QtBindings
#Ruby/GTK
#monkeybars
#FFI::Tk

Although this list is not as scientific as the official survey result, it does reflect current project usage quite well, and it shows the general acceptance of a particular toolkit. We can see by comparing the two lists that the most popular toolkits (Shoes, FxRuby, wxRuby, Ruby/GTK) are still relevant today. Shoes has proven to be a popular choice since its creation in 2007. Most of the other toolkits remain stable, judging by the dates of code commits of their respective repository. One main exception is wxRuby. wxRuby has not seen a release since September of 2009 even though wxWidgets, the C++ GUI library which wxRuby is based, is still in active development.

However, even though most of these projects are being maintained, there has not been much growth to the GUI community for Ruby. There's still a very low number of applications that are built using GUI toolkits for Ruby, and many of them are personal projects. A simply Google search for Ruby GUI toolkits will return results that mostly predates 2010.

== Overview of other GUI toolkits ==
This article will not attempt to cover the same toolkits that were discussed in the previous articles. The following toolkits are not the most popular choices for Ruby GUI development. However, comparisons can then be made with more popular options by examining the necessary steps to get each one of them up and running

=== Visual Ruby ===
[http://visualruby.net/ Visual Ruby] is designed to simplify the process of adding a GTK+ windows to Ruby applications. It is also designed to completely integrate with the Glade user interface designer.

==== Installation ====
# Install Ruby 1.9.3
# Install Glade and GTK
# Install
>> gem install visualruby

==== Up and Running ====
To run Visual Ruby, simply run the following command
>> vr

After starting up VR, you will see a list of example projects that you can open and run.

[[File:Visual_ruby_1.png]]

[[File:Visual_ruby_2.png]]

=== Monkeybars ===
[https://github.com/monkeybars/monkeybars-core Monkeybars] is a library that enables the use of [http://en.wikipedia.org/wiki/Swing_%28Java%29 Swing] from [http://en.wikipedia.org/wiki/JRuby JRuby]. JRuby is the Java implementation of the Ruby interpreter. This means Ruby code is executed in the JVM. As you'd expect, JRuby is tightly integrated with Java, and it has the ability to invoke classes of the Java platform. As a result, Swing, the Java GUI toolkit, can be used with JRuby.

Monkeybars aims to allow you to continue using the GUI editing tools (e.g. Netbeans) you are used to but makes it easy to write all your application logic in pure Ruby. It utilizes the Model, View, Controller (MVC) design pattern to separate view logic and user interface components from application logic.[http://monkeybars.rubyforge.org/]

It should be noted, however, that Monkeybars should not be the first choice if you're looking to quickly create a GUI application from scratch. The overhead of getting one of these projects up and running will be relatively higher than most of the other libraries.

Monkeybars excels at building large and complex GUI applications since it is based on the mature Java language and Swing libraries. This will be a big advantage if creating non-trivial Swing applications with the logic written in Ruby is what you're looking for.[http://www.ibm.com/developerworks/library/j-monkeybars/index.html]

==== Installation ====
# Install Java and JRuby
# Install Monkeybars

>> gem install rawr
>> gem install monkeybars

==== Up and Running ====
To create a new project directory

>> monkeybars test_project

After creating a new monkeybars project, follow the detailed tutorials [http://monkeybars.org/tutorials.html here] to configure your project.

=== FFI-Tk ===

[https://github.com/manveru/ffi-tk FFI-Tk] is a pure Ruby FFI (foreign funciton interface) wrapper for the Tk GUI toolkit.

==== Installation ====

gem install ffi-tk

==== Up and Running ====
require 'ffi-tk'
Tk.init
Tk::Button.new('.', text: 'Press me'){
Tk.message_box(message: 'Hello, World!')
}.pack
Tk.mainloop

== Conclusion ==
Although there are many toolkits available for building GUI applications with Ruby, there hasn't been much growth in this area relative to 2010. One possible explanation is that the popularity of desktop application develop has yielded to web applications, which Ruby is most well known for due to it's Rails framework. By looking at the several toolkits examined above, we can also see why some of them remain to be less popular than others. Monkeybars, for example, has too much overhead just to get an application up and running. The more dependencies that are necessary, the heavier the toolkit feels. It does seem, however, that the more popular options will continue to be stable projects. One example is Shoes. Shoes is currently at version 3, and a new version is coming soon. Shoes 4 will be the next version of Shoes[https://github.com/shoes/shoes4]. Perhaps this is why the [http://shoesrb.com/downloads download] page for Shoes is currently void of any content.

== External Links ==
*[https://www.ruby-toolbox.com/categories/GUI_Frameworks The Ruby Toolbox GUI Frameworks]
*[http://visualruby.net/ Visual Ruby Homepage]
*[https://github.com/monkeybars/monkeybars-core Monkeybars GitHub Page]
*[https://github.com/manveru/ffi-tk FFI-Tk GitHub Page]

== References ==
[1] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH Previous Submission 1] 
[2] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_MM Previous Submission 2] 
[3] [http://monkeybars.rubyforge.org/ Monkeybars Homepage] 
[4] [http://www.ibm.com/developerworks/library/j-monkeybars/index.html The monkeybars library] 
[5] [http://shoesrb.com/downloads Shoes 4 Github Page]

CSC/ECE 517 Spring 2013/ch1a c ct

2013-02-14T23:08:17Z

Ctsui: /* References */

__TOC__

== Introduction ==
[https://docs.google.com/a/ncsu.edu/document/d/1czn14Zpte-kVHdcb5BUIkpI6wRcABH246jGCg9vncQA/edit#heading=h.8hxo5kudhpn2 Topic Writeup]

Ruby as a programming language has gained popularity in recent years (mainly due to the Rails web framework). There exists quite a few graphical user interface toolkits/frameworks for Ruby so that desktop GUI applications can be created. Most are simply bindings to existing GUI framework API's like Qt and GTK+, so they may seem awkward and unfitting to the Ruby language's style. Shoes, on the other hand, is written for Ruby specifically. Two previous articles have made detailed comparisons between different toolkits by looking at various factors such as ease of installation, documentation, look and feel, and difficulty of usage.[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH][http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_MM] This article will give updates on GUI toolkits that has developed since the previous articles were written, as well as discuss other toolkits that were not present in the previous articles.

== Current State of GUI Toolkits for Ruby ==

There is a number of Ruby GUI toolkits to choose from to create a desktop application. In one of the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH#Projects_developed_in_wxRuby previous] articles, an official 2008 Ruby GUI Survey was referenced to discuss the popularity of available GUI toolkits. For a quick recap, here is the result for the question "''Which of the GUI toolkits do you currently use, and which do you think it's likely you'll use in the future?''"

[[File:Survey_results1.jpg|thumb|Survey Results]]

#Shoes
#Ruby-GNOME2/GTK
#wxRuby
#Ruby-Tk
#Ruby Cocoa/MacRuby
#QtRuby
#JRuby + Swing
#FxRuby
#JRuby + SWT

[https://www.ruby-toolbox.com/categories/GUI_Frameworks The Ruby Toolbox], a website that tracks the popularity of Ruby related tools by usage in open source projects, has a list of several toolkits under its "GUI Frameworks" category. The ranking in current popularity (Feb 2013) of GUI toolkits is as follows:

#Shoes
#FxRuby
#wxRuby
#QtBindings
#Ruby/GTK
#monkeybars
#FFI::Tk

Although this list is not as scientific as the official survey result, it does reflect current project usage quite well, and it shows the general acceptance of a particular toolkit. We can see by comparing the two lists that the most popular toolkits (Shoes, FxRuby, wxRuby, Ruby/GTK) are still relevant today. Shoes has proven to be a popular choice since its creation in 2007. Most of the other toolkits remain stable, judging by the dates of code commits of their respective repository. One main exception is wxRuby. wxRuby has not seen a release since September of 2009 even though wxWidgets, the C++ GUI library which wxRuby is based, is still in active development.

However, even though most of these projects are being maintained, there has not been much growth to the GUI community for Ruby. There's still a very low number of applications that are built using GUI toolkits for Ruby, and many of them are personal projects. A simply Google search for Ruby GUI toolkits will return results that mostly predates 2010.

== Overview of other GUI toolkits ==
This article will not attempt to cover the same toolkits that were discussed in the previous articles. The following toolkits are not the most popular choices for Ruby GUI development. However, comparisons can then be made with more popular options by examining the necessary steps to get each one of them up and running

=== Visual Ruby ===
[http://visualruby.net/ Visual Ruby] is designed to simplify the process of adding a GTK+ windows to Ruby applications. It is also designed to completely integrate with the Glade user interface designer.

==== Installation ====
# Install Ruby 1.9.3
# Install Glade and GTK
# Install
>> gem install visualruby

==== Up and Running ====
To run Visual Ruby, simply run the following command
>> vr

After starting up VR, you will see a list of example projects that you can open and run.

[[File:Visual_ruby_1.png]]

[[File:Visual_ruby_2.png]]

=== Monkeybars ===
[https://github.com/monkeybars/monkeybars-core Monkeybars] is a library that enables the use of [http://en.wikipedia.org/wiki/Swing_%28Java%29 Swing] from [http://en.wikipedia.org/wiki/JRuby JRuby]. JRuby is the Java implementation of the Ruby interpreter. This means Ruby code is executed in the JVM. As you'd expect, JRuby is tightly integrated with Java, and it has the ability to invoke classes of the Java platform. As a result, Swing, the Java GUI toolkit, can be used with JRuby.

Monkeybars aims to allow you to continue using the GUI editing tools you are used to but makes it easy to write all your application logic in pure Ruby. It utilizes the Model, View, Controller (MVC) design pattern to separate view logic and user interface components from application logic.

It should be noted, however, that Monkeybars should not be the first choice if you're looking to quickly create a GUI application from scratch. The overhead of getting one of these projects up and running will be relatively higher than most of the other libraries.

Monkeybars excels at building large and complex GUI applications since it is based on the mature Java language and Swing libraries. It also allows the use of visual designers(e.g. Netbeans) available to create Swing layouts. This will be a big advantage if creating Swing applications with the logic written in Ruby is what you're looking for.[http://monkeybars.rubyforge.org/][http://www.ibm.com/developerworks/library/j-monkeybars/index.html]

==== Installation ====
# Install Java and JRuby
# Install Monkeybars

>> gem install rawr
>> gem install monkeybars

==== Up and Running ====
To create a new project directory

>> monkeybars test_project

After creating a new monkeybars project, follow the detailed tutorials [http://monkeybars.org/tutorials.html here] to configure your project.

=== FFI-Tk ===

[https://github.com/manveru/ffi-tk FFI-Tk] is a pure Ruby FFI (foreign funciton interface) wrapper for the Tk GUI toolkit.

==== Installation ====

gem install ffi-tk

==== Up and Running ====
require 'ffi-tk'
Tk.init
Tk::Button.new('.', text: 'Press me'){
Tk.message_box(message: 'Hello, World!')
}.pack
Tk.mainloop

== Conclusion ==
Although there are many toolkits available for building GUI applications with Ruby, there hasn't been much growth in this area relative to 2010. One possible explanation is that the popularity of desktop application develop has yielded to web applications, which Ruby is most well known for due to it's Rails framework. By looking at the several toolkits examined above, we can also see why some of them remain to be less popular than others. Monkeybars, for example, has too much overhead just to get an application up and running. The more dependencies that are necessary, the heavier the toolkit feels. It does seem, however, that the more popular options will continue to be stable projects. One example is Shoes. Shoes is currently at version 3, and a new version is coming soon. Shoes 4 will be the next version of Shoes[https://github.com/shoes/shoes4]. Perhaps this is why the [http://shoesrb.com/downloads download] page for Shoes is currently void of any content.

== External Links ==
*[https://www.ruby-toolbox.com/categories/GUI_Frameworks The Ruby Toolbox GUI Frameworks]
*[http://visualruby.net/ Visual Ruby Homepage]
*[https://github.com/monkeybars/monkeybars-core Monkeybars GitHub Page]
*[https://github.com/manveru/ffi-tk FFI-Tk GitHub Page]

== References ==
[1] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH Previous Submission 1] 
[2] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_MM Previous Submission 2] 
[3] [http://monkeybars.rubyforge.org/ Monkeybars Homepage] 
[4] [http://www.ibm.com/developerworks/library/j-monkeybars/index.html The monkeybars library] 
[5] [http://shoesrb.com/downloads Shoes 4 Github Page]

CSC/ECE 517 Spring 2013/ch1a c ct

2013-02-14T23:08:03Z

Ctsui: /* References */

__TOC__

== Introduction ==
[https://docs.google.com/a/ncsu.edu/document/d/1czn14Zpte-kVHdcb5BUIkpI6wRcABH246jGCg9vncQA/edit#heading=h.8hxo5kudhpn2 Topic Writeup]

Ruby as a programming language has gained popularity in recent years (mainly due to the Rails web framework). There exists quite a few graphical user interface toolkits/frameworks for Ruby so that desktop GUI applications can be created. Most are simply bindings to existing GUI framework API's like Qt and GTK+, so they may seem awkward and unfitting to the Ruby language's style. Shoes, on the other hand, is written for Ruby specifically. Two previous articles have made detailed comparisons between different toolkits by looking at various factors such as ease of installation, documentation, look and feel, and difficulty of usage.[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH][http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_MM] This article will give updates on GUI toolkits that has developed since the previous articles were written, as well as discuss other toolkits that were not present in the previous articles.

== Current State of GUI Toolkits for Ruby ==

There is a number of Ruby GUI toolkits to choose from to create a desktop application. In one of the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH#Projects_developed_in_wxRuby previous] articles, an official 2008 Ruby GUI Survey was referenced to discuss the popularity of available GUI toolkits. For a quick recap, here is the result for the question "''Which of the GUI toolkits do you currently use, and which do you think it's likely you'll use in the future?''"

[[File:Survey_results1.jpg|thumb|Survey Results]]

#Shoes
#Ruby-GNOME2/GTK
#wxRuby
#Ruby-Tk
#Ruby Cocoa/MacRuby
#QtRuby
#JRuby + Swing
#FxRuby
#JRuby + SWT

[https://www.ruby-toolbox.com/categories/GUI_Frameworks The Ruby Toolbox], a website that tracks the popularity of Ruby related tools by usage in open source projects, has a list of several toolkits under its "GUI Frameworks" category. The ranking in current popularity (Feb 2013) of GUI toolkits is as follows:

#Shoes
#FxRuby
#wxRuby
#QtBindings
#Ruby/GTK
#monkeybars
#FFI::Tk

Although this list is not as scientific as the official survey result, it does reflect current project usage quite well, and it shows the general acceptance of a particular toolkit. We can see by comparing the two lists that the most popular toolkits (Shoes, FxRuby, wxRuby, Ruby/GTK) are still relevant today. Shoes has proven to be a popular choice since its creation in 2007. Most of the other toolkits remain stable, judging by the dates of code commits of their respective repository. One main exception is wxRuby. wxRuby has not seen a release since September of 2009 even though wxWidgets, the C++ GUI library which wxRuby is based, is still in active development.

However, even though most of these projects are being maintained, there has not been much growth to the GUI community for Ruby. There's still a very low number of applications that are built using GUI toolkits for Ruby, and many of them are personal projects. A simply Google search for Ruby GUI toolkits will return results that mostly predates 2010.

== Overview of other GUI toolkits ==
This article will not attempt to cover the same toolkits that were discussed in the previous articles. The following toolkits are not the most popular choices for Ruby GUI development. However, comparisons can then be made with more popular options by examining the necessary steps to get each one of them up and running

=== Visual Ruby ===
[http://visualruby.net/ Visual Ruby] is designed to simplify the process of adding a GTK+ windows to Ruby applications. It is also designed to completely integrate with the Glade user interface designer.

==== Installation ====
# Install Ruby 1.9.3
# Install Glade and GTK
# Install
>> gem install visualruby

==== Up and Running ====
To run Visual Ruby, simply run the following command
>> vr

After starting up VR, you will see a list of example projects that you can open and run.

[[File:Visual_ruby_1.png]]

[[File:Visual_ruby_2.png]]

=== Monkeybars ===
[https://github.com/monkeybars/monkeybars-core Monkeybars] is a library that enables the use of [http://en.wikipedia.org/wiki/Swing_%28Java%29 Swing] from [http://en.wikipedia.org/wiki/JRuby JRuby]. JRuby is the Java implementation of the Ruby interpreter. This means Ruby code is executed in the JVM. As you'd expect, JRuby is tightly integrated with Java, and it has the ability to invoke classes of the Java platform. As a result, Swing, the Java GUI toolkit, can be used with JRuby.

Monkeybars aims to allow you to continue using the GUI editing tools you are used to but makes it easy to write all your application logic in pure Ruby. It utilizes the Model, View, Controller (MVC) design pattern to separate view logic and user interface components from application logic.

It should be noted, however, that Monkeybars should not be the first choice if you're looking to quickly create a GUI application from scratch. The overhead of getting one of these projects up and running will be relatively higher than most of the other libraries.

Monkeybars excels at building large and complex GUI applications since it is based on the mature Java language and Swing libraries. It also allows the use of visual designers(e.g. Netbeans) available to create Swing layouts. This will be a big advantage if creating Swing applications with the logic written in Ruby is what you're looking for.[http://monkeybars.rubyforge.org/][http://www.ibm.com/developerworks/library/j-monkeybars/index.html]

==== Installation ====
# Install Java and JRuby
# Install Monkeybars

>> gem install rawr
>> gem install monkeybars

==== Up and Running ====
To create a new project directory

>> monkeybars test_project

After creating a new monkeybars project, follow the detailed tutorials [http://monkeybars.org/tutorials.html here] to configure your project.

=== FFI-Tk ===

[https://github.com/manveru/ffi-tk FFI-Tk] is a pure Ruby FFI (foreign funciton interface) wrapper for the Tk GUI toolkit.

==== Installation ====

gem install ffi-tk

==== Up and Running ====
require 'ffi-tk'
Tk.init
Tk::Button.new('.', text: 'Press me'){
Tk.message_box(message: 'Hello, World!')
}.pack
Tk.mainloop

== Conclusion ==
Although there are many toolkits available for building GUI applications with Ruby, there hasn't been much growth in this area relative to 2010. One possible explanation is that the popularity of desktop application develop has yielded to web applications, which Ruby is most well known for due to it's Rails framework. By looking at the several toolkits examined above, we can also see why some of them remain to be less popular than others. Monkeybars, for example, has too much overhead just to get an application up and running. The more dependencies that are necessary, the heavier the toolkit feels. It does seem, however, that the more popular options will continue to be stable projects. One example is Shoes. Shoes is currently at version 3, and a new version is coming soon. Shoes 4 will be the next version of Shoes[https://github.com/shoes/shoes4]. Perhaps this is why the [http://shoesrb.com/downloads download] page for Shoes is currently void of any content.

== External Links ==
*[https://www.ruby-toolbox.com/categories/GUI_Frameworks The Ruby Toolbox GUI Frameworks]
*[http://visualruby.net/ Visual Ruby Homepage]
*[https://github.com/monkeybars/monkeybars-core Monkeybars GitHub Page]
*[https://github.com/manveru/ffi-tk FFI-Tk GitHub Page]

== References ==
[1] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH Previous Submission 1] 
[2] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_MM Previous Submission 2] 
[3] [http://monkeybars.rubyforge.org/ Monkeybars Homepage] 
[3] [http://www.ibm.com/developerworks/library/j-monkeybars/index.html The monkeybars library] 
[4] [http://shoesrb.com/downloads Shoes 4 Github Page]

CSC/ECE 517 Spring 2013/ch1a c ct

2013-02-14T23:06:39Z

Ctsui: /* Monkeybars */

__TOC__

== Introduction ==
[https://docs.google.com/a/ncsu.edu/document/d/1czn14Zpte-kVHdcb5BUIkpI6wRcABH246jGCg9vncQA/edit#heading=h.8hxo5kudhpn2 Topic Writeup]

Ruby as a programming language has gained popularity in recent years (mainly due to the Rails web framework). There exists quite a few graphical user interface toolkits/frameworks for Ruby so that desktop GUI applications can be created. Most are simply bindings to existing GUI framework API's like Qt and GTK+, so they may seem awkward and unfitting to the Ruby language's style. Shoes, on the other hand, is written for Ruby specifically. Two previous articles have made detailed comparisons between different toolkits by looking at various factors such as ease of installation, documentation, look and feel, and difficulty of usage.[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH][http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_MM] This article will give updates on GUI toolkits that has developed since the previous articles were written, as well as discuss other toolkits that were not present in the previous articles.

== Current State of GUI Toolkits for Ruby ==

There is a number of Ruby GUI toolkits to choose from to create a desktop application. In one of the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH#Projects_developed_in_wxRuby previous] articles, an official 2008 Ruby GUI Survey was referenced to discuss the popularity of available GUI toolkits. For a quick recap, here is the result for the question "''Which of the GUI toolkits do you currently use, and which do you think it's likely you'll use in the future?''"

[[File:Survey_results1.jpg|thumb|Survey Results]]

#Shoes
#Ruby-GNOME2/GTK
#wxRuby
#Ruby-Tk
#Ruby Cocoa/MacRuby
#QtRuby
#JRuby + Swing
#FxRuby
#JRuby + SWT

[https://www.ruby-toolbox.com/categories/GUI_Frameworks The Ruby Toolbox], a website that tracks the popularity of Ruby related tools by usage in open source projects, has a list of several toolkits under its "GUI Frameworks" category. The ranking in current popularity (Feb 2013) of GUI toolkits is as follows:

#Shoes
#FxRuby
#wxRuby
#QtBindings
#Ruby/GTK
#monkeybars
#FFI::Tk

Although this list is not as scientific as the official survey result, it does reflect current project usage quite well, and it shows the general acceptance of a particular toolkit. We can see by comparing the two lists that the most popular toolkits (Shoes, FxRuby, wxRuby, Ruby/GTK) are still relevant today. Shoes has proven to be a popular choice since its creation in 2007. Most of the other toolkits remain stable, judging by the dates of code commits of their respective repository. One main exception is wxRuby. wxRuby has not seen a release since September of 2009 even though wxWidgets, the C++ GUI library which wxRuby is based, is still in active development.

However, even though most of these projects are being maintained, there has not been much growth to the GUI community for Ruby. There's still a very low number of applications that are built using GUI toolkits for Ruby, and many of them are personal projects. A simply Google search for Ruby GUI toolkits will return results that mostly predates 2010.

== Overview of other GUI toolkits ==
This article will not attempt to cover the same toolkits that were discussed in the previous articles. The following toolkits are not the most popular choices for Ruby GUI development. However, comparisons can then be made with more popular options by examining the necessary steps to get each one of them up and running

=== Visual Ruby ===
[http://visualruby.net/ Visual Ruby] is designed to simplify the process of adding a GTK+ windows to Ruby applications. It is also designed to completely integrate with the Glade user interface designer.

==== Installation ====
# Install Ruby 1.9.3
# Install Glade and GTK
# Install
>> gem install visualruby

==== Up and Running ====
To run Visual Ruby, simply run the following command
>> vr

After starting up VR, you will see a list of example projects that you can open and run.

[[File:Visual_ruby_1.png]]

[[File:Visual_ruby_2.png]]

=== Monkeybars ===
[https://github.com/monkeybars/monkeybars-core Monkeybars] is a library that enables the use of [http://en.wikipedia.org/wiki/Swing_%28Java%29 Swing] from [http://en.wikipedia.org/wiki/JRuby JRuby]. JRuby is the Java implementation of the Ruby interpreter. This means Ruby code is executed in the JVM. As you'd expect, JRuby is tightly integrated with Java, and it has the ability to invoke classes of the Java platform. As a result, Swing, the Java GUI toolkit, can be used with JRuby.

Monkeybars aims to allow you to continue using the GUI editing tools you are used to but makes it easy to write all your application logic in pure Ruby. It utilizes the Model, View, Controller (MVC) design pattern to separate view logic and user interface components from application logic.

It should be noted, however, that Monkeybars should not be the first choice if you're looking to quickly create a GUI application from scratch. The overhead of getting one of these projects up and running will be relatively higher than most of the other libraries.

Monkeybars excels at building large and complex GUI applications since it is based on the mature Java language and Swing libraries. It also allows the use of visual designers(e.g. Netbeans) available to create Swing layouts. This will be a big advantage if creating Swing applications with the logic written in Ruby is what you're looking for.[http://monkeybars.rubyforge.org/][http://www.ibm.com/developerworks/library/j-monkeybars/index.html]

==== Installation ====
# Install Java and JRuby
# Install Monkeybars

>> gem install rawr
>> gem install monkeybars

==== Up and Running ====
To create a new project directory

>> monkeybars test_project

After creating a new monkeybars project, follow the detailed tutorials [http://monkeybars.org/tutorials.html here] to configure your project.

=== FFI-Tk ===

[https://github.com/manveru/ffi-tk FFI-Tk] is a pure Ruby FFI (foreign funciton interface) wrapper for the Tk GUI toolkit.

==== Installation ====

gem install ffi-tk

==== Up and Running ====
require 'ffi-tk'
Tk.init
Tk::Button.new('.', text: 'Press me'){
Tk.message_box(message: 'Hello, World!')
}.pack
Tk.mainloop

== Conclusion ==
Although there are many toolkits available for building GUI applications with Ruby, there hasn't been much growth in this area relative to 2010. One possible explanation is that the popularity of desktop application develop has yielded to web applications, which Ruby is most well known for due to it's Rails framework. By looking at the several toolkits examined above, we can also see why some of them remain to be less popular than others. Monkeybars, for example, has too much overhead just to get an application up and running. The more dependencies that are necessary, the heavier the toolkit feels. It does seem, however, that the more popular options will continue to be stable projects. One example is Shoes. Shoes is currently at version 3, and a new version is coming soon. Shoes 4 will be the next version of Shoes[https://github.com/shoes/shoes4]. Perhaps this is why the [http://shoesrb.com/downloads download] page for Shoes is currently void of any content.

== External Links ==
*[https://www.ruby-toolbox.com/categories/GUI_Frameworks The Ruby Toolbox GUI Frameworks]
*[http://visualruby.net/ Visual Ruby Homepage]
*[https://github.com/monkeybars/monkeybars-core Monkeybars GitHub Page]
*[https://github.com/manveru/ffi-tk FFI-Tk GitHub Page]

== References ==

[1] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH Previous Submission 1]

[2] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_MM Previous Submission 2]

[3] [http://www.ibm.com/developerworks/library/j-monkeybars/index.html The monkeybars library]

[4] [http://shoesrb.com/downloads Shoes 4 Github Page]

CSC/ECE 517 Spring 2013/ch1a c ct

2013-02-14T22:58:55Z

Ctsui: /* Monkeybars */

__TOC__

== Introduction ==
[https://docs.google.com/a/ncsu.edu/document/d/1czn14Zpte-kVHdcb5BUIkpI6wRcABH246jGCg9vncQA/edit#heading=h.8hxo5kudhpn2 Topic Writeup]

Ruby as a programming language has gained popularity in recent years (mainly due to the Rails web framework). There exists quite a few graphical user interface toolkits/frameworks for Ruby so that desktop GUI applications can be created. Most are simply bindings to existing GUI framework API's like Qt and GTK+, so they may seem awkward and unfitting to the Ruby language's style. Shoes, on the other hand, is written for Ruby specifically. Two previous articles have made detailed comparisons between different toolkits by looking at various factors such as ease of installation, documentation, look and feel, and difficulty of usage.[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH][http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_MM] This article will give updates on GUI toolkits that has developed since the previous articles were written, as well as discuss other toolkits that were not present in the previous articles.

== Current State of GUI Toolkits for Ruby ==

There is a number of Ruby GUI toolkits to choose from to create a desktop application. In one of the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH#Projects_developed_in_wxRuby previous] articles, an official 2008 Ruby GUI Survey was referenced to discuss the popularity of available GUI toolkits. For a quick recap, here is the result for the question "''Which of the GUI toolkits do you currently use, and which do you think it's likely you'll use in the future?''"

[[File:Survey_results1.jpg|thumb|Survey Results]]

#Shoes
#Ruby-GNOME2/GTK
#wxRuby
#Ruby-Tk
#Ruby Cocoa/MacRuby
#QtRuby
#JRuby + Swing
#FxRuby
#JRuby + SWT

[https://www.ruby-toolbox.com/categories/GUI_Frameworks The Ruby Toolbox], a website that tracks the popularity of Ruby related tools by usage in open source projects, has a list of several toolkits under its "GUI Frameworks" category. The ranking in current popularity (Feb 2013) of GUI toolkits is as follows:

#Shoes
#FxRuby
#wxRuby
#QtBindings
#Ruby/GTK
#monkeybars
#FFI::Tk

Although this list is not as scientific as the official survey result, it does reflect current project usage quite well, and it shows the general acceptance of a particular toolkit. We can see by comparing the two lists that the most popular toolkits (Shoes, FxRuby, wxRuby, Ruby/GTK) are still relevant today. Shoes has proven to be a popular choice since its creation in 2007. Most of the other toolkits remain stable, judging by the dates of code commits of their respective repository. One main exception is wxRuby. wxRuby has not seen a release since September of 2009 even though wxWidgets, the C++ GUI library which wxRuby is based, is still in active development.

However, even though most of these projects are being maintained, there has not been much growth to the GUI community for Ruby. There's still a very low number of applications that are built using GUI toolkits for Ruby, and many of them are personal projects. A simply Google search for Ruby GUI toolkits will return results that mostly predates 2010.

== Overview of other GUI toolkits ==
This article will not attempt to cover the same toolkits that were discussed in the previous articles. The following toolkits are not the most popular choices for Ruby GUI development. However, comparisons can then be made with more popular options by examining the necessary steps to get each one of them up and running

=== Visual Ruby ===
[http://visualruby.net/ Visual Ruby] is designed to simplify the process of adding a GTK+ windows to Ruby applications. It is also designed to completely integrate with the Glade user interface designer.

==== Installation ====
# Install Ruby 1.9.3
# Install Glade and GTK
# Install
>> gem install visualruby

==== Up and Running ====
To run Visual Ruby, simply run the following command
>> vr

After starting up VR, you will see a list of example projects that you can open and run.

[[File:Visual_ruby_1.png]]

[[File:Visual_ruby_2.png]]

=== Monkeybars ===
[https://github.com/monkeybars/monkeybars-core Monkeybars] is a library that enables the use of [http://en.wikipedia.org/wiki/Swing_%28Java%29 Swing] from [http://en.wikipedia.org/wiki/JRuby JRuby]. JRuby is the Java implementation of the Ruby interpreter. This means Ruby code is executed in the JVM. As you'd expect, JRuby is tightly integrated with Java, and it has the ability to invoke classes of the Java platform. As a result, Swing, the Java GUI toolkit, can be used with JRuby.

Monkeybars aims to allow you to continue using the GUI editing tools you are used to but makes it easy to write all your application logic in pure Ruby. It utilizes the Model, View, Controller (MVC) design pattern to separate view logic and user interface components from application logic.

It should be noted, however, that monkeybars should not be the first choice if you're looking to quickly create a GUI application from scratch. The overhead of getting one of these projects up and running will be relatively higher than some other libraries.

What monkeybars is good for is building large and complex GUI applications since it is based on the mature Java language and Swing libraries. If creating Swing applications with Ruby is what you're looking for, this will be a reasonable choice. [http://www.ibm.com/developerworks/library/j-monkeybars/index.html]

==== Installation ====
# Install Java and JRuby
# Install Monkeybars

>> gem install rawr
>> gem install monkeybars

==== Up and Running ====
To create a new project directory

>> monkeybars test_project

After creating a new monkeybars project, follow the detailed tutorials [http://monkeybars.org/tutorials.html here] to configure your project.

=== FFI-Tk ===

[https://github.com/manveru/ffi-tk FFI-Tk] is a pure Ruby FFI (foreign funciton interface) wrapper for the Tk GUI toolkit.

==== Installation ====

gem install ffi-tk

==== Up and Running ====
require 'ffi-tk'
Tk.init
Tk::Button.new('.', text: 'Press me'){
Tk.message_box(message: 'Hello, World!')
}.pack
Tk.mainloop

== Conclusion ==
Although there are many toolkits available for building GUI applications with Ruby, there hasn't been much growth in this area relative to 2010. One possible explanation is that the popularity of desktop application develop has yielded to web applications, which Ruby is most well known for due to it's Rails framework. By looking at the several toolkits examined above, we can also see why some of them remain to be less popular than others. Monkeybars, for example, has too much overhead just to get an application up and running. The more dependencies that are necessary, the heavier the toolkit feels. It does seem, however, that the more popular options will continue to be stable projects. One example is Shoes. Shoes is currently at version 3, and a new version is coming soon. Shoes 4 will be the next version of Shoes[https://github.com/shoes/shoes4]. Perhaps this is why the [http://shoesrb.com/downloads download] page for Shoes is currently void of any content.

== External Links ==
*[https://www.ruby-toolbox.com/categories/GUI_Frameworks The Ruby Toolbox GUI Frameworks]
*[http://visualruby.net/ Visual Ruby Homepage]
*[https://github.com/monkeybars/monkeybars-core Monkeybars GitHub Page]
*[https://github.com/manveru/ffi-tk FFI-Tk GitHub Page]

== References ==

[1] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH Previous Submission 1]

[2] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_MM Previous Submission 2]

[3] [http://www.ibm.com/developerworks/library/j-monkeybars/index.html The monkeybars library]

[4] [http://shoesrb.com/downloads Shoes 4 Github Page]

CSC/ECE 517 Spring 2013/ch1a c ct

2013-02-14T22:42:01Z

Ctsui: /* External Links */

__TOC__

== Introduction ==
[https://docs.google.com/a/ncsu.edu/document/d/1czn14Zpte-kVHdcb5BUIkpI6wRcABH246jGCg9vncQA/edit#heading=h.8hxo5kudhpn2 Topic Writeup]

Ruby as a programming language has gained popularity in recent years (mainly due to the Rails web framework). There exists quite a few graphical user interface toolkits/frameworks for Ruby so that desktop GUI applications can be created. Most are simply bindings to existing GUI framework API's like Qt and GTK+, so they may seem awkward and unfitting to the Ruby language's style. Shoes, on the other hand, is written for Ruby specifically. Two previous articles have made detailed comparisons between different toolkits by looking at various factors such as ease of installation, documentation, look and feel, and difficulty of usage.[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH][http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_MM] This article will give updates on GUI toolkits that has developed since the previous articles were written, as well as discuss other toolkits that were not present in the previous articles.

== Current State of GUI Toolkits for Ruby ==

There is a number of Ruby GUI toolkits to choose from to create a desktop application. In one of the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH#Projects_developed_in_wxRuby previous] articles, an official 2008 Ruby GUI Survey was referenced to discuss the popularity of available GUI toolkits. For a quick recap, here is the result for the question "''Which of the GUI toolkits do you currently use, and which do you think it's likely you'll use in the future?''"

[[File:Survey_results1.jpg|thumb|Survey Results]]

#Shoes
#Ruby-GNOME2/GTK
#wxRuby
#Ruby-Tk
#Ruby Cocoa/MacRuby
#QtRuby
#JRuby + Swing
#FxRuby
#JRuby + SWT

[https://www.ruby-toolbox.com/categories/GUI_Frameworks The Ruby Toolbox], a website that tracks the popularity of Ruby related tools by usage in open source projects, has a list of several toolkits under its "GUI Frameworks" category. The ranking in current popularity (Feb 2013) of GUI toolkits is as follows:

#Shoes
#FxRuby
#wxRuby
#QtBindings
#Ruby/GTK
#monkeybars
#FFI::Tk

Although this list is not as scientific as the official survey result, it does reflect current project usage quite well, and it shows the general acceptance of a particular toolkit. We can see by comparing the two lists that the most popular toolkits (Shoes, FxRuby, wxRuby, Ruby/GTK) are still relevant today. Shoes has proven to be a popular choice since its creation in 2007. Most of the other toolkits remain stable, judging by the dates of code commits of their respective repository. One main exception is wxRuby. wxRuby has not seen a release since September of 2009 even though wxWidgets, the C++ GUI library which wxRuby is based, is still in active development.

However, even though most of these projects are being maintained, there has not been much growth to the GUI community for Ruby. There's still a very low number of applications that are built using GUI toolkits for Ruby, and many of them are personal projects. A simply Google search for Ruby GUI toolkits will return results that mostly predates 2010.

== Overview of other GUI toolkits ==
This article will not attempt to cover the same toolkits that were discussed in the previous articles. The following toolkits are not the most popular choices for Ruby GUI development. However, comparisons can then be made with more popular options by examining the necessary steps to get each one of them up and running

=== Visual Ruby ===
[http://visualruby.net/ Visual Ruby] is designed to simplify the process of adding a GTK+ windows to Ruby applications. It is also designed to completely integrate with the Glade user interface designer.

==== Installation ====
# Install Ruby 1.9.3
# Install Glade and GTK
# Install
>> gem install visualruby

==== Up and Running ====
To run Visual Ruby, simply run the following command
>> vr

After starting up VR, you will see a list of example projects that you can open and run.

[[File:Visual_ruby_1.png]]

[[File:Visual_ruby_2.png]]

=== Monkeybars ===
[https://github.com/monkeybars/monkeybars-core Monkeybars] is a library that enables the use of Swing from JRuby. Monkeybars aims to allow you to continue using the GUI editing tools you are used to but makes it easy to write all your application logic in pure Ruby. It utilizes the Model, View, Controller (MVC) design pattern to separate view logic and user interface components from application logic.

It should be noted, however, that monkeybars should not be the first choice if you're looking to quickly create a GUI application from scratch. The overhead of getting one of these projects up and running will be relatively higher than some other libraries.

What monkeybars is good for is building large and complex GUI applications since it is based on the mature Java language and Swing libraries. If creating Swing applications with Ruby is what you're looking for, this will be a reasonable choice. [http://www.ibm.com/developerworks/library/j-monkeybars/index.html]

==== Installation ====
# Install Java and JRuby
# Install Monkeybars

>> gem install rawr
>> gem install monkeybars

==== Up and Running ====
To create a new project directory

>> monkeybars test_project

After creating a new monkeybars project, follow the detailed tutorials [http://monkeybars.org/tutorials.html here] to configure your project.

=== FFI-Tk ===

[https://github.com/manveru/ffi-tk FFI-Tk] is a pure Ruby FFI (foreign funciton interface) wrapper for the Tk GUI toolkit.

==== Installation ====

gem install ffi-tk

==== Up and Running ====
require 'ffi-tk'
Tk.init
Tk::Button.new('.', text: 'Press me'){
Tk.message_box(message: 'Hello, World!')
}.pack
Tk.mainloop

== Conclusion ==
Although there are many toolkits available for building GUI applications with Ruby, there hasn't been much growth in this area relative to 2010. One possible explanation is that the popularity of desktop application develop has yielded to web applications, which Ruby is most well known for due to it's Rails framework. By looking at the several toolkits examined above, we can also see why some of them remain to be less popular than others. Monkeybars, for example, has too much overhead just to get an application up and running. The more dependencies that are necessary, the heavier the toolkit feels. It does seem, however, that the more popular options will continue to be stable projects. One example is Shoes. Shoes is currently at version 3, and a new version is coming soon. Shoes 4 will be the next version of Shoes[https://github.com/shoes/shoes4]. Perhaps this is why the [http://shoesrb.com/downloads download] page for Shoes is currently void of any content.

== External Links ==
*[https://www.ruby-toolbox.com/categories/GUI_Frameworks The Ruby Toolbox GUI Frameworks]
*[http://visualruby.net/ Visual Ruby Homepage]
*[https://github.com/monkeybars/monkeybars-core Monkeybars GitHub Page]
*[https://github.com/manveru/ffi-tk FFI-Tk GitHub Page]

== References ==

[1] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH Previous Submission 1]

[2] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_MM Previous Submission 2]

[3] [http://www.ibm.com/developerworks/library/j-monkeybars/index.html The monkeybars library]

[4] [http://shoesrb.com/downloads Shoes 4 Github Page]

CSC/ECE 517 Spring 2013/ch1a c ct

2013-02-14T22:40:54Z

Ctsui: /* External Links */

__TOC__

== Introduction ==
[https://docs.google.com/a/ncsu.edu/document/d/1czn14Zpte-kVHdcb5BUIkpI6wRcABH246jGCg9vncQA/edit#heading=h.8hxo5kudhpn2 Topic Writeup]

Ruby as a programming language has gained popularity in recent years (mainly due to the Rails web framework). There exists quite a few graphical user interface toolkits/frameworks for Ruby so that desktop GUI applications can be created. Most are simply bindings to existing GUI framework API's like Qt and GTK+, so they may seem awkward and unfitting to the Ruby language's style. Shoes, on the other hand, is written for Ruby specifically. Two previous articles have made detailed comparisons between different toolkits by looking at various factors such as ease of installation, documentation, look and feel, and difficulty of usage.[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH][http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_MM] This article will give updates on GUI toolkits that has developed since the previous articles were written, as well as discuss other toolkits that were not present in the previous articles.

== Current State of GUI Toolkits for Ruby ==

There is a number of Ruby GUI toolkits to choose from to create a desktop application. In one of the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH#Projects_developed_in_wxRuby previous] articles, an official 2008 Ruby GUI Survey was referenced to discuss the popularity of available GUI toolkits. For a quick recap, here is the result for the question "''Which of the GUI toolkits do you currently use, and which do you think it's likely you'll use in the future?''"

[[File:Survey_results1.jpg|thumb|Survey Results]]

#Shoes
#Ruby-GNOME2/GTK
#wxRuby
#Ruby-Tk
#Ruby Cocoa/MacRuby
#QtRuby
#JRuby + Swing
#FxRuby
#JRuby + SWT

[https://www.ruby-toolbox.com/categories/GUI_Frameworks The Ruby Toolbox], a website that tracks the popularity of Ruby related tools by usage in open source projects, has a list of several toolkits under its "GUI Frameworks" category. The ranking in current popularity (Feb 2013) of GUI toolkits is as follows:

#Shoes
#FxRuby
#wxRuby
#QtBindings
#Ruby/GTK
#monkeybars
#FFI::Tk

Although this list is not as scientific as the official survey result, it does reflect current project usage quite well, and it shows the general acceptance of a particular toolkit. We can see by comparing the two lists that the most popular toolkits (Shoes, FxRuby, wxRuby, Ruby/GTK) are still relevant today. Shoes has proven to be a popular choice since its creation in 2007. Most of the other toolkits remain stable, judging by the dates of code commits of their respective repository. One main exception is wxRuby. wxRuby has not seen a release since September of 2009 even though wxWidgets, the C++ GUI library which wxRuby is based, is still in active development.

However, even though most of these projects are being maintained, there has not been much growth to the GUI community for Ruby. There's still a very low number of applications that are built using GUI toolkits for Ruby, and many of them are personal projects. A simply Google search for Ruby GUI toolkits will return results that mostly predates 2010.

== Overview of other GUI toolkits ==
This article will not attempt to cover the same toolkits that were discussed in the previous articles. The following toolkits are not the most popular choices for Ruby GUI development. However, comparisons can then be made with more popular options by examining the necessary steps to get each one of them up and running

=== Visual Ruby ===
[http://visualruby.net/ Visual Ruby] is designed to simplify the process of adding a GTK+ windows to Ruby applications. It is also designed to completely integrate with the Glade user interface designer.

==== Installation ====
# Install Ruby 1.9.3
# Install Glade and GTK
# Install
>> gem install visualruby

==== Up and Running ====
To run Visual Ruby, simply run the following command
>> vr

After starting up VR, you will see a list of example projects that you can open and run.

[[File:Visual_ruby_1.png]]

[[File:Visual_ruby_2.png]]

=== Monkeybars ===
[https://github.com/monkeybars/monkeybars-core Monkeybars] is a library that enables the use of Swing from JRuby. Monkeybars aims to allow you to continue using the GUI editing tools you are used to but makes it easy to write all your application logic in pure Ruby. It utilizes the Model, View, Controller (MVC) design pattern to separate view logic and user interface components from application logic.

It should be noted, however, that monkeybars should not be the first choice if you're looking to quickly create a GUI application from scratch. The overhead of getting one of these projects up and running will be relatively higher than some other libraries.

What monkeybars is good for is building large and complex GUI applications since it is based on the mature Java language and Swing libraries. If creating Swing applications with Ruby is what you're looking for, this will be a reasonable choice. [http://www.ibm.com/developerworks/library/j-monkeybars/index.html]

==== Installation ====
# Install Java and JRuby
# Install Monkeybars

>> gem install rawr
>> gem install monkeybars

==== Up and Running ====
To create a new project directory

>> monkeybars test_project

After creating a new monkeybars project, follow the detailed tutorials [http://monkeybars.org/tutorials.html here] to configure your project.

=== FFI-Tk ===

[https://github.com/manveru/ffi-tk FFI-Tk] is a pure Ruby FFI (foreign funciton interface) wrapper for the Tk GUI toolkit.

==== Installation ====

gem install ffi-tk

==== Up and Running ====
require 'ffi-tk'
Tk.init
Tk::Button.new('.', text: 'Press me'){
Tk.message_box(message: 'Hello, World!')
}.pack
Tk.mainloop

== Conclusion ==
Although there are many toolkits available for building GUI applications with Ruby, there hasn't been much growth in this area relative to 2010. One possible explanation is that the popularity of desktop application develop has yielded to web applications, which Ruby is most well known for due to it's Rails framework. By looking at the several toolkits examined above, we can also see why some of them remain to be less popular than others. Monkeybars, for example, has too much overhead just to get an application up and running. The more dependencies that are necessary, the heavier the toolkit feels. It does seem, however, that the more popular options will continue to be stable projects. One example is Shoes. Shoes is currently at version 3, and a new version is coming soon. Shoes 4 will be the next version of Shoes[https://github.com/shoes/shoes4]. Perhaps this is why the [http://shoesrb.com/downloads download] page for Shoes is currently void of any content.

== External Links ==
*[http://visualruby.net/ Visual Ruby Homepage]
*[https://github.com/monkeybars/monkeybars-core Monkeybars GitHub Page]
*[https://github.com/manveru/ffi-tk FFI-Tk GitHub Page]

== References ==

[1] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH Previous Submission 1]

[2] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_MM Previous Submission 2]

[3] [http://www.ibm.com/developerworks/library/j-monkeybars/index.html The monkeybars library]

[4] [http://shoesrb.com/downloads Shoes 4 Github Page]

CSC/ECE 517 Spring 2013/ch1a c ct

2013-02-14T22:40:26Z

Ctsui:

__TOC__

== Introduction ==
[https://docs.google.com/a/ncsu.edu/document/d/1czn14Zpte-kVHdcb5BUIkpI6wRcABH246jGCg9vncQA/edit#heading=h.8hxo5kudhpn2 Topic Writeup]

Ruby as a programming language has gained popularity in recent years (mainly due to the Rails web framework). There exists quite a few graphical user interface toolkits/frameworks for Ruby so that desktop GUI applications can be created. Most are simply bindings to existing GUI framework API's like Qt and GTK+, so they may seem awkward and unfitting to the Ruby language's style. Shoes, on the other hand, is written for Ruby specifically. Two previous articles have made detailed comparisons between different toolkits by looking at various factors such as ease of installation, documentation, look and feel, and difficulty of usage.[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH][http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_MM] This article will give updates on GUI toolkits that has developed since the previous articles were written, as well as discuss other toolkits that were not present in the previous articles.

== Current State of GUI Toolkits for Ruby ==

There is a number of Ruby GUI toolkits to choose from to create a desktop application. In one of the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH#Projects_developed_in_wxRuby previous] articles, an official 2008 Ruby GUI Survey was referenced to discuss the popularity of available GUI toolkits. For a quick recap, here is the result for the question "''Which of the GUI toolkits do you currently use, and which do you think it's likely you'll use in the future?''"

[[File:Survey_results1.jpg|thumb|Survey Results]]

#Shoes
#Ruby-GNOME2/GTK
#wxRuby
#Ruby-Tk
#Ruby Cocoa/MacRuby
#QtRuby
#JRuby + Swing
#FxRuby
#JRuby + SWT

[https://www.ruby-toolbox.com/categories/GUI_Frameworks The Ruby Toolbox], a website that tracks the popularity of Ruby related tools by usage in open source projects, has a list of several toolkits under its "GUI Frameworks" category. The ranking in current popularity (Feb 2013) of GUI toolkits is as follows:

#Shoes
#FxRuby
#wxRuby
#QtBindings
#Ruby/GTK
#monkeybars
#FFI::Tk

Although this list is not as scientific as the official survey result, it does reflect current project usage quite well, and it shows the general acceptance of a particular toolkit. We can see by comparing the two lists that the most popular toolkits (Shoes, FxRuby, wxRuby, Ruby/GTK) are still relevant today. Shoes has proven to be a popular choice since its creation in 2007. Most of the other toolkits remain stable, judging by the dates of code commits of their respective repository. One main exception is wxRuby. wxRuby has not seen a release since September of 2009 even though wxWidgets, the C++ GUI library which wxRuby is based, is still in active development.

However, even though most of these projects are being maintained, there has not been much growth to the GUI community for Ruby. There's still a very low number of applications that are built using GUI toolkits for Ruby, and many of them are personal projects. A simply Google search for Ruby GUI toolkits will return results that mostly predates 2010.

== Overview of other GUI toolkits ==
This article will not attempt to cover the same toolkits that were discussed in the previous articles. The following toolkits are not the most popular choices for Ruby GUI development. However, comparisons can then be made with more popular options by examining the necessary steps to get each one of them up and running

=== Visual Ruby ===
[http://visualruby.net/ Visual Ruby] is designed to simplify the process of adding a GTK+ windows to Ruby applications. It is also designed to completely integrate with the Glade user interface designer.

==== Installation ====
# Install Ruby 1.9.3
# Install Glade and GTK
# Install
>> gem install visualruby

==== Up and Running ====
To run Visual Ruby, simply run the following command
>> vr

After starting up VR, you will see a list of example projects that you can open and run.

[[File:Visual_ruby_1.png]]

[[File:Visual_ruby_2.png]]

=== Monkeybars ===
[https://github.com/monkeybars/monkeybars-core Monkeybars] is a library that enables the use of Swing from JRuby. Monkeybars aims to allow you to continue using the GUI editing tools you are used to but makes it easy to write all your application logic in pure Ruby. It utilizes the Model, View, Controller (MVC) design pattern to separate view logic and user interface components from application logic.

It should be noted, however, that monkeybars should not be the first choice if you're looking to quickly create a GUI application from scratch. The overhead of getting one of these projects up and running will be relatively higher than some other libraries.

What monkeybars is good for is building large and complex GUI applications since it is based on the mature Java language and Swing libraries. If creating Swing applications with Ruby is what you're looking for, this will be a reasonable choice. [http://www.ibm.com/developerworks/library/j-monkeybars/index.html]

==== Installation ====
# Install Java and JRuby
# Install Monkeybars

>> gem install rawr
>> gem install monkeybars

==== Up and Running ====
To create a new project directory

>> monkeybars test_project

After creating a new monkeybars project, follow the detailed tutorials [http://monkeybars.org/tutorials.html here] to configure your project.

=== FFI-Tk ===

[https://github.com/manveru/ffi-tk FFI-Tk] is a pure Ruby FFI (foreign funciton interface) wrapper for the Tk GUI toolkit.

==== Installation ====

gem install ffi-tk

==== Up and Running ====
require 'ffi-tk'
Tk.init
Tk::Button.new('.', text: 'Press me'){
Tk.message_box(message: 'Hello, World!')
}.pack
Tk.mainloop

== Conclusion ==
Although there are many toolkits available for building GUI applications with Ruby, there hasn't been much growth in this area relative to 2010. One possible explanation is that the popularity of desktop application develop has yielded to web applications, which Ruby is most well known for due to it's Rails framework. By looking at the several toolkits examined above, we can also see why some of them remain to be less popular than others. Monkeybars, for example, has too much overhead just to get an application up and running. The more dependencies that are necessary, the heavier the toolkit feels. It does seem, however, that the more popular options will continue to be stable projects. One example is Shoes. Shoes is currently at version 3, and a new version is coming soon. Shoes 4 will be the next version of Shoes[https://github.com/shoes/shoes4]. Perhaps this is why the [http://shoesrb.com/downloads download] page for Shoes is currently void of any content.

== External Links ==
[http://visualruby.net/ Visual Ruby Homepage]
[https://github.com/monkeybars/monkeybars-core Monkeybars GitHub Page]
[https://github.com/manveru/ffi-tk FFI-Tk GitHub Page]

== References ==

[1] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH Previous Submission 1]

[2] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_MM Previous Submission 2]

[3] [http://www.ibm.com/developerworks/library/j-monkeybars/index.html The monkeybars library]

[4] [http://shoesrb.com/downloads Shoes 4 Github Page]

CSC/ECE 517 Spring 2013/ch1a c ct

2013-02-14T22:36:16Z

Ctsui: /* Overview of other GUI toolkits */

__TOC__

== Introduction ==
[https://docs.google.com/a/ncsu.edu/document/d/1czn14Zpte-kVHdcb5BUIkpI6wRcABH246jGCg9vncQA/edit#heading=h.8hxo5kudhpn2 Topic Writeup]

Ruby as a programming language has gained popularity in recent years (mainly due to the Rails web framework). There exists quite a few graphical user interface toolkits/frameworks for Ruby so that desktop GUI applications can be created. Most are simply bindings to existing GUI framework API's like Qt and GTK+, so they may seem awkward and unfitting to the Ruby language's style. Shoes, on the other hand, is written for Ruby specifically. Two previous articles have made detailed comparisons between different toolkits by looking at various factors such as ease of installation, documentation, look and feel, and difficulty of usage.[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH][http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_MM] This article will give updates on GUI toolkits that has developed since the previous articles were written, as well as discuss other toolkits that were not present in the previous articles.

== Current State of GUI Toolkits for Ruby ==

There is a number of Ruby GUI toolkits to choose from to create a desktop application. In one of the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH#Projects_developed_in_wxRuby previous] articles, an official 2008 Ruby GUI Survey was referenced to discuss the popularity of available GUI toolkits. For a quick recap, here is the result for the question "''Which of the GUI toolkits do you currently use, and which do you think it's likely you'll use in the future?''"

[[File:Survey_results1.jpg|thumb|Survey Results]]

#Shoes
#Ruby-GNOME2/GTK
#wxRuby
#Ruby-Tk
#Ruby Cocoa/MacRuby
#QtRuby
#JRuby + Swing
#FxRuby
#JRuby + SWT

[https://www.ruby-toolbox.com/categories/GUI_Frameworks The Ruby Toolbox], a website that tracks the popularity of Ruby related tools by usage in open source projects, has a list of several toolkits under its "GUI Frameworks" category. The ranking in current popularity (Feb 2013) of GUI toolkits is as follows:

#Shoes
#FxRuby
#wxRuby
#QtBindings
#Ruby/GTK
#monkeybars
#FFI::Tk

Although this list is not as scientific as the official survey result, it does reflect current project usage quite well, and it shows the general acceptance of a particular toolkit. We can see by comparing the two lists that the most popular toolkits (Shoes, FxRuby, wxRuby, Ruby/GTK) are still relevant today. Shoes has proven to be a popular choice since its creation in 2007. Most of the other toolkits remain stable, judging by the dates of code commits of their respective repository. One main exception is wxRuby. wxRuby has not seen a release since September of 2009 even though wxWidgets, the C++ GUI library which wxRuby is based, is still in active development.

However, even though most of these projects are being maintained, there has not been much growth to the GUI community for Ruby. There's still a very low number of applications that are built using GUI toolkits for Ruby, and many of them are personal projects. A simply Google search for Ruby GUI toolkits will return results that mostly predates 2010.

== Overview of other GUI toolkits ==
This article will not attempt to cover the same toolkits that were discussed in the previous articles. The following toolkits are not the most popular choices for Ruby GUI development. However, comparisons can then be made with more popular options by examining the necessary steps to get each one of them up and running

=== Visual Ruby ===
[http://visualruby.net/ Visual Ruby] is designed to simplify the process of adding a GTK+ windows to Ruby applications. It is also designed to completely integrate with the Glade user interface designer.

==== Installation ====
# Install Ruby 1.9.3
# Install Glade and GTK
# Install
>> gem install visualruby

==== Up and Running ====
To run Visual Ruby, simply run the following command
>> vr

After starting up VR, you will see a list of example projects that you can open and run.

[[File:Visual_ruby_1.png]]

[[File:Visual_ruby_2.png]]

=== Monkeybars ===
[https://github.com/monkeybars/monkeybars-core Monkeybars] is a library that enables the use of Swing from JRuby. Monkeybars aims to allow you to continue using the GUI editing tools you are used to but makes it easy to write all your application logic in pure Ruby. It utilizes the Model, View, Controller (MVC) design pattern to separate view logic and user interface components from application logic.

It should be noted, however, that monkeybars should not be the first choice if you're looking to quickly create a GUI application from scratch. The overhead of getting one of these projects up and running will be relatively higher than some other libraries.

What monkeybars is good for is building large and complex GUI applications since it is based on the mature Java language and Swing libraries. If creating Swing applications with Ruby is what you're looking for, this will be a reasonable choice. [http://www.ibm.com/developerworks/library/j-monkeybars/index.html]

==== Installation ====
# Install Java and JRuby
# Install Monkeybars

>> gem install rawr
>> gem install monkeybars

==== Up and Running ====
To create a new project directory

>> monkeybars test_project

After creating a new monkeybars project, follow the detailed tutorials [http://monkeybars.org/tutorials.html here] to configure your project.

=== FFI-Tk ===

[https://github.com/manveru/ffi-tk FFI-Tk] is a pure Ruby FFI (foreign funciton interface) wrapper for the Tk GUI toolkit.

==== Installation ====

gem install ffi-tk

==== Up and Running ====
require 'ffi-tk'
Tk.init
Tk::Button.new('.', text: 'Press me'){
Tk.message_box(message: 'Hello, World!')
}.pack
Tk.mainloop

== Conclusion ==
Although there are many toolkits available for building GUI applications with Ruby, there hasn't been much growth in this area relative to 2010. One possible explanation is that the popularity of desktop application develop has yielded to web applications, which Ruby is most well known for due to it's Rails framework. By looking at the several toolkits examined above, we can also see why some of them remain to be less popular than others. Monkeybars, for example, has too much overhead just to get an application up and running. The more dependencies that are necessary, the heavier the toolkit feels. It does seem, however, that the more popular options will continue to be stable projects. One example is Shoes. Shoes is currently at version 3, and a new version is coming soon. Shoes 4 will be the next version of Shoes[https://github.com/shoes/shoes4]. Perhaps this is why the [http://shoesrb.com/downloads download] page for Shoes is currently void of any content.

== References ==

[1] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH Previous Submission 1]

[2] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_MM Previous Submission 2]

[3] [http://www.ibm.com/developerworks/library/j-monkeybars/index.html The monkeybars library]

[4] [http://shoesrb.com/downloads Shoes 4 Github Page]

CSC/ECE 517 Spring 2013/ch1a c ct

2013-02-11T04:03:51Z

Ctsui:

__TOC__

== Introduction ==
[https://docs.google.com/a/ncsu.edu/document/d/1czn14Zpte-kVHdcb5BUIkpI6wRcABH246jGCg9vncQA/edit#heading=h.8hxo5kudhpn2 Topic Writeup]

Ruby as a programming language has gained popularity in recent years (mainly due to the Rails web framework). There exists quite a few graphical user interface toolkits/frameworks for Ruby so that desktop GUI applications can be created. Most are simply bindings to existing GUI framework API's like Qt and GTK+, so they may seem awkward and unfitting to the Ruby language's style. Shoes, on the other hand, is written for Ruby specifically. Two previous articles have made detailed comparisons between different toolkits by looking at various factors such as ease of installation, documentation, look and feel, and difficulty of usage.[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH][http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_MM] This article will give updates on GUI toolkits that has developed since the previous articles were written, as well as discuss other toolkits that were not present in the previous articles.

== Current State of GUI Toolkits for Ruby ==

There is a number of Ruby GUI toolkits to choose from to create a desktop application. In one of the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH#Projects_developed_in_wxRuby previous] articles, an official 2008 Ruby GUI Survey was referenced to discuss the popularity of available GUI toolkits. For a quick recap, here is the result for the question "''Which of the GUI toolkits do you currently use, and which do you think it's likely you'll use in the future?''"

[[File:Survey_results1.jpg|thumb|Survey Results]]

#Shoes
#Ruby-GNOME2/GTK
#wxRuby
#Ruby-Tk
#Ruby Cocoa/MacRuby
#QtRuby
#JRuby + Swing
#FxRuby
#JRuby + SWT

[https://www.ruby-toolbox.com/categories/GUI_Frameworks The Ruby Toolbox], a website that tracks the popularity of Ruby related tools by usage in open source projects, has a list of several toolkits under its "GUI Frameworks" category. The ranking in current popularity (Feb 2013) of GUI toolkits is as follows:

#Shoes
#FxRuby
#wxRuby
#QtBindings
#Ruby/GTK
#monkeybars
#FFI::Tk

Although this list is not as scientific as the official survey result, it does reflect current project usage quite well, and it shows the general acceptance of a particular toolkit. We can see by comparing the two lists that the most popular toolkits (Shoes, FxRuby, wxRuby, Ruby/GTK) are still relevant today. Shoes has proven to be a popular choice since its creation in 2007. Most of the other toolkits remain stable, judging by the dates of code commits of their respective repository. One main exception is wxRuby. wxRuby has not seen a release since September of 2009 even though wxWidgets, the C++ GUI library which wxRuby is based, is still in active development.

However, even though most of these projects are being maintained, there has not been much growth to the GUI community for Ruby. There's still a very low number of applications that are built using GUI toolkits for Ruby, and many of them are personal projects. A simply Google search for Ruby GUI toolkits will return results that mostly predates 2010.

== Overview of other GUI toolkits ==
This article will not attempt to cover the same toolkits that were discussed in the previous articles. The following toolkits are not the most popular choices for Ruby GUI development. However, comparisons can then be made with more popular options by examining the necessary steps to get each one of them up and running

=== Visual Ruby ===
[http://visualruby.net/ Visual Ruby] is designed to simplify the process of adding a GTK+ windows to Ruby applications. It is also designed to completely integrate with the Glade user interface designer.

==== Installation ====
# Install Ruby 1.9.3
# Install Glade and GTK
# Install
>> gem install visualruby

==== Up and Running ====
To run Visual Ruby, simply run the following command
>> vr

After starting up VR, you will see a list of example projects that you can open and run.

[[File:Visual_ruby_1.png]]

[[File:Visual_ruby_2.png]]

=== Monkeybars ===
[https://github.com/monkeybars/monkeybars-core Monkeybars] is a library that enables the use of Swing from JRuby. Monkeybars aims to allow you to continue using the GUI editing tools you are used to but makes it easy to write all your application logic in pure Ruby. It utilizes the Model, View, Controller (MVC) design pattern to separate view logic and user interface components from application logic.

It should be noted, however, that monkeybars should not be the first choice if you're looking to quickly create a GUI application from scratch. The overhead of getting one of these projects up and running will be relatively higher than some other libraries.

What monkeybars is good for is building large and complex GUI applications since it is based on the mature Java language and Swing libraries. If creating Swing applications with Ruby is what you're looking for, this will be a reasonable choice. [http://www.ibm.com/developerworks/library/j-monkeybars/index.html]

==== Installation ====
# Install Java and JRuby
# Install Monkeybars

>> gem install rawr
>> gem install monkeybars

==== Up and Running ====
To create a new project directory

>> monkeybars test_project

After creating a new monkeybars project, follow the detailed tutorials [http://monkeybars.org/tutorials.html here] to configure your project.

=== FFI-Tk ===

FFI-Tk is a pure Ruby FFI (foreign funciton interface) wrapper for the Tk GUI toolkit.

==== Installation ====

gem install ffi-tk

==== Up and Running ====
require 'ffi-tk'
Tk.init
Tk::Button.new('.', text: 'Press me'){
Tk.message_box(message: 'Hello, World!')
}.pack
Tk.mainloop

== Conclusion ==
Although there are many toolkits available for building GUI applications with Ruby, there hasn't been much growth in this area relative to 2010. One possible explanation is that the popularity of desktop application develop has yielded to web applications, which Ruby is most well known for due to it's Rails framework. By looking at the several toolkits examined above, we can also see why some of them remain to be less popular than others. Monkeybars, for example, has too much overhead just to get an application up and running. The more dependencies that are necessary, the heavier the toolkit feels. It does seem, however, that the more popular options will continue to be stable projects. One example is Shoes. Shoes is currently at version 3, and a new version is coming soon. Shoes 4 will be the next version of Shoes[https://github.com/shoes/shoes4]. Perhaps this is why the [http://shoesrb.com/downloads download] page for Shoes is currently void of any content.

== References ==

[1] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH Previous Submission 1]

[2] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_MM Previous Submission 2]

[3] [http://www.ibm.com/developerworks/library/j-monkeybars/index.html The monkeybars library]

[4] [http://shoesrb.com/downloads Shoes 4 Github Page]

CSC/ECE 517 Spring 2013/ch1a c ct

2013-02-09T03:11:31Z

Ctsui:

__TOC__

== Introduction ==
[https://docs.google.com/a/ncsu.edu/document/d/1czn14Zpte-kVHdcb5BUIkpI6wRcABH246jGCg9vncQA/edit#heading=h.8hxo5kudhpn2 Topic Writeup]

Ruby as a programming language has gained popularity in recent years (mainly due to the Rails web framework). There exists quite a few graphical user interface toolkits/frameworks for Ruby so that desktop GUI applications can be created. Most are simply bindings to existing GUI framework API's like Qt and GTK+, so they may seem awkward and unfitting to the Ruby language's style. Shoes, on the other hand, is written for Ruby specifically. Two previous articles have made detailed comparisons between different toolkits by looking at various factors such as ease of installation, documentation, look and feel, and difficulty of usage.[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH][http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_MM] This article will give updates on GUI toolkits that has developed since the previous articles were written, as well as discuss other toolkits that were not present in the previous articles.

== Current State of GUI Toolkits for Ruby ==

There is a number of Ruby GUI toolkits to choose from to create a desktop application. In one of the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH#Projects_developed_in_wxRuby previous] articles, an official 2008 Ruby GUI Survey was referenced to discuss the popularity of available GUI toolkits. For a quick recap, here is the result for the question "''Which of the GUI toolkits do you currently use, and which do you think it's likely you'll use in the future?''"

[[File:Survey_results1.jpg|thumb|Survey Results]]

#Shoes
#Ruby-GNOME2/GTK
#wxRuby
#Ruby-Tk
#Ruby Cocoa/MacRuby
#QtRuby
#JRuby + Swing
#FxRuby
#JRuby + SWT

[https://www.ruby-toolbox.com/categories/GUI_Frameworks The Ruby Toolbox], a website that tracks the popularity of Ruby related tools by usage in open source projects, has a list of several toolkits under its "GUI Frameworks" category. The ranking in current popularity (Feb 2013) of GUI toolkits is as follows:

#Shoes
#FxRuby
#wxRuby
#QtBindings
#Ruby/GTK
#monkeybars
#FFI::Tk

Although this list is not as scientific as the official survey result, it does reflect current project usage quite well, and it shows the general acceptance of a particular toolkit. We can see by comparing the two lists that the most popular toolkits (Shoes, FxRuby, wxRuby, Ruby/GTK) are still relevant today. Shoes has proven to be a popular choice since its creation in 2007. Most of the other toolkits remain stable, judging by the dates of code commits of their respective repository. One main exception is wxRuby. wxRuby has not seen a release since September of 2009 even though wxWidgets, the C++ GUI library which wxRuby is based, is still in active development.

However, even though most of these projects are being maintained, there has not been much growth to the GUI community for Ruby. There's still a very low number of applications that are built using GUI toolkits for Ruby, and many of them are personal projects. A simply Google search for Ruby GUI toolkits will return results that mostly predates 2010.

== Overview of other GUI toolkits ==
This article will not attempt to cover the same toolkits that were discussed in the previous articles. The following toolkits are not the most popular choices for Ruby GUI development. However, comparisons can then be made with more popular options by examining the necessary steps to get each one of them up and running

=== Visual Ruby ===
[http://visualruby.net/ Visual Ruby] is designed to simplify the process of adding a GTK+ windows to Ruby applications. It is also designed to completely integrate with the Glade user interface designer.

==== Installation ====
# Install Ruby 1.9.3
# Install Glade and GTK
# Install
>> gem install visualruby

==== Up and Running ====
To run Visual Ruby, simply run the following command
>> vr

After starting up VR, you will see a list of example projects that you can open and run.

[[File:Visual_ruby_1.png]]

[[File:Visual_ruby_2.png]]

=== Monkeybars ===
[https://github.com/monkeybars/monkeybars-core Monkeybars] is a library that enables the use of Swing from JRuby. Monkeybars aims to allow you to continue using the GUI editing tools you are used to but makes it easy to write all your application logic in pure Ruby. It utilizes the Model, View, Controller (MVC) design pattern to separate view logic and user interface components from application logic.

It should be noted, however, that monkeybars should not be the first choice if you're looking to quickly create a GUI application from scratch. The overhead of getting one of these projects up and running will be relatively higher than some other libraries.

What monkeybars is good for is building large and complex GUI applications since it is based on the mature Java language and Swing libraries. If creating Swing applications with Ruby is what you're looking for, this will be a reasonable choice. [http://www.ibm.com/developerworks/library/j-monkeybars/index.html]

==== Installation ====
# Install Java and JRuby
# Install Monkeybars

>> gem install rawr
>> gem install monkeybars

==== Up and Running ====
To create a new project directory

>> monkeybars test_project

After creating a new monkeybars project, follow the detailed tutorials [http://monkeybars.org/tutorials.html here] to configure your project.

=== FFI-Tk ===

FFI-Tk is a pure Ruby FFI (foreign funciton interface) wrapper for the Tk GUI toolkit.

==== Installation ====

gem install ffi-tk

==== Up and Running ====
require 'ffi-tk'
Tk.init
Tk::Button.new('.', text: 'Press me'){
Tk.message_box(message: 'Hello, World!')
}.pack
Tk.mainloop

== Conclusion ==
Although there are many toolkits available for building GUI applications with Ruby, there hasn't been much growth in this area relative to 2010. One possible explanation is that the popularity of desktop application develop has yielded to web applications, which Ruby is most well known for due to it's Rails framework. By looking at the several toolkits examined above, we can also see why some of them remain to be less popular than others. Monkeybars, for example, has too much overhead just to get an application up and running. The more dependencies that are necessary, the heavier the toolkit feels. It does seem, however, that the more popular options will continue to be stable projects. One example is Shoes. Shoes is currently at version 3, and a new version is coming soon. Shoes 4 will be the next version of Shoes[https://github.com/shoes/shoes4]. Perhaps this is why the [http://shoesrb.com/downloads download] page for Shoes is currently void of any content.

== References ==

[1] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_PH Previous Submission 1]

[2] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch1_S10_MM Previous Submission 2]

[3] [http://www.ibm.com/developerworks/library/j-monkeybars/index.html The monkeybars library]

[4] [http://shoesrb.com/downloads download Shoes 4 Github Page]