PushPopTest fail
Up does it go, the Tulip Message Log window
Bug fixed in commit https://sourceforge.net/p/auber/code/12543/
dot grammar bug
The feature is only available since Tulip 5.6.3. Nothing more than image information is recorded in the snapshot.
nice! any way to obtain an unstable current version? later than the current 573?
Sure this helps! 1. i suppose this does not apply in version 5.4, but only later versions (i do not see the "tooltips display parameters") 2. can I keep the feature in the static image generated (snapshot)?
AppImage 573 Segmentation fault (core dumped)
Hello Alain, this bug is already fixed, see https://sourceforge.net/p/auber/bugs/895/ and Tulip 5.7.4 should be available in March. Hope you're doing well too. Patrick
Tulip offers an approaching solution in some views through the display of a specific tooltip associated to every graph element. See the paragraph 'Augmented display' in https://tulip.labri.fr/Documentation/current/tulip-user/html/workspace.html#node-link-diagram-view Hope this helps.
possibly off topic: i would like to generate an image of my graph clickable, with info on nodes while hovering the image; I'm probably dreaming but who knows? Would we have a solution with tulip?
AppImage 573 Segmentation fault (core dumped)
Tulip 5.7.3 AppImage does not start on Ubuntu 22.04 with Intel iris graphics driver
Thanks you very much for your report. libglapi.so will be removed from the AppImage since it seems to be a specific dependency only induced by the local context of the tulip_perspective build.
To be noted, the crash occurs with the upstream version of the Intel drivers installed from a PPA, reverting back to the default one bundled by Ubuntu makes the crash goes away. Nevertheless, the libglapi.so should still be removed from the AppImage in order to use the one from the host system instead and avoid this crash on future Ubuntu releases.
Tulip 5.7.3 AppImage does not start on Ubuntu 22.04 with Intel iris graphics driver
Hi Antoine, I hope your GL_RENDERER hint is helpful ;-) my glxinfo doesn't provide any "GL_RENDERER" string but an "OpenGL renderer string" string (hint, as we see in a moment this is the one requested) perhaps there was a typo and it should have been "glinfo" but I couldn't find any reference to the glinfo tool within the Fedora biosphere https://rpmfind.net/linux/RPM/fedora/devel/rawhide/x86_64/g/glx-utils-9.0.0-4.fc40.x86_64.html mesa-23.3.2.tar.xz from mesa3d.org doesn't contain any reference...
I looked into that issue and managed to reproduce it as I have an old Intel NUC with legacy Intel HD Graphics GPU (same as you Andre I guess) that is taking the dust but is still functional. This looks like a bug in the mesa crocus driver when OpenGL rendering mode is set to GL_SELECT (used when selecting graph elements in views with the mouse). I also tested using the latest version of the driver on Ubuntu (using https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers) and I still got the...
I looked into that issue and managed to reproduce it as I have an old Intel NUC with legacy Intel HD Graphics GPU (same as you Andre I guess) that is taking the dust but is still functional. This looks like a bug in the mesa crocus driver when OpenGL rendering mode is set to GL_SELECT (used when selecting graph elements in views with the mouse). I also tested using the latest version of the driver on Ubuntu (using https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers) and I still got the...
Nevertheless thank you. I just verified it, that it is still broken and was not 'accidentally' fixed due to a library update. I needed a lot of clicking this time, approximately 50? clicks. But at the moment I can't debug this any further. Regards Andre
crash when double-clicking a graph node
I was unable to reproduce the your bug. As shown by the stack trace from call #2 to call #15, the problem does not seem to come from Tulip but rather from the crocus driver (/usr/lib64/dri/crocus_dri.so). Regards
Hi Perry, I followed the discussion you are having with Bruno, allow me to jump in. If I understand well, you are annoyed by the fact that the top level graph contains both the metanode you created and the nodes it contains, and would like to only have the metanode, the contained node being accessible by other means (double clicking the metanode in the GUI for instance). This however is not possible. The highest level graph in the hierarchy will necessarily contain the collection of all nodes that...
Can't compile Tulip with QT6 enabled
I think I might not have made clear what I want. The above snippit works (assuming you ment g.createMetaNode instead of sub.createMetaNode), but when using saveGraph(graph, "test.tlp"), it will render the nodes n1 and n2 twice. Once inside the generated metanode and once outside the metanode. I would like the nodes to be only visible inside the metanode. Is this possible or am I misunderstanding what a metanode is supposed to do?
no it is still still somehow reproducible, QT6 doesn't help!
no it is still still somehow reproducible, QT6 doesn't help!
Looks like building with QT6 somehow fixes this issue?? see https://sourceforge.net/p/auber/bugs/894/
This worked, thank you very much And somehow I can't reproduce the Crash which I reported here https://sourceforge.net/p/auber/bugs/893/ any more.
I will be out of my office until the beginning of January. As we have only validated the Tulip build with Qt 6 up to the 6.4 version, I may just suggest you to try to replace the file library/tulip/gui/include/tulip/GlSimpleEntityItemModel.h by the one in attachment.
Can't compile Tulip with QT6 enabled
still crashes when self-compiled, using essentially tar xvfz tulip-5.7.3.tar.gz cd tulip-5.7.3 mkdir build cd build cmake .. cmake --build . make install
When compiling from source I see the following [ 64%] Building CXX object plugins/import/BibTeX/CMakeFiles/BibTeXImport-5.7.3.dir/ImportBibTeX.cpp.o In function ‘char* seq(char*)’, inlined from ‘std::string& forceUtf8String(std::string&)’ at /home/user/Downloads/tulip-5.7.3/plugins/import/BibTeX/ImportBibTeX.cpp:1001:16: /home/user/Downloads/tulip-5.7.3/plugins/import/BibTeX/ImportBibTeX.cpp:88:18: warning: storing the address of local variable ‘c4’ in ‘utf8seq’ [-Wdangling-pointer=] 88 | return...
crash when double-clicking a graph node
Tulip 5.7.3 is availablre
This is working (Python, easier for testing) and tested: n1 = graph.addNode(); n2 = graph.addNode(); graph.addEdge(n1,n2); g = graph.addCloneSubGraph("g"); meta = graph.addCloneSubGraph("meta"); sub.createMetaNode(meta); - metanodes cannot be created on the root graph - subgraph g contains the resulting graph after the creation of the metanode. The content of the metanode should be inside it before the creation of the metanode - subgraph meta is the content of the metanodes. hope this helps
Thank you for your reply. Your code is quite similar to the code I gave in the second snippet, and has the same problem: the created metanode is empty. I also tried this: ~~~ Graph graph = newGraph(); Graph sub = graph->addSubGraph(); Graph* subGraph = sub->addSubGraph(); sub->createMetaNode(subGraph); node n1 = subGraph->addNode(); node n2 = subGraph->addNode(); sub->addEdge(n1,n2); ~~~ But that results in the nodes n1 and n2 being created twice, once inside the metanode and once outside the metanode...
Dear Perry, Metanodes cannot be created on the root graph. You should create another subgraph level and create the metanode on the subgraph. The root graph cannot be used anymore for visualization (it contains the metanodes and the nodes and edges which are inside the metanodes). The following code should work (not tested) : Graph graph = newGraph(); sub = graph->addSubGraph(); Graph subGraph = sub->addSubGraph(); node n1 = subGraph->addNode(); node n2 = subGraph->addNode(); sub->addEdge(n1,n2);...
Hello, I am exploring the use of the Tulip api in c++ for visualizing some hierachical data, and I am trying to generate a meta-node using the api. However, looking at the documentation it is not clear how the createMetaNode function is supposed to work. The example below generates an error that a meta-node cannot be created in the root of the graph. #include <iostream> #include <tulip/TlpTools.h> #include <tulip/Graph.h> using namespace std; using namespace tlp; int main() { initTulipLib(); Graph...
Add support for the trivial graph format .tgf
Thanks for letting us know about the "Trivial Graph Format". A plugin allowing to import a tgf file has been added in the current code line. I will be available in the next release.
missing text for property names for algorithm configurations when building with QT6 support
The fix for this bug will be integrated to the next release.
Thanks for your report. I reproduced the bug which seems to be a Qt6 bug. The parameter names are displayed but not visible. They become visible by proceeding as follows: - put the mouse in the left column on the line between two rows, - a double vertical arrow is then displayed, - press the mouse left button and scroll down to enlarge the above line and reveal the corresponding parameter name. I found nothing to ensure the parameter name visibility. So I think I have to find a workaround with a...
Thany you all for your provided support Andre
Tulip-5.7.2.AppImage crashes when selecting a layout algorithm within the GUI
Thanks to Antoine (the developer who integrated OGDF source in Tulip) for giving its 2 cents. And thanks to you Andre for your recent reports. So the AppImage build will be fixed for the next Tulip release.
At least this behavior should be somehow documented.
Indeed see Ticket #888, which we have already resolved, rebuilding from the source tar.gz doesn't show the crashes. This makes sense, locally -march=native is always ok. But for something portable like an AppImage, -march=native somehow works against the idea of portability. Question: Would it be possible to drop that -march=native somehow for the AppImage? Regards Andre
General trees are often used to encode a cluster structure, where leaves correspond to clusters and inner nodes correspond to hierarchical merging patterns of clusters. The number of leaves in such a tree thus exactly corresponds to the number of clusters which may be handy to control when generating a tree. While binary trees with a given number of leaves can easily be generated, I am struggling to find a reference for an algorithm that does the same for geenral trees (at first I thought one of...
Hi Andre, The issue likely comes to the fact that the OGDF library bundled in Tulip source folder is compiled with the following GCC flags: -march=native which produces binaries non portable across CPU architectures. Commenting lines 16 to 19 in file tulip-5.7.2/thirdparty/OGDF/cmake/compiler-specifics.cmake and rebuilding the AppImage should fix the issue. Cheers !
Could this be a CPU problem with my old Intel Core i7-3770 processor? The combinations - Ryzen 5 5625U + Ubuntu 22.04 - Ryzen 7 5700U + Fedora 37 with the AppImage don't crash
shouldn't it be possible to extract the contents of the AppImage without running it? The documentation from AppImage suggests that this should be possible. see https://github.com/AppImage/AppImageKit and search for --appimage-extract --appimage-mount --appimage-version
I did the same in using VirtualBox instead of virt-manager. You can extract then run the appimage in doing this : cd /tmp path_to_appimage/Tulip-5.7.2.AppImage ./squashfs-root/AppRun
How exactly did you use this .iso file? I installed virt-manager and started the systemd service. Then i added the .iso to a new VM with 16Gb of RAM and 4 Cores, on my 32Gb i7-3770 host Used the first option in the Grub menu (Live Image) with the .iso file. Opened Firefox, downloaded from sourceforge the AppImage, chmodded it and executed it and crash. This all was very slow. Regards Andre Here is the output from the crash [liveuser@localhost-live ~]$ cd Downloads/ [liveuser@localhost-live Downloads]$...
How exactly did you use this .iso file? I installed virt-manager and started the systemd service. Then i added the .iso to a new VM with 8Gb of RAM and 4 Cores, on my 32Gb i7-3770 host Used the first option in the Grub menu (Live Image) with the .iso file. Opened Firefox, downloaded from sourceforge the AppImage, chmodded it and executed it and crash. This all was very slow. Regards Andre Here is the output from the crash [liveuser@localhost-live ~]$ cd Downloads/ [liveuser@localhost-live Downloads]$...
Checked again, still crashes. - I wonder if it would be possible to share how you built the Tulip-5.7.2.AppImage - Looks like it depends on the AppImage version being used, it might be possible to make the AppImage extractable. https://superuser.com/questions/1301583/how-can-i-extract-files-from-an-appimage - If extraction would be possible it should be easier for debugging
I'm really sorry but I was unable to reproduce the crash you reported. As I have no machine with your OS, I tried booting a virtual machine using Fedora-Workstation-Live-x86_64-38-1.6.iso, then lauching Tulip-5.7.2.AppImage on your cairo.graphml file. Every layout plugin I applied worked as expected.
Can't compile Tulip 5.7.2 on Fedora 38
Thanks a lot for your input. We made a lot of cmake configuration changes in the current code line in using cmake 3.12 as minimal cmake version. In cmake/TulipPython.cmake FIND_PACKAGE(PythonInterp 3.7 REQUIRED) has been replaced by FIND_PACKAGE(Python 3.7 REQUIRED COMPONENTS Interpreter Development) which does the correct check.
I'm attaching the output of a configure step when there is no python3-devel package installed
searching for this object.h file was the correct hint. The python3-devel package wasn't installed. After installing it the build worked with the unmodified tulip-5.7.2 shipped ConsoleUtilsModule.cpp file. But I suggest to error out at configure time and give some hints when the cmake configure step can't detect this file Regards and thank you very much Andre
Random General Tree Algorithm
It seems to be an old bug. Its fix will be available in the next Tulip release. Can you tell me more about the number of requested leaves in a new feature request.
Here is a new version of library/tulip-python/src/ConsoleUtilsModule.cpp. If its compilation fails again, I will be really interested by the cpython/object.h file used to compile it (must be in /usr/include/python.../cpython). Thanks in advance
Random General Tree Algorithm
the build still errors with the same file
Here is a new version of library/tulip-python/src/ConsoleUtilsModule.cpp, I successfully compiled using Python 3.7 to 3.12. Tell me if it works for you.
I wonder where can I find the repo with the newest code? sourceforge looks too old and github has that remark that that repo isnt used anymore https://github.com/Tulip-Dev/tulip Regards Andre
I wonder where can I find the repor with the newest code? sourceforge looks too old and github has that remark that that repo isnt used anymore https://github.com/Tulip-Dev/tulip Regards Andre
nope, still 3.11.6 [user@localhost ~]$ python --version Python 3.11.6 [user@localhost ~]$ dnf list installed | grep python3.x86_64 boost-python3.x86_64 1.78.0-14.fc38 @updates libcap-ng-python3.x86_64 0.8.3-8.fc38 @updates libpeas-loader-python3.x86_64 1.36.0-1.fc38 @fedora python3.x86_64 3.11.6-1.fc38 @updates
Can't compile Tulip 5.7.2 on Fedora 38
The first error is already fixed in the current code line. For the second one, I suppose you tried to compile with Python 3.12 which is not supported in Tulip 5.7.2 code line. The support of Python 3.12 will be added in the next Tulip release.
missing text for property names for algorithm configurations when building with QT6 support
Add support for the trivial graph format .tgf
Can't compile Tulip 5.7.2 on Fedora 38
Tulip-5.7.2.AppImage crashes when selecting a layout algorithm within the GUI
ambiguous call to QWebEngineView(std::nullptr_t)