(1) is a user misunderstanding. Try changing your XmNfocusPolicy to XmEXPLICIT. (2) is a user misunderstanding. This is configurable in the window manager. (3) is a programmer error if this occurs. The programmer should install a WM protocol to catch window closure action and handle appropriately. NOTHING of what you object to in Motif is unsupported.
As I see it, the candidates for consideration are: (a) Better language interface. A set of public C++ classes should be devised, not contradicting the Doug Young Model, which encapsulate the C widget classes. There is considerable backwards compatability issues here: the classes should strictly separate the realization of the GUI component from the class constructor in order to provide the flexibility of programmer control required by this issue. Note that there are many widget set wrappers around developed by various individual groups, and there is also the issue of millions of lines of auto-generated C++ from GUI builders. Hence the proposed classes should not force too tight a binding: Light and portable are the keywords, I guess. (b) The Widget Set. Some of the Motif 2.1 widgets were not well directed, IMHO. Personally, I would much preferred to have seen a proper TabManager than the over-fussy Notebook. I feel the Container should probably have been three widgets, rather than one. Other than that, I think the set is fine as it stands as a basic component grouping. If you were feeling bold, an industrial strength Table might come into consideration, although the beauty of Motif here is the fact that you can just plug in one of these from the various component vendors already. I think on the whole I might leave this one to the experts. (c) Themeability. This in fact is not hard to do. If you want the Metallic look to your interface, say, throwing a suitable render table with the correct border, shadow, and highlight coloring, can already be done by hand. What might be of consideration here is the addition of a shell or display resource to auto-configure the sub-hierarchy in the given manner. Altering the general shape of the components themselves again should not be hard due to the fact that the drawing routines are all centralised within the Xme routines. For me, however, this issue is controversial. I dont believe it is entirely appropriate to mimic the interface of one platform onto another desktop, except in the circumstances where the product concerned is already closely associated with a given platform and the reflexes of the users are pre-primed. But then that's just my view. On the subject of "if only": truth is, they wanted to, even people in Sun were urging them to do it, but they couldnt: binding legal contracts didnt time out until recently, so their hands were tied. Dont blame the Open Group: throwing blame around isnt helpful: we cannot alter the history.
"Problem" ?? This, as far as commercial organisations is concerned, would be very much in its favour. It is absolutely essential that someone somewhere is directly prepared to stand up and be responsible for the software which they produce. None of this denial of warrantee you see in the open source movement. How would you feel about getting on an aircraft if you knew that the test programs for the engines were written by people who were not prepared to stand up and be counted?
Nope. Understand this. For many companies, Linux is a convenient, decent operating system which provides UNIX home working for their employees at a very competetive cost: not much more than the price of the box itself. However, the target platform for the given product is not even Linux at all. It's an HP or a Starfire back in the office. The release of Motif allows them to at last provide a consistent environment between the office (commercial UNIX) and the home environment. You may think Qt/GTK+/Linux is going to take over the world, but you are sadly mistaken. There is no way in the world that the Sun's of this world will ever adopt these things as a standard part of their supported release. Ever. Lets discuss why. For mission critical applications, which their customers support, direct responsibility is essential. Where they are coming from, software kills. Allowing any anonymous tom, dick, or harry in to hack up a toolkit on which their software depends is a damn bad idea. Open source is a direct contradiction of the guarrantees of safety which their application domains require: the open source movement should either directly accept the responsibilities which their codes necesitate, or get out. You cannot run mission critical applications using something developed on the bunch of monkeys theory. This does not invalidate the release of the sources as a contradiction of secrecy: you must differentiate between the toolkit and the product.
Certainly not. I refer to my answer above. There's just no pleasing some people: but I can assure you this is not being released just to please the open source community itself. Its very strongly for corporate reasons also. Antony Fountain.
My hands have been tied for a long while: I knew about the Open Sources, but could not refer to this fact. Hence I could only say: "Watch this Space". It does not, however, make any difference with respect to the argument of the article: you must differentiate between the purposes (products) to which a toolkit is put, and the toolkit itself. I continue to maintain that much of Motif's usage remains very much behind closed doors. Whether Motif itself is hidden is irrelevent.
Re:Qt, GTK+, Motif (as languages)
on
Motif's Not Dead
·
· Score: 1
You read me right here. Motif programmed by hand is not particularly simple compared to the likes of Qt. You do need to know what you are doing. I have been programming in X/Motif for over 10 years, and I am still learning new wrinkles. Personally, as a language (syntax on the page) I have a very soft spot for Qt indeed. Having ploughed through the sources, I can honestly say that it gives me a warm feel: I get the feeling it has been designed and written by people who have an inkling for what it is all about. Sorry chaps: GTK+ gives me no such warm feeling. to me, it reeks of hackery, and does not give me any vibes of top-down design. As a language, I therefore will freely admit to a preference for Qt over Motif. However, in terms of writing product with end users in mind, particularly in the large scale and internationalized markets, I strongly believe that the newer Linux toolkits just are not there for technical reasons, stated in the article. Qt and GTK+ may well be perfectly fine for small to medium tasks. Its when you need to scale up that things start to fall apart. Antony Fountain.
By dispensing with Xt, Qt and GTK+ can provide small lightweight components which are relatively easy to port. The big problem with this approach is the fact that in throwing out Xt, you also dispense with any attempt to provide a proper object level component model. This has very serious side effects, particulary with respect to scalability of the language. Compare and contrast with Java. In this language, I can write a GUI builder which can walk up to any bean, and dynamically query the attributes of the object, present a resource panel to the user, and from thence, generate code. I can do the same thing to a slightly lesser extent with an Xt widget based component: I can query the widget class, extract resource table data, and again present a proper resource panel for the instance of the widget class concerned. All just by dynamically poking into the widget class: all the information I need is right there in the object itself. I cannot do this for Qt or GTK+. Although Qt provides the QtWidget, this object is a specimen skeleton only: the resource tables for this component are NULL. There is no way to dynamically query a Qt/GTK+ component and deduce sufficient from the object pointer: the essential property of introspection is missing from the design. This has two consequences. Firstly, I cannot write a GUI builder (this happens to be what I do for a living) that will dynamically load third party components for the languages without providing a complete object description to the builder. But no equivalent of UIL/WML for these environments exist. Secondly, I cannot write a component which can be dynamically slotted into someones GUI builder, because there is no hook which will allow my component to talk. The component vendor and the GUI builder each needs the other, but in the absence of a component model, there is nothing which will allow them to talk. This means that anyone writing a GUI builder for the languages has to statically build in such knowledge as is required to present to the user from the start: you have to hard code what the object fails to deliver. There are other issues I have with these environments, namely to do with support for internationalization. there simply is no equivalently powered Qt/GTK+ mechanism for the XmFontList/XmRenderTable/XmString combination. The world does not all speak English: in fact, most of it doesnt. In this respect, Qt and GTK+ simply arent good enough. This has two consequences: firstly, there are upgrade issues associated with trying to keep the latest release of the base software in step with whoever provides the GUI builder. Secondly, in the absence of the professional GUI builder/third party component market, which we have already decided cannot be provided, you have no option but to either write all your code by hand, or pass control of your application to some private piece of hobbyware which masquerades as a support environment. This stuff just isnt going to scale into the professional large scale international market. You can write small to medium scale projects with it (dont get me wrong, I personally think Qt to be a very well written language indeed) but you are not going to get into the space shuttle test program domain.
Slashdot Mirror
(1) is a user misunderstanding. Try changing your XmNfocusPolicy to XmEXPLICIT. (2) is a user misunderstanding. This is configurable in the window manager. (3) is a programmer error if this occurs. The programmer should install a WM protocol to catch window closure action and handle appropriately. NOTHING of what you object to in Motif is unsupported.
As I see it, the candidates for consideration are: (a) Better language interface. A set of public C++ classes should be devised, not contradicting the Doug Young Model, which encapsulate the C widget classes. There is considerable backwards compatability issues here: the classes should strictly separate the realization of the GUI component from the class constructor in order to provide the flexibility of programmer control required by this issue. Note that there are many widget set wrappers around developed by various individual groups, and there is also the issue of millions of lines of auto-generated C++ from GUI builders. Hence the proposed classes should not force too tight a binding: Light and portable are the keywords, I guess. (b) The Widget Set. Some of the Motif 2.1 widgets were not well directed, IMHO. Personally, I would much preferred to have seen a proper TabManager than the over-fussy Notebook. I feel the Container should probably have been three widgets, rather than one. Other than that, I think the set is fine as it stands as a basic component grouping. If you were feeling bold, an industrial strength Table might come into consideration, although the beauty of Motif here is the fact that you can just plug in one of these from the various component vendors already. I think on the whole I might leave this one to the experts. (c) Themeability. This in fact is not hard to do. If you want the Metallic look to your interface, say, throwing a suitable render table with the correct border, shadow, and highlight coloring, can already be done by hand. What might be of consideration here is the addition of a shell or display resource to auto-configure the sub-hierarchy in the given manner. Altering the general shape of the components themselves again should not be hard due to the fact that the drawing routines are all centralised within the Xme routines. For me, however, this issue is controversial. I dont believe it is entirely appropriate to mimic the interface of one platform onto another desktop, except in the circumstances where the product concerned is already closely associated with a given platform and the reflexes of the users are pre-primed. But then that's just my view. On the subject of "if only": truth is, they wanted to, even people in Sun were urging them to do it, but they couldnt: binding legal contracts didnt time out until recently, so their hands were tied. Dont blame the Open Group: throwing blame around isnt helpful: we cannot alter the history.
"Problem" ?? This, as far as commercial organisations is concerned, would be very much in its favour. It is absolutely essential that someone somewhere is directly prepared to stand up and be responsible for the software which they produce. None of this denial of warrantee you see in the open source movement. How would you feel about getting on an aircraft if you knew that the test programs for the engines were written by people who were not prepared to stand up and be counted?
Nope. Understand this. For many companies, Linux is a convenient, decent operating system which provides UNIX home working for their employees at a very competetive cost: not much more than the price of the box itself. However, the target platform for the given product is not even Linux at all. It's an HP or a Starfire back in the office. The release of Motif allows them to at last provide a consistent environment between the office (commercial UNIX) and the home environment. You may think Qt/GTK+/Linux is going to take over the world, but you are sadly mistaken. There is no way in the world that the Sun's of this world will ever adopt these things as a standard part of their supported release. Ever. Lets discuss why. For mission critical applications, which their customers support, direct responsibility is essential. Where they are coming from, software kills. Allowing any anonymous tom, dick, or harry in to hack up a toolkit on which their software depends is a damn bad idea. Open source is a direct contradiction of the guarrantees of safety which their application domains require: the open source movement should either directly accept the responsibilities which their codes necesitate, or get out. You cannot run mission critical applications using something developed on the bunch of monkeys theory. This does not invalidate the release of the sources as a contradiction of secrecy: you must differentiate between the toolkit and the product.
Certainly not. I refer to my answer above. There's just no pleasing some people: but I can assure you this is not being released just to please the open source community itself. Its very strongly for corporate reasons also. Antony Fountain.
My hands have been tied for a long while: I knew about the Open Sources, but could not refer to this fact. Hence I could only say: "Watch this Space". It does not, however, make any difference with respect to the argument of the article: you must differentiate between the purposes (products) to which a toolkit is put, and the toolkit itself. I continue to maintain that much of Motif's usage remains very much behind closed doors. Whether Motif itself is hidden is irrelevent.
You read me right here. Motif programmed by hand is not particularly simple compared to the likes of Qt. You do need to know what you are doing. I have been programming in X/Motif for over 10 years, and I am still learning new wrinkles. Personally, as a language (syntax on the page) I have a very soft spot for Qt indeed. Having ploughed through the sources, I can honestly say that it gives me a warm feel: I get the feeling it has been designed and written by people who have an inkling for what it is all about. Sorry chaps: GTK+ gives me no such warm feeling. to me, it reeks of hackery, and does not give me any vibes of top-down design. As a language, I therefore will freely admit to a preference for Qt over Motif. However, in terms of writing product with end users in mind, particularly in the large scale and internationalized markets, I strongly believe that the newer Linux toolkits just are not there for technical reasons, stated in the article. Qt and GTK+ may well be perfectly fine for small to medium tasks. Its when you need to scale up that things start to fall apart. Antony Fountain.
By dispensing with Xt, Qt and GTK+ can provide small lightweight components which are relatively easy to port. The big problem with this approach is the fact that in throwing out Xt, you also dispense with any attempt to provide a proper object level component model. This has very serious side effects, particulary with respect to scalability of the language. Compare and contrast with Java. In this language, I can write a GUI builder which can walk up to any bean, and dynamically query the attributes of the object, present a resource panel to the user, and from thence, generate code. I can do the same thing to a slightly lesser extent with an Xt widget based component: I can query the widget class, extract resource table data, and again present a proper resource panel for the instance of the widget class concerned. All just by dynamically poking into the widget class: all the information I need is right there in the object itself. I cannot do this for Qt or GTK+. Although Qt provides the QtWidget, this object is a specimen skeleton only: the resource tables for this component are NULL. There is no way to dynamically query a Qt/GTK+ component and deduce sufficient from the object pointer: the essential property of introspection is missing from the design. This has two consequences. Firstly, I cannot write a GUI builder (this happens to be what I do for a living) that will dynamically load third party components for the languages without providing a complete object description to the builder. But no equivalent of UIL/WML for these environments exist. Secondly, I cannot write a component which can be dynamically slotted into someones GUI builder, because there is no hook which will allow my component to talk. The component vendor and the GUI builder each needs the other, but in the absence of a component model, there is nothing which will allow them to talk. This means that anyone writing a GUI builder for the languages has to statically build in such knowledge as is required to present to the user from the start: you have to hard code what the object fails to deliver. There are other issues I have with these environments, namely to do with support for internationalization. there simply is no equivalently powered Qt/GTK+ mechanism for the XmFontList/XmRenderTable/XmString combination. The world does not all speak English: in fact, most of it doesnt. In this respect, Qt and GTK+ simply arent good enough. This has two consequences: firstly, there are upgrade issues associated with trying to keep the latest release of the base software in step with whoever provides the GUI builder. Secondly, in the absence of the professional GUI builder/third party component market, which we have already decided cannot be provided, you have no option but to either write all your code by hand, or pass control of your application to some private piece of hobbyware which masquerades as a support environment. This stuff just isnt going to scale into the professional large scale international market. You can write small to medium scale projects with it (dont get me wrong, I personally think Qt to be a very well written language indeed) but you are not going to get into the space shuttle test program domain.