Suggestion: Optional and closable widgets

[tariqbuilds]

Suggestion: Optional and closable widgets

[commonquail]

Am I understanding you correctly that you would like support for plug-in-like widgets? That's something that's been suggested a few times and, I think, a very good idea. It's tricky, though. You need to be able to detect all enabled widgets as well as generate the necessary HTML/JS to query and display those widgets, and you need a framework that makes it easy to build and configure widgets in the first place.

I'm playing around with some ideas to solve those problems but I haven't gotten far enough to conclude whether they'll work, let alone show them off. I'd need to make other changes before I can get much further with this, too, so that'll have to take priority.

In the meantime, if you want to go ahead with this, you can fork the repository and make a separate branch for your widget. Periodically pull in changes from this repository and rebase your branch on top of master. I would avoid pushing this branch if possible; if you rebase you will have to force-push and if you merge you will end up with a lot of merge commits.

[geirawsm]

Yes, you understood me. Fortunately Deluge runs in a terminal command, so I think I can pull put information easily, but I will see how it goes and check back on it.

Also, I'm a Git-n00b, so I will read up on those instructions first before I do anything else ;)

[commonquail]

Take a look at the forking tutorial. Note that it uses merge instead of rebase. Merging is easier and faster for the developer doing the work but it generally pushes that workload elsewhere (specifically to reviewers). Rebasing is overall more work for the individual developer but it makes for easier reviews and cleaner histories. If this seems silly to you, I find that you kind of have to understand rebasing to fully appreciate this effect.

One important thing none of the GitHub tutorials explain is that you should always make pull requests on a separate branch. If you push your changes to your master and submit a pull request from there, whenever you make changes in the future that pull request will update -- nobody wants that. That said, if you're working on an optional widget, unless we make a decision down the line to include a folder of optional widgets it probably shouldn't be a pull request at all, so I don't think you have to worry about this.

Workflow sketch:

# Make a new branch and check it out immediately.
git checkout -b deluge
# code code code
git add [-p]
git commit
...
# Get new stuff.
git fetch upstream # I prefer fetch because I think pull does too much.
git checkout master # If you use pull, be sure to do this first.
git rebase upstream/master # If you have made any changes to master you'll have to merge.
# Now synchronise your branch.
git checkout deluge
git rebase master

Occasionally you may get a merge conflict while rebasing. Don't be afraid of this -- it's just like a merge conflict when merging and Git tells you everything you need to do:

# Launch a tool to help you resolve conflicts.
git mergetool
...
# No more conflicts?
git rebase --continue
# Confused? Afraid to continue? Want to try something else?
git rebase --abort

[geirawsm]

Wow, I was going to read what I could about it, but you got to writing it down before I got the chance, thanks 👍

I'll close this issue in the meantime.

[geirawsm]

I tried figuring this out, but had to give up. Wasn't able to pull in the info from console at all into the php at all because of lack of knowledge.

[commonquail]

Did you look at shell_exec()?

[geirawsm]

Yes, I tried that as well. It seems that normal shell commands works just fine, but deluge-console info doesn't get through. I do notice that it takes about 5 seconds from the command is run in bash untill the output shows, but I'm unsure if this is the problem. I have to find out more about this before trying again.