1.初学Qt的事件小坑记录(5）——事件的accept()和ignore()
2.Orthofinder 2.3
3.Qt的场景图Scene Graph
4.QT获取程序编译时间与当前时间的区别及应用场景
5.Qt笔记(十六)之鼠标 键盘事件
6.聊聊最近QSerialPort遇到的特性

初学Qt的小坑记录(5）——事件的accept()和ignore()

       在Qt开发中，事件处理是记录构建交互界面的关键步骤。我们通常会重写一系列的源码事件函数，例如QWidget类中的事件mousePressEvent(QMouseEvent *)和mouseReleaseEvent(QMouseEvent *)，以及QMainWindow类中的记录closeEvent(QCloseEvent *)等，以实现特定的源码多代理系统源码事件监听与处理功能。

       Qt中，事件事件产生后首先由本Widget处理，记录然后按照对象树的源码路径向上传递给祖先Widget，直至根节点。事件若事件的记录m_accept参数设置为true，则事件处理终止。源码默认情况下，事件m_accept参数为true，记录这意味着事件通常只在最底层的源码Widget上执行一次。

       举个例子，定义MainWindow类继承自QMainWindow，同时定义MyButton类，继承自QPushButton类，并复写mousePressEvent函数，附加一些调试信息。

       通过mybutton.cpp和mainwindow.cpp两个文件，可以观察到：点击按钮外的其他部分时，输出"mousePressEvent of class MainWindow"；而点击按钮时，输出"mousePressEvent of class MyButton"。这表明默认情况下，按钮的点击事件不会传递给其父窗口。

       为了使父窗口捕获到鼠标点击事件，需要在MyButton::mousePressEvent函数末尾添加event->ignore();。这样将m_accept参数设置为false，点击按钮时会输出两条信息。

       事件处理中还涉及accept()与ignore()函数。thinkphp 博客源码accept()将m_accept设置为true，表示组件希望处理事件，而ignore()则设置为false，表示组件忽略该事件。setAccepted(bool)是二者功能的等价调用。

       在实际开发中，并未遇到需要显式调用accept()的情况，但某些事件传播方式可能与常规有所不同，尤其是在事件m_accept为false时，可能会出现需要特殊处理的场景。在分类讨论时，忽略事件后再次接受事件可能有助于简化逻辑。

       此外，关于closeEvent(QCloseEvent *)的处理，一个常见的需求是在关闭窗口前弹出确认对话框。在复写closeEvent函数时，若调用event->ignore()，则关闭事件未被处理，窗口不会关闭；默认情况下或显式调用event->accept()表示允许关闭窗口。

       在调用基类的closeEvent方法时，通常包含显式调用accept()以实现关闭窗口。此时，是否写入accept()或调用基类方法并无直接关系，只要m_accept参数为true，窗口就会调用hide()方法隐藏（如果设置过WA_DeleteOnClose，则进一步析构窗口对象）。总之，理解并灵活使用事件处理函数如accept()和ignore()，以及在特定场景下正确处理closeEvent，对于构建高效、响应式的php视频播放源码Qt应用至关重要。

Orthofinder 2.3

       1.查找直系同源群(orthogroups)和直系同源物(orthologs)

        2.推断所有直系同源群的有根基因树(rooted gene trees)

        3.识别这些基因树中的所有基因复制事件(gene duplication events)

        4.推断有根物种树(rooted species tree)，并将基因复制事件从基因树映射到物种树上

        5.为不同物种基因组间的比较分析提供全面的统计信息

        通过修改 config.json 文件，OrthoFinder 支持用户自定义调用软件

            STAG是一种从所有基因推测物种树的算法，不同于使用单拷贝的直系同源基因进行进化树构建。

        分为如下几步：

        1.BLAST all-vs-all搜索。使用BLASTP以evalue=e-3进行搜索，寻找潜在的同源基因。(除了BLAST, 还可以选择DIAMOND和MMSeq2)

        2.基于基因长度和系统发育距离对BLAST bit得分进行标准化。

        3.使用RBNHs确定同源组序列性相似度的阈值

        4.构建直系同源组图(orthogroup graph)，用作MCL的输入

        5.使用MCL（Markov Cluster Algorithm）对基因进行聚类，划分直系同源组

        具体的分析和参数解释还可见中文 生信技术公众号 /s/eeaTOQUHh6zuhYbbLA_Lnw  

           æ ‡å‡†OrthoFinder运行会生成一组文件，这些文件描述了直系同源群，直系同源，基因树，解析基因树，有根物种树，基因复制事件以及所分析物种集的比较基因组统计数据。

            Orthogroups.tsv：一个制表符分隔的文本文件， 每行包含属于单个直系同源群的基因 。来自每个 直系同源群（Orthogroup，OGXXXX） 基因被组织成列，每个物种一列。

            Orthogroups_UnassignedGenes.tsv：一个制表符分隔的文本文件，其格式与Orthogroups.csv相同，但 包含未分配给任何直系同源群的所有基因。

            Orthogroups.txt(传统格式):包含Orthogroups.tsv文件中描述的直系同源群，但使用OrthoMCL输出格式。(方便需求)

            Orthogroups.GeneCount.tsv：一个制表符分隔的文本文件，其格式与Orthogroups.csv相同， 记录了每个 Orthogroup 中基因在物种间的分布情况，可以用于分析同源基因在物种间的收缩和扩张。

            Orthogroups_SingleCopyOrthologues.txt： 单拷贝直系同源组。每个物种正好包含一个基因的直系同源群列表，即它们包含一对一的直系同源物。它们非常适合进行种间比较和种树推断。(实际使用时候可以根据需求挑选)。建树选择物种太多时，可能文件为空。

            以物种为单位，记录了每个物种与其他物种间的直系同源基因。

            ç›´ç³»åŒæºç‰©ç›®å½•ä¸ºæ¯ä¸ªç‰©ç§åŒ…含一个子目录，该子目录又包含本物种与其他所有物种的成对比较文件，列出该物种对之间的直系同源物（Orthogroup）。 直系同源物可以是一对一，一对多或多对多，这取决于直系同源物分化后的基因复制事件。 文件中的每一行都包含一个物种中的基因，而该基因是另一物种中该基因的直系同源物，并且每一行都被交叉引用到包含这些基因的直系群中。

            ç®€å•ç‚¹è¯´ç›´ç³»åŒæºç‰©(Orthologues)目录能够找到俩俩物种间的所有直系同源基因。

              每个 直系同源群orthogroup（gene_num >= 4）的有根基因树结构。 默认基因树没有支持值，OrthoFinder 为了节省计算时间没算了，有方法获取支持值（没去学）。

            ä¸ºæ¯ä¸ªç›´ç³»åŒæºç¾¤æŽ¨æ–­å‡ºæœ‰æ ¹çš„系统发育树，使用 OrthoFinder复制损失合并模型 进行解析。(根据需求用)

        详细说明可见  /s/eeaTOQUHh6zuhYbbLA_Lnw

             SpeciesTree_rooted.txt：从所有包含STAG支持的直系同源组推断的STAG物种树 ， 此文件有bootstrap值。

            SpeciesTree_rooted_node_labels.csv：与上述相同的树，但是节点被赋予标签(而不是支持值)，用于解释基因重复数据。

            Orthogroups_for_concatenated_alignment.txt：仅在 -M msa 模式下输出，列出了所有串联起来用于推断物种树的 orthogroup ID

           Duplications_per_Orthogroup.tsv：记录了每个 orthogroup 中推断出的基因重复事件数量。

            Duplications_per_Species_Tree_Node.tsv： 记录了物种树中每个节点、物种中发生基因重复事件的数量。

            Orthogroups_SpeciesOverlaps.tsv： 每个物种对之间共享的 orthogroup 直系同源群 （以方矩阵形式）。 不同物种间的同源基因的交集

            OrthologuesStats _ *.tsv：是制表符分隔的文本文件，其中包含矩阵，这些矩阵给出了每对物种之间一对一，一对多和多对多关系的直系同源物数量。

            Statistics_Overall.tsv：记录了有关 orthogroup 的常规统计信息。

            Statistics_PerSpecies.tsv：以物种为单位，记录了有关 orthogroup 的常规统计信息。

            OrthologuesStats _ *：记录了每对物种之间一对一、一对多和多对多关系的直向同源物数量。

            åœ¨Statistics_Overall.csv 和Statistics_PerSpecies.csv中的一些名词：

        Species-specific orthogroup： 完全由一个物种的基因组成的直系同源群 。

        G和O，指的是当你直系同源组按照基因数从大到小进行排列，然后累加，当加入某个组后，累计基因数大于%的总基因数，那么所需要的直系同源组的数目就是O，该组的基因数目就是G。

        Single-copy orthogroup: 单拷贝直系同源群， 每个物种中仅有一个基因的直系同源群 。这些直系同源群是推断物种树和许多其他分析的理想选择。

        Unassigned gene: 未分配的基因， 无法与任何其他基因放入直系同源群的基因，无法和其他基因进行聚类的基因。

           æ‹¥æœ‰åŸºå› æ ‘意味着 OrthoFinder 可以识别发生的所有基因复制事件。OrthoFinder 在文件Species_Tree/ SpeciesTree_rooted_node_labels.txt ä¸­æ ‡è®°ç‰©ç§æ ‘的节点。

            ä¸‹å›¾ä¸ºè‡ªå¸¦æ¡ˆä¾‹ä¸­ç›´ç³»åŒæºç»„ OG 的有根基因树结构。首先分析 N（node ），其左右枝 N、N 是旁系同源（agal），说明 N 发生了一次基因复制。不断递归可以发现，N 后发生了 4 次基因复制。同理分析 N，其中 N2、N4、N6 为旁系同源（geni），说明 N 后发生了 2 次基因复制。结合 N、N，说明 N 后发生了 6 次基因复制。由于 agal、geni 中基因与 N1 均不是旁系同源，所以 OG 中总共发生了 6 次基因复制事件。

            Duplications.tsv：记录了程序推测出的所有基因复制事件的信息。其中 Species Tree Node 表示基因复制事件发生时所对应的物种树节点（即复制是在该物种内发生的）；Gene tree node 表示基因复制事件发生时所对应的基因树节点与基因复制事件对应的节点；Support 表示复制后两个基因副本未被丢失的比例；Type 中 Terminal 表示重复发生在物种树的末端分支上，Non-Terminal 表示重复发生在物种树的内部分支上，被多个物种共享；Genes 1、Genes 2 为基因列表，其中 Genes 1 表示来自复制后基因的一个副本；Genes 2 表示来自复制后基因的另一个副本。

            SpeciesTree_Gene_Duplications_0.5_Support.txt ：记录了物种树每个节点、分枝上包含的基因复制事件的总和，格式为节点或物种名 + 数字（基因复制事件数量）。

            ä»¥ä¸Šç»™å‡ºäº†åŸºå› å¤åˆ¶äº‹ä»¶çš„Summary。其中每个节点显示节点名称，后跟一个下划线，然后是映射到物种树中每个节点充分支持的基因复制事件的数量。如果至少 % 的后代物种保留了复制基因的两个拷贝，则基因复制事件被认为是“得到充分支持的”。例：对于四足动物的共同祖先 N1，有   ä¸ªå¾—到充分支持的基因复制事件。

               æ¯ä¸ªç›´ç³»åŒæºç¾¤çš„FASTA文件给出了 每个直系同源群中每个基因的氨基酸序列。

                ä¸Žç›´ç³»åŒæºç¾¤åºåˆ—目录相同的文件，但 仅限于每个物种仅包含一个基因的直系同源群。

            æ­¤æ–‡ä»¶å¤¹ä»…在 -M msa 模式下输出，均为 FASTA 格式文件。

            1.记录了每个 orthogroup 中序列间的多序列比对结果。

            2.记录了程序通过 CMSA 算法过滤后的 orthogroup 中各序列串联后的多序列比对结果，同时比对结果中空位数 > % 的列已被删除。

        还会有一个名为WorkingDirectory的目录，其中包含运算过程的中间文件，例如blast结果，DIAMOND 比对结果，STAG 输出的无根物种树等。2.3.版本还生成了一些其他文件夹，没看了

        1.基因树(Gene Trees)： 根据每个直系同源群推断的系统发育树。

            åŸºå› æ ‘：指基于单个同源基因差异构建的系统发生树。这种树代表的仅仅是单个基因的进化历史，而不是它所在物种的进化历史。

            Orthogroups_SingleCopyOrthologues.txt：用来看画基因树应该选择哪一个直系同源群的文件。该文件中每个物种正好包含一个基因的直系同源群列表，即它们包含一对一的直系同源物。它们非常适合进行种间比较和种树推断。

        2.解析的基因树(Resolved Gene Trees)： 为每个直系同源群推断出有根的系统发育树，使用OrthoFinder复制损失合并模型进行解析。

        3.物种树(Species Tree)： 从所有直系同源群推断出的STAG物种树，包含内部节点上的STAG支持值，并以STRIDE为根（-M dendroblast）。

       å¤§éƒ¨åˆ†éƒ½æ˜¯æ‘˜æŠ„的，记录有错的地方，麻烦批评指正了。

        看得头晕，挺多还没理解，后面弄WGD再来看看

        声明：本篇多为资料整理总结，仅用于自学记录，侵删，谢谢。感谢作者大大们分享：

        OrthoFinder    /davidemms/OrthoFinder

        xuzhougeng     /p/e0bbb2ba

        浓香鸭腿面    /s/Jny5cTHqQh9yQx-cKQTWbA#tocbar--ebkh9l

        生信技术     /s/eeaTOQUHh6zuhYbbLA_Lnw

Qt的场景图Scene Graph

       场景图在Qt Quick 2.0中扮演关键角色，它基于已知要绘制内容构建。所有QML项目均使用此图进行渲染，其默认实现与OpenGL紧密相连，旨在提供高效性能。

       Qt与OSG的场景图结构类似，都通过构建不同节点间的特定关系进行组织。然而，两者在节点数量和关联的渲染状态方面存在差异。Qt的场景图直接进行渲染，而OSG则将场景图转换为渲染树以避免频繁的渲染状态切换。

       Qt的场景图基于界面元素的位置、透明度等信息构建，而OSG场景图则直接通过节点构建。这意味着用户在Qt中不直接参与场景图的构建，而在OSG中则可直接参与。

       举例来说，假设界面包含包含十个项目的列表，每个项目都有背景色、图标和文本。使用传统绘图技术，这可能导致次绘图调用和类似数量的状态更改。相比之下，场景图可以重组原始图元以进行渲染，仅需一次调用即可绘制所有背景、图标和文本，将绘制调用总数减少到3次。这种批处理和状态更改的减少，可以显著提高某些硬件的性能。

       场景图由QQuickWindow类管理和呈现，用户可以自定义Item类型通过调用QQuickItem :: updatePaintNode（）将其图形基元添加到场景图中。linux 调度源码分析场景图是Item场景的图形表示，包含渲染所有项目的足够信息。在许多平台上，场景图形甚至会在GUI线程准备下一帧状态时在专用渲染线程上进行渲染。

       场景图由许多预定义节点类型组成，每个类型都有特定用途。尽管被称为场景图，其实更准确地定义为节点树。该树由QML场景中的QQuickItem类型构建，并由渲染该场景的渲染器处理。节点本身不包含任何绘图代码或虚拟paint（）函数。

       用户可以添加自定义节点到场景图，即使是表示3D模型的完整子树。在场景图中最重要的节点是QSGGeometryNode，用于定义自定义图形的几何形状和材质。使用QSGGeometry定义几何形状，并描述图形图元的形状或网格。材质定义如何填充此形状的像素。

       一个节点可以拥有任意数量的子节点，这些几何节点按照子顺序进行渲染，父级在子级之后。常见的节点包括QSGSimpleRectNode和QSGSimpleTextureNode，它们是QSGGeometryNode的子类，分别用于定义矩形几何形状的纯色材质和纹理材质。

       节点的所有权通常由创建者或场景图通过QSGNode :: OwnedByParent明确完成。使用线程渲染循环时，图形API（如OpenGL、Vulkan、Metal等）操作以及与场景图的交互必须专门在渲染线程上进行，通常在updatePaintNode（）调用期间。

       材质描述了如何填充QSGGeometryNode中几何图形的asp access 源码下载内部，它封装了用于图形管线顶点和片段阶段的图形着色器。对于只需将自定义阴影应用于QML Item类型的用户，可以使用ShaderEffect类型在QML中直接执行此操作。

       材质类别包括纯色、纹理填充等。便利节点旨在简化常见自定义节点的使用，例如QSGSimpleRectNode和QSGSimpleTextureNode。

       场景图的呈现发生在QQuickWindow类内部，但呈现管道中有一些地方可供用户附加应用程序代码。可以通过直接调用场景图使用的图形API（如OpenGL、Vulkan、Metal等）来添加自定义场景图内容或插入任意渲染命令。共有三种渲染循环变体：基本、窗口和线程。其中，基本和窗口是单线程的，线程在专用线程上执行场景图渲染。

       线程和Windows渲染循环依赖于图形API实现来节流。基于线程的渲染循环可以在多个配置中使用，以增加多核处理器的并行度，并更好地利用停顿时间。这可以显着提高性能，但对与场景图进行交互的位置和时间施加了限制。

       在许多配置中，场景图渲染将在专用渲染线程上进行。这样做是为了增加多核处理器的并行度，并更好地利用停顿时间，例如等待阻塞交换缓冲区调用。这可以显着提高性能，但对与场景图进行交互的位置和时间施加了限制。

       关于渲染过程，当QML场景中发生更改并调用QQuickItem :: update（）时，事件被发布到渲染线程以启动新帧。渲染线程准备绘制新帧。在渲染线程准备新帧时，GUI线程调用QQuickItem :: updatePolish（）对项目进行最终修饰，然后再渲染它们。然后，阻塞GUI线程，发出QQuickWindow :: beforeSynchronizing（）信号，进行必要的准备工作。接着，将QML状态同步到场景图中，渲染场景图，然后发出QQuickWindow :: frameSwapped（）信号。

       在渲染线程正在渲染时，GUI可以自由地进行动画、处理事件等。在默认情况下，线程渲染器可以使用OpenGL、Vulkan、Metal、移动平台、EGLFS嵌入式Linux平台等。通过设置QSG_RENDER_LOOP = threaded，始终可以强制使用线程渲染器。

       场景图日志功能支持多个类别，帮助跟踪性能问题和错误。例如，qt.scenegraph.time.texture记录进行纹理上传的时间，qt.scenegraph.time.compilation记录着色器编译的时间等。在遇到图形问题或不确定使用的渲染循环或图形API时，应始终启用qt.scenegraph.general和qt.rhi类别，以获得初始化期间打印的一些基本信息。

       场景图还具有适应层，该层允许硬件特定的优化，包括自定义纹理、渲染器、动画驱动程序、渲染循环等。通过这些机制，Qt能够充分利用硬件资源，提高渲染性能。

QT获取程序编译时间与当前时间的区别及应用场景

       - 编译时间，即源代码编译完成的日期和时间，它固定在编译阶段，用于标识代码版本和历史变更，通常在代码版本控制或维护记录中发挥作用。比如，你可以通过 "__DATE__" 和 "__TIME__" 获取这个信息，如在代码中设置 QString dateTime; dateTime += __DATE__; dateTime += " "; 然后输出到文本框。

       - 运行时间，则是程序在执行过程中获取的当前日期和时间，它会随着程序的运行而动态变化。例如，通过`QDateTime::currentDateTime();`获取当前时间并显示在文本框中，如`ui->textEdit_2->setText(QDateTime::currentDateTime().toString());`。

       - 编译时间获取，通过特定的编译时宏（如`__DATE__`和`__TIME__`）获取，然后将结果显示在UI元素中，如`ui->textEdit->setText(dateTime);`。

       - 运行时间获取，使用Qt库中的`QDateTime::currentDateTime()`函数获取并显示，如直接输出当前日期和时间到`ui->textEdit_2`。

       在实际应用中，编译时间用于记录源代码的历史，而运行时间则用于实时操作或记录事件，如日志生成或监控程序运行状态。程序启动时的编译时间和系统时钟并不一致，但程序运行时的当前时间和系统时钟是同步的。

Qt笔记(十六)之鼠标 键盘事件

       事件的获取在软件开发中比较常见。鼠标左键单击/双击时事件、按键按下事件是楼主接触较多的。今天，我们将梳理常见的鼠标、键盘事件，作详细记录。

       Qt提供的事件监测接口方便快捷，通常只需重写对应的函数。

       事件分类如下：

       1. 鼠标按下事件

       2. 鼠标移动事件

       注：mouseMoveEvent默认在鼠标按下时检测。若需检测鼠标移动而无需按下，可设置setMouseTracking(true)。

       3. 鼠标双击事件

       4. 鼠标滚轮事件

       5. 按键按下事件

       6. 按键抬起事件

       我们通过代码演示上述事件的应用效果：

       核心代码示例：

       效果呈现：

       如需获取更详细代码实现，请参考CSDN链接：Qt笔记(十六)之鼠标 键盘事件

聊聊最近QSerialPort遇到的特性

       在最近的Qt串口编程中，我遇到了一个关于数据准备就绪的特性问题，这里记录一下我的解决过程。

       原本以为这个问题已经解决，但实际工作中遇到的问题促使我重新审视官方文档。官方描述中提到，当知道端口准备好读写时，可以调用read()或write()等方法。然而，"数据准备就绪"这一概念的时机并未明确给出，这成为了一个疑惑点。

       查阅文档时，我发现了一个函数，它在数据可读写时触发readyRead信号，即"数据准备就绪"，但依然没有提及具体何时达到这个状态。在QtBug中，我发现了年的一个报告，似乎证实了官方文档可能存在描述上的不足。

       在对事件循环的理解上，我开始意识到事件的优先级在决定数据处理顺序上扮演关键角色。事件循环的执行并非立即，而是按照优先级顺序。这就意味着，即使数据已经发送出去，用户可能会感受到延迟，但实际上是数据在缓冲区等待适当时机被处理。

       总结起来，有三个关键点：首先，read前需要readReady状态；其次，readReady前数据可能先存入缓冲区；最后，从缓冲区读取数据需要通过waitForReadyRead或processEvents将数据放入事件循环，而这个过程受到事件优先级的控制，不会立即执行。

       解决这个问题的直接方法是调整事件的优先级。作为五年经验的Qt开发者，我对这个特性有了更深入的理解，但仍有讨论的空间。欢迎一起探讨。

qt日志功能

       电脑中的qt日志，蕴含着信息的宝藏，也可能成为无用的数据泥潭。网络设备、系统和服务程序在运行时，会产生名为log的事件记录。每一行qt日志包含日期、时间、用户和动作等操作描述。Windows网络操作系统配备多种qt日志，包括应用程序日志、安全日志、系统日志、Scheduler服务日志、FTP日志、WWW日志、DNS服务器日志等。这些日志因系统配置的服务差异而有所不同。当我们对系统执行操作时，qt日志通常会记录相关信息，对系统安全人员而言极为有价值。例如，当有人进行IPC探测时，系统会在安全日志中迅速记录探测者的IP、时间、用户名等信息；通过FTP探测后，FTP日志会记录IP、时间、使用用户名等信息。qt日志对实现网络安全的价值取决于两个关键因素：一是系统和设备需要适当设置以记录所需数据；二是必须具备合适的工具、培训和资源来分析收集的数据。