I'm writing a lightweight IDE. I chose Ruby+Gtk2 for the task. I already have a minimal prototype for it, but right now, most of the code is inside my window class. I'll soon start working on the "real deal", but I would like to know what design patterns should I make use of. I'm planning for plugin support too, so that the app will be extensible. Any ideas are welcome, but please discuss your option a bit.
Please keep in mind this is a scripting language. I'm not sure if all of Java's design patterns apply here.
Design patterns are solutions for common problems. What problems are you having? In consulting work, we see that often when someone sets out saying "Okay, here's my idea. What design patterns can I put to work?," the architecture gets overly complicated very quickly.
Instead of looking for design patterns that you could possibly use, read up on design patterns (I hate to link to Wikipedia, but their article does have a good list to get you started on other searches with at least) and then apply them when you come up with a problem that fits their criteria.
As far as having a lot of code in your window class, that may be appropriate for your application, or you may want to look at something like a loose MVC pattern. Generally for GUI programming, a rigid MVC is going to be too strict, and require too much work for "true" separation of concerns.
There are many common problems that can be solved without design patterns, and that does not mean the solution is right or wrong. Plugin support, for instance, is very often given just by supplying a plugin interface or a set of events a plugin can respond to. Alternatively, you could look at the Adapter pattern.
I'm not sure if this will be much help, but the book "Design Patterns in Ruby" talks about, well, design patterns in ruby and how they might differ from Java's design patterns.
Also, don't forget to check out existing IDEs. What did they use?
Since editing will be a component of your IDE, you should check up on actual open source editors.
Just to clarify a possible misunderstanding: Are you perhaps referring to UI patterns (as opposed to software architecture design patterns)? Your question seems to me to make more sense that way.
I'm not sure if this is appropriate, but there's a nice book about disecting & building an IDE in C#. The book does discuss about the design patterns being used to develop the Sharp Develop IDE.
SharpDevelop is a nice IDE & it's open source you might want to have a peek at this book & home page for Sharp Develop.
The best way to design a ruby GUI application is to use visualruby:
http://visualruby.net
You can make your GUI totally separate from your classes. For example, If you want to create a GUI for the following class, you can do it easily without disturbing it:
class DataObject
def initialize(name, address, email, phone)
#name = name
#address = address
#email = email
#phone = phone
end
end
You create a GUI for this class by subclassing it, and adding the GUI:
class DataObjectGUI < DataObject
include GladeGUI
def show()
load_glade(__FILE__) #loads glade/DataObjectGUI.glade into #builder
set_glade_all() #populates glade controls with insance variables from DataObject
show_window()
end
end
The GladeGUI interface contains all the GUI magic. The load_glade() method will load the file, DataObject.glade. This is a glade form that contains Gtk::EntryBoxes named,name, address, phone and email. The form will show on the screen with all the fields filled-in.
Obviously the show_window() will make the window appear on the screen. The destroy window is automatically called by GladeGUI when you click the "x" button.
This disign pattern can be used for any class. A good example is if you have an ActiveRecord class, and you want to show the record on the screen. You just subclass as above, and it's editable and savable.
This example is taken from one of the example projects on visualruby.net.
Related
I'm quite new to Smalltalk and I've been searching a whole day how I could write a GUI. I've found loads of information on how to work with Morphs and what Halos are, but I don't seem to be able to find what I need (It's only a table with the entries from a Dictionary).
Next to Morphs, I also found quite something on how smalltalk introduced the MVC-principle. I even found the ST-80 Views Category, containing everything I would need, but again I am not sure on how to use it correctly and somehow I don't seem to find the right sources to get me started.
Therefore my question(s): Where to start to build a simple GUI? How should I choose from the billion Morphs available and how do I combine them to a solid interface? Should MVC only be used when it gets more complex or are they also useful for simple GUIs? Is there any general overview on what to use in which cases?
To illustrate what I would like to do, I added some pseudo-code of how I would have it in mind:
d := Dictionary new.
"add data to the dictionary..."
view := DictionaryView new.
view addDictionary: d.
button := SimpleButtonMorph new.
"e.g. change label to sum of values"
button target: [button label: d sum.].
window := SystemWindow labelled: test.
window addMorph: view.
window addMorph: button.
Any help to get me started with this is highly appreciated.
Update:
I recently found a chapter from a book that helped me understand morphic better with some nice explanation and example code and for people who want to know more, there is a whole list of free books too. Also useful were the tutorials from the squeak wiki. Especially the one on Pluggable Morphs helped me to understand this concept better. Note that this tutorial is hidden in the list of unreviewed tutorials (possibly because there is a little error in the project that can be downloaded).
In Squeak (I presume you use Squeak, because you speak of Morphs and ST80),
there are several ways to build GUIs.
Plain Morphs
You can just put together Morphs. Typically, you need some Widget, like a SimpleHierarchicalListMorph. But this process gets tedious fast.
ToolBuilder
If you're creating an application that somehow resembles a tool, of whatever kind, the ToolBuilder might be your friend. Tools like the System Browser, the Debugger, or more recently, the FontImporter are built with ToolBuilder. It requires a Model with the #buildWith: message. Search for implementers of this message to get an idea how to use ToolBuilder.
But probably the easiest way:
Morphic Designer
The Morphic Designer lets you put together your Application UI graphically. You can re-use the design and do not need too many code to hook you program up to the UI. Examples included.
Note: You also found the MVC implementation. It has come out of fashion in Squeak, but it still should be usable. However, you must create a new Project to use MVC. It is, by the way, possible to create tools that can run in both Morphic and MVC projects when you use ToolBuilder.
What's the closest equivalent of the Smalltalk Class Hierarchy Browser?
I've seen some workarounds like this, but it seems not scriptable.
There really isn't one, at least not with a Smalltalk-like UI including static and dynamic behaviors.
Eclipse and IntelliJ both have some structural insight. Eclipse has a view sort-of similar to a browser. The biggest issue with either is that unless you're working on live objects (e.g., debugging) you won't necessarily know all of an object's behavior since some is defined at runtime. A static view without an image or partial runtime cannot give a complete picture.
IntelliJ does a decent job of figuring things out. For example, a class with an attr_accessor :foo will show the #foo instance variable in the structure pane. I'm not sure you can configure the UI around to be more browser-like, though; Eclipse is better in this regard–each "level" can be added separately.
(Since 1994-95ish I've felt we kept taking steps backwards, it's only recently that IDEs have gotten smart enough to give me back some of the productivity I had with Smalltalk/Lisp. Smalltalk's image-based runtime confers a lot of advantages in this regard.)
For more fun, you could take a Moose image, write a Ruby parser with PetitParser and a Glamour code browser. That would provide a Smalltalk UI :)
[edit] Oh, someone didn't like the answer. Care to explain why? It is a perfectly good solution.
One thing that constantly causing me headache in programming is when I don't have any naming-convention in a domain where I have to deal with a lot elements. It is clearly what is happening to me when using UI designers such as Windows Forms designer.
Everytime I start a new project I am trying to reinvent a "seem-strong" naming convention but it always fail at some points. For me there is 2 main problems compared to classic code definition for naming GUI elements:
You have to place a lot of variables (GUI elements) which can all be accessed in the same scope, so you need to have to a strong naming convention to find quickly the right element.
You often need to access to a specific type of GUI control (ex: TextBox, Label, ...), so the best solution for GUI elements is to name them after their types (Hungarian style notation), which can be sometimes confusing and not helping in finding the right element quickly.
If someone has a documentation describing a good convention or a strong convention he invented for its own project, I would really like to know it!
NB: I did not classified this question under .NET or Windows Forms tags has it seems applicable to a lot of frameworks. If not, let me know.
EDIT:
In fact the convention I most use is using a reversed hungarian notation (meaning the type comes first) followed by a path based on the UI elements hierarchy. For example, to easily access to a TextBox which belongs to the "Settings" tab of my program I would call it this way:
this.tb_settingTab_xxx
My problem using this convention is that it is not perfect and sometimes fails when you have a UI element that belongs to another which also belongs to another which also belongs to ...
I am really searching for is the unbreakable and handy naming-convention. I am quitely surprised that Microsoft never gaved any guidelines concerning this. Or am I going wrong? (ie. Mark Rushakoff comment).
There are various naming conventions described in this post. The key is to remain consistent throughout the project. I deal with a lot of controls, but find it straightforward to label them based on what they are. Textbox = tbMyControl, Label = lblMyControl. The 'MyControl' bit might be the same if they relate to similar aspects (e.g. tbUsername, lblUsername). However, there's no confusion on what I'm accessing. If you find you're getting confused, then maybe you're trying too many different notations? Keep it simple and logical.
Note: I use the following in code that covers - and sometimes mixes - "raw" Win32, ATL/WTL and MFC, so don't take it literally, only the principle. (Also, be forgiving on the m_)
I use a two-letter-shortcut for standard control types, followed by the name which resembles the functionality of the control (in most cases, Identical / close to the label). The name of related controls needs to match of course - e.g.
CStatic m_stBasePath;
CEdit m_edBasePath;
CButton m_cbBrowseBasePath;
It's not perfect for all scenarios, but generally I'd say a dialog where this isn't good enough anymore might have to many controls for the user already.
I've written three paragraphs that could be titled "details and defense" - and subsequently deleted them, since there's a very clear essence:
Consistency.
I mostly use the dialog resource itself for orientation, and have strict equivalence between resource ID's and associated members. So the "Base path" - related controls aren#t together in an alphabetic order, but I rarely see this as a problem.
The standard control type already contains very obvious information about functionaltiy of a control - a checkbox to enable / disable a group of features or for a boolean option, an edit or drop down to enter/select a value, a button to open a sub dialog, a static control for the label, etc.
I'm not sure how this style transfers if you transfer it to a platform with much more controls or when you use a lot of custom controls, as my WinForms projects have been comparedly small.
I need to write a GUI app in Ruby that supports easily changing the text color for items in a listbox (ownerdraw) on Linux.
What GUI framework is recommended?
Shoes
Nobody knows shoes
http://shoooes.net/
It's by _why, so it's zany, but very usable.
Sorry for the super late answer, but in case anyone's wondering:
If you're using JRuby, I think Monkeybars should work for this. I'm 100% sure, first-hand, that it works for general list box manipulation, but what I'm not 100% sure about is whether it has complete functionality. Also not 100% on how perfectly it would work with Ownerdraw listboxes; I used typical Java-defined-netbeans-built boxes for simplicity's sake.
I didn't however, allow users to select multiple of the lines from the list (i.e. ctrl or shift + click). I remember that was working in some ways, but was giving me some trouble as far as passing functions. If I recall correctly, the biggest issue I was having with this, actually, was deciding how I wanted to manage requests to reorder the list while they had many things selected (E.G. if they clicked the shift-down or shift-up buttons while holding many elements). But other than that I think it worked fine.
From what I've seen using both, it's a bit more complicated to set up than shoes, but I found it to be very rewarding (at least as far as a simple school assignment was concerned, where I was required to have a GUI, but wanted to start learning Ruby, so I opted for a Java Swing front end to JRuby).
I certainly wouldn't be the best source for help setting it up and getting all your functions to work, and unfortunately there is minimal information about Monkeybars floating around, especially with regards to specialized "how do I do X?" kinds of questions, but there are boards available (links below) with very friendly and helpful posters. Much like here :)
http://groups.google.com/group/monkeybars-mvc/topics
*looks like the Kenai page has been abandoned and moved to the above google group and github
They also force a MVC architecture - so if you're going to use Monkeybars, you need to design your program to be compatible with this style. I never really saw this as a big deal, but I'm sure some people would dread being told how to structure their code.
So it's important to consider whether those are deal breakers before going through the trouble of installing the Monkeybars tools on your computer, but if you can deal with the few issues associated with it, Monkeybars can be a fantastic tool for building (and perhaps more importantly - manipulating) GUI around a JRuby project.
EDIT: here's some very basic example code using Moneybars:
define_signal :add_element, :add_element
def add_element(model, transfer)
trackList.getModel().addElement(model.addable.to_s)
end
where "trackList" was simply what the list was called on the Java end of the code (so "trackList.getModel()" would return the listbox model holding the list [for this project I needed 7 distinct lists to share a listbox, and to be switched between via drop-down list; if you only wanted one list to use the listbox you could just call it by name and remove the ".getModel()" part]. "addable" was the name of the well-fomatted element/string that I wanted to add to the list, and "model" (lower case) was the 'model' class used to conform to MVC architecture.
Sorry about the ugly signal part at the top, I had heavy deadlines and not enough time to play around with the variable names to use them better. It worked, and that was what mattered at the time (unfortunately). I'm reasonably sure the first one was the name of the signal (sent from the 'control' class) and the second one was probably a reference to the definition immediately following it. Sorry about my ignorance here, but it just made life easier to leave it as was (i.e. as was explained in the Monkeybars example code).
But there you have it, a function for adding elements to a GUI listbox using JRuby and Swing. It automatically redraws the screen when these signals are sent, so that's taken care of too. Right after that def is called you would see the changes. Modifying other aspects of the listbox were just as simple. Hope that helps anyone :)
The best way to go is visualruby:
http://visualruby.net
The code would look something like this:
#view = VR::ListView.new(:name => String, :address => String)
#view.ren_background(:name => "red")
#view.add_row(:name => "Hank", :address => "123 main")
That would make the background red for the name column. The #view variable would be used to populate a spot in the gui form.
Is there is a generic, widely understood term for GUI elements. I have programmed so many GUI toolkits, I couldn't tell if Windows-only programmers know what the Java crowd means when they talk about widgets. Does a GTK+ user know what a control is? And does anybody besides me remember gadgets?
Qt uses widgets, Swing uses Components. Most gui programmers will understand what you mean when you say a scroll-widget/component.
As component is to generic, I'd say: Visual component.
It just describes exactly what it is: a visible, self-contained element, that does some well-defined task.
According to my Human-Computer Interaction teacher and to the this HCI manual the name is "widget".
Component?
I would say "element". "Component" evokes COM object for me.
I don't think there is one term to cover it, but window, component, widget and control are all in widespread use, so I would think most developers understand them all, although they may mean slightly different things in different frameworks (i.e. which is the lowest common class/component in the framework).
Actually, I think GUi element (or graphical element/interface element) is a pretty good catch-all term.
As noted in this SO question, naming is hard, and that makes this question very much program-related!
As specified in the javadoc of org.eclipse.swt.widgets.Widget, a Widget refers to "user interface objects" in general.
So it might be more precise than the too-generic term "component".
Symbian (currently) uses controls, but S60 is in the process of moving to QT so this is likely to move to widgets.
I'd suggest that you stick to the convention of your GUI framework. That way people who invested the time to learn the framework will know what you mean, and those who don't wouldn't know what you meant till they did anyway. If it's for a framework independent article or some such, define what you mean either at the start or in an appendix (for example: control - a GUI element, also commonly known as component, widget, etc).