Autogenerate will come. I just don't have any infrastructure for it yet. It requires something completely different to the way thumbnails and deficons are loaded.
Hi @orgin @ broadblues #29 Errm, so you didn't spot the "New" gadget then?
Yep, that's the problem! I started out wrong so I saw the "delete" button and pressed that. OK, with what little brain I have, couldn't figure out-- "New what"? If you don't have anything then 'new' is kind of illogical, isn't it? How about more logic, If I had a list of buttons, then "new'' is going to erase all my buttons. I'm not going that. So, the interface presents me with this dilemma of what to do? In these 'all or nothing' decisions, I usually just quit and leave.
@ orgin I don't understand anything of what you are saying. Me neither! Your program is a real 'tripper'! I'm not saying that in a derogatory manner. It's the logic of FILER that I have difficulty with. For example, the "Copy" and "Move" file functions with menu buttons, before you introduced 'drag and drop', had to entered backwards to work, i.e., 'Source'=destination and 'Destination'=source. Huh? What happened to 'From'=source and 'To'=destination; just in E-mail reference. BTW, nice work on the 'drag and drop' file functions' which solved the obtuse button selections. I'm actually 'shy' to use FILER in daily file use. I'm having a problem with confidence.
"New" creates a new empty userbutton that you have to enter data into. "Delete" deletes currently selected userbutton and selects the next one if there is one. "Delete All" deletes all userbuttons, after a confirmation requester.
About source/destination:
The logic with the default setting is that a button should always state what would happen if you clicked on it (Ie, normal HCI nomenclature). That is, the text "set source" means that source will be set if you click this button.
The reverse option simply turns it into a toggle button that states the mode that is currently active. (Compare to: I am pressed/I am not pressed)
backwards to work, i.e., 'Source'=destination and 'Destination'=source. Huh?
Try going to Filer's Prefs, and ticking/unticking the "Reverse source/dest button" option.
I found Filer's default behaviour to be very confusing too (although it is that way due to a certain way of thinking/logic). Ticking the above option makes it show Source in the source/from lister, which makes FAR more sense to me! (And I'd bet it makes more sense to most people...)
- Add background task "Thumber" for automatic thumbnail generation
- Add settings for ignored devices for thumbnails
- Add setting for activating automatic thumbnail creation
- Fix rapid parent lockup
@ChrisH
Can you see if the lockup still happens for you?
When I got it to happen it was when IIntuition->RefreshWindowFrame() was called. For some reason it locked up. Perhaps because intuition wasn't done with the gadget layout, causing it into a race condition. But that's just a guess.
Yeah, I'm very impressed too. Exellent work, Orgin! Thumbnail creation works very good, so far. Maybe toolbar icon, to switch on/off automatic creation, would be good idea?
Great work, getting more interesting for me with every revision
Any change of adding a possiblity to create larger thumnails then 64x64 ? 100 would be nice, but I'd like to choose any size i'd want. And how about basic operations on the images like rotate ? Possible ?
But I have another issue in the about page of the FilerPrefs, ill be crazy to use the "FilerPrefs 53.30 (31.1.2010)" variable, how I can manage it as I would like to align it and make it italic/bolder ?
Now my string at the bottom of the window look like:
That string is from the program version string, it's not managed by the localization files. Done that way so that there will never be a mismatch between them.
I'll check why the locale string is not the same in both apps.
Dunnu, just to do some math for you. All thumbnails are stored in the same size* (64*64) and then scaled to fit whatever size you set in filer prefs when they are loaded from the thumbnail directory.
Letting you select 100*100 in prefs would mean that I either would have to store them all in a larger size or scale them up from 64*64.
Storing them all in 100*100 would use up 2.44 times more memory and take 2.44 times longer to load.
Storing them all in 128*128 would use up 4 times more memory and take 4 times longed to load.
I originally intended to use 32*32 (4 times faster than now) or 48*48 (1.8 times faster than now) but opted for 64*64 since that's the size used by the new icon theme in 4.1u1, even though it's significantly slower.
So sure I could easily let you use even larger sizes, but the question is if it would really be worth it in terms of speed and memory consumption.
* Images smaller than 64*64 are not scaled up so they don't use the full 64*64 size in the thumbnail directory
I just thought I would also second the request for support for larger thumbnails as at modern high resolutions you can't really see that they are anyway at sizes smaller than 64x64 so their usefulness seems limited to me. But if could just be I am getting older and my eye site could be better.
I would also love to see a thumbnail grid mode as well if like the "image" view mode under dopus9 for windows if possible.
Sam440ep 667mhz 512megs OS4.1 + Minimig, 4MB RAM, ARM add-on board WinUae 2.3.2, OS 3.9, BB2, Catweasel MkIV Amiga 1200, BlizzardPPC 060/200 with SCSI, mediatorSX, Voodoo3, pci lan
Letting you select 100*100 in prefs would mean that I either would have to store them all in a larger size or scale them up from 64*64.
Why? Why not just generate & store them at 100*100 when it is asked? If it happens to find a "wrongly-sized" thumbnail, then it can just regenerate that thumbnail.
BTW, does the thumbnail cache check file dates? It would make sense to invalidate/regenerate them if the date changes (say due to someone using a shell program to rotate the picture). You can set the thumbnail cache's filedate to the same as the original file's.
Also, I guess it would be good if it was able to automatically delete thumbnails for "missing" pictures. Not sure if this would be easy for your implementation, so don't worry about it too much if not.
P.S. I am curious - what library/function do you use to resize pictures to thumbnail size? edit: I am guessing graphics.library/BitMapScale().
It remembers it (well, it uses the setting you have in prefs, it does not clone the temporary toggling you have made with the menu or user buttons), it' just that it doesn't use them when being rendered off screen. I'll see if I can find some way of rendering them reliably off screen.