How to contribute in development of Tuxguitar?

[BeFrankly]

In spite of the fact, that there are many places one can find more or less old code of tuxguitar, this project here seem to be the most active and up to date. So congratuations for that.

As you might now, Karl Fogel, the autor of the book "Producing Open Source Software" (https://producingoss.com/) has given a lot of hints and ideas on how to let a open source software project come to success. Some of these ideas are related to the question, how to get more developers.

So if you really want others to contribute, you should give a clear description on how to set up a development environment, some coding guidelines, naming the main modules, how to test, how to commit fixes and how to get in contact with other developers. Describe the working process.

I know that this is a hard job at the beginning, but it is not worth nothing.

At the moment i.e. I did not find a description on how to set up the eclipse environment. I found some post in the sourceforge area, but they are all outdated an embedded links are not working anymore.

So do you think you can give other developers a good start?

[guiv42]

Hi
First thing: good to known you would like to contribute :)
And thanks for raising these good questions, so let me try to provide a few (and incomplete) answers.

you should give a clear description on how to set up a development environment

install.md is a very good starting point to set up a build environment.
I did not find a perfect solution for the development environment, here is what I could do:

• in my openSuse tumbleweed environment, I installed flatpak version of "Eclipse IDE for JAVA Developers"
• then, open Eclipse, hide welcome window, and click on "File/Import...", select "Maven/Existing Maven Projects", then "Next"
• browse to "./tuxguitar/desktop/build-scripts/tuxguitar-linux-swt-x86_64" folder, then click Finish

simplescreenrecorder-2023-12-20_22.54.35.mp4

The same operations can be done to import "/tuxguitar/desktop/build-scripts/tuxguitar-linux-jfx-x86_64", and "tuxguitar/desktop/TuxGuitar-test" (see below about tests).
It displays many warnings, but at least this is sufficient to work on the code.
But I still build and run manually from a shell, since with this method I could not build TuxGuitar within Eclipse with "-P native-modules" option. It seems in my config it does not find how to compile the .c files.

some coding guidelines

That is something I am clearly not skilled enough to do

naming the main modules

A difficult point also. Each time I start to address a new topic I discover new areas of the code, which is quite wide. So I cannot say I have a global view. I did not find any comment/document about global architecture.

how to test

This is a significant pain point. When I discovered this code a few months ago I was quite surprised not to find any test in the code base. It seems "manual ad hoc testing" was the test strategy. I am really missing a serious test infrastructure, but again I'm not skilled enough to put this in place.
I tried to introduce a few automated tests in TuxGuitar-test module, but I definitely do not consider it a clean solution. Anyway, that's what I could do, and I still felt it was better than nothing (I was working at that time on a modification I considered a bit complex).
That would be a very profitable investment to take some time to setup this missing test infrastructure.

how to commit fixes and how to get in contact with other developers. Describe the working process.

I guess that needs to be created from scratch. With essentially 2 persons involved up to now we did not need to dig into this subject.

Hope this can help.

[BeFrankly]

Dear @guiv42 , thanks a lot. That will give me a starting point. I think the working process does not have to been described from scratch. First it is sure that github itself and git in special form the working process. So a link to as description of theses working process definition will be a good start. But you both have to make clear, who is the one who checks the new code and decides to put it in the master brunch. That's something what totally unclear to me.

Another question: Is one of you both the admin of the URL tuxguitar.app? If so, you MUST put an so called "impressum" on it and a way to contact the admin. I am sure that you live in the European Union, I guess like me in germany, and you have a risk for paying a penalty. Lawyers are searching for those websites with crawlers!

So how I help not only with this teacher like hints?

My time consuming job, my working on a honary capacity and the doing exercises on the guitar for playing in an orchestra does not allow me to dig deep into the code, probably. I will see.

If tuxguitar.app has a CMS, I could be active as a writer and I also can support the documentation.

So where do you need (a bit) help?

[guiv42]

Guten Tag ;)
Once again I only have partial answers to your questions.

who is the one who checks the new code and decides to put it in the master brunch. That's something what totally unclear to me.

