Well whatever the problem is (In my icon set all icons have a drawer associated with them and it still doesn't work all the time) having a file/directory shouldn't be an issue and should be corrected in a future update/release, as it would only confuse new users. There's no technical reason as to why it has to be that way, the icon graphics is associated with the info file, not the directory/file.
Fully agreed. I was just trying to give an explanation.
Quote:
Also the workbench windows seem to cache data in some way, you can manipulate the icons even though they don't exists in the file system. OS4 needs a better notification system so that file windows can update their content when stuff happens in the file system.
Uhm... have you tried AutoUpdateWB (not in the Final Update release)?
Saimo I had exactl;y the same settings, I don't know what you picture did but all of a sudden it has started to work and I changed nothing. Only difference was I was looking at tooltypes for things in WBStarup to see if there could be any clashes.
Thanks for the help anyway, that's another minor problem solved.
I sometimes get a GR from Radeon driver during the boot. Just before WorkBench appears. It won't continue the boot, all I see is the CLI window. Reboot solves the problem, but it would be nice to know what causes this.
I guess when they redo the workbench they'll fix stuff like this.
Yes, so do I. After all, I think it would be trivial already now, given that all that would be needed is adding a checkbox in the Workbench preferences and little else.
Well whatever the problem is (In my icon set all icons have a drawer associated with them and it still doesn't work all the time) having a file/directory shouldn't be an issue and should be corrected in a future update/release, as it would only confuse new users. There's no technical reason as to why it has to be that way, the icon graphics is associated with the info file, not the directory/file.
Wrong. When you drop an icon to an appwindow it get's an AppMessage with struct WBArg * am_ArgList which includes a lock (wa_Lock) to the current directory the object is in and the name (wa_Name) of the object (not it's icon, i.e. without ".info") in that directory. For tool and project icons without files that's possible, for example if you have a foo:bar/file.info without a foo:bar/file the workbench can sent the appmessage with the wa_Lock of "foo:bar" and "file" as wa_Name. For directory icons without matching directory it's not possible, for example if you have a foo:bar/dir.info directory icon but no foo:bar/dir directory the appmessage to be sent would have to have the wa_Lock of "foo:bar/dir" and wa_Name "", but there is no foo:bar/dir -> no lock possible -> no appmessage possible.
Whilst it is still working I have a slight problem with Candy Factory 1.03, When I go in to select Screen mode it only displays half a dozen P96-0:Fakenative:640 x 480 screen modes and four Radeon 7000 modes all at 8 bit where as before it use to display 16 bit and 32 bit screen modes, anyone else have this problem?
Maybe ZeoNeo need to release Candy Factory 2 Now
Come on Matt you know you want too
This Puny World will bow down to Professor Chaos Prepare for the greatest Villan you have ever seen!!
Yes give that explanation to the average user. The answer you'll get is just "just fix it". So whatever reason there is for doing it that way it's simply the wrong way of doing it. It's like the QNX guys giving a pointless technical explaination as to why sounds stutters in an mp3 player when you do something cpu intensive at the same time. It just shouldn't do that for whatever reason, anything else isn't acceptable to the end user.
As I said, there's no technical reason that makes it impossible to solve this problem.
As I said, there's no technical reason that makes it impossible to solve this problem.
There is no problem at all changing it if you don't care about backward compatibility, but if we change it no current software using an AppWindow will work any longer ... Try to exmplain that to AmigaOS users
Reread this thread again and check how many people complain that broken software doesn't work any longer on AmigaOS4 final, now imagine what would have happened if a lot of correct software would have stop working
Can't you use wa_Lock "foo:bar" and wa_Name "dir" if the directory that is being dragged doesn't really exist?
That should fix it for programs that are just appending .info, and others that really do want a dir will just return an error that you have dragged a file in (or it doesn't exist, or whatever)?
Detect when an icon has been dragged and dropped on a window and the position where is was dropped. If it was dropped in a specific zone, retrieve filename of said icon. Read icon image data from the icon file. Display icon images.
Are you saying that that is a problem that is _totally_ impossible to do in AmigaOS 4.0 without breaking backward compability?
Even if it is (which I don't believe for 1 millisecond that it is) it's still not a good enough answer to the end user. It just needs to work (tm).
Detect when an icon has been dragged and dropped on a window and the position where is was dropped. If it was dropped in a specific zone, retrieve filename of said icon. Read icon image data from the icon file. Display icon images.
Are you saying that that is a problem that is _totally_ impossible to do in AmigaOS 4.0 without breaking backward compability?
Yes, because you do not drag and drop icons with the current AppWindow system, you drag and drop objects. As long as there actually is an object there is no problem, it only fails if you try to drag and drop an icon which does not have an object (and even in that case only for directories), something like that wasn't supposed to work at all ...
A new, additional method for draging and dropping icons, which don't belong to anything, would have to be added, but of course that could only work in new software which will have to support this new method once it's implemented.
"A new, additional method for draging and dropping icons, which don't belong to anything, would have to be added, but of course that could only work in new software which will have to support this new method once it's implemented."
- the scrolling bug of a window in name mode is still there (I mean you continue to scroll below or before the files)
- drag n drop from ram: to sys: does not give a status window (something like 10% done bla) (I tried with a 30Mb file and thought waou it is so fast but in fact only half was copied when I rebooted )
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
(works just fine here).
)
