UI Improvements

[weisJ]

Replaced BorderFactory borders with Darklaf borders:

• This makes sure borders match the given theme.

---

Migrated most icons to be compatible with all themes:

• The current icons have hard coded color values, which are optimized for a dark theme. By using the named colors provided by darklaf themes icons are generally more visible in all themes.

Made frame icon be theme responsive for better visibility:

• I have added an utility method in the latest darklaf-snapshot version which converts an Icon to a frame Image and also refreshes the icon if it is themed s.t. the frame icon always matches the theme. I also took the liberty to convert the threadtear.svg icon to be a real vector graphic instead of a wrapped raster image.

Those two things are part of an effort the make the application theme agnostic. The next step would be to migrate hard coded colors the be replaced by theme colors if possible or else provided on a per theme basis (at least a dark/light version should be available).

---

Improved layout of some panels:

• I would advocate against the usage of GridLayout for aligning components in a grid. GridLayout ignores the preferred size of components and will make them too big alsmost all of the time.
• Buttons that span a whole panel inside a split pane are a bit of an eyesore. Especially in combination with GridLayout the buttons all change size and move relative to another whith looks a bit weird if the divider is moved.

---

Replaced usage of IconLoader#loadIcon with IconLoader#getIcon. The former is a rather "low level" api. The latter will enabled more efficient icon loading (i.e. if the same icon is loaded multiple times the same icon will be returned each time).

---

Changed hint rendering for JTreeWithHint:

• Custom rendering should be done in #paintComponent not in #paint.
• Using a JLabel for painting the text moves the burden of layout out the text and setting up font foreground, rendering hint etc. to swing.

[weisJ]

For now I have switched the build to use the snapshot version of darklaf. The api for creating the frame icon may be moved into a more reasonable position, so there might be some change there.

[Col-E]

Side note, what are your line terminator settings on? Some of the changes seem to overwrite entire files despite only a few lines being changed.

[ViRb3]

Perhaps we should enforce newline format as well in the .editorconfig to prevent such issues from happening.

[weisJ]

Well its using the system default for me so CRLF. What line endings are the files curretly using? I can't seem to find out without automatically converting them. Note that the line ending should also be enforced through the .gitattributes file.

Also it would be nice to have a style config so the code style matches the rest of the source code. Ideally this should be enforced through CI. Maybe have a look at Autostyle

Is the repository using CRLF? If yes that’s a big issue if there isn’t an appropriate configuration file to enforce it. By default git will always try to normalise all line endings to LF.

[weisJ]

The line endings are fixed now. I needed to disable core.autocrlf for git but at the same time explicitly mark .svg and .properties files to have LF endings. There .gitattributes file can be expanded to specify all the line endings. After that all files need to be renormalized through git. (While trying to fix the line endings I noticed that even changing the lines from CRLF to CRLF through the gitattributes file the changes will be staged)

[GraxCode]

I really didn't expect the line borders to look that good, but you convinced me otherwise. But there is still something wrong here that needs to be changed: Windows 10, 1920:1080, Java 10

[weisJ]

Should be better now.

One more thing: I have replaced all usage of JScrollPane with OverlayScrollPane. I haven't checked all usage but the painting should be fine. However if you experience that the part below the scrollbar looks out of place with the rest of the viewport please report it.

[weisJ]

I noticed that the syntax theme isn't updated if the theme is changed. This does happen now.

[GraxCode]

Looking better now. Thanks! (Also, why is com.github.weisj.darklaf.theme.event.ThemeInstalledListener not resolved?)

[GraxCode]

I also noticed that /res/krakatau.zip was corrupted.

[weisJ]

I also noticed that /res/krakatau.zip was corrupted.

Probably happend while trying to force git to use the existing line endings.

Also, why is com.github.weisj.darklaf.theme.event.ThemeInstalledListener not resolved?

Not exactly sure. Will have to look into it. Maybe pushing a new snapshot will fix it.

---

I noticed that for the loading indicator the whole panel gets removed and added in again. This looks kind of weird when the loaded jar is not large and no loading time is needed (The panels flashes for a moment).

I have replaced it with a statusbar at the bottom of the frame. One can either show the loading indicator or a progressbar.

threadtear.statusBar.runWithLoadIndicator("Loading", () -> {
 // Do lengthy task here
});

threadtear.statusBar.runWithProgressbar("Loading", callback -> {
 // Do lengthy task here
 // Update progressbar using callback.setProgress(progressValue)
});

For now the statusbar also doubles as a message panel e.g. currently I have it display the information how many class files have been loaded.

threadtear.statusBar.setMessage("Message");

