Linked by Thom Holwerda on Mon 16th Feb 2009 14:07 UTC
Thread beginning with comment 349425
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
You seem to by implying that it's not possible to create an image compositor like Shake with a native toolkit like QT or GTK. I don't buy it.
Sure you could re-implement Shake in Qt today, but Qt was a lot more primitive when Shake was written. Given the tools available, I think they did the right thing going with a custom toolkit. Would they have started today I doubt they would have made the same choice, but hopefully they would have kept the same UI and design.
Also by writing, for example, a custom file selector optimized for the job, rather than relying on the default platform one, they made the app a lot easier to use. Admittedly at the cost of it taking a few minutes to fully get the hang of, but in my book that is a tiny price to pay. Sometimes it's worth writing a specialized widget to solve a specialized task. For large apps used in isolation I think harder to learn is worthwhile price to pay for easier to use.
RE[7]: All guis the same
by abraxas on Tue 17th Feb 2009 13:11
in reply to "RE[6]: All guis the same"
Sure you could re-implement Shake in Qt today, but Qt was a lot more primitive when Shake was written. Given the tools available, I think they did the right thing going with a custom toolkit. Would they have started today I doubt they would have made the same choice, but hopefully they would have kept the same UI and design.
I already said I'm not arguing for Shake to get a new UI. This doesn't have anything to do with Shake specifically.
Also by writing, for example, a custom file selector optimized for the job, rather than relying on the default platform one, they made the app a lot easier to use. Admittedly at the cost of it taking a few minutes to fully get the hang of, but in my book that is a tiny price to pay. Sometimes it's worth writing a specialized widget to solve a specialized task. For large apps used in isolation I think harder to learn is worthwhile price to pay for easier to use.
Hmmm. I did say that it is okay to stray from the conventions when it is needed but sticking as closely to them as possible makes thing a lot easier for an end-user. I'm not so stubborn as to expect strict guidelines that never can be broken but making something different for the sake of being different is not something we need.




Member since:
2005-07-07
I'm not tyring to make the argument that Shake needs to use a different toolkit, just that a completely custom toolkit is not necessary and often confusing. You seem to by implying that it's not possible to create an image compositor like Shake with a native toolkit like QT or GTK. I don't buy it.