TODO

TODOS Drone réunion 7 jan 2013:

GUI:

• clone with Ctrl+Move http://www.qtcentre.org/threads/46194-QGraphicsScene-clone-selected-item-by-Alt-Move

• values in tooltips ? link interessant

• stylesheets

  • see QtCreator . I did already copy them in resource/stylesheet
  • see http://doc.qt.digia.com/4.6/stylesheet-examples.html

• correct GearGUI painting so that when opacity<100% we don't have artifacts

• collapsing expert / unplugged plugs on gearGui

• [DONE jukea] setZ on top when selecting gears

• wrap selection in metagear

  • autoexpose plug to keep same logic

• [60% DONE jukea] implement different layout modes for gears (normal, noPlugName, compact, ultracompact)

• don't needlessly destroy plugs in GearGui::rebuildLayout (because it loses connections if I'm correct)

• [20% DONE jukea] restore meta gears edition

  • and implement single window edition (Quartz-style), breadcrumb at the top, possibly with "dive-in" animation on click

• add comment GUI items QuartzComposer style (savable, copyable..etc)

• [15% DONE jukea] QT4 property edition

  • Choose property edition style
  • check out: QtPropertyBrowser --and-- here is the doc
  • [DONE jukea] start by making QT3 classes work again [using emit gearSelected(gearGui);]
  • refactor to QT4 new MVC classes
  • property edition for missing types (ex: vector(foogy) with collapse icon visual studio-style)

• [10% DONE jukea] implement panels

  • usable kits :
    • http://www.behance.net/chrisfarina
    • http://www.behance.net/gallery/Pro-Audio-UI-Kit/2726145
    • http://dmonzon.com/freebies/minimal-light-user-interface-freebie/
    • http://www.plugindex.de/wp-content/uploads/2011/08/REAKTOR-PRISM.jpg
    • http://www.simsaudio.co.kr/simsv2/skin_board/k_build_home/product/infrasonic/uax2/0313b.png
    • http://graphicriver.net/item/tabletphone-ui-professional-set-bundle/222275?ref=diegomonzon
    • maybe we should use QGraphicsWidget ? Yes : QWidgets (that we would eventually use) can be embeded in QGraphicsWidgets (http://doc-snapshot.qt-project.org/4.8/qgraphicslinearlayout.html#details)
  • [DONE jukea] Refactor code to separate controller from GearGui (instead of controller inheriting GearGui)
  • see 2 instance of same widget : http://qt-project.org/forums/viewthread/15385 http://stackoverflow.com/questions/7042799/showing-the-same-qpushbutton-on-multiple-widgets

• [75% DONE jukea] migrate Q3ListView -> QTreeWidget

  • [DONE] restore classification hierarchy
  • [DONE] restore Drag&Drop
  • Get realistic gearGUI rendering while Dragging http://lists.trolltech.com/qt4-preview-feedback/2006-09/msg00204.html
  • add visual indicators for different gearTypes (ex : MyGear[F] for a frei0r gear. With F in superscript)

• [100% DONE jukea] Isolate GUI from core

  • [DONE] restore copy/paste
  • [DONE] refactor load/save to isolate Core from GUI. XML must be able to be saved/loaded when no GUI is active. Possible way : have 2 completely separated sections in XML ? Other way: Tags (ex: GearGui, Control) that can be simply dropped by the loading mechanism of gears when core is not active?)
  • [DONE] However .. Control inherits QGraphicsWidget. Maybe just declare IControl as an interface in Core ( And why do we need to have Control from the Core anyway ?)
  • [DONE] Schema::save -> it asks gearGuis if they are selected when copying (ctrl-C).
  • [DONE] Schema::load -> When pasting, it selects all gears afterwards
  • [DONE] MetaGear & Gear -> createGui should not be called from there
  • [DONE] MetaGear::createPlugs calls GearGUI->rebuidLayout -> should emit a signal instead)

• merge gear & metaGear classification in gear picker list

• [100% DONE foogy-magical branch] classification & gearInfo : no more hardcoded stuff. Only through an XML "manifesto" per gear (gear name, desc, link to example schema, plug descriptions)

• [90% DONE jukea] clean remaining std::stuff

• renaming gears by doubleclicking on their titlebar

• [100% DONE jukea] undo stack

  • [DONE jukea] moving stuff around
  • [DONE jukea]add connections
  • [DONE jukea]delete connections
  • [DONE jukea]add gear
  • [DONE jukea]delete gear
  • [DONE jukea]paste

• [50% DONE jukea] delete selected stuff

• [60% DONE jukea] copy/paste. TODO :

  • [DONE jukea]paste somewhere else than exactly over source .. !
  • [DONE jukea]weird bug when pasting where some of the pasted gears are cluttered at (0,0)
  • [DONE jukea]remove "QGraphicsScene::addItem: item has already been added to this scene"

• [40% DONE jukea] while running, opacity=50% for sleeping (unready) gears

  • visual updates are not done correctly

• optimize rendering speed

  • http://blog.qt.digia.com/blog/2010/01/11/qt-graphics-and-performance-the-cost-of-convenience/
  • http://blog.qt.digia.com/blog/2008/05/12/qwidget-vs-graphics-view-ding-ding-ding/

Plugs / connections : refactoring

• refine and implement new rules for connections (can connect A->B if B is subclass of A)

  • see QObject's :
    • inline bool inherits(const char *classname) const
    • { return const_cast<QObject *>(this)->qt_metacast(classname) != 0; }

• changing plug numbers/type at runtime

• défine what can be changed at runtime

Types:

• remove depracted subtype stuff
• incoherence between "IsA" et "HasA" (ex : value vs array)
• specify the "final" list of types
• 2d vs 3d .. single type or 2 types?

Gears:

• Solve this conflict : gearinfo XMLs get updated to match the gear structural modification (at least for Plugs , maybe more), but the modified version is the one in the "installed plugins directory". Not the developpement version.

• Q_OBJECTness :

  • Currently, Gears inheriting class Gear don'T have the Q_OBJECT Macro, consider this :
  • While it is possible to use QObject as a base class without the Q_OBJECT macro and without meta-object code, neither signals and slots nor the other features described here will be available if the Q_OBJECT macro is not used. From the meta-object system's point of view, a QObject subclass without meta code is equivalent to its closest ancestor with meta-object code. This means for example, that QMetaObject::className() will not return the actual name of your class, but the class name of this ancestor.

• code a scriptingGear (probably using QScript?)

  • references:
  • http://doc.qt.digia.com/qq/qq02-fun-fast-and-flexible-qt-script.html
  • http://www.java2s.com/Questions_And_Answers/Qt/Development/qtscript.htm

• import d'effets audio de PD

  • Intégration de libPD: https://github.com/libpd

Other :

• sanitize terminology, rename some concepts, while keeping a hint of drone-flavor (let's keep Gear, at least? pretty please?) . C.f : https://wikifarm.koumbit.net/orangeseeds/drone/Core/Drone0.4/Nomenclature

Engine :

• refactor unique gear names by concatening with a random hash instead of incremented integers
  • seems safer for undo stack, which could cause names collisions
• Make some system so gears can throw an error/warning (And the GUI counterpart)
• ISchemaEventListener ... what's this ? why not signal/slot instead ?
• Copy vs Reference …. ex : for the scene type (3d). Do element selectors copy to next gear of pass references to subset of the data?
• scene -> julien imagines a DOM-style datatype with selection gears( à la jQuery) that return subsets containing references to elements. Doesn't suit dataflow programming so well thought… Tats propose de faire une copie pour tout split d'output (fournir une copie pour les connection 2..3..4..N )
• connection with type casting : implement a mecanism that create a default conversion gear for the types
• implement something like vvvv's spreads
• clarify sleeping plugs ... (Tats -> sleep state travels toward beginning of graph, which is the other way around currently. (can route to a single subgraph using 1 select gear with Tats way of doing) .. also : "This is a very comprehensive article on dataflow programming. Section 2 is very interesting. There's even graphics about switch and merge "gears" which are more or less what Julien and I were discussing about tonight. http://www.cs.ucf.edu/~dcm/Teaching/COT4810-Spring2011/Literature/DataFlowProgrammingLanguages.pdf Also cf. pp 5 and 6: data-driven approach vs demand-driven approach which are exactly the two models Julien and I were opposing tonight."