Re: [Fsfe-uk] Re: An ignorant question?

[Robin Green]

On Tue, 10 Jun 2003, Chris Croughton wrote:

> On Tue, Jun 10, 2003 at 10:13:21AM +0100, Ralph Corderoy wrote:
> 
> > The OP who wanted a Visual Basic equivalent but `direct to X' probably
> > doesn't realise that X has no concept of push-buttons, scrollbars, etc.
> > It provides only a mechanism in many things, not a policy, e.g. how a
> > scrollbar should look and work.
> 
> Actually, I do -- but my friends who just want to write a simple GUI
> front end for something don't necessarily, nor should they need to.
> What we need is something with the widgets or whatever built in, and
> statically linked into the final app so they don't have to faff around
> with whether they have the right version of shared libraries installed
> (current Linux/X state of the art reminds me of Win3.1, when every time
> you installed a package you had a different and incompatible DLL
> version).

The one key difference:
Windows installers would (and still do, I'm afraid)
render other programs unusable by overwriting DLLs without warning.
A decent Linux package manager shouldn't do that, because of dependency
checks.

I've already tried to make a case that semi-automated installing of
necessary packages to resolve dependencies is better than static linking.
Another issue is security. If everyone dynamically links to zlib, and
a security hole is found in zlib, you only need to upgrade one package.
If everyone statically links to it, you need to upgrade EVERYTHING that 
uses it - and how do you know which ones those are? Are all the programs
you use even MAINTAINED any more?

> For instance, I pulled down the binaries for Squeak/Smalltalk, only to
> find that it wanted a different version of glibc.

The rough equivalent to that in the Windows world would be downloading
a program only to find out that it only runs on Windows XP and you still
have Windows 98. On Windows what do you do... shell out for an OS upgrade?
On Linux you can sometimes get away with just upgrading glibc. I have
done in the past; only once had a problem, which was due to trying out
a bleeding-edge version, not due to any actual need to upgrade glibc.

>  If it hadn't been
> that it would likely have objected to my version of Gtk or whatever it
> uses for the GUI.  At which point I think of compiling from source,

Uhh, how is compiling from source going to solve the problem that it
probably requires features or bugfixes (or even, God forbid, bugs!) which
aren't in your version of Gtk?

Compiling from source is sometimes useful for performance and (pre
GCC3.2) to resolve libstdc++ dependencies (or more accurately, C++ ABI
dependencies). It does not, and cannot, magically make all version
dependency problems go away.

> And I gather they are all incompatible interfaces, yes?

Yes.

>  So what I want
> is a single GUI which lets me choose which widget set I want to use
> (defaulting to whatever) and after that lets me pick from whichever one
> I have selected, without having to load up yet another development kit
> with yet another user interface -- and to say "take my application and
> generate it using Motif (or whatever) so I can see the different style".

So, let me get this straight. You want a single development environment
that can automatically convert your application from Motif to Athena
or Athena to GTK?

I think you'll be a long time looking.

I think a more realistic approach would be to pick two (or possibly three)
toolkits, one for low resource machines and one for high resource
machines. Then if you're coding to low spec machines for a project, your
decision is already made. If not, you can pick one of the two.

Note that Qt/KDE have a number of different "look and feels", so they
can be made to look like other widget sets. However, the default is 
to use the L&F selected in the Control Center, which means all KDE
apps have whichever L&F the user or distro maker has chosen.

> Because the casual user who just wants to knock up a simple GUI doesn't
> want to have to use XYZ for Athena, QWERTY for Motif/Lesstif, VBNM for
> Tk etc., zie just wants to get the job done.

This casual user can look at, off the top of my head:

* xgammon for an example of what Athena looks like
* Muffin for an example of what Motif looks like (it uses Java AWT which
currently uses Motif)
* Bitkeeper for an example of what Tcl/Tk looks like
* GNOME for an example of what Gtk can look like
* Konqueror for an example of what Qt can look like

They don't need a development environment supporting 10 different toolkits
just to see what those toolkits look like.

If they are then programming using 10 different toolkits they are NOT
a casual user by any stretch of the imagination!

Choice is a good thing. But asking for a development environment which
supports all the main toolkits is a bit like asking Microsoft to support
all Borland's stuff in Visual Studio. It Ain't Going To Happen, I'm
afraid.

> The same goes for other applications.  One thing MS have got right is
> that they use VB for scripting in every application which needs
> scripting -- Word, Excel, PowerPoint, etc. as well as "standalone" VB --
> so you only have to learn one language.  This theoretically could be
> done with (for instance) Java, but it isn't, they all do their own.

Well, I certainly agree with that. More apps should support BeanShell
scripting! (A 100% interpreted language very similar to Java, which
is nowadays 90% compiled.)

KDE does allow language-neutral scripting with DCOP, but it's not usually
very useful, or even working. I tried scripting Kate and it worked - 
so long as you only had one file open.

-- 
Robin