On Thu, 21 Nov 1996 you wrote:
>These are the basic ideas. I would like to hear some opinions about that.
Well I am no expert on X-windows, but since you asked here is my two cents
worth.
>the current architecture is not adequate to use in an object-oriented design.
>So we decided to write the code of the new window manager from scratch.
Objects, sounds great ! If the wm is properly abstracted one could use it as
a model for other wm. But... what about the infamous C++ code bloat and
related performance issues ? Other GUI's which are object oriented seam to
suffer from such issues. N*xt for example, while Macrosoft's object OS has
been put on the back-burner and it is rumored that the only application MS
has written using object frameworks is w*rdpad. Personally I prefer object
methodologies has long as not to much performance is sacrificed.
>clients would have a way to determine some global settings, like color
sets, fonts, desktop size, etc.
>Changing these items in the wm would notify the applications about the new
setting, so they could automatically
>take the appropiate decissions.
>
>Color management implemented as a color server, possibly compatible with
the Motif one.
>
>Window style management implemented via X resource manager.
>
>Some kind of drag and drop support, Motif and/or OffiX compatible.
>
>Full (or as closest as possible) M*tif compliance.
Here is where things begin to get cloudy. There are differences between X
and win95, things such as frame buffers, messages and events methods, to
name a few. A good article relating to this can be found in the July/August
1994 issue of The X Journal. It's called Implementing the Windows API on
U*NIX/M*tif, and it describes the experiences from some one who worked on a
similar project, from the trenches point of view.
Perhaps the best approach is a compromise and use the best features of win95
and M*tif. As long as the user can run M*tif applications using this vm,
M*tif compliance may become a secondary issue.
Here are some features I would like to see:
-use of buffers to improve performance.
-use DLL's to implement controls (widgets) thus providing flexibility and
extendibility.
-create something akin to the registry, a policy database which can be
modified using a policy editor.
-A scripting language which could be used to write macros, such as MS VBA. A
good candidate would be Java.
-Some sort of printer support such as it is found in win95.
>A new class library for developing applications is being written, with
win95 look and feel, and including as
>many as controls (widgets) as Win95 has.
Will it include the new controls which MS uses in O*fice97 ?
What about an IDE for programmers ?
>A separate, generic wm-communication API library would be also available.
A scripting language which could be used to communicate with the vm. A good
candidate would be Java.
>There is not a fixed policy, or direction, in the fvwm development, except,
perhaps, making it infinitely configurable.
I agree that it should be infinitely configurable. However global
configuration which can be overwritten by the application should be the
standard.
If the above can be achieved then Linux, X95 vm, Xclass95 will provide the
functionality to compete head on with the evil Macrosoft empire, at a
fraction of the cost.
On a final note, has any consideration being given to legal issues such as
copyright and patent infringement ?
If company has the resources to engage in a legal battle with a US
government agency on trade practices ... enough said.
Cheers,
David
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Sat Nov 30 1996 - 23:11:06 GMT