sillydan1 / graphedit Goto Github PK

The current implementation is O((M+N) * D). The original paper describes a way of reducing that down to O(D * N) using some dijkstra magic. (see the original paper: http://btn1x4.inf.uni-bayreuth.de/publications/dotor_buchmann/SCM/ChefRepo/DiffUndMerge/DAlgorithmVariations.pdf )

Reproduction Steps

• Create new model file
• Open the new model file
• Switch to Petrinet syntax
• Check that keys 1 and 2 will switch between place and transition vertex choices
• Pull tab into a new window
• The keybinds will not work anymore

See #16 (comment) for more detail

You should be able to actually install the application as a program on your OS.

• Linux (flatpak, .deb(?), appimage(?))
• OSX (homebrew, dmg(?))
• Windows (.msi or something idk)
• CI / CD
  • CI: build and run tests
  • CD: publish builds on semver compatible tag commit pushes

The interface is a bit unintuitive and could use a "getting started" thing. Maybe host it on the documentation site

As a plugin developer, I dont necessarily want to use Java to build my plugin. Python would be preferable

Maybe take a look at JEP for a solution to this

• Release v1.0.0
  • javadoc
  • proper deb
  • dont package /doc (javadocs on gtz.dk instead)
  • Print / get / show the project dir
  • Fully collapsable log tab and file pane (easiest is to simply remove the min-height / min-width)
  • Ctrl + scroll wheel is expected to zoom in/out, it doesnt
  • Rightclick drag is expected to drag viewport, it doesnt
  • CD
  • Delete key doesnt work on unified tool
  • Ctrl+N dialogue not autoappending .json
  • Preloader is ass - just launch into /tmp/graphedit/uuid and ask for savedir on first Ctrl+S (or something better)
  • Change saved settings file notification to "saved /path/to/place/settings.json" instead
  • MenuItems are lowercase, they should be Upper Case
  • window title is just "java"
  • trying to open project.json through filepane shouldn't be that scary
  • inspector pane is odd to use
  • buffer changed *-thing
  • Unread logs *-thing
  • modals should have titles
  • modals are ugly - missing padding
  • autoselect unified tool
  • homebrew
  • flatpak
  • readme install steps

Image icon
“Counter”
Text area inspector for properties
On-hover effect(?)

As a plugin developer, it is annoying that I have to create so much boiler plate code for my view and viewmodels. It would be nice if there was some automatic eventlistener abstraction.

Something like

private AutoListened<Boolean> myCustomProperty; // no need for adding the myCusomProperty.addEventListever cruft

• Github kanban board / roadmap project
• javadoc
• Logo commission
• Manpages
• Changelog (autgenerated at release)
• wiki at graphedit.gtz.dk
• Readme polish

Because Windows uses different backslashes in folder names, the gitCommitSha and gitCommitShaLong methods need to be changed a little.
First the result is saved into a string, then all "" are replaced with "/". This is still a valid syntax, as using / in folder names is OS-independent.

This issue also suggests using multiline formating for the string from these methods, as they are added to BuildConfig in the buildConfig method.

gitCommitSha

def gitCommitSha = { ->
    def stdout = new ByteArrayOutputStream();
    exec {
        commandLine 'cmd', 'git', 'describe', '--long', '--always', '--dirty', '--exclude=*', '--abbrev=8';
        standardOutput = stdout;
    }
    def rawSha = stdout.toString();
    rawSha = rawSha.replace('\\', '/');
    return rawSha.trim();
}

gitCommitShaLong

def gitCommitShaLong = { ->
    def stdout = new ByteArrayOutputStream();
    exec {
        commandLine 'cmd', 'git', 'describe','--long','--always','--exclude=*','--abbrev=40';
        standardOutput = stdout;
    }
    def rawShaLong = stdout.toString();
    rawShaLong = rawShaLong.replace('\\', '/');
    return rawShaLong.trim();
}

buildConfig

buildConfig {
        buildConfigField("String", "APP_NAME", "\"${project.name}\"");
        buildConfigField("String", "APP_VERSION", provider { "\"${project.version}\"" } );
        buildConfigField("long", "BUILD_TIME", "${System.currentTimeMillis()}L");
        buildConfigField("String", "COMMIT_SHA", "\"\"\"\n${gitCommitSha()}\"\"\"");
        buildConfigField("String", "COMMIT_SHA_LONG", "\"\"\"\n${gitCommitShaLong()}\"\"\"");
        className("BuildConfig");
        packageName("dk.gtz.graphedit");
        useJavaOutput();
    }

• Protobuf specification (that way, you are language agnostic)
• Implement ILsp / ILspEngine interfaces
• Lint protobuf specification
• Implement ILint / ILinter interfaces

It's a bit too annoying with the copy-paste mess... Having the lsp.proto in a seperate repository would make it easier to synchronize versions.

Maybe also consider if there are someone who've made a protobuf package manager - this could also be your time to shine 🌞

Nevermind, this buffrs looks like the way to go (once they have the buffrs registry up and running)

The colors in markdown-style hyperlinks are randomized, and they dont seem to be isolated to the link itself. Probably just a logic bug somewhere

Example

Reproduction Steps

• Open a model
• Add a vertex
• Select that new vertex
• Change Tab
• Press FOCUS button

I suspect this is just a simple handler that is missing when creating new vertices

An interface for a step right before and after a save action that converts model objects to other types of model objects. Maybe. Or maybe it should just be a Files > Export Project > [pick your exporter] and then it saves the model file in the format you've specified (same with Files > Import Project)

Description

The undo tree will keep remembering stuff that has happened in closed files.

Reproduction Steps

• Open a model file
• Do some edits
• Save the model
• Close the model
• Inspect the undo tree. There are still steps.

Suggested Solution

We need to detect that when a model is being closed, that all associated undo-tree nodes are removed as well.

It would be nice if we had a first-party plugin manager, so users can enable / disable plugins at runtime and maybe search on a "marketplace" for plugins. The Standard plugins should be disable-able, but not uninstallable.

I personally dont have any experience with this, so any help would be much appreciated.

As a plugin developer, I dont necessarily want to use java as my plugin language. It would be nice to be able to write plugins on Lua.

Take a look at luaj for inspiration