I always think that such statements are flawed because you cannot drive innovation on a controlled environment as much as on an open environment. The console, a closed platform, does not let developers think outside of the box. On the other hand, a pc has an open architecture allowing external innovation to merge into itself. This gives a richer, freer development environment to the game developer. That's why all major innovation in computer gaming has appeared on the pc first. This will not change until the pc becomes the console. The media center is a good attempt at this.
But you have full access to the catalog for on-demand listening, plus all the niceties that comes with the service. I have been using Rhapsody for a while now and its just amazing by itself, with or without the ability to burn. Looking at it in another way, you can sample the full song before commiting to buying it, not just short 30sec clips.
I tried. I really tried. Honest to God, but motif is just not functionnal enough for serious development, although the only logical choice.
For instance, it is more then toolkit, it's a framework. Sounds like a silly limitation ? not really. First of all, Fountain speaks of it in terms of a framework he says things like "As a language, Motif does show its age". This innocent statement is very heavy in meaning. I wouldn't say that of an api, only of a framework. And to that extent, the Motif toolkits wraps alot of Xt calls, trying like hell to not have you code with Xt at all, and denying you alot of Xt's functionnality.
A framework ties you in so tightly with the application you write that you cannot really extend the functionnality the framework offers other then within the bounds the framework allows you to go.
In other words, use of any motif components locks you in the motif way of doing things and you can only extend it a very high price.
Fountain claims that having had motif built on Xt is a good thing for the component architecture of motif. True, but Motif ties in on Xt by locking out the developper of several useful Xt functionnality, basically, an application writer using Motif is limited to a subset of Xt (and Xlib for that matter) for working on components without wrecking havoc on the motif app.
Fountains speaks of wrapping motif in C++ front-ends to facilitate use of the toolkit. Sure, but to what end ? It is a common practice to find in software development businesses wrappers around several lib's or toolkits they use to offer a common front end to the application writers, a practice that aims at decoupling the application from the toolkits: an honest effort.
The problem with this is that you still are locked in with the motif way of doing things. If you intend to develop an other type of component that you would wish to interact in the motif toolkit and perhaps another toolkit, you will find yourself running into a brick wall. It is possible, I am doing it right now, but the cost of making this work is far to great for the end result. It is like writing a framework with a framework. This is possible if the frameworks are orthogonal ( do not step over each other in functionnality, in which case you are effectively merging frameworks ), but in the most common case, a business wants to develop its own api/framework, in which case, using motif makes it a daunting task, virtually impossible.
This is examplified by the premise of a framework: "dont call me, I will call you" idiom. Build a framework on another one and you will find yourself coding loops and loops around motif to overcome the difficulty of not being able to control it like you need to.
I haven't use Qt or GTK, but in my opinion, the success of any of these two will be if they offer an good api without any framework functionnality. The framework functionnality should be another separate layer that you can use or not, depending on your needs.
I will end this rant on a positive note for Motif: it is the most ported toolkit out there and it's single most strong point.
And unfortunately because of this and the fact that it's now free to get development librairies, this makes of motif the only really good choice for xplatform development for all the *nix's out there. I certainly hope that in the near future, this will change. It is, but not as fast as it should...
I always think that such statements are flawed because you cannot drive innovation on a controlled environment as much as on an open environment. The console, a closed platform, does not let developers think outside of the box. On the other hand, a pc has an open architecture allowing external innovation to merge into itself. This gives a richer, freer development environment to the game developer. That's why all major innovation in computer gaming has appeared on the pc first. This will not change until the pc becomes the console. The media center is a good attempt at this.
But you have full access to the catalog for on-demand listening, plus all the niceties that comes with the service. I have been using Rhapsody for a while now and its just amazing by itself, with or without the ability to burn.
Looking at it in another way, you can sample the full song before commiting to buying it, not just short 30sec clips.
I tried. I really tried. Honest to God, but motif is just not functionnal enough for serious development, although the only logical choice.
For instance, it is more then toolkit, it's a framework. Sounds like a silly limitation ? not really. First of all, Fountain speaks of it in terms of a framework he says things like "As a language, Motif does show its age". This innocent statement is very heavy in meaning. I wouldn't say that of an api, only of a framework. And to that extent, the Motif toolkits wraps alot of Xt calls, trying like hell to not have you code with Xt at all, and denying you alot of Xt's functionnality.
A framework ties you in so tightly with the application you write that you cannot really extend the functionnality the framework offers other then within the bounds the framework allows you to go.
In other words, use of any motif components locks you in the motif way of doing things and you can only extend it a very high price.
Fountain claims that having had motif built on Xt is a good thing for the component architecture of motif. True, but Motif ties in on Xt by locking out the developper of several useful Xt functionnality, basically, an application writer using Motif is limited to a subset of Xt (and Xlib for that matter) for working on components without wrecking havoc on the motif app.
Fountains speaks of wrapping motif in C++ front-ends to facilitate use of the toolkit. Sure, but to what end ? It is a common practice to find in software development businesses wrappers around several lib's or toolkits they use to offer a common front end to the application writers, a practice that aims at decoupling the application from the toolkits: an honest effort.
The problem with this is that you still are locked in with the motif way of doing things. If you intend to develop an other type of component that you would wish to interact in the motif toolkit and perhaps another toolkit, you will find yourself running into a brick wall. It is possible, I am doing it right now, but the cost of making this work is far to great for the end result. It is like writing a framework with a framework. This is possible if the frameworks are orthogonal ( do not step over each other in functionnality, in which case you are effectively merging frameworks ), but in the most common case, a business wants to develop its own api/framework, in which case, using motif makes it a daunting task, virtually impossible.
This is examplified by the premise of a framework: "dont call me, I will call you" idiom. Build a framework on another one and you will find yourself coding loops and loops around motif to overcome the difficulty of not being able to control it like you need to.
I haven't use Qt or GTK, but in my opinion, the success of any of these two will be if they offer an good api without any framework functionnality. The framework functionnality should be another separate layer that you can use or not, depending on your needs.
I will end this rant on a positive note for Motif: it is the most ported toolkit out there and it's single most strong point.
And unfortunately because of this and the fact that it's now free to get development librairies, this makes of motif the only really good choice for xplatform development for all the *nix's out there. I certainly hope that in the near future, this will change. It is, but not as fast as it should...