BPIs: The Simplest GUIs
mimus
programs is counterbalanced by the increased complexity of writing and
size of such GUI programs, using GUI libraries or toolkits such as GTK2+;
indeed, for relatively simple programs, the GUI portion of the program is
often more complicated and larger than the portion which does the basic
work of the program.
One method of simplifying the writing of GUI programs is to write and use
a "visual", "what you see is what you get" (WYSIWYG), rapid application
development (RAD) or GUI builder program such as glade for GTK2+, which is
in essence a GUI program for building GUI programs; this method of course
necessitates writing and learning to use such program.
But the simplest GUI programming of all should be that which takes
advantage of the fact that every general-use platform supports at least
one web-browser which in essence encapsulates the GUI capability of that
platform, by writing GUI programs as simple servers communicating with the
user via ordinary Hypertext Markup Language (HTML)/Extensible Hypertext
Markup Language (xhtml) pages, the same as used on the Web.
Such browser program interface (BPI) programming will substitute for the
above-mentioned complexities a general one-time dealing with the
networking library of the platform for which such programs will written to
provide a "boiler-plate" networking-style interface for that platform, and
then for each specific program the writing of the core program as a server
and the relatively simple writing of ordinary HTML/xhtml pages for the
user interfaces, which latter skill is of course already widespread.
It will also readily allow network interactions with such programs.
Best of all, the functions common to all such servers-- in terms of the
most widely-used approach to network programming, socket-based programming
(a socket is data-storage at either end of a connection between two
programs, consisting of temporary storage of the data being transferred
and information about the connection), such functions consist of creating
a socket, binding it to an address, listening for and accepting a client
connection, and transferring data from client to server and server to
client-- are incorporated into the inetd and xinetd daemons (a daemon is a
residential or continuously-running background system program or process),
the latter incorporating extra security and other internal functions,
which daemons greatly simplify the writing of such servers, reducing such
programming to that of the unique features of each.
inetd (which originated in BSD) and xinetd are available on the vast
majority of *NIX platforms (eg, UNIX, BSD, Linux) and have been ported to
other platforms including MacOS and Windows.
Every ordinary computer user is familiar of course with the
immensely-configurable GUI features afforded by HTML/xhtml, text, fonts,
colors, styles, links, images, tables, text-entry boxes, buttons,
multiple-choice radio-buttons, menus and frames.
Perhaps less widely appreciated is the fact that HTML/xhtml also afford
up-loading of files from client programs to servers, allowing heavy
data-flow to be a true two-way street between server and client, and thus
in BPI programming between user and program.
Finally, HTML/xhtml allow the use of scripting languages, such as
Javascript and Perl, which bring to the HTML/xhtml GUI vast increments of
functionality.
--
Usenet is a strange place.
< Dennis M. Ritchie
Gene
This is a _very_ old idea. I used a java-based local web server GUI
application in 1997. See also AWS for a little web server designed
primarily to provide GUI power to a language with only modest other
GUI development options. One problem is that locally installed
applications are expected by users to have a certain slick look and
feel. These are difficult to provide reliably, especially when you
have little or no ability to control the browser configuration.
Users' expectations are violated when an installed applicaiton summons
a web browser. Installation quirkiness and the requisite open ports
for a web server are problems very expensive to solve. Consequently
the idea never got traction.
mimus
Sure. But let's give it a cool name and acronym and try to push it a bit,
eh?
> I used a java-based local web server GUI
> application in 1997. See also AWS for a little web server designed
> primarily to provide GUI power to a language with only modest other
> GUI development options. One problem is that locally installed
> applications are expected by users to have a certain slick look and
> feel. These are difficult to provide reliably, especially when you
> have little or no ability to control the browser configuration.
Well, they're _user_-configurable, or at least user-IT-guru-configurable . . . .
> Users' expectations are violated when an installed applicaiton summons
> a web browser.
They should get used to it. And having a variety of software available
via bookmark shouldn't offend anyone (might even intrigue some, leading
to actually learning about it all). Especially with a tabbing browser.
> Installation quirkiness and the requisite open ports
> for a web server are problems very expensive to solve.
I favor port 4256 . . . .
> Consequently the idea never got traction.
I'm hoping xinetd will go a long way toward fixing a lot of that.
It calls for a different core programming approach, too, as much so as
standard GUI programming, one not entirely the same as just web-server
programming, since you'll frequently have, say, temporary files being held
in one state or another between page requests . . . .
Taking a slightly different angle on it all, maybe if we can get the
webheads interested in GUI design they'll leave the websites alone so we
can get back on the Web to the concept that content being available to the
widest possible number of readers or customers and browsers and OSen is
what is important, not running the Latest And Coolest Webwarez (demanding
the latest browsers and OSen) . . . .
I know that's radical, but a man can dream, can't he?
--
This is a feature, not a bug.
< The fetchmail FAQ
Alf P. Steinbach
> On Jun 6, 7:06 pm, mimus <tinmimu...@hotmail.com> wrote:
>>
>> But the simplest GUI programming of all should be that which takes
>> advantage of the fact that every general-use platform supports at least
>> one web-browser which in essence encapsulates the GUI capability of that
>> platform, by writing GUI programs as simple servers communicating with the
>> user via ordinary Hypertext Markup Language (HTML)/Extensible Hypertext
>> Markup Language (xhtml) pages, the same as used on the Web.
>>
>> Such browser program interface (BPI) programming will substitute for the
>> above-mentioned complexities a general one-time dealing with the
>> networking library of the platform for which such programs will written to
>> provide a "boiler-plate" networking-style interface for that platform, and
>> then for each specific program the writing of the core program as a server
>> and the relatively simple writing of ordinary HTML/xhtml pages for the
>> user interfaces, which latter skill is of course already widespread.
>>
>> It will also readily allow network interactions with such programs.
>>
>
> application in 1997. See also AWS for a little web server designed
> primarily to provide GUI power to a language with only modest other
> GUI development options. One problem is that locally installed
> applications are expected by users to have a certain slick look and
> feel. These are difficult to provide reliably, especially when you
> have little or no ability to control the browser configuration.
> Users' expectations are violated when an installed applicaiton summons
> a web browser. Installation quirkiness and the requisite open ports
> for a web server are problems very expensive to solve. Consequently
> the idea never got traction.
Please do note that a number of such technologies are currently widespread:
A Windows HTML applications.
An [.hta] file that runs locally.
B AJAX-based web applications.
E.g. most things from Google.
C Various desktop gadget technologies (Konqueror/Yahoo, Windows Vista gadgets,
Mac gadgets, Google gadgets, Opera gadgets, etc.)
D Mozilla XUL.
Mostly for web applications and for Mozilla app extensions, but there's
also work on support for stand-alone local XUL apps.
E Microsoft's programming model for Vista and beyond.
So indeed it's a very old idea, and contrary to your claim it has "got
traction", i.e. become popular and in widespread use.
In all of the example technologies mentioned above applications do have a
"certain slick look and feel". That's not a problem. The main problem is that
the security model for web browsing doesn't mesh well with the required
functionality of a local application, and in terms of that A and E measure up, D
may measure up, and B and C are mostly restricted to GUI side doing the real
stuff on a server (which of course may be a local one, but still).
Cheers & hth.,
- Alf
--
Due to hosting requirements I need visits to <url: http://alfps.izfree.com/>.
No ads, and there is some C++ stuff! :-) Just going there is good. Linking
to it is even better! Thanks in advance!
Richard Heathfield
<snip>
> Taking a slightly different angle on it all, maybe if we can get
> the webheads interested in GUI design they'll leave the websites
> alone so we can get back on the Web to the concept that content
> being available to the widest possible number of readers or
> customers and browsers and OSen is what is important, not running
> the Latest And Coolest Webwarez (demanding the latest browsers and
> OSen) . . . .
>
> I know that's radical, but a man can dream, can't he?
Hear hear. The way I see it, if a Web site crashes my most
commonly-used browser (Galeon), it's the Web site that's broken,
not the browser. There are vastly many broken Web sites (but by no
means all).
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Forged article? See
http://www.cpax.org.uk/prg/usenet/comp.lang.c/msgauth.php
"Usenet is a strange place" - dmr 29 July 1999
mimus
> mimus said:
>
> <snip>
>
>> Taking a slightly different angle on it all, maybe if we can get
>> the webheads interested in GUI design they'll leave the websites
>> alone so we can get back on the Web to the concept that content
>> being available to the widest possible number of readers or
>> customers and browsers and OSen is what is important, not running
>> the Latest And Coolest Webwarez (demanding the latest browsers and
>> OSen) . . . .
>>
>> I know that's radical, but a man can dream, can't he?
>
> Hear hear. The way I see it, if a Web site crashes my most
> commonly-used browser (Galeon), it's the Web site that's broken,
> not the browser. There are vastly many broken Web sites (but by no
> means all).
Flash has been at the top of my Internet hit-list for a couple of years
now, originally for its wond'rous backward-compatibility with itself,
browsers and OSen, then for websites the contents of which are completely
wrapped in Flash with no alternate routes to it, and most recently for
websites that force YouTube downloads on their main pages . . . .
--
Usenet: The Biggest and Oldest and Most Powerful Net-Forum of All!
mimus
This is wonderful, a book-- well, at least a longer article-- on BPI is
writing itself.
--
C: The B-52 of programming languages!
< Amazon review of K&R (2d ed.)
RSN
mimus
The generation of browser program interface pages on-the-fly will allow
easy reconfiguration of the interface itself, eg in number of text-boxes
and button-arrays presented depending on user-query and other
circumstances.
--
C: The First and Still the Best Portable AL!
RSN