luni64 / EncoderTool

The EncoderTool is a library to manage and read out rotary encoders connected either directly or via multiplexers to ARM based boards. Encoder push buttons are supported. Callback functions can be attached to encoder changes and button presses to allow for event driven applications
MIT License
48 stars 12 forks source link

Wiki -> Documentation Folder #18

Closed ElectronicsArchiver closed 2 years ago

ElectronicsArchiver commented 2 years ago


Please check the Preview


Changes

Files Remaining  3 

luni64 commented 2 years ago

Thanks a lot. I'll have a closer look in the evening.

A quick note: I saw that you moved the examples folder to /resources. That won't work since the Arduino IDE needs that folder besides src to integrate the examples. (https://arduino.github.io/arduino-cli/0.21/library-specification/).

ElectronicsArchiver commented 2 years ago

God damn Arduino filesystem bs again..

Well how about this, for the current PR I change it back to how it was before and in a subsequent PR the library gets moved into a folder by itself, something like Library?

You have to upload the files to the Arduino Library Registry, so it wouldn't be a problem right? Or does it use a link, in which case it should still be possible?

luni64 commented 2 years ago

I copied the current landing page from the main branch to the PR.

ElectronicsArchiver commented 2 years ago

Huh? Why would you do that?

luni64 commented 2 years ago

God damn Arduino filesystem bs again..

Well how about this, for the current PR I change it back to how it was before and in a subsequent PR the library gets moved into a folder by itself, something like Library?

You have to upload the files to the Arduino Library Registry, so it wouldn't be a problem right? Or does it use a link, in which case it should still be possible?

Nope, that won't work the structure is quite strict otherwise the library manager will refuse to load it. So it needs to be compliant to the 1.5 library spec

luni64 commented 2 years ago

Huh? Why would you do that?

No worries, not the original one but the one from you which I worked on the last days. It has active badges now and I fixed the content. Need to fix the links to the document folder (still point to the wiki) but this can be done later

ElectronicsArchiver commented 2 years ago

Nope, that won't work the structure is quite strict otherwise the library manager will refuse to load it. So it needs to be compliant to the 1.5 library spec

You cannot just use a folder with the library.properties and library.json files in them?

luni64 commented 2 years ago

You cannot just use a folder which the library.properties and library.json files in them?

No, the Arduino builder relies on it here again the spec: https://arduino.github.io/arduino-cli/0.21/library-specification/. But actually this is not a big thing as long as it works

luni64 commented 2 years ago

I had a closer look by now. Some comments

All in all I like it very much. Looking forward to publish it.

ElectronicsArchiver commented 2 years ago

About manual line breaks: Often people argue that it breaks it for mobile, but forget that most of the people using GitHub are on Desktop. So by not properly formatting text and "leaving it up to the page" it will just go from left to right on basically any slightly modern screen. People also forget what a typesetters job is, that is, setting text to be readable. 60 characters per line would be ideal, just like in books and newspaper articles, as that is literally the average human limit, more just makes you switch from left to right and disorients the reader. I usually go with 60-80 for a better acceptance rate, its hard to get some people to even < 100 .. If you really care about mobile, I would suggest the same as someone that really cares about multi-language support, make a separate adjusted version.

About the banner: I added it for two reasons, as a link back to the overview, like logos usually link back to a home page and to theme the documentation to the repositories topic. I could make the banner thinner if you'd like~

luni64 commented 2 years ago

60 characters per line would be ideal, just like in books and newspaper articles, as that is literally the average human limit, more just makes you switch from left to right and disorients the reader. I usually go with 60-80 for a better acceptance rate, its hard to get some people to even < 100 ..

Agreed, your design, you decide.

If you really care about mobile, I would suggest the same as someone that really cares about multi-language support, make a separate adjusted version.

Is this even possible with a github markdown file? Anyway, I'm fine with the 60

I could make the banner thinner if you'd like~

Can you give it a try on one of the pages? (if it doesn't generate too much work of course)

ElectronicsArchiver commented 2 years ago

Is this even possible with a github markdown file? Anyway, I'm fine with the 60

Like with different lang documentation it would be separate and usually linked to with a header bar containing a language selection.

If you use GitHub pages, you can of course build that in.

Can you give it a try on one of the pages? (if it doesn't generate too much work of course)

Sure~

ElectronicsArchiver commented 2 years ago

Overview

luni64 commented 2 years ago

Wow, this is really nice. Thanks a lot for all the work. Would you mind placing something like "design by ElectronicsArchiver" on the pages? Honour where honour is due...

ElectronicsArchiver commented 2 years ago

Thanks.

Well I could add a contributors page, if you don't mind that~

luni64 commented 2 years ago

Thats a good idea. You could also mention @ihatemornings who did the 4051 extenison

ElectronicsArchiver commented 2 years ago

What did lunOptics do?

luni64 commented 2 years ago

lunOptics is just me from a test account

luni64 commented 2 years ago

So, I'll pull it into master then