Very Computer

Yes

Quote:> is correct, then I assume that I should not code specifically for KDE
> but instead do general coding for X11?  Would this assure me that my
> application could run on all flavors of Linux or are there other
> issues that I should check out first?

It would generally assure you that your application will run on X11. For
the most part this is a safe bet, although somewhat lacking in the
higher level functions you find in GNOME or KDE, or other WM/DE.

Quote:

> 2) What is the best editor for doing development under Linux?  I don't
> mind using make files to do the compilation/linkage but I would like
> an editor that supports at least the following basic stuff:
>   - syntax highlighting
>   - intelligent indent
>   - block indent/unindent
>   - permit having more than one file opened at the same time
> A bonus would be the possibility of customizing the keyboard shortcuts
> (I'm used to the Brief keyboard but am more than willing to learn a
> different one).  Another bonus would be the support of macros (or some
> kind of scripting language).  Of course, a nice IDE would also be
> nice, provided that it works with Corel LINUX and is currently
> available :-)

emacs lets you do all that and its free. If you are more used to
something like a VC++ editor, check out Visual SlickEdit ($).

Quote:

> 3) Is the de* that comes with Linux (aka gdb) worth spending time
> learning it or are there better ones out there.

Of course it is because any of the razzle-dazzle de*s I have used
just utilize gdb under the covers. I would then suggest checking out
DDD.

Quote:

> 4) Is there some build-in programmers documentation for X11
> programming?  What about good books on the subject?

Yes if your installation included it but otherwise it is free somewhere.
And there are massive volume of books on X development. Either go, or
browse, your favorite store. I am sure others will fill in their
opinions replete with ISBN.

Quote:> 5) If I do decide to develop for a specific "desktop", which one is
> the most popular (if any) and how popular is KDE?

The two that seem to be most used are GNOME and KDE. Or you can write
your own and make it the most popular.

Quote:> 6) Any other comments to help me start out in the right direction?

Patience.

Quote:

> Tia,
> Denis

--
Frank V. Castellucci
http://www.veryComputer.com/
OOA/OOD/C++ Standards and Guidelines for Linux

Centuries ago, Nostradamus foresaw a time when Denis Sarrazin would say:

Quote:>Hi,

>I just installed Corel LINUX and I am planning on developing a variety
>of GUI applications to run under Linux.  I'd like to support all
>flavors of Linux, not just the Corel version since I plan on
>distribution my applications.  

>Since I will be doing C++ programming, for the compiler, I was
>thinking of using gcc/g++ (which I think is supposed to be fairly ANSI
>C++ compliant?).  

There do exist other options; KAI and Comeau C++ are available.
Perhaps preferable for some purposes; if you're a beginner at this,
you're highly unlikely to see any differences they offer, and as G++
develops further, their (possible) advantages gradually "evaporate."

Quote:>What I am wondering are the following:

>1) although CorelLinux comes with KDE, it is my understand that KDE is
>just one possible "desktop" available for Linux.  I think that all of
>them are running over X11 (aka X-Windows?) though, correct?  If this
>is correct, then I assume that I should not code specifically for KDE
>but instead do general coding for X11?  Would this assure me that my
>application could run on all flavors of Linux or are there other
>issues that I should check out first?  

KDE and GNOME are both "desktop environmnents."  

From a "user's" point of view, they both represent sets of
applications that use common libraries and which thus (in each set)
share greatly in terms of "look and feel."

From a *developer's* point of view, KDE and GNOME are two competing
sets of application development libraries.  They thus offer
"application services" like:
  - A GUI (Qt vs GTK)
  - Config file management
  - XML parser
  - Interprocess communications (via CORBA)
  - Various other such "stuff."

You're incorrect in thinking that they "take over;" both systems run
as a set of libraries and applications, and since they are in distinct
files and processes, they can co-exist quite happily on the same
desktop at the same time.

Granted that you can only have one window manager; that is the program
that controls everything that is *outside* the scope of *all* the
windows.

<http://www.veryComputer.com/~cbbrowne/xdesktop.html>

