Hi, > Apologies for not replying earlier, I've been quite busy these last two > days.
No worries ;-) > So far I have been exploring the advantages/disadvantages of using > QML/QtQuick vs traditional widget based GUI. QML has some great design > features that could improve the overall user experience and aren't > easily implemented when using widgets. I was originally planning to > develop some parts using QML ( animations and charts ) and integrate > them with the main widget based GUI. However I am now exploring the > possibility of doing the entire GUI in QML. Suggestions on which > approach to choose are welcome. From Wikipedia: "QML (Qt Meta Language or Qt Modeling Language) is a User interface markup language. It is a JavaScript-based, declarative language for designing user interface–centric applications. (...) QML elements can be augmented by standard JavaScript both inline and via included .js files" I'm actually hesitant to build such a benchmark-GUI in a meta language, because essential parts of the actual benchmarking is done in C++, so you would unnecessarily end up with two languages (C++ and QML) rather than one. Then there's also an aspect of maintainability: Here in Vienna we started the development of our semiconductor device simulator GUIs in Qt. Thus, we can contribute to the maintenance of a benchmark GUI if it is written in 'plain Qt', but we will have a much harder time doing so if it is written in QML. > Reading through your discussion about expert benchmark setting I see > that I probably should have spent more time studying the autotuner and > benchmark codes :/ I understand that there is a great need for expert > benchmark customization and I hope to succeed in making that part as > detailed as possible, but there should a certain limit to the extent of > details. What I'm saying is I'd rather not spend time developing > features that will be used only a couple of times. Surely there are some > details that aren't of critical importance? You covered the important functionality already in your GSoC proposal. This is what you should focus on, the expert mode is icing on the cake on is certainly not crucial for a first release. I'm convinced that additional input and ideas will show up while coding up the GUI for the standard use case, so we cannot fully specify the expert features right now anyway... > It would be great if you guys could agree on what expert details are of > greatest priority. I'm going to start studying the autotuner and > benchmark codes so I can better understand what needs to be done. I think it's most efficient to either have a Skype session about it or to meet in IRC to discuss. I'll be on travel the next days, but I'll propose some time slot in the second half of next week. Best regards, Karli ------------------------------------------------------------------------------ Is your legacy SCM system holding you back? Join Perforce May 7 to find out: • 3 signs your SCM is hindering your productivity • Requirements for releasing software faster • Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce _______________________________________________ ViennaCL-devel mailing list ViennaCL-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viennacl-devel
