search

yoyurec / logseq-banners-plugin

136 stars 11 forks source link

Integration with Awesome Links plugin #62

Open stdword opened 1 year ago

stdword commented 1 year ago

Idea There is a way to set an icon in Banners plugin and in Awesome Links plugin. This is a very cool functionality!

But there are problems when I using this plugins in conjunction with each other:

  1. Setup AwesomeLinks inheritance feature to look to the property page-type:
  2. Setup Banners advanced config feature to look to the same property page-type:
  3. Let's create pages with different icon configurations:
Icon Setting Method Page Content Result
Simple icon property ✅
Banners advanced config ✅
Inheritance 🚫 Banners missing feature: Inheritance. Plugin should inherit icon, banner, and other properties like Awesome Links does
Proxy inheritance 🚫 Banners missing feature: Inheritance. Plugin should inherit icon, banner, and other properties like Awesome Links does

❗️❗️❗️ Related ticket from Awesome Links plugin: here. ❗️❗️❗️ Please, NOTE: these cases are different, but with the same first steps.

yoyurec commented 1 year ago

in the Banners plugin, config with custom props was created as inheriting via JSON before inheriting via props was introduced in Awesome Links... now it's not just a bug, it's a conflict! Looks like the banners config needs to get rid of icon field. In other cases with both inherit - how to decide a winner?

PS: according to active users/downloads amount - Banners icon settings should win )))

stdword commented 1 year ago

My thoughts here:

  1. From the product point of view: inheriting system in Awesome Links is more agile and handy to setup, then a list of json strings
  2. From simple Logseq user point of view: it is better to handle all stuff inside Logseq with an easy UX. People, not familiar with development don't know how to use JSON. And I think they deserve to use such a cool app like Logseq. Moreover: I believe in near future Logseq can be a very popular tool for thousands of them.
  3. From the backwards compatibility point of view: users/dowbloads — a good metric here (agree with you). Banners config can have a first priority.
  4. My point of view: may be it is make sense to join these plugins into one? The both handle decorations of page and link to it.
yoyurec commented 1 year ago

1,2 - agree

  1. From the backwards compatibility point of view: users/dowbloads — a good metric here (agree with you). Banners config can have a first priority.

but i have no stats about JSON usage )) i think it's small amount of ppl and most for simple things like page-type like here https://twitter.com/gijigae/status/1544826000260796416

JSON was introduced just to make life easier to not copy-paste same icon+banner prop to similar pages. i think to drop JSON and do inheriting with hope it will not broke users settings )

  1. My point of view: may be it is make sense to join these plugins into one? The both handle decorations of page and link to it.

they do different things. plus i just splitted AwesomeLinks fomr Solarized Extended due to many things in one plugin )))

stdword commented 1 year ago

i think to drop JSON and do inheriting with hope it will not broke users settings ) 🔥🔥🔥 That will be totally unambiguous and very cool!