OpenMotif 2.4 User Requirements

This forum is read only. No new submissions are accepted.

Questions about motif? Contact us

Submitted by Mark on Fri, 12/02/2005 - 15:57.

Hi,
The purpose of this forum is to provide a mechanism to gather feature/functionality requirements from the Motif user community for the next release of OpenMotif.
There are a lot of possibilities. Some of the ones that have been requested in the past include:

  • GUI modernization - this encompasses everything from providing a replacement for the file dialog to style/color changes to adding themes. Accessibility - Many governments around the world have defined requirements for making software accessible to people of all physical abilities. In the USA, this has been defined by Section 508
    Desktop Integration - With CDE being replaced by Gnome and KDE as the desktops of choice, there has been requirements that Motif provide better support for integrating with these desktops and applications written in either GTK+ or Qt.

This is just a start. Please suggest additional requirements!
Mark [/]

Sat, 12/24/2005 - 16:53#1

Sat, 12/24/2005 - 16:53#1

Anonymous

OpenMotif 2.4 User Reguirements

I have a few suggestions looking for to be integrated in the next realese of Motif. I would love to see MotifPlus or making it C++ library instead of pure C calls.

0) Free Motfi GUI Builder that comes with the package
1) Pluggable themes (Not just images and icons)
2) Dockable windows/toolbars
3) Enahnced pan widged

BTW if we want Motif to be well integrated in the new Desktops (GNOME/KDE), why not just rely on GTK/Qt on which these desktops are natives, and all th functionality I mentioned already there??????

Wed, 12/28/2005 - 16:21#3

Wed, 12/28/2005 - 16:21#3

Anonymous

OpenMotif 2.4 User Reguirements

The panning widget to be the same as either in GTK or MFC. But I think all the requirested features already there in the GTK or QT. What other advantages do you think we have in Motif?

Fri, 12/30/2005 - 20:02#4

Fri, 12/30/2005 - 20:02#4

Mark

OpenMotif 2.4 User Reguirements

There is already a panner/porthole in Motif 2.3 (actually was introduced in Motif 2.2). That is why I am a little confused on what you are looking for. (Stay tuned for the OM 2.3 6B update manual. That will have the documentation you need to see if it meets your needs!)

Mark

 

Fri, 01/13/2006 - 15:19#5

Fri, 01/13/2006 - 15:19#5

Anonymous

Re: OpenMotif 2.4 User Reguirements

Mark wrote:

Hi,

The purpose of this forum is to provide a mechanism to gather feature/functionality requirements from the Motif user community for the next release of OpenMotif.

There are a lot of possibilities. Some of the ones that have been requested in the past include:

  • GUI modernization - this encompasses everything from providing a replacement for the file dialog to style/color changes to adding themes.

    Accessibility - Many governments around the world have defined requirements for making software accessible to people of all physical abilities. In the USA, this has been defined by Section 508

    Desktop Integration - With CDE being replaced by Gnome and KDE as the desktops of choice, there has been requirements that Motif provide better support for integrating with these desktops and applications written in either GTK+ or Qt.

This is just a start. Please suggest additional requirements!

Mark

What about "multiple columned list" and/or "tree widget" (GTK has merged these two in one): this is what I miss from GTK/QT.
[/]

 

Fri, 03/03/2006 - 01:39#8

Fri, 03/03/2006 - 01:39#8

Anonymous

OpenMotif 2.4 User Reguirements

A good set of C++ wrappers should be included with the standard (Open)Motif distribution. Now, I understand that squeen likely just always wants the ablity to program in just strait C. But C is a language that makes it easy to shoot yourself in the foot, C++ makes it harder, but when you do you blow off your whole foot -- Stroustrup said something like this. One thing that keeps Motif loosing market share is that it is difficult for younger programmers -- under 32 years of age who learned languages explictly made for OOP as their schooling languages hate using strings to figure out dynamic bindings.

However, until Motif becomes cross platform to Microsoft Windows and Apple (natively wo X) it will not be something I would consider to write any new software in. That really should be the next step for Motif -- to compete with the likes of wxWidgets, Tk, and Qt. Now, of course, given that it is based on X Windows and Xt lib I don't see how to get there from here.

Of course this feature for Motif is a lot of work I don't expect that it could even be done in a (Open)Motif 2.4.

Fri, 03/03/2006 - 18:54#9

Fri, 03/03/2006 - 18:54#9

