search

ohenley / awesome-ada

A curated list of awesome resources related to the Ada and SPARK programming language
Creative Commons Zero v1.0 Universal
641 stars 71 forks source link

Move many libraries and bindings to relavant sections #58

Closed onox closed 4 years ago

onox commented 4 years ago

The Libraries section at the end was a large collection of all kinds of different libraries and bindings and contained some duplicates. I have moved most of them to their relevant sections so that they are easier to find.

I have added some new projects as well: AXMPP, dcf-ada, weechat-ada, weechat-canberra, and weechat-emoji.

See the description in the commit message for a list of all the changes.

ohenley commented 4 years ago

Great initiative.

It hitches me a bit that those binding project's description does not ALL explicitly advertises as , plain and mean. This list should promote Ada first as in 100% Ada codebase and anything else should warn as such.

Maybe we can live with some 'less explicit formulation' like 'API', 'interface library' etc for the time being ... and maybe I could come back to amend those of a visual tag, a 'binding' legend.

Thanks for the work.

onox commented 4 years ago

We should indeed indicate the type of projects, whether they are 100% Ada or depend on C libraries for example. We could use tables instead of bullet lists for this, for example:

image

What do you think? The 'License' column contains SPDX license identifiers.

ohenley commented 3 years ago

I do not know really. I am hesitating here for the following reasons:

a) The default 'awesome list format' is one-liners, not tables. (Well, last time I checked) b) Markdown tables are cumbersome to maintain ... the formatting, IMO. c) The real estate doubles with tables. d) Can we hide the table lines because as-is they let me cold a bit?

Personally, I was more inclined to use icons/legend to distinguish library, binding, pure Ada, etc. something like:

For the licenses ... I do not know, never thought about adding them.

I think we might need other opinions.

Thanks for the brainstorm btw.

onox commented 3 years ago

Tables are indeed a bit cumbersome to edit. I considered adding license badges, but that would spam img.shields.io quite a bit. I like your use of the emojis. For now we can use a :green_circle: for 100% Ada (including non-system dependencies) and :orange_circle: for projects that use or depend on non-Ada code (like bindings).

ohenley commented 3 years ago

Inviting people so they can chip in if they have opinions/ideas on the matter. Thx guys.

thindil commented 3 years ago

As far I checked, other awesome lists don't have tables, thus I agree with @ohenley on that matter. And I agree with @onox on opinion about emojis :smile: My guess: the general idea about awesome lists is to have something almost in plain text. If someone wants to make it good-looking, there are a few external websites for that: example

I think about type - in my opinion, it could be better if we (for example) do something like super categories: libraries and bindings and then split them on computing, GUI, etc.

Licenses - maybe just a plain text? Like link - description here. GPL-2?

onox commented 3 years ago

I think about type - in my opinion, it could be better if we (for example) do something like super categories: libraries and bindings and then split them on computing, GUI, etc.

That would mean that people need to look at 2 places when they look for something that can help them solve a problem. So appending a :green_circle: and :orange_circle: sounds better to me.

Licenses - maybe just a plain text? Like link - description here. GPL-2?

We can add the SPDX identifier (plain text) of the project.

Fabien-Chouteau commented 3 years ago

Inviting people so they can chip in if they have opinions/ideas on the matter. Thx guys.

I like the idea that the bindings are mixed with the other projects and sorted by topics. I personally think that a binding to an existing and maintain library brings more to the ecosystem than a partial rewrite in Ada or SPARK.

I think it would be also useful to tell which project is available in Alire.

reznikmm commented 3 years ago

The approach with a :green_circle: and :orange_circle: looks fine. SPDX could be long, like GPL-3.0-or-later with GCC-exception-3.1 and not precise, because each file can have another license. I wouldn't bother with license at all.

thindil commented 3 years ago

Every new solution causes new problems :)

I agree that it can look better, but it still needs some work:

  1. If we want to use emojis, they must be in different shapes. I think the list should be accessible for everyone also for visual impaired people too. And if there will be only difference in colors, color blinded people will don't notice the difference. Thus, my proposition: use square emoji for libraries and circle for bindings. Or any other shapes?
  2. If you add only emoji it may be not visible for screen-readers or braille screens (especially the last one). Also, if someone uses some unique font (without full Unicode support) or read it on a terminal without Unicode support, will also not notice symbols. Thus, I propose that full info as (an example, icons should be different): ⚫ library and ◾ binding or something like this. Unless you want to do these symbols as images. Then just image can be, because we can add alt option to it. Just the image will be unfriendly to read that file on the terminal.

About license: I agree with @reznikmm :smile: but also: SPDX was designed only for Open Source licenses. And we have here also proprietary software here, thus it cannot be labeled with SPDX :smile: Maybe left license info as an optional parameter?

@Fabien-Chouteau Alire: while I like the idea of having it, I think that list isn't the best place to put that information. What happens when we have been any other package manager for Ada someday? We will add it to the list also? As far I saw, even Rust list don't have info about availability of a package in their cargo system.

Fabien-Chouteau commented 3 years ago

What happens when we have been any other package manager for Ada someday?

Ada waited 37 years for its first package manager, even if this low probability event occurs it won't be difficult to change this document.

I think using the tag would be a great addition :

We will add it to the list also? As far I saw, even Rust list don't have info about availability of a package in their cargo system.

In don't think this comparison is fair, in the Rust ecosystem everything is on Cargo, so there is no need to mention it

Fabien-Chouteau commented 3 years ago

Also, some Rust awesome lists do use Cargo badges : https://github.com/rust-embedded/awesome-embedded-rust

thindil commented 3 years ago

I'm sorry @Fabien-Chouteau, but I'm still stubborn and don't agree with you about the badge. Especially a badge as a graphical element. In my opinion the main problem is how we both see the list. I wish to keep it with the main awesome list style: like a table of contents, with minimal, crucial information only. Links only to projects and nothing more (I even don't like these miniatures of books here :smile: ). Like the main awesome list. You want to do from it full documentation in one file :wink: I'm not sure if it is even allowed in awesome lists format.

Anyway I think I would be nice to get to know an opinion of the others on this issue cough cough @ohenley please enable discussions in the repository cough cough :smile:

mosteo commented 3 years ago

I'd keep libraries/bindings together, for the reason that the ultimate purpose is to able to use something from Ada.

I'm an information nerd so I tend to favor detail. I love dashboards. That said, in this case I'd go with the plain text (no tables) awesome style. Perhaps use different icons at the end to signal properties, e.g.: ⚙📦💧🅐⚖ (runnable/library/binding/Alire/link to license). But it may look cramped/overwhelming and the icons should have a similar style to be pleasing to the eye.

As interested party wrt Alire I'm not sure how much I should comment on that. A single icon would be enough for the important bit of whether it is indexed. Bonus if linked to its Alire page to quickly check the version. The badge is nice though, if it could be made smaller/less intrusive.

onox commented 3 years ago

So something like this?

:green_circle: = library :orange_square: = binding :package: = link to Alire crate