Filer 53.29 testing

Uploaded 53.29h, which is a developer release and not a final release.

http://openamiga.org/attachment/project/20/filer_53.29h.lha

Don't use 53.28 locale files or you might get string corruptions.

Note to translators: Please don't upload translations for the development releases to OS4Depot. When the new version is final and uploaded to os4depot you can upload new ones.

@orgin

Tested. With the "show real icons", it's starts to be a bit slower (for example when you try to open Work directory, with tons of dirs and files, then it takes some time). For example without "show real icons", i come to "work" faster that in second, but with "show real icons", it's takes 2-3 seconds.. I think it's because you firstly cashing everything, and then show for user ? If so, maybe better will be split on some parts, like cashing 50 items, and spawn, then, (when user already see his partition), cashing more , etc. I.e. to make it "real-time".

Idea with checking d&d only on left-right, are very nice ! It's solve some crap with selecting many items, etc. But still, there is that problem which you say "aos specific" (auto-unselecting of some items when you d&d it), and, one more problem/suggestion: When you mark many items, then d&d them, then while it copies you press "chancel", these items which already done, are not un-selects (but their must be unselects, to show user which are done, and which still not).

Also i think about that problem with "auto-unselecting", you still need to make workoraund for it .. (because it's really not so good with that). For now i can't give any good solution, but if you in interest to make workoraund for it, i can help with ideas ..

ps. Programm itself are pretty nice for now. It's already have many necessary options, nextly only new additionals and fixes :) Thanks for :)

@kas1e

Yes I know it's slow, people will have to live with that for now. Loading icons is slow, just as it is when you open a workbench window with a lot of icons. It might have been a bit faster if there was a global OS facility for caching images in different sizes and with different backgrounds while still being able to detect if the icon had changed on disk. But such a facility does not exist and I don't want each filer instance to cache its own set of images since that would use up a horrible amount of memory.

I'll look into deselecting items that are copied.

It does not matter how many ideas you have about the "unselect" issue, the listbrowser class cannot be controlled in that manner from the outside no matter how many ideas you have. You'll just have to get used to it. Or alternatively you could write a new listbrowser class with all the original functionality included plus the fix for unselecting and then send it to me.

@anyone

If there's a developer interested in making a system facility for caching scaled icon images, here's some ideas:

Implement it as a library.

An application calls this api function to get an image:

struct Object *GetIconImage(STRPTR filename, LONG backgroundrgb, LONG selectedbackgroundrgb, LONG maxwidth, LONG maxheight);

filename - Name of the file/directory the icon points to
backgroundrgb - background color for the non selected image
selectedbackgroundrgb - background for the selected image
maxwidth - the icon will be scaled to this width unless it violates maxheight
maxheight - the icon will be scaled to this height unless is violates maxwidth

On each call the library will check if the modified date has changed for the icon file. If not it will check if it holds a copy that matches the background colors and the size parameters. If it does it returns the stored BitMapObject, if not it loads the diskobject for the file scales it to the correct size with the requested background colors and creates a new BitMapObject and returns it.

A GetIconImageAttrs() function could be added to provide other options, like returning real transparent (alpha) icons or other types of scaling options.

I can provide all code needed to load and create icon bitmap objects.

Missing is the library and a clever/fast way to index it all in memory.

The library should probably also have a Flush() function that will remove all loaded icons from memory. Perhaps with an optional timestamp so that old icons can be removed in certain timed intervals.

@orgin

Quote:

Yes, you are right. The same i noticed with WorkBench itself when i start to use aos4 heavy, and that is what i dislike .. Hope os4 core devels will think about that necessary part of OS itself and will works on it .. It's pretty suck to have more or less modern os on more or less modern hardware, but where is showing the many icons are so slow (still).

Quote:

I wish to help, but as all the other ones i am already have some projects which need to finish (sdl+gl window mode fix as example, etc). But it's looks not so hard to just add fix to the listbrowser, if, sources are present ? (or we have no sources ?) If you have the sources of the current listbrowser, i will be in interest to have a look, maybe i can fix/add that "unselected" problem.

Related to the idea about cashing library, imho, that must to do os4 core developers, as part of OS itself. The problem which i see, it's not about only "Scalled icons". As i can detect, not scalled icons shows the same slow in WB, no ?

@kas1e

The listbrowser class is internal to Hyperion.

@orgin

I mean writing listbrowser class from scratch make no sense, if , Hyperion already have the sources. Better just add necessary stuff to it.

@kas1e

Hence the original "Call Hyperion".

Are we full circle yet?

@orgin
Not sure that i understan your "Are we full circle yet?". What you mean ? Anyway, i got your point, let's wait while Hyperion will matures enough to works on it.

@orgin
Thanks for the update, will try it. While I remember, problems I noticed with previous versions:

If you use CopyAs, and it asks about replacing a file, it uses the SOURCE name not the TARGET name, which can be quite confusing (and is definitely wrong!).

The "recently visited folders" list is very nice, but would it be possible to make this SHARED by all Filers, and PERSISTENT (so closing one or all Filers does not erase the list?). I guess both requests are related, so some kind of global task (perhaps FilerCX?) needs to store the recently visited folders. This was very handy in DOpus 5...

@ChrisH

"If you use CopyAs, and it asks about replacing a file, it uses the SOURCE name not the TARGET name, which can be quite confusing (and is definitely wrong!)."

Okey I'll add that to the list.

"The "recently visited folders" list is very nice, but would it be possible to make this SHARED by all Filers, and PERSISTENT (so closing one or all Filers does not erase the list?). I guess both requests are related, so some kind of global task (perhaps FilerCX?) needs to store the recently visited folders. This was very handy in DOpus 5..."

Yeah someone else mentioned that as well and it's on the list at least. The browsing history in it's current version is actually meant to be lister individual though so that you can step back and forth* in the list for that individual lister. If it were global and you stepped around in one lister, went back to another lister and clicked back where should you end up if the old entry isn't even in the list any more due to browsing in another window? Seems it could get quite messy. The current browsing history is like a web browser history, it keeps the session history in memory.

The current behavior with back/forth was actually something that was requested by users and it seems the "global visited folders" is another non compatible feature that is sort of mutually exclusive to teh current one.

Perhaps when I add the favorite folder list this will be less of a "problem" though.


*The back and forth buttons can be added in the Toolbar section in preferences. Or you can press space for keyboard navigation and press the right/left keys.

@orgin
I didn't know about Forward/Back buttons. But I know from experience with Windows XP that I almost never use them (as you have to remember where you were last), and instead prefer the Parent button (whose behaviour does not depend on where you were before!). Vista really infuriates me by not having a Parent button (clicking on the "bread crumbs" is extremely error prone, and requires repositioning the mouse every step).

So I think I would prefer a global history, and no Forward/Back, if I had the choice. But perhaps you can have both an invisible local history (for Forward/Back) and a global history (for the pop-up list)?

@orgin

I like the option of viewing the icons.

Could a button be added to switch easily between views?

@orgin Quote:
First, let me say that showing the icons is GREAT. Love it! But of course it is slow too (I thought I had killed Filer when I tried to view a folder containing 2000 icon-less files).

What I'd like to see is that *initially* the "no icon" view is shown (i.e. super fast), but that also the icons are being loaded in the *background* by another process/task. You can see that kind of thing being done in Windows.

Then there is no need for a way to quickly switch between both icon views, because you get the best of both.


Even better, how about loading the icons of files with real .info files first, and then only later let DefIcons do it's slow file-type recognition thing. That would be another speed boost, if you were viewing a folder with a mix of real & fake icons.

@orgin

Like it! Showing the icons really makes sense and seems to work quite well.

I too would prefer a global "visited" list (it was me who mentioned it the first time I think) perhaps you could use a temp file in T: to cache the list of visited directories?

One oddity with drag and drop, clicking on a selected item and draging deselects that item (Ithink that's what kas1e was talking about above) but still iniates a drag and drop action, this means that if only one file was selected nothing happens or if multiple files were sleceted the action is taken only on every file except the file "deslected". Perhaps only slection and not deselection should initaed adrag and drop? This would avoid accidentally leaving files behind etc.

Oh and I would still like the option to reverse the default drag and drop behaviour so that the default is copy (Workbench alike mode only does that in some cases so is worse IMHO).


Filer is probably my most used app now and I like the way it's going overall.

@PEB

Already did, may not be in the dev release. I'll release a new dev version this evening to be sure.

@ChrisH

Quote:

I actually opted against that since loading icons may change the height of rows and the listbrowser gadget probably won't be able to handle drag select and scrolling very well if it's constantly being updated. I could add it as a test feature though and see how well it behaves.

@broadblues

"One oddity with drag and drop, clicking on a selected item and draging deselects that item (Ithink that's what kas1e was talking about above) but still iniates a drag and drop action, this means that if only one file was selected nothing happens or if multiple files were sleceted the action is taken only on every file except the file "deslected". Perhaps only slection and not deselection should initaed adrag and drop? This would avoid accidentally leaving files behind etc."

Unfortunately there's no reliable way of detecting that. I could check if there's anything selected at all though, but that's a heavy operation that is actually discouraged where i'm detecting the drag motion which is why I didn't do it in the first place.

@orgin
I've been trying new versions of Filer as they appear and like what I see. I have a couple of questions though. Is the "Help text" for user buttons supposed to work? I entered the text for a couple of user buttons but no help bubble appears over my user buttons when I move the pointer over them. Can Filer windows be opened on a public screen other than WorkBench? I am thinking about replacing Dopus4 with Filer but I'd like to use a seperate screen.

@xenic

"Is the "Help text" for user buttons supposed to work?"

Not in the current version no. We'll see once os4.1u1 is out.

"Can Filer windows be opened on a public screen other than WorkBench?"

Not yet, but it's on the todo list.

@orgin
O.K. Thanks for the answers. Keep up the good work.