Requesting communication with HydrusDev #49
Comments
|
Why would we need that? I don't follow. |
|
As Hydron is trying to be a faster alternative to Hydrus it would be great if Hydron can match most of the features from Hydrus in order to find ways of optimization. |
|
Optimization and dropping features that hinder performance come hand in
hand. I don't see much point in this. If there are specific features you
want, feel free to create issues and I will evaluate, if they are viable
and how best to implement them.
…On 19 September 2018 at 22:04, Donald Tsang ***@***.***> wrote:
As Hydron is trying to be a faster alternative to Hydrus it would be great
if Hydron can match most of the features from Hydrus in order to find ways
of optimization.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#49 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AHfPsIzCkQAo-vO5If-rJxGvJircOT09ks5ucpU7gaJpZM4Wwtj6>
.
|
|
Some of the big feature would be:
|
|
For reference https://8ch.net/hydrus/res/417.html |
Planned support multiple boorus and iqdb. Currently only support gelbooru.
What do you have in mind?
Already there but not as complete as the CLI yet.
What?
Planned.
I feel that is out of project scope. Hydron mostly targets file formats that are supported by boorus.
Ditto.
Planned.
Out of scope.
Ditto. |
|
@bakape update your list again, also when discussing file formats I would exclusively state a file reader for ebooks, audio, video, text (fanfic), WebP/FLIF, APNG, SWF. CAD and Office/Document files should have a trigger on the desktop to use native software to open |
Link dead.
If it is only opened by external applications, then that would not be any overhead-inducing complexity. I'll see to it at a later time. Working on other projects in the last few weeks. |
|
@bakape https://8ch.net/hydrus/res/471.html (sorry)
Hydrus is made to be a semi-universal file tagger, meant to replace traditional folder systems. |
These would be good to implement IMO. |
|
Need thumbnailer support first.
…On Wed, 26 Sep 2018, 09:05 チルノ, ***@***.***> wrote:
APNG, WebP, FLIF
These would be good to implement IMO.
Even if some browsers don't support them, ultimately it's up to the user,
and since this is a personal thing, it should be okay to implement.
APNG should be obvious, and FLIF is really cool.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#49 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AHfPsKdqtgXbsrl_7793efnnGY2_Ulkiks5uexlAgaJpZM4Wwtj6>
.
|
|
I'll make an issue for it, I should probably see what I can do about it as far as the Rust version goes, and if it's worth the effort. (e.g.: lack of possible libraries) |
|
Concerning the Rust version, it would probably be less work for you to
reuse the existing C code and call it from Rust.
…On Wed, 26 Sep 2018, 09:09 チルノ, ***@***.***> wrote:
I'll make an issue for it, I should probably see what I can do about it as
far as the Rust version goes, and if it's worth the effort. (e.g.: lack of
possible libraries)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#49 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AHfPsMyadDJ7GXFgNhqiOgsqou0vLp2zks5uexohgaJpZM4Wwtj6>
.
|
|
Depending on how things go, we might as well just use full C, but I'll leave that for the other thumbnailer issue if that does end up being the case. |
|
If you ask me, full C is more practical. You can then use this C
thumbnailer from Rust.
…On Wed, 26 Sep 2018, 12:10 チルノ, ***@***.***> wrote:
Depending on how things go, we might as well just use full C, but I'll
leave that for the other thumbnailer issue if that does end up being the
case.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#49 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AHfPsNaGKMmJFPR8Zv7bry36m4EmqOoJks5ue0SAgaJpZM4Wwtj6>
.
|
|
Well, the whole point of me even doing this in Rust is to git gud at it as well as fix the memory scaling issues. I guess the second point is kind of null since you're doing it in C, but fuck it. |
|
@Chiiruno I would say that swf, webm and mp4 support is important (see Danbooru and Derpibooru) |
|
Webm is already supported, not sure if MP4 is, but it should be. |
|
@Chiiruno wouldn't say that as there are too many good stuff in swf |
|
Without a doubt, but there's no point in implementing it in hydron. |
|
Seems like it does for some SWF formats. |
|
@bakape If I am going to be concrete, include FLIF, HEIF, BPG and SVG as images, and MP4, MKV, WEBM and OGV as video, with MP3, AAC, M4A, OGG, OPUS, WAV and FLAC as music. |
To share images and tags with friends or people who are a part of a "private file-sharing club" (/ptg/-style)
Tag synonyms and tag hierarchies, and also *booru downloaders that download tags along side images. |
Since there is no complete feature list or UML-esque document of Hydrus online, it would be helpful if you can contact the dev privately or go to the Hydrus Discord server to co-ordinate.
The text was updated successfully, but these errors were encountered: