Is xournalpp reinventing the wheel?

[Alexis-Prel]

TL;DR: xournalpp has awesome killer features, but user-base constantly requests more. Relying on Inkscape (or similar) for selections, copy-pasting, layers, and tools might represent less work than implementing everything from scratch.

Let me start by saying how much I like xournalpp. It is incredibly handy, and the very active github page proves that this is the result of countless hours of work from the developers. For me the distinctive features of xournalpp that I could not find elsewhere are:

• really nice handling of handwriting
• easy creation of multiple page documents
• insertion of vertical space (genius feature!)

So a big thank you for that.

This post is going to be a little blunt though, as it addresses what I think is the elephant in the room when scrolling through the Issues tickets (577 to this day): about half the tickets are feature requests.
Many of these features have already been implemented in more mature software.
For reference, you can find at the end of this post a list of requests for features that are already available in Inkscape and its plugins. The redundancy does not stop there in my opinion, considering bug tickets that concern tools that are present in both software.

It is conceivable to port xournalpp as a plugin of Inkscape, but xournalpp's handling of multiple-page documents is markedly superior.

Instead, I am wondering if it would be possible to use Inkscape as a backend for supplying basic tools, such as: text, selections, groups, and layers.
That would shift xournalpp's core tasks to what it already does well: the management of multiple page documents and receiving handwritten input.

• Selections:
  • Create quick access menu on selection #3091;
  • Highlight selection before moving #2394
  • Multiple Individual Select / Group Selections #1838
  • Right clicking a selection should bring up a context menu #1422
  • Can't select objects out of boundary #1292
  • Copy selection to clipboard as an image #1220
  • Switching to a selection tool should autoselect any currently editing text object #1169
  • and more, like naming a selection as a SVG group, selecting elements by color/stroke style, moving selection with arrow keys, etc.
• Copy-pasting:
  • Paste on cursor #3229
  • Feature request: allow copy and paste between documents #2294
  • and more, such as duplicating or cloning objects (clone change upon original's change), copy/paste the style of an element
• Layers handling:
  • Let's have a place with full control over layers #3000
  • Be Able to Merge Two Layers Together #2784
  • Add simple possibility to change layer of an object #2750
  • Visual button to add and manage layers #2494
  • Edit layer names #1886
  • Import multiple-page pdf files as different layers  #1865
  • Tooltip for changing line color #1320
• Extra/improved tools:
  • Drawing circles based on diameter or center & radius #3151
  • Give the possibility to manage default color pickers #2884
  • Rotate by a Specific Angle, and Current Angle Feedback #2802
  • Spline interpolation of strokes for better quality rendering #2578
  • Hatching / section lining as a fill option #2493
  • Pen, double arrow #2362
  • Add pipette tool #1565
  • Stroke thickness slider #1361
  • Grid overlay #1231
  • Add inline styling for text tool #1092
  • Rich text support #729
• View:
  • Select area to zoom #3158
  • View "single page" #2117
  • major/minor grid #1909
• Page layout:
  • Default paper format #2191
  • Rotate pdf pages #1883
  • Fit page to selection #1096
• Miscellaneous:
  • Merge two xournal notebooks files #2816
  • Adding a start page to Xournalpp for finding files easily at startup #2305
  • Page organizing by labels, levels and groups #2301
  • Export to jpg #1896
  • Add Redo shortcut: Ctrl+Shift+Z #1323

[LittleHuba]

Hi @Alexis-Prel !

Thanks for your honest opinion and all the work you have put into this post. Accumulating a list of issues as yours is quite some work.
And also thank you for addressing the elephant in the room 😉

There is definitely an overlap between Inkscape and Xournal++, as both work with graphical editing. You could say the same for every other graphical editing software out there. In some manner even MS Word and Inkscape share quite a lot. That said, it is not as easy to use Inkscape as backend as it seems. The actual handling of the model (rotating the page, adding a stroke, grouping elements) is the least effort. Integrating this feature with the GUI is another story though. What I want to say with this is, that we would not save a lot of effort with this move. We would still need to integrate all the features of Inkscape into our GUI and do all the input handling ourselves.
Further it would require a near rewrite of Xournal++ to integrate Inkscape as such a substantial part of Xournal++. I do currently not see us doing such a task in the near future. There is a ton of other reasons why this would actually mean more work for us than implementing the features in our own code base. If you want to know them, please let me know and I'll compile a more thorough list.

So while your idea is interesting, it does not really solve the underlying issue.

What would help us though, is a community manager. Somebody that takes care of the evergrowing list of tickets and compiles them into a list of problems in decending order of magnitude, so we know what to tackle next. This way, we developers would get more free time to actually implement the requests. Should you be interested, feel free to reach out to us.

[mohe2015]

I think the problem is that Inkscape (probably) is not modular enough and ready for embedding. But in a world where applications would be designed like that I think this would actually have been feasible. Still would've not been an easy task.

[Technius]

I also thank you for your help here. I just want to comment about the issue situation (@LittleHuba has already discussed the drawbacks of the Inkscape backend idea).

This post is going to be a little blunt though, as it addresses what I think is the elephant in the room when scrolling through the Issues tickets (577 to this day): about half the tickets are feature requests.

We only have this many open feature requests because we tend to prioritize bug fixes and issues with existing features instead of adding new things: of the 1335 closed issues, 772 concern bugs. We leave feature request issues open (as long as they fit within the scope of the project) because they are "issues" to someone as long as they remain unimplemented, but we don't have to implement every one! To filter out noise, we have labeled feature requests that we have "accepted" with priority labels. We try to tackle priority::high issues or difficulty::easy issues first.

The redundancy does not stop there in my opinion, considering bug tickets that concern tools that are present in both software.

Yes, I agree that many concerns in Xournal++ and Inkscape overlap. However, since Xournal++ is focused on note-taking, we're only interested in reimplementing features that help facilitate note-taking. This is much less work than trying to adapt the application on top of an older, larger codebase that no one on the core maintenance team knows anything about.

[Kreijstal]

if you could make a good note-taking GUI workspace that is half as good as xournalpp let me know. (Because that would be awesome, and I've been looking)
But as far as it seems, it looks like you would have to rewrite Inkscape itself.. yeah, talk about reinventing the wheel.

[Alexis-Prel]

Hmm, I think we are talking about different things.

My point was simply that xournalpp's strength is its GUI, but that some useful primitives for new/enhanced features (layers, transformations, selections, exports) are already implemented in Inkscape.

The question was then about which is least effort between using Inkscape as a backend or implementing these features from scratch. LittleHuba gave a convincing argument as to why the second option is better so I don't see any value in arguing further.