You should pull from origin

[kyleboyle]

To get the OSX media next and media prev keys working
tmk#199

[squarefrog]

Is the long term goal of this fork to get it merged into tmk/tmk_keyboard, or is it due to be a long running fork?

Seems like it'd be best for all for to get merged as we would all benefit from an always up-to-date master branch.

[adamgordonbell]

+1 on merging in

[jonaswouters]

any news on this? using the changes from tmk#199 does not seem to fix the media keys

[kyleboyle]

You need tmk#160 and tmk#199

[oysteinkrog]

@cub-uanic Would it be OK for you if someone else took your work and submitted a PR upstream?
Obviously keeping the proper git commits (correct git author etc).

[dragon788]

@oysteinkrog @jonaswouters @kyleboyle The last github activity from @cub-uanic was 8 months ago. I'm wondering if we need to look at somebody else's fork and see if there is a more active one that can be referenced from the TMK readme that can get some of these awesome changes merged in. I'm eagerly anticipating both an ErgoDox EZ and an ErgoDox Infinity and while I'll probably use the HaaTa firmware on the Infinity for a while, I know I will probably end up using QMK if there isn't more activity getting the ErgoDox code into the main TMK repo or at least up to speed with its newer changes (which it seems there are a lot of pull requests open for).

[squarefrog]

It's not too hard a task to fork this repository and pull in the changes from master. But out of respect for Cubs hard work I would definitely like to see this merged into tmk.

However merging it in would require permission from @cub-uanic. None of us can make that decision for him.

[oysteinkrog]

Not to be disrespectful towards @cub-uanic, but at this point I think it's OK f someone else submitted a PR/continued the work.
Keep in mind that all the code is in fact open source licensed (GPLv2, BSD afaik).

[squarefrog]

A fair point. It would be worth checking with tmk whether they'd accept a Pull Request under these circumstances. I think it would definitely be a huge benefit to the community for him to do so.

[cub-uanic]

Hello guys,
I'm defer merge of pull request #24 to it's author, @marknsikora - now he is contributor on this project.
See new topic on GH for my full announce: https://geekhack.org/index.php?topic=79171
Thank you all!

[squarefrog]

That's ubderstandable! Thanks for keeping the project alive!

[marknsikora]

Thanks @cub-uanic, I'd be happy to continue this project.

[squarefrog]

Doing some research this morning has lead me to tmk#173 - it seems that tmk is intending the layouts to be seperate from the core code moving forward.

Towards the bottom of the thread there's quite an elegant way to do this, although it would mean a large scale reorganisation of the project, but would make keeping this fork up to date much easier. It would however render #24 useless.

I wonder if it's worth spinning off a new repository, possibly as an organisation, to allow multiple people to work on the project?

[marknsikora]

I was aware that this was the longterm goal of tmk but I was unaware that they were recommending it already.This looks like it only moves the problem around though. We're still stuck tracking changes in tmk.

For the time being my plan is to update the branch once every few months (probably around 6), when useful major features are introduced, or when upstream closes bugs that affect us.

[squarefrog]

The way they are looking at moving forward makes sense. You add tmk-core as a subtree or submodule, then theres a nice level of separation between the keymap and core.

See https://github.com/BenBergman/bluetooth_kinesis and https://github.com/p3lim/keyboard_firmware for an example.

[dragon788]

Are there any features that TMK is lacking that QMK brings to the table? Now that we at least can get a current layout merged back into TMK, I wonder if like @marknsikora mentioned if its time for a new org/repo to continue the active development.

I've been using QMK on my ErgoDox EZ and it is pretty awesome with some of the extra features with momentary and dual purpose keys, macros and many other things.

[squarefrog]

Now that we at least can get a current layout merged back into TMK

This wont happen - tmk said he wants to split out the code and layouts to make development easier.

As for the separate repo, I think I've changed my mind on this. Migrating to a different org would mean we lose all the commit history for files. I'm tempted to create a new branch and reorganise the project for the future which should separate the Ergodox specific layout code and core, so that for an end user to upgrade it'd just be a case of:

$ git submodule update --remote --merge

Then re-building your firmware.

[marknsikora]

@dragon788
I recently got a plank so I've been reviewing the QMK code. The main advantage I've seen is that they use more bits to encode the layouts which removes the need to use functions as much. Before I look more into it though there are some things here that I want to cleanup first.

Currently I have my eye on tmk#304, I've been trying to refactor the LED code among some other things and this should greatly simplify things. That combined with #29 should allow us to do things like set custom LED settings in layouts. Also it will close a long outstanding TODO of being able to set the lefthand LEDs based on the current layer.

@squarefrog
I agree that moving to an org may not be worthwhile. This is a fairly slow moving project. For the time being both of us have collaborator access so I imagine we can keep on top of things.