Wouldn't it be interesting if there were a set of modules for building user interfaces that was kind of like DBI is to databases? It would be nice to have user interfaces in perl that were portable beyond ye old Tk programing. What would it be called? SUI (Standard User Interface)??

Replies are listed 'Best First'.
Re: User Interfaces
by Masem (Monsignor) on May 01, 2001 at 21:57 UTC
    It would be nice, but you run into the problem of some features supported on some toolkits, and not on others, and the ways to call such are all different. Sure, I know this is what a unified toolkit would try to solve , but unlike DBI and databases, where there is a nice standard SQL that all of them basically support, toolkits have no such standard so that even trying to distill a subset of GUI elements that would work would be a rather daunting task. Also, you have problems with how events are handled in the various toolkits; this is probably a bigger stumbling block for a perl interface than it might seem.

    The best way to do any sort of problem that might have a graphical interface is to remove as much of the non-GUI-based logic from the code into a module, and then write GUI code that uses that module; this way, if you write a QT app and I'd like to make a GTK version, I don't have to play around with your logic, only do the necessary 'mapping' of GUI elements.


    Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain
      Perhaps you're both right. It would be entirely convenient for there to be a standardized interface with gui generating applications or extensions. And yes, such a standardized language as SQL is required for this kind of an undertaking. Maybe that's what needs to be done. Maybe someone with some experience and three fourths of a brain should whip up an RFC for a standardized interface for GUI apps (SGL -> Standardized GUI Language). Once the community has beaten around a bunch of ideas, a standard could be developed, and then we could work on the DBI equivalents for interfacing each GUI module or application via SGL. A standard has to start as an idea and become a standard. Of course there will be functionality within some specific GUI apps that would not be supported directly through the SGL, but eventually vendors/developers would include ways of accessing this functionality via extended SGL commands.

      *shrug*

      A lack of a standard is often an indication that a standard needs to be developed, rather than a sign that all movement in the direction of a standard is hopeless.

      I think it would be rather keen.

      -=rev=-
        If such a standard would exist, I certainly would consider writing some GUIs after all. My attempts thusfar have stranded at the superficial use of quite a variety of toolkits.

        Such a standard would really be useful IMHO.

        Jeroen
        "We are not alone"(FZ)

      Just an idea that tumbled out while I was doing something meaningless :) Take note, I'm not seriously considering this, I just thought it would be something interesting to throw out. I find that when I work on a project I spend more time working on user interfaces than anything else.

      Besides, I thought it wasn't necessarily just SQL that was important, I thought it was an issue of database drivers, which don't all communicate the same. The SQL commands between databases might be the same, but the method for connecting and communicating would be different.

      I certainly realize that user interfaces can be way more complex than database interfaces in some ways. However, I think the idea is amusing.

Re: User Interfaces
by clemburg (Curate) on May 02, 2001 at 16:48 UTC

    Interestingly, the Xanalys Lispworks Common Lisp Compiler contains such a thing. It is called the CAPI.

    From the docs:

    "The CAPI (Common Application Programmer's Interface) is a library for implementing portable window-based application interfaces. It is a conceptually simple, CLOS-based model of interface elements and their interaction. It provides a standard set of these elements and their behaviors, as well as giving you the opportunity to define elements of your own. The CAPI's model of window-based user interfaces is an abstraction of the concepts that are shared between all contemporary window systems, such that you do not need to consider the details of a particular system. These hidden details are taken care of by a back end library written for that system alone. An advantage of making this abstraction is that each of the system-specific libraries can be highly specialized, concentrating on getting things right for that particular window system. Furthermore, because the implementation libraries and the CAPI model are completely separate, libraries can be written for new window systems without affecting either the CAPI model or the applications you have written with it. The CAPI currently runs under X Window System with Motif, and Microsoft Windows."

    Christian Lemburg
    Brainbench MVP for Perl
    http://www.brainbench.com

      beautiful :) might have to go back and look at Lisp some more
Re: User Interfaces
by jplindstrom (Monsignor) on May 02, 2001 at 10:11 UTC
    DBI is a programming related solution to a programming related problem. Good.

    A similar GUI system would be a programming related solution to a user interface design related problem. Bad.

    Your program might be cross platform. But your users aren't.

    For example, if they boot Windows they expect a Windows GUI. Actually, the deserve a Windows GUI. Anything else will reflect badly on your program, however unfair that is.

    The problem with a cross platform system is the details. Everything has to be right in a good GUI, down to the last pixel.

    Like Masem said, separating logic from presentation is a very good way to go. In some ways it will make your logic more complex (program flow will jump between classes where it previously didn't), in some ways it will make it more clean (things that belong together will be together). It will surely force you to think more about it which is probably a good thing.

    It is easier if you don't mix UI metaphors (like one Command Line Interface and one GUI). Tk and Win32::GUI generally have more in common than they have with a batch style program.

    /J