Rename UI modules... or not?

[petebankhead]

Hi, so I was wondering if the UI modules should be renamed.

Specifically, it can sometimes be confusing that log-viewer is a subproject within a project called log-viewer.

So I was thinking perhaps log-viewer-ui? Or is there something better?

Also, arguably log-viewer-console is confusing because it doesn't log to the console... it logs to a text area.

So maybe log-viewer-ui-textarea and log-viewer-ui-richtextfx?

Finally, what does everyone feel about log-viewer vs. logviewer? I am continually typing logviewer but don't know if I need to just rewire my brain...

[alanocallaghan]

Specifically, it can sometimes be confusing that log-viewer is a subproject within a project called log-viewer.

I would suggest log-viewer-core or something similar that communicates the purpose of the module. Same with script-editor, I think the plain module name is very confusing.

Finally, what does everyone feel about log-viewer vs. logviewer? I am continually typing logviewer but don't know if I need to just rewire my brain...

I have also been doing this. Given that the package names must lack hyphens I'd argue we drop them for consistency. For example package qupath.ui.scripteditor.ace; in module script-editor-ace could be changed to module scripteditor-ace in project scripteditor. CamelCase or hyphen/underscore separation helps a lot with comprehension especially for ESL people but probably not worth the downside of typing the wrong version over and over

[alanocallaghan]

Maybe worth noting that github will redirect CamelCase to camelcase and vice versa when it comes to repo names

[Rylern]

• For the sub project containing the console application, I think log-viewer-ui-textarea is fine.
• For the sub project containing the rich console application, I would prefer log-viewer-ui-richtextarea, because I think that the name should reflects more the feature (a rich text area) rather than the implementation (the RichTextFX dependency).
• For the sub project containing the main application, I think we should have something like log-viewer-ui-main, or log-viewer-ui-advanced, or log-viewer-ui-enhanced. The idea is to have log-viewer-ui-* to make it consistent with the names of the other UI implementations, and a word that conveys the idea that it contains more advanced features.
• Similarly, shouldn't we regroup sub-projects that implement a logging framework? Something like log-viewer-log-logback, log-viewer-log-reload4j, etc.

Wouldn't log-viewer-core be more for sub projects used by all other sub projects? This would correspond to the current log-viewer-api.

I'm fine with both logviewer and log-viewer.

Is that relevant to keep log-viewer in all sub project names? It's a bit redundant

[alanocallaghan]

Wouldn't log-viewer-core be more for sub projects used by all other sub projects? This would correspond to the current log-viewer-api.

Depends if you're considering the project as a library or an application. The actual logviewer borderpane is in the plain module log-viewer, which I wouldn't really guess when looking at the module names.

Also is there a relevant distinction between sub-project and module? Unfortunately module is used by JPMS and IntelliJ Idea to mean mostly the same thing, while I believe project is the top level component...

[petebankhead]

For the sub project containing the rich console application, I would prefer log-viewer-ui-richtextarea, because I think that the name should reflects more the feature (a rich text area) rather than the implementation (the RichTextFX dependency).

I don't have a strong opinion on it, but I based my suggestion on the fact that the logging managers include the name of the dependency (e.g. logback). And the script editor naming currently refers to ace.

For the sub project containing the main application, I think we should have something like log-viewer-ui-main, or log-viewer-ui-advanced, or log-viewer-ui-enhanced. The idea is to have log-viewer-ui-* to make it consistent with the names of the other UI implementations, and a word that conveys the idea that it contains more advanced features.

Makes sense to me, sounds good.

I'm fine with both logviewer and log-viewer.

With the longer names, I start to really prefer logviewer.

Is that relevant to keep log-viewer in all sub project names? It's a bit redundant

I wonder the same... I guess the main thing is that the jar/maven identifiers look sensible. Currently, I think it would look like this:

implementation "io.github.qupath:logviewer-ui-main:0.1.0"

It's inconsistent with the package name, since we don't use io.github there, but I think that's ok...

As long as those are sensible, then I think the submodule names don't matter a lot - although I think I tend slightly towards keeping logviewer since a name like api could cause confusion since that is also used within Gradle when declaring dependencies.

Also is there a relevant distinction between sub-project and module?

Gradle also has its own ideas... in this case, I was thinking of the Gradle idea of a subproject.

---

Side-note: my recent use of buildSrc with Gradle to store shared configuration stuff in #37 might not have been too smart... it seems to be the gradle way of doing things, but it prevents me importing as a subproject with QuPath to work with both simultaneously in an IDE, because only one buildSrc directory is allows. Not really important, but if anyone has a better way to store the shared configuration stuff then please go for it...