Activity for Tulip
-
Tulip released /tulip/tulip-5.7.3/tulip-5.7.3_x64_no_python_setup.exe
-
-
-
-
-
-
Bruno Pinaud posted a comment on discussion Help
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);...
-
Perry Kloet posted a comment on discussion Help
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...
-
Patrick Mary modified ticket #158
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...
-
Andre Maute posted a comment on ticket #887
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
-
Melançon Guy posted a comment on ticket #890
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...
-
Antoine Lambert posted a comment on ticket #887
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)
-
This bug is now fixed in the Tulip code line. Thanks again for your input.
-
missing cstdint include
-
This bug is now fixed in the Tulip code line. Thanks a lot for your input.
-
Guilhem saurel created ticket #886
ambiguous call to QWebEngineView(std::nullptr_t)
-
missing cstdint include
-
Tulip 5.7.2 is available
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
The GML export does not support the export of user defined properties; in the GML format the name of a property (called attribute) is restricted to be a 7-bit ASCII key ([a-zA-Z][a-zA-Z0-9]*) while it is a UTF-8 delimited string for Tulip. Then only Tulip "view" properties are exported using their GML equivalent attribute.
-
Extending the GML export plugin?
-
I'm happy I could help renovate Tulip's dusty and deeper layers ... :-)
-
inducedSubgraph method adding nodes multiple times ?
-
Finally, the error was not in the inducedSubGraph optimized code, which was perfectly legitimate, but it revealed a problem in a much older code.
-
My bad. This is due to an old optim replacing a set by a vector. It will be fixed soon.
-
inducedSubgraph method adding nodes multiple times ?
-
Eccentricity Plugin returns -1 diameter when selecting unnormalized values
-
Fixed in Tulip 5.7
-
Fast & Furious? Thanks.
-
Asap is now.