Anonymous

Let's get real ...

Motif is dead! Unless there is suddenly a change in philosophy and supports a C++ interface, and native Windows and OSX guis, there is no way it will compete with offerings such as Qt, wxWidgets, GTK++, etc. I have never seen the answer to the question: What advantages does Motif provide over the other offerings? ... and I don't expect to see it either.

Sat, 03/04/2006 - 19:59#10

Sat, 03/04/2006 - 19:59#10

Anonymous

Re: OpenMotif 2.4 User Reguirements

The standard Motif theme is sort of prehistoric and terribly ugly. I do love, however, the Indigo Magic desktop and its customized Motif theme. "5dwm" seems to be dead. So, if somebody could step up

Tue, 03/28/2006 - 00:11#11

Tue, 03/28/2006 - 00:11#11

happygolucky

XmText and XmTextField

The behavior of the XmTextField and XmText with respect to render tables and rendition tags should be updated. One should be able to program to use tags to specify which font or set of fonts to use for the text in a given instance thereof.

Currently, one can only use the _MOTIF_DEFAULT_LOCALE tag. I have been told elsewhere that the extentions to Motif for CDE actually allow one to specify which rendition to use for an XmTextField or XmText instance. Such extentions should likely be standardized in the next version of Motif.

Futher though, one should be able to specify not just the font through the rendtion table, but also the color and other rendition features. (Hopefully, someday the tab list stuff will work within renditions.)

Futhermore, one should be able to use multiple tags in rendering text in the XmText and XmTextField so that even each character may use a different rendition. This sort of thing would make it easier to actually write things such as code editors that do syntax highlighting.

Basically, a design of the XmTextField and XmText should also incorporate use of XmString being ingrated with XmTextField and XmText so that Motif is more consistant.

Thu, 08/20/2009 - 08:43#12

Thu, 08/20/2009 - 08:43#12

Olivier LAHAYE

A better system integration

A better system integration would be cool.

At least, there is no pkg-config file which would be very
convenient for many config tools

Here is one that could be used on 64bits systems that have
the pkg-config tool:

Filename: /usr/lib64/pkgconfig/xm.pc
-----------8<-----------8<-----------8<-----------8<-----------
prefix=/usr
exec_prefix=/usr
libdir=/usr/lib64
includedir=/usr/include

Name: Xm
Description: Open Motif Widgets Library, version 2.4.x
Version: 2.4.0
Requires: xproto xt xmu
Requires.private: x11 xext xt xmu xpm
Cflags: -I${includedir}
Libs: -L${libdir} -lXm
-----------8<-----------8<-----------8<-----------8<-----------

 

Wed, 08/26/2009 - 11:02#13

Wed, 08/26/2009 - 11:02#13

blinkenlichten

Hello there! I would like

Hello there!
I would like to say that i.m.h.o. OpenMotif is the best way to create GUI-application which has interact with the POSIX-system built in functions. The only disadvantage - it relies on X11 font rendering system, which is not fully capable for some languages. But motif gives an impression of industry-standart tool, hence it doesn't have to be overloaded much.
Also many people thought about it's visual look [exact suggestion - is to make better shadows and effects], really, maybe there's need to go further from simplicity to provide ease in interaction with human, i.m.h.o. that's important for applications used by workers for automobile engines testing, for example.

To skeptics (e.g. "C++ and Qt rocks!"):
Personally, I'm young enthusiast, 20years old, and I appreciate OpenMotif's team for developing such great toolkit. Apparently it's the best thing I found, when started to learn C-programming [quite short period ago], to make gui-application for homemade oscilloscope.

Regards, blinkenlichten.

 

Fri, 08/28/2009 - 13:56#14

Fri, 08/28/2009 - 13:56#14

dpeterc

I am glad you like

I am glad you like OpenMotif, I share your taste, but I would like to correct one imprecision.

blinkenlichten wrote:

The only disadvantage - it relies on X11 font rendering system, which is not fully capable for some languages.

