New Project: Kool Desktop Environment. Programmers wanted!
Matthias Ettrich
-------------------------------------------
New Project: Kool Desktop Environment (KDE)
-------------------------------------------
Programmers wanted!
Motivation
----------
Unix popularity grows thanks to the free variants, mostly Linux. But still a
consistant, nice looking free desktop-environment is missing. There are
several nice either free or low-priced applications available, so that
Linux/X11 would almost fit everybody needs if we could offer a real GUI.
Of course there are GUI's. There is the Commond Desktop Environment (much
too exansive), Looking Glas (not too expensive but not really the solution),
and several free X-Filemanagers that are almost GUI's. Moxfm for example is
very well done, but unfortunately it is based on Motif. Anyway, the
question is: What is a GUI? What should a GUI be?
First of all, since there are a lot of missunderstandings on this topic,
what is NOT a GUI:
- the X-Window-System is NOT a GUI. It's what its name says: A Window system
- Motif is NOT a GUI. They tried to create a GUI when they made Motif, but
unfortunately they couldn't really agree, so they released Motif as
Widget-Library with a Window-Manager. Much later they completed Motif with
the CDE, but too late, since Windows already runs on the majority of
desktops.
- Window-managers are NOT GUI's. They are (better: should be) small programs
that handle the windows. It's not really the idea to hack a lot of stuff
into them.
IMHO a GUI should offer a complete, graphical environment. It should allow a
users to do his everyday tasks with it, like starting applications, reading
mail, configuring his desktop, editing some files, delete some files, look
at some pictures, etc. All parts must fit together and work together. A
nice button with a nice "Editor"-icon isn't not at all a graphical user
environment if it invokes "xterm -e vi". Maybe you have been disappointed
long time ago too, when you installed X with a nice window manager, clicked
on that beautiful "Help"-Icon ... chrk chrk (the hard disk)...an ugly,
unsuable, weird xman appeared on the desktop :-(
A GUI for endusers
------------------
The idea is NOT to create a GUI for the complete UNIX-system or the
System-Administrator. For that purpose the UNIX-CLI with thousands of tools
and scripting languages is much better. The idea is to create a GUI for an
ENDUSER. Somebody who wants to browse the web with Linux, write some letters
and play some nice games.
I really believed that is even yet possible with Linux until I configured my
girlfriends Box. Well, I didn't notice anymore that I work with lots of
different kind of menues, scrollbars and textwidgets. I already know that
some widgets need to be under the mouse when they should get the keyevents,
some sliders wants the middle mouse for dragging and some textwidgets only
want emacs-bindings and don't understand keys like "pos1" or "end". And
selecting some text is different everywere, too. Even the menues and buttons
(for exampel Xaw, Fvwm, XForms, Motif) behave completely different.
One word to the Athena-Widgets: Although there are a few nice applications
available that uses these "widgets" we should really get rid of them.
Thinking that "Athena is a widget-library" is a similar missunderstanding
like "X is a GUI". Athena is an very old example how widget libraries could
be implemented with Xlib and Xt. It's more or less a online-documentation
for Widget-Set-Programmers, but not a tool for application-programmers.
Unfortunately, the old Unix problem, a so good online-documentation that
people used it for applications.
So one of the major goals is to provide a modern and common look&feel for
all the applications. And this is exactly the reason, why this project is
different from elder attempts.
Since a few weeks a really great new widget library is available free in
source and price for free software development. Check out
http://www.troll.no
The stuff is called "Qt" and is really a revolution in programming X. It's
an almost complete, fully C++ Widget-library that implementes a slightly
improved Motif look and feel, or, switchable during startup, Window95.
The fact that it is done by a company (Troll Tech) is IMO a great advantage.
We have the sources and a superb library, they have beta testers. But they
also spend their WHOLE TIME in improving the library. They also give great
support. That means, Qt is also interesting for commercial applications. A
real alternative to the terrible Motif :) But the greatest pro for Qt is the
way how it is programmed. It's really a very easy-to-use powerfull
C++-library.
Qt is also portable, yet to Windows95/NT, but you do not have to worry about
that. It's very easy to use UNIX/X specific things in programming, so that
porting to NT is hardly possible :-)
I really recommand looking at this library. It has IMO the power to become
the leading library for free software development. And it's a way to escape
the TCL/TK monsters that try to slow down all our processors and eat up our
memory...
It's really time yet to standarize the desktop somewhat. It's nonsense to
load 10 different widgets into memory for the same task.
Imagine this desktop:
- fvwm (own widgets)
- rxvt (own widgets)
- tgif (own widgets)
- xv (own widgets)
- ghostview (athena widgets)
- lyx (xforms widgets)
- xftp (motif widgets)
- textedit (xview widgets)
- arena (own widgets)
One may argue that a usual UNIX-Box has enough memory to handle all these
different kind of widgets. Even if this might be correct, the really
annoying thing is, that all these widgets (menus, buttons, scrollbars, etc.)
behave slightly different. And this isn't only an academic example, I've
really seen such desktops :-}
I know we couldn't get rid of this chaos at once, but my dream is a
coexistance between Motif and Qt.
The Kool Desktop Environment (KDE)
----------------------------------
I don't have the time to do this all alone (also since LyX is my main
project). But a thing like a Desktop Environment can easily be cut into lots
of parts. There is very probably a part for you, too! If you want to learn
some X-programming, why not doing a small, neat project for the KDE? If you
know others who like to programm something, please pretend them from writing
the 1004th tetris games or the 768th minesweeper clone ;-) Think we also
have enough XBiffs yet...
So here is my project list so far. Probably there are even more things to do
that would fit great into the KDE. It's a very open project.
- Panel:
The basic application. Run's as FvwmModule (at the beginning). Offers a
combination between Windows95 and CDE. I think about a small taskbar at
the bottom and a kind of CDE-panel on the top of the screen. The panel has
graphical icon menus on the left (similar to GoodStuff) to launch
applications, 4 buttons in the middle to switch to other virtual desktops
and few icons for often needed applications on the right. There is for
example a mail-icon that also indicates new mail, a wastebasket to open
the delete-folder (that also indicates when it isn't empty and is capable
of drag'n'drop). Maybe a analog clock with date at the very right. Also a
nice special icon for exiting the environment or locking the screen. All
the stuff is completly configurable via GUI. I'm also thinking about
solutions, that only available applications can be installed on the
desktop and that new applications appear on the desktop automatically.
I started to work on this panel, but would of course love some help. There
are also lot of smaller things to do, like a tool to chose a background
pixmap (for each virtual desktop) etc.
Also nice icons are needed!
- Filemanager
Another major application inside the KDE. The idea is not to create a
powerful high-end graphical bash-replacement (like tkdesk tries to be),
but a nice looking easy-to-use filemanager for simple tasks. Simple tasks
are mainly deleting some files, copying some files, copying some files on
the disk, starting applications by clicking on a file (for example
ghostview for postscript files or xli for gifs, etc).
I'm thinking about nice windows, one for each directory, that shows icons
for every file. It should be possible to drag files around (either copy or
move), even between different windows. Another important point is the
support of the floppy-disk, so that mounting/umounting is done
user-transparent.
Dragging of icons should be done in a nice way, that means moving around a
special window (see Qt's xshape example), NOT like xfm or xfilemanager by
setting another monochrome bitmap for the cursor.
So it will also be possible to put files as icons on the desktop. This is
IMO a very nice feature. Since applications are launched by the panel,
it's even clear that icons are real data-objects. With fvwm-1 and the
FvwmFileMgr it wasn't really clear wether an icon is yet a file or an
iconified window.
Drag'n'drop inside a Qt application isn't really difficult.
The filemanager is IMO a very nice and not too time consuming project.
Who wants?
- mail client
A really comfortable mailclient. IMO the most comfortable mailclient for X
is yet XF-Mail. And the author is willing to port it to Qt when the
KDE-project will start! But he asks for some assitance (for example for
coding the small popups, etc.)
- easy texteditor
Very small but important project. An editor that fits the needs of those
who have to edit a textfile once in a month and didn't find the time yet
to learn vi (and don't have the time to wait for x-emacs to start, and
don't have the memory to use a motif-static-nedit, and don't have the
cpu-power and memory to use a tk-monster like tkedit,...)
Unfortunatly the Qt multiline-textwidget isn't available in Qt-1.0, but
Troll-Tech already announced the beta-testing. So the texteditor can be
started in a few weeks, too.
- Terminal
Similar to the CDE terminal program. A kind of xterm with nice menu bar to
set the font, exit, etc. Nice project, get the xterm sources and add a GUI
with Qt!
- Image viewer
The application that will be launced as default from the filemanager for
gifs, jpegs and all this. Well, xv is shareware and really needs quite a
long time for startup. But there is a plain Xlib programm without any
menues or buttons called "xli". Get the sources and make it userfriendly
with Qt!
- Lots of small other tools:
* xdvi with Qt-Gui
* ghostview with Qt-Gui
* xmag with Qt-Gui
* whatever you want
- Hypertext Help System
A complete desktop environment needs a nice hypertext online help. I think
the best choice would be HTML (>= 2.0). So a free Qt-based html-viewer
would be a great idea. It might be possible to use the Arena-sources, but
arena needs very long for startup. Maybe it would be best to start from
scratch. Qt offers excellent functions for dealing with different fonts.
For a help system HTML 2.0 is more than enough, some nice search function
added and that's it. Since it is also possible to convert the obsolete
troff man-pages to HTML, we can also integrate the original UNIX help
system.
BTW: There is a Troll Tech Qt-competition (look at their webpages). The
best application (not only functionallity, but also design counts. Just
porting an existing great application to Qt won't probably be enough :-( )
wins $2000 and a few Qt on NT licenses (worth another $2000). They also
mentioned a browser-project as an example. So a nice HTML-browser in Qt,
ready in Janurary may be worth $4000 (This includes selling the unneeded
NT licenses ;-) )
- Window Manager
At the beginning, the KDE panel will work as an Fvwm-Module. When this is
done, a lot of stuff can be stripped from the bloated fvwm window manager.
We don't need anymore fvwm-menus, icon handling and zillions of
configurable things. We need a small, realiable windowmanager. So maybe
stripping all unncessary stuff from fvwm will make sense in a while. But
this may come very last.
- System Tools
Whatever a user, or you, might need. A graphical passwd comes to my mind.
But probably there are a lot more! Maybe this will lead to a little system
administration tool someday.
- Games
We have yet a nice tetris game (an Qt example program). What is needed is
a nice set of small games like solitaire (please with nice cards that can
be really dragged!). There are several nice card games available for X,
for example xpat2. So why not take the cards from them and write a real
solitaire games, very similar to MS-Solitaire. I really had to install
Wine sometimes just to play solitair, what an overhead! But other games
are needed, too. Take xmris, pacman, etc. add a nice GUI. Or write some
from scratch. Whatever you want :)
- Icons
A set of nice icons. 3D-pixmaps are quite a good start (but why should the
button be inside a pixmap, if we use a toolkit with buttons???)
- Documentation
A documentation project is always a good thing to have. But before we
should clearify how the hypertext help system should look like. We can
then start with documentation pages in the chosen HTML-subset and for
example use arean as help browser. Anyway we need some application to
document first.
- Web-Pages / Ftp Server / Aministration
We need a server for the files and webpages that inform about the state of
the project. Especially what projects are currently worked on and what
projects still wait for somebody to do them. I set up a preliminary
homepage on
http://www-pu.informatik.uni-tuebingen.de/users/ettrich
that just contains this posting yet and a few links. I may setup real
webpages for the very beginning but I would be very happy if I could
concentrate on discussion and coding. So if there is someone out there in
the net who likes to design and maintain webpages, here is a job for him
:)
- Discussion
The most important topic :-) If you are interested please
join the mailing list
k...@fiwi02.wiwi.uni-tuebingen.de
Subscribing can be done by sending a mail with in *Body*:
subscribe <your email address>
to
kde-r...@fiwi02.wiwi.uni-tuebingen.de.
- Applications
When the KDE gets widely accepted, new (free) applications will hopefully
be based on Qt, too, to fit with the comfortable and pleasant look and
feel of the desktop.
We may for example port LyX to Qt, so that a comfortable wordprocessor is
available. But that is still in discussion in the LyX Team.
A nice vector-orientated drawing tool would also be fine. Well, Xfig is a
powerful but ugly monster. But there is "tgif", a very powerful, easy to
use but ugly program. The author don't like the idea of adding a Qt GUI
for the menus, icons and scrollbars, since Qt is C++ and he wants to keep
tgif plain C, since on some sites no C++ compiler is available. Well, the
KDE doesn't really aim on these old and weird UNIX boxes (also I think a
g++ is almost everywhere available). But maybe the tgif-author agrees when
somebody else adds a nice GUI to tgif (the sources are free, don't know
wether this is GPL). Since tgif yet implements its own GUI this shouldn't
be too difficult. It's really easy with Qt to access plain Xlib
functionality and functions, so not very much will have to be rewritten.
Also C++ makes it very easy to include plain C code.
What about an easy to use, nice newsreader similar to knews? Could also be
integrated into the KDE. ... and ... and ... and.
So there is a lot of work (and fun) to do! If you are interested, please
join the mailing list. If we get about 20-30 people we could start. And
probably before 24th December the net-community will give itself another
nice and longtime-needed gift.
The stuff will be distributed under the terms of the GPL.
I admit the whole thing sounds a bit like fantasy. But it is very serious
from my side. Everybody I'm talking to in the net would LOVE a somewhat
cleaner desktop. Qt is the chance to realize this. So let us join our rare
sparetime and just do it!
Hopefully looking foward to lots of followups and replies!
Regards,
Matthias Ettrich
(ett...@informatik.uni-tuebingen.de)
BTW: Usually these postings get a lot of answers like "Use a Mac if you want
a GUI, CLI rules!", "I like thousands of different widgets-libraries on my
desktop, if you are too stupid to learn them, you should use windoze", "RAM
prices are so low, I only use static motif programs", "You will never
succeed, so better stop before the beginning", "Why Qt? I prefer
schnurz-purz-widgets with xyz-lisp-shell. GPL! Check it out!", etc. Thanks
for not sending these as followup to this posting :-) I know I'm a
dreamer...
BTW2: You might wonder why I'm so against Tk. Well, I don't like the
philosophy: Tk's doesn't have a textwidget, for example, but a slow
wordprocessor. Same with other widgets. In combination with TCL the programs
become slow and ugly (of course there are exceptions). I didn't yet see any
application that uses Tk from C++ or C, although an API seems to exist.
TCL/TK is very usefull for prototyping. Ideal for example for kernel
configuration. And since Tk looks little similar to Motif, the widgets are
also quite easy to use. But I really don't like any TCL/Tk application to
stay permanantly on the desktop. And Qt is much easier (at least as easy) to
program. Check it out!
BTW3: I don't have any connections to Troll Tech, I just like their product
(look at the sources: really high quality!) and their kind of marketing:
free sourcecode for free software.
Kevin Cabral
Matthias Ettrich (ett...@ti-ibm03.informatik.uni-tuebingen.de) wrote:
: -------------------------------------------
: New Project: Kool Desktop Environment (KDE)
: -------------------------------------------
:
: Programmers wanted!
: Motivation
: ----------
: Unix popularity grows thanks to the free variants, mostly Linux. But still a
: consistant, nice looking free desktop-environment is missing. There are
: several nice either free or low-priced applications available, so that
: Linux/X11 would almost fit everybody needs if we could offer a real GUI.
Matthias,
I think that nice looking window managers are wonderful, but a
more worthwhile project for programmers in the Linux community would be to
create a FreeCDE system. I personally would much rather have a unified
print and drag-and-drop API than another pretty window manager.
BTW: I hope you will consider porting LyX over to Qt in the future, and I
hope that The Gimp will also join it in moving to more open libraries.
Kevin
nall
>
> I really believed that is even yet possible with Linux until I configured my
> girlfriends Box.
was 'configuring your girlfriends' "box"' really that traumatic? <grin>
nall.
--
jonathan n. nall na...@cs.duke.edu
they say your eyes are the same color as they always were.
that kind of information just floors me...
http://www.duke.edu/~jnn/mountain_goats/mg.html
G Sumner Hayes
kca...@freenet.columbus.oh.us (Kevin Cabral) writes:
>
> BTW: I hope you will consider porting LyX over to Qt in the future, and I
> hope that The Gimp will also join it in moving to more open libraries.
>
Motif-appearance toolkit written over Xlib only for speed.
I think it's only available to developers, but they say it works
really well and will be the basis of the next release of the Gimp.
TTFN,
Sumner
Steve Dunham
> kca...@freenet.columbus.oh.us (Kevin Cabral) writes:
There is a copy somewhere on the web site. I like the new widgets,
they look as good as Motif, if not better. The toolkit is called
"gtk", but shouldn't be confused with the "gtk" being created by the
Mosaic developers.
Steve
dun...@gdl.msu.edu
Lars Hofhansl
Matthias Ettrich wrote:
>
> -------------------------------------------
> New Project: Kool Desktop Environment (KDE)
> -------------------------------------------
>
> Programmers wanted!
>
[...]
> I really recommand looking at this library. It has IMO the power to become
> the leading library for free software development. And it's a way to escape
> the TCL/TK monsters that try to slow down all our processors and eat up our
> memory...
>
[...]
> BTW2: You might wonder why I'm so against Tk. Well, I don't like the
> philosophy: Tk's doesn't have a textwidget, for example, but a slow
> wordprocessor. Same with other widgets. In combination with TCL the programs
> become slow and ugly (of course there are exceptions). I didn't yet see any
> application that uses Tk from C++ or C, although an API seems to exist.
> TCL/TK is very usefull for prototyping. Ideal for example for kernel
> configuration. And since Tk looks little similar to Motif, the widgets are
> also quite easy to use. But I really don't like any TCL/Tk application to
> stay permanantly on the desktop. And Qt is much easier (at least as easy) to
> program. Check it out!
>
Hi,
I just want to give a few comment on that.
Admittedly I'm tired of this TK-Monster-tale!
It's slow when you write the whole application in plain TCL,
but that's not how is was meant to be.
You actually can register C-procedures as TCL-commands
and call them directly from the interpreter (the only
overhead is the command-parsing at runtime).
You can also call evaluate small TCL-Scripts from within
C.
I wrote some middle sized TK-applications for a company using TCL
and TK. I used TCL only to glue (how John Osterhout calls it) my
C-routines together, which made the programs fast, and very
easy to maintain!
I think TCL/TK is one of the most reasonable paradigms for
GUI-devopment... We only miss a really GUI-builder :) !
(The speed has to be improved on windows, which is currently
in progress)
Granted, it's tempting to write the whole application in TCL/TK, and
some guys seem to have misunderstood the whole idea.
But then again, what do you want?
- you can write the whole thing in TCL which is easy but slow
- you can write the main parts in C or C++ and use TCL/TK only
for the GUI and non-time-critical portions, which is still easier
than Motif or QT and about as efficient!
Again, TCL/TK was designed as glue language for C or C++,
if you use it like that, it's the perfect solution!
If I had to vote what development tools to use for KDE, it most
certainly would be TCL/TK (used in an intelligent way...).
It is even worked on a window manager called TKWM,
which is basicly a TCL/TK interpreter with extra commands for
windows management (of course the new commands are written in C).
just my $0.02
Lars
Brian Kimball
Matthias Ettrich wrote:
> IMHO a GUI should offer a complete, graphical environment. It should allow a
> users to do his everyday tasks with it, like starting applications, reading
> mail, configuring his desktop, editing some files, delete some files, look
> at some pictures, etc. All parts must fit together and work together. A
> nice button with a nice "Editor"-icon isn't not at all a graphical user
> environment if it invokes "xterm -e vi". Maybe you have been disappointed
> long time ago too, when you installed X with a nice window manager, clicked
> on that beautiful "Help"-Icon ... chrk chrk (the hard disk)...an ugly,
> unsuable, weird xman appeared on the desktop :-(
Wow. That brings back memories of my first X experience. <shudder>
> Since a few weeks a really great new widget library is available free in
> source and price for free software development. Check out
> http://www.troll.no
Also check out http://www.mlsoft.com/xml/xml.html for some cool motif
add-ons.
The widget library is free for linux.
I seem to remember people working on the fvwm95 project also doing some
kind of integrated file manager that resembles the win95 file windows.
I think this included possible file-icons on the desktop.
My impression is that a bunch of people just recently realized that the
current linux/X situation really bites and they all decided to start
their own little projects. It would be nice to see people buckle down
and focus on one common project (like the KDE). I think this would add
a lot of value to linux. Good luck dude.
Brian
Greg Howland
This sounds very similar to the Afterstep project.
Have you considered working with them?
--Greg
Henning Brockfeld
I don't want to start a new widget war. If someone wants to start a
project like KDE with Qt, it ok. But I think it is a good idea to have
a close look at GNUStep ( http://www.gnustep.org ) before starting.
GNUStep is becoming a clone of the OpenStep API from Next including a
RTF textwidget and Display Postscript.
Henning
--
Henning Brockfeld mailto: Broc...@wigeo.bwl.uni-muenchen.de
Institut f"ur Wirtschaftsgeographie Universit"at M"unchen
James Bailie
Lars Hofhansl <lhof...@indiana.edu> wrote:
> It is even worked on a window manager called TKWM,
> which is basicly a TCL/TK interpreter with extra commands for
> windows management (of course the new commands are written in C).
Is TKWM still kicking around/maintained? If so, where can I find it?
James Bailie
Linux bigot,
in London, Ontario, Canada
------------------------------------------------
Matthias Ettrich
nall (na...@spike.cs.duke.edu) wrote:
: >
: > I really believed that is even yet possible with Linux until I configured my
: > girlfriends Box.
: was 'configuring your girlfriends' "box"' really that traumatic? <grin>
yes, unfortunatly :-( I needed several hours and the result isn't as
good as I expected. Anyway she now works with it but she doesn't really
believe my claims anymore that this system could sometime be something
for everybody. Well, one might argue that it's enough if Linux/X11 fits
for me. But as a computer-science student who will maybe end up as a
programmer (who knows) I really would like more marketshare for Unix
so that I will not have to write software for strange other systems.
Don't grin, this could happen to everybody. someday. ;)
Matthias
BTW: But I want a nice environment for myself, too, of course.
: nall.
Matthias Ettrich
Kevin Cabral (kca...@freenet.columbus.oh.us) wrote:
: Matthias Ettrich (ett...@ti-ibm03.informatik.uni-tuebingen.de) wrote:
: : -------------------------------------------
: : New Project: Kool Desktop Environment (KDE)
: : -------------------------------------------
: :
: : Programmers wanted!
: : Motivation
: : ----------
: : Unix popularity grows thanks to the free variants, mostly Linux. But still a
: : consistant, nice looking free desktop-environment is missing. There are
: : several nice either free or low-priced applications available, so that
: : Linux/X11 would almost fit everybody needs if we could offer a real GUI.
: Matthias,
: I think that nice looking window managers are wonderful, but a
: more worthwhile project for programmers in the Linux community would be to
: create a FreeCDE system. I personally would much rather have a unified
: print and drag-and-drop API than another pretty window manager.
I'm not talking about yet-another window manager. I'm talking about
an Qt-based environment similar to the CDE. Qt yet doesn't have
a drag-and-drop API. I'm not sure when it will come. But of course
this would be a nice project. Join and do that API!
(as a sideeffect and for testing purpose maybe also the filemanager
comes out...)
: BTW: I hope you will consider porting LyX over to Qt in the future, and I
: hope that The Gimp will also join it in moving to more open libraries.
: Kevin
Greets,
Matthias
William P Shaw
In article <53vkaq$n...@newsserv.zdv.uni-tuebingen.de>,
Matthias Ettrich <ett...@ti-ibm01.informatik.uni-tuebingen.de> wrote:
>nall (na...@spike.cs.duke.edu) wrote:
>: >
>: > I really believed that is even yet possible with Linux until I
>: > configured my girlfriends Box.
>
>: was 'configuring your girlfriends' "box"' really that traumatic? <grin>
>
>yes, unfortunatly :-( I needed several hours and the result isn't as
>good as I expected.
Several hours! If I spent that long working with the 'box' and I
didn't produce the expected result, I'd be sleeping on the front
porch! --Bill.
--
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++ William Shaw the shaman wps...@pitt.edu ++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Patrice Fortier
Matthias Ettrich (ett...@ti-ibm01.informatik.uni-tuebingen.de) wrote:
: I'm not talking about yet-another window manager. I'm talking about
: an Qt-based environment similar to the CDE. Qt yet doesn't have
: a drag-and-drop API. I'm not sure when it will come. But of course
: this would be a nice project. Join and do that API!
: (as a sideeffect and for testing purpose maybe also the filemanager
: comes out...)
As far as I can remember Qt is free only for free software development.
So if a company wants to create a product on Linux, she'll have the
choice between:
1. Motif
2. Qt
Since both of them are Commercial products, it'll use Motif (standard).
Even if the Qt API is better...
--
Lokh.
"Famous remarks are very seldom quoted correctly."
- Simeon Strunsky
Linh Dang
>>>> "Pat" == Patrice Fortier <for...@emi.u-bordeaux.fr> writes:
Pat> Matthias Ettrich (ett...@ti-ibm01.informatik.uni-tuebingen.de)
Pat> wrote: : I'm not talking about yet-another window manager. I'm
Pat> talking about : an Qt-based environment similar to the CDE. Qt
Pat> yet doesn't have : a drag-and-drop API. I'm not sure when it
Pat> will come. But of course : this would be a nice project. Join
Pat> and do that API! : (as a sideeffect and for testing purpose
Pat> maybe also the filemanager : comes out...)
Pat> As far as I can remember Qt is free only for free software
Pat> development. So if a company wants to create a product on
Pat> Linux, she'll have the choice between:
Pat> 1. Motif 2. Qt
Pat> Since both of them are Commercial products, it'll use Motif
Pat> (standard). Even if the Qt API is better...
If their primary target is Linux, I think they would rather use Qt
since they don't have to staticly link the gui lib in. Users can buy
the app and use it with the free Qt shared lib. Look at the problems
StarOffice has with Motif. Last time I checked, Lesstiff is only
source compatible with Motif. So Lesstiff can't solve the problems
Motif-based comercial apps since the only thing u get is a binary.
just my 0.02$
L.D.
--
=====================================================================
Linh Dang Nortel Technology
Member of Scientific Staff Speech Recognition Software
li...@nortel.ca
=====================================================================
Lars Hofhansl
Hi,
it has not been worked on since TK4.0, and even
this was only an alpha version.
Still it might be a good starting point!
Take a look ant Eric Schenks homepage:
http://www.cs.utoronto.ca/~schenk/
Lars
Lou Ruppert
In article <gknsp7g...@nortel.ca>,
Linh Dang <li...@nortel.ca> writes:
> Pat> As far as I can remember Qt is free only for free software
> Pat> development. So if a company wants to create a product on
> Pat> Linux, she'll have the choice between:
>
> Pat> 1. Motif 2. Qt
>
> since they don't have to staticly link the gui lib in. Users can buy
> the app and use it with the free Qt shared lib. Look at the problems
> StarOffice has with Motif. Last time I checked, Lesstiff is only
> source compatible with Motif. So Lesstiff can't solve the problems
> Motif-based comercial apps since the only thing u get is a binary.
True, but if it shares the Motif API then making a Lesstif version
would be no more complex than relinking with lesstif libraries rather
than motif. I think if a common interface were to be made for Linux that
the best interface to use would be Motif. Why? Because there is already
a base of Motif applications out there, such as Netscape and Mosaic, and
Java has a Motif look and feel, at least for the Linux release. If any
other 'standard' were developed, it would have to sit alongside those
applications, which would dash away any hopes of a common look all around.
I don't believe a common interface could ever be completely achieved under
an open system like Linux, but I think the best solution would be to use
Motif/Lesstif.
-Lou
--
Lou Ruppert lrup...@npac.syr.edu
"The Lou Ruppert home page": http://groomlake.npac.syr.edu/~lruppert/
"And the LORD said unto Joshua, Get thee up; wherefore liest thou thus upon
thy face?" -Joshua 7:10
Hallow
[Posted and mailed]
In article <m2zq1pk...@dunham.tcimet.net>,
Steve Dunham <dun...@gdl.msu.edu> writes:
>
>> I think it's only available to developers, but they say it works
>> really well and will be the basis of the next release of the Gimp.
>
> There is a copy somewhere on the web site. I like the new widgets,
> they look as good as Motif, if not better. The toolkit is called
> "gtk", but shouldn't be confused with the "gtk" being created by the
> Mosaic developers.
Actually, it is the exact same gtk (gIMP tOOLkIT)! And version 1.0 (at
least that's what I beleive it will be numbered) will remove the need
for motif or xlib (one or the other is required right now).
And it's not really a widget set either. It's kinda wierd. But it's way
faster and smaller than motif, is syntactically similar to programming
for motif (that's why two free formerly motif tools (gimp and mosaic)
are being converted).
Hallow
hal...@hallow.erols.com
>
> Steve
> dun...@gdl.msu.edu
>
Linh Dang
>>>> "Lou" == Lou Ruppert <lrup...@npac.syr.edu> writes:
Lou> In article <gknsp7g...@nortel.ca>, Linh Dang
Lou> <li...@nortel.ca> writes:
Pat> As far as I can remember Qt is free only for free software
Pat> development. So if a company wants to create a product on
Pat> Linux, she'll have the choice between:
>>
Pat> 1. Motif 2. Qt
>> If their primary target is Linux, I think they would rather use
>> Qt since they don't have to staticly link the gui lib in. Users
>> can buy the app and use it with the free Qt shared lib. Look at
>> the problems StarOffice has with Motif. Last time I checked,
>> Lesstiff is only source compatible with Motif. So Lesstiff can't
>> solve the problems Motif-based comercial apps since the only thing
>> u get is a binary.
Lou> True, but if it shares the Motif API then making a Lesstif
Lou> version would be no more complex than relinking with lesstif
Lou> libraries rather than motif. I think if a common interface were
Very true, indeed!
The question are
how mature is lesstiff ?
under what license will it be ditributed ? GPL, LGPL, ... (can
commercial apps use it ?, btw, we're talking about comercial
softwares, freeware is almost a non-issue).
Don't forget Qt is commercial for commercial software !
Lou> to be made for Linux that the best interface to use would be
Lou> Motif. Why? Because there is already a base of Motif
Lou> applications out there, such as Netscape and Mosaic, and Java
Lou> has a Motif look and feel, at least for the Linux release. If
Lou> any other 'standard' were developed, it would have to sit
Lou> alongside those applications, which would dash away any hopes of
Lou> a common look all around. I don't believe a common interface
This is a non-issue ! Qt has Motif L&F !
Lou> could ever be completely achieved under an open system like
Lou> Linux, but I think the best solution would be to use
Lou> Motif/Lesstif.
Lou> -Lou -- Lou Ruppert lrup...@npac.syr.edu "The Lou Ruppert home
Lou> page": http://groomlake.npac.syr.edu/~lruppert/ "And the LORD
Lou> said unto Joshua, Get thee up; wherefore liest thou thus upon
Lou> thy face?" -Joshua 7:10
Paul Seelig
In article <326322...@erols.com>,As to my understanding Afterstep is just about another window manager.
But Matthias' idea is about a desktop environment (can you say CDE?) which is
a whole different thing.
> Have you considered working with them?
>
Read his posting again. He is clearly differentiating a window manager from
a desktop environment. Afterstep is about looks but not functionality and
the KDE is primarily an approach for functionality.
We don't need good looks, but a homogeneous user interface. With all window
managers there is still such a heterogeneous way of handling your programs
that it stinks for the average end user. Afterstep is nice but it doesn't
make usage of an editor like 'vi' very convincable for the average user. And
have you ever seen and used a real NeXT box? That's what is called a GUI with
real functionality! Afterstep is still miles away from that although the
looks seem to be there - but that's all.
Regards, P. Seelig *8^)
--
Paul Seelig pse...@goofy.zdv.uni-mainz.de
African Music Archive - Institute for Ethnology and Africa Studies
Johannes Gutenberg-University - Forum 6 - 55099 Mainz/Germany
Our AMA Homepage in the WWW at http://www.uni-mainz.de/~bender/
Leo Comitale
In article <540115$d...@usenet.srv.cis.pitt.edu>,
William P Shaw <wps...@pitt.edu> wrote:
>In article <53vkaq$n...@newsserv.zdv.uni-tuebingen.de>,
>Matthias Ettrich <ett...@ti-ibm01.informatik.uni-tuebingen.de> wrote:
>>nall (na...@spike.cs.duke.edu) wrote:
>>: >
>>: > configured my girlfriends Box.
>>
>>: was 'configuring your girlfriends' "box"' really that traumatic? <grin>
>>
>>yes, unfortunatly :-( I needed several hours and the result isn't as
>>good as I expected.
>
>Several hours! If I spent that long working with the 'box' and I
>didn't produce the expected result, I'd be sleeping on the front
>porch! --Bill.
I don't think he gets it.
--
Leo Comitale
UofT CPE 9T6+PEY
Eric Vought
> If I had to vote what development tools to use for KDE, it most
> certainly would be TCL/TK (used in an intelligent way...).
>
> which is basicly a TCL/TK interpreter with extra commands for
> windows management (of course the new commands are written in C).
This would also make configuration extremely easy, provide backwards
compatibility with the X Resource database, and leverage a hell of a lot
of existing code and extensions.
Eric Vought
> IMHO a GUI should offer a complete, graphical environment. It should allow a
> users to do his everyday tasks with it, like starting applications, reading
> mail, configuring his desktop, editing some files, delete some files, look
> at some pictures, etc. All parts must fit together and work together. A
> nice button with a nice "Editor"-icon isn't not at all a graphical user
> environment if it invokes "xterm -e vi". Maybe you have been disappointed
On the contrary, this is exactly what it should be able to do, only you
should also be able to change it to "xterm -e joe" or "textedit" or
"xemacs" or "KDEEdit" or "crisp", etc. If you do build an environment
like you describe, configurability has to be a part of it. Sure, you
might supply several good programs with it, but you shouldn't lock out
people's ability to use other programs *and* for them to fully replace
your programs. In other words, if every time your GUI wants the user to
edit a file, it pops up KDEEdit, even though the user prefers to and
does use pico everywhere else, that doesn't cut it. If the user wants
pico, the GUI should use pico *everywhere*. If you have a set of key
bindings in the GUI, the user should be able to reconfigure them. Why?
Maybe the user is used to a Macintosh and wants familiar bindings. Maybe
the user is missing a left hand and typing Ctrl-A is a royal pain. This,
by the way, means that reasonable backwards compatibility with other
programs needs to be maintained.
Summary, yes, by all means, build a standard system- it has been done
before (The Andrew Toolkit Springs to mind, as does OpenLook), but it
can be done better. But- allow people to deviate from that standard.
Their reasons may be much better than you think, and you cannot possibly
anticipate the needs of everyone.
Suggestion:
__________
BTW: Have you considered a scrapbook for storing scraps of cut and
pastage, Macintosh style? I hate the Mac interface, but it does have its
points, the scrapbook being one of them. An application that serves as a
clipboard that will store say, the last two or three copy actions would
also be helpful, allowing you to copy to and from the scrapbook as
desired.
One other thing: If you provide toolbars, (I'm sure you will) make a
configuration option where by you can display short text interpretations
(not just balloon help- balloon help is for slightly longer phrases)
either with or *instead of* the icons. I find icons can be a great
source of confusion with new users (just what *does* the picture of the
teddy bear mean?!?). It also helps with people that have low resolution,
monochrome, or crappy monitors where the pictures become unrecognizable.
Additionally some people don't have a lot of memory or a fast video card
(pixmaps take up a tremendous amount of memory in a highly graphical
interface- text takes up a lot less- easier on disk space too and much
easier to internationalize).
Ralph Schleicher
Matthias Ettrich <ett...@ti-ibm03.informatik.uni-tuebingen.de> cited
below with "ME" writes:
ME> IMHO a GUI should offer a complete, graphical environment. It should
ME> allow a users to do his everyday tasks with it, like starting
ME> applications, reading mail, configuring his desktop, editing some
ME> files, delete some files, look at some pictures, etc. All parts
ME> must fit together and work together.
Emacs, man! Emacs! :-)
ME> - Panel:
There are still some keys unbound!
ME> - Filemanager
Dired.
ME> - mail client
Gnus, you can also read News with it!
ME> - easy texteditor
Hell yeah!
ME> - Terminal
Shell mode.
ME> - Image viewer
Say `! display RET' in Dired.
ME> - Hypertext Help System
Texinfo.
--
Ralph * http://www.UL.BaWue.DE/~rs/
GNU -- vivat, crescat, floreat!
Edwin Lim
In article <32635025...@lrz.uni-muenchen.de>,
Henning Brockfeld <Henning....@lrz.uni-muenchen.de> wrote:
>I don't want to start a new widget war. If someone wants to start a
>project like KDE with Qt, it ok. But I think it is a good idea to have
>a close look at GNUStep ( http://www.gnustep.org ) before starting.
>GNUStep is becoming a clone of the OpenStep API from Next including a
>RTF textwidget and Display Postscript.
I think Henning has a point. Does anyone know what is the advantage
KDE has over GNUstep? KDE sounds like a face lift on some apps. If
that is the case, then it might be a worthwhile attempt. However, if
interoperability (aka drag and drop, OLE, Opendoc, whatever the
recent incarnation is) is desired, perhaps we should seriously look
farther ahead than a face lift. I fear that a face lift of the apps
will generate a lot of excitement that might take too long to complete,
and when it does finish, it would likely be superceded by other stuff
(e.g., CDE) making it look incomplete once again. I bring this up in
light of the uncertain fate that the X+free Unices world is coming to
at the end of the year.
The Unix world (at least the commercial Unix world) is tending towards
CDE+Motif, and soon when the Open Group takes over X, it will be
CDE+Motif+X, integrated (whatever that means). The Open Group has not
made Motif and CDE free, and when X is integrated with Motif and CDE, I
doubt if X will be free as we all know it now. Even if X remains free
and functional stand-alone, the free Unices community will lose much of
its attractive value (sorry, can't think of an appropriate word right
now) due to lack of CDE and Motif, making us look like the outsiders in
a "unified" (commercial) Unix world. Of course, I am sure that
XInside, Metro-X, and others will come up with commercial solutions for
many polular free Unices (some already offer CDE), but those will
most likely come at a dollar price, leave some not so popular free
Unices (or popular free Unices but on uncommon hardware) out in the
cold, and most of all, come with all kinds of strings attached--not
quite the "live free or die" Unix motto.
The Open Group has not announced the fate of X as yet. Since the
maintenance of X is to be handed over at the end of the year, one is
free to speculate what does that mean. Whatever it may be, I think we
should not count on Open Group to be a benevolent entity (it might be,
I don't know.. can anyone clarify this?) on a long term basis. Thus my
suggestion of a new direction in the form of GNUstep.
I am certain most people who have seen a NeXT box will agree that
OPENstep is a more elegant solution than CDE+Motif. It has ground-up
drag and drop (or whatever you prefer to call it), but most important
of all is that the specifications are really open which means that a
free version such as GNUstep can be implemented. Compare that to
CDE+Motif, you have to pay a fees to even get Motif on your box, it is
fat (Qt looks like a much better implementation in many ways, plus
Troll Tech is nice to hackers), CDE needs money as well (am I
correct?), and I would guess that Open Group will not endear itself to
the free Unix community. Money and big players and politics are
involved now, so technology usually take a back seat.
I think I have speculated enough. Anyone else has any other inputs
that more closely correspond to reality? :-) Corrections? Pointers?
Gurus? I think many can benefit from this discussion, don't keep us in
the dark! It would be great if a generally general agreement/concensus
can be arrived at so we all can have a direction to work towards.
Also, follow-up to comp.os.linux.advocacy, where it belongs.
Cheers,
e. (bracing for flame/fireballs/wand of death/etc.)
--
_______________________________________________________________________________
Edwin _Lim_ Aun Whei | U of Calif., Irvine | Never let truth stand in the
el...@dodo.eng.uci.edu | Mech & Aerospace Engr | way of pride.
Warwick Allison
1. Qt DOES have the Motif Look-and-Feel (unless you run your applications
with "-style windows", in which case they ... ... <shudder>, I can't say it)
2. Motif is resource-unfriendly - you have to either statically link (ie. big
ugly slow binaries), or EVERY user pays for the libraries.
3. Qt source is available, and is written in C++, so you can trivially change
the library behaviour WITHOUT CHANGING THE SOURCE. Anyone who disagrees
with this point doesn't have a clue about C++.
4. All Qt-based applications can be distributed freely for X11 on any Unix
environment to which Qt has been ported (all popular variants, and some more
obscure).
Anyway, this has been over and over before - why do so many people in this
group still not have a clue? Probably because far too many just TALK about
what others should do and about the relative merits of various toolkits,
but don't actually DO any programming, so the same old have-heard rubbish
is repeated over and over.
--
Warwick
[yeah, I'm a little ticked]
--
_-_|\ war...@cs.uq.edu.au ---------------------------------------
/ * <- Comp Sci Department, Hackers do it with fewer instructions
\_.-._/ Univ. of Queensland, ---------------------------------------
v Brisbane, Australia. URL: http://student.uq.edu.au/~s002434
G Sumner Hayes
If Troll Tech and their lawyers are out there, they might want to read
through to the end of this posting. It describes a number of
relatively large legal loopholes in the licensing agreement; a
combination of these loopholes could possibly (I'm not a lawyer,
though I may be some year) allow the development of commercial
applications for Windows 95 (or NT, or MacOS,...) under the "free Qt
license". Oops.
Disclaimer: I am not a lawyer. All of the below information may be
incorrect. I assume no liability for damages caused by incorrect
information in this message.
war...@cs.uq.edu.au (Warwick Allison) writes:
>
> 4. All Qt-based applications can be distributed freely for X11 on any Unix
> environment to which Qt has been ported (all popular variants, and some more
> obscure).
Actually, this is not quite true and is something which has always
mystified me. The Qt free-software license agreement specifies the
following (among other things), which has a number of somewhat strange
consequences listed below:
> COPYRIGHT AND RESTRICTIONS
>
> The Qt toolkit is a product of Troll Tech AS. This license is limited to
> use on computers running the X Window System.
It does not specify that the license agreement applies only to Unix
systems; bear in mind that Unix is a trademark, and I don't know if
Linux has the right to call itself "Unix" or not. Certainly there are
things like VMS and the Hurd which run the X Window System but are not
Unix; the free Qt license applies to them. That's not where it ends,
though; there are several bogus factors here that should be cleared
up.
1. It is technically illegal for me to install Qt on my Linux machine
unless I start X first; the computer must be "running the X Window
System".
2. If I start X on one console, but then run Dosemu on another
console and run Windows 3.1 under Dosemu, it is technically legal for
me to develop Windows applications under free Qt. Similarly, I could
use Wine/WABI (if they're ever available and functional) with gcc
(which can cross-compile Win32 apps) to develop Windows apps from
Unix; according to the licensing agreement those applications do not
need to be X applications. The machine simply has to be "running the
X Window System".
3. If I install or MicroX (or another X server) on my Windows machine
or MacX on my Macintosh and run them, it is technically legal for me
to develop Windows or Macintosh applications under free Qt, even if
the applications are not X applications (since the machine _is_
"running the X Window System".)
4. More realistically, it is perfectly legal to develop X
applications if I am running PM/X or XFree86 under OS/2.
I don't mind any of the above except #1, but they seem to be clear
violations of the spirit of the licensing agreement (except perhaps
#4). I doubt it would be easy to implement the Windows-specific (or
Mac-specific) code needed to exploit #2 or #3, but it is technically
legal so long as the Qt core code isn't modified. I really don't see
why free software for Windows or OS/2 or MacOS or the Amiga or any
other platform is disallowed (especially when free software for
Solaris or HP/UX, also commercial OSes, is allowed), either, but c'est
la guerre.
Another bogosity is in the following:
> You may use the Qt toolkit to create application programs provided that:
> - You accept this license.
> - Your software does not require modifications to Qt.
What if my software does not _require_ modifications to Qt, but will
benefit from them?
Example #1: I find a bug in the Qt draw widget. I'm writing a paint
program. I distribute a patch to Qt with my program. The patch isn't
required, but without it the program may be buggy. Obviously I would
send the patch to Troll Tech, but if they for some reason decided to
abandon the free version it would be nice for this to remain an
option. Under the current scheme, it is a legal option; I would like
to see it remain legal.
Example #2: I write Windows extensions to Qt which require a
modification here and there to the Makefile. I write free apps on my
machine using loophole #2 or #3 from above. I distribute the software
and the Windows extensions. The software doesn't require the Windows
extensions, but they do allow it to run on additional platforms.
Hmm... I don't mind this, but the Troll Techies might want to
consider it.
Another problem, this one more alarming:
> You may use the Qt toolkit to create application programs provided that:
[Above conditions snipped to avoid repetition]
> - You satisfy ONE of the following three requirements
> EITHER
> Users of your software can obtain source code for the software, freely
> modify the source code (possibly with restrictions on copyright
> notices, attributions and legal responsibility), and freely
> redistribute original or modified versions of the software.
[Or the GPL is used, or the LGPL is used]
This first condition expressly permits me to do the following:
1. Write KillerQtApp, a super awesome Word Processor/Web Browser/C
Compiler/Spreadsheet rolled into one. Release KillerQtApp into the
public domain, but only upload it to Bob, my partner at KillerSoftware
Inc.
2. KillerQtApp is in the public domain. This more than satisfies the
free criterion of Qt's licensing agreement. Bob can now take it
(since it is in the public domain) and release a copy under
KillerSoftware, Inc's highly restrictive commercial licensing
agreement even without changing a single line of code or recompiling.
If I give Bob a binary of KillarQtApp, he won't be using Qt to do any
of the development or creation of the commercial app; he'll just be
changing the licensing scheme, which is perfectly legit. In fact, the
Qt free license implicitly allows this sort of behaviour by insisting
that my users (Bob) be allowed to distribute modified versions of the
software.
I may even be allowed to develop Qt apps in the public domain on
my own hard drive, compile them, then change the licensing scheme
myself; this is much more legally questionable, though.
More sophisticated exploits of this sort which stand an even better
chance of being upheld in court exist, too.
*sigh* American law is so strange. It's really obvious what you
mean, but your legal statements aren't airtight and I think it's
highly possible for the sort of thing I outline above to be ruled
legal by U.S. courts. I could be wrong, though.
I like Qt. I like Troll Tech. They seem to be honestly supporting
free software. I wish them the best of luck in clearing up this sort
of legal mumbo jumbo so they can continue to work on a great widget
set.
Disclaimer: I refuse any legal liability for any damage caused by
misinformation in this post.
TTFN,
Sumner Hayes
sum...@cmu.edu
Arnt Gulbrandsen
G Sumner Hayes <sum...@CMU.EDU>
> If Troll Tech and their lawyers are out there, they might want to read
> through to the end of this posting. It describes a number of
> relatively large legal loopholes in the licensing agreement; a
> combination of these loopholes could possibly (I'm not a lawyer,
> though I may be some year) allow the development of commercial
> applications for Windows 95 (or NT, or MacOS,...) under the "free Qt
> license". Oops.
When we chose to release the source, we knew that would leave us wide
open. There are some small license holes, there more or less have to
be in order to make Qt usable for free software, and it's very very
easy for the dishonest to simply ignore the license.
If we can make a decent living from the honest _and_ provide a good
GUI toolkit for the unix/x11 free software community, we're satisifed.
> It does not specify that the license agreement applies only to Unix
> systems; bear in mind that Unix is a trademark, and I don't know if
> Linux has the right to call itself "Unix" or not. Certainly there are
> things like VMS and the Hurd which run the X Window System but are not
> Unix; the free Qt license applies to them. That's not where it ends,
> though; there are several bogus factors here that should be cleared
> up.
If you want to use Qt on unicos, the Hurd, QNX, linux or something
else which runs X11 but isn't Spec 1170-certified, that's okay. The
X11 version of Qt is for X11, not for unix.
> 1. It is technically illegal for me to install Qt on my Linux machine
> unless I start X first; the computer must be "running the X Window
> System".
In our opinion, no. If you really want to pick nits about the meaning
of "run": When you install Qt, your CPU is necessarily installing Qt,
not running X.
> 2. If I start X on one console, but then run Dosemu on another
> console and run Windows 3.1 under Dosemu, it is technically legal for
> me to develop Windows applications under free Qt.
>
> 3. If I install or MicroX (or another X server) on my Windows machine
> or MacX on my Macintosh and run them, it is technically legal for me
> to develop Windows or Macintosh applications under free Qt, even if
> the applications are not X applications (since the machine _is_
> "running the X Window System".)
Technically legal, but you'd need the Windows version of Qt to
compile. And there isn't any free software license for the Windows
version.
> 4. More realistically, it is perfectly legal to develop X
> applications if I am running PM/X or XFree86 under OS/2.
Certainly.
> I don't mind any of the above except #1, but they seem to be clear
> violations of the spirit of the licensing agreement (except perhaps
> #4). I doubt it would be easy to implement the Windows-specific (or
> Mac-specific) code needed to exploit #2 or #3, but it is technically
> legal so long as the Qt core code isn't modified. I really don't see
> why free software for Windows or OS/2 or MacOS or the Amiga or any
> other platform is disallowed (especially when free software for
> Solaris or HP/UX, also commercial OSes, is allowed), either, but c'est
> la guerre.
We like the Unix/X11 free software community.
> Another bogosity is in the following:
>
> > You may use the Qt toolkit to create application programs provided that:
> > - You accept this license.
> > - Your software does not require modifications to Qt.
>
> What if my software does not _require_ modifications to Qt, but will
> benefit from them?
>
> Example #1: I find a bug in the Qt draw widget. I'm writing a paint
> program. I distribute a patch to Qt with my program. The patch isn't
> required, but without it the program may be buggy. Obviously I would
> send the patch to Troll Tech, but if they for some reason decided to
> abandon the free version it would be nice for this to remain an
> option. Under the current scheme, it is a legal option; I would like
> to see it remain legal.
(There isn't a "draw widget" in Qt.)
Is there any way we might reassure you that the free license isn't
going away in any future version of Qt, _without_ further endangering
our ability to sell professional licenses?
Statement of company policy: We will continue to release new versions
of Qt for X11 for free software use.
> Example #2: I write Windows extensions to Qt which require a
> modification here and there to the Makefile. I write free apps on my
> machine using loophole #2 or #3 from above. I distribute the software
> and the Windows extensions. The software doesn't require the Windows
> extensions, but they do allow it to run on additional platforms.
> Hmm... I don't mind this, but the Troll Techies might want to
> consider it.
Right. Of course, in real life you'd probably buy a professional
license rather than spend a year writing something which people may
not be allowed to use with future versions of Qt.
> Another problem, this one more alarming:
<alarming problem deleted for brevity>
> More sophisticated exploits of this sort which stand an even better
> chance of being upheld in court exist, too.
Sure - but _is_ there any way to allow free software development in
all its strange varieties while disallowing everything else?
Personally, I think your fictional pal would be flamed to the south
pole by the c.o.l.* readers. If he's rational and wants to make a
profit, he might choose to buy a commercial license. It's not that
expensive, after all.
> *sigh* American law is so strange. It's really obvious what you
> mean, but your legal statements aren't airtight and I think it's
> highly possible for the sort of thing I outline above to be ruled
> legal by U.S. courts. I could be wrong, though.
Right or wrong - lawyers' fees are rather steeper than our
professional license.
--Arnt
Arthur Jerijian
In article <5400v7$c...@dialin33.zdv.uni-mainz.de>, Paul Seelig wrote:
>In article <326322...@erols.com>,
> Greg Howland <g...@erols.com> writes:
>> This sounds very similar to the Afterstep project.
>>
>As to my understanding Afterstep is just about another window manager.
>But Matthias' idea is about a desktop environment (can you say CDE?) which is
>a whole different thing.
>
>> Have you considered working with them?
>>
>Read his posting again. He is clearly differentiating a window manager from
>a desktop environment. Afterstep is about looks but not functionality and
>the KDE is primarily an approach for functionality.
He probably meant GNUstep, which is intended to be a complete GPLed
OpenStep replacement. You can find more information about AfterStep
at http://www.afterstep.org.
>--
> Paul Seelig pse...@goofy.zdv.uni-mainz.de
> African Music Archive - Institute for Ethnology and Africa Studies
> Johannes Gutenberg-University - Forum 6 - 55099 Mainz/Germany
> Our AMA Homepage in the WWW at http://www.uni-mainz.de/~bender/
--Arthur
Martin Spott
Hi Matthias,
Matthias Ettrich (ett...@ti-ibm03.informatik.uni-tuebingen.de) wrote:
>
> -------------------------------------------
> New Project: Kool Desktop Environment (KDE)
> -------------------------------------------
[...]
I wouldn't like to see just another desktop development.
Linux gains popularity and respect by going conform to already existing
(open) standards. Why don't you/we call for support of the GnuStep project
if you/we don't like commercial desktops ?
This is a project to implement a desktop which is based on an open standard,
not bound to commercial Motif, possibly a little bit huge but very
functional and it goes the object oriented way, which will be a very
important criteria already in the near future.
There already exist implementations on NeXT and Solaris/Sparc.
See www.gnustep.org (Nort America) or
www.nmr.embl-heidelberg.de (Europe)
Martin.
--
EMail: I prefer correspondence to: Martin...@onyx.dirnet.com
If necessary, business mail can be sent to: Martin...@uni-duisburg.de
--------------------------------------------------------------------------
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------
Matthias Ettrich
William P Shaw (wps...@pitt.edu) wrote:
: In article <53vkaq$n...@newsserv.zdv.uni-tuebingen.de>,
: Matthias Ettrich <ett...@ti-ibm01.informatik.uni-tuebingen.de> wrote:
: >nall (na...@spike.cs.duke.edu) wrote:
: >: >
: >: > I really believed that is even yet possible with Linux until I
: >: > configured my girlfriends Box.
: >
: >: was 'configuring your girlfriends' "box"' really that traumatic? <grin>
: >
: >yes, unfortunatly :-( I needed several hours and the result isn't as
: >good as I expected.
: Several hours! If I spent that long working with the 'box' and I
: didn't produce the expected result, I'd be sleeping on the front
: porch! --Bill.
Toll einen Auslaender mit Wortwitzen zu aergern. Spitze. Noch
was Konstruktives? ;-)
Sorry I didn't get it. Not really my kind of humour anyway.....
Best regards,
Matthias
: --
Ingo Luetkebohle
Linh Dang wrote:
> If their primary target is Linux, I think they would rather use Qt
> since they don't have to staticly link the gui lib in.
Did you ever see a company whose primary target is Linux?
---Ingo
Ingo Luetkebohle
Brian Kimball wrote:
> My impression is that a bunch of people just recently realized that the
> current linux/X situation really bites and they all decided to start
> their own little projects.
Yes, indeed, that is the fact. There exist (at least) the Linux
Interface Project (http://blank.pages.de/lip/subscribe.html for ml
information), OpenStep (a.k.a GNUstep), the Gtk group (with a slightly
different focus), a project of the Free Software Union, EZWGL and some
others I probably forgot.
And the dicussion is always the same. I have seen a posting from Warwick
Allison which boils down to a pretty good explanation of why people
choose Qt. He and I had some heated discussions about why _not_ to
choose Qt on the lip mailing list so if you need reasons for that, look
at the archive. I also traced the discussion that erupted once Peter
Mattis and Spencer Kimball announced their Gtk toolkit. It was
remarkably similiar to what I see here (e.g. "There are already many
good toolkits: Tk, XForms, Lesstif, Qt, etc").
The bottom line is, I'm rather tired now, from hearing the same
arguments again and again. I consider it especially interesting that
Matthias, for all the good has done otherwise, didn't even consider it
necessary to check if there are already any projects out which do what
he wants to do. I would be perfectly willing to take back my
suggestions, even if I consider them better, if that results in one
common project and I believe that many of the programmers currently with
the LIP are of the same opinion.
Unfortunately, many other people don't see the necessity to have one
common project. As long as that isn't the case, we will probably have to
just go along and chose among the things that evolve. This is rather
similiar to the way things have gone in the past with other standards
(TCP/IP for example) so this might not be the worst way to choose. I
fear, though, that it may be the slowest way to choose.
> It would be nice to see people buckle down
> and focus on one common project (like the KDE). I think this would add
> a lot of value to linux. Good luck dude.
I heartily agree. Lets get together folks and stop bitching.
---Ingo
John Hasler
Sumner Hayes writes:
> 2. KillerQtApp is in the public domain. This more than satisfies the
> free criterion of Qt's licensing agreement. Bob can now take it
> (since it is in the public domain) and release a copy under
> KillerSoftware, Inc's highly restrictive commercial licensing
> agreement even without changing a single line of code or recompiling.
I have a copy of "A Midsummer Night's Dream" on my bookshelf: the title
page says "all rights reserved", ie, the most restrictive possible license.
Yet I can copy out the text and do anything I want with it. Why? Because
the text is in the public domain. The copyright applies only to the
publishers changes, that is, his book design and typesetting.
KillerQtApp is in the public domain: it has no copyright. Bob has
copyright only on his changes. As he made no changes, he has no copyright
and so cannot enforce his licensing agreement. If he does make changes, I
can take them out and then release my version as I wish.
> *sigh* American law is so strange. It's really obvious what you mean,
> but your legal statements aren't airtight and I think it's highly
> possible for the sort of thing I outline above to be ruled legal by
> U.S. courts.
I think you are wrong about these specific examples, but I agree that Troll
Tech's license is vague and ill-conceived. They should either use the GPL
or hire an attorney (I'm not one).
--
John Hasler This posting is in the public domain.
jgha...@win.bright.net Do with it what you will.
Dancing Horse Hill Make money from it if you can; I don't mind.
Elmwood, Wisconsin
G Sumner Hayes
Ingo Luetkebohle <i...@devconsult.de> writes:
>
> Did you ever see a company whose primary target is Linux?
>
Yes, several. The most famous is probably Caldera.
TTFN,
Sumner
Kenneth Michael Apa
I think the whole KDE idea is worth three thumbs-up. I think we should
ask ourselves some questions before we get cracking.
1) There is going to be the whole C vs. C++ vs. Objective-C war.
Everyone has their own idea of what the greatest language on earth is.
I think if your going to use Objective-C you should support GNUstep and
help out there as much as you can. It would be really unproductive to
duplicate with they are already doing. C has had it far share of
toolkits. I agree with the original poster that we should use C++, but
perhaps we should vote on it.
2) I think we should kiss everyones standards goodbye. We're linux users,
right??? We can do things better and faster anyways. CDE = Motif part2.
Besides, CDE was outdated before the first alpha versions were in testing.
Lets let HP have CDE, SGI have OpenGL, Sun have Openlook(I know everyone
agrees with that one). Linux should have it's own standards and APIs for
just about everything, because Linux is better than the commercial Unices.
3) QT is real cool, but it's huge. They've got classes for everything.
Don't get me wrong. I think QT one of the best development tools I've
ever seen, but we could improve upon it. A smaller toolkit with a GUI
builder would be great. Let's keep the learning curve low. QT is just
too huge.
4) Let's take the best from each UI and make it better. An example might
be something like: NextMail, Iris Insight(online help), Mac
Scrapbook(said before), Windows95 style filemanager with a SGI style
IconCatalog, and some killer Icons(ray-traced in BMRT/real photos).
5) Everthing organized on a website so people can see what projects are
underway.
What does everyone think? I say let's kick some ass!
Ken
Brady Montz
wps...@pitt.edu (William P Shaw) writes:
>
> In article <53vkaq$n...@newsserv.zdv.uni-tuebingen.de>,
> Matthias Ettrich <ett...@ti-ibm01.informatik.uni-tuebingen.de> wrote:
> >nall (na...@spike.cs.duke.edu) wrote:
> >: >
> >: > I really believed that is even yet possible with Linux until I
> >: > configured my girlfriends Box.
> >
> >: was 'configuring your girlfriends' "box"' really that traumatic? <grin>
> >
> >yes, unfortunatly :-( I needed several hours and the result isn't as
> >good as I expected.
>
> Several hours! If I spent that long working with the 'box' and I
> didn't produce the expected result, I'd be sleeping on the front
> porch! --Bill.
> --
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> ++ William Shaw the shaman wps...@pitt.edu ++
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Box privileges revoked!
--
Brady Montz
bra...@cs.arizona.edu
Arnt Gulbrandsen
xk...@uxa.ecn.bgu.edu (Kenneth Michael Apa)
> 3) QT is real cool, but it's huge. They've got classes for everything.
> Don't get me wrong. I think QT one of the best development tools I've
> ever seen, but we could improve upon it. A smaller toolkit with a GUI
> builder would be great. Let's keep the learning curve low. QT is just
> too huge.
As one of the Qt developers, may I ask what parts of it could be
dispensed with?
--Arnt
Tim D. Gilman
Kenneth Michael Apa <xk...@uxa.ecn.bgu.edu> wrote:
>
>3) QT is real cool, but it's huge. They've got classes for everything.
>Don't get me wrong. I think QT one of the best development tools I've
>ever seen, but we could improve upon it. A smaller toolkit with a GUI
>builder would be great. Let's keep the learning curve low. QT is just
>too huge.
Sorry, but this is an ignorant statement. Qt is not huge. It is rather
small for a full blown GUI. Also keep in mind that it's basically
written from scratch (directly on top of Xlib, which is a *good* thing).
It doesn't depend on Xt or Xaw or any other crappy toolkit. It's
no-nonsense built the *right* way from the ground up.
As far as I'm concerned, Xt, Xaw and Xm should be blown off the face
of the earth never to be seen again. They're old dinosaurs and it's
embarassing that they still are around and kicking.
Let's face it. It doesn't get much better than Qt. It's small, fast,
rich, easy to use and understand, practical, great cross-referenced
documentation, Troll Tech is generous to free-software developers and
responsive to all developers. Nobody is going to come up with
something as good in a reasonable amount of time, and the fact that
it's maintained by people who get up and go to work on it everyday
helps to ensure its success and existence.
I'm pessimistic about this whole project for a couple of reasons. One,
I don't really like the name (K00L desktop). Two, I have heard these
kinds of ideas for years, which turn into fly-by-night science
projects, and then fizzle into oblivion. I think that's because 1)
there is no real leader who actually knows what he is doing and/or 2)
nobody is willing to spend the time it really takes, because unless
they become famous or something, there is no real reward.
This can't just be a group of people writing a mismash of different
things and sending it to a guy who puts it all together. To take on
something this ambitious, there needs to be a talented, knowledgable
leader who has a lot of time on his hands (like Linus).
Who is going to step forward and pull off a desktop environment that is
unified and built from the ground up, not just fvwm hacks and icons
that do "xterm -exec vi?"
Who has the ability, time and vision to really pull it off?
--
Tim D. Gilman <tdgi...@best.com> <tdgi...@bigbang.berkeley.edu>
http://www.best.com/~tdgilman
.fvwmrc archive: ftp://ftp.best.com/pub/tdgilman/Fvwmrcs
G Sumner Hayes
Arnt Gulbrandsen <agu...@troll.no> writes:
>
> When we chose to release the source, we knew that would leave us wide
> open. There are some small license holes, there more or less have to
> be in order to make Qt usable for free software, and it's very very
> easy for the dishonest to simply ignore the license.
Okay, sounds good. I have no problems adhering to the spirit of the
agreement, but I also have a twisted mind that likes to look for
loopholes. I just thought I'd point them out in case you hadn't
considered this.
TTFN,
Sumner
Markus Gutschke
G Sumner Hayes <sum...@CMU.EDU> writes:
> kca...@freenet.columbus.oh.us (Kevin Cabral) writes:
> > BTW: I hope you will consider porting LyX over to Qt in the future, and I
> > hope that The Gimp will also join it in moving to more open libraries.
> >
> The Gimp, in new versions, doesn't require Motif; it uses a free
> Motif-appearance toolkit written over Xlib only for speed.
>
> I think it's only available to developers, but they say it works
> really well and will be the basis of the next release of the Gimp.
Ah, is that why the developers' version keeps crashing on me :-) I
really like all of the new features, but so-far the current
developers' release is a little shaky. I am looking forward to the
next official release.
Markus
Brian H Cooper
>Sorry, but this is an ignorant statement. Qt is not huge. It is rather
>small for a full blown GUI. Also keep in mind that it's basically
>written from scratch (directly on top of Xlib, which is a *good* thing).
>It doesn't depend on Xt or Xaw or any other crappy toolkit. It's
>no-nonsense built the *right* way from the ground up.
> [...]
>
>Who is going to step forward and pull off a desktop environment that is
>unified and built from the ground up, not just fvwm hacks and icons
>that do "xterm -exec vi?"
>
>Who has the ability, time and vision to really pull it off?
>
>--
>Tim D. Gilman <tdgi...@best.com> <tdgi...@bigbang.berkeley.edu>
I think these two statements should form the basis of any continuing
discussion of this topic.
For those who don't like Qt, want everyone to buy Motif, think GNUstep
is going to be dandy, or want the Linux to subscribe to some other
commercial standard - Great! but take it elsewhere. There's absolutely
no point in trying to stop someone from offering another choice for
free. Don't like? Don't download it. Big deal. Put this subject
in yer kill file.
For those who think this is a pretty good idea, there seems to be a
consensus that Qt is done The Right Way and we like Troll Tech.
Therein lies the standard against KDE ought to be judged. Will
we develop it planned from the ground up as good as it's underlying
lib.
As for "Who has the ability, time and vision to really pull it off?"
I would hope that Matthias, being the original poster, would step
in and assume this role publicly, and it probably won't take another
Linus.
Here are a couple points I think ought to be considered:
1) This is another CHOICE. The developers may think it blows everything
else away but let's not get confused and think we have to fight anybody
over it. In the lab where I am, they just threw on CDE, and if
you don't like it, tough. I thought that was pretty rude. The argument
of "well why didn't the original poster just look at some existing
standard or support GNUstep etc" is IRRELEVANT.
2) There have been some comments about icon this and that and extreme
graphics. That's nice but not everyone wants that garbage/can handle
the load. Development will naturally drift toward a "look-and-feel"
but design ought to consider _from_the_beginning_ having every aspect
user configurable. I want a choice. The small amount of considerate
code added for this will not nearly match the bloat in silly cuteness
that some app developers will want to put in.
3) Matthias in his original posting noted specifically that this is
for ENDUSERS. I don't tend to view my machine that way, so a lot
of that doesn't appeal to me and I tend to abuse it installing
all sorts of mishmash stuff to see what I like, but I'd like the
rest of my family to be able to use it without asking me questions.
Especially my little one who is due in the spring. (At least
until he/she is nine years old or so and should be programming in C/C++
and abusing the machine in his/her own way ;)
4) Matthias Ettrich's document processor LyX is awesome and I wouldn't
have given this thread a second thought if not for that. It would give
his argument considerably more weight if he could convince the LyX team
to go for Qt instead of Xforms. hint hint.
Brian Cooper
Chris Waters
In article <543pfq$m...@charm.magnus.acs.ohio-state.edu>,
Brian H Cooper <coo...@concord.eng.ohio-state.edu> wrote:
>Here are a couple points I think ought to be considered:
>1) This is another CHOICE. The developers may think it blows everything
>else away but let's not get confused and think we have to fight anybody
>over it. In the lab where I am, they just threw on CDE, and if
>you don't like it, tough. I thought that was pretty rude. The argument
>of "well why didn't the original poster just look at some existing
>standard or support GNUstep etc" is IRRELEVANT.
No, it's not! If you like the idea and want to succeed quickly, then
it's in your best interests to claim that other projects are irrelevant,
of course. Contrariwise, if you think that standards are a good thing
(and have a lot to do with why Linux has been so successful), then you
may want to remind people of this fact before they go running off
dumping a lot of time and energy into a project like this; time that
they might well have preferred to invest in creating something more
standard if only they had realized that that was an option.
I *am* in the latter camp; I don't actually object to a project like
this, but I want to retain the right to remind people that there are
other projects, which may be more useful in, for example, allowing
people to bring stuff from the office to work on at home at their Linux
boxen.
Yes, I do think that both sides have to fight! There are only so many
Linux developers, and people who are qualified to work on this project
are probably qualified to work on the others. OTOH, I don't think
either side has to fight very hard; the number of Linux programmers is
finite, but reasonably large and growing. I just object to being told
that I can't offer *any* negative comments in this thread no matter what
my feelings are about it.
Consider this: if Linux had come with pico, and you *could not get*
either vi or emacs for it, do you think it would have been as much of a
success? Of course, once you have vi and emacs, offering pico as well
is a win-win situation. Well, at the moment, you *can not get* a freely
distributable Motif/CDE or NeXTStep. Saying "forget it, we don't need
'em if we build this," strikes me as a lot like saying, "forget vi and
emacs, we don't need 'em if we build pico." Allow me to disagree--we
*do* need Motif, no matter how much you may think it sucks (and a lot of
people think both vi and emacs suck too). I have no objection to
alternatives--I might even like them better. I just hate too see *too*
much energy spent on them while the standard stuff--which some people
will *need* to see before they'll take Linux seriously--languishes.
david parsons
In article <543mtu$a...@shellx.best.com>,
Tim D. Gilman <tdgi...@best.com> wrote:
>Who is going to step forward and pull off a desktop environment that is
>unified and built from the ground up, not just fvwm hacks and icons
>that do "xterm -exec vi?"
You say this as if something is *wrong* with 'xterm -exec vi'; a GUI
environment that doesn't let people use their favorite editor isn't
one that's worth the effort of untarring onto their machine.
____
david parsons \bi/ Shoot, even Windows lets you use your favorite editor.
\/
Bryan Seigneur
Wonderful, wonderful idea. But before you start another project
and make a new TLA, find out who's working on the same thing. Not
to criticize, but just to do my job. This is what a forum is for.
You will undoubtedly get a very detailed picture of where we are
in this free interface issue very quickly from the ensuing thread.
There is at least one project I know of which is working on
building a GOOD gpl'd interface specifically for Linux (but
since it would be free, it would undoubtedly be ported, at least
to other Intel OSes). I think they named it LIP (Linux Interface
Project). If messing around with Linux has taught me anything,
it's that often what you need is out there, it's just a matter of
finding it, or at least assembling the parts.
Anyway, just wanted to let you know about LIP. I'm sure much more
useful data will be added, too, before the thread dies. Here you
can find how to contact the LIP people, get on the maillist, etc:
http://homepages.munich.netsurf.de/Michael.Dingler/lwp.html
I love the name (KDE), I'm sure as they think about/start to
do things in LIP, they could use a great ironic name like that.
Yes, plenty of objects to recieve TLAs ;)
Matthias Ettrich wrote:
>
> -------------------------------------------
> New Project: Kool Desktop Environment (KDE)
> -------------------------------------------
>
> Programmers wanted!
>
> Motivation
> ----------
>
> Unix popularity grows thanks to the free variants, mostly Linux. But still a
> consistant, nice looking free desktop-environment is missing. There are
> several nice either free or low-priced applications available, so that
> Linux/X11 would almost fit everybody needs if we could offer a real GUI.
...
Now, eagerly going to reading your post in its entirety,
--
Bryan Seigneur
/ / inux
/ /__ink ==> http://www.sonetech.com/~bry/linmarks.html
/____/ist
Asger K. Alstrup Nielsen
>have given this thread a second thought if not for that. It would give
>his argument considerably more weight if he could convince the LyX team
>to go for Qt instead of Xforms. hint hint.
You can probably bribe us :-)
Greets,
Asger Alstrup
Anselm Lingnau
Im Artikel <32651589...@devconsult.de> schrieb
Ingo Luetkebohle <i...@devconsult.de>:
> Did you ever see a company whose primary target is Linux?
Caldera?
Anselm
--
Anselm Lingnau ......................... lin...@tm.informatik.uni-frankfurt.de
Trying to outsmart a compiler defeats the purpose of using one.
--- Brian Kernighan & P. J. Plauger, *The Elements of Programming Style*
Warwick Allison
xk...@uxa.ecn.bgu.edu (Kenneth Michael Apa) writes:
>3) QT is real cool, but it's huge. They've got classes for everything.
>Don't get me wrong. I think QT one of the best development tools I've
>ever seen, but we could improve upon it. A smaller toolkit with a GUI
>builder would be great. Let's keep the learning curve low. QT is just
>too huge.
I wrote my first derived widget class in Qt just 24 hours after downloading
it, yet some Motif programmers go on for years without ever doing so. If Qt
is anything, it isn't difficult to learn - check out the awesome on-line
docs (http://www.troll.no/qt/index.html).
As for huge, surely you don't mean the executables are huge - programs
can be as small as 10K, since they dynamically link (unlike evil Motif
for most free software users), and even the dynamic library is only 840K,
that's close to Xt+Xaw3d (610K), yet packs in four times the functionality.
Finally, YES, "we could improve upon it". That's the great thing about
C++ - you can extend other code to your wishes without having to hack away
at the base code.
--
Warwick
Brian H Cooper
In article <designDz...@netcom.com>,
Chris Waters <des...@netcom.com> wrote:
>In article <543pfq$m...@charm.magnus.acs.ohio-state.edu>,
>Brian H Cooper <coo...@concord.eng.ohio-state.edu> wrote:
>
>>of "well why didn't the original poster just look at some existing
>>standard or support GNUstep etc" is IRRELEVANT.
>
>No, it's not! If you like the idea and want to succeed quickly, then
>it's in your best interests to claim that other projects are irrelevant,
The projects themselves are not irrelevant. You should have gathered
that from my insistence on choice. The claim that Matthias didn't
foresee this in his original post IS. His arguments were clearly
layed out, that yes there are all these other projects and
a lot of people will think they are dandy, but he and others are
going to this anyway.
>
>Yes, I do think that both sides have to fight!
For the sake of principle, I have to agree with you here, but I think
your reason (below) is flawed.
> There are only so many
>Linux developers, and people who are qualified to work on this project
>are probably qualified to work on the others. OTOH, I don't think
I don't think Linux developers are a resource to be monopolized. My
time is my time.
> I just object to being told
>that I can't offer *any* negative comments in this thread no matter what
>my feelings are about it.
I give in on this point. But in the past 36 hours I have seen the
same few arguments presented 6 ways from sunday. Can I suggest a
more productive line of attack:
Hey I think trying to make this environment is a great
idea. I think we need these features: a,b,c,d,e.
Then sit back and let everybody say: Yeah! That's exactly what we
need except 'e' sucks.
Then you say (here's the kicker): Well system Z is doing all that
except maybe 'd' is pretty much crap right now but if you guys
wanted to fill in this piece, we're done!
Then the final step is to see how many pieces f,g,h,i that KDE people
want that system Z will _never_ be interested in.
As far as OG's Motif+CDE goes (the system I was complaining about
originally), the powers that be have tried to convince us it's great
this and that, but it treats the user like a child. Granted, that
kind of "standard" may get it far in the MS world, but I really do
think we can do without it.
>
>Consider this: if Linux had come with pico, and you *could not get*
>either vi or emacs for it, do you think it would have been as much of a
>success? Of course, once you have vi and emacs, offering pico as well
>is a win-win situation. Well, at the moment, you *can not get* a freely
>distributable Motif/CDE or NeXTStep. Saying "forget it, we don't need
>'em if we build this," strikes me as a lot like saying, "forget vi and
>emacs, we don't need 'em if we build pico." Allow me to disagree--we
>*do* need Motif, no matter how much you may think it sucks (and a lot of
>people think both vi and emacs suck too). I have no objection to
>alternatives--I might even like them better. I just hate too see *too*
>much energy spent on them while the standard stuff--which some people
>will *need* to see before they'll take Linux seriously--languishes.
I think this argument can be turned on it's head. Restate your
quote as "forget it, we don't need another free environment
project if we just let Open Group and Gnu build theirs"
BTW: jed is the one true editor ;)
Whether Motif sucks or not, I don't think the mainstream Linux community
can accept any system without freely available source, and clones
are going to have a tough time when OG merges it with X and CDE.
GNUstep looks like it's gearing up to be a graphical monster. Someone
please correct me if it's gonna go great on my 486/33 8Mb machine.
If I wanted to startup swapping out 4 Mb I'd use ms-windows.
James Youngman
In article <53tkvv$b...@newsserv.zdv.uni-tuebingen.de>,
ett...@ti-ibm03.informatik.uni-tuebingen.de says...
>
>
> -------------------------------------------
> New Project: Kool Desktop Environment (KDE)
> -------------------------------------------
>
> Programmers wanted!
Why not just contribute to the development of GNU Teak?
--
James Youngman VG Gas Analysis Systems |The trouble with the rat-race
Before sending advertising material, read |is, even if you win, you're
http://www.law.cornell.edu/uscode/47/227.html|still a rat.
Ingo Luetkebohle
Anselm Lingnau wrote:
> Caldera?
Or LST, SuSE, Redhat, whatever. Yeah, sure, all those distributions have
Linux as their primary targets. I have nevers seen anyone of them
producing an office application, though.
The bottom line is: I am opposed to the "We are Linux, we don't need the
rest of the world" statements that have been voiced in this group. It
can never be wrong if something runs over many platforms.
---Ingo Luetkebohle
Kenneth Michael Apa
Arnt Gulbrandsen (agu...@troll.no) wrote:
: xk...@uxa.ecn.bgu.edu (Kenneth Michael Apa)
: > 3) QT is real cool, but it's huge. They've got classes for everything.
: > ever seen, but we could improve upon it. A smaller toolkit with a GUI
: > builder would be great. Let's keep the learning curve low. QT is just
: > too huge.
: As one of the Qt developers, may I ask what parts of it could be
: dispensed with?
All of those drawing routines for one. We can do that stuff in Xlib. We
just need a canvas. What we really need is something small that we can
build off of. QT wasn't design to be small so it's hard to really get
rid of any of the parts. I understand that you wanted to get rid of some
of the horrors of X programming(colormaps and fonts come to mind), but
your going to have to learn a little Xlib down the road anyways.
Ken
Peter A. Koren
In article <32635025...@lrz.uni-muenchen.de>,
Henning....@lrz.uni-muenchen.de says...
>
>I don't want to start a new widget war. If someone wants to start a
>project like KDE with Qt, it ok. But I think it is a good idea to have
>a close look at GNUStep ( http://www.gnustep.org ) before starting.
>GNUStep is becoming a clone of the OpenStep API from Next including a
>RTF textwidget and Display Postscript.
>
> Henning
>
>--
>Henning Brockfeld mailto: Broc...@wigeo.bwl.uni-muenchen.de
>Institut f"ur Wirtschaftsgeographie Universit"at M"unchen
>
>http://www.wigeo.bwl.uni-muenchen.de/~hbrock/
Good thought! What is the point of further fragmenting the Linux community on
selecting a GUI when an superior design is well along in being ported to
Linux?
One additional point to be made about GNUStep is that framworks are based on
objective C, a dynamically typed and dynamically bound language (and part of
the normal GNU gcc/g++ distribution). It is far simpler to do high quality OO
programming in objective c than in C++. It also subsumes all of C and can be
used in code along with legacy C++. And, of course, as the GNU moniker
indicates, GNUStep is GPL'd.
Peter Koren
pko...@gte.net home Linux Box `:-)
pko...@ti.com work WIN NT :-(
G Sumner Hayes
> : As one of the Qt developers, may I ask what parts of it could be
> : dispensed with?
>
> All of those drawing routines for one. We can do that stuff in
> Xlib.
Gods, no. Xlib should be avoided at all costs; once you start making
xlib calls, you lose portability to other platforms. (It's the C vs.
Assembly argument all over again!)
TTFN,
Sumner
Steve Mazza
Hi -
Drawing routines should be done in Xlib.
X is portable. Therefore, so is the proposed project.
In article <0mNbSJ200...@andrew.cmu.edu>,
G Sumner Hayes <sum...@CMU.EDU> writes:
--
Cheers,
Steve -
====================================================
TSD, Inc maz...@steitz.com
1714 Connecticut Avenue NW http://www.steitz.com
Washington, DC 20009 http://204.180.171.217
phone: (202) 986-0024 fax: (202) 986-0014
====================================================
Frederick (Rick) A Niles
Just to give my opinion...
If it's not GPL ... I'm againist it!
Your going to run in to the same hassles as with
Motif eventually. Just use lesstif or write your
own widget library.
Best / Worst case scenario:
Your project is a wild success to the point no
one wants to run Linux without it. However, you're
still tied to a proprietary solution and your can't
use it with other commercial UN|Xs without paying....
I think that's a bad place to be and would only
serve to undermine the concept of Linux as being
total free from licenses.
It's quite un-GNU...
--
Rick Niles.
Grant Edwards
Lars Hofhansl (lhof...@indiana.edu) wrote:
: I just want to give a few comment on that.
: Admittedly I'm tired of this TK-Monster-tale!
: It's slow when you write the whole application in plain TCL, but that's not
: how is was meant to be.
: You actually can register C-procedures as TCL-commands and call them
: directly from the interpreter (the only overhead is the command-parsing at
: runtime). You can also call evaluate small TCL-Scripts from within C.
[...]
: Granted, it's tempting to write the whole application in TCL/TK, and
: some guys seem to have misunderstood the whole idea.
: But then again, what do you want?
: - you can write the whole thing in TCL which is easy but slow
You can write the whole thing in Scheme, which is easier and faster. ;)
(or Python, or Perl5, or any of the other languages that work with Tk.)
--
Grant Edwards | Microsoft isn't the | Yow! There's a little
Rosemount Inc. | answer. Microsoft | picture of ED MCMAHON doing
| is the question, and | BAD THINGS to JOAN RIVERS in
gra...@rosemount.com | the answer is no. | a $200,000 MALIBU BEACH
| HOUSE!!
david parsons
In article <3266F0FD...@axp745.gsfc.nasa.gov>,
Frederick (Rick) A Niles <ni...@axp745.gsfc.nasa.gov> wrote:
>Just to give my opinion...
>
>If it's not GPL ... I'm againist it!
>
>Your going to run in to the same hassles as with
>Motif eventually. Just use lesstif or write your
>own widget library.
And watch it die. Qt wins big over Motif in that it is possible to get
free copies, even though they've got rather restrictive licensing terms
for them. And it is reportedly portable so that you can migrate apps
from one platform to Windows, if need be.
>I think that's a bad place to be and would only
>serve to undermine the concept of Linux as being
>total free from licenses.
Linux isn't free from licenses. On any given distribution, you'll find
licenses galore, from the GPV through the BSD license and all the way to
the MIT license.
____
david parsons \bi/ o...@pell.chi.il.us
\/
William Burrow
Steve Mazza (maz...@doobie.steitz.com) wrote:
: Hi -
: Drawing routines should be done in Xlib.
: X is portable. Therefore, so is the proposed project.
Qt is portable to MacOS, Win95 and WinNT. Sure, X may be on those
platforms, but not everyone is using X on them.
The mere association of KDE with Qt does not imply that it is portable to
those other platforms. Already, somebody is developing an application
that uses a jpeg library for Unix. There is a portability issue there.
I don't wish to start a portability war (yeah, too late), but it takes
effort to make portable software.
--
--
William Burrow -- Fredericton Area Network, New Brunswick, Canada
Copyright 1996 William Burrow
This line left intentionally blank.
Lars Gullik Bjonnes
>> Frederick (Rick) A Niles writes:
[..]
FAN> Best / Worst case scenario: Your project is a wild success to
FAN> the point no one wants to run Linux without it. However,
FAN> you're still tied to a proprietary solution and your can't use
FAN> it with other commercial UN|Xs without paying....
When did you read the Qt license? Free for machines running X Window
system it says.
FAN> I think that's a bad place to be and would only serve to
FAN> undermine the concept of Linux as being total free from
FAN> licenses.
FAN> It's quite un-GNU...
Yes, let's make Linux license free: drop GPL, Linux as freeware!
Lgb
Anselm Lingnau
Im Artikel <545oqb$l...@sf18.dseg.ti.com> schrieb
Peter A. Koren <pko...@ti.com>:
> One additional point to be made about GNUStep is that framworks are based on
> objective C, a dynamically typed and dynamically bound language (and part of
> the normal GNU gcc/g++ distribution).
Is it just me, or is anybody else wary of a philosophy that is implicitly
tied to One True Language (be that Objective C, C++, Java, ...)?
Anselm
--
Anselm Lingnau ......................... lin...@tm.informatik.uni-frankfurt.de
[I believe] that science is one of the primary art forms of the 20th century.
--- Steve Roy
Anselm Lingnau
Im Artikel <326650DF...@devconsult.de> schrieb
Ingo Luetkebohle <i...@devconsult.de>:
> Or LST, SuSE, Redhat, whatever. Yeah, sure, all those distributions have
> Linux as their primary targets. I have nevers seen anyone of them
> producing an office application, though.
I quoted Caldera especially because they *don't* produce a Linux
distribution. They use somebody else's distribution and add stuff that
they have (had) ported to Linux, such as WordPerfect etc. In my book,
this is `having Linux as a primary target' without just being yet another
distributor.
> The bottom line is: I am opposed to the "We are Linux, we don't need the
> rest of the world" statements that have been voiced in this group. It
> can never be wrong if something runs over many platforms.
Hear, hear.
Personally, I'd be inherently suspicious of anything calling itself
`Linux-something'. If it's not worth being made to run on any Unix, it's
not worth being done for Linux, IMHO. (This may exclude some things that
need to go far down into the kernel.)
Anselm
--
Anselm Lingnau ......................... lin...@tm.informatik.uni-frankfurt.de
If you think of C as a preprocessor for the PDP-11 assembler, it makes a
lot more sense. --- Reid Kneeland
G Sumner Hayes
o...@pell.chi.il.us (david parsons) writes:
> Linux isn't free from licenses. On any given distribution, you'll find
> licenses galore, from the GPV through the BSD license and all the way to
> the MIT license.
And Larry Wall's Artistic License, and the LGPV, and the VIM/Uganda
charityware license, and the Elvis Freeware License, and the Aladdin
Public License, and...
TTFN,
Sumner
Kristian Köhntopp
Anselm Lingnau <lin...@tm.informatik.uni-frankfurt.de> writes:
>Is it just me, or is anybody else wary of a philosophy that is implicitly
>tied to One True Language (be that Objective C, C++, Java, ...)?
Short Summary:
The point to make here is that GNUstep makes use of some
concepts that come easily with the "Objective" component of
Objective-C, but are very hard to implement in other langages.
GNUstep is not really dependent on C as a language. It is just
that GNUstep is dependent on some "Objective" features that are
not easily simulated in other, more restrictive languages.
Objective-C has some features that come in very handy when you
have to implement containers or widgets. On the other hand
these very concepts are seen as Evil [tm] by other schools of
OOP. It's SIMULA vs. Smalltalk people, again.
GNUstep _can_ be used with any OOP language, _if_ that language
can
- make method invocations variable at run-time.
- can derive classes from superclasses without recompilation of
the superclass and without needing the source of the
superclass.
- can ask any object of that class for its class name, the
names and types of all instance variables and the names and
signatures of all methods of this class and all its
superclasses at run-time.
Objective-C _can_ be used with C. It does not even need a
extern "C"-directive as C++ does.
The "Objective" component of "Objective-C" is completely
independent of its "C" component (in syntax as well as in
semantics) and can be applied to almost any other language. In
fact Nextsteps "Objective-C" compiler is in reality an
"Objective-C++" compiler, if you want it to be. There are
"Objective"-dialects of other languages, too. Among them are
regular programming languages such as COBOL, Fortran and other
and script languages such as perl and Tcl.
Longer explaination: Objective-C, like Smalltalk, binds methods
by name, not by pointer. In Objective-C a method call is in
essence a much more efficicent way of doing something roughly
like this
struct method {
char *name;
void *func;
};
method method_table_for_somefunc[] {
{ "doit", doit },
{ "another_method", another_method },
{ NULL, NULL }
}
send_message_to_func(char *msg, ...) {
int p;
for (p=0; method_table_for_somefunc[p].name; p++) {
if (strcmp(msg, method_table_for_somefunc[p].name) == 0)
break;
}
if (method_table_for_somefunc[p].name == NULL)
signal_error();
else
(*(clever_cast)method_table_for_somefunc[p].func)(self,...);
}
In reality the compiler generates a hash value from the method
name and the lookup name->address is done without looping. The
new keyword @selector("somestring") which is evaluated at
compile-time like sizeof() returns the hash-value of type SEL
for the given string.
This breaks typing at compile time, but Objective-C has other
ways of determining types and names at run-time. For those guys
from the we-want-to-prove-our-programs department this is bad
news and so they see Objective-C (and Smalltalk) as evil
things that can never work as exspected (Well, they do work and
they even scale...).
So in Objective-C you can send a fixed message to a single
object: [ myObject mymessage ]. In this example, the method
(member function) "mymessage" of "myObject" is called. This is
nothing spectacular.
You can also make the object variable, which is still common in
other languages:
id anObject;
int length, i;
length = [ myList count ]; // Determine the number of objects in my list
for (i=0; i<length; i++) {
// Determine the object at position i in the list
anObject = [ myList objectAt: i ];
// Call the method "mymessage" of this object
[ anObject mymessage ];
// shorter:
// [[ myList objectAt: i ] mymessage ];
}
But in Objective-C you can also make the method variable.
Objective-C objects understand the method [ someObject perform:
someSelector ] where someSelector is any selector, even a
variable of type SEL. So constructs like
SEL aSelector;
int length, i;
length = [ myList count ];
for (i=0; i<length; i++)
[[ myList objectAt: i ] perform: aSelector ];
are valid, useful and common in Objective-C. Similar things are
usually much harder in C++ and Java. You could even improve the
above iterator to
for (i=0; i<length; i++) {
anObject = [ myList objectAt: i ];
if ([anObject respondsTo: aSelector ])
[ anObject perform: aSelector ];
}
which only applies aSelector to those objects that actually
implement a method for this selector.
Now you could implement a class List or Array which stores
elements of type id (id is a shorthand notation for (Object *),
which is a pointer to an Object or any class derived from
Object) and you could implement a method "makeObjectsPerform:
(SEL) aSelector" in List, which is basically the loop shown
above.
This is a completely generic container class: It can store any
kind of objects. It can even be (horrors!) heterogenous and
store Windows, Buttons, Checkbooks and Stones in the same list.
This container class can apply any method to all of its
objects.
Note that this never involves any recompiling. List can be
compiled and stashed away in some library in 1988, the source
file can be lost (or not be sold to me). This List class can
still store objects I write today and can send them messages I
invented yesterday. I can derive classes from List without need
for Lists source. To some extent I can even abandon the header
file for List, because most of it can be reconstructed from the
runtime information stored within List.o. Obviously, #defines,
typedefs, enums and so on are lost, though, because they are C
and not Objective.
So why is this name-bindung business useful for something like
GNUstep, a GUI class library framework? Well, imagine some
Button class which implements an on-screen button that can be
pushed with a mouse. What method should be called when the
button is pressed and to which class does this method belong?
To be sufficiently general the button must be useable with any
application I might come up with in the future. Of course the
Button class should not be recompiled just because I wanted to
use it in some application of mine or because I want to
subclass it. So each instance of Button has two variables, one
called "target" of type id and one called "action" of type SEL.
And when you press that button,
if ([ target respondsTo: action ])
[ target perform: action ];
This button is general and can be used anywhere withour source
and recompilation. Yeah, and a more complex view which is made
up from many Buttons, ScrollViews is put on screen with
[[ myView elementList ] makeObjectsPerform: @selector(display) ];
Now think of an interface builder program that has some palette
of builtin GUI element classes such as Buttons, ScrollViews,
TextFields and so on. This IB should be useful with YOUR
selfmade GUI element classes as well without recompiling and
relinking the entire IB. Fortunately you are using ELF and have
the ability to dynamically load additional code.
So you load and link your selfmade GUI elements into your IB.
But how can the IB program be sure that what it just loaded is
a proper and conforming GUI element? Well, it simply asks the
new Class or its objects with "respondsTo: (SEL) aSelector" if
they respond to the proper messages. There is additional
support for such tests in the Objective-C language that allows
one to define a protocol (a set of methods) and any object can
be asked if it conforms to that protocol with "conformsTo:".
This is almost the same as asking for the presence every method
of this protocol with "respondsTo:".
So you can have your 1988 commercial GUI builder for which you
have never seen source, have it load some 1993 GUI palette you
have bought from another independent vendor and use this to
interface with your 1996 selfmade program.
And, additional plus, you can have your IB test drive your
applications GUI by simulating the still unwritten classes of
your future application with some
no-operation-understand-anything Classes without the need to
compile anything. This allows you to play around with
application interfaces without having any application specific
code, yet.
Note that those parts of your application that already have
code ARE working in this test drive simulation. So if you don't
write any code at all, but use only existent objects, you can
create proper applications within your IB without ever touching
a compiler. Yes, this is useful. I have done this and the
resulting application was performing useful and nontrivial
tasks (Implementing a simple Master-Detail-View into a database
by joining several tables, sorting this tables by varying
criteria and printing the result to some postscript printer.
The application featured Nextstep AppKit objects for the GUI
and Nextstep DBKit objects for the database and no selfmade
code. I sold it.).
What is the price of all this?
Performance Price:
Well, they say that C++ virtual function calls are factor two
slower than C function calls and that Objective-C messages are
factor six slower that C function calls, so Objective-C method
invocations are three times as slow as C++ method function
invocations. Note that this is ONLY for method invocations. All
plain statements are equally fast in all three languages - a
simple for(i=0; i<100000; i++) is equally fast in all three
languages. Objective-C programs are NOT three times as slow as
C++ programs.
Note that you need not pay the price for Objective-C method
invocation if you don't want to: You can ask any Object for its
method function pointers and call them repeatedly directly,
which is just as fast as in C.
Note that this is seldom necessary, too. My machine is a
Nextstation 68040 @ 25 MHz and its entire operating systems
down to vital parts of the device drivers is written in
Objective-C with all on-screen drawing going through a
Postscript interpreter. While this machine is not the fastest
thing in the world, it is fast enough for all daily tasks. I
never needed to resort to function pointers in my whole
Nextstep existence.
Compiler Price:
It is possible to construct method invocations in Objective-C
that generate runtime errors and that cannot be detected
automatically by the compiler. Thus, Objective-C is not
statically type-safe.
Note that this does not mean that Objective-C is untyped. Each
Objective-C object has exactly one exactly determined type and
you can ask this object for its type at any time. You need not
do that, though, and so it is theoretically possible for you to
construct programs that break.
In practice that does not turn out to be a problem. Large and
very large projects have been done in Objective-C and without
pain. Objective-C and Nextstep are targetted for and used for
mission critical applications, mainly in the banking and
insurance business and they perform well.
Kristian
--
Kristian Koehntopp, Wassilystrasse 30, 24113 Kiel, +49 431 688897
"Aeh, habe ich jetzt jemanden gespoilt, weil ich geschrieben habe das die
3.Staffel ein Ende hat?" -- Anja Ahlfeld, de.rec.sf.babylon5
Ray Auchterlounie
Kenneth Michael Apa <xk...@uxa.ecn.bgu.edu> wrote:
>I think the whole KDE idea is worth three thumbs-up. I think we should
>ask ourselves some questions before we get cracking.
>1) There is going to be the whole C vs. C++ vs. Objective-C war.
>Everyone has their own idea of what the greatest language on earth is.
Erm, haven't you forgotten one... :)
[ maybe if we keep the war real quiet the J*** advocates will stay in
the Emacs groups talking about rewriting that... ]
ray
--
Ray Auchterlounie <r...@kythera.demon.co.uk>
"Forty Two! Is that all you've got to show for
seven and a half million years' work?"
Joe Smulowicz
Matthias Ettrich (ett...@ti-ibm03.informatik.uni-tuebingen.de) wrote:
| -------------------------------------------
| New Project: Kool Desktop Environment (KDE)
| -------------------------------------------
| Programmers wanted!
|----------
|Unix popularity grows thanks to the free variants, mostly Linux. But still a
|consistant, nice looking free desktop-environment is missing. There are
|several nice either free or low-priced applications available, so that
|Linux/X11 would almost fit everybody needs if we could offer a real GUI.
I gave OS/2 the boot and abhor MS WIN* in part because of their growing (and
almost now total) reliance on a GUI interface.
I run HPUX here at work, and NEVER make use of the GUI features other than
having an occasional icon on the desktop to start a common application.
The day Linux requires a GUI as its main interface will be the day I abandon
it as well.
Early man started with simple cave drawings and after thousands of years
evolved to a rich and powerful interface known as words. Now everyone wants
to return to our primitive past. I guess history DOES repeat itself.
------------------------------------------------------------------------------
Joe Smulowicz Hewlett-Packard Tel: 508-659-3760
jo...@an.hp.com Mailstop 450, 3000 Minuteman Road Fax: 508-685-3577
Andover, Massachusetts 01810
PGP fingerprint: 50 EA 8B 22 A0 59 60 D5 DD 4B 04 04 12 26 2E 16
------------------------------------------------------------------------------
Nathan Denny
Frederick (Rick) A Niles wrote:
>
> Just to give my opinion...
>
> If it's not GPL ... I'm againist it!
>
> Your going to run in to the same hassles as with
> Motif eventually. Just use lesstif or write your
> own widget library.
>
> one wants to run Linux without it. However, you're
> still tied to a proprietary solution and your can't
>
> I think that's a bad place to be and would only
> total free from licenses.
>
> It's quite un-GNU...
>
> --
> Rick Niles.
Here's a good point. Qt may be free, as in no cost, but it doesn't
quite fit the ideal GNU sense of freedom.
Nate:SCHCATS!
Markus Gutschke
Ralph Schleicher <r...@purple.ul.bawue.de> writes:
> Emacs, man! Emacs! :-)
>
> ME> - Panel:
> There are still some keys unbound!
> ME> - Filemanager
> Dired.
> ME> - mail client
> Gnus, you can also read News with it!
> ME> - easy texteditor
> Hell yeah!
> ME> - Terminal
> Shell mode.
> ME> - Image viewer
> Say `! display RET' in Dired.
(defun display-image-in-buffer (file)
"Puts the image contained in the file in the current buffer"
(interactive "f")
(let ((IT (make-glyph-internal))) ;; IT, a la Stephen King
(set-glyph-property IT 'image file) ;; not as in ITaly
(make-annotation IT nil 'text)))
> ME> - Hypertext Help System
> Texinfo.
M-x all-hail-xemacs
I have to admit, though, that XEmacs is not neccessarily the perfect
solution for *all* GUI problems. Something along the lines of a free
CDE implementation would probably help Linux in becoming more widely
accepted.
Markus
Julian Regel
mar...@onyx.dirnet.com (Martin Spott) wrote:
>I wouldn't like to see just another desktop development.
>Linux gains popularity and respect by going conform to already existing
>(open) standards. Why don't you/we call for support of the GnuStep project
>if you/we don't like commercial desktops ?
I'd second that!
>This is a project to implement a desktop which is based on an open standard,
>not bound to commercial Motif, possibly a little bit huge but very
>functional and it goes the object oriented way, which will be a very
>important criteria already in the near future.
>There already exist implementations on NeXT and Solaris/Sparc.
>See www.gnustep.org (Nort America) or
>www.nmr.embl-heidelberg.de (Europe)
The computer industry seem unanimous in the opinion that the NeXTstep
GUI is very well designed and is light years ahead of other unix
interfaces. The Gnustep project will create a platform where
everything is laid down, even the size of icons (if I read it
correctly). Also, and perhaps more importantly, it will provide the
development tools to create the user apps.
The Motif/CDE might well become the commercial standard but it's
possible that a free unix standard based around Gnustep could take
off. As it stands at the moment, NeXTstep has a better GUI than the
CDE (IMHO, naturally). The KDE sounds good but it would be sad to see
so much time and effort being put into a project that is already up
and running.
Jules
Byron A Jeff
In article <3267BC...@cs.siu.edu>,
Nathan Denny <sch...@cs.siu.edu> wrote:
>Frederick (Rick) A Niles wrote:
>>
>> Just to give my opinion...
>>
>> If it's not GPL ... I'm againist it!
>>
>
>quite fit the ideal GNU sense of freedom.
Everybody in this thread should pick up a copy of the November 1996 Linux
Journal and read the Qt article written by one of the Co-founders of Troll
Tech. Their gist is simple:
* They Like X11/Linux. In fact they develop Qt on it and port it to other
platforms from there.
* They promote freeware for the X11/Linux platform.
* They want to make money (don't we all? ;-)
So the upshot is that Qt is freely distributable with source code for X11/Unix
based platforms, and commercial gotta pay for others (especially M$).
For Linux/FreeBSD the license is equivalent to GNU's. And it seems to me that
the only reason one of us would port an app to M$ Windows is for the sole
purpose of making money. So Troll Tech should get a cut.
I'm satisfied with Troll Tech position and plan to write a test app or three
in Qt now that I have a article with some cookbook examples.
You don't have to pay to get Qt on your Linux box. You get the source code. You
have to pay for Motif. You don't get the source code for it (unless you pay
the huge bucks...). Troll Tech looks like a GNU outfit, and talks like a GNU
outfit (on Unix platforms). So why should we not treat them like a GNU outfit
and use their stuff?
BAJ
--
Another random extraction from the mental bit stream of...
Byron A. Jeff - PhD student operating in parallel - And Using Linux!
Georgia Tech, Atlanta GA 30332 Internet: by...@cc.gatech.edu
Matt McLeod
On 18 Oct 1996 17:14:09 GMT, Joe Smulowicz <jo...@an.hp.com> wrote:
>I gave OS/2 the boot and abhor MS WIN* in part because of their growing (and
>almost now total) reliance on a GUI interface.
>
>I run HPUX here at work, and NEVER make use of the GUI features other than
>having an occasional icon on the desktop to start a common application.
>
>The day Linux requires a GUI as its main interface will be the day I abandon
>it as well.
No-one is talking about making Linux require a GUI - rather, providing an
option for those who want one. Preferably an option which fits in nicely
with the existing CLI stuff.
IOW - you don't like GUI's, and you don't want to use one. Bully for you.
Others do like them. This isn't an either-or situation.
This project has the potential to make Linux a win-win platform for GUI/CLI.
--
Matt McLeod "Bill spent his whole time trying to be
System Administrator argumentative and not trying to come up
Hunter Network Association with solutions." [Ed Roberts on Bill Gates]
Freedom Software Support
Matthias Ettrich (ett...@ti-ibm03.informatik.uni-tuebingen.de) wrote:
> -------------------------------------------
> New Project: Kool Desktop Environment (KDE)
> -------------------------------------------
>
> Programmers wanted!
Freedom Software would be willing to contribute with
the source code of Freedom Desktop Light for this effort.
Please don't subestimate the task of building a
desktop manager. Several Years have been spent building
Freedom Desktop. We could also contribute with
other pieces of technology (i.e Freedom Rt - Object oriented
toolkit). For more information about Freedom Desktop,
please visit http://www.fsw.com
Freedom Software is about to announce a free version
of the software for Linux (personal use only). This version
is called Freedom Desktop Light for Linux.
If I were you, I wouldn't restrict the project to a specific
toolkit (at least for now). There are many pieces of public
software that can be reused easily. It could take a long
time to rebuild everything from scratch. Try to reuse
the more you can now. You can standarize on a single
toolkit later.
Also keep in mind that Motif is the defacto standard.
Most Unix platform ship with Motif. It would be nice
if your desktop work on all the versions of Unix
Edgar Galvis
Freedom Software
http://www.fsw.com/motif.html - Home of Freedom Desktop for Motif
sup...@freedom.lm.com
Ralf W. Stephan
Anselm Lingnau writes:
> Is it just me, or is anybody else wary of a philosophy that is implicitly
> tied to One True Language (be that Objective C, C++, Java, ...)?
You're not alone there. OTOH, with a reasonably reusable design
in your app, being written in an OOP language (be it C++/ObjC/Java),
you could easily interface with many GUIs. I keep telling this until
I'm mad, I believe.
The key is writing reusable soft (not one tied to a specific interface)
and porting it to the yet-another-new-and-fancy GUI which has the
most audience/support now. Oh well then, why not unite on just
*this* project: build a C++ framework for general Linux apps with
interfaces to Tk/Motif/Qt/GNUstep/your favourite GUI.
Bored,
ralf
--
Lynx-enhanced pages at http://www.bayreuth-online.de/~stephan
Uli Kaage
In article <ufzq1of...@alfa.purple.UL.BaWue.DE>,
Ralph Schleicher <r...@purple.ul.bawue.de> wrote:
>Matthias Ettrich <ett...@ti-ibm03.informatik.uni-tuebingen.de> cited
>below with "ME" writes:
>
>ME> IMHO a GUI should offer a complete, graphical environment. It should
>ME> allow a users to do his everyday tasks with it, like starting
>ME> applications, reading mail, configuring his desktop, editing some
>ME> files, delete some files, look at some pictures, etc. All parts
>ME> must fit together and work together.
>
>Emacs, man! Emacs! :-)
>
>ME> - Panel:
>There are still some keys unbound!
>ME> - Filemanager
>Dired.
>ME> - mail client
>Gnus, you can also read News with it!
>ME> - easy texteditor
>Hell yeah!
>ME> - Terminal
>Shell mode.
>ME> - Image viewer
>Say `! display RET' in Dired.
>Texinfo.
>
>Ralph * http://www.UL.BaWue.DE/~rs/
>
>GNU -- vivat, crescat, floreat!
Matthias pointed out that he wants to create an
End-User-GUI. Although emacs is a very complex and
powerful editor, it's not easy to use for so called
End-Users. And it's not that what an End-User expects
as a GUI.
BTW, why call it KDE when it could be called LDE
(Linux Desktop Environment ?) ;-)
Uli
--
Uli Kaage - u...@anna.sub.de
Edwin Huffstutler
[ Uli Kaage wrote: ]
(... agree with the emacs comments - it *IS* the answer to everything, but
not for the newbie...)
> BTW, why call it KDE when it could be called LDE
> (Linux Desktop Environment ?) ;-)
Because whatever these KDE people come up with would (should) be runnable
on any Unix system without too much trouble... be it Linux, FreeBSD, or
some commercial OS. Branding it "linux-only" would make it a less
attractive alternative and restrict the possibilites for world
domination (or whatever their goals are :).
--
Edwin Huffstutler http://www.primenet.com/~edwinh/
edw...@primenet.com Linux - because reboots are for hardware changes
eh...@sedona.intel.com SPG Logic Engineering, Intel Corp.
david parsons
In article <54e3dh$j...@nnrp1.news.primenet.com>,
Edwin Huffstutler <edw...@primenet.com> wrote:
>[ Uli Kaage wrote: ]
>
>(... agree with the emacs comments - it *IS* the answer to everything, but
>not for the newbie...)
>
>> BTW, why call it KDE when it could be called LDE
>> (Linux Desktop Environment ?) ;-)
>
>Because whatever these KDE people come up with would (should) be runnable
>on any Unix system without too much trouble... be it Linux, FreeBSD, or
>some commercial OS.
And if it's based on Qt you should be able to move large chunks of it over
to the million tonne elephant that's parked outside the front door. This
is good; once you've got similar UIs on the, ahem, excellent operating
systems from the PC world, it will be easier to wean them over to Unix.
Karsten Weiss
In de.comp.os.linux.misc Julian Regel wrote:
JR> The computer industry seem unanimous in the opinion that the NeXTstep
JR> GUI is very well designed and is light years ahead of other unix
JR> interfaces. The Gnustep project will create a platform where
JR> everything is laid down, even the size of icons (if I read it
JR> correctly). Also, and perhaps more importantly, it will provide the
JR> development tools to create the user apps.
BTW: Is there a www page where I can't check out the look of a
GNUstep application? The GNUstep homepage contains much information
but not a single picture of an application.
--
Karsten Weiss
-
UUCP: kar...@addx.au.s.shuttle.de FIDONET: 2:246/1416.37
STUDBOX: knw...@studbox.uni-stuttgart.de GERNET: 21:492/1616.37
INTERNET: knw...@trick.informatik.uni-stuttgart.de >ASK FOR PGP KEY<
Sascha Ziemann
Matthias Ettrich wrote:
> : : New Project: Kool Desktop Environment (KDE)
> I'm not talking about yet-another window manager. I'm talking about
> an Qt-based environment similar to the CDE. Qt yet doesn't have
> a drag-and-drop API. I'm not sure when it will come. But of course
> this would be a nice project. Join and do that API!
> (as a sideeffect and for testing purpose maybe also the filemanager
> comes out...)
Of course the 20.000th filemanager! Why not wasting time with things
that already exist.
A GUI is an absolut personal decision. I take what I think it is nixe
and usefull. I expect you writing a "Kool" program so far you think that
it is "Kool". But THAT is the problem! A really great GUI does not force
the user to use a special look an feel! But all existing GUIs do this.
And your project will create the next one!
A really great GUI does not define weather a button is rectangular or
round!
It must be possible to change the outfit of the GUI like the colors of
the desktop. If you want to write something great, write that!
Beside that the process of creating a program and using a program must
be the same! A GUI-program should be an example of how this program
could look like and the user has to be able to change the outfit at all.
It must be possible to move the buttons to other places in a dialog-box.
It must be possible the create new different dialog-boxes with the
dialog-elements from the existing. It must be possible to join
dialog-boxes and frames in the way the user likes it. If you want to
write something great, write that!
-- bis später...
- Sascha ---<~>=( http://www.ping.de/sites/aibon/ )=<~>---
() Free speech online
/\ http://www.eff.org/BlueRibbon/bluehtml.html
Johann Hibschman
In article <54g2dm$1...@halon.vggas.com>,
James Youngman <JYou...@vggas.com> wrote:
>
>And ka11ing 1t Koo1 is 1ess of a turn-0ff?
AAH! Don't *do* that. <shudder>
l8r,
- jOhAnN
--
Johann Hibschman
joh...@physics.berkeley.edu
Arnt Gulbrandsen
ra...@ark.franken.de (Ralf W. Stephan)
> You're not alone there. OTOH, with a reasonably reusable design
> in your app, being written in an OOP language (be it C++/ObjC/Java),
> you could easily interface with many GUIs. I keep telling this until
> I'm mad, I believe.
Seems reasonable on the face of it, but the only program I know about
which uses this technique AND WORKS is emacs. Since emacs is hardly
an example of brilliant OO/GUI design, I tend to be skeptical of the
whole idea.
--Arnt
Uli Kaage
In article <54e3dh$j...@nnrp1.news.primenet.com>,
Edwin Huffstutler <edw...@primenet.com> wrote:
>[ Uli Kaage wrote: ]
>> (Linux Desktop Environment ?) ;-)
>
>Because whatever these KDE people come up with would (should) be runnable
>on any Unix system without too much trouble... be it Linux, FreeBSD, or
>attractive alternative and restrict the possibilites for world
>domination (or whatever their goals are :).
>
>--
> Edwin Huffstutler http://www.primenet.com/~edwinh/
> edw...@primenet.com Linux - because reboots are for hardware changes
> eh...@sedona.intel.com SPG Logic Engineering, Intel Corp.
>
Calling it LDE would not constitute a restriction to the rest
of the Un*x world. Especially since Linux is a kind of Un*x.
This name only states that it's a desktop-environment from a
Linux-Box where its development first started.
I think, if it becomes a good GUI no one would care about its origin.
If it's usefull it will be used.
But please don't take that LDE-suggestion that serious ... 8-)))
Ralph Schleicher
"Markus Gutschke" <gut...@uni-muenster.de> cited below with "MG"
writes:
ME> - Image viewer
>> Say `! display RET' in Dired.
MG> (defun display-image-in-buffer (file)
MG> "Puts the image contained in the file in the current buffer"
MG> (interactive "f")
MG> (let ((IT (make-glyph-internal))) ;; IT, a la Stephen King
MG> (set-glyph-property IT 'image file) ;; not as in ITaly
MG> (make-annotation IT nil 'text)))
And for all those young, hep kids who only know about `click and pray'
instead of learning the proper way doing things:
(defun mouse-display-image-in-buffer (event)
"Puts the image you click on in the current buffer."
(interactive "e")
(let (file)
(save-excursion
(set-buffer (window-buffer (posn-window (event-end event))))
(save-excursion
(goto-char (posn-point (event-end event)))
(setq file (dired-get-filename))))
(select-window (posn-window (event-end event)))
(display-image-in-buffer file)))
The thread is about GUIs, isn't it? ;-)
Michael Dillon
In article <326322...@erols.com>, Greg Howland <g...@erols.com> wrote:
>This sounds very similar to the Afterstep project.
>Have you considered working with them?
Actually it sounds very similar to the GUI portion of the Berlin project.
Have you considered working with them?
http://veda.synet.net/numan/berlin/ is the URL for more info
--
Michael Dillon - ISP & Internet Consulting
Memra Software Inc. - Fax: +1-604-546-3049
http://www.memra.com - E-mail: mic...@memra.com
Jerol DeMars
Chris Waters wrote:
>
> No, it's not! If you like the idea and want to succeed quickly, then
> it's in your best interests to claim that other projects are irrelevant,
> of course. Contrariwise, if you think that standards are a good thing
> (and have a lot to do with why Linux has been so successful), then you
> may want to remind people of this fact before they go running off
> dumping a lot of time and energy into a project like this; time that
> they might well have preferred to invest in creating something more
> standard if only they had realized that that was an option.
>
There is already a standards group being formed called the Free software
union. They are trying to come up with standards for a gui and
application
programming interface. Right now there has been talk of using gnustep
and corba, but nothing final yet. They are deciding the board of
members at this time. They have a lot of progress in the works and are
trying to raise as many members as possible. Every member has the right
to vote for the up and coming standards for linux and free software.
Give them a look. They are at http://www.jagunet.com/~braddock/fslu/org
They also have a mailing list with you can subscribe to from the home
page.
On a different note there is also another gui design project for linux
in the works that is starting from scratch like this kool desktop
enviroment. It is called the linux interface project (LIP). They want
to make a radically new designed gui for linux on a new widget set that
they are writing. They
are also in the design stage but have started writing some sample code.
Give them a look. They are at http://blank.pages.de/lip/
Take a look at both these pages. They may help some of the redundacy
before the KDE starts.
Jerol DeMars
je...@gencomp.com
James Youngman
In article <54e3dh$j...@nnrp1.news.primenet.com>, edw...@primenet.com says...
>
>[ Uli Kaage wrote: ]
>
>(... agree with the emacs comments - it *IS* the answer to everything, but
>not for the newbie...)
>
>> (Linux Desktop Environment ?) ;-)
>
>Because whatever these KDE people come up with would (should) be runnable
>on any Unix system without too much trouble... be it Linux, FreeBSD, or
>some commercial OS. Branding it "linux-only" would make it a less
>attractive alternative and restrict the possibilites for world
>domination (or whatever their goals are :).
And ka11ing 1t Koo1 is 1ess of a turn-0ff?
--
James Youngman VG Gas Analysis Systems |The trouble with the rat-race
Before sending advertising material, read |is, even if you win, you're
http://www.law.cornell.edu/uscode/47/227.html|still a rat.
James Youngman
In article <54gag8$p...@agate.berkeley.edu>, joh...@physics20.berkeley.edu
says...
Just the effect I was looking for! Seeing the phrase "Kool Desktop
Environment" sends a shiver down my spine.
Sascha Ziemann
Steve Dunham wrote:
> > The Gimp, in new versions, doesn't require Motif; it uses a free
> > Motif-appearance toolkit written over Xlib only for speed.
>
> > I think it's only available to developers, but they say it works
> > really well and will be the basis of the next release of the Gimp.
>
> There is a copy somewhere on the web site. I like the new widgets,
> they look as good as Motif, if not better. The toolkit is called
> "gtk", but shouldn't be confused with the "gtk" being created by the
> Mosaic developers.
Is it Tk based on Guile?
Asger K. Alstrup Nielsen
JYou...@vggas.com (James Youngman) writes:
>Just the effect I was looking for! Seeing the phrase "Kool Desktop
>Environment" sends a shiver down my spine.
Matthias only used that as a working title. If you can come up with
something better, he's very open for suggestions. It would be a shame
if people were turned off only by the name.
Greets,
Asger Alstrup
Peter Dalgaard BSA
I don't know, given that the CDE acronym was taken, I thought that KDE
was KindaKute (TM)...
--
O__ ---- Peter Dalgaard Blegdamsvej 3
c/ /'_ --- Dept. of Biostatistics 2200 Cph. N
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~~~~~~~~~ - (p.dal...@biostat.ku.dk) FAX: (+45) 35327907
Uli Kaage
In article <3269E4E0...@aibon.ping.de>,
Sascha Ziemann <s...@aibon.ping.de> wrote:
>Beside that the process of creating a program and using a program must
>be the same! A GUI-program should be an example of how this program
>could look like and the user has to be able to change the outfit at all.
>It must be possible to move the buttons to other places in a dialog-box.
>It must be possible the create new different dialog-boxes with the
>dialog-elements from the existing. It must be possible to join
>dialog-boxes and frames in the way the user likes it. If you want to
>write something great, write that!
>
In my opinion this would turn back the wheel. Why do you need to
change the appearance of a program? The user interface is designed to
reflect the internal state of the program. If the user interface is
designed adequate, there's no need to add more an more stuff or to
change the layout of it's widgets. You can't improve the functionality
of such a program by doing things like that.
There were times, when nearly every little software-firm had their own
view of GUIs. Some thought the style of a button would be great for
headlines. Others implemented text-fields as labels. Diversity is not
always the best. That's the good thing with Windows or MACs GUI: If
you are familiar to the outfit of one program, it's easy to use all
others.
So, a generalized GUI makes life a lot easier and let's you focus on
the really important part of using a program: Make the program what
you want, not make it look like you want.
bis sp"atestens ... Uli
John Stevens
In article <543e49$s...@news.ecn.bgu.edu>,
Kenneth Michael Apa <xk...@uxa.ecn.bgu.edu> wrote:
>I think the whole KDE idea is worth three thumbs-up. I think we should
>ask ourselves some questions before we get cracking.
>
>1) There is going to be the whole C vs. C++ vs. Objective-C war.
>Everyone has their own idea of what the greatest language on earth is.
>I think if your going to use Objective-C you should support GNUstep and
>help out there as much as you can. It would be really unproductive to
>duplicate with they are already doing. C has had it far share of
>toolkits. I agree with the original poster that we should use C++, but
>perhaps we should vote on it.
Step #1. Build a GPL (I repeat, *GPL*) widget library, possibly based
on Xt, possibly based on pure Xlib, using an OO language (my vote
is for C++, it has a much wider audience and acceptance than
Objective C).
>2) I think we should kiss everyones standards goodbye. We're linux users,
>right??? We can do things better and faster anyways. CDE = Motif part2.
>Besides, CDE was outdated before the first alpha versions were in testing.
>Lets let HP have CDE, SGI have OpenGL, Sun have Openlook(I know everyone
>agrees with that one). Linux should have it's own standards and APIs for
>just about everything, because Linux is better than the commercial Unices.
I think that kissing all standards goodbye would be frightfully self
destructive. At the very least:
Step #2. Identify standards (or parts of existing standards) to be used.
Fill in what is missing (and, in good OOD style, reiterate step #1
as needed).
>3) QT is real cool, but it's huge. They've got classes for everything.
>Don't get me wrong. I think QT one of the best development tools I've
>ever seen, but we could improve upon it. A smaller toolkit with a GUI
>builder would be great. Let's keep the learning curve low. QT is just
>too huge.
And is commercial. Forget Qt. I repeat, a commercial product should
be absolutely taboo for this project. I appreciate the attitude of the
company, but the strength of the Linux system is that it is based on
*FREE* software (and I mean, free, as in free to be fixed, debugged,
upgraded or modified by any competent Linux programmer). Qt's license
is such that Troll Tech (rightfully so, of course) retains control over
the source: it cannot be modified to fit the needs of the project.
>4) Let's take the best from each UI and make it better. An example might
>be something like: NextMail, Iris Insight(online help), Mac
>Scrapbook(said before), Windows95 style filemanager with a SGI style
>IconCatalog, and some killer Icons(ray-traced in BMRT/real photos).
Cool. So long as the programs are modified to fit the projected "Linux
standard GUI". If you don't establish a standard GUI design and
philosophy (ala the Mac), you *WILL* end up right back where you started,
with exactly the same problems as you have now.
>5) Everthing organized on a website so people can see what projects are
>underway.
Sounds good to me.
>What does everyone think? I say let's kick some ass!
I have written some C++ classes based on pure Xlib. Xt is nice, but
in my opinion, it provides a lot of overhead, with little benefit for this
project. Resource files are out. Just *TRY* explaining resource files to
somebody. Even programmers get heart burn trying to figure it out. . .
If we can succesfully complete steps 1 and 2, then this project may be
feasible. If not, we still have generated useful results that will
be of benefit to the Linux/Free Unix community.
John S.
P.S. No insult intended to the creators of Xt, of course. Good idea,
solidly built, but by the time you get Motif Tools (Xmt, which I use
a lot) running on Motif, running on Xt, running on X, it gets a little
much.
I am not adamant about getting away from Xt, but it seems like an idea
worth investigating, especially since Xt could be done so much better
using C++.
G Sumner Hayes
Peter Dalgaard BSA <p...@bush.kubism.ku.dk> writes:
>
> I don't know, given that the CDE acronym was taken, I thought that KDE
> was KindaKute (TM)...
>
The Kommon Desktop Environment? I'd prefer something that didn't
contain any spelling errers, persunally...
Cordially,
Sumner
Please don't e-mail postings to me, my mailbox is already full enough.
John Stevens
In article <543pfq$m...@charm.magnus.acs.ohio-state.edu>,
Brian H Cooper <coo...@concord.eng.ohio-state.edu> wrote:
>
> For those who don't like Qt, want everyone to buy Motif, think GNUstep
>is going to be dandy, or want the Linux to subscribe to some other
>commercial standard - Great! but take it elsewhere. There's absolutely
>no point in trying to stop someone from offering another choice for
>free. Don't like? Don't download it. Big deal. Put this subject
>in yer kill file.
I disagree. This thread is about KDE, not a Qt sales pitch. I don't like
Qt (for reasons described in another post), but the project interests
me.
> For those who think this is a pretty good idea, there seems to be a
>consensus that Qt is done The Right Way and we like Troll Tech.
Consensus? Not as far as I have read. You seem to be implying that
the decision to use Qt has already been made. If so, fine, but
I don't see that as a given, yet.
>As for "Who has the ability, time and vision to really pull it off?"
>I would hope that Matthias, being the original poster, would step
>in and assume this role publicly, and it probably won't take another
>Linus.
Whatever. I suspect that there are lots of people who could/would work
on this. But for the project to be sucessful, we need to write and
commit to a GUI "standard", decide on what problem we are trying to solve
(is this really an end user system?), etc.
>Here are a couple points I think ought to be considered:
>1) This is another CHOICE. The developers may think it blows everything
>else away but let's not get confused and think we have to fight anybody
>over it. In the lab where I am, they just threw on CDE, and if
>you don't like it, tough. I thought that was pretty rude. The argument
>of "well why didn't the original poster just look at some existing
>standard or support GNUstep etc" is IRRELEVANT.
No, it is not. Until it is decided what problem we are trying to solve,
it is pointless to continue. After review, we may very well discover
that the problem we are trying to sovle has already been solved, or
that our efforts would be better spent supporting an existing product
development team.
>2) There have been some comments about icon this and that and extreme
>graphics. That's nice but not everyone wants that garbage/can handle
>the load. Development will naturally drift toward a "look-and-feel"
>but design ought to consider _from_the_beginning_ having every aspect
>user configurable.
Absolutely not. The whole point of the original post (Mathias?) was to
create an *END-USER* system. If you want total configurability, then
why switch away from what already exists?
>I want a choice.
Then stick with what already exists. This project has no real point
unless it starts with the clear understanding that we are trying to
create a system that expresses a well thought out, carefully defined
user interface philosophy (ala the Mac).
Note that this does not totally rule out configurability, it allows
for things to be configured that do not affect the "correctness" of
the program.
>3) Matthias in his original posting noted specifically that this is
>for ENDUSERS. I don't tend to view my machine that way, so a lot
>of that doesn't appeal to me and I tend to abuse it installing
>all sorts of mishmash stuff to see what I like, but I'd like the
>rest of my family to be able to use it without asking me questions.
So for your families sake, this should be an END-USER interface, and
not be something targeted for people like you and me.
I don't use the Mac 'cause I don't like those super-slick, super-steep
walls. . . But that kind of philosophy is eminently valid for appliance
style computing.
John S.
david parsons
In article <54ito3$d...@anna.sub.de>, Uli Kaage <u...@anna.sub.de> wrote:
>In article <3269E4E0...@aibon.ping.de>,
>Sascha Ziemann <s...@aibon.ping.de> wrote:
>>Beside that the process of creating a program and using a program must
>>be the same! A GUI-program should be an example of how this program
>>could look like and the user has to be able to change the outfit at all.
>>It must be possible to move the buttons to other places in a dialog-box.
>>It must be possible the create new different dialog-boxes with the
>>dialog-elements from the existing. It must be possible to join
>>dialog-boxes and frames in the way the user likes it. If you want to
>>write something great, write that!
>In my opinion this would turn back the wheel. Why do you need to
>change the appearance of a program?
You don't, but the user might. That's why you set up preferences
and let the user play around until they're happy with the way their
UI looks. And if you build this sort of configurability in, you
don't need to worry about supporting a program that's been hacked
into bloody gobbets by someone customising their code.
(What I left unsaid is that preferences need to function across ALL
of the applications that talk to your UI; if the user makes buttons
look like hot dogs, then _every_ button should look like a hot dog,
not just the buttons in the app that they just called up preferences
in.)
David L. Johnson
david parsons wrote:
> >In my opinion this would turn back the wheel. Why do you need to
> >change the appearance of a program?
>
> You don't, but the user might. That's why you set up preferences
> and let the user play around until they're happy with the way their
> UI looks. And if you build this sort of configurability in, you
> don't need to worry about supporting a program that's been hacked
> into bloody gobbets by someone customising their code.
>
> (What I left unsaid is that preferences need to function across ALL
> of the applications that talk to your UI; if the user makes buttons
> look like hot dogs, then _every_ button should look like a hot dog,
> not just the buttons in the app that they just called up preferences
> in.)
I disagree. The user (or the guru who is handsomely paid to configure
the machine for the user 8^)) should be able to decide independently
which apps have hot-dog buttons.
When I (finally) convinced my wife that fighting with WP-5.1 was no
longer worth the effort, that she could get better font support using
WP-6.1 and Winders-3.1, she insisted that the background be blue, since
that was what she was used to. I had no choice but to make all the
active windows have a blue background -- she didn't mind, but I thought
it looked ugly. It should have been possible to set WP's background to
blue, and leave the others alone. Same thing here.
--
David L. Johnson dl...@lehigh.edu, dl...@netaxs.com
Department of Mathematics http://www.lehigh.edu/~dlj0/dlj0.html
Lehigh University
14 E. Packer Avenue (610) 758-3759
Bethlehem, PA 18015-3174
Wolfram Gloger
jste...@bamboo.verinet.com (John Stevens) wrote:
> Step #1. Build a GPL (I repeat, *GPL*) widget library, possibly based
> on Xt, possibly based on pure Xlib, using an OO language (my vote
> is for C++, it has a much wider audience and acceptance than
> Objective C).
This has been _done_ with C++. There is the Xt-port of wxWindows
(LGPLed), which still seems to be not very widely known, see
http://www.aiai.ed.ac.uk/~jacs/wxwin.html
ftp://ftp.comnets.rwth-aachen.de/pub/x/wxWindows/1.64b
While it is true that the main creator of wxWindows, Julian Smart, has
decided to cut time spent on the X version and concentrate on the MS
Windows version, the Xt port is actively maintained by Markus Holzem
(m...@comnets.rwth-aachen.de).
There is also the `V' C++ toolkit, see:
http://www.cs.unm.edu/~wampler
However, its API is about 3 years younger than wxWindows', and
therefore considerably less advanced IMHO.
[About Qt]
> And is commercial. Forget Qt. I repeat, a commercial product should
> be absolutely taboo for this project. I appreciate the attitude of the
> company, but the strength of the Linux system is that it is based on
> *FREE* software (and I mean, free, as in free to be fixed, debugged,
> upgraded or modified by any competent Linux programmer). Qt's license
> is such that Troll Tech (rightfully so, of course) retains control over
> the source: it cannot be modified to fit the needs of the project.
Very true. Another big downside is that it can't be used freely for
internal projects (again, this is no complaint against Troll Tech).
> I have written some C++ classes based on pure Xlib. Xt is nice, but
> in my opinion, it provides a lot of overhead, with little benefit for this
> project. Resource files are out. Just *TRY* explaining resource files to
> somebody. Even programmers get heart burn trying to figure it out. . .
I disagree here. Xt resources are one of the most powerful mechanisms
X11 provides. If they're too complicated for you, you don't _have_ to
specify resource files. You can use them very sparingly with great
efficiency, too.
> I am not adamant about getting away from Xt, but it seems like an idea
> worth investigating, especially since Xt could be done so much better
> using C++.
This is correct (the Xt creators didn't have C++ available
originally). If you (or anyone) can come up with a good, free C++
replacement for libXt that would be very worth while. Maybe a start
in that direction is also already available on the net ?
Regards,
Wolfram.
Uli Kaage
In article <326D8363...@lehigh.edu>,
>david parsons wrote:
>>>In my opinion this would turn back the wheel. Why do you need to
>>>change the appearance of a program?
>>
>> You don't, but the user might. That's why you set up preferences
>> and let the user play around until they're happy with the way their
>> UI looks. And if you build this sort of configurability in, you
>> don't need to worry about supporting a program that's been hacked
>> into bloody gobbets by someone customising their code.
>The user (or the guru who is handsomely paid to configure
>the machine for the user 8^)) should be able to decide independently
>which apps have hot-dog buttons.
>
>When I (finally) convinced my wife that fighting with WP-5.1 was no
>longer worth the effort, that she could get better font support using
>WP-6.1 and Winders-3.1, she insisted that the background be blue, since
>that was what she was used to. I had no choice but to make all the
>active windows have a blue background -- she didn't mind, but I thought
>it looked ugly. It should have been possible to set WP's background to
>blue, and leave the others alone. Same thing here.
>
Anyway, I keep my point of view: Perhaps we, the unix users, are used
to configure everything that comes along the desktop. This really
takes a lot of time, that is better spent on the more important tasks.
I'm not talking about hacked GUIs. The phrase *let the user **play**
around until they're happy with the way their UI looks* makes it all
clear.
You wouldn't go to a car seller and say: *I want a car with the
gas-pedal on the left and the tachometer in the luggage-boot*, wouldn't
you 8-) ? But on some things you are definitely right. Some little things
should be configurable by the user: colors, for example. Maybe,
color-blind people would need to change them. And that's another reason
for the usefulness of GUIs. If you need to change the color, it should
be take effect for every program that you use.
Maybe I'm going to far-off of this thread. I just wanted to make
clear, that a standardized GUI would be very useful for the end-users.
CU ... Uli
Arnt Gulbrandsen
jste...@bamboo.verinet.com (John Stevens)
> The obvious compromise is to build a resource file reader/parser/lint/writer
> tool, and simply do not tell anybody that the resource files still exist,
> though of course this allows for installation "problems".
>
> Questions, comments, complaints?
It takes real time to write configurable programs. Configuration is
not something you add in an evening after the program has been written
- you need to use variables where you'd otherwise use constants and
functions where you'd use variables, you need extra sanity checking
all of the place, and most of all, you need an (or several) extra
dialog(s) to set up the configuration options.
Besides, "make it configurable" is all too often a cop-out, an excuse
for bad defaults.
--Arnt
John Stevens
In article <u46842j...@md.dent.med.uni-muenchen.de>,
Wolfram Gloger <Wolfram...@dent.med.uni-muenchen.de> wrote:
>jste...@bamboo.verinet.com (John Stevens) wrote:
>
>> Step #1. Build a GPL (I repeat, *GPL*) widget library, possibly based
>> on Xt, possibly based on pure Xlib, using an OO language (my vote
>> is for C++, it has a much wider audience and acceptance than
>> Objective C).
>
>This has been _done_ with C++. There is the Xt-port of wxWindows
>(LGPLed), which still seems to be not very widely known, see
>
> http://www.aiai.ed.ac.uk/~jacs/wxwin.html
>
> ftp://ftp.comnets.rwth-aachen.de/pub/x/wxWindows/1.64b
Thanks for the pointers. I'll look it up.
>> I have written some C++ classes based on pure Xlib. Xt is nice, but
>> in my opinion, it provides a lot of overhead, with little benefit for this
>> project. Resource files are out. Just *TRY* explaining resource files to
>> somebody. Even programmers get heart burn trying to figure it out. . .
>
>I disagree here. Xt resources are one of the most powerful mechanisms
>X11 provides. If they're too complicated for you, you don't _have_ to
>specify resource files. You can use them very sparingly with great
>efficiency, too.
But the context of this discussion is the KDE prooject, and if I read
the original poster correctly, this would be an interface designed for
use by a person who uses a computer as an appliance.
Such people expect to see pop-up diaglogs when they wish to configure
their programs, they cannot, will not, be able to deal with resource
files.
The obvious compromise is to build a resource file reader/parser/lint/writer
tool, and simply do not tell anybody that the resource files still exist,
though of course this allows for installation "problems".
Questions, comments, complaints?
John S.
Grant Edwards
G Sumner Hayes (sum...@CMU.EDU) wrote:
: Peter Dalgaard BSA <p...@bush.kubism.ku.dk> writes:
: >
: > I don't know, given that the CDE acronym was taken, I thought that KDE
: > was KindaKute (TM)...
: >
: The Kommon Desktop Environment? I'd prefer something that didn't
: contain any spelling errers, persunally...
#if defined(PetPeeve)
Bravo!
When I see trademarks or product names with misspelled words, I figure there
are two possibilities:
1) The person who named the product/store/whatever just wasn't bright
enough to know that the word is spelled "Light" rather than "Lite" (or
Klassic vs. Classic). In that case I don't want to do business with
somebody that incompetent.
or
2) They think misspelling words is "cute". I don't want to do business with
anybody that nauseating.
If you want my business (or just my respect) don't use misspelled words in
the name of your store, service, or product.
I don't freak over the occasional typo in informal communications such as a
Usenet posting. But, when you're paying to have three words painted in a 2m
high font on the front of a building you should at least SPELL THEM CORRECTLY!
#endif
--
Grant Edwards | Microsoft isn't the | Yow! I had a lease on an
Rosemount Inc. | answer. Microsoft | OEDIPUS COMPLEX back in
| is the question, and | '81...
gra...@rosemount.com | the answer is no. |