Re:Article is OLD, Focus on eliminating the fork!
on
The Superior Motif?
·
· Score: 1
No surprise, Motif predated any stable C++ compiler. So the designers created an object-oriented toolkit in "C". (Actually the Xt designers did this, Motif is just a widget set that is built on Xt).
Over the years, there have been C++ wrappers for Motif, probably not unsimilar to gtk--. However, if you want to use C++ and Motif, probably the best solution is ViewKit from SGI. It was developed by Doug Young (see his Prentice Hall Book "Object-Oriented Programming with C++ and Motif"). It group widgets into a larger grain set of objects, that then made inheritance a reasonable thing to do.
For a long time, SGI developers used ViewKit and Open Inventor for their visualization work. A non-commericial use version of ViewKit that works with Open Motif is available at http://www.viewkit.com
Mark
Article is OLD, Focus on eliminating the fork!
on
The Superior Motif?
·
· Score: 1
Hey everyone, the original article from Fountain is well over 12 months old and it was already featured on Slashdot when first published (do a search on "Motif"). One must ask why the Slashdot folks recycle stuff like this...
Lots of things have changed since then. Don't waste your time picking apart whether his comments on GTK/QT internationalization are correct, or why did he not know about Kylix, etc. Those all happened after the original article.
The relevant issue is dealing with the fork that has occurred in the Linux community over the UI toolkit and desktop. Let's learn from the UNIX wars and resolve this quickly before we degenerate into a civil war while Microsoft sits on the sidelines and laughs at us, again...
The basic tradeoffs (from my viewpoint, and I'm a Motif guy) are:
1. Motif - Enterprise/Legacy support. It is used in mission critical applications today. New mission critical business applications being developed for Fortune 1000 on Unix/Linux in C/C++ are generally using Motif. The real decrease in the use of Motif for new applications has been the result of enterprises moving to Java and Windows.
2. QT - Provides cross platform portability and native C++. This has been done before by a variety of companies that are now out of business (remember Galaxy?). The goal is to reduce the cost of supporting multiple OS's. The problem is that you end up creating a subset of the GUI that is natively available on the platform. Let's remember, we're writing applications for the benefit of end users, not ourselves. If the end user sees an application as being somewhat different in look and feel to his other applications, then it is confusing and frustrating. Lots of applications have started out using a portable toolkit only to be eventually rewritten in the native toolkit. The TrollTech folks are smart, perhaps they have it right and this won't happen?
3. GTK+ - C based, LGPL I think (and I am sure someone will correct me), that GTK+ was developed to provide a open toolkit and avoid the original commercial oriented licenses of QT and Motif. Certainly, However, Motif is now freely available on open source platforms and QT offers a GPL version for open source fans.
The world has indeed changed since Anthony wrote his article. The cross platform and C++ support of QT provides valid reasons why somebody might chose QT. However, I am personally completely perplexed on why someone might jettison one mature C based toolkit for another, that is less reliable and still needs to mature. There is just no real benefit.
While I am at it, some of the myths that seem to flow through this conversation:
1. Motif is bloated - check the facts. Compared stripped versions of the archive libraries. Even accounting for Xt, Motif on x86 is approximately the same size or smaller.
2. Motif is ugly - mostly claimed by people that don't understand resources.
3. Motif is dead - mature? maybe, dead? no way. Check the MotifZone (www.motifzone.net). There is themes for Motif there!
4. New applications are using GTK+/Qt - True for Open Source applications. Less clear for commercial/proprietary ones.
5. QT/GTK+ provide more modern widgets - true as part of the native toolkit. But that is not clearly an advantage because it creates a larger, bloated toolkit. There are plenty of Motif widgets out there (both open source and commercial), that do whatever you need.
6. Motif is history because Sun et. al. has abandon it. Well, maybe I'm older than most of you out there (I was a r.99p13 user of Linux), but my memory is that you are best betting against Sun and their choice of toolkits. Sun has a horrible history of picking the wrong toolkit.Remember NeWs? Remember Xview? Remember OpenLook? It is developers and end users that chose the toolkit, not the hardware vendor. This is even more true today as hardware vendors that seem to be focusing more on servers and less on desktops everyday. This means their influence on GUI toolkits are even less.
7. QT/GTK+ have better GUI builders - obviously, these people have never tried to use a GUI builder in a production application. First generation GUI builders often leave developers holding the bag. Great prototypers, gets you 80% there, and then drops you short with ugly machine generated code. Motif went through that phase over 10 years ago. The GUI builders that are now available, provide mechanisms, including preserving changes to the generated code, that allows you to go 100% of the distance. (They also generate readable code!) Go to the Glade home page and look at their todo list. It includes styles, modified generated code, etc. all done by Motif GUI builders 5 years ago. I seem to recall that TrollTech now claims that their QT Designer is a "real GUI Builder" in their latest release (probably don't have the exact words here, so please forgive the paraphrase) In regards to Kylix, I kind of like it. Pascal was my first computer languare. Let's drop C/C++ and switch!;-)
In any case, the real issue here is trying to figure out how to eliminate the fork in the road. This may not be a technical decision...
I think there are some licensing issues here that are not related to the traditional KDE/QT license bashing.
To be specific, under the GPL the theory is that if you create an application that uses open source code licensed under GPL, the GPL provisions are extended to your application too.
So what about commercial applications that allow the embedding of Kparts components covered under the GPL? Does the GPL flow back or is this a mechanism that allows proprietary developers to circumvent the GPL?
Although I am not a lawyer, I would guess that the XParts architecture with the use of dcomp certainly avoids the triggering of the GPL...
No surprise, Motif predated any stable C++ compiler. So the designers created an object-oriented toolkit in "C". (Actually the Xt designers did this, Motif is just a widget set that is built on Xt).
Over the years, there have been C++ wrappers for Motif, probably not unsimilar to gtk--. However, if you want to use C++ and Motif, probably the best solution is ViewKit from SGI. It was developed by Doug Young (see his Prentice Hall Book "Object-Oriented Programming with C++ and Motif"). It group widgets into a larger grain set of objects, that then made inheritance a reasonable thing to do.
For a long time, SGI developers used ViewKit and Open Inventor for their visualization work. A non-commericial use version of ViewKit that works with Open Motif is available at http://www.viewkit.com
MarkHey everyone, the original article from Fountain is well over 12 months old and it was already featured on Slashdot when first published (do a search on "Motif"). One must ask why the Slashdot folks recycle stuff like this...
Lots of things have changed since then. Don't waste your time picking apart whether his comments on GTK/QT internationalization are correct, or why did he not know about Kylix, etc. Those all happened after the original article.
The relevant issue is dealing with the fork that has occurred in the Linux community over the UI toolkit and desktop. Let's learn from the UNIX wars and resolve this quickly before we degenerate into a civil war while Microsoft sits on the sidelines and laughs at us, again...
The basic tradeoffs (from my viewpoint, and I'm a Motif guy) are:
1. Motif - Enterprise/Legacy support. It is used in mission critical applications today. New mission critical business applications being developed for Fortune 1000 on Unix/Linux in C/C++ are generally using Motif. The real decrease in the use of Motif for new applications has been the result of enterprises moving to Java and Windows.
2. QT - Provides cross platform portability and native C++. This has been done before by a variety of companies that are now out of business (remember Galaxy?). The goal is to reduce the cost of supporting multiple OS's. The problem is that you end up creating a subset of the GUI that is natively available on the platform. Let's remember, we're writing applications for the benefit of end users, not ourselves. If the end user sees an application as being somewhat different in look and feel to his other applications, then it is confusing and frustrating. Lots of applications have started out using a portable toolkit only to be eventually rewritten in the native toolkit. The TrollTech folks are smart, perhaps they have it right and this won't happen?
3. GTK+ - C based, LGPL I think (and I am sure someone will correct me), that GTK+ was developed to provide a open toolkit and avoid the original commercial oriented licenses of QT and Motif. Certainly, However, Motif is now freely available on open source platforms and QT offers a GPL version for open source fans.
The world has indeed changed since Anthony wrote his article. The cross platform and C++ support of QT provides valid reasons why somebody might chose QT. However, I am personally completely perplexed on why someone might jettison one mature C based toolkit for another, that is less reliable and still needs to mature. There is just no real benefit.
While I am at it, some of the myths that seem to flow through this conversation:
1. Motif is bloated - check the facts. Compared stripped versions of the archive libraries. Even accounting for Xt, Motif on x86 is approximately the same size or smaller.
2. Motif is ugly - mostly claimed by people that don't understand resources.
3. Motif is dead - mature? maybe, dead? no way. Check the MotifZone (www.motifzone.net). There is themes for Motif there!
4. New applications are using GTK+/Qt - True for Open Source applications. Less clear for commercial/proprietary ones.
5. QT/GTK+ provide more modern widgets - true as part of the native toolkit. But that is not clearly an advantage because it creates a larger, bloated toolkit. There are plenty of Motif widgets out there (both open source and commercial), that do whatever you need.
6. Motif is history because Sun et. al. has abandon it. Well, maybe I'm older than most of you out there (I was a r.99p13 user of Linux), but my memory is that you are best betting against Sun and their choice of toolkits. Sun has a horrible history of picking the wrong toolkit.Remember NeWs? Remember Xview? Remember OpenLook? It is developers and end users that chose the toolkit, not the hardware vendor. This is even more true today as hardware vendors that seem to be focusing more on servers and less on desktops everyday. This means their influence on GUI toolkits are even less.
7. QT/GTK+ have better GUI builders - obviously, these people have never tried to use a GUI builder in a production application. First generation GUI builders often leave developers holding the bag. Great prototypers, gets you 80% there, and then drops you short with ugly machine generated code. Motif went through that phase over 10 years ago. The GUI builders that are now available, provide mechanisms, including preserving changes to the generated code, that allows you to go 100% of the distance. (They also generate readable code!) Go to the Glade home page and look at their todo list. It includes styles, modified generated code, etc. all done by Motif GUI builders 5 years ago. I seem to recall that TrollTech now claims that their QT Designer is a "real GUI Builder" in their latest release (probably don't have the exact words here, so please forgive the paraphrase) In regards to Kylix, I kind of like it. Pascal was my first computer languare. Let's drop C/C++ and switch! ;-)
In any case, the real issue here is trying to figure out how to eliminate the fork in the road. This may not be a technical decision...
Mark
I think there are some licensing issues here that are not related to the traditional KDE/QT license bashing.
To be specific, under the GPL the theory is that if you create an application that uses open source code licensed under GPL, the GPL provisions are extended to your application too.
So what about commercial applications that allow the embedding of Kparts components covered under the GPL? Does the GPL flow back or is this a mechanism that allows proprietary developers to circumvent the GPL?
Although I am not a lawyer, I would guess that the XParts architecture with the use of dcomp certainly avoids the triggering of the GPL...