[weisJ]

Pushing a new snapshot indeed fixed the issue.

[GraxCode]

Gradle still doesn't resolve ThemeInstalledListener locally :/ (Maybe because it is cached?)

I like the idea of the statusbar, but it definitely needs some padding. Also in my opinion, the frame has to be a slightly smaller or there needs to be a small distance between the lower actionbar and the trees, to match the "ratio", as with the new design, the tree looks too big.

[weisJ]

Gradle still doesn't resolve ThemeInstalledListener locally :/ (Maybe because it is cached?)

Technically that’s what

configurations.all {
     resolutionStrategy.cacheDynamicVersionsFor 0, 'seconds'
 }

is for.

I like the idea of the statusbar, but it definitely needs some padding.

Also in my opinion, the frame has to be a slightly smaller or there needs to be a small distance between the lower actionbar and the trees, to match the "ratio", as with the new design, the tree looks too big.

What ratio do you have in mind?

[GraxCode]

Gradle still doesn't resolve ThemeInstalledListener locally :/ (Maybe because it is cached?)

Technically that’s what

configurations.all {
     resolutionStrategy.cacheDynamicVersionsFor 0, 'seconds'
 }

is for.

I like the idea of the statusbar, but it definitely needs some padding.

Also in my opinion, the frame has to be a slightly smaller or there needs to be a small distance between the lower actionbar and the trees, to match the "ratio", as with the new design, the tree looks too big.

What ratio do you have in mind?

Only a slight change, but will immediately look better.

[weisJ]

I have added a bit of space. Also the status bar has some padding now.

The build currently fails as the gradle version is too old. I would advise to run ./gradlew build instead of gradle build. I have migrated the build script to the kotlin dsl for better type safety and added a bit more structure to the whole build process. Ideally though I would like to do a bit more:

• Properly configure git through .gitattributes. As I have mentioned this will require to convert all files once in a re-normalizing commit.
• Move the project layout to the default gradle/maven layout i.e. src/main/java/... instead of simply src/.... With the current setup resources and source files share the same directory.
• If needed the project could be split into two sub-projects. One for the application and one for the executions etc. This allows for better decoupling.
• Setup Autostyle to enforce the project style guide.

[GraxCode]

Sure, that would be great! Thanks!

[GraxCode]

And travis.yml should probably changed to use ./gradlew build (but I'm sure it will require a chmod to get it to work). Also it would be nice to not force push, but to make new commits, so I can see what is changed each time.

[weisJ]

For the autostyle configuration the simplest setup is to export the .eclipseformat config file from eclipse. I have routed the plugin to pick up on the file threadtear.eclipseformat.xml. You simply place it in the root directory and remove the default value of false from the skipAutostyle property.

[weisJ]

I have moved the code into the threadtear-gui subproject and prepared threadtear-core for all non-gui code. You probably know the best about how to approach decoupling the gui from the rest of the code.

[GraxCode]

Very nice. I noticed that the decompiler theme is always light now somehow, and the krakatau decompiler doesn't seem to work (it probably can't access the .zip file, or it was corrupted again), but you are probably not finished with your work here. Also, if threadtear is split in two subprojects, how does shadow handle that correctly?

[weisJ]

Very nice. I noticed that the decompiler theme is always light now somehow, and the krakatau decompiler doesn't seem to work (it probably can't access the .zip file, or it was corrupted again), but you are probably not finished with your work here.

Some resource paths needed to be adjusted for the new layout.

Also, if threadtear is split in two subprojects, how does shadow handle that correctly?

Yes. Every project gets compiled into it's own jar file which gets merged by the shadow task (It collects all necessary transitive dependencies).

---

I'm almost finished. Just trying to make sure I haven't missed anything. I'll probably come around and provide an darklaf extension with themes for RSyntaxArea. But that is something for later.

[GraxCode]

Please tell me when you're finished, so I can merge.

[weisJ]

I think I'm finished. If I find anything else to do I'll create a new PR.

[GraxCode]

Then I would like to thank you very much for your work.

[GraxCode]

Okay, so i moved the core classes into the core subproject, but of course there are still connections between both projects. I saw you added the core subproject as dependency to the gui subproject, and it works fine, but when I use the gui project as dependency for the core subproject, I get a circulation error. How do I handle that?

[weisJ]

Cyclic dependencies aren't allowed in gradle. You have some options (not exclusive):

1. Move any non-gui code into the core project. Which means classes which contain gui and non-gui code need to be split up.
2. Shared classes that are used in core and gui can be moved into a seperate subproject (e.g. util) which both gui and core depend on.