Quote:>2) What is the best editor for doing development under Linux?  I don't
>mind using make files to do the compilation/linkage but I would like
>an editor that supports at least the following basic stuff:
>  - syntax highlighting
>  - intelligent indent
>  - block indent/unindent
>  - permit having more than one file opened at the same time
>A bonus would be the possibility of customizing the keyboard shortcuts
>(I'm used to the Brief keyboard but am more than willing to learn a
>different one).  Another bonus would be the support of macros (or some
>kind of scripting language).  Of course, a nice IDE would also be
>nice, provided that it works with Corel LINUX and is currently
>available :-)

There are two "churches" of the Emacs "religion," GNU Emacs and
XEmacs.  Both do all that you mention, and have 20 years worth of
customization added to them, which means they can (and do) do things
you'd never have thought of.  Quite capable as capable assistants in
development.

JED is an "emacs clone" that is much smaller and faster, yet with much
the same ability to do the things you ask of.

These days, there are X-based VI clones (gvim comes to mind) that also
offer syntax hilighting, indentation support, and such.

<http://www.veryComputer.com/~cbbrowne/editors.html>

Quote:>3) Is the de* that comes with Linux (aka gdb) worth spending time
>learning it or are there better ones out there.

There are several graphical front ends, including one called "ddd;"
I'm not sure where the preponderence of preference lies.  I don't do
much C++ debugging, so I can't provide authoritative suggestions here.

Quote:>4) Is there some build-in programmers documentation for X11
>programming?  What about good books on the subject?

You're likely to not directly write X11 code; you'll probably look to
one of the 3-4 common GUI libraries:
  - Qt
  - GTK
  - FLTK
  - Take a chance, look at GNUstep/Objective-C!

None are forcibly tied to X11, as all can also operate on some other
system (whether MacOS or Win32), and thus do not mandate that you
directly know a lot about X11.

<http://www.veryComputer.com/~cbbrowne/xwindows.html>

Quote:>5) If I do decide to develop for a specific "desktop", which one is
>the most popular (if any) and how popular is KDE?

GNOME and KDE are the two most popular "desktop" projects.  I suggest
you take a look at their web sites (www.[project-name].org), and, in
particular, look at the architectural designs.

Whichever architecture you like better will help suggest where you
should head.

Quote:>6) Any other comments to help me start out in the right direction?

"What is the purpose of a person acquiring perfect French
pronunciation if they have nothing of value to say in any language?"
-- Walter Ong

Something you'll find in looking at the GNOME and KDE projects is that
in many application areas people have things fairly "well-staked-out."
You may need to have a clear model of something useful (and reasonably
specialized) that you are interested in helping to build.  There is,
for instance, little need for there to be Yet Another Kludged-up File
Manager.  (Both GNOME and KDE have had to start over on their file
manager projects.)

Learning French is a whole lot more useful if you actually have a
concrete plan as to what to do with it.  And that plan will suggest
what sorts of vocabulary you need to concentrate on.  Attracting a
French girlfriend may need different vocabulary from learning French
cuisine (kitchen French) versus a plan to know French Revolutionary
history.

In the same way, if you have some class of application that you want
to build, that will inform your search for useful information.  And if
you have no idea, that risks being equivalent to "having nothing of
value to say in any language."  Food for thought, I hope...
--
"Who is General Failure and why is he reading my hard disk?"

[...]

Quote:> I will be using templates a fair bit for my main project (in
> particular, base classes that are templates) and hopefully gcc can
> handle these things.

Try it and see.  I'm not an expert, but gcc-2.95.2 has pretty good
template support I think, and the STL supplied with it is close enough
to the standard that most people would be happy with it.  Earlier
versions have progressively less support for templates.

[...]

Quote:> One question/clarification: are you saying that I could open and run a
> Gnome application while running KDE?  Or vice versa?

Yes to both.  What does it mean to be "running KDE" anyway?  One runs
an X server (which is chosen by what kind of hardware you've got), a
window manager, and a collection of whatever X applications you wish.
(The window manager isn't compulsory, but most people run one, most of
the time.)  

KDE supplies a window manager, and kdestart starts this window manager
and a collection of KDE applications, but that's all---you're free to
run (for example) Netscape (which uses Motif libraries), or xclock
(which uses Athena widgets, I think), or any of the GNOME
applications.  KDE and GNOME also provide file managers; they're just
applications, albeit applications which can put things on the root
window.

[...]

Quote:> Early today, I found a Linux GNU C++ book at the local computer book
> discount store and there is a section in it that introduces Xlib.  I
> tried out the example and got the thing to work (interestingly, the
> "window" appeared with the same "skin" as all of the other KDE
> windows so I guess KDE controls the appearance of windows even if I
> write no special code for it - nice).

Not quite.  Window managers put the edges around applications
(typically a titlebar, perhaps with buttons, possibly a border, and
often handles of some sort so that users can resize the windows).  But
that's all: everything inside the window is done by the application.
So the KDE window manager was putting its titlebar and other bits
around your application---had you had any widgets (scrollbars or
whatever) in your application, they'd have been using whatever widget
library your application was linked with.

It's that that gives X its reputation for inconsistency: different
applications may have different scrollbars, different dropdown menus,
different internal focus policies, etc.

[...]

Quote:> Got also the O'Reilly book on GNU Emacs (although it is for version
> 19 and I've got version 20 -- hopefully the changes between the two
> versions aren't too big).  I also got a copy of Emacs for DOS/Win32
> so that I can use the same editor in both environments.

The Help menu should have a "News" somewhere.  That shows the
differences between versions.  However, it's probably not
significant---virtually everything in the book will still be valid in
version 20, and in XEmacs, should you try that.

[...]

Quote:> > You're likely to not directly write X11 code; you'll probably look to
> > one of the 3-4 common GUI libraries:
> >   - Qt
> >   - GTK
> >   - FLTK
> >   - Take a chance, look at GNUstep/Objective-C!

> > None are forcibly tied to X11, as all can also operate on some other
> > system (whether MacOS or Win32), and thus do not mandate that you
> > directly know a lot about X11.

> I'll check out your link to find out more about each.  I'll try to
> find a good book on whichever appears to best suit my needs.

I think Qt costs money for Windows development.  And for commercial
Unix projects, for that matter.  I don't know whether your intended
use would fall in to the category which would require payment or not.

It's probably a good idea to check that kind of thing, if only to rule
out some alternatives.  Gtk+ falls under the lesser GNU general public
license, I think, which should be acceptable.  Don't know about FLTK
or GNUstep.

[...]

I used the interactive tool called Corel Update which basically does the
same thing.  The only diff is that instead of using "stable" in the
above links, it uses the word "slink", whatever that means.  I'll
investigate to try to find out what the diff between slink and stable
(static link, maybe? although I'm not sure what that would mean in this
context).

Thks,
Denis

Do the widgets come with the GTK+/Lesstif/Qt libraries or as part of
KDE/GNOME specific libraries?

Quote:> Corel Linux is indeed based on Debian; it strips off rather a lot of
> stuff.

I suspect I could find a good book on Debian Linux at one of the
computer discount stores hereabout.  This may be useful to get to
understand Corel Linux in more specific details.

Quote:> O'Reilly has a book on Qt that looks quite good; New Riders have a
> couple books on GNOME and GTK that are pretty good.  If you've got a
> Borders or Barnes & Noble nearby, they're likely to stock them.

I'm in Canada so no Barnes & Noble.  We do have "monster" stores such as
Chapters that are equivalent.  We also have relatively smaller book
store chains (the best one for computer books hereabout is called
Prospero).  I'll check out for books on these various topics of interest
once I've checked out some of the info online (to get at least a general
idea which one(s) I'm most interested in -- no need to buy all of the
Linux programming books out there<g>).

Quote:> GNOME has some libraries to help you hook up to databases via ODBC;
> KDE may provide similar; I'm not certain.

I thought ODBC was a Mickeysoft specific thingie -- didn't know it
existed in the Linux world.  I'll have to check it out.  Right now I'm
looking at the Berkeley DB (v1) library although I need to acertain
whether I can use it in a "shareware" application or not.  It does seem
to be installed on my Linux and it may be good enough for what I need to
use it for.  Or not.  I got one of the Linux Journal mag that focuses on
databases so I'll be going through that as well.

