Re:Seems worse for the normal user
on
Mozilla 0.9.1 Out
·
· Score: 2
I agree, this is one thing I really like about IE.
With all this copying of Windows UI, why don't any of the toolkits support such menubars? It looks like this is a native MFC thing and has been around for awhile.
Of course what I would really like to see is the eradication of all these toolbars and a switch to pop-up menus and windows that contain only content, but it is looking hopeless...
Another point is that when you compile a C program you have the source code and can add the missing delimiters. When you read the web page you cannot fix it, no matter how detailed the error message is (and Netscape produces NO error message).
It is shameful that people here refuse to say that MicroSoft does anything right. In fact, ignoring the exact letters of silly standards is what the original Unix designers did (that's why we have single-character newlines while Windoze and all others have ^M^J and the unnecessary complexity that adds, and why 8-bit characters work), and it really does result in an easier-to-use system, and also makes it a lot easier to program.
MicroSoft only does evil extensions when they produce data that can only be interpreted by their programs. This must be fought, but simple changes like this, where the result and how to use it are clear, is not evil, it is just an attempt to be user friendly. People here have got to see the difference.
Is there a good reason for this or is this due to some stupidity in MSWord? I assumme it has something to do with bidirectional scripts, but if normal space is not used for anything in Arabic then I would accuse MicroSoft of being stupid.
If this is the normal non-breaking space character (0xA0 in Unicode) then it takes 2 bytes in Unicode.
I didn't claim they tried to support all European characters. What I meant is that they did not ignore them totally. They (rather stupidly) thought that a few accent marks would do the job.
The cent sign was replaced with the caret. That is why shift+6 prints a caret, if you look at old typewriters that was how you printed a cent sign. This is in fact the main reason I think they considered European support, since from an American point of view the cent sign is more important. The fractions were what were replaced by the square braces. The curly braces, vertical bar, and apparently the tilde were added later (originally they printed as square braces, slash, and caret, and devices that totally ignored the lower-case bit were allowed, and the original tilde was changed to underscore because that character was missing originally).
"Extended ASCII" usually refers to the replacement of several of the punctuation marks with European characters. This was pretty useless because by then most OS's had assigned meaning to those punctuation marks (like the square brackets), also only 5 or 6 new characters were available. This died almost immediately when people started supporting the 8th bit as data rather than parity.
Thanks for some more intelligent discussion about UTF-8.
I might add a few things:
In UTF-8 not just NULL or Escape are not in the multibyte characters, in face *all* 7-bit characters are not in the multibyte characters (the multibytes have the high bit set in all bytes). This means that *any* program that treats all bytes with the high bit set as a "letter" will work and can parse, hash, match, search, etc identifiers/words with foreign letters in them!
In addition the UTF-8 encoding is just heavy enough that random line noise is very unlikely to match a UTF-8 encoding. If programs treat "illegal" UTF-8 encodings as individual bytes in the ISO-8859-1 character set, it will display virtually all existing ASCII/ISO-8859-1 documents unchanged!
The end result is that it should be easy to switch all interfaces (not just over the network, but inside programs and to libraries) to UTF-8. This will vastly simplify the handling of Unicode because there will be no need for ASCII back compatability interfaces. We could also eliminate all the "locale" crap and make ctype.h the simple thing it once was.
Even Arabic will encode smaller in UTF-8 than UTF-16. This is due to the fact that very common characters (not just English, but things like space and newline) are only one byte.
When ASCII was invented it was based on existing typewriters, including the ones sold in Europe. At that time output was on paper and it was rather easy to overstrike characters to produce accented characters. How else do you explain the existence of the '~', '^', and backquote characters (in addition the underscore code was originally a macron). They actually designed it so the countries of NATO could type as well as they could on a typewriter. They also deleted several characters Americans wanted (fractions, fl and fi ligatures, open and close quotes, cent sign were all very common on typewriters of that period).
Yes, only a small set of countries was considered, and only minimal support. But this claim on "no support for anything not USA" is false.
UTF-8 can encode 31 bit characters with an obvious extension of the standard (or perhaps this is part of the standard, I'm not sure).
After that point it breaks down (if you continue the first byte is filled and the prefixes will have to go into the second byte). Alternatively you can quit at that point, use the remaining bit as the 32'nd bit, and say that UTF-8 cannot encode more than 32 bits.
Anyway, one big advantage of variable-sized encoding is that there is potentially no limit to the size of the data transferred.
My personal opinion is that UTF-8 should be used *everywhere*, including all internal interfaces to libraries and services like X. The sooner we stamp out these "wide characters" and all the complexity they cause by doubling or quadrupiling the number of interfaces we need, the better.
UTF-8 probably does not address the concerns of the article, which is about the fact that Unicode does not contain all possible scribbles drawn by humans. But the fact that English speakers were able to compensate for decades and even adapted to the rather arbitrary and limited 62-character ascii set would indicate that people will easily compensate for this as well.
I don't think "extensions rule". I would much rather see them add things in such a way that old programs can take advantage of them. Sure, *new* controls are an "extension", but there is no reason to make parallel interfaces to do the same thing. I ranted about this before, but maybe I need to be specific about how I would have added AntiAliased and Unicode support to X:
1. Add a new call to set the current font, with an intelligent interface. But both this and the "old" (xlfd) call update the same internal data structures, ie you don't need to know what call was used when drawing anything.
Antialiasing just works after that, as long as copy or replace pixel transfer mode is on. Setting xor mode, etc, turn off antialiasing. This is what the much-derided MicroSoft did with their calls (they did not always support antialiasing), I see no reason X cannot do at least that well!
To support Unicode, I would make the interface take UTF-8 encoding ALL THE TIME. However there are no "errors", instead illegal sequences of UTF-8 are printed as individual bytes. This would support ISO-8859-1 encoding just fine, there needs to be 3 accented characters in a row to make it accidentally think it is a UTF-8 character.
X11 lacking a standard toolkit is a feature, just like you said. One problem with a lot of this crap being added to Xlib is that everybody says "but Qt will be adding support really soon". This does not cut it, I don't want to be forced to use Qt anymore than I want to be forced to use MFC.
Re:Games: XFree86 with DRI, or Linux FBDev?
on
XFree 4.1.0 Out
·
· Score: 2
Yes the driver probably will need to be open-source. However it appears that after you have basic "turn this pixel this color" support, everything else in the interface is like "send this value to this control register". This will allow the "secret" stuff (ie what numbers to put into what control registers) to be put into a user-level "accelerated graphics library" and remain closed-source.
What software is this? Do you have the source code? It seems hard to believe that some other company has compiled the source code for Linux and not removed the colormap dependency, since no Linux XFree86 driver supports multiple visuals.
Unfortunately for you, hardware support for 8-bit colormaps is going away very fast, and interest in supporting or emulating it is nearly zero since it prevents all the cool 3-D stuff and antialiasing from working. I recommend you get into that code and try to patch out whatever requires it asap.
My guess is the big problem is that it stores colors in a byte inside structures in the program. What you need to do is make a 256-entry lookup table from that byte to an actual X pixel, make a macro wrapper that you then need to put around all uses of color in the program that does the lookup through the table. You also need to fix the code that calls XAllocColor so that it instead allocates a new entry in the table, puts the result of XAllocColor there, and returns that table index.
If your program is using bit-fiddling to draw overlays, well you really need to seriously consider rewriting it. This typically will bypass any hardware acceleration and I have also seen signs that (due to the fact that it is never tested) it often does not work on X servers. The easiest way to get "overlays" is to use a pixmap "backbuffer" and draw the main image there. Copy it to the screen to "erase the overlay" and draw on the main window to "draw the overlay".
I know this is a pain, but I really recommend you fix your program if at all possible.
PS: if they are using this program on Windows, they already fixed it, so see what was done to the code there.
I have a lot of problems with the designs being done to X. There is no reason for this to be an "extension". All that needs to be done is send a XConfigureNotify event to the desktop window with the new size, and let the window manager do whatever it wants with this.
I'm sure they are all worried about "what about old window managers that don't expect an XConfigureNotify event for the desktop?". Well my response is: "SO WHAT?". I really expect that they will ignore it, and your windows will end up unmoved and thus positioned off the screen. If the window manager crashes, well then it was written like crap and you should not be using it anyway.
This paranoia about changing anything without making an "extension" is really killing any possibility of X being worthwhile. We should be having anti-aliased fonts BY DEFAULT, not with an "extension", and I really care absolutly ZERO that this breaks programs that use Xor to draw fonts (it doesn't anyway, just turn it off if Xor is being used). It is disgusting that you need to use elaborate interfaces and an "extension" to draw images using shared memory, why the hell does it not select the fastest possible transfer for me automatically? Why haven't we jettisoned colormaps and switched to true-color emulation on all displays?
The much-hated MicroSoft did the equivalent of all of these, and did them in ways so that old programs not only continued to work, but actually could take advantage of these changes. It is pretty pathetic that the X design commitee cannot even match MicroSoft's lame attempts!
Comon, surely you can tell the differece between "use opensource software" (which is what Ballmer said) and "use the source code to opensource software" (which is what the people being bitched about in that article did).
Unlike you, some people who argue against the GPL are actually intelligent, and things like this greatly diminish any respect they can get, here or anywhere!
I think there should be a requirement here: any SlashDot poster who says "I can't write my commercial software because of the GPL" must provide the following information:
Exaclty what piece of GPL code they need for their commercial software.
Proof that that piece is not actually under the LGPL or any of the zillion LGPL-like licenses, or under another free license, or available commercially.
Proof that there is no equivalent piece of software available commercially.
Documentation showing that they attempted to contact the author and get them to relicense the code in a way that it could be used in their commercial product, and were turned down (note that any price quote does not count as being turned down!)
A convincing argument as to why they could not clean-room reverse engineer the code.
This rather simple set of requirements will restrict the submittors of these messages to the actual commercial software developers who are seeing their business destroyed by the GPL. Unfortunately the number of these is exactly ZERO.
Every single developer using SourceForge's CVS has a "copy stored elsewhere". That is how CVS works.
A developer can type "cvs diff -r HEAD" to see what has changed between whatever is checked in and what they have on their local store.
Actually the idea that the hackers would do this is rather silly. This was also suggested that hackers into MicroSoft may have modified the Windows source code to introduce back doors. Anybody who thinks this is possible should be writing movie scripts.
No, it's new XML addressing. The four new 4Gig banks are addressed by putting the ascii strings "zero", "one", "two", and "thre" into the top 4 bytes. MicroSoft and Intel engineers patented the new spelling of 3 that allows them to save 8 bits per address!
Very good point. Isn't some of the microcode on that Pentium processor un-free? What about the design of some of the ASICs? I'll bet the electricity comes from a generator that may have a Windows machine controlling it!
We have Linux machines here that support overlay visuals. Both X and OpenGL overlays are supported and have 8 bits. These are made by BoXX and have FireGL2 cards.
It is true that I have never seen a Linux X that supports multiple main-layer visuals. However I consider it a good thing, it is a waste of hardware to support these legacy apps. This is an area where a commercial entity like Sun can compete with Linux.
I think the LGPL can cover your "interfaces" problem just fine.
Most of the your problems and absurdities are due to your assumption that people will put stuff under the GPL when it makes absolutely no sense to do so (at least assumming they want their stuff to be used).
In for your printer driver example, it is true that a GPL printer driver can not legally be used by a non-GPL program. Contrary to what MicroSoft is trying to claim, this does not mean that MSWord is suddenly forced to be GPL. It means you cannot use MSWord with this printer driver. This probably makes this printer driver pretty useless for the majority of users and thus the author was really stupid for putting it under the GPL rather than the LGPL or another license.
Most likely outcome is that they will get the authors of the original code to agree to sell/donate it under a different license to them. This will look like a win for everybody.
They could also be pains in the ass and work around the GPL this way: My understanding is that this is a plugin that plays movie files. Their big hole is that they are advertising features of this plugin, and that there is no other plugin. They could remove the advertising and say something like "Plays many movie formats" and then also provide some dummy plugin (perhaps also under the gpl) that does something useless like play.gif movies. That way the program "works" without the gpl plugin and they can legitimatly say it is not a derived work. This may make some gpl purists mad, but I don't see this as being too bad an outcome either.
Re:Article is OLD, Focus on eliminating the fork!
on
The Superior Motif?
·
· Score: 3
Although I also think Motif sucks, your arguments seem to indicate you don't know what you are talking about.
The problems of the inability to direct a FILE* to an in-memory stream (at least in a portable way) are well known and toolkit independent. You will be in exactly the same state if you call your binary library from GTK. Yea, libc should be fixed, however I have seen the nice ideas of iostreams be turned into an enormous bloated mess by people who have no clue (with "wide characters" and binary i/o and attempts to make a thing designed for byte streams into the do-all of stream input output), so I am not sure if we want them messing with FILE* (which I have been forced to return to because of the bloat and slowness of the modern template cio library).
You have to flush the output buffers. For cpio you can do "cout If a binary library writes to stdout or stderr, there is no way any toolkit can get this without modifying libc (actually there may be something that can be done with Glibc, but whatever it is is going to be toolkit independent).
Motif was written long before C++ so it is not suprising that there is no way to redirect cout to a widget. Motif also does not use C++ which means this could not be part of standard Motif (though easily in a C++ only header file).
Except KDE sets something so that Qt is switched to Win32 appearance all the time. A very good idea. I wish Qt would just give up this stupid "Unix look" and make the default be the Win32. The could probably delete a lot of code, too (apparently this appearance stuff is sepearte from the newer themes stuff).
In our in-house Qt applications we turn on Win32 appearance everywhere. The Motif look is ugly as sin, and since the widgets change size lots of stuff does not work.
I have to also rant against this belief that the users are confused if they don't have a "consistent user interface" between their programs. This is absolutely untrue, I have never seen anybody confused because the buttons in their programs look different, witness the game designers who don't seem very concerned about the appearance of buttons! What does confuse people is when their favorite application changes between platforms (or between versions). I have been killed here because I attemted to change our bindings to be Windows-like, people could not stand it (despite using this application on NT) and I had to change it back! Nobody seems concerned that Alt+X does cut in my program but it is Ctrl+X in other programs, they were totally frustrated by my attempt to change it to Ctrl+X. So I believe that consistency in an application is far, far, more important than between applications. And all attempts by toolkits to mimic the "theme" of the platform are mistakes that make the programs unportable and user unfriendly.
Slashdot Mirror
With all this copying of Windows UI, why don't any of the toolkits support such menubars? It looks like this is a native MFC thing and has been around for awhile.
Of course what I would really like to see is the eradication of all these toolbars and a switch to pop-up menus and windows that contain only content, but it is looking hopeless...
Another point is that when you compile a C program you have the source code and can add the missing delimiters. When you read the web page you cannot fix it, no matter how detailed the error message is (and Netscape produces NO error message).
It is shameful that people here refuse to say that MicroSoft does anything right. In fact, ignoring the exact letters of silly standards is what the original Unix designers did (that's why we have single-character newlines while Windoze and all others have ^M^J and the unnecessary complexity that adds, and why 8-bit characters work), and it really does result in an easier-to-use system, and also makes it a lot easier to program.
MicroSoft only does evil extensions when they produce data that can only be interpreted by their programs. This must be fought, but simple changes like this, where the result and how to use it are clear, is not evil, it is just an attempt to be user friendly. People here have got to see the difference.
If this is the normal non-breaking space character (0xA0 in Unicode) then it takes 2 bytes in Unicode.
The cent sign was replaced with the caret. That is why shift+6 prints a caret, if you look at old typewriters that was how you printed a cent sign. This is in fact the main reason I think they considered European support, since from an American point of view the cent sign is more important. The fractions were what were replaced by the square braces. The curly braces, vertical bar, and apparently the tilde were added later (originally they printed as square braces, slash, and caret, and devices that totally ignored the lower-case bit were allowed, and the original tilde was changed to underscore because that character was missing originally).
"Extended ASCII" usually refers to the replacement of several of the punctuation marks with European characters. This was pretty useless because by then most OS's had assigned meaning to those punctuation marks (like the square brackets), also only 5 or 6 new characters were available. This died almost immediately when people started supporting the 8th bit as data rather than parity.
I might add a few things:
In UTF-8 not just NULL or Escape are not in the multibyte characters, in face *all* 7-bit characters are not in the multibyte characters (the multibytes have the high bit set in all bytes). This means that *any* program that treats all bytes with the high bit set as a "letter" will work and can parse, hash, match, search, etc identifiers/words with foreign letters in them!
In addition the UTF-8 encoding is just heavy enough that random line noise is very unlikely to match a UTF-8 encoding. If programs treat "illegal" UTF-8 encodings as individual bytes in the ISO-8859-1 character set, it will display virtually all existing ASCII/ISO-8859-1 documents unchanged!
The end result is that it should be easy to switch all interfaces (not just over the network, but inside programs and to libraries) to UTF-8. This will vastly simplify the handling of Unicode because there will be no need for ASCII back compatability interfaces. We could also eliminate all the "locale" crap and make ctype.h the simple thing it once was.
Even Arabic will encode smaller in UTF-8 than UTF-16. This is due to the fact that very common characters (not just English, but things like space and newline) are only one byte.
Yes, only a small set of countries was considered, and only minimal support. But this claim on "no support for anything not USA" is false.
After that point it breaks down (if you continue the first byte is filled and the prefixes will have to go into the second byte). Alternatively you can quit at that point, use the remaining bit as the 32'nd bit, and say that UTF-8 cannot encode more than 32 bits.
Anyway, one big advantage of variable-sized encoding is that there is potentially no limit to the size of the data transferred.
My personal opinion is that UTF-8 should be used *everywhere*, including all internal interfaces to libraries and services like X. The sooner we stamp out these "wide characters" and all the complexity they cause by doubling or quadrupiling the number of interfaces we need, the better.
UTF-8 probably does not address the concerns of the article, which is about the fact that Unicode does not contain all possible scribbles drawn by humans. But the fact that English speakers were able to compensate for decades and even adapted to the rather arbitrary and limited 62-character ascii set would indicate that people will easily compensate for this as well.
1. Add a new call to set the current font, with an intelligent interface. But both this and the "old" (xlfd) call update the same internal data structures, ie you don't need to know what call was used when drawing anything.
Antialiasing just works after that, as long as copy or replace pixel transfer mode is on. Setting xor mode, etc, turn off antialiasing. This is what the much-derided MicroSoft did with their calls (they did not always support antialiasing), I see no reason X cannot do at least that well!
To support Unicode, I would make the interface take UTF-8 encoding ALL THE TIME. However there are no "errors", instead illegal sequences of UTF-8 are printed as individual bytes. This would support ISO-8859-1 encoding just fine, there needs to be 3 accented characters in a row to make it accidentally think it is a UTF-8 character.
X11 lacking a standard toolkit is a feature, just like you said. One problem with a lot of this crap being added to Xlib is that everybody says "but Qt will be adding support really soon". This does not cut it, I don't want to be forced to use Qt anymore than I want to be forced to use MFC.
Yes the driver probably will need to be open-source. However it appears that after you have basic "turn this pixel this color" support, everything else in the interface is like "send this value to this control register". This will allow the "secret" stuff (ie what numbers to put into what control registers) to be put into a user-level "accelerated graphics library" and remain closed-source.
Unfortunately for you, hardware support for 8-bit colormaps is going away very fast, and interest in supporting or emulating it is nearly zero since it prevents all the cool 3-D stuff and antialiasing from working. I recommend you get into that code and try to patch out whatever requires it asap.
My guess is the big problem is that it stores colors in a byte inside structures in the program. What you need to do is make a 256-entry lookup table from that byte to an actual X pixel, make a macro wrapper that you then need to put around all uses of color in the program that does the lookup through the table. You also need to fix the code that calls XAllocColor so that it instead allocates a new entry in the table, puts the result of XAllocColor there, and returns that table index.
If your program is using bit-fiddling to draw overlays, well you really need to seriously consider rewriting it. This typically will bypass any hardware acceleration and I have also seen signs that (due to the fact that it is never tested) it often does not work on X servers. The easiest way to get "overlays" is to use a pixmap "backbuffer" and draw the main image there. Copy it to the screen to "erase the overlay" and draw on the main window to "draw the overlay".
I know this is a pain, but I really recommend you fix your program if at all possible.
PS: if they are using this program on Windows, they already fixed it, so see what was done to the code there.
I'm sure they are all worried about "what about old window managers that don't expect an XConfigureNotify event for the desktop?". Well my response is: "SO WHAT?". I really expect that they will ignore it, and your windows will end up unmoved and thus positioned off the screen. If the window manager crashes, well then it was written like crap and you should not be using it anyway.
This paranoia about changing anything without making an "extension" is really killing any possibility of X being worthwhile. We should be having anti-aliased fonts BY DEFAULT, not with an "extension", and I really care absolutly ZERO that this breaks programs that use Xor to draw fonts (it doesn't anyway, just turn it off if Xor is being used). It is disgusting that you need to use elaborate interfaces and an "extension" to draw images using shared memory, why the hell does it not select the fastest possible transfer for me automatically? Why haven't we jettisoned colormaps and switched to true-color emulation on all displays?
The much-hated MicroSoft did the equivalent of all of these, and did them in ways so that old programs not only continued to work, but actually could take advantage of these changes. It is pretty pathetic that the X design commitee cannot even match MicroSoft's lame attempts!
Unlike you, some people who argue against the GPL are actually intelligent, and things like this greatly diminish any respect they can get, here or anywhere!
Sorry, I was responding to one of the earlier postings, not yours.
Exaclty what piece of GPL code they need for their commercial software.
Proof that that piece is not actually under the LGPL or any of the zillion LGPL-like licenses, or under another free license, or available commercially.
Proof that there is no equivalent piece of software available commercially.
Documentation showing that they attempted to contact the author and get them to relicense the code in a way that it could be used in their commercial product, and were turned down (note that any price quote does not count as being turned down!)
A convincing argument as to why they could not clean-room reverse engineer the code.
This rather simple set of requirements will restrict the submittors of these messages to the actual commercial software developers who are seeing their business destroyed by the GPL. Unfortunately the number of these is exactly ZERO.
A developer can type "cvs diff -r HEAD" to see what has changed between whatever is checked in and what they have on their local store.
Actually the idea that the hackers would do this is rather silly. This was also suggested that hackers into MicroSoft may have modified the Windows source code to introduce back doors. Anybody who thinks this is possible should be writing movie scripts.
No, it's new XML addressing. The four new 4Gig banks are addressed by putting the ascii strings "zero", "one", "two", and "thre" into the top 4 bytes. MicroSoft and Intel engineers patented the new spelling of 3 that allows them to save 8 bits per address!
Very good point. Isn't some of the microcode on that Pentium processor un-free? What about the design of some of the ASICs? I'll bet the electricity comes from a generator that may have a Windows machine controlling it!
It is true that I have never seen a Linux X that supports multiple main-layer visuals. However I consider it a good thing, it is a waste of hardware to support these legacy apps. This is an area where a commercial entity like Sun can compete with Linux.
I think this falls under the "mere aggregation" clause and thus there is no problem.
Sorry, the reason your non-GPL program can call fopen() is that fopen() is under the LGPL, not because other systems have an fopen() call.
Most of the your problems and absurdities are due to your assumption that people will put stuff under the GPL when it makes absolutely no sense to do so (at least assumming they want their stuff to be used).
In for your printer driver example, it is true that a GPL printer driver can not legally be used by a non-GPL program. Contrary to what MicroSoft is trying to claim, this does not mean that MSWord is suddenly forced to be GPL. It means you cannot use MSWord with this printer driver. This probably makes this printer driver pretty useless for the majority of users and thus the author was really stupid for putting it under the GPL rather than the LGPL or another license.
They could also be pains in the ass and work around the GPL this way: My understanding is that this is a plugin that plays movie files. Their big hole is that they are advertising features of this plugin, and that there is no other plugin. They could remove the advertising and say something like "Plays many movie formats" and then also provide some dummy plugin (perhaps also under the gpl) that does something useless like play .gif movies. That way the program "works" without the gpl plugin and they can legitimatly say it is not a derived work. This may make some gpl purists mad, but I don't see this as being too bad an outcome either.
The problems of the inability to direct a FILE* to an in-memory stream (at least in a portable way) are well known and toolkit independent. You will be in exactly the same state if you call your binary library from GTK. Yea, libc should be fixed, however I have seen the nice ideas of iostreams be turned into an enormous bloated mess by people who have no clue (with "wide characters" and binary i/o and attempts to make a thing designed for byte streams into the do-all of stream input output), so I am not sure if we want them messing with FILE* (which I have been forced to return to because of the bloat and slowness of the modern template cio library).
You have to flush the output buffers. For cpio you can do "cout If a binary library writes to stdout or stderr, there is no way any toolkit can get this without modifying libc (actually there may be something that can be done with Glibc, but whatever it is is going to be toolkit independent).
Motif was written long before C++ so it is not suprising that there is no way to redirect cout to a widget. Motif also does not use C++ which means this could not be part of standard Motif (though easily in a C++ only header file).
It is possible to be crappier than Windows. "different" and "better" are not synonyms. Analog computers are different too, maybe you should use them.
In our in-house Qt applications we turn on Win32 appearance everywhere. The Motif look is ugly as sin, and since the widgets change size lots of stuff does not work.
I have to also rant against this belief that the users are confused if they don't have a "consistent user interface" between their programs. This is absolutely untrue, I have never seen anybody confused because the buttons in their programs look different, witness the game designers who don't seem very concerned about the appearance of buttons! What does confuse people is when their favorite application changes between platforms (or between versions). I have been killed here because I attemted to change our bindings to be Windows-like, people could not stand it (despite using this application on NT) and I had to change it back! Nobody seems concerned that Alt+X does cut in my program but it is Ctrl+X in other programs, they were totally frustrated by my attempt to change it to Ctrl+X. So I believe that consistency in an application is far, far, more important than between applications. And all attempts by toolkits to mimic the "theme" of the platform are mistakes that make the programs unportable and user unfriendly.