Core library of gTorrent which handles everything but UI/UX
License: GNU General Public License v3.0
Core library of gTorrent which handles everything but UI/UX
Example usage: https://gist.github.com/truNEET/5ace7c2503fe516150b7. This branch contains a small executable which loads the core to test basic functionality
Refer here
Maybe getTimeString(), getRateString() and such should be provided in their own namespace and have standard names and return values.
Thursday Jul 17, 2014 at 14:17 GMT
Originally opened as https://github.com/gtorrent/gTorrent-legacy/issues/59
Requesting a feature like that of rutorrent/rtorrent:
This would be useful for cross-seeding torrents. For example:
You have two torrent for 'lots of files'; torrent a and torrent b. Both torrents contain the same content. However, torrent a wants to create a directory called 'lots.of.files' while torrent b wants to create the directory 'lots_of_files'. To cross-seed in this situation, you would need to edit either torrent a's or torrent b's torrent file to match the directories.
With the "Don't add torrent's name to path" option, this would not be a problem. Users would not need to edit torrent files which in turn means cross-seeding with trackers that check torrent hashes would be possible.
Wednesday Jul 16, 2014 at 18:25 GMT
Originally opened as https://github.com/gtorrent/gTorrent-legacy/issues/41
The following list is almost done. Right now I'm polishing the rough edges. But I still am accepting suggestions to add to the list.
If you feel like a feature should belong in #70 feel free to move it there or comment down here if you can't.
Added incrementally as they are found.
To prevent features getting their own special unique 0.0.X, it's much better if you make a PR to a branch just for your own feature, so that when we do increment 0.0.X we can do it together with a bunch of other features that have also been confirmed to work.
Notes: Please try to work on this issues on a separate branch so that you can create partial PRs for other people to test before we actually merge it into master. When we merge into master the following should be done:
Hey guys, great to see the project starting back up. I'm going to start contributing again soon. Is there a place that we can all talk? Is the IRC dead?
best way would be to combine addTorrent and addMagnet, since i think we just need to check whether to use add_torrent_params.ti or add_torrent_params.url
otherwise we could duplicate the duplication check code (bad idea)
Compiler output:
http://pastebin.com/WqeB938U
Note: This is being built from the gtorrent-ncurses repository, if that changes anything
Thursday Jul 17, 2014 at 16:34 GMT
Originally opened as https://github.com/gtorrent/gTorrent-legacy/issues/77
We have a partial implementation of this.
On GNU/Linux: We will be using $XDG_CONFIG_HOME/gtorrent which usually translates to ~/.config/gtorrent
This is the working directory of gTorrent, it's where it will store:
On Windows: We will use -- No, let's not forget how retarded some Windows babbies can get. Some anon suggests %APPDATA%\gtorrent%APPDATA%\gtorrent for session related data and the user's home directory for configuration files. I +1 that.
On Mac: See GNU/Linux.
Obviously the fact that we'll have to split up where user configs and session data is stored makes this irritating as we can't use the same DIR. Therefore, on all core systems, there'll be two MACROs used to define where config/session data is stored, even if it is the same on GNU/Linux and Mac.
should just be in the build directory (./build/ if using scripts/install.sh)
See previous thread here: #68
Saturday Jul 19, 2014 at 00:44 GMT
Originally opened as https://github.com/gtorrent/gTorrent-legacy/issues/103
from some guy on IRC, can we test + merge this?
if( downloaded <= 0 )
{
ttd << string();
}
else
{
const string suffixes[] = { " B", " KB", " MB", " GB" };
const int maxoffset = sizeof( suffixes ) / sizeof( suffixes[0] );
int offset = floor( log( downloaded ) / log( 1024 ) );
if( offset >= maxoffset )
offset = maxoffset - 1;
ttd << fixed << setprecision(3) << downloaded / pow( 1024, offset ) << suffixes[offset];
}
return ttd.str();See documentation here: http://libtorrent.org/reference.html
Thursday Jul 17, 2014 at 14:38 GMT
Originally opened as https://github.com/gtorrent/gTorrent-legacy/issues/69
Similar to #59, but not exactly the same.
This feature offers the ability to store the current list of torrents and their statuses/properties preferably in gTorrent's own home directory and load them again the next time gTorrent is run.
This feature should still work if gTorrent is closed due to unexpected crashes, else an angry mob will lynch us.
.config/gtorrent.config/gtorrent
Wednesday Jul 16, 2014 at 22:40 GMT
Originally opened as https://github.com/gtorrent/gTorrent-legacy/issues/51
IMO logging isn't something a torrent client should implement. I would recommend either using an existing library like boost.log or moving it to another package.
While maybe not too critical just yet, we should start to think of how we would like to handle our plugin architecture. Our plugins should not be shipped as a dll or so file as we can't ensure that plugin authors would be willing to release source or target every platform.
If we decide to go this approach, that leaves us two strong scripting language canidates, Python or Lua.
What do you guys think? I'd love to start working on a branch and an RSS plugin as an example.
Wednesday Jul 16, 2014 at 14:03 GMT
Originally opened as https://github.com/gtorrent/gTorrent-legacy/issues/36
Friday Jul 18, 2014 at 07:31 GMT
Originally opened as https://github.com/gtorrent/gTorrent-legacy/issues/91
None
The way the all.h header file is included, using the CXX_FLAGS and as a relative path in the CMakeFile makes it so this can not be built as a submodule, or any other time cmake is ran outside of the main directory.
Friday Jul 18, 2014 at 13:45 GMT
Originally opened as https://github.com/gtorrent/gTorrent-legacy/issues/96
None
Thursday Jul 17, 2014 at 15:57 GMT
Originally opened as https://github.com/gtorrent/gTorrent-legacy/issues/76
Thursday Jul 17, 2014 at 23:09 GMT
Originally opened as https://github.com/gtorrent/gTorrent-legacy/issues/86
None
Thursday Jul 17, 2014 at 15:16 GMT
Originally opened as https://github.com/gtorrent/gTorrent-legacy/issues/70
Hold it, you might think. We haven't even released 0.1.0 yet, why are you making an issue for 0.2.0?
The purpose of this issue to take features we have come up with while working on 0.1.0 that we've noticed aren't appropriate for 0.1.0, so that we can move it here and forget about it and work on it later.
Tuesday Jul 15, 2014 at 17:04 GMT
Originally opened as https://github.com/gtorrent/gTorrent-legacy/issues/21
Installation of the binaries to /usr/bin etc. and the assets (i.e icons) to /usr/share/icons/
TODO: Read the PREFIX variable etc.
Thursday Jul 17, 2014 at 15:25 GMT
Originally opened as https://github.com/gtorrent/gTorrent-legacy/issues/72
Example:
Failed to fetch http://us.archive.ubuntu.com/ubuntu/pool/main/u/upstart/upstart_1.13-0ubuntu1_amd64.deb 404 Not Found [IP: 2001:67c:1562::13 80]
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?
A simple script should be used to either
A. Keep trying over and over agian, until it werks, wwww
B. Wait between each dependency download (? Will this actually help?)
Nonetheless, a script should be used to check why fetching has failed and to reattempt the update if it can establish that the error won't be repeated if a retry is made.
Notes: I have enabled caching but I see no hard evidence. In the event of confirming that Travis actually caches apt-get downloads, this issue can be closed.
If .config/gtorrent is owned by root, the message printed out is "process is not unique" (even though it is)
There's absolutely no reason to use recursion in processIsUnique()
Thursday Jul 17, 2014 at 14:18 GMT
Originally opened as https://github.com/gtorrent/gTorrent-legacy/issues/60
Thursday Jul 17, 2014 at 15:32 GMT
Originally opened as https://github.com/gtorrent/gTorrent-legacy/issues/73
[ ] Choose a unit-testing framework
[ ] Write tests
inb4 gt-core too small for unit-tests
can't hurt m8
Thursday Jul 17, 2014 at 16:36 GMT
Originally opened as https://github.com/gtorrent/gTorrent-legacy/issues/78
Wednesday Jul 16, 2014 at 10:48 GMT
Originally opened as https://github.com/gtorrent/gTorrent-legacy/issues/34
One of the original goals was to have a modules/plugins system to have 'optional features' that a user could install, and not have the client be bloated with features that a user does not want or use. It also opened up the possibility of non-gtorrent developers easily extending the client. It's pretty much the same thing that rutorrent does with their plugins.
Using Lua for the plugins was talked about, because it's very lightweight to ship the interpreter, but other languages like Python would work too.
Ideas for modules that could be implemented is:
I think we need to decide how (or if) a modules system is going to be implemented into the clients, hopefully in a toolkit-independent way. The earlier this is done, the better, as it allows for a lot more work to start happening once it is finished.
Thursday Jul 17, 2014 at 23:09 GMT
Originally opened as https://github.com/gtorrent/gTorrent-legacy/issues/87
None
Thursday Jul 17, 2014 at 15:19 GMT
Originally opened as https://github.com/gtorrent/gTorrent-legacy/issues/71
Client doesn't check to see if the existing torrent has been loaded or not.
Saturday Jul 19, 2014 at 05:48 GMT
Originally opened as https://github.com/gtorrent/gTorrent-legacy/issues/107
If you resume a torrent by readding the .torrent or magnet link, the downloaded and uploaded represent the amount since the program was started, not the total
void gt::Platform::makeSharedFile()
{
if(processIsUnique() && !checkDirExist("/tmp/gfeed")) //If the pipe already exists we'll just use it
if(mkfifo("/tmp/gfeed", 0755) == -1)
throw std::runtime_error("Couldn't create pipe! Check your permissions or if /tmp/gfeed exists");
fd = open("/tmp/gfeed", O_RDONLY | O_NONBLOCK); // TODO: use streams
if(fd == -1)
throw std::runtime_error("Couldn't open pipe");
if(ld == -1)
ld = open("/var/lock/gtorrent.lock", O_CREAT | O_RDONLY, 0600);
if(ld == -1)
throw std::runtime_error("Couldn't open pipe");
processIsUnique(); // a call here to lock the file
}/var/lock/gtorrent.lock is not the path we use for the lockld == -1 checks are redundant since processIsUnique will not return until ld != -1This is a legitimate post.
gtorrent-core is a formatting layer and that's about it. Most of the code that isn't remapping the libtorrent api is for features like file association, string formatting and core related setting files.. all of which are UI/UX related and should be client based code.
Why restrict the GUI developers by having them map libtorrent API calls from gtorrent-core then send a PR? Instead of poking holes in the wall when necessary just remove the whole damn wall.
I propose we remove the entire gtorrent-core code base and shift the scope of the gtorrent project to focus on the GUI development of gtorrent, using libtorrent directly. The whole purpose of this project was to create a torrent client that was lightweight and not bloated with adware, or, the utorrent killer.
I've spoken to fuyukaidesu on #gtorrent about this and he couldn't come up with any real reasons to keep gtorrent-core other than it being bothersome to switch the gtk branch over to using pure libtorrent.
I think we need to put our heads together and come up with a solid specification for the gt-core and it's interfaces.
Once we have the spec down, the gt-core code base will be much easier to maintain and we won't have all these merge problems where we end up with multiple accessors for the same variables (see: Torrent::getSize()/getWanted()/getTorrentSize()).
Also we'll have some real documentation- new UIs will be much easier to create.
Current implementation is a hash map with string keys to string values.
It's simple, but not effective.
Also a hash map is so fucking noob.
I propose creating a new class called SettingsOption, which will contain:
This could allow the config file to be self documenting when it's first generated.
Even though most config options should be self documenting by name alone.
Along the way we could consider:
The current Setting class will be replaced with a abstract Setting parent that will contain:
And other modules will inherit from it, adding their own options.
Sunday Jul 13, 2014 at 09:11 GMT
Originally opened as https://github.com/gtorrent/gTorrent-legacy/issues/4
So we can run as a daemon and have remote clients connect, the glorious UNIX way!
We should use cpplint for conformance with google's C++ style guidelines.
cppcheck and clang's analyzer for detecting logic bugs
Currently association is done in gt::Platform::associate
where the files ~/.local/share/applications/gtorrentt.desktop and ~/.local/share/applications/gtorrentm.desktop are created, generated and written.
After gtorrent gets typically uninstalled by the casual user, these desktop entries remain behind, like unpleasant love marks.
parts of boost we might use:
some of this is part of TR2...how do the TRs work?
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.