Quote:> You've got a pretty big task ahead; you probably need to be prepared
> to prototype some components with the expecation of throwing them
> away as "first tries."

Of course.  A great way for me to learn is to try to do things and see
what problems I run into.  Then fix them.  Great learning experience
even if it does mean that I may have to throw away some of the stuff I
do as my understanding matures.

Quote:> A significant thing to do is to look into what mailing lists exist for
> the respective environments so that you can get input from people that
> know them intimately.

Thanks.  Once I've narrowed things down a bit more, I'll make sure to
join the appropriate mailing list for those tools that I want to use (or
investigate seriously).

Denis

I just checked and Corel/Debian Linux come with gcc 2.7.2.3 and g++
(which is the name they give to egcs) 2.91.66.  I checked the Debian web
site and 2.95 is not yet in the "stable" area, it is marked as frozen.
For now, I'll stick with g++ 2.91.66 and check weekly to see when 2.95
makes it to the stable state.  I suspect that there would probably not
be any problems using 2.95 as it stands but I'd rather be safe then
sorry :-)

Quote:> If you really want your program to be very portable, don't think in terms of
> KDE or GNOME.  You will not want to tie your program to either of them.  Now,
> this does not mean that you should avoid using GTK+ or Qt as your development
> library for the GUI.  GTK+ is not GNOME, and Qt is not KDE.  It just happens
> that they use these libraries as their foundation, and as a unifying factor
> in the applications that are written specifically for these desktops.  You
> can very happily write a program using GTK+ for your GUI and run it under KDE
> or any other desktop or window manager, so long as the user has GTK+
> installed.  The same goes for using Qt. This generally is not a problem.
> Installing a widget library is a much smaller task than installing a whole
> group of desktop software.

Thanks.  I've been receiving a lot of useful info (both via email and on
this newsgroup) that is helping me get a clearer idea of where the
pieces fit.  

As you state, it is better for me to just look at the GUI libraries
(such as Qt and GTK+) and decide which one I like best and then use it.
I don't need to worry or care too much about which Windows manager is
actually running, I believe (for example, I'm running under kdm which is
the KDE manager, unless I'm mistaken).

To try to compare a bit with Win32, I would guess that KDE is closer to
what Explorer is, GTK+ and the likes might be compared to MFC, and X11
would be the Win32 APIs and the underlying Windows operating system (os
may not be the right word here <g>).

For people to be able to run my application regardless of which Windows
manager (KDE, GNOME, etc), they would need to have the libs for
whichever GUI toolkit I decide to use installed on their copy of Linux
(or maybe I can even statically link these?).  Note that I do not plan
on distributing the source code for my application: does this mean that
I have to recompile it on different flavors of Linux or will the same
compiled executable run on all versions of Linux using the same
processor (aka Intel)?

I will start by looking at the libs that come with my Linux and the free
ones (GTK+ is free but didn't fully come with my Linux).  At this
initial stage, I'm particularly interested in both GTK+ and Lesstif
(both being free and I have Lesstif already installed on my Linux, I
believe).  I'll need to find out the diff between Lesstif and Motif (and
whether I can write a Motif app but not require users of it to buy Motif
or not).  In any case, the number of questions regarding each of these
will likely grow exponentially (<s>) so I'll check their web sites and
gather more information (including looking through their tutorial,
trying to get a list of the widgets that come with them if any,
gathering a list of apps build with them, finding sample code, joining
their dev mailing lists, etc.)

Quote:> While you don't really need to have a deep understanding of X in order to
> program with GTK+ or Qt, you really ought to understand the basic
> architecture and ideas underlying it.  Learn the basics of the philosophy and
> architecture of X.  For example, it is somewhat important to know that X was
> designed to be network transparent, so that you can run an application on any
> machine, and display it on any other.  It is important to understand what the
> X server is, what a window manager is, and what they both do.  You ought to
> have an idea of how your program interacts with these two pieces of software,
> though you don't need to know all of the details.

Yes, that is what I want.  Someone else compared it to a client-server
architecture.  I saw the event-driven side of things in a quite intro
look at it.  I'll I need is to spend more time with it at a highlevel
and then try things at a "practical" level (throw-away code, as someone
else mentionned).  Of course, this will give me a chance to practice and
learn Emacs at the same time and I want to learn cvs too, amongst other
things.

Thanks for the info.

D

[...]

Quote:> I used the interactive tool called Corel Update which basically does
> the same thing.  The only diff is that instead of using "stable" in
> the above links, it uses the word "slink", whatever that means.
> I'll investigate to try to find out what the diff between slink and
> stable (static link, maybe? although I'm not sure what that would
> mean in this context).

Debian releases are named after Toy Story characters, I believe.
slink is presumably one of them.  stable is a link to whatever is
currently the stable version; that should be changing relatively
shortly to potato (which is becoming stable).

So "slink" is a specific version, "stable" represents whatever the
current stable version happens to be.

Very cute.  I'll keep checking until potato becomes the stable one
(sounds kinda funny when I say it, but when in Rome... :-).  Thks.

D

Quote:Denis writes:
> I used the interactive tool called Corel Update which basically does the
> same thing.

Corel Update is a front-end for apt.

Quote:> The only diff is that instead of using "stable" in the above links, it
> uses the word "slink", whatever that means.

'slink' was the code name for the stable distribution (Debian 2.1) while it
was in development.  When the currently frozen 'potato' distribution is
released as 2.2 stable will point to it instead of slink.
--
John Hasler

Dancing Horse Hill
Elmwood, Wisconsin

Quote:Denis writes:
> I checked the Debian web site and 2.95 is not yet in the "stable" area,
> it is marked as frozen.  For now, I'll stick with g++ 2.91.66 and check
> weekly to see when 2.95 makes it to the stable state.  I suspect that
> there would probably not be any problems using 2.95 as it stands but I'd
> rather be safe then sorry :-)

