fsfe-uk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Fsfe-uk] An ignorant question?


From: Chris Croughton
Subject: Re: [Fsfe-uk] An ignorant question?
Date: Thu, 12 Jun 2003 11:53:55 +0100
User-agent: Mutt/1.2.5i

On Tue, Jun 10, 2003 at 09:01:33PM +0100, Roger Leigh wrote:

> Chris Croughton <address@hidden> writes:
> 
> > Glade doesn't seem to work properly without Gnome, ditto KDevelop with
> > KDE.  I use fvwm (and that's another rant, having applications which
> > depend on a specific window manager is asking for trouble).  I want
> > something which will create straight X applications, not ones tailored
> > to a specific WM.
> 
> Glade comes in two flavours, one is plain GTK+, the other has GNOME
> support.  Neither are dependent on any particular WM.

Hmm, perhaps it's an older version of Glade that just doesn't work,
period.  For instance, when I place a button (or anything else for that
matter) on a created window it immediately expands to fill the whole
of that window and can't be changed by anything I do.  KDevelop wouldn't
even compile without KDE installed.

> BTW, nowadays Glade is not meant for use as an IDE (unlike KDevelop,
> which is); it's a UI designer, full stop.  You load the saved XML
> interface description using libglade, though for small projects I tend
> to just create the interface "by hand"--gtk_box_pack_start()
> et. al. aren't /that/ difficult.

