Basic support is now working, when you dnd something on the
FileView object, it'll reply what has been dropped. Now the
piece of code missing is what to do with that information
when it's been dropped
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Instead of applying the drop to the m_tree widget in the
FileView object, it should apply to the entire window then
the file url's dropped, should be added to the currently
visible FileView object, that way it's very general and you
can drop anywhere as opposed to just on the FileView, which
is kinda specific
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Created a new Window object, Window_DND, which basically
applies a DND functionality on that window, then I made
Window_Main and Window_Download derive from it, since I
reckon those windows are the ones which make sense to allow
drops onto.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When you DND multiple files onto the interface, it'll open a
side panel to the Window_Download object, which shows your
list of downloads you have open, of course, the user could
"force" this panel open even though he has only one download
open, but thats irrelevant, if he wants to do that, fine.
It's pretty cool, slides out of the side of the window over
a period of a few seconds
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Found bug where if you drop multiple files onto the
interface, it'll add another item to the Queue drop down menu.
Along these lines, I'd like to be able to change a file's
queue it belongs in by changing this drop down. You'd be
able to change a file to another queue by selecting a new
queue for it.
To move a file between a queue like this would require:
1) Copy from the queue's FileView object to the new
queue's FileView object, removing it from the original
2) Move the actual file on disk to the new folder for the
other queue, if of course, the file is partly downloaded.
HOWEVER, there is a problem with multiple queues, see (1) so
wait until thats resolved before bothering
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Fixed the bug with dragging files onto the interface would
result in multiple duplications of the queue in the drop
down menu. Was calling Window_Download::Show() each time I
dropped another file, even though I already call
Window_Download::Show(), and it's stupid to do so in the
Window_Download::AddDownload(url) method anyway
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Need to hook up some code that changes what detauls are
shown in the Window_Download object
I implemented code to do this, but now it crashes,
mysteriously along the same lines as when I would remove a
queue, it would complain about the stamp being invalid and
then something about peeking.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Fixed this bug, apparently when you remove a row from a
tree/list view, you emit a selection changed signal, if of
course you've connected a signal to the changed slot in a
selection object, so when you remove a row, you'll emit this
signal, execute the callback then of course if you attempt
to mess around with iterators for that tree/list view,
you'll be getting the rror with iter->stamp and all that
nonsense. So you must disable the signal, remove what you
want, the re-enable it after you're done.
Now I need to do two things:
1) When I have multiple download in the window, clicking
ok will add all of them
2) when you change the Queue in the drop down menu,
Adding the downloads will add them to different queue's
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Item 1 of my immediate above list is complete, when you add
multiple downloads, then ok, it'll correctly add those to
the Download queue
Item 2 is partly completed, you can choose a different queue
regardless of which you dropped the download onto. The
limitation is that your selection applies to the entire list
of downloads you dropped. But this is similar to not having
a custom Queue options per download, I guess if I solve that
problem, I solve this one almost immediately afterwards.
But you cannot change the queue of an existing download, say
to move it to another queue
** would moving a download to another queue, involve
deleting the existing file in the other queue directory or
leaving it alone?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Now you can select multiple files, change their options and
ok them all, if they are new downloads, they'll be added and
follow the options you've set. If they are existing
downloads, they'll update and continue as set. Also ok'ing
a list of downloads where some of them are existing files
and some of them are new files just dnd'd to the window,
will only add the new ones, which is correct behaviour.
Also now you can change the qeue of each dl and it'll change
to the appropriate queue, the only limitation to this is
that it'll only change the queue, it wont actually move it
to the new FileView within the new queue.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=682144
Basic support is now working, when you dnd something on the
FileView object, it'll reply what has been dropped. Now the
piece of code missing is what to do with that information
when it's been dropped
Logged In: YES
user_id=682144
Instead of applying the drop to the m_tree widget in the
FileView object, it should apply to the entire window then
the file url's dropped, should be added to the currently
visible FileView object, that way it's very general and you
can drop anywhere as opposed to just on the FileView, which
is kinda specific
Logged In: YES
user_id=682144
Created a new Window object, Window_DND, which basically
applies a DND functionality on that window, then I made
Window_Main and Window_Download derive from it, since I
reckon those windows are the ones which make sense to allow
drops onto.
Logged In: YES
user_id=682144
When you DND multiple files onto the interface, it'll open a
side panel to the Window_Download object, which shows your
list of downloads you have open, of course, the user could
"force" this panel open even though he has only one download
open, but thats irrelevant, if he wants to do that, fine.
It's pretty cool, slides out of the side of the window over
a period of a few seconds
Logged In: YES
user_id=682144
Found bug where if you drop multiple files onto the
interface, it'll add another item to the Queue drop down menu.
Along these lines, I'd like to be able to change a file's
queue it belongs in by changing this drop down. You'd be
able to change a file to another queue by selecting a new
queue for it.
To move a file between a queue like this would require:
1) Copy from the queue's FileView object to the new
queue's FileView object, removing it from the original
2) Move the actual file on disk to the new folder for the
other queue, if of course, the file is partly downloaded.
HOWEVER, there is a problem with multiple queues, see (1) so
wait until thats resolved before bothering
Logged In: YES
user_id=682144
Fixed the bug with dragging files onto the interface would
result in multiple duplications of the queue in the drop
down menu. Was calling Window_Download::Show() each time I
dropped another file, even though I already call
Window_Download::Show(), and it's stupid to do so in the
Window_Download::AddDownload(url) method anyway
Logged In: YES
user_id=682144
Need to hook up some code that changes what detauls are
shown in the Window_Download object
I implemented code to do this, but now it crashes,
mysteriously along the same lines as when I would remove a
queue, it would complain about the stamp being invalid and
then something about peeking.
Logged In: YES
user_id=682144
Fixed this bug, apparently when you remove a row from a
tree/list view, you emit a selection changed signal, if of
course you've connected a signal to the changed slot in a
selection object, so when you remove a row, you'll emit this
signal, execute the callback then of course if you attempt
to mess around with iterators for that tree/list view,
you'll be getting the rror with iter->stamp and all that
nonsense. So you must disable the signal, remove what you
want, the re-enable it after you're done.
Now I need to do two things:
1) When I have multiple download in the window, clicking
ok will add all of them
2) when you change the Queue in the drop down menu,
Adding the downloads will add them to different queue's
Logged In: YES
user_id=682144
Item 1 of my immediate above list is complete, when you add
multiple downloads, then ok, it'll correctly add those to
the Download queue
Item 2 is partly completed, you can choose a different queue
regardless of which you dropped the download onto. The
limitation is that your selection applies to the entire list
of downloads you dropped. But this is similar to not having
a custom Queue options per download, I guess if I solve that
problem, I solve this one almost immediately afterwards.
But you cannot change the queue of an existing download, say
to move it to another queue
** would moving a download to another queue, involve
deleting the existing file in the other queue directory or
leaving it alone?
Logged In: YES
user_id=682144
Now you can select multiple files, change their options and
ok them all, if they are new downloads, they'll be added and
follow the options you've set. If they are existing
downloads, they'll update and continue as set. Also ok'ing
a list of downloads where some of them are existing files
and some of them are new files just dnd'd to the window,
will only add the new ones, which is correct behaviour.
Also now you can change the qeue of each dl and it'll change
to the appropriate queue, the only limitation to this is
that it'll only change the queue, it wont actually move it
to the new FileView within the new queue.