OpenMotif supports UTF-8 and XFT fonts, so you can display text in any language.
As a matter of fact, the Motif-based software developed by my company is translated in 11 languages, and can display "difficult" languages like Thai and Chinese.
http://www.arahne.si/
You can download the demo from here:
http://www.arahne.si/installAWeave.html
and change the language in ArahWeave setup screen.
You are correct in stating the problems in displaying the text in some languages, as a UTF-8 Unicode font with support for all languages is not easy to find on Linux.
So for correct display of Chinese, we have to use font SimHei, and for Thai, we have to use Tahoma.
These fonts are not available in regular Linux distributions, nor any other fonts of comparable quality and characters for Thai or simplified Chinese. Don't be misled by the label "simplified" - it is still difficult with tens of thousands of glyphs.
To change the font in ArahWeave, go in Files > Save setup, Appearance tab, and choose the Antialiased font from the drop down text box.

What Motif is lacking, and Qt has, is automatic switching to a default UTF8 font, which has all the glyphs, in case when the character is not available in the currently selected font. OpenMotif uses raw XFT rendering, which displays a rectangle or space in the area of the missing character, while Qt's text rendering, even if it is also XFT based, will replace the missing character with one from the default font. So it will look ugly and out of place, but still readable.

On the architectural side, Motif is X11 based toolkit, so it is only reasonable that it uses X11 for rendering. I don't think any toolkit nowadays implements a "private" version of font rendering. The task is much too big. Motif only needs to use the X11 font services in a little more elaborate way, like I suggested above.

 

Mon, 05/17/2010 - 14:34#15

Mon, 05/17/2010 - 14:34#15

moorecm

dpeterc wrote: I am glad

dpeterc wrote:

I am glad you like OpenMotif, I share your taste, but I would like to correct one imprecision.

blinkenlichten wrote:

The only disadvantage - it relies on X11 font rendering system, which is not fully capable for some languages.

OpenMotif supports UTF-8 and XFT fonts, so you can display text in any language.
As a matter of fact, the Motif-based software developed by my company is translated in 11 languages, and can display "difficult" languages like Thai and Chinese.
http://www.arahne.si/
You can download the demo from here:
http://www.arahne.si/installAWeave.html
and change the language in ArahWeave setup screen.
You are correct in stating the problems in displaying the text in some languages, as a UTF-8 Unicode font with support for all languages is not easy to find on Linux.
So for correct display of Chinese, we have to use font SimHei, and for Thai, we have to use Tahoma.
These fonts are not available in regular Linux distributions, nor any other fonts of comparable quality and characters for Thai or simplified Chinese. Don't be misled by the label "simplified" - it is still difficult with tens of thousands of glyphs.
To change the font in ArahWeave, go in Files > Save setup, Appearance tab, and choose the Antialiased font from the drop down text box.

What Motif is lacking, and Qt has, is automatic switching to a default UTF8 font, which has all the glyphs, in case when the character is not available in the currently selected font. OpenMotif uses raw XFT rendering, which displays a rectangle or space in the area of the missing character, while Qt's text rendering, even if it is also XFT based, will replace the missing character with one from the default font. So it will look ugly and out of place, but still readable.

On the architectural side, Motif is X11 based toolkit, so it is only reasonable that it uses X11 for rendering. I don't think any toolkit nowadays implements a "private" version of font rendering. The task is much too big. Motif only needs to use the X11 font services in a little more elaborate way, like I suggested above.

Have you tried using an input method, such as SCIM, with XFT fonts?
Have you tried supporting a right to left language?
Have you tried any bidirectional languages, such as Arabic, where the language reads from right to left but numbers remain left to right?

Out of the box, these questions can only be answered with failure. They can all be done, if you download Motif and patch it yourself. That notion, my friend, is absolutely ludicrous with the other toolkit offerings.

Additionally, regarding the rest of the thread, one poster had it right. Motif is dead.

Why is the recommended stable version of OpenMotif still 2.2.3? Stability should be the first goal of these efforts--not hacking in more poorly integrated bells and whistles. I suggest an entire rewrite as version 3, not wasting effort on 2.4.

 

Sun, 09/06/2009 - 19:44#16

Sun, 09/06/2009 - 19:44#16

blinkenlichten

Oh, yes, that part in my

Oh, yes, that part in my post was really incorrect, maybe I got confused after reading some other information about some problems with glyphs etc.
I take my words back.

Thank you for explanation.

 

Thu, 05/06/2010 - 15:31#17

Thu, 05/06/2010 - 15:31#17

blinkenlichten

Hello! Maybe such kind of

Hello!
Maybe such kind of widget would be useful to add:
An expandable widget, e.g. there is an arrow, clicking on it appears the container-widget below where other widgets could be placed.

That would be great for use in the configuration dialogs.