Comments (7)
Reasonable feature request! I think it could be rather challenging to find useful defaults, though. Metagraphs can represent basically everything; the desired look of the graph depends on the specific use case a lot. What kind of convenience functions could there be besides streamlining
graphplot(g; nlabels=repr.(labels(g)))
Since the look of the graph plot depends mainly on keyword arguments, I think there are 3 ways one could achieve that kind of convenience functions:
specific recipe
One could overload graphplot
for MetaGraph
objects. This would basically create a new plot recipe just for MetaGraphs
.
Pros:
- "cleanest" one-liners possible (i.e.,
mgraphplot(myMetaGraph)
might suffice in simple cases)
Cons:
- more annoying documentation-wise because the new recipe would essentially duplicate most of the old one but overwrite some specific defaults.
- less flexible? I.e. if the nodelabel type is a symbol
:foo
. Should it be displayed asfoo
or:foo
? This kind of decision would be baked into theGraphMakie
recipe code then.
"preprocessing" function
I used this pattern extensively in my own work based on GraphMakie
: write some helper function that helps generating the specific keyword arguments as a named tuple:
function gpargs(mg::MetaGraph)
# do clever stuff here
return (; nlabels=..., elabels=...)
end
fig, ax, p = graphplot(myMetaGraph; gpargs(myMetaGraph)...)
Pros:
- The code could live in a package extension; not sure if in
GraphMakie
orMetaGraphsNext
. - rather flexible because all kw arguments could still be overwritten easily (if the same keyword appears multiple times, Julia will use the last one).
Cons:
- less elegant
extraction functions
Alternatively, one could do something similar but on a keyword base:
fig, ax, p = graphplot(myMetaGraph; elabels=extract_elabels(myMetaGraph),
nlabels=extract_nlabels(myMetaGraph), ...)
Pros:
- most flexible
Cons:
- most verbose
Did you have something similar in mind, or did you think of something completely different?
from graphmakie.jl.
On THIS constructor we get the following information:
vertices_description
is a vector of pairslabel => data
(the code of a vertex will correspond to its rank in the list)edges_description
is a vector of pairs(label1, label2) => data
Following that, for me the most sensible defaults would be to have anything that's named "data" show on hovering the corresponding element, and have the label value be rendered into the node (ideally while allowing to provide transformer functions, defaults: labeltransformer=identity, datatransformer=identity
).
If one needs to show the data as the nodelabel (for example in non-interactive cases/static exports) one can simply supply labeltransformer = x->g[x]
since MetaGraph g provides the data if supplied with the label.
EDIT: regarding your 3 ways, I really like all of them while I prefer the first one (own recipe). and having preprocessing as the 2nd.
from graphmakie.jl.
If it should be interactive, i.e. only showing the data on hover, the problem is a bit more complicated because this requires registering interactions, which are a property of the axis rather than the plot content and thus cannot be defined within the recipe, which is a known limitation of the current recipe system in Makie. For that, the solution would be to define something along the lines of
function showDataOnHover(p; labeltransformer, datatransformer)
# do something usefull
return someHoverHandler(...)
end
fig, ax, p = graphplot(mymetagraph; ilabels=mylabeltransformer.(nodelabels(mymetagraph))
register_interaction!(ax, :datahover, showDataOnHover(p; datatransformer=...))
from graphmakie.jl.
Wouldn't it be possible to fully hook into the recipe system and call register_interaction/define process_interaction within the full-recipe-plot!-function?
Going that route: https://docs.makie.org/stable/explanations/recipes/#full_recipes_with_the_recipe_macro
and calling the necessary functions within the
function plot!(myplot::MyPlot)
# normal plotting code, building on any previously defined recipes
# or atomic plotting operations, and adding to the combined `myplot`:
register_interaction!(myplot, :graphhover) do
#some hover landling
end
lines!(myplot, rand(10), color = myplot.plot_color)
plot!(myplot, myplot.x, myplot.y)
myplot
end
(adapted from the url above)
from graphmakie.jl.
The problem is that there is no reference to the axis object within the plot!(p::GraphPlot)
function. p
is just a reference to the plot, while the interaction needs to be registered with the axis. The plot object does not know anything about the axis in which it is displayed.
from graphmakie.jl.
Would it be possible to register interaction handlers on the plot and then hook into the code which assigns the plot to an axis and make it also extract the interaction handlers, re-registering it on the axis?
something like
function plot!(myplot::MayPlot)
register!(myplot, :on_axis_assign) do ax
register_interaction!(ax, :graphhover) do
#some hover landling
end
end
end
from graphmakie.jl.
In theory yes, but that's a feature that is not yet provided by Makie. As a workaround, it is also always possible to write your own recipie-like functions, which create entire figures with complex interactions instead of a single plot:
function visualize_graph(mg::MetaGraph)
fig = Figure()
# plot, register callbacks and so on
return fig
end
Nevertheless, I think regarding this issue the first step right now would be to create this kind of show-data-on-hower interaction. If you need help with that, you can provide me a small MWE including the construction and basic plotting of a MetaGraph and I can try to define an interaction constructor for that.
from graphmakie.jl.
Related Issues (20)
- curve_distance & curve_distance_usage observable not updating figure
- Precompilation stuck on Julia 1.9 HOT 6
- handle overlapping `nlabels` HOT 6
- node_color and node_marker only accept Symbol HOT 5
- Performant graph plotting and benchmarking HOT 4
- Element-wise `automatic` configuration HOT 1
- Deleting a plot doesn't remove all listeners HOT 2
- Mixing directed and undirected edges HOT 2
- Add padding around graphplot to accommodate node size. HOT 2
- `node_attr` broken using Makie v0.19.11 HOT 1
- Slow start HOT 2
- Setting node size with ilabel
- Improve Reftests HOT 1
- KeyError: key :textsize not found when running doc examples HOT 2
- UndefVarError: `mouse_selection` not defined HOT 5
- arrow_shift = :end works poorly with larger edge width HOT 6
- bounding box cuts off nodes HOT 3
- `pick` one `LineSegments` returns odd index HOT 2
- Dynamic Layout + Interaction.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from graphmakie.jl.