Active Topics
-
The N900 is now 15 years old! (9)
to Nokia N900 by Arno_11 - 3 hrs, 53 mins ago -
Sailfish OS for the Motorola Moto G7 Power (XT1955-5) - (ocean) (4)
to SailfishOS by Maemish - 5 days, 16 hrs ago - more...
 |
|
2010-09-13
, 12:38
|
|
Posts: 2,853 |
Thanked: 968 times |
Joined on Nov 2005
|
#172
|
Originally Posted by jonnenau
Every minute, no... but each and every time I run DropN900, certainly ! Actually it's the only command I ran up to now (but see next post), and it's the only one not on the screen...
I have put a sync button to the main menu of the app now, I think this is fast enough accessAs you prolly wont do this every minute or so anyways. If not lets put a button to the main UI.
So yes, I'd still like a button down there with the rest :-)
__________________
maemo blog
maemo blog
|
|
2010-09-13
, 13:01
|
|
Posts: 2,853 |
Thanked: 968 times |
Joined on Nov 2005
|
#173
|
Originally Posted by jonnenau
Me again... I realize this has been a much asked-for and eagerly awaited feature... and I don't want to come across as a grumpy, ungrateful badger... but this new version of DropN900 actually works less well for me than the previous. Let me explain:
dropn900-0.1.5-3 now available as a download/update![/SIZE]
- Synchronization now goes both ways as follows
My main use for DropN900 is to easily bring (and update) to my N900 various unpackaged Python projects (mine or other people's) so I can try them out, or just use them, under Maemo5. I put these in a special subfolder of my Dropbox root on the PC, matching a subfolder of my dropbox root on the N900.
Up to now, one-way sync worked real well for this, but real two-way sync is almost useless : now DropN900 insists on uploading .pyo files, changed data and settings files, all sorts of stuff which is at best useless, and at worst pollutes the online Dropbox contents.
I see two ways I could have my setup back and still please the "real-sync" users :
* the easy one : implement whole directory download as already mentioned by 'slender'. With a "silent update" option it would be just like the old one-way sync :-)
* the better one : add a one-way/two-way choice in the sync settings. Or even let users define *two* local sync folders there, one being full-sync, the other one-way (or each with its own option, etc.)
What do you think ? :-)
PS: I do believe the eye candy in the (very nice) transfer window is responsible for most of the slowdown. Maybe a simpler UI, like plain scrolling text, would be less taxing.
__________________
maemo blog
maemo blog
 |