You would be quite safe with 2.95.  Most of the packages in frozen were
compiled with it.  It is the distribution that it is in that is not yet
stable, not the compiler.  Debian builds an entire distribution and then
releases it as a whole.  However, we try very hard to support incremental
upgrades.
--
John Hasler

Dancing Horse Hill
Elmwood, Wisconsin

As a quick follow up to my original request for help, I just downloaded
and installed Glade.  This is a very cool (at first glance) front end
for Gtk+ development.  Wow.  I tried it and developed a simple screen
with a button and toolbar and added an event handler for the click event
(aka signals in XWindows parlance).  Generated the C code and did a
make.  Worked like a charm.  I think I'll play with this choice
combination (Gtk+ / Glade) for now as it seems to do everything I need
it to (including notebooks).  I'll join the mailing lists, of course.

Does anyone have experience with this combination of tools?  Would you
say it is a fair/good choice to do GUI development of applications for
Linux?  Are there any serious problems with this set of tools when the
size of the application grows beyond the trivial?  Anything else that I
should know before investing a lot of time on these two tools (together
with a bunch of other ones, of course)?

Thks,
Denis

Unless, of course, you tried to compile a new kernel with it,
in which case the last egcs or gcc-2.7.2.3 would be stable
choices.

--
Dave Blake

: Hi,

: I just installed Corel LINUX and I am planning on developing a variety
: of GUI applications to run under Linux.  I'd like to support all
: flavors of Linux, not just the Corel version since I plan on
: distribution my applications.  

: Since I will be doing C++ programming, for the compiler, I was
: thinking of using gcc/g++ (which I think is supposed to be fairly ANSI
: C++ compliant?).  

: What I am wondering are the following:

: 1) although CorelLinux comes with KDE, it is my understand that KDE is
: just one possible "desktop" available for Linux.  I think that all of
: them are running over X11 (aka X-Windows?) though, correct?  If this
: is correct, then I assume that I should not code specifically for KDE
: but instead do general coding for X11?  Would this assure me that my
: application could run on all flavors of Linux or are there other
: issues that I should check out first?  

You are right. You should program for X window rather than KDE.
But this doesn't prevent you from using all the best features of KDE.
Anyway, you'll need some GUI toolkit for writing GUI program.

