graphView nodeWidget not clickable on bottom boundary region

[ajayg51]

If we try to interact with graphview leaf node widget on bottom boundary areas, it behaves abnormally and remains unclickable.

[nabil6391]

Any code to reproduce?

[akau0316]

I have the same problem, and I found if I adjust Level Separation smaller, it will be normal

[koodimetsa]

Here is code to reproduce:

import 'package:flutter/material.dart';
import 'package:graphview/GraphView.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData(
        colorScheme: ColorScheme.fromSeed(seedColor: Colors.deepPurple),
        useMaterial3: true,
      ),
      home: const MyHomePage(),
    );
  }
}

class MyHomePage extends StatefulWidget {
  const MyHomePage({super.key});

  @override
  State<MyHomePage> createState() => _MyHomePageState();
}

class _MyHomePageState extends State<MyHomePage> {
  @override
  Widget build(BuildContext context) {
    return const Scaffold(body: SafeArea(child: GraphWidget()));
  }
}

class GraphWidget extends StatefulWidget {
  const GraphWidget({super.key});

  @override
  State<GraphWidget> createState() => _GraphWidgetState();
}

class _GraphWidgetState extends State<GraphWidget> {
  final Graph graph = Graph()..isTree = true;
  BuchheimWalkerConfiguration builder = BuchheimWalkerConfiguration();

  @override
  void initState() {
    super.initState();

    final node1 = Node.Id(1);
    final node2 = Node.Id(2);
    final node3 = Node.Id(3);

    graph.addNode(node1);
    graph.addNode(node2);
    graph.addNode(node3);

    graph.addEdge(node1, node2);
    graph.addEdge(node1, node3, paint: Paint()..color = Colors.red);
  }

  @override
  Widget build(BuildContext context) {
    builder
      ..siblingSeparation = (50)
      ..levelSeparation = (50)
      ..subtreeSeparation = (80)
      ..orientation = (BuchheimWalkerConfiguration.ORIENTATION_TOP_BOTTOM);

    return Expanded(
      child: InteractiveViewer(
          constrained: false,
          scaleEnabled: false,
          boundaryMargin: const EdgeInsets.all(100),
          minScale: 0.01,
          maxScale: 5.6,
          child: GraphView(
            builder: (Node node) {
              // I can decide what widget should be shown here based on the id
              var a = node.key!.value as int;
              return rectangleWidget(a);
            },
            graph: graph,
            algorithm:
                BuchheimWalkerAlgorithm(builder, TreeEdgeRenderer(builder)),
          )),
    );
  }

  Widget rectangleWidget(int a) {
    return MouseRegion(
      cursor: SystemMouseCursors.click,
      child: GestureDetector(
        onTap: () {
          // print('clicked');
          final n = graph.getNodeUsingId(a);
          print(n.position);
        },
        child: Container(
            padding: const EdgeInsets.all(16),
            decoration: BoxDecoration(
              borderRadius: BorderRadius.circular(4),
              color: Colors.blue[100],
            ),
            child: Text('Node ${a}')),
      ),
    );
  }
}

[koodimetsa]

And here is an image from inspector:

[Masadow]

It's because when algorithm is ran, it's called with shiftX and shiftY to 10 which causes the whole graph to move by 10 pixels and therefore exiting the viewport on bottom right. (GraphView.dart L196)

Is there any reason to do that @nabil6391, looks like it was made to have some kind of padding but this seems wrong to me.

We should either be able to configure the coordinate shifting ourselves or the size should be calculated accordingly (+20 on x and y to get a consistent box) (BuchheimWalkerAlgorithm.dart L112)

As a temporary solution, you can extend your preferred algorithm and suppress the shifting :

class Algorithm extends BuchheimWalkerAlgorithm {
  Algorithm(super.configuration, super.renderer);

  @override
  Size run(Graph? graph, double shiftX, double shiftY) => super.run(graph, 0, 0);
}

[nabil6391]

Thats a good find and honestly I am not sure why we do the shift, can you help create a PR with the fix and then I can take a look

[Masadow]

That should be an easy fix but I'm way too busy right now to take time for it, I'm sorry.

But if anyone come accross this issue, he can easily contribute as I've provided all the necessary.

Ideally, shiftX and shiftY would become a parameter defaulting to Offset.zero