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).
Related
Maybe this question is too open-ended and someone will kill it
--- however:
I am building systems (web apps and native) requiring multiple language support, including rtl languages like Arabic and Hebrew. Currently I have no need to be able to program in those languages, but writing content is a must.
There are some difficult choices to make I think in the implementation, because I think at some level (I don't know it's why I'm asking) the text file needs to have a consistent direction of string flow, but when we read and compose these files we need to view these elements with their character order reversed in order for them to be sensible.
(Open ended and non-constructive? I'm hoping to construct a solution.)
I fail to see the connection with SublimeText.
You need RTL support, you use a pre-made component that can handle it.
Or start with a library that can help with that support and does the heavy-lifting (for instance Uniscribe, http://msdn.microsoft.com/en-us/library/windows/desktop/dd374091%28v=vs.85%29.aspx,
or HarfBuzz, http://www.freedesktop.org/wiki/Software/HarfBuzz/)
Adding it yourself means a lot of work (SublimeText fails miserably at it, I don't even think it tries).
To get an idea what you have to deal with, take a look at the Unicode Bidirectional Algorithm
(http://www.unicode.org/reports/tr9/)
Just vote for adding RTL Languages here...
https://sublimetext.userecho.com/topic/37207-right-to-left-languages-support/
They will add it if the votes reach 600
In my experience code behind UI can easily get ugly, and inorganized, e.g. long functions, lots of variables etc.
How do you manage the code behind UI?
The MVC pattern is often used to impose some structure and organisation.
Following the principles of SOLID OO design and similar ideas helps.
It depends on your programming-language.
Threre are a lot of QA-Tools for different languages. Have a look at wikipedia
Which languages and techniques do you use?
One solution is to use 'immediate mode' UIs. It basically boils down to only caring about the UI element you're currently focussed on and binding the variables with data-side app variables. This is the opposite of retention mode UIs
Great video here.
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.
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.