Well, for small non-interactive things I use my own C++ class which does
both X and Postscript, but that is strictly output-only (and the X part
has some limitations, it assumes that it can get the kind of display it
wants and fails disgracefully if it can't).

> > (And another common thing with X applications --
> > where are the keyboard shortcuts?  Far too many of them assume GUI =>
> > pointing device, and forget about keyboard shortcuts, which is something
> > even MS are not bad at.
> 
> Agreed.  Many programmers seem to forget that the keyboard exists.
> GTK+ 2.x are vastly better WRT this; I've written GTK+ programs that
> can be used completely from the keyboard--it's not a lot of effort to
> set up the hotkeys, focus movement through dialogues and so on.  If
> you are forced to use the mouse, it's badly designed, IMHO.

Well, not quite IMO.  There are some things which are pretty silly using
the keyboard (or horribly slow), like some interactive graphics work,
just as there are some which are silly using the mouse (entering keys
for example).  But everything else should be able to be done with both,
not necessarily exactly as easily but not difficult.

For instance, my 'benchmark' application for a GUI, Noteworthy Composer
('doze only).  It's a music scoring package, and the interface does
allow everything to be done with either mose of keyboard.  OK, so some
of that is via menus, but neither ALT-I E or mouse menu click and select
is all that onerous.  Inserting a treble clef is one click on the mouse
and two keypresses, inserting a note is two clicks on the mouse or one
keypress.    Either way entering and editing the music is fast.  The
only thing in the interface it doesn't have is a macro facility.

> [...]
> > As seen above -- "try this for Gnome, that for KDE, or build it from
> > source for something different", most people will say "I'll use VB,
> > I know that works".  And so, when I actually need a simple GUI, will
> > I, because I need something that works /now/, where I can learn 90%
> > of what I need through the help text and actually write an app in
> > under half an hour.
> 
> All the VB apps I've had the displeasure to use were complete pants,
> combining RSI-inducing interfaces with dog slow code.

I could say the same about Tcl/Tk apps.  It's not a feature of the code,
it's whether the programmer bothered to design it properly.  Just like
the lack of 'hotkeys', which can happen with any design (but is less
likely to happen in 'doze apps because 'doze users expect them; Mac
users on the other hand seem to forget that a keyboard is even there
except for text input; *ix programmers should know better but most seem
to be so wowed by the "graphics, man!" that they forget).

> Learning a "proper" language and GUI toolkit will seem rather
> difficult at first, but the quality of the work you will be doing will
> (potentially!) be of a much higher standard.

I don't know whether you consider C++ to be a 'proper' language.  I can
switch to C, Fortran, Pascal (spit!), Perl (double spit!), Awk or even
CORAL-66 or ALGOL (but please not!) if you prefer.  Or even COBOL,
although I haven't written a COBOL program for about 28 years.

In general, though, if I want menu and form type interfaces I'll use
(n)curses, which work almost anywhere (certainly anything with terminal
and POSIX.1 emulation).  It's only on the rare occasions that it would
be nice to see a load of changing data as graphics that I need a GUI.

But it's usually faster for me to knock up a small server app in VB to
display the data, and have the acual program send it the data, than to
mess about with graphics interfaces under X.

> If you want to do something "right now", you're out of luck--you'll
> need to invest some time into learning the fundamentals of your chosen
> toolkit.  I'd suggest getting GTK+ (2.2), Qt (3.x), gtkmm (2.x), or
> whatever takes your fancy, and work your way through the tutorials and
> docs.  In a few weeks, you'll be up to writing seriously complex UIs.

You mean the sort of thing I wrote within half an hour in VB, having
never seen VB before (and it bears very little resemblance to Dartmouth
BASIC or even CP/M MSBASIC)?

> As an example of a simple sort-of-RAD application, see
> http://www.whinlatter.uklinux.net/gtk/ogcalc.c.  This took about six
> hours to write, being unfamiliar with GTK+.  I used Glade to design
> the interface, then constructed it by hand.  If you used Glade to do
> all the interface, all you would need to do is write the callbacks and
> load the interface--this would take a matter of minutes.

Hmm, as far as I can see (and I haven't tried compiling or running it
yet) it calculates how drunk and heavy you really are (%ABV and OG)
based on your glasses prescription (RI), how heavy you feel (PG) and a
corrective factor <g>.  More probably, it's something to do with
fermentation.  But the comments don't say...

(I don't see from that code how the window or the widgets in it are
positioned.  Is something missing, or is it just buried in the code
somewhere?)

> If this doesn't appeal, there are non-free tools like Kylix, but it's
> not very popular in the Free software world.

Which is my point, at the moment people are still having to go to
non-free software to do what they need.  And since most RAD GUI stuff
I've seen is in-house (in fact all such that I have written has been for
employers or just for myself, when what was wanted was a low-cost
interface to something we were doing not for distribution) people are
going to go with what works.  I think my (legal) copy of VB cost me 25
quid on eBay (it's not the latest version, but that's fine by me), if it
takes me more than an hour to get "up to speed" on some other system
then it's not worth it.

> [OT: It's over ten years since I last touched any BASIC-like stuff,
> but I just started a new job, after a long period of unemployment,
> writing software (unfortunately proprietary) for DOS-based
> point-of-sale terminals.  After several years of coding with
> C/C++/etc. on UNIX, it was quite a shock to use a (BASIC-alike 4GL)
> language mostly written without things you take for granted, like
> functions, types, structures, ADTs etc.  As an aside, they are
> considering moving to GNU/Linux on MIPS, which sounds a lot more like
> home!]

Well, as I said VB is not now very much like BASIC, it has functions,
subroutines, types, scoping, structures, classes, methods, etc.  In fact
most of it is done using instantiations of classes (objects), for
instance you just create an instance of a 'button' and set its
properties, overload its default event processing methods, call its
methods etc.  And importantly all of the standard event handling is
built-in.

> Partly because of this, and what Paul Johnson wrote, as well as
> thoughts I've been having over the last few years, it seems like a
> full accounts package for GNU/Linux would be perhaps /the/ killer
> application for encouraging the adoption of Free software.  I do have
> some experience of GTK+ and PostgreSQL I am willing to contribute if
> any like-minded people are interested in collaborating on this (I
> don't yet have a great knowledge of accounting, although I will be
> learning quite soon for my job).

Hmm, I have very little knowledge of accounting at all (balancing my
bank account and predicting cash flow is about as far as I get, I've
heard of "double entry" but it sounds like something you'd get arrested
for!).  And my idea of a good database is usually a flat ASCII file
searched with grep or awk (I keep thinking I ought to learn MySQL but I
don't have any application I need it for).

Chris C




reply via email to

[Prev in Thread] Current Thread [Next in Thread]