[archived] General discussion #44
Comments
|
Hi, thanks for your work ! Bonjour et merci pour votre travail ! |
|
@Salan54 bonne question. Je pense qu'on pourrait rajouter une option pour que les liens s'ouvrent avec |
|
http://myrepos.branchable.com/ great software if you manage multiple git repositories ( |
|
I am no fan of A couple of arguments about this topic: |
|
@Salan54 In fact I think I agree with @e2jk , you'd better use middle-click, or "open in new tab", as it allows you to control what links you want to open in a new tab. After thinking about it, I hate sites that force new tabs. It breaks the back button and spaws a myriad of tabs.
@e2jk your links were quite good :) Sold for me, we won't add this. @Salan54 Please read the links mentioned above, and if you really want to force new tabs (I think you don't), you can add |
|
J'ai lu avec beaucoup d'intérêt les liens indiqués par @e2jk. Je partage tout à fait sa position : il n'est pas souhaitable de forcer l'ouverture des liens dans un nouvel onglet depuis un site "standard". Mais Shaarli n'est pas un site "standard" mais un "annuaire de liens" et il me semble un peu extrême de vouloir appliquer ici la règle universelle. |
|
Hi there. I'm quite new to this fork community and its goals, so I went through your issue/PR list. I'm a bit confused about themes, templates and plugins. From what I understand :
While I understand the requirement, those features look poorly compatible between them. I suggest that themes should be placed inside one tpl directory (and those two would be merged). About plugins, there is not a lot we can do the way they're made, except being well documented for templates creator. And don't worry, I also know that's low priority. 🐃 |
|
@ArthurHoaro Good summary, thanks. Yes, we need to come up with a clean directory structure if we want to support third-party themes, templates and plugins. Themes and templates repos are currently experimental/unsupported, and serve the purpose of centralizing currently available ressources for Shaarli. Plugin support is not ready yet. They will need cleanup before they are actually usable. Your are right that the CSS files are template-specific. I'll post a directory/file structure proposal soon. |
|
Regarding the directory structure change: I think we should get the plugin system working first. Please help reviewing #52. This system makes use of raintpl includes. So the dir structure will be influenced by this. |
|
I am forwarding a discussion from Debian's security mailing list. So far:
So I think we meet the GPL requirements. Will ask for more info on the mailing list (I can't find a world-viewable archive of this list), comments are welcome. Edit: my reply to the mailing list: |
|
FYI I have created a Gitter chat room to discuss Shaarli. Have a look at https://gitter.im/shaarli/Shaarli |
|
v0.0.43beta released! Thanks to everyone involved. |
|
I've registered a bountysource project for Shaarli. Anyone can now vote for issues there instead of adding +1s to the bug tracker. You can also place bounties (starting with $5 I think) on bugs; anyone that fixes a bug on which a bounty has been placed can claim it. The bountysource badge is displayed in the main README. Sorting of plugin requests in #14 is almost over. The current plugin system implementation is on the I've started removing owners from the organization (people that have shown no sign of life since the fork). The remaining owners are @e2jk @sebsauvage @Sbgodin and myself. It think it's enough since we are active in maintaining the code/issues. @ArthurHoaro has write access to the templates repository. I've started reorganizing the shaarli-themes repo to make it compatible with 0.0.43beta and clean the stylesheets. I think we'll not implement a theme selector for several reasons; continuing in #22 |
|
Maybe you can add the bountysource link in the readme. EDIT: Uh nevermind. I was looking at my not updated fork repo. |
|
@ArthurHoaro it's on top, next to to the gitter link |
|
I think we could add some tag management/general organization tricks to the wiki, some have been discussed here #146 (comment) |
|
I've managed to use my IM client (pidgin) to login to https://gitter.im/shaarli/Shaarli. It's not straightforward so here is how to do it:
|
|
Another bookmark sharing and management web app: https://github.com/plainmade/unmark / https://unmark.it/. Added to the wiki. |
|
I've updated the milestones. Feedback welcome. 0.0.44beta will be released on Sunday after merging these patches. |
|
I think template support should be set before 1.0 milestone since it's an important change. Also I don't really see why #143 is in milestone 1.0 while most other minor (priority) improvements are in 1.1. But overall, that's great! |
|
You're right. Edited milestones. |
|
0.0.44beta released. Again, thanks to you all. |
|
0.0.45beta released, fixes 2 small bugs. |
|
Dans le linklist, pour l'affichage de l'url d'une note, ce ne serait pas mieux que ce soit une url absolue qui soit affichée? Ca me pertube un peu de n'avoir qu'un morceau d'url affichée entre les balises et |
|
Another interesting project that lists Shaarli: https://github.com/Kickball/awesome-selfhosted Contributions are welcome :) |
|
I wonder if a hashtag system would not be interesting. The idea is that, in the description, any word ahead of # is linked to ?searchtags=[theword] But maybe there is a potential difficulty of compatibility with a markdown plugin... |
|
I like the idea. There is no conflict with Markdown: |
|
Sorry but... what's the difference between the current tag system (_?searchtags=cms_) |
|
We should discuss that in #278. There is no difference, except it creates an automatic link when you write an #hashtag in the description. |
I retrieved @nodiscc plugin system proposed in #164 and changed it to create PHP plugin system. It relies on hooks triggered by certain actions (only template rendering for now). **It's only a proposition, let me know what you think of it**. * I think that an 'only template' plugin system might be too restrictive, and doesn't allow a lot of extension. * I raised concerns in #44 and don't blend too well with user made templates. * @nodiscc lacks of time to finish this. * I'd like to see 0.9beta release one day. :) PluginManager class includes enabled plugin PHP files at loading and register their hook function. When we want to trigger a hook, 'PluginManager::executeHooks()' is called, eventually with rendering data. It will call every plugin function registered under the standardized name: hook_<plugin_name>_<hook_name> Rendering data can be altered and/or completed. This is exactly what @nodiscc did. Templates contain plugin display at specific location, which are populated by the plugin functions. Here is what's has been done: * hook_render_linklist: when linklist is rendered, all links data passed to plugins. It allows plugins to alter link rendering (such as Markdown parsing). They can also add a linklist icon for every link (QRCode, etc.) * hook_render_header: every page builder triggers this hook. Plugins can add specific data to header if the current page is concerned (toolbar). * hook_render_footer: : every page builder triggers this hook. Plugins can add specific data to header if the current page is concerned (JS file). * hook_render_includes: : every page builder triggers this hook. Plugins can add specific data to header if the current page is concerned (CSS file). We can easily add hooks to whatever is pertinent (link add, picwal rendering, etc.). * Strong documentation, especially for plugin developers. * Unit tests for PluginManger and Router. * Test this heavily. Later: * finish Markdown plugin. * Add a plugin page in administration.
I retrieved @nodiscc plugin system proposed in shaarli#164 and changed it to create PHP plugin system. It relies on hooks triggered by certain actions (only template rendering for now). **It's only a proposition, let me know what you think of it**. * I think that an 'only template' plugin system might be too restrictive, and doesn't allow a lot of extension. * I raised concerns in shaarli#44 and don't blend too well with user made templates. * @nodiscc lacks of time to finish this. * I'd like to see 0.9beta release one day. :) PluginManager class includes enabled plugin PHP files at loading and register their hook function. When we want to trigger a hook, 'PluginManager::executeHooks()' is called, eventually with rendering data. It will call every plugin function registered under the standardized name: hook_<plugin_name>_<hook_name> Rendering data can be altered and/or completed. This is exactly what @nodiscc did. Templates contain plugin display at specific location, which are populated by the plugin functions. Here is what's has been done: * hook_render_linklist: when linklist is rendered, all links data passed to plugins. It allows plugins to alter link rendering (such as Markdown parsing). They can also add a linklist icon for every link (QRCode, etc.) * hook_render_header: every page builder triggers this hook. Plugins can add specific data to header if the current page is concerned (toolbar). * hook_render_footer: : every page builder triggers this hook. Plugins can add specific data to header if the current page is concerned (JS file). * hook_render_includes: : every page builder triggers this hook. Plugins can add specific data to header if the current page is concerned (CSS file). We can easily add hooks to whatever is pertinent (link add, picwal rendering, etc.). * Strong documentation, especially for plugin developers. * Unit tests for PluginManger and Router. * Test this heavily. Later: * finish Markdown plugin. * Add a plugin page in administration.
I retrieved @nodiscc plugin system proposed in shaarli#164 and changed it to create PHP plugin system. It relies on hooks triggered by certain actions (only template rendering for now). **It's only a proposition, let me know what you think of it**. * I think that an 'only template' plugin system might be too restrictive, and doesn't allow a lot of extension. * I raised concerns in shaarli#44 and don't blend too well with user made templates. * @nodiscc lacks of time to finish this. * I'd like to see 0.9beta release one day. :) PluginManager class includes enabled plugin PHP files at loading and register their hook function. When we want to trigger a hook, 'PluginManager::executeHooks()' is called, eventually with rendering data. It will call every plugin function registered under the standardized name: hook_<plugin_name>_<hook_name> Rendering data can be altered and/or completed. This is exactly what @nodiscc did. Templates contain plugin display at specific location, which are populated by the plugin functions. Here is what's has been done: * hook_render_linklist: when linklist is rendered, all links data passed to plugins. It allows plugins to alter link rendering (such as Markdown parsing). They can also add a linklist icon for every link (QRCode, etc.) * hook_render_header: every page builder triggers this hook. Plugins can add specific data to header if the current page is concerned (toolbar). * hook_render_footer: : every page builder triggers this hook. Plugins can add specific data to header if the current page is concerned (JS file). * hook_render_includes: : every page builder triggers this hook. Plugins can add specific data to header if the current page is concerned (CSS file). We can easily add hooks to whatever is pertinent (link add, picwal rendering, etc.). * Strong documentation, especially for plugin developers. * Unit tests for PluginManger and Router. * Test this heavily. Later: * finish Markdown plugin. * Add a plugin page in administration.
|
Time for a new release? There has been a fair amount of changes since 0.0.45beta, including bug fixes. |
|
Agreed :) What about adding intermediate milestones?
|
|
+1 for the release. I don't know about version standards, but anything would be better than 0.0.45. :) |
|
+1 for the release too :) |
|
Happy birthday shaarli/Shaarli and thanks everyone for keeping it flying |
|
🍰 \o/ 🍰 |
|
I have updated/rewritten shaarchiver and audio/video archival are working perfectly! If someone is able to help for the next step (downloading webpages in a logical way - calls to wget?), and other TODOs in |
|
I can help with CI stuff, dependency management and virtualenvs in Python 😈 Also, Shaarchiver could be integrated as a Shaarli plugin, to one-click archive media content :) |
|
The tool is in a very early stage, but if you'd like to write a simple test, I'm all ok! Always happy to learn. I like virtualenv but prefer to rely on my distro's package manager for dependencies. Being written in Python it would need wsgi to run server-side (no PHP frontend running Being a tool for locally archiving files I don't know if it makes sense to run it server-side. You could always setup a cron job for periodic runs though. |
|
Note: this is a draft, open to discussion -feel free to suggest a different/better versioning planning :) Note II: future tags should be both annotated and GPG-signed -working on it New milestonesThe current major Works In Progress are, by descending order of priority:
Intermediate milestones could be added as follows:
Past commitsHere's a suggestion for tagging past commits and switch to a new versioning scheme. This is a bit rough and artificial, but provides an overall idea of the progress that has been made lately :) Please note that the displayed version will still be v0.3.0
v0.2.0
v0.1.0
|
|
I agree about the new milestones. About versioning, let's release Is this ok? 0.3.0 is still > 0.0.45 and we don't have to create "artificial" releases/versions/tags. |
|
Works for me, I'll take care of:
|
|
GnuPG signature added to the wiki! Should we archive this discussion thread and open a new one? |
|
Nice work on the documentation, as always :) Future discussion should go in #308 |
General discussion about Shaarli, this fork, sharing interesting resources, whatever. Offtopic allowed.
https://github.com/shaarli/Shaarli/wiki
The text was updated successfully, but these errors were encountered: