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

• 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

• [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)

• 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

  • [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)

• implement panels

  • maybe we should use QGraphicsWidget ?
  • 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

• Isolate GUI from core

  • Schema::save -> it asks gearGuis if they are selected when copying (ctrl-C).
  • Schema::load -> When pasting, it selects all gears afterwards
  • MetaGear & Gear -> createGui should not be called from there
  • MetaGear::createPlugs calls GearGUI->rebuidLayout -> should emit a signal instead)

• merge gear & metaGear classification in gear picker list

• classification & gearInfo : no more hardcoded stuff. Only through an XML "manifesto" per gear (gear name, desc, link to example schema, plug descriptions)

• renaming gears by doubleclicking on them

• [15% DONE jukea] undo stack

  • [DONE jukea] moving stuff
  • add connections
  • delete connections
  • add gear
  • delete gear
  • paste
  • property edit
  • rename gear

• [50% DONE jukea] delete selected stuff

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

  • paste somewhere else than exactly over source .. !
  • maybe refactor code? : all Gui Items should inherit from some interface (serializable ?) so we can iterate and save without knowing each type
  • weird bug when pasting where some of the pasted gears are cluttered at (0,0)
  • 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

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:

• 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

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."