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.
Related
i'm currently working on a big projekt and i loose many time searching the right thing in the code. i need to get e.g. a method which makes someting special. so i scroll the whole code.
are there any common and effective methods to struct a file of code? e.g.
1. all global variables
2. constructor etc.
3. all methods
4. all event handlers
do you know common methods to do this??
It's more usual to break large projects into several source files, with logically related functionality. This helps with speeding up compilation and reducing coupling in your design as well as helping you navigate the code.
An example might be to have separate files for
UI functionality
helper classes (such as geometric/maths stuff)
file I/O
core functionality that connects the rest together
Design is a large topic, the book Code Complete by Steve McConnell might be a good starting point for you.
You shouldnt use global variables :)
Try spreading things out over different classes and files. Maks sure each class has only one purpose, instead of 1 class that manages a whole lot of different tasks.
That sounds like a sensible enough structure to me, what would really benefit you though is learning to use the tools you have available — whatever editor you're using it will have a search function, you can use that to quickly find what you're looking for.
Some editors will also include bookmarks too, and most offer a way to move back and forward through recent positions in the file.
Seen this sort of things started, never seen it kept on under the pressure to turn out code though.
Basically my rule of thumb is, if I feel the need to do this, break the code file up.
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.
So - highly hypothetical question and more like discussion about your coding style and practice you use daily.
I will take as example: CodeGear RAD Studio 2009 (sorry to all D7 fans, but Unicode rules).
I have capability to expand/collapse functions/procedures/records and few other complex data structures, but what if code is lengthy?
What makes the task and its accomplishment efficient - the time required to add comments (its req actually) and expand/collapse necessary area or use OMT offered possibilities?
To give example input from myself - I have small app, about 1,5k lines and I do not use Modeling. Is it smart enough or do I lose a lot of time if I need to find some simple references or (event) calls?
If I understand your question correctly, it is a bout finding your way into code (yours or someone elses').
I use Model Maker Code Explorer for browsing through source code (and for refactoring existing code, and creating new code). At EUR 99, it is dead cheap for what it does.
It usually gives me a perfect overview of what I need, and has a nice 'search' interface as well.
If I need more complex searches, I usually use the GExperts (grep) search function: it is blazingly fast, and with good naming of your identifiers, it is usually a breeze to find stuff.
If I understand your question correctly, you want to know what is more efficient:
Use comments and expandable sections.
Use moddeling techniques.
I think it depends on personal style. Modeling can be great, but has dangers of spending too much time creating nice pictures.
We have a large app 500k+ lines. We do not use collapsable sections because we keep our file size acceptable and we have a good file organisation structure. We sometimes use modeling if complex parts are added (class diagrams and state diagrams). And we use lots of comment to explain difficult parts.
If you have Delphi 2009 you can use also the Delphi Class Explorer (in the View menu) in order to see your classes. It seems a little bit cryptic but only for the first 5 minutes. After this you will get used with it.
Also you can use CnPack a very impressive package in order to help you manage your project. Basically, in the IDE appears a new menu called 'CnPack' which has a bunch of wizards to help you find the way out in the source. Some examples:
Uses Cleaner
Procedure List (it gives you the incremental search capability for your procedures - very neat)
Bookmark Browser
etc.
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.