Are GUIs always frustrating/tedious?

A place to discuss the implementation and style of computer programs.

Moderators: phlip, Moderators General, Prelates

User avatar
Inglonias
Posts: 126
Joined: Mon Jun 28, 2010 5:54 pm UTC

Are GUIs always frustrating/tedious?

Postby Inglonias » Mon May 14, 2012 11:07 pm UTC

I do most of my code in Java right now, and the only way I know to do a GUI is with the Swing library. Making a GUI that looks the way I like is tedious, and takes a bunch of time I could be using to improve my code. Yes, NetBeans offers a WYSIWYG GUI editor, but I've heard that the code for it isn't as efficient as code I would get by coding my own GUI.

Are there other languages out there that improve the task of creating a GUI for your program, or is this just something I have to deal with, regardless of language. I know that I haven't tried all that many languages. (I have some experience with Python, Java, and GML) so I'm wondering if there are other ways to do a GUI.

User avatar
Sc4Freak
Posts: 673
Joined: Thu Jul 12, 2007 4:50 am UTC
Location: Redmond, Washington

Re: Are GUIs always frustrating/tedious?

Postby Sc4Freak » Tue May 15, 2012 2:07 am UTC

Yes, there are other ways to do it. Try writing an application for WPF (or Silverlight, or Metro in Win8, or anything else that uses XAML).

WPF, Silverlight, and Metro for Win8 all use the same general layout engine and while it can be hard to grasp at first, but it's probably one of the most elegant systems I've seen for GUI applications. The layout of your application is defined by the XAML markup language. You can write it by hand, or you can use a WYSIWYG tool to generate it for you (eg. Expression Blend). The XAML is separate from the rest of your code, which means that the designers (if you have them) can work in Expression Blend to create XAML and the designers don't have to touch any code (designers work on the design/XAML, programmers work on the code). Practically everything to do with presentation can be defined in XAML - layout, animation, etc can be done without touching any code.

While most people are familiar with MVC, the design pattern used in WPF/Silverlight/etc is MVVM (Model-View-ViewModel). The Model is the same in MVVM as it is in MVC - it contains your business logic and data (eg. connections to databases, customer information, configuration data, whatever).

The View is the XAML and the "code-behind". The code-behind has direct access to the elements and properties generated by XAML so you can manually create GUI elements and manipulate them in code if you want. But generally, you'd prefer to do things in XAML rather than in code. If you need to do any really complex layout or initialization for your GUI, the code-behind is where you'd do it.

The ViewModel is the "glue" between the View and the Model. It's an abstraction of the Model, and facilitates communication between the two. You hook up your XAML with your ViewModel. Whenever the Model changes or updates, it notifies the ViewModel, which transforms the information into something suitable to be displayed, and then the ViewModel finally notifies the View (and then the View updates with the new data). The process happens in reverse for input events in the View that cause changes in the ViewModel or Model.

Part of the elegance is the concept of "binding". In XAML, you bind properties of your elements to properties in your ViewModel and the framework handles updates transparently for you. Here's a simplified example (in pseudo-XAML and C#):

In your XAML file:

Code: Select all

<Window Name="MainWindowView" DataContext="MyViewModel">
<!-- ... -->
    <!-- Create a textbox with a binding to the MyViewModel.FooText property -->
    <TextBox Text="{Binding FooText}" />

    <!-- Create a button that will fire an event handler when clicked -->
    <Button Text="Update" Click="UpdateButtonClickHandler" />
<!-- ... -->
</Window>

In your View:

Code: Select all

class MainWindowView : Window
{
    public void UpdateButtonClickHandler(EventArgs e)
    {
        MyViewModel vm = (MyViewModel)(this.DataContext);
        vm.Update();
    }
}

In your ViewModel:

Code: Select all

class MyViewModel : ViewModelBase
{
    public string FooText { get; set; }
   
    public void Update()
    {
        // Update your model if you need to

        /* ... */
       
        // Because the TextBox in XAML has a binding to the Text property in
        // MyViewModel, when you change this variable it's automatically updated
        // in the View (and on-screen).
        FooText = "Hello, world";
    }
}


With this kind of system it becomes very simple and elegant to build large GUIs with complex behaviors. Separation between the code (C#/C++/JavaScript, whatever) and the design (XAML) means you can have one team working on the design independently of the programmers. Automatic binding of properties means you can update the View or the Model with minimal communication and barely any code. And the way this is designed means that the Controller (in the traditional MVC parlance) is obsolete - it's handled by the framework for you. And, of course, you have the same separation of concerns between your View and Model that you get with MVC.

EvanED
Posts: 4331
Joined: Mon Aug 07, 2006 6:28 am UTC
Location: Madison, WI
Contact:

Re: Are GUIs always frustrating/tedious?

Postby EvanED » Tue May 15, 2012 3:36 am UTC

Qt also has some crazy declarative language for doing GUIs. I don't know much about it though, or how it compares to XAML (which will largely bind you to Windows).

User avatar
PM 2Ring
Posts: 3715
Joined: Mon Jan 26, 2009 3:19 pm UTC
Location: Sydney, Australia

Re: Are GUIs always frustrating/tedious?

Postby PM 2Ring » Wed May 16, 2012 2:36 am UTC

For a similar approach which isn't Windows-centric, there is Glade for GTK+, which uses XML for the GUI specification. Although I've created a few GUIs in Python that use GTK, I've never actually used Glade - my GUIs were all fairly simple, so relatively easy to construct directly in code -thus I can't really say much about it. But I do find the concept intriguing as I feel that separating the GUI specs from the rest of the program is a Good Idea.

Ben-oni
Posts: 278
Joined: Mon Sep 26, 2011 4:56 am UTC

Re: Are GUIs always frustrating/tedious?

Postby Ben-oni » Wed May 16, 2012 4:46 am UTC

"Me, too."

Cocoa also takes a similar approach. A series of .xib files contain objects, including the GUI which is usually created in Interface Builder. The peculiar thing in this case is that any object can be placed in a .xib file, which can include controllers, data objects, whatever. When the objects are dynamically loaded from file, relationships between them (targets and outlets) are also loaded, so a text box that links to underlying data links automagically. Need a button to do something? You can write the code into a controller (if you so wished), and declare it an IBAction so that the button can link to it. Custom view objects are also easy: just subclass NSView, and declare the object to be of the new class. Your GUI now has customized behavior.

troyp
Posts: 557
Joined: Thu May 22, 2008 9:20 pm UTC
Location: Lismore, NSW

Re: Are GUIs always frustrating/tedious?

Postby troyp » Wed May 16, 2012 1:43 pm UTC

There's a list of these kind of declarative UI languages on Wikipedia.

Anonymously Famous
Posts: 242
Joined: Thu Nov 18, 2010 4:01 am UTC

Re: Are GUIs always frustrating/tedious?

Postby Anonymously Famous » Thu May 17, 2012 11:23 pm UTC

troyp wrote:There's a list of these kind of declarative UI languages on Wikipedia.

Note to self: Take a look at this list.

Thanks, troyp. That looks like it will be useful.


Return to “Coding”

Who is online

Users browsing this forum: No registered users and 5 guests