|
2010-09-13
, 13:38
|
|
Posts: 116 |
Thanked: 445 times |
Joined on Apr 2010
@ Oulu, Finland
|
#174
|
Originally Posted by fpp
I think for most this update brought what they wanted, you on the other hand have a slightly special use case. I could do in the setting to select both ul/dl or just one of them to happen when you sync. But better than that I think a filtering system defined by the user would be better. So you could filter extensions out of the upload/download sync, in your case you would add .pyo/.pyc files and you would be fine again? When you modify then .py files I guess you want to upload the working versions back? If not you can filter .py files also out of the upload.
Me again... I realize this has been a much asked-for and eagerly awaited feature... and I don't want to come across as a grumpy, ungrateful badger... but this new version of DropN900 actually works less well for me than the previous. Let me explain:
My main use for DropN900 is to easily bring (and update) to my N900 various unpackaged Python projects (mine or other people's) so I can try them out, or just use them, under Maemo5. I put these in a special subfolder of my Dropbox root on the PC, matching a subfolder of my dropbox root on the N900.
Up to now, one-way sync worked real well for this, but real two-way sync is almost useless : now DropN900 insists on uploading .pyo files, changed data and settings files, all sorts of stuff which is at best useless, and at worst pollutes the online Dropbox contents.
...
Would this fit your needs? Also I think the eye candy is not the problem but python + Qt, as said I would need to test this out with C++ to see if it would still be a problem. I certainly am not going to downgrade my ui to text only, as I am a ui freak and want everything looking nice. On the other hand if the usability starts to hurt to much then its a problems. I haven't gotten slow downs in transfers ui when having ~20 items. If you do syncs bigger than this every time i guess it might be a problem.
One solution for this would be to make one big sync item in the transfers thing and update that when the thing progresses, then you just wont have so detailed info (from, to, timestamp, time spent, size) for every single item but a combined thing. Maybe I'll do this, what do you think?
1) Filter out extensions from upload and download (eg. .pyc, .dll)
2) Make Transfers UI use a single sync status item that updates the combined state of the sync.
Any takers?
__________________
DropN900 - the maemo 5 DropBox client
DropN900 - the maemo 5 DropBox client
|
|
2010-09-13
, 15:34
|
|
Posts: 2,853 |
Thanked: 968 times |
Joined on Nov 2005
|
#175
|
Originally Posted by jonnenau
Thank you so much for listening and accomodating pesky users like me... actually I had thought of this but didn't dare propose it, as it seemed to be more work than the previous two solutions :-)
1) Filter out extensions from upload and download (eg. .pyc, .dll)
But yes, of course it would be just fine. Actually this is exactly what I already do between my 3 PCs and my Dropbox account itself, so having this filter capability also between Dropbox and my N900 would be ideal !
2) Make Transfers UI use a single sync status item that updates the combined state of the sync.
Any takers?
I just realized something I found wrong with the previous way of synch'ing :
1) first you got a (static) screen that told you how many files would be changed, and in which folders, before continuing. But you didn't know exactly _which_ files, so it wasn't always easy to decide.
2) you only found out which ones on the second, graphic-heavy, dynamic screen, but then they were already being downloaded...
So your new approach would correct both problems at once : first, a very detailed (but static) report of all that's going to happen (like in the new version) ; then a dynamic, but much lighter animation to show the sync progress.
I think it's worth trying. Oh, and the big red sync button too :-)
__________________
maemo blog
maemo blog
|
|
2010-09-13
, 18:13
|
|
Posts: 2,829 |
Thanked: 1,459 times |
Joined on Dec 2009
@ Finland
|
#176
|
Originally Posted by jonnenau
Yep. Actually IMO quite many apps take tad too long to start. Still Operas startup speed amazes me
.. Also the startup time is beginning to be quite long for dropn900. There are several thousand lines of code (haven't counted exactly) that it goes trough, numerous libs that it includes etc.
So yes, I have also tested with something like 192 small file downloads and the painting is too slow when DL/UL is going on and after that also, I just think its too heavy in general not while its loading other stuff. File upload/download is probably very heavy for the cpu, my "eye candy" animations should not be heavy at all compared to the real heavy lifting. If you really do this big syncs all the time (i suspect that you wont) just move slowly in the transfers window with your finger swipes and its better
Should not be heavy? Have you tested with just simple list without animations
And itīs true that I do not often do this kind of syncing.
....And no I don't think the own view/model thingie would be easy to make
Thanks for the feedback!
Itīs interesting to see that you have already thought about those things.btw. one more request.
- Ability to run sync from cli (with errorlevels and maybe option for animation 1/23..2/23 etc.) so that i can add it to scheduled tasks.
|
|
2010-09-19
, 19:10
|
|
Posts: 12 |
Thanked: 5 times |
Joined on Mar 2010
|
#177
|
Hi,
thanks for this great application, just a little request: If I delete some files from my pc the dropbox client delete them from the server, but if I try to sync the folder with DropN900 those files are not deleted from my N900 but they are uploaded to the Dropbox server, I think there is something wrong.
Many thanks.
thanks for this great application, just a little request: If I delete some files from my pc the dropbox client delete them from the server, but if I try to sync the folder with DropN900 those files are not deleted from my N900 but they are uploaded to the Dropbox server, I think there is something wrong.
Many thanks.
|
|
2010-09-19
, 19:43
|
|
Posts: 19 |
Thanked: 4 times |
Joined on Jun 2010
@ Atlanta, GA, USA
|
#178
|
I am absolutely loving this app. Thank you for creating this!
__________________
.
Thou shalt not follow the NULL pointer, coz at its end, all madness and chaos lie...
.
Thou shalt not follow the NULL pointer, coz at its end, all madness and chaos lie...
|
|
2010-09-20
, 07:01
|
|
Posts: 116 |
Thanked: 445 times |
Joined on Apr 2010
@ Oulu, Finland
|
#179
|
Originally Posted by bblue
Well this is exactly the kind of problem we get with the REST API. I don't get notification from the dropbox servers for deleted, new, renamed, update files so I could do the sync. The PC application gets them and is always connected to the dropbox server. When a file is not present on the server I can predict that two things has happened
Hi,
thanks for this great application, just a little request: If I delete some files from my pc the dropbox client delete them from the server, but if I try to sync the folder with DropN900 those files are not deleted from my N900 but they are uploaded to the Dropbox server, I think there is something wrong.
Many thanks.
1. The file is new, created by the user in the folder and he wants to upload it to server with sync.
2. This file is not present on server, so this file should be deleted?
I cannot predict what of these two scenarios has happened. I cannot ask the server for "history" or ask it if this was before there and I should delete it locally. I'm afraid this is a hard problem to figure out without getting some kind of notification from the server. Even the dropbox team has not done synchronization for the iPhone application (at least last time I checked) and these kind of things might be exactly the reason.
Hopefully the API will get better and I can go around this. Of course I could keep some kind of "last server history" of all the folders locally, this would be some work though. Other thing would be to ask "Do you want to upload or delete local files that are not present on the server?" or something, dunno. I think at this point you will have to go and delete the files manually, I didn't think of this when I made the upload sync but you are 100% correct that this is bad and should be fixed. I am currently abroad in Macedonia and cant dev maemo here easily so this will have to wait, sorry for this.
__________________
DropN900 - the maemo 5 DropBox client
DropN900 - the maemo 5 DropBox client
Last edited by jonnenau; 2010-09-20 at 07:05.
| The Following 2 Users Say Thank You to jonnenau For This Useful Post: | ||
|
|
2010-09-20
, 10:48
|
|
Posts: 12 |
Thanked: 5 times |
Joined on Mar 2010
|
#180
|
Originally Posted by jonnenau
Hi,
Well this is exactly the kind of problem we get with the REST API. I don't get notification from the dropbox servers for deleted, new, renamed, update files so I could do the sync. The PC application gets them and is always connected to the dropbox server. When a file is not present on the server I can predict that two things has happened
1. The file is new, created by the user in the folder and he wants to upload it to server with sync.
2. This file is not present on server, so this file should be deleted?
I cannot predict what of these two scenarios has happened. I cannot ask the server for "history" or ask it if this was before there and I should delete it locally. I'm afraid this is a hard problem to figure out without getting some kind of notification from the server. Even the dropbox team has not done synchronization for the iPhone application (at least last time I checked) and these kind of things might be exactly the reason.
Hopefully the API will get better and I can go around this. Of course I could keep some kind of "last server history" of all the folders locally, this would be some work though. Other thing would be to ask "Do you want to upload or delete local files that are not present on the server?" or something, dunno. I think at this point you will have to go and delete the files manually, I didn't think of this when I made the upload sync but you are 100% correct that this is bad and should be fixed. I am currently abroad in Macedonia and cant dev maemo here easily so this will have to wait, sorry for this.
thanks for your reply and efforts, I think to be able to select/unselect the files that are in the upload list can help (semi-automated sync).
So yes, I have also tested with something like 192 small file downloads and the painting is too slow when DL/UL is going on and after that also, I just think its too heavy in general not while its loading other stuff. File upload/download is probably very heavy for the cpu, my "eye candy" animations should not be heavy at all compared to the real heavy lifting. If you really do this big syncs all the time (i suspect that you wont) just move slowly in the transfers window with your finger swipes and its better
All the networking and file I/O is threaded. This is why you can move in the app while something heavy is happening in the first place. So this is the best I can do with python, I could change the transfers UI a bit to make it perform better, but really i dont think its the eye candy (read: nice stylesheets, some images) that is making it slow, its the high number of items added there, cause with ~20 you are fine scrolling how you like.
Also it should be fine to do other stuff in the main ui when sync is going on. As said its threaded so the thread will just wait for its turn to be executed. I think I have own pollers in both sync and normal action threads, so basically you would be running main + 2 extra threads if you do other actions, but in theory should be fine.
Possibility to select multiple files and download them
- This could be done if I do the new main UI with my own view/model but not easily with current. I haven't subclassed the items so it might be tricky to get actions out of them. Usually in Qt the widgets wont emit "mouseClicked/keyPressed" but you have to subclass the widget and reimplement the handling functions. QTreeWidget is really not able to support this kind of thing before you subclass it (and the QTreeItem to make your custom items), its just for basic usage that most people want, but for me its getting a bit too basic. Getting the load bars into the tree view when you double click them was a kind of a hack already and pushing the boundaries. I will probably remake the main ui at some point.
Possibility to download whole directory- This would be easy, just get the metadata if not there, download all the files. Could be coming.
Double click functionality- You mean double click on normal items, as folders already open/close? Yeah this could be, maybe select from settings what this does, example DL the item to your default location.
Long press functionalityAnd no I don't think the own view/model thingie would be easy to make
Thanks for the feedback!
DropN900 - the maemo 5 DropBox client
Last edited by jonnenau; 2010-09-13 at 11:51.