(it is not just library like MFC, it is rather combination of such
library with features provided by USER32 module, when pure Xlib is
compatible with GDI by features)

If you are programming C++, you may well choose same toolkit as KDE uses
- QT. There are a lot of others,  C++ ones as fltk, pure C ones, like
Xaw, Motif or Gtk, and ones which are oriented toward highlevel
languages like Tk.

Once you choose toolkit you are free to either support high-level
features of KDE (for which you'll need to link with some KDE specific
libraries) or not.

: 2) What is the best editor for doing development under Linux?  I don't
: mind using make files to do the compilation/linkage but I would like
: an editor that supports at least the following basic stuff:
:   - syntax highlighting
:   - intelligent indent
:   - block indent/unindent
:   - permit having more than one file opened at the same time
: A bonus would be the possibility of customizing the keyboard shortcuts
: (I'm used to the Brief keyboard but am more than willing to learn a
: different one).  Another bonus would be the support of macros (or some
: kind of scripting language).  Of course, a nice IDE would also be
: nice, provided that it works with Corel LINUX and is currently
: available :-)

You've described features which are "must have" for real Unix editor.
So you may choose from two main ones - vi (in any of its modern
incarnations) or Emacs.
Of vi clones, I'll reccomend vim. It have all things you described and
it allows to use any of main three scripting languages (Perl, Python,
Tcl) for macros. It also allows to call make from inside editor and, if
some errors was reported, allows to jump cursor around them.

Emacs, on other hand is kind of "operationg system in one program thing"
It uses Lisp as its macro language, and includes WWW browser, mail
client and psychoanalyst program written in Lisp inside editor.
It may be hard to learn, but if you like it, you never would use
anything else.

: 3) Is the de* that comes with Linux (aka gdb) worth spending time
: learning it or are there better ones out there.

Yes. Most of other ones are just frontends to gdb. The more you would
unix the more often you'll see that if there is program which does its
job well, people don't rewrite it if it lacks some features. They just
write another small program, which does required thing and calls already
existing tool to do the rest.

: 4) Is there some build-in programmers documentation for X11
: programming?  What about good books on the subject?

There is a lot of docs in Debian Linux system (and Corel Linux is just subset
of Debian with few bells and whistles like KDE added)
So, if Corel doesn't include package Xbook and you don't mind download
16Mbytes of compressed documentation, just download this package from
www.debian.org and install in your system.

Of course, besides xbooks, there are manual pages for each X function,
but manual pages are good when you are knowing name of function.

There is also books from O'Reilly and associates - 7 volumes series
about X window which cover everything from protocol reference to writing
your own window manager.

: 5) If I do decide to develop for a specific "desktop", which one is
: the most popular (if any) and how popular is KDE?

There are two main ones - KDE and Gnome. There is also CDE, but it is
from the world of commercial Unices, not from Linux, althogh linux port
exists. So, if you manage to develop your app so it would work with
both, probably you users would be satisfied. And, considering all
efforts both development teams undertake to achieve compatibility, this
is possible enough.

: 6) Any other comments to help me start out in the right direction?

Postpone you GUI efforts for while and learn basics of Unix system first
- forking, interprocess communications, interoperability with shell.
It is also worth learning why C++ is considered low-level language.
Spend few days with Python, Tcl and Scheme.

--
I'm telling you that the kernel is stable not because it's a kernel,
but because I refuse to listen to arguments like this.
        -- Linus Torvalds

I knew it was 2.9something, I just wasn't running it to check it.  As someone else
mentioned, 2.95 is stable and is safe to use, but 2.91.66 may also be sufficient
for your needs.

Actually, g++ is not the new name for egcs.  egcs essentially replaced GCC and is
now called GCC.  So GCC is the new name for egcs.  g++ is a wrapper around GCC that
sets it up for compilation of C++ code (it calls gcc with the appropriate set of
command line arguments).  It really is an integral part of GCC.  It may be,
though,  that Corel decided to make g++ be a wrapper around egcc (GCC 2.91.66),
which was probably a wise choice, since GCC 2.91.66 handles newer C++ constructs
better.  The only real difference between compiling a program using egcc and g++
(in this case) is that g++ will treat the source file as a C++ file, even if it is
only a C file, whereas egcc by default will look at the file's extension and
determine whether to treat it as a C or a C++ file.  A file ending in ".c" will be
treated as a C file, and a file ending in ".C", ".cpp", ".cxx", etc., will be
treated as a C++ file.  One thing to note is that if you are mixing C and C++
source files, it will make your life easier to compile them all with g++ to avoid
name mangling problems.  Otherwise, I'm not sure there is any real benefit to using
g++ instead of egcc.

