簡(jiǎn)介一套完整的Qt甘特圖組件源碼GanttMel-master 項(xiàng)目面向需要在桌面應(yīng)用中展示任務(wù)時(shí)間線、項(xiàng)目進(jìn)度或進(jìn)行項(xiàng)目調(diào)度的Qt開發(fā)者及相關(guān)學(xué)習(xí)者。資源包共27個(gè)文件主要包含C源代碼cpp/h、Qt界面文件ui、Visual Studio工程文件sln/vcxproj以及可執(zhí)行程序exe和說明文檔md整體僅約1.69MB便于快速下載與編譯研究。已有859人學(xué)習(xí)/瀏覽特別適合用來研究QGraphicsView框架下的自定義繪圖、模型-視圖-控制器MVC數(shù)據(jù)綁定、時(shí)間軸坐標(biāo)轉(zhuǎn)換、事件處理與動(dòng)畫過渡、布局滾動(dòng)與資源管理等關(guān)鍵機(jī)制的工程化實(shí)現(xiàn)。通過閱讀源碼可掌握如何重寫paint()方法繪制任務(wù)條形、將日期時(shí)間映射為像素坐標(biāo)、監(jiān)聽鼠標(biāo)鍵盤事件實(shí)現(xiàn)拖動(dòng)與縮放并能將該組件遷移或直接集成到現(xiàn)有Qt項(xiàng)目管理界面中同時(shí)工程附帶可執(zhí)行程序便于對(duì)照查看運(yùn)行效果也可基于此版本繼續(xù)擴(kuò)展里程碑、任務(wù)依賴等高級(jí)功能。 做Qt上位機(jī)或者項(xiàng)目管理系統(tǒng)總會(huì)遇到一個(gè)繞不開的需求甘特圖。Qt官方?jīng)]有一套開箱即用的甘特圖控件第三方庫(kù)又普遍偏輕量遇到真實(shí)業(yè)務(wù)里的拖拽改期、里程碑、任務(wù)依賴、跨泳道移動(dòng)基本都得自己動(dòng)手。我第一次做這功能時(shí)圖省事基于QTableWidget加委托繪制上線跑了半年問題越積越多最后忍無可忍用QGraphicsView體系重寫了一套這就是標(biāo)題里說的“另一個(gè)版本”。這篇記錄的就是整個(gè)重寫過程從第一版為什么扛不住到第二版怎么拆架構(gòu)、寫交互、調(diào)性能再到打包發(fā)布時(shí)踩過的坑給同樣在Qt里做甘特圖或同類自定義控件的同學(xué)做個(gè)參考。如果你只是想畫個(gè)靜態(tài)展示的條狀圖用QTableWidget甚至直接在paintEvent里畫都?jí)蛴?。但一旦涉及大量任?wù)、拖動(dòng)、縮放這類高頻交互那套方案會(huì)讓你越改越難受。下面我把兩版的差異、關(guān)鍵數(shù)據(jù)結(jié)構(gòu)和實(shí)際踩坑細(xì)節(jié)攤開講清楚。1. 第一版甘特圖被淘汰的原因QTableWidget方案的三個(gè)硬傷1.1 數(shù)據(jù)量一上去刷新就肉眼可見地卡第一版實(shí)現(xiàn)很直接QTableWidget每個(gè)任務(wù)占一行固定列寬表示一天任務(wù)條通過QStyledItemDelegate在單元格里畫出來。任務(wù)在幾十條以內(nèi)時(shí)看不出問題一旦到了幾百條任務(wù)、跨三四年時(shí)間軸卡頓立刻就來了。QTableWidget是按“單元格”管理的控件滾動(dòng)、縮放、編輯任意一個(gè)單元格都可能觸發(fā)整片視口重繪你的任務(wù)條繪制邏輯會(huì)被反反復(fù)復(fù)調(diào)用而其中大部分其實(shí)根本不在可見區(qū)域。更要命的是第一版把“日期”映射到了“列寬”想做按小時(shí)排程就得把列寬縮到很小可任務(wù)名稱又要占據(jù)一列寬度整張表就會(huì)變得非常怪異。后來我意識(shí)到用表格的行列結(jié)構(gòu)去模擬時(shí)間軸本質(zhì)上就是拿錯(cuò)誤的數(shù)據(jù)模型硬湊視圖需求越往后越疼。1.2 拖拽改期和跨泳道移動(dòng)事件處理繞到懷疑人生第一版的需求還沒那么復(fù)雜只要求任務(wù)條能拖動(dòng)改期、能從一個(gè)泳道挪到另一個(gè)泳道。QTableWidget上做這件事要么重寫viewportEvent要么在單元格里塞定時(shí)器加鼠標(biāo)跟蹤自己去判斷鼠標(biāo)是不是拖到了邊緣、要不要自動(dòng)滾動(dòng)、當(dāng)前懸停的是哪一行。尤其當(dāng)任務(wù)條只占單元格的一部分時(shí)hitTest邏輯非常別扭鼠標(biāo)事件還會(huì)被ItemDelegate截走處理優(yōu)先級(jí)亂七八糟。我記得當(dāng)時(shí)為了做“拖到視口邊緣自動(dòng)滾動(dòng)”這個(gè)功能前后改了兩個(gè)星期。每次滾動(dòng)都觸發(fā)update()然后update()又觸發(fā)繪制繪制里又去做命中判斷整個(gè)事件循環(huán)像一團(tuán)亂麻。最終雖然能跑但代碼里全是補(bǔ)丁任何一個(gè)新需求進(jìn)來都會(huì)牽一發(fā)動(dòng)全身。1.3 重新選型時(shí)的方案對(duì)比第二次動(dòng)手之前我認(rèn)真列了一遍候選方案包括繼續(xù)在QWidget子類里自繪、用QCustomPlot硬畫、以及徹底轉(zhuǎn)QGraphicsScene。對(duì)比下來結(jié)論相當(dāng)明確方案繪制方式交互復(fù)雜度大數(shù)據(jù)量表現(xiàn)適用場(chǎng)景QTableWidget Delegate單元格重繪難做拖拽/縮放數(shù)千條以上吃力簡(jiǎn)單排程、只讀展示QWidget::paintEvent全量自繪中等滾屏需自己優(yōu)化全量重繪時(shí)會(huì)卡靜態(tài)圖表QGraphicsScene/ViewItem局部更新拖拽、命中、局部刷新都很順手幾千到幾萬可控制需高頻交互的自定義圖QCustomPlot圖層化數(shù)據(jù)曲線不適合做任務(wù)條拖拽大數(shù)組曲線很優(yōu)秀波形、頻譜等數(shù)據(jù)圖QCustomPlot畫波形和頻譜確實(shí)強(qiáng)我也在同一套上位機(jī)軟件里拿它做了串口數(shù)據(jù)的時(shí)域波形和頻域分析但拿它做甘特圖這種需要逐任務(wù)響應(yīng)鼠標(biāo)事件的場(chǎng)景遠(yuǎn)不如QGraphicsScene自然。場(chǎng)景框架本身提供了item級(jí)緩存、碰撞檢測(cè)和局部更新相當(dāng)于把最難的渲染調(diào)度問題先解決了一半。2. 第二版甘特圖的骨架設(shè)計(jì)場(chǎng)景、泳道、任務(wù)條怎么分層2.1 三個(gè)核心類的劃分與職責(zé)第二版架構(gòu)我分成三層最外層是GanttView繼承QGraphicsView負(fù)責(zé)處理縮放、滾動(dòng)、坐標(biāo)換算中間層是QGraphicsScene只做item管理和事件轉(zhuǎn)發(fā)最內(nèi)層是若干個(gè)QGraphicsObject派生類包括時(shí)間軸TimeRulerItem、泳道背景LaneItem、任務(wù)條TaskItem、依賴箭頭DependencyItem。這里最關(guān)鍵的一個(gè)決策是業(yè)務(wù)數(shù)據(jù)模型和視圖item徹底分離。我在數(shù)據(jù)層定義一個(gè)Task結(jié)構(gòu)體里面只存任務(wù)id、父任務(wù)id、名稱、開始日期、持續(xù)天數(shù)、進(jìn)度、所屬泳道等字段完全不存任何像素坐標(biāo)。視圖層的TaskItem持有Task的指針或副本所有位置信息在paint和布局時(shí)臨時(shí)計(jì)算。struct Task { int id; int parentId; QString name; QDate startDate; int durationDays; int progress; // 0~100 int laneId; QListint dependOn; };這樣做的好處是縮放時(shí)間軸時(shí)任務(wù)條的位置全部根據(jù)新的dayWidth重新計(jì)算不用去改數(shù)據(jù)保存項(xiàng)目時(shí)直接把Task序列化成JSON就行不用從item一個(gè)字段一個(gè)字段往回?fù)浮?.2 日期-像素坐標(biāo)換算甘特圖的“計(jì)量單位”要統(tǒng)一甘特圖所有繪制和交互的基礎(chǔ)就是日期和像素之間的換算。我在GanttView里維護(hù)兩個(gè)核心變量m_beginDate時(shí)間軸起點(diǎn)日期和m_dayWidth每個(gè)像素對(duì)應(yīng)的天數(shù)縮放時(shí)改變。qreal GanttView::dateToX(const QDate date) const { return m_beginDate.daysTo(date) * m_dayWidth; } QDate GanttView::xToDate(qreal x) const { return m_beginDate.addDays(static_castint(x / m_dayWidth)); }這里有個(gè)細(xì)節(jié)值得注意換算時(shí)統(tǒng)一用“天”做單位不要混用小時(shí)、月。如果需求里有精確到小時(shí)的排程你可以把基準(zhǔn)時(shí)間改成分鐘但整個(gè)視圖里所有換算都必須走同一個(gè)函數(shù)絕不允許在業(yè)務(wù)代碼里到處直接寫x date.dayOfYear() * 18這種裸計(jì)算。我第一版就吃過這種虧三處代碼分別用日、周、月做軸最后拼在一起完全對(duì)不上。任務(wù)條寬度就是durationDays * m_dayWidth起點(diǎn)就是dateToX(startDate)。數(shù)據(jù)發(fā)生變化時(shí)只需要調(diào)用一次TaskItem::updateGeometry()所有位置都能同步。2.3 任務(wù)條繪制細(xì)節(jié)進(jìn)度、里程碑、依賴關(guān)系怎么畫TaskItem繼承QGraphicsObject重寫boundingRect()和paint()。boundingRect()里除了任務(wù)條本身的矩形還向外擴(kuò)幾個(gè)像素不然抗鋸齒產(chǎn)生的邊緣會(huì)被裁剪掉看起來像毛邊。繪制任務(wù)條主體的代碼大致是這樣void TaskItem::paint(QPainter *painter, const QStyleOptionGraphicsItem *option, QWidget *widget) { Q_UNUSED(option); Q_UNUSED(widget); const QRectF barRect boundingRect().adjusted(1, 1, -1, -1); painter-setPen(QPen(QColor(#3B82F6), 1.0)); painter-setBrush(QColor(#EFF6FF)); painter-drawRoundedRect(barRect, 4.0, 4.0); // 進(jìn)度填充 QRectF progressRect barRect; progressRect.setWidth(barRect.width() * m_task.progress / 100.0); painter-setBrush(QColor(#3B82F6)); painter-drawRoundedRect(progressRect, 4.0, 4.0); // 里程碑畫成菱形 if (m_task.durationDays 0) { painter-setBrush(QColor(#F59E0B)); painter-drawPolygon(milestonePoints()); } }進(jìn)度、里程碑、依賴箭頭的顏色和形狀盡量做成可配置項(xiàng)不要在繪制代碼里散落幾十個(gè)魔法值。QPen、QBrush這類對(duì)象創(chuàng)建開銷也不小高頻繪制時(shí)能提為成員就提為成員能緩存就緩存。依賴關(guān)系我用獨(dú)立的DependencyItem做負(fù)責(zé)在父任務(wù)尾部畫一條線連到子任務(wù)頭部帶箭頭。這個(gè)item不用QGraphicsPathItem重寫而是直接在paint里用QPainterPath畫貝塞爾曲線好處是保存、更新、命中檢測(cè)比較統(tǒng)一后續(xù)要加“依賴類型”FS、SS、FF也好擴(kuò)展。3. 把交互做順手拖拽、縮放、編輯器的實(shí)現(xiàn)與防坑3.1 任務(wù)條拖拽移動(dòng)、改期、跨泳道拖拽是甘特圖交互的核心。TaskItem重新實(shí)現(xiàn)三個(gè)鼠標(biāo)事件注意所有坐標(biāo)盡量用scene坐標(biāo)不要用視圖坐標(biāo)否則滾動(dòng)時(shí)會(huì)產(chǎn)生偏移。void TaskItem::mousePressEvent(QGraphicsSceneMouseEvent *event) { m_dragOffsetX event-scenePos().x() - scenePos().x(); m_originalStartDate m_task.startDate; m_originalLaneId m_task.laneId; setCursor(Qt::ClosedHandCursor); event-accept(); } void TaskItem::mouseMoveEvent(QGraphicsSceneMouseEvent *event) { QPointF scenePos event-scenePos(); qreal newX scenePos.x() - m_dragOffsetX; int dayOffset m_view-xToDate(newX).daysTo(m_originalStartDate); if (!m_snapToDay) { dayOffset qRound(scenePos.x() / m_view-dayWidth()); dayOffset m_originalStartDate.daysTo(m_view-beginDate()) dayOffset; } QDate newStart m_originalStartDate.addDays(dayOffset); setStartDate(newStart, /* notifyData */ false); // 跨泳道判斷 if (LaneItem *lane m_view-laneAtY(scenePos.y())) { setY(lane-contentTop() m_task.laneId * lane-height()); m_task.laneId lane-laneId(); } event-accept(); } void TaskItem::mouseReleaseEvent(QGraphicsSceneMouseEvent *event) { setCursor(Qt::ArrowCursor); if (m_task.startDate ! m_originalStartDate || m_task.laneId ! m_originalLaneId) { emit taskChanged(m_task); } event-accept(); }拖拽過程中我先不修改底層數(shù)據(jù)庫(kù)只更新item顯示等鼠標(biāo)釋放那一刻確認(rèn)確實(shí)有變化再發(fā)信號(hào)出去。這里有個(gè)很微妙的點(diǎn)拖拽事件里如果每次都把數(shù)據(jù)寫到持久層會(huì)造成大量無意義的保存操作還不能撤銷。做成“釋放時(shí)統(tǒng)一提交”之后配合重做棧就很舒服。跨泳道移動(dòng)我采用實(shí)時(shí)吸附在mouseMoveEvent里查鼠標(biāo)當(dāng)前位置下的LaneItem只要換行了就更新y坐標(biāo)。泳道的y用固定行高乘泳道序號(hào)計(jì)算不依賴泳道item內(nèi)部復(fù)雜的padding這樣即使某條泳道高度不同也能正確落位。3.2 時(shí)間縮放與滾動(dòng)聯(lián)動(dòng)縮放邏輯放在GanttView::wheelEvent里用Ctrl滾輪觸發(fā)因?yàn)楦侍貓D本身用滾輪滾動(dòng)很頻繁不能占用普通滾輪事件。void GanttView::wheelEvent(QWheelEvent *event) { if (event-modifiers() Qt::ControlModifier) { const double factor event-angleDelta().y() 0 ? 1.25 : 0.8; const double newDayWidth qBound(2.0, m_dayWidth * factor, 40.0); if (qFuzzyCompare(newDayWidth, m_dayWidth)) return; QPointF anchor mapToScene(event-position().toPoint()); QDate anchorDate xToDate(anchor.x()); m_dayWidth newDayWidth; layoutItems(); // 讓所有任務(wù)條按新寬度重排 updateTimeRuler(); // 讓鼠標(biāo)所在位置對(duì)應(yīng)的日期保持不動(dòng)避免縮放后視角亂跳 qreal newAnchorX dateToX(anchorDate); horizontalScrollBar()-setValue( static_castint(newAnchorX - anchor.x())); event-accept(); return; } QGraphicsView::wheelEvent(event); }以鼠標(biāo)位置為錨點(diǎn)這個(gè)細(xì)節(jié)特別重要。不加錨點(diǎn)時(shí)每次縮放當(dāng)前視野就會(huì)跳走用戶需要反復(fù)拖動(dòng)滾動(dòng)條才能回到原來在看的區(qū)域體感很差。加完錨點(diǎn)之后縮放手感接近地圖App用戶會(huì)很自然地把注意力放在鼠標(biāo)指向的那個(gè)任務(wù)上。縮放時(shí)任務(wù)條的刷新策略我采用的是重新計(jì)算全局dayWidth后遍歷現(xiàn)有item調(diào)用prepareGeometryChange()再批量update()。不要用view-scale()去整體縮放畫布那樣雖然位置能變但文字、線條會(huì)模糊而且item的boundingRect和實(shí)際顯示區(qū)域會(huì)錯(cuò)位。3.3 “點(diǎn)兩下改名”和內(nèi)部編輯器的焦點(diǎn)控制在視圖內(nèi)直接編輯任務(wù)名我用的是“雙擊一個(gè)TaskItem后在任務(wù)條上方臨時(shí)創(chuàng)建一個(gè)QLineEdit”的方案。直接scene()-addWidget()彈出來的編輯框在Qt 5.15上經(jīng)常遇到輸入法彈出、焦點(diǎn)亂跳的問題特別是中文輸入場(chǎng)景下很容易崩。后來我改成讓編輯框公用一個(gè)QGraphicsProxyWidget雙擊時(shí)移動(dòng)到目標(biāo)item位置并顯示編輯完隱藏而不是每次銷毀重建。還有一個(gè)坑是TaskItem雙擊進(jìn)入編輯狀態(tài)后鼠標(biāo)拖拽邏輯會(huì)和編輯框焦點(diǎn)沖突。我的處理是進(jìn)入編輯時(shí)給那個(gè)TaskItem掛一個(gè)Qt::WidgetWithChildren不響應(yīng)鼠標(biāo)的flag退出編輯再恢復(fù)避免用戶在編輯框里選中文字時(shí)誤觸發(fā)任務(wù)條拖拽。這套邏輯雖然小但踩過坑的人都會(huì)知道有多煩。4. 性能優(yōu)化幾千個(gè)任務(wù)節(jié)點(diǎn)不卡的做法4.1 渲染瓶頸核心避免無效更新很多人覺得甘特圖卡是因?yàn)镼Painter畫得慢其實(shí)真正的問題往往是無效更新。在QGraphicsScene里scene-update()是全場(chǎng)景重繪任務(wù)只有幾十條還好任務(wù)一多直接觸發(fā)海量item的paint調(diào)用。我改成這樣幾個(gè)策略視圖級(jí)設(shè)置setViewportUpdateMode(QGraphicsView::MinimalViewportUpdate)讓場(chǎng)景只重畫變化區(qū)域。任務(wù)條移動(dòng)、縮放時(shí)只調(diào)用該item的update()和相關(guān)區(qū)域絕不全局scene-update()。QGraphicsItem::setCacheMode(QGraphicsItem::DeviceCoordinateCache)對(duì)靜態(tài)背景和泳道陰影很有用但對(duì)頻繁變化的進(jìn)度填充反而會(huì)增加緩存失效開銷所以只給背景層用。有一個(gè)崩潰隱患必須單獨(dú)提醒絕對(duì)不要在paint()里調(diào)用update()或者任何會(huì)觸發(fā)布局重算的函數(shù)這會(huì)讓Qt進(jìn)入重繪遞歸輕則閃爍重則直接棧溢出崩潰。我第一次重寫時(shí)在一個(gè)公共繪制函數(shù)里加了刷新調(diào)用結(jié)果程序一打開窗口就崩排查了一整天才發(fā)現(xiàn)是遞歸重繪。4.2 可見區(qū)域裁剪和任務(wù)條復(fù)用性能的另一個(gè)大頭是裁剪。甘特圖時(shí)間軸跨度經(jīng)常好幾年任務(wù)可能有幾千條但屏幕上一屏只能顯示幾十條。處理辦法很直接GanttView在滾動(dòng)結(jié)束、縮放結(jié)束時(shí)計(jì)算當(dāng)前視口對(duì)應(yīng)的日期范圍只讓這個(gè)范圍內(nèi)的任務(wù)條保持可見范圍外的TaskItem::setVisible(false)。void GanttView::updateVisibleRange() { const QRectF visibleRect mapToScene(viewport()-rect()).boundingRect(); const QDate begin xToDate(visibleRect.left()); const QDate end xToDate(visibleRect.right()); for (TaskItem *item : m_taskItems) { const bool visible item-startDate() end item-endDate() begin; item-setVisible(visible); } }幾千條任務(wù)的數(shù)據(jù)量下全部創(chuàng)建TaskItem加入場(chǎng)景也就幾MB內(nèi)存完全不必做復(fù)雜的虛擬化懶加載幾萬條以上再考慮按可見范圍動(dòng)態(tài)創(chuàng)建和銷毀。用setVisible(false)隱藏的好處是切回時(shí)不用重新構(gòu)造對(duì)象滾動(dòng)起來不會(huì)有“突然冒出空位”的錯(cuò)覺。實(shí)際測(cè)下來一個(gè)1500行任務(wù)的甘特圖在縮放、拖拽、滾動(dòng)三種操作下都能穩(wěn)定60幀左右性能已經(jīng)完全夠用。4.3 與qcustomplot頻譜繪制的橫向?qū)Ρ冉?jīng)驗(yàn)我在這個(gè)上位機(jī)項(xiàng)目里另一塊負(fù)責(zé)串口數(shù)據(jù)采集后顯示時(shí)域波形再用kissfft做時(shí)域轉(zhuǎn)頻域最后交給qcustomplot繪制頻譜圖。這兩塊功能用到的優(yōu)化經(jīng)驗(yàn)和甘特圖是共通的qcustomplot里大數(shù)據(jù)量曲線要用setData()批量更新而不是一條一條addData()QGraphicsScene里則要避免全場(chǎng)景update。兩者的核心思路都是“最小化重繪區(qū)域”。如果你在做類似的Qt項(xiàng)目把甘特圖、波形顯示、圖像處理這些功能拆分成獨(dú)立模塊每個(gè)模塊只管自己的繪制和交互互相之間只用信號(hào)槽通信后期會(huì)省很多事。尤其是和halcon這類第三方SDK集成時(shí)底層處理線程和UI層徹底分開才不會(huì)出現(xiàn)“一刷新就卡死”的玄學(xué)問題。5. 收尾與發(fā)布打包、崩潰排查與再擴(kuò)展5.1 windeployqt發(fā)布和運(yùn)行時(shí)崩潰問題項(xiàng)目開發(fā)完用windeployqt打包發(fā)布到?jīng)]有安裝Qt環(huán)境的機(jī)器上最常見的報(bào)錯(cuò)就是This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.這個(gè)報(bào)錯(cuò)的根源基本都出在platforms目錄缺失或版本不匹配。發(fā)布目錄里必須存在platforms/qwindows.dll而且這個(gè)dll的位數(shù)、編譯套件要跟exe一致。我剛發(fā)布時(shí)用mingw版Qt打了一個(gè)包又用msvc版補(bǔ)了一個(gè)dll結(jié)果32位和64位混在一起雙擊直接彈這個(gè)錯(cuò)誤。另外windeployqt不會(huì)自動(dòng)帶上qcustomplot.dll這類第三方庫(kù)需要手動(dòng)復(fù)制或者用windeployqt --no-translations之后再補(bǔ)拷。建議打包完成后用一個(gè)干凈的虛擬機(jī)或未裝Qt的電腦做最后驗(yàn)證不要想當(dāng)然。5.2 崩在鼠標(biāo)事件里的常見原因重寫過程中我遇到的崩潰絕大多數(shù)集中在拖拽事件和item增刪時(shí)段。最典型的一個(gè)場(chǎng)景任務(wù)條在mouseMoveEvent里觸發(fā)了對(duì)某個(gè)item的刪除釋放鼠標(biāo)時(shí)Qt內(nèi)部還在遍歷場(chǎng)景的事件分發(fā)列表于是懸空指針直接崩。解決辦法是刪除item時(shí)不要手動(dòng)delete要scene-removeItem(item)之后再deleteLater()讓事件循環(huán)安全回收。另一個(gè)容易崩的點(diǎn)是遍歷scene-items()的過程中修改場(chǎng)景結(jié)構(gòu)。比如在拖拽回調(diào)里調(diào)用scene-addItem()而外層正好在items()返回的列表上迭代容器失效就會(huì)崩。所有需要批量修改item的操作統(tǒng)一先收集到一個(gè)臨時(shí)列表迭代完成后再統(tǒng)一操作。另外給TaskItem里的業(yè)務(wù)對(duì)象用QPointer包裹能很大程度避免“數(shù)據(jù)被釋放但item還在引用”的野指針問題。5.3 后續(xù)擴(kuò)展方向第二版做完穩(wěn)定后我已經(jīng)把“任務(wù)依賴”“里程碑”“多泳道”“進(jìn)度顯示”“拖拽改期”“Ctrl滾輪縮放”都跑通了。后續(xù)如果繼續(xù)擴(kuò)展可以在這個(gè)基礎(chǔ)上加子任務(wù)折疊、關(guān)鍵路徑高亮、導(dǎo)入導(dǎo)出MS Project格式、撤銷重做棧。數(shù)據(jù)模型和視圖分離的設(shè)計(jì)讓這些功能都有比較清晰的落點(diǎn)不會(huì)像第一版一樣想加一個(gè)功能就得把所有繪制代碼重寫一遍。關(guān)于開發(fā)環(huán)境我個(gè)人的建議是做這種重度信號(hào)槽交互、經(jīng)常需要調(diào)試崩潰的項(xiàng)目還是用Qt Creator最順手信號(hào)槽斷點(diǎn)、對(duì)象樹檢視都是神器。VS Code配合Qt Designer也能寫編輯體驗(yàn)好但排查Qt內(nèi)部信號(hào)槽調(diào)用鏈時(shí)效率明顯低一截。如果沒特殊偏好主開發(fā)用Qt Creator日常寫純C邏輯再用VS Code兩者配合會(huì)舒服很多。這次重寫給我最深的體會(huì)是甘特圖這種組件表面的功能只是畫條狀圖真正的難度都在交互和性能上。第一次用QTableWidget本質(zhì)上是拿表格思維硬套時(shí)間軸需求第二次換到QGraphicsScene等于先把渲染和交互的地基鋪好后面每加一個(gè)功能都輕松得多。如果你也正在Qt里被類似的自繪控件折磨不妨早點(diǎn)考慮場(chǎng)景框架這條路雖然剛開始會(huì)有一段學(xué)習(xí)成本但長(zhǎng)遠(yuǎn)看非常值得。本文還有配套的精品資源點(diǎn)擊獲取