This question arises because I want to capture LostFocusEvent from Dialog. Unfortunately, this event is not fired for non Component derived components. What I want to ask is what is the aim of Dialog not derived from Component, but RichWindow, as compared to the Swing library?
I think really the best way to get the answer is to contact Ingo Maier directly, but you may be able to deduce the some of the thinking behind from his blog article The scala.swing package in 2.8 and beyond:
Window hierarchy
This is how the Java AWT/Swing window hierarchy looks like:
While AWT's Frame and Dialog share the common base class Window, the Swing extensions have no subclass relationship or extend a common interface even though they share common functionality not present in AWT. In an attempt to straighten things up a little, we redesigned the window base hierarchy in scala.swing which now looks as follows:
[...]
This design lets us factor common wrapper code into class RichWindow.
So I am guessing that this is a deliberate design by the author stating that Windows are in fact not components in the same way frames and buttons are, and can be dropped on to other containers.
Related
I'd like to obtain a reference to underlying java components for the controls I have in my GUI so as to customize their appearance.
I know about findjobj from Yair Altman which works really well:
myLink = uicontrol('String', '<html><u>Button that looks like a link.</u></html>');
jObj = findjobj(myLink);
jObj.setContentAreaFilled(0);
Unfortunately this solution is quite slow when there are a "lot" of controls to customize (because it has to parse the full hierarchy of objects in the figure and this for each control to customize).
Moreover the figure must be visible (else controls are not instantiated and java references cannot be found). Plus it must be moved of screen to avoid users to touch it while findjobj is running (sometimes make things crash because findjobj somehow relies on position of controls to find them while internally calling also drawnow which updates positions) ...
On some machines, even with only a few controls to customize, it can be up to 10 seconds before to have the figure to appear (most of the time is spent in findjobj).
I also know about uicomponent again from Yair Altman to directly create controls and get the handle to the underlying java component in one shot:
[myLink, jObj] = uicomponent('Style', 'JButton', 'String', '<html><u>Button that looks like a link.</u></html>');
jObj.setContentAreaFilled(0);
Unfortunately here the parent property can only be a figure and of course my controls are placed in gui layout containers to handle resizing and many other things nicely (and gui layout containter are not valid hg-handles for uicomponent to work)...
So was wondering if there could be any other fast solution to get underlying java components for controls in my GUI ? ... NB: I mainly only need to have buttons that looks like hyperlinks or animated gif (i.e. borderless buttons with htlm text/img inside).
This isn't a direct answer to your question, but I've built several GUIs that are based around GUI Layout Toolbox and that contain Java swing components. I typically arrange things so that the GUI Layout container (HBox, VBox, Grid etc) has a uipanel as a child, and then the uipanel has the Java swing component as a child.
You can typically parent a Java component to the uipanel in exactly the same way as parenting it to a figure (unlike a GUI Layout container), and it's no problem to parent a uipanel to a GUI Layout container.
So, for example, to add a button with a dropdown menu (no menu items, so it won't do anything, but just to illustrate):
>> u = uipanel;
>> ddbuttonclass = 'com.mathworks.widgets.DropdownButton';
>> ddbutton = javaObjectEDT(ddbuttonclass);
>> [jddbutton, hjddbutton] = javacomponent(ddbutton, [30,30, 60, 30], u);
Now you can parent u to a GUI Layout container, and you get all the nice resizing.
I'm not that familiar with Yair's uicomponent, but if you can get the handle of the java component somehow, you should be able to use something like the above.
PS If you want his direct input, #Yair is sometimes active on SO - he may get notified if I mention his name. If you're doing a lot of Java/MATLAB GUI work, I'd also recommend buying his book.
UICOMPONENT was designed to be a direct replacement of both Matlab's built-in UICONTROL and JAVACOMPONENT functions. This means that you can directly place a UICOMPONENT within panels, even those created by the GUI Layout toolbox.
You might need to cast the layout panel's handle to double (double(hPanel)) on some Matlab releases but that's about it:
[myLink, jObj] = uicomponent('Parent',hPanel, ...);
[myLink, jObj] = uicomponent('Parent',double(hPanel), ...); % on some Matlab releases
You could also use JAVACOMPONENT directly, but it doesn't really give you any benefits over UICOMPONENT, since UICOMPONENT uses JAVACOMPONENT under the hood and also adds important functionality (such as ensuring the component is placed on the EDT, and merging important properties from the Matlab wrapper).
As for FINDJOBJ, you can speed it up a bit by specifying the target object class using the 'class' parameter. But if your figure contains hundreds of controls it might still be slow. To this day, close to 10 years after my first version of FINDJOBJ, I still do not know of a direct way to get the underlying Java object. I assume there is one that is used internally by MathWorks, but I do not know it.
As #SamRoberts mentioned, this is all discussed in my book...
I use the MVC programming model. I am running into a problem using Unity's hierarchy inspector. Say I have a Controller script: C_CardDrag. Now, because this drags a UI item thats nested several layers deep, it won't be readily apparenty that this C_CardDrag script is attached to an icon within in the card, and NOT the root object. You see what I mean in the image below (the blue highlight is where the C_Drag needs to be attached, NOT the top level object, otherwise the whole thing gets dragged when I only want the icon in the middle dragged).
I feel that it can be VERY confusing to design and name classes when they need to appear on nested objects.
Do you have any design practices I can follow to make script names clearer to where they are attached?
For example say I have a Tree object, and it has several brances. And lets say I have a C_Tree script, and a C_Branch script. How would you handle making it clear that C_Tree goes on a Tree, a TOP level object, where as C_Branch goes on a nested UI object?
Update:
Found a good resource here: Component based game engine design
Like any software that is being developed, you should only apply the appropriate Architectural and Design patterns that fit that project.
For example:
I was building a game that would be used for different devices. Although Unity lets you switch from Android to iOS seemingly easy. This game could be played completely differently on different devices, so I wen't with MVC.
Another game was built around Peer to Peer.
So overall you have a lot of options.
The way you can organize your files is by folders in the Project section of the Editor. I like to use something like this:
You will notice the Model is not in the Hierarchy. I don't use MonoBehaviours for models. In some cases, even the Controller could be non-MonoBehaviour code. That is why I prefer to have all the organization happen in the Project not the Hierarchy.
New to GWT here...
I'm using the UIBinder approach to layout an app, somewhat in the style of the GWT Mail sample. The app starts with a DockLayoutPanel added to RootLayoutPanel within the onModuleLoad() method. The DockLayoutPanel has a static North and a static South, using a custom center widget defined like:
public class BigLayoutWidget extends ResizeComposite {
...
}
This custom widget is laid out using BigLayoutWidget.ui.xml, which in turn consists of a TabLayoutPanel (3 tabs), the first of which contains a SplitLayoutPanel divided into WEST (Shortcuts.ui.xml) and CENTER (Workpanel.ui.xml). Shortcuts, in turn, consists of a StackLayoutPanel with 3 stacks, each defined in its own ui.xml file.
I want click events within one of Shortcuts' individual stacks to change the contents of Workpanel, but so far I've only been able to manipulate widgets within the same class. Using the simplest case, I can't get a button click w/in Shortcuts to clear the contents of Workpanel or make WorkPanel non-visible.
A few questions...
Is ResizeComposite the right type of class to extend for this? I'm following the approach from the Mail example for TopPanel, MailList, etc, so maybe not?
How can I make these clicks manipulate the contents of panels in which they do NOT reside?
Are listeners no longer recommended for handling events? I thought I saw somewhere during compilation that ClickHandlers are used these days, and the click listener "subscription" approach is being deprecated (I'm mostly using #UiHandler annotations)
Is there an easy way to get a handle to specific elements in my app/page? (Applying the "ID" field in the UI.XML file generates a deprecation warning). I'm looking for something like a document.getElementById() that get me a handle to specific elements. If that exists, how do I set the handle/ID on the element, and how can I then call that element by name/id?
Note that I have the layout itself pretty well nailed; it's the interaction from one ui.xml modularized panel to the next that I can't quite get.
Thanks in advance.
If you don't have a use for resizing events than just use Composite
What you want is what the GWT devs called message bus (implemented as HandlerManager). You can get a nice explanation in the widely discussed (for example, on the GWT Google Group, just search for 'mvp') presentation by Ray Ryan from Google I/O 2009 which can be found here. Basically, you "broadcast" an event on that message bus and then a Widget listening for that event gets the message and does its stuff.
Yep, *Handlers are the current way of handling events - the usage is basically the same so migration shouldn't be a problem (docs). They changed it so that they could introduce custom fields in the future, without breaking existing code.
If you've set an id for any DOM element (for Widgets I use someWidget.getElement().setId(id), usually in combination with DOM.createUniqueId()) you can get it via GWT.get(String id). You'll get then a RootPanel which you'll have to cast to the right Widget class - as you can see it can get a little 'hackish' (what if you change the type of the Widget by that id? Exceptions, or worse), so I'd recommend sticking with MVP (see the first point) and communicating via the message bus. Remember however, that sometimes it's also good to aggregate - not everything has to be handled via the message bus :)
Bottom line is I'd recommend embracing MVP (and History) as soon as possible - it makes GWT development much easier and less messy :) (I know from experience, that with time the code starts to look like a nightmare, if you don't divide it into presentation, view, etc.)
In a tool such as Photoshop, there is a selection of tools you can click on (e.g. pen, brush etc). Once you click on a tool, you can use that tool to paint, erase etc depending on what tool is selected.
I'm wondering how that would be best implemented in an OO design. I could only think of having a GUIManager that always knows which tool is selected, then when the Canvas (drawing area) detects a mouse click or mouse drag it asks GUIManager which tool is selected and applies that tool's behavior.
Does anyone describe a possible solution in class level detail (or in any detail if you don't have time).
Take a look at the State Pattern which has exactly your example.
However, it's not actually a GUI question but more to an object-oriented approach to how to model this problem. The GUI doesn't really play into this.
I'm not sure OO principles really play into this except in the sense that all graphic elements are probably derived from common base classes in your GUI of choice.
The amount of complexity in an application that needs a hierarchy of screen menus à la photoshop would presumably dwarf the difference between composition vs inheritance vs functional-style vs whatever-you-want.
Although, should you be motivated to write the program twice using different styles, it might be interesting to see the results. The ranking of various programming styles is an open question without real answers at this point, although we think that OO-styles are important in a way we haven't yet completely quantified.
One idea for this would be to have a tool class. Just sketching this in C++-like pseudocode:
class Tool
{
public:
// Keep a pointer to the "document", i.e. some representation of the
// image you are editing
Tool(Document *pDoc);
// Process mouse events -- this need to be overridden to execute
// the appropriate behaviour depending on the concrete type of tool
virtual void OnMouseEvent(const MouseEvent &e) = 0;
// and so on
};
You then inherit from this abstract tool class to provide the concrete tools your application needs. When a certain tool is selected, you instantiate a corresponding tool object and remember it somewhere. The window forwards mouse events to the currently active tool object, which then does the appropriate thing for the tool that was selected.
This is an implementation of the State pattern that Johannes refers to.
I have a set of nonGUI objects which have a one to one realtionship with GUI objects.
All events are routed through the top level window.
Many ( not all ) events occuring on the GUI object result in calling a method on the associated object.
Some methods in the NonGui objects which when called change the GUI objects.
One example would be some sort of game like Rogue with a modern GUI.
You have the area a player occupies in one turn ( call it a region )
and you have the object ( a button ) associated with it on the GUI.
Keep in mind it's only an analogy ( and not even the real problem ) and no analogy is perfect.
The question is, how does one design this sort of thing?
Since the button class is from a third party library, I cannot imbed a reference to the nonGUI object in it, though I can imbed a reference to the GUI object in the nonGUI object. So it looks likeI will have to create a map from a buttons to "regions" somewhere, but where do I put it? In the toplevel window? In the top level model?
Do IU spin off some sort of interface class?
Suggestions?
It would help if you mentioned your platform and language, but generally it sounds like you are describing Model-View-Controller.
Your "GUI" object(s) are the View. This is where you keep all the rendering logic for your user interface. User interactions with the View are handled by the Controller.
The Controller is a thin layer of event handles. User interaction calls methods on the Controller, which then routes them to the Model.
Your "non-GUI" object(s) are the Model. This is the object that contains business logic and whose state is ultimately updated by clicking buttons on your GUI.
You mention "embedding" references between the objects. This is not necessary as long as events in your GUI can be routed by some mechanism to your Controller. This design pattern is useful because it separates your UI logic from your business logic. You can "snap on" a new Views very easily because there is very little event wiring between the View and the controller.
The Wikipedia article has more information and links to implementation examples.
Waste a little time looking at Falcon's Eye (though it is Nethack rather than Rogue). There's a long history of skinning rogue like games (or command line apps in general), which isn't quite classic mvc - it already has a full UI, instead you're adding a decorator to that UI with either a direct translation, or another metaphor (such as gparted, the gnome partition editor, which allows construction of a sequence of partition editing commands by direct manipulation)