Well that is pretty clear: @helge17 created this repo and owns exclusive write access (I'm perfectly ok with that). Currently there is no such thing as a robust code review in place, it's just a matter of available workforce (help welcome!).

Is one of you both the admin of the URL tuxguitar.app?

This site has been created recently, and is maintained by @helge17. Content is now available here in this repo.

So where do you need (a bit) help?

There are a lot of things to do. Here are just a few ideas, don't hesistate to propose others.

1. software dev
   Two major activities I could not start (lack of skills): put in place a serious test infrastructure, and rework the Android app (many, many errors and warnings displayed by Android Studio).
   Then, main sources of inspiration for new features/bug fixes are issues and discussions in this repo.

2. Support to dev
   If you cannot actively develop, contribution to code review would be appreciated. It's difficult to take over someone else's code, especially of this size. I already introduced a few bugs in the past, improvement is possible in this area.
   Active testing of the app also has a significant added value (e.g. I cannot test in MacOs or Win11 configs).
   Writing a synthesis of this thread in a dedicated article "how to contribute.md" could also be useful to welcome new developers (or should this be added directly in readme.md?). In this area, description of how to import project in Android Studio is also missing (and not trivial).

3. Support to users
   Re-building a TuxGuitar users community is a challenge. I'd bet most users believe the project is discontinued.
   User's documentation is kind of a neverending story, so there's always some work to do here.
   Online help could also be improved, as everyone seeks for online support these days. A few ideas for the website: FAQ/hints sections, short video tutorials, wiki, forum... (possibly multilingual? Not all guitarists speak English). Translation of embedded user doc is also an open question.
   It's a pity a lot a information was lost together with .com.ar website.

Note: we use this thread to discuss the next steps for development, don't hesitate to contribute.

[helge17]

Ciao a tutti!

I'll try to summarize the current development status from my point of view.

About a year ago I started to package TuxGuitar 1.5.6 for Debian. Since Upstream was no longer active, I was curious if I could build TuxGuitar for the other platforms as well, and it worked. So I decided to publish my modifications here on Github. At that time guiv42 also tried to contribute to TuxGuitar, and so we kind of became the new upstream developer.

I would describe our roles like this:

• guiv42 mainly works on the Java code, without him TuxGuitar would not evolve, thanks for this work!

• I mainly take care about all the other stuff: providing binary builds, testing and merging pull requests, skins, translations, help pages, maintaining the website. I'm definitely not in a position to contribute to the Java code or define coding guidelines, I'm not a programmer.

If someone submits a patch, I would ask guiv42 to review the code.

Communication currently only takes place here on Github.

Of course we would be happy if more people would contribute to TuxGuitar. As guiv42 already said there is a lot to do. A few points from my side:

• Deciding whether we continue with SWT, JFX or maybe QT, then polishing the selected toolkit
• Fixing compiler warnings, cleaning up and simplifying the build process
• Work on open issues
• MacOS: Better OS integration, is TuxGuitar-AudioUnit still useful (contains a binary libtuxguitar-audiounit-jni.jnilib)? Build on ARM architecture?
• Support for high resolution (HiDPI) (take over from 2.0beta?)
• Android: Update and maybe bring the new version to F-Droid and the Play Store
• Dark mode does not work well on all platforms, matching skin is not automatically set
• Fixing and updating the export/import modules for third-party file formats
• Support different architectures under Linux, bring TuxGuitar into the distributions
• Soundfont: License issue for Linux distributions. Use anotherone? Provide soundfont apart from the program? Provide some download option for external soundfont sources? Use the same soundfont on desktop and Android?
• Update sound drivers (alsa jack vst lv2 pulseaudio java audio pipewire audiounit,... ?)
• The LV2 plugin still depends on QT5.
• What about the outdated VST plugin? License issue for Linux distributions. Update, remove?
• Convert messages*.properties to utf8
• Replace FTP support by WebDAV in collection browser

At the moment from the technical point of view I would concentrate on fixing bugs, tidying up and updating the code, not so much on new features, so that TuxGuitar will run flawlessly on current OS versions.

Is one of you both the admin of the URL tuxguitar.app? If so, you MUST put an so called "impressum" on it and a way to contact the admin.

I am the admin of tuxguitar.app. I will add some legal information in the next few days.

If tuxguitar.app has a CMS, I could be active as a writer and I also can support the documentation.

There is no CMS on tuxguitar.app, only the pages from the website folder and the help pages, both are included in this repository. A CMS would cause additional work, server load and legal issues (user data, external content, tracking etc.). A forum could also make sense, but this also needs to be maintained.

Well, that's the plan for now. If more people join in, we could do more, and a community could evolve over time. I have no problem if someone more capable than me is willing to take on some responsibility. But I'm also happy with the way things are now and I'm willing to keep TuxGuitar alive for the near future. And please don't forget: This is a spare time project, so don't expect too much.

@guiv42, just let me know if you agree with my understanding, your opinion is very important to me.

[guiv42]

This history is a coincidence. After complaining for years about the graphical representation of bends, I finally tried to implement it myself, and I was the first surprised when I succeeded. When I first connected to SF to submit my contribution, I discovered that development had stalled for a while, and that this initiative had started here. And I thought this was the most credible path to make sure TuxGuitar has a future. Thanks again @helge17 for that.
Up to now my strategy was the following: first, make this repository attractive. So, listen to users. That's why I focused on bug reports and feature requests from SF first, then from here in github. I also tried to implement a few visible new features (e.g. click & drag back-ported from 2.0beta, or volume controls this week).
I don't know if this game is won, but I would say it's on a good track. The idea of helge17 to simplify the build process and provide easily installable builds was brilliant (I found many posts on SF about users unable to build or to apply themselves some patches). Finally, not so many guitarists want to play with a build system and a command line...

So, what's next? I am aligned with all objectives listed above. And also on the way of working. But my main problem is I'm limited by my development skills. I'm an amateur, and most of these objectives seem out of reach for me.
Anyway, this app has been really valuable to me for years, so I'm motivated to continue this development.

I'll try to keep listening to user's requests, especially those with a low complexity. But that could be a good moment to spend some time trying to make this repo more attractive to developers.
@BeFrankly: I'll try to spend some time on this debugger issue ;)

[BeFrankly]

@helge17 and @guiv42 , I'm glad to have you here, two enthusiasts that are doing open source projects in spare time.
Or should I say three?!

Your last posts here made much things clear to me. It mainly made clear how you think about this project. Shame is, that until now you both are just nicknames in a github thread to me and you can be male, female, something in between or maybe alians. Some aliens might be good in maven and java. Funny think to imagine.

And seems that it's a really European project (italian, french, german).

My first offer of contributing is to write a guide how to implement the project in eclipse, about the starting point, how to compile SWT and how to debug (multi-threaded).

And related to the web page I understand, that you don't want a CMS at the moment and yes, seem to be state of the art today to version content of the web page in an VCS like git. We will see, if you, @helge17 will be a bottleneck for publishing new web content or new program versions. If so, we can discuss this point later.

At the moment all is fine. My new findings about debugging I will write further down in this discussion.

[BeFrankly]

Dear @guiv42 , here are my first steps with maven in eclipse. I have used eclipse from time to time since years know and use it for ABAP development (SAP) every week. I have never coded java but am familiar with the concept of object oriented design.

Following a little maven tutorial I was able to create a new "Hello world" project, build, run and debug it out of eclipse. But I am not able to build tuxguitar out of eclipse. So I'm also not able to debug. If you could give a screenrecording about building and start debugging, it would be great. Some screenshots of the main build and run configurations needed will also help.

[guiv42]

First experience with Eclipse on my side, and I know I use it in a sub-optimal way. Especially the debugger, that I only used from my test module.

1. build TuxGuitar out of eclipse
   Did you follow all steps from install.md? There are quite a few dependencies to install, but then it should be straightforward.
   What kind of error do you get?

2. build TuxGuitar from eclipse
   This is how I did to build without the native modules (video truncated in the middle of the process to reduce size):

simplescreenrecorder-2023-12-21_18.49.19.mp4

If I add "native-modules" in "Profiles" field, I get the following error when it builds tuxguitar-alsa-linux:
[exec] make: gcc: no such file or folder (translated from French)
Of course gcc and make are installed on my machine.

So, most of the times I build without the native-modules, then before submitting a pull request I always check it still works correctly with the native-modules, running command mvn clean verify -P native-modules from shell

[BeFrankly]

Yesterday evening after a long workday I have followed the install.md instructions. Today, batch history shows the commands. They are listed in the attachment. In line 199 I just can see a git command. Have I really done a git clone of the repository? I must have done, because the build went fine. tuxguitar has started.

In eclipse you gave me good build starting point. I used to do a build in a context of a single project. So I tried on the tuxguitar project itself. You do It for the whole opened projects and your starting point is different. So I tried it But still build out of eclipse fails (see attachment). There is a problem with freebsd-swt-x86_64 SNAPSHOT. Between yesterday and today I just have done a release upgrade of my develop VM from Ubuntu 20.04 to 22.04.

Is the main method in the tuxguitar project the start of the app? And how to debug.

[guiv42]

I'm sorry but this time I do not understand the questions:

batch history shows the commands. They are listed in the attachment.

Attachment seems to be missing.

So I tried it But still build out of eclipse fails (see attachment)

Are we using the same words for the same thing? When I say "build out of eclipse" I mean "build from a shell". Here I do not understand where you try to build: in Eclipse (as shown in my video) or in a shell with mvn command? Difficult to understand without the attachment.

There is a problem with freebsd-swt-x86_64 SNAPSHOT.

I don't understand how you trigger the build, how comes it tries to build freebsd version? For sure it cannot work from Linux.
If you want to build freebsd version you'll need to setup a freebsd environment.
I recommend that, as a first step, you only try to build Linux/SWT variant. This is why I specify this starting point in the build configuration. Then, in a second step, you can try to build the other variants (Linux/JFX, Windows/SWT&JFX, etc.)

[BeFrankly]

Oh sorry, missed the attachment.
batchy.txt

Did some further test. I proof read the install.md and found out, that the release upgrade from ubuntu 20.04 to 22.04 uninstalled some packages. So I did the first step (Install Prerequisites) again and then the build process from command line works. But the eclipse did not. I will start from the beginning tomorrow with importing in eclipse. We will see. If you've got a hint for me, ok, but I will switch off my computer now.

[guiv42]

the the build process from command line works

Good point :)
I'm not sure I will be able to help you so much in the Eclipse configuration, as I really do not master this tool. In your case there is a problem about the definition of what to build: I don't understand why it tries to build "tuxguitar-freebsd-swt-x86_64", this cannot work.
Logically, the entry point for the maven build should be "tuxguitar/desktop/build-scripts/tuxguitar-linux-swt-x86_64/pom.xml". Starting from this file, maven follows all dependencies and builds. And there is absolutely no link to any freebsd specific item.
Here is the list of built modules (result of my video above)

