Recent changes to feature-requests

Allow to copy the magnet link of shared files

2025-02-24T22:12:55.547000Z

Hi!

The other day i wanted to share a file with a friend and i wanted to give him the magnet link of a file i was sharing with gtkg.

Unfortunately there's no way to obtain them from the GUI.

I believe this would be beneficial and could bring more people to use gtkg as it would make it easier to share files.

#283 Better magnet link support

2020-11-03T15:38:35.254000Z

GTKG's magnet parser does not recognize the xt.n syntax. I'm still
wondering as to what it would do with various xt.n parameters knowing
that it currently only supports the urn:sha1: ones.

Why not search for each urn:sha1 ?

only urn:sha1 is supported? is it possible to add support to urn:bitprint ?

Conceivably, it would make sense to have xt.n recognized and it would
make sense for a magnet to hold different hashes for different
protocols, all in one magnet. But this is not what you are talking
about here in your request.

Correct, that's not what i'm referring to. Magnet links can support several files.

xt also allows for a group setting. Multiple files can be included by
adding a count number preceded by a dot (".") to each link parameter.

magnet:?xt.1=[ URN of the first file]&xt.2=[ URN of the second file]

From wikipedia: https://en.wikipedia.org/wiki/Magnet_URI_scheme

I'm just realizing that this can open a can of worms....

The part on dn+xt creating an entry in the search with the dn but really
looking for the SHA1 is a good idea, although of course it would do
both of these things at the same time. SHA1 are searched through the
DHT (Distributed Hash Table) and file names through Gnutella queries.

I like that :-)

#283 Better magnet link support

2020-11-03T13:53:38.746000Z

GTKG's magnet parser does not recognize the xt.n syntax. I'm still wondering as to what it would do with various xt.n parameters knowing that it currently only supports the urn:sha1: ones.

Also, what would it mean to have two urn:sha1: listed, especially if they are different... ?

Conceivably, it would make sense to have xt.n recognized and it would make sense for a magnet to hold different hashes for different protocols, all in one magnet. But this is not what you are talking about here in your request.

The part on dn+xt creating an entry in the search with the dn but really looking for the SHA1 is a good idea, although of course it would do both of these things at the same time. SHA1 are searched through the DHT (Distributed Hash Table) and file names through Gnutella queries. I confess I would have to look at the code to know exactly what happens today in that case and whether it works already as suggested here.

Better magnet link support

2020-11-02T19:46:35.668000Z

New features i would like to have:
1- Support multiple files in the magnet link. A magnet link can contain several files. Example from the spec:
magnet:?xt.1=urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C&xt.2=urn:sha1:TXGCZQTH26NL6OUQAJJPFALHG2LTGBC7

However gtkg doesn't seem to do anything with this :-(

2- Better support of the "dn" parameter of the magnet link.
I do a normal search, then i right click on a result and copy the magnet. Then from the magnet link i remove all the parameters except the "xt" and the "dn". I change the "dn" parameter value. After that i add it on gtkg.
There will be an entry in the download tab, but without any sources (0/0/0). It won't move from this state.

My suggestion would be to create a search with the dn as the label, but it would search for the sha1, instead of going directly to the downloads tab

#282 OSX version of 1.2.0

2020-08-01T01:16:53.971000Z

Took a bit longer to load, but yes.

note - I got the following crash on first load, so I removed the ibz.1.dylib file and it worked -

#282 OSX version of 1.2.0

2020-07-31T07:44:22.107000Z

status: open --> open-accepted
assigned_to: Raphael Manfredi

#282 OSX version of 1.2.0

2020-07-31T07:43:48.760000Z

Hello, I have just uploaded the binary to sourceforge.
Can you please let me know if it installs and runs correctly?

I was not able to upload it before because the Travis CI on OSX was not working at the time of the release, so this is not exactly 1.2 that I uploaded, but the current devel version (close enough to 1.2, but still, that's why I need validation that it runs!).

Thanks!

OSX version of 1.2.0

2020-07-29T05:13:02.818000Z

When will the OSX version of 1.2.0 become available to download?

OSX version of 1.2.0

2020-07-29T05:13:02.818000Z

Ticket 282 has been modified: OSX version of 1.2.0
Edited By: Raphael Manfredi (rmanfredi)
Status updated: u'open' => u'open-accepted'
Owner updated: None => u'rmanfredi'

use LZMA compression for source tarball

2017-10-07T07:49:09.882000Z

Using xz format decreases by 5% the size of the source code tarball :

j@j:~$ bunzip2 --stdout gtk-gnutella-1.1.12.tar.bz2 | xz -9 --stdout > gtk-gnutella-1.1.12.tar.xz
j@j:~$ ls -l gtk-gnutella*tar*
-rw-rw-r-- 1 j j 20075956 oct.   7 08:30 gtk-gnutella-1.1.12.tar.bz2
-rw-rw-r-- 1 j j 19178144 oct.   7 09:43 gtk-gnutella-1.1.12.tar.xz
j@j:~$