Feel free to read the TL;DR: sections at the end of sections to get the gist of it and move on. :D I might do them more often, just 'cause I know my posts are often long and could be summed up more concisely.
Anywho, let's get on with the GUI stuff. As most of you know, the user interface of a program is what the user sees and interacts with when trying to use a program. There are two fundamentally different types of user interface. Thee's the command line interface, which is how we'd be using our programs so far, if they weren't processed in Netbeans:
(Ignore that it isn't Java, it all looks the same!). The second type is the graphical interfaces we'll be looking at this chapter, consisting of windows, icons menus, pointers, buttons and so on (but wait, there's more! I'm a goddamn child). An example is the calculator we all know so well from windows:
Lookit all those buttons and shit! Funnily enough, constructing the graphic interfaces uses, you guessed it, objects! This language, man. Still, building some of these will be ideal practice for using some pre-existing libraries and their methods, so on and so forth. I'm not 100% sure, but there may be some thread material in there somewhere, which might pose a little bit of a problem, but we can burn that bridge when we get to it (I'm aware).
TL;DR: GUIs are made using objects. Look at pictures for examples.
If you want more detailed info than provided, that I for some reason can't provide on being questioned, or you just don't wanna wait:
is a good place to go. Also note if you're looking for good designs, stop. I've got the aesthetic ability of a cracked out raccoon.
If you're building a graphic interface, you'll probably be doing it as a set of components, a lot of which will be visual ones, since they have the representation onscreen. Y'know, the whole graphic part. Using the term component instead of object is just because standard components (scroll bars etc) are themselves groups of objects. Each object in the component has its own responsibilities, like separate classes in a smaller program. It's like inception, with classes. Smaller cogs that control larger cogs which make the machine move. Please tell me that made a little sense. :(
From the programmer's point of view, each component is represented by an umbrella class, which is the class of the interface object. An instance of the component is created just by instantiating the umbrella class. Any other objects required for working behind the scenes are automatically made as part of that instance.
I wish I could give an example without jumping ahead and missing other important introductory info.
TL;DR: Basically, though, you call a button, which is a visual representation of such. But in initializing it, a bunch of behind the scene objects are created to make it work.
Events & Event-Driven Systems
A GUI will operate by responding to events generated by the underlying system. This'll usually be hardware, a key press, or mouse click (Think of the calculator). Even mouse movements (hover over an image online and you get the alt text) or whatever. This is basically the job of the GUI. Wait for a given event, then react accordingly. This kind of event-driven system is different to what we've been doing so far, since so far we've had our main method giving us a clear line of control.
TL;DR: This isn't a normal program. Based on events that happen, such as a button click, the GUI handles it and performs the necessary tasks associated with that event.
AWT and Swing
These are the GUI components and event architectures that come with Java. AWT stands for Abstract Window Toolkit. AWT allows us to work with a GUI without worrying about the underlying details of a computer's windowing system. Not that you would anyway. The way it works means that its fairly heavyweight though, so there's a library called Swing which allows a Java GUI to operate faster and be more responsive. Swing is lightweight and can be built on top of AWT.
Swing provides a fairly large library of classes for building sweet graphic interfaces, in more detail than what AWT provides. A notable feature of Swing is its support for PLAF (pluggable look & feel), allowing the appearance of a GUI implemented in Swing to change on demand, with no messy code rewrites. So that makes design easy. Hell, you can even develop your own general look/feel if you wanted to.
Again, intricate details of what they do is unimportant, but basically we'll be using both.
TL;DR: AWT good. Swing better. It's what we'll be using to build our GUIs for flexibility and huge libraries at our disposal. Custom design and easily switched design at any point without tonnes of code changing, to boot.
I think that's long enough, even with the tl;dr segments, so that's it for now..Questions welcome! Comment, follow, subscribe, share etc, and see you on Monday!
And as part of a shameless plug for a friend, if you're interested in classic movies/books/music, visit his site here (fixed), and feel free to throw loads of criticism at us.