@Orgin I keep forgetting to mention this. The Search window behaves in a really strange way compared to all other file search systems I've seen (and especially Workbench's). Specifically:
1. If both Filename pattern AND Contents are provided, then files only have to match EITHER to appear, instead of BOTH. This makes it fairly useless IMHO.
(And I don't see the point of making this configurable, since if one wants to see files matching either criteria, then it is easy to perform a Filename search followed by a Contents search.)
2. It seems to default to case-sensitive searches.
3. It is not clear how one can change the default Search options, since there is no "Save" option. However, it must be possible, since it keeps putting something I once searched for in the "Contents" field!
BTW, had you thought of making the search results act like another Filer window? i.e. You'd be able to rename/delete/etc the found files. If not easy, then how about a "Show location" button, which would open a Filer window in the relevant directory, with the specified file selected?
Reading the thumbnail size would mean loading the whole diskobject. Which would make everything terribly, terribly and then some more, slow.
It does not check dates (yet). Diskobjects doesn't have a date field as far as I know. And checking/setting the date of the .info file is prohibited since then your're then assuming how the icons are stored. I have some ideas on how to circumvent this without breaking the assumption rule so we'll see, unfortunately all of them means that it will be slower.
The icons are resized using IIcon->DrawIconState(). Images are resized using IGraphics->BitMapScale()
The search parameters are stored automatically every time you search.
Search will move into the main window at some point. Bit like the os4depot view. It's too large to add in an afternoon though so it will be one of the upcoming 'themed' updates (like the current is themed thumbnails). I have several other update themes planned ahead of it though. After all I'm only one man and can't manage too many big changes at a time.
Reading the thumbnail size would mean loading the whole diskobject. Which would make everything terribly, terribly and then some more, slow.
Ummm, surely you know the thumbnail's size when you load it for displaying?!? So why can't you invalidate/regenerate the cache at that point?
IQuote:
t does not check dates (yet). Diskobjects doesn't have a date field as far as I know. And checking/setting the date of the .info file is prohibited since then your're then assuming how the icons are stored.
Hmmm, I hadn't thought of that. But does it *really* matter? I mean, the date-check would be a minor function which could easily be disabled in a later release, in the UNlikely event that it changed...
OR you could just save thumbnails as as IFF files, using Datatypes. Although I'm currently trying to do that for (scaled) bitmaps myself, without luck so far: UtilityBase thread.
The icons are resized using IIcon->DrawIconState(). Images are resized using IGraphics->BitMapScale()
BitMapScale does pretty awful scaling (there is no 'smoothing' so you get horrid "aliasing" artifacts). But DrawIconState() seems to do quite nice scaling... had you thought of using DrawIconState() for scaling bitmaps?
It seems to me that one could create a temporary in-memory "fake icon", and use that to resize the bitmap nicely. I'll hopefully try this myself, although it looks like it'll be a bit fiddly, since you appear to need to create a gadget to hold the bitmap...
True. I'll investigate it when add the '[ ] Use huge thumbnails (slow)" 128x128 option to prefs. The code is getting very spagetthified with all these options people want though. At some point people are going to have to decide if they want a fast and easy to use file manager or a slow cumbersome, do it all including your breakfast, no so much a file manager anymore-app.
Well some people probably want the icons to regenerate when you rotate the original picture or if you're a graphical artist and change them a lot. Though of course, the functions for manually rerendering are still there.
I don't think that using IFF files would be impossible (bar perhaps alpha transparency). I simply just decided not to go there since I already had the code for icon files and since they're easier to handle and the scaling in drawiconstate works quite well.
I don't know if the icon functions will work if you try to insert anything above 128*128 or 256*256 into it. Anyway the trouble would probably not be worth it for the Filer, if people want perfect images then they are using the filer for the wrong reasons. I have a feeling using composition related functions would create a better result anyway, hopefully we'll be able to access that when (if?) a new sdk comes out.
The CompositeTags() function already exists in the latest public SDK. For examples you can see the source codes of the SRec and CDXLPlay programs. The Composite/CompositeTags functions are also explained in the graphics.library autodoc.
Ahh nice, I'll see if I can do a drop in replacement of BitMapScale() with that function. Of course on OS4.0 I would have to fall back to BitMapScale().
Dispite Snuffy's quirky way of expressing himself, I think he makes a reasonably case for changeing the name "New" to "Add" or maybe the more verbose "Add New"
Scanning through a number of system preferences , this does seems to be the convention.
At some point people are going to have to decide if they want a fast and easy to use file manager or a slow cumbersome, do it all including your breakfast, no so much a file manager anymore-app.
IMHO you should err on the side of fast and easy, we allready have image processing applications, etc, and I don't eat breakfast
Filer is getting ever more powerful but it *is* starting to slow down, dispite the coolness of the features. I personally wouldn't bother with an icon mode either, that's what the workbench is for. Now that you've manage to get a degree of interaction between the two with FilerCX I don't see any need to replicate functionality.
I made some tests. Make it: COMPTAG_ScaleX, COMP_FLOAT_TO_FIX((float32)(cwidth+1)/(float32)width) COMPTAG_ScaleY, COMP_FLOAT_TO_FIX((float32)(cheight+1)/(float32)height)
(Or blit the result into x+1,y+1 and width-1,height-1.)
Rock lobster bit me - so I'm here forever X1000 + AmigaOS 4.1 FE "Anyone can build a fast CPU. The trick is to build a fast system." - Seymour Cray
- Prefs: Update about body locale string - Add menu entry for turning on/off auto thumbnail generating - Add user buttons for turning on/off auto thumbnail generating - Add HUGE thumbnail setting - Fix a bug where a thumbnail wasn't removed from the cache - Increase maximum thumbnail size to 128 in HUGE mode
Sorry to write this if just asked... Unfortunately I've no time to look at these "try the work-in-porgress" topics ATM... But I think that if Mid-Mouse can be setted to go to Device list(as on ASL req) that was really nice and usefull :)