Quote:> As you state, it is better for me to just look at the GUI libraries
> (such as Qt and GTK+) and decide which one I like best and then use it.
> I don't need to worry or care too much about which Windows manager is
> actually running, I believe (for example, I'm running under kdm which is
> the KDE manager, unless I'm mistaken).

Almost.  kdm is the K display manager which controls X login sessions.  kdm is
KDE's version of xdm (X Display Manager).  You can get some info about xdm to get
an idea of what its job is by typing "man xdm" at the command prompt.  kwm is the
window manager used by KDE.  It's not a big deal, but there is a difference between
the jobs of kdm and kwm.  It won't affect your work any, but it still may be nice
for you to understand it.

Quote:> To try to compare a bit with Win32, I would guess that KDE is closer to
> what Explorer is, GTK+ and the likes might be compared to MFC, and X11
> would be the Win32 APIs and the underlying Windows operating system (os
> may not be the right word here <g>).

You're getting closer.  I would say KDE is more like the whole Windows desktop
including the task bar, start menu, etc.  For me, Explorer is just a fancy file
manager.  kfm does much of what Explorer does.  You're right that GTK+ or Qt is
like MFC, and X11 is more like the graphics parts of the  Win32 API.  X is totally
separate from the operating system, so the analogy kind of stops there.  Under
windows, the windowing system is integrated into the OS, whereas X is a separate
process that runs on top of the OS just like any other process.  It just happens
that this one is graphical.

Quote:> For people to be able to run my application regardless of which Windows
> manager (KDE, GNOME, etc), they would need to have the libs for
> whichever GUI toolkit I decide to use installed on their copy of Linux
> (or maybe I can even statically link these?).  Note that I do not plan
> on distributing the source code for my application: does this mean that
> I have to recompile it on different flavors of Linux or will the same
> compiled executable run on all versions of Linux using the same
> processor (aka Intel)?

It's possible you will need to recompile your program for different Linux
distributions, though you may not need to, given that more recent distributions
(aside from Debian, as far as I know) use most of the recent libraries.  At the
least, you will need to let the user know what libraries are required by the
application, so they can update their system if necessary.  You will also want to
consider how it is packaged.  You will probably want to produce an RPM package, a
Debian package, and perhaps a gzipped tar file.

I think the biggest problem you may run into will be with the C and C++ library
versions.  Some systems are still using the libc5 C library, whereas most new ones
are using glibc2 (or libc6).  There are not compatible, so you will either need to
compile your program for both and create a package for each, or simply decide that
you will use one or the other and let the user know which is required.  Also, since
you will be using "standard" C++, you will need to take into account the C++
library used.  Since you are compiling with gcc 2.91.66, you will be using
libstdc++.so.2.9.  Many systems with a recent but not completely current
distribution will have libstdc++.so.2.8.  The two can coexist peacefully, so it's
not a big deal, but the user will need to know which library is required, so they
can install it if necessary.

Quote:> I'm particularly interested in both GTK+ and Lesstif
> (both being free and I have Lesstif already installed on my Linux, I
> believe).  I'll need to find out the diff between Lesstif and Motif (and
> whether I can write a Motif app but not require users of it to buy Motif
> or not).

Lesstif is an opensource project whose goal is to create a widget library that is
source compatible with Motif 1.2.  In other words, Lesstif is designed to be a
drop-in replacement for Motif.  So, if you use Lesstif, no, the user won't need to
purchase a copy of Motif.

There are commercial GUI builders for Motif (or in this case, Lesstif) also.

Lyle Taylor

If you think "potato" is funny, the next codename is "woody" (after Woody
the cowboy in Toy Story).
--