[INFO] gervill 1.0 ........................................ �[1;32mSUCCESS�[m [  6.821 s]
[INFO] tuxguitar-lib SNAPSHOT ............................. �[1;32mSUCCESS�[m [  3.538 s]
[INFO] tuxguitar-editor-utils SNAPSHOT .................... �[1;32mSUCCESS�[m [  1.552 s]
[INFO] tuxguitar-ui-toolkit SNAPSHOT ...................... �[1;32mSUCCESS�[m [  0.637 s]
[INFO] tuxguitar SNAPSHOT ................................. �[1;32mSUCCESS�[m [  6.223 s]
[INFO] tuxguitar-ui-toolkit-swt SNAPSHOT .................. �[1;32mSUCCESS�[m [  1.107 s]
[INFO] tuxguitar-gm-utils SNAPSHOT ........................ �[1;32mSUCCESS�[m [  0.123 s]
[INFO] tuxguitar-ascii SNAPSHOT ........................... �[1;32mSUCCESS�[m [  0.142 s]
[INFO] tuxguitar-browser-ftp SNAPSHOT ..................... �[1;32mSUCCESS�[m [  0.258 s]
[INFO] tuxguitar-compat SNAPSHOT .......................... �[1;32mSUCCESS�[m [  0.524 s]
[INFO] tuxguitar-converter SNAPSHOT ....................... �[1;32mSUCCESS�[m [  0.217 s]
[INFO] tuxguitar-gervill SNAPSHOT ......................... �[1;32mSUCCESS�[m [  0.246 s]
[INFO] tuxguitar-gm-settings SNAPSHOT ..................... �[1;32mSUCCESS�[m [  0.163 s]
[INFO] tuxguitar-gtp SNAPSHOT ............................. �[1;32mSUCCESS�[m [  0.509 s]
[INFO] tuxguitar-gtp-ui SNAPSHOT .......................... �[1;32mSUCCESS�[m [  0.122 s]
[INFO] tuxguitar-gpx SNAPSHOT ............................. �[1;32mSUCCESS�[m [  0.274 s]
[INFO] tuxguitar-jsa SNAPSHOT ............................. �[1;32mSUCCESS�[m [  0.317 s]
[INFO] tuxguitar-lilypond SNAPSHOT ........................ �[1;32mSUCCESS�[m [  0.178 s]
[INFO] tuxguitar-lilypond-ui SNAPSHOT ..................... �[1;32mSUCCESS�[m [  0.129 s]
[INFO] tuxguitar-midi SNAPSHOT ............................ �[1;32mSUCCESS�[m [  0.183 s]
[INFO] tuxguitar-midi-ui SNAPSHOT ......................... �[1;32mSUCCESS�[m [  0.108 s]
[INFO] tuxguitar-musicxml SNAPSHOT ........................ �[1;32mSUCCESS�[m [  0.127 s]
[INFO] tuxguitar-awt-graphics SNAPSHOT .................... �[1;32mSUCCESS�[m [  0.150 s]
[INFO] tuxguitar-pdf SNAPSHOT ............................. �[1;32mSUCCESS�[m [  0.145 s]
[INFO] tuxguitar-pdf-ui SNAPSHOT .......................... �[1;32mSUCCESS�[m [  0.117 s]
[INFO] tuxguitar-ptb SNAPSHOT ............................. �[1;32mSUCCESS�[m [  0.219 s]
[INFO] tuxguitar-tef SNAPSHOT ............................. �[1;32mSUCCESS�[m [  0.224 s]
[INFO] tuxguitar-tuner SNAPSHOT ........................... �[1;32mSUCCESS�[m [  0.213 s]
[INFO] tuxguitar-svg SNAPSHOT ............................. �[1;32mSUCCESS�[m [  0.172 s]
[INFO] tuxguitar-image-swt SNAPSHOT ....................... �[1;32mSUCCESS�[m [  0.158 s]
[INFO] tuxguitar-synth SNAPSHOT ........................... �[1;32mSUCCESS�[m [  0.357 s]
[INFO] tuxguitar-synth-gervill SNAPSHOT ................... �[1;32mSUCCESS�[m [  0.195 s]
[INFO] tuxguitar-synth-export SNAPSHOT .................... �[1;32mSUCCESS�[m [  0.175 s]
[INFO] tuxguitar-debug-helper SNAPSHOT .................... �[1;32mSUCCESS�[m [  0.119 s]
[INFO] tuxguitar-tray-swt SNAPSHOT ........................ �[1;32mSUCCESS�[m [  0.101 s]
[INFO] tuxguitar-linux-swt-x86_64 SNAPSHOT ................ �[1;32mSUCCESS�[m [  2.697 s]

And about some previous questions:

Is the main method in the tuxguitar project the start of the app?

From start script, I interpret that the entry point of the app is TGMainSingleton.main

And how to debug.

That's a good question I would like to have the answer to! I don't really know how to use the debugger in Eclipse. Up to now I only used it from tuxguitar-test module, to run/debug Junit tests.

[BeFrankly]

@guiv42 and @helge17 , if it's ok for you, I will remove the TGMain Class, try to build and if it's ok make my first pull request, just to see if the procedure works.

[BeFrankly]

So sad to say that I have problem in pushing. I'm not a first time user of git and not a first time user of eclipse but to push into your (or may be all foreign) repo is not possible to me. The remote origin is configured with https and I tried two different ways to login. First I tried my username and password that ends up with no permission. So I found some users who had the same problem and workaround was to use a oauth token. So I generated one but this ends up with git-receive-pack not permitted.

I tried two different tokens with more or less rights, but none will work. Any idea? @helge17 , do I have the right to push into your repo?

[guiv42]

That seems normal to me, since you don't have write access to helge17's repo (just like me).
Github standard process is:

• create your personal fork of this repo (I see you've just done it)
• clone your repo locally on your machine
• create a local dev branch
• once you have committed your modifications, push your branch to github
• from your github repo you will then be able to create a pull request
  (see this tutorial)

[BeFrankly]

@guiv42 , sorry for that. It was a beginners problem. Ok, now I know how it works. There were some problems wit eclipse but know I've created my first test balloon in form of a pull request. Thank your for the link to the tutorial. Have not seen this before.
Mmmh. So let me summarize: After having problems in being awake enough for divide push from pull, having problems with eclipse usage as a snap in ubuntu, having to restart eclipse so it sees the new dev branch in my forc and accept the staging, I have spend a lot of spare time just to delete a class. Oh dear.

@guiv42: Last thing we both should find out is, why debugging does break. If we fixed this, it will be time to write a wiki about how to fork, how to clone a fork, import in eclipse, configure the build and to start a debug session.

Then everyone with java knowledge can contribute.

[guiv42]

Good to know you have gone successfully across all these steps, welcome onboard!
Not much time available these days, but I don't forget this debugging issue.

[guiv42]

@BeFrankly congratulations for your first contribution. Just for information, here is what I usually do after a pull request was merged. Note that I'm also a beginner in git/github, so there might be other ways to reach the same result

• from github web interface, in your repo: delete dev branch, update master branch from helge17's repo
• locally, pull the updated master: git checkout master && git pull origin master
• locally, delete dev branches: git fetch -p && git branch -d dev

[helge17]

@guiv42, I think it's time to give you write permissions to the repository. I'm not that familiar with the permissions on Github, but I think I need to make you a "collaborator". Would that be okay with you?

[guiv42]

Thanks for your trust!
It is somehow comfortable for me not to have write access, but it means I rely on you for merging pull requests, testing, etc. and I understand it creates additional work for you. So I would say it's really up to you, I'm OK if you think that can help.
Just keep in mind I'm a beginner in git & github, so it might take some time before I understand how to use all these tools efficiently

[helge17]

No worries; I just sent you the invitation.

[BeFrankly]

@helge17 , it is a good idea to give someone else access to your repo in case you get lost like julian. I don't hope some but who knows. Thanks for giving @guiv42 access.

[guiv42]

@BeFrankly : good news, I made significant progress in the analysis of the debugging issue.
TuxGuitar is developed on top of 2 different ui frameworks: SWT and JFX (and Qt initially, but we could not maintain this version, see #20). So, all interactions with these frameworks are done through a layer of abstraction involving java interfaces. Then, each interface is implemented by 2 different classes, one for SWT and one for JFX.
So, to enable debugging we need to tell the debugger where to find the ui-related classes.
I'm definitely no expert of Eclipse, so I don't know if I have done it correctly, but at least I found a way. Please correct me if there is a cleaner method to reach the same result.

• start by building swt variant
• in Eclipse, open debug configuration as you did in your video above
• then, in "Dependencies" tab, click on "Classpath entries"
• then I added tuxguitar-ui-toolkit-swt jar file by clicking on "Add JARs...", then browsing to tuxguitar-ui-toolkit-swt/target and selecting .jar file
• then I added swt jar file, by clicking on "Add External JARs...", and browsing in the file-system to org.eclipse.swt.gtk.linux.x86_64-4.13.jar file, that you should have downloaded already (else build step would have failed)

after that, debugger seems to work
Note: logically it should be possible to create another similar debug configuration for JFX variant

[BeFrankly]

@guiv42 , as I told you, it has to do with classpath entries. I tried and debugging seem to work so far, meaning, that tuxguitar starts and is displayed on the screen. Crazy thing observed by me was, that I first was not able to add the tuxguitar-ui jar file out of the list. Eclipse did not list the folder where it is in. It listed the x86_64 folder. See here:

After I reimported the project all folders where listed and I was able to debug in both configurations.

Thank you for that.
I observed, that debugging console complained about png files it did not find. So under the source tab of the debug configuration I added the paths where these files are in as an absolute path, but still debugger complains about them.

The gui of the app look a bit creapy without them.

Step by step we are getting to our goal. To my opinion the maven configuration should give the debugger what it needs. The maven dependencies are listed beneath the classpath entries but empty. Until now I do not have a deep understanding of maven but i guess I right with my idea.

[BeFrankly]

@guiv42 , some new findings ( while debugging 😄 ): app tries to load the png files from subdirectories in "/home/{user}/.config/tuxguitar/cache", subdirectory "skins/Oxygen/8.png" i.e.. If I copy the skins folder to that place it worked as expected. Solution could not be to copy the png files over there by the build process. We have to find out why the root is "/.../.config" and have to make it configurable for developing and debugging.

[guiv42]

After I reimported the project all folders where listed and I was able to debug in both configurations.

I have similar issues regularly, especially when I "play" with git (switching branch, etc) while Eclipse is open. Usually it is fixed just by updating the workspace (alt+F5, select all, then OK), no need to re-import completely the project.

[guiv42]

@BeFrankly , about debugging

1. dependency to swt
   We could possibly solve the swt dependency issue in another way. In fact, I have already created a module dedicated to tests. Eventually we could use it as a starting point for debugging, as its pom file should already have the correct dependencies including swt.

2. icons not found in debugging mode
   I'm not sure it is really a problem, debugging is still possible even without a user-friendly interface. And I don't know how to solve this issue. Globally, I have not fully understood yet how TuxGuitar handles such resources (see TGIconManager, TGFileUtils, TGResourceManager)

[helge17]

I agree; so lets move the technical documentation to common/doc (or just doc?) and I will put a link to that folder on the website.

[BeFrankly]

So wait: I've just added some Doc at "/desktop/Tuxguitar/doc" and made a new brunch in my repo. Is your plan to move this folder to "/common"? So how will you merge my next pull request? And finally, how to load the "/common" folder into the eclipse project? What are your plans there?

[helge17]

I've just added some Doc at "/desktop/Tuxguitar/doc" and made a new brunch in my repo. Is your plan to move this folder to "/common"? So how will you merge my next pull request?

If it helps we can merge your PR at the current position "/desktop/Tuxguitar/doc" and move the doc folder to "/common" or maybe "/" afterwards.

@guiv42, is that OK for you? I would prefer "/doc" over "/common/doc", so its more visible and consistent with "/misc" and "/website".

[guiv42]

Yes, no problem.
@BeFrankly don't change anything to you plans, we can move the files/folders afterwards. If it implies some modifications for Eclipse configuration I can probably do it. Anyway I plan to add some information in a doc "how to contribute" (e.g. for non-developers: how to translate, how to create issues, etc).

[helge17]

@BeFrankly, I just merged your PR #187, thanks for the update! Just get on with your work and let us know when you're done, then we'll reorganize the folders and maybe fix some links.

[guiv42]

Hi @BeFrankly

Thanks for your "contribute.md" document, I just pushed an updated version (essentially added info for non-developers).
I still have a few questions & remarks.

• about "Backers" role (see here): what was your objective when describing this role? Currently we do not accept donations, so I don't really understand.
• "Read the docs of your repository provider": not understood. Would it be simpler to add a link to github tutorial? (see the link I added a few lines above).
• you have intentionally blurred some areas in your screenshots, except this one where your full path on your machine is visible. It's not consistent with other screenshots so I don't know if this was intentional or not (anyway your first name is probably not top-secret)
• did you find a way to build with the native modules from Eclipse? This point is quite important, as it's possible when changing code to break compatibility with a native module, it already happened to me with Jack. When I add "native-modules" in the provided build configuration ("Main" tab, "Profiles" field) I still get an error I do not understand. It fails to build tuxguitar-alsa-linux-x86_64, with error "make: gcc: no such file or directory". Both make and gcc are installed in my environment.

We currently have some inconsistencies between "install.md" and "contribute.md" that need to be solved. For example, following steps are defined in both documents, in an inconsistent manner (user won't do these steps twice):

• clone repo
• install swt packages with mvn install command

"install.md" file has the advantage of describing all dependencies which need to be installed before trying to build TuxGuitar. It's also the only place where the process is defined to build the native modules.
So, I would probably recommend the following process for a newcomer:

1. follow instructions from install.md and make sure everything can be built from a console
2. only when this first step succeeded, then setup Eclipse configuration.

What do you think?
Looking at "contribute.md", it would mean re-writing "Make a local copy of the forked repository" section, and to replace it by: from git perspective, add an existing local repository (already created when following "install.md" procedure).

Independently, @BeFrankly just a few hints for your next pull requests:

• It's better to pull and merge master branch into your dev branch (or to rebase dev branch to master) before submitting a pull request. So, if there is any conflict you can solve it yourself locally before pushing (I believe it's a bit more complex after pull request has been sent).
• Personally I "squash" commits in my dev branch before submitting a pull request. I usually commit locally very often (even very minor evolutions), and all these "intermediate" commits have no real added value in master branch's history.

Edit: we also need to fix erroneous link in readme

[BeFrankly]

Dear @guiv42 , there are many points in your post and I will try to respond to them one by one from top to bottom:

Backers

I do not think that anyone will contact us for giving us money. But why not. If you want I can remove this point and we first read (again) this chapter of Producing Open Source Software
https://producingoss.com/en/money.html

Then we start a new discussion about this point. You can not spend hours of hours spare time over years on this project just for fun. It will come to a point, when you have run dry.

Read the docs of your repository provider

To my understanding of git, one can add one or more remotes. This remotes do not necessarily have to been hosted on github. One can host his own on an other provider and still you will be able to work together with pull requests. That's how I understand git. I might be wrong, but a remote is just an URL in the git pull command.
There might be contributers, that do not like to work with github. As you might know, there are other git providers around the world and git is open so one can set up a git server on his own server. So that why I didn't put just a link to the github docu.

blurring paths in the screenshots

I know that some screenshots contain a "frank" in the path. Oohhh, this is a security risk. Really? Don't know. Who said that my name is Frank. I like the name, but is it mine. Don't know. Do you? ;-)
My nickname BeFrank here on github also contains "frank". So is it my name. May be. There are so many lovely Franks around the world. Frank Sinatra, Frank Zappa, Frankenstein, Frank N. Furter...

Building native moduls

I will give it a try.

inconsistencies between install.md and contribute.md

There is a difference between building and installing. A developer wants to be able to build and run the code out of his IDE but this not necessarily mean, he want's to install the build on his computer as a normal software. I'm not happy with this external SWT library. I found some maven documentation that seem to add this external lib as a reference to the online resource. The development of an app should be encapsulated and not have any reference to outside. This is not always possible but I'm sure with SWT.jar it is. But I didn't have time to set up a slightly different build process now.

hints for my next pull request

Thanks for that. I am not familiar with all the git things. Since years a am working with subversion but 7 years ago I started my first git project but was on my own. So there were just some developers that forked my repository but never made a pull request.

I first will study https://git-scm.com/book/en/v2 again. This is a very good book about git.

error link in readme

I have fixed this hopefully, but eclipse at the moment does not work correct here, it has problems in resolving the links. My next pull request will hopefully contain the fix. But first I have to clean up my branches and my repository status.

Hope my reply helps in understanding the reasons why I did all of it this way.

[guiv42]

Thanks for this detailed answer, many points as you said!

Backers

Yes, I would prefer to remove this line. That's right, one day this point will be re-opened. But for now it seems cleaner to me to remove it, as it may puzzle the reader.

building native modules
I will give it a try.

Thanks. It seems important to me: without this, contributors could possibly submit code that does not build.
In fact, it might be even cleaner if we add a list of a few recommended steps to perform before sending a contribution. Basically:

• build desktop app with native-modules, in both SWT and JFX configuration, at least for Linux & Windows
• build Android app

These steps should be accessible to all users with a standard Linux environment.
What do you think? I can add this in "contribution.md" if you want.

inconsistencies between install.md and contribute.md
There is a difference between building and installing

"install.md" could possibly be renamed "build_install.md" then, as it describes all necessary steps to build.

I'm not happy with this external SWT library. I found some maven documentation that seem to add this external lib as a reference to the online resource. The development of an app should be encapsulated and not have any reference to outside. This is not always possible but I'm sure with SWT.jar it is.

Yep, it seems nobody is happy with that. This problem is not new, it was the very first issue in this repo! (#1). It seems it's been around since at least 2021. I could not find a way to bypass this manual installation step.

I insist we need to fix this redundancy issue between the 2 docs. Yet, at 2 different places, we instruct user to download and install swt packages (here and here). Any user will only do the job once. Same problem for maven installation (here and here).

[BeFrankly]

Because this discussion has got a long history and many aspects are within it, I decided to close it now an create some new discussion. @guiv42 , there are some aspects that you have told about from my point of view they do not belong to this discussion. The main goal why I had started this discussion was to have a starting point for contributing as a developer. We have this starting point now an much more. On this long run we dropped a not used main method, found out something about dependencies and had a better understanding of who we are and what our role is.

The aspects your are talking about, mainly the problems in building native moduls, where to but the swt library and the maven installation instruction should be issues that can be solved.

So lets start new issues and new discussions so that it will be better readable for others.
I finally made a pull request about my last fixes in contribute.md and README.md. Take a look.