Resolving issues

@Xenic
Btw, just in case : i add also to compile log revision of svn (at the end of whole log). I mean, if you want to be sure someday what svn build are on dopus5.org at the current time, you can just choice any compiler-log from dopus5.org and scroll down. At the end there will be something like:

Quote:

@xenic

Thanks, I'll grab it and test tomorrow when 1074 is up...

@kas1e
Yes, I'm aware of the revision in the log. That was a good idea. People don't need to keep D/L the overnight compile if nothing has changed. The revision in the log tells them when there is a change.

@Severin
I fixed a number of things in addition to the pattern issue. I eliminated resolution of device,volume,assign paths entered in "Environment/Path list" window. Is that where you had the name resolution problem you reported in the Dopus5 project bugs section? Could you test to see if I fixed the right place?

The fontname sizes were also increased for Buttons and elsewhere too.

@xenic

FTP_Sites loads fine now, thank you

Testing the other fixes now...

Name resolution works great, now most of my paths are sys: instead of volume name so I don't have to have separate installations of dopus anymore for each bootable partition, beta, FE, 4.1.1 etc.. Also very handy if you have to boot from a backup if your normal boot partition screws up.

Font names like "DejaVu Sans Condensed Bold Oblique.font" now work

I found another bug in FTP, if you do a recursive copy where drawers are created a failure message pops up everytime, click retry and it continues quite happily.

I get this copying files to android devices. Maybe a timing problem, trying to write to the drawer before android has created it?

@Severin
Quote:
I don't own any android devices so I can't confirm any issues with those. BSzili did all the work on the FTP module and I don't know enough about network programming to fix those kinds of issues. I'm more likely to break the FTP module than fix anything complicated. I'll have to leave that to another programmer. Sorry.

@xenic

No problem, it's not a major bug anyway, just a little tedious.

Is there any chance of adding mousewheel support to all the settings windows eg. environment, menus, filetypes, command list etc. ? Again, no rush just something I'd like to see eventually.

@Severin
Sorry, I'm just trying to kill some bugs. Other programmers (other than kas1e) seem to have lost interest in Dopus5 & I don't have the time.

@xenic

No problem.

How about looking into the desktop icon positioning bug? it seemd to have some hardcoded width and height limits in there so doesn't work on large screens, eg. I have it set to use the right hand side of my screen for icons, width is ok but only uses just over half the height, theres plenty of space available but it always puts some icons in the top left corner. I can send screen grabs showing the positioning windows and where it's putting icons if you want.

Again not a serious bug, just annoying when icons are placed under button banks etc.

A more serious problem is drag and drop onto external programs, asl filerequesters, app windows etc., it just beeps at me. Doesn't matter if it's lister items, desktop icons, they all fail.

@Severin
I'll check it out when I get a chance.

EDIT:
I checked out the issues you mentioned. When I set an icon area that ran from the bottom of the screen dragbar to the bottom of the screen and wide enough for a single column of icons, it worked. I'm using an 1180 by 1024 screen with standard OS4 disk icons. I have just enough partitions to fill the icon space from top to bottom. All my disk icons are unsnapshotted. The dimensions for the icon area appear to be stored in an Intuition IBox structure, which means the only limit is about 64k x 64k which is larger than any screen size I know of.

I tested drag-n-drop to a Multiview requester with the original "fixed" OS3 SASC open-source version of Dopus5, and it doesn't work there either. I'm guessing that it wasn't possible in the commercial Dopus5 either.

Hey Xenic,

Thanks for picking up the torch on Dopus!

I've running the nightly from 1/30 and it looks like I'm getting a crash in Environment_open.

I've created a ticket in SF: https://sourceforge.net/p/dopus5allamigas/bugs/51/

@xenic

weird, I'm using 1920x1080 with the right hand third of the screen allocated for appicons and left outs which is where it seems to put desktop icons as well, about half the time I start some icon are put in the top left. I have no drive icons as they're all hidden, no disks, listers/buttons or group windows defined.

although the appicon area does not show appicons or iconified icons, eg. the imagefx appicon only shows if I have workbench running too.

@Severin
A lot of programs use their program icon for appicon or iconifiled icons. If the program icon is snapshotted then it won't show in the Dopus5 appicon area or in the next slot on WorkBench either. Some programs create an icon, load the image from the program icon and then specify then appicon position based on the assumption that they are on the WorkBench screen.

Sometimes it's just not possible to have some icons where your want them. If I iconify SYS:Utilities/IconEdit, the icon will show up on the WorkBench screen at the position it's snapshotted at in it's window and in the upper left on the Dopus5 screen. If I copy IconEdit to RAM: and unsnapshot the program icon, it will iconify to the next slot on the WorkBench screen and in the appicon area on the Dopus5 screen.

On the other hand, the NotePad icon will show up on WorkBench in the next WorkBench icon slot and in the upper left on the Dopus5 screen whether it's snapshotted or not. The NotePad icon also has the name System:Untitled no matter where it iconifies to.

I think Dopus5 is doing the best that can be expected considering the inconsistancies in the way appicons are created or handled by the programmer.

@tekmage
Quote:
I'm not picking up any torches. After working on Dopus5 for a year and a half and then taking a long break, I just returned to fix a few bugs before I move on to something else.

Quote:
When you file a bug report at SourceForge you need to specify the platform (OS4, OS3,MOS etc.), the Dopus5 version and the revision if it's an overnight compile.

I tested the latest overnight compile (r1076) with my config files and could not reproduce your crash. I also D/L the overnight compile and tested with the default config and could not reproduce your crash.

Be aware that you need to install all the Dopus5 components (program, library and modules) when you use the overnight compile. You also need to reboot if you have already run another version of Dopus5 because the library and modules will stay in memory. Can you D/L the overnight compile, reboot, extract the archive and run Dopus5 from the extracted archive with the default config; then test opening Environment?

I'm fairly sure that Severin would have said something if there was a crash.

@xenic

No problems with environment here with r1075.

@anyone that might now...

Is there anywhere to get the binary updates now that Dopus5.org is dead?

Is there a version of the FTP module that doesn't chuck out loads of debug info?

Ftp module has a major problem with calculating the percentage copied on large files, copying a 750mb movie results it the percentage shown a 1%, 2%, 3%, 4%, 5%, blank, 1% etc over and over.

any large file seems to cause this, although the percentage it gets to seems to vary according to filesize. Wrong variable type used?

@Severin
Quote:
I'm afraid not. It's kas1e who has the setup for compiling all Dopus5 versions (OS4, MOS, OS3, AROS). kas1e did post a few messages in the Dopus5 developer forum at sf.net last week. Other than that I haven't heard anything from him in months. He said in those recent messages that he wanted to make a new release due to the number of bug fixes done since the first release. I don't know how long it will take for him to make a new release.

Quote:
If you are using an FTP version from the dopus5.org overnight compiles, the debug output is there intentionally. Those versions are beta. A release version shouldn't have the debug output.

I don't have much spare time lately so I suggest you file a bug report at sf.net for your FTP module issues. If you don't do that I won't remember them when I do find time for Dopus5.

I did finally determine the cause of the system freeze you reported when running ADpro after Dopus5 was running. It's occurring in dopus5.library and is caused by a change in OS4 and a seperate bug in OS4. I've made a workaround fix but haven't commited it to the repository yet. I should get the fix committed tommorrow and provide more detailed explanation of the problem in a response to your bug report at sf.net.

@xenic

Excellent news about ADPro, THANK YOU!!!

Now I suppose I'll have to see if I can get SF working with oddity anymore, not easy to use SF when you only have an amiga. I know, I have macs but they're all obsolete PPC beasties that are more out of date than my amigas...

The FTP problem is only cosmetic, not a big problem.

@xenic

Thank you! That's great news about ADPro.

@Severin
Quote:

I added my responses to your ADpro bug report with Odyssey so you should be able to add a bug report for your FTP issue.

I commited a fix for the Dopus5/ADpro freeze to the repository today. The current Dopus5 code appears to enter an infinite interrupt loop when ADpro is started which could be dangerous situation. I strongly suggest that users do not attempt to run ADpro after DOpus5 is running until a new release containing the fix is released.

If kas1e doesn't make a new Dopus5 release within a week or 2, I may add an updated version to the repository files section. Unfortunately, I can't replace the current versions at OS4Depot or Aminet because I didn't upload them.