Has Alfkil (Qt port developer) gone?

@BillE

I will fix you a user archive :).

Thanks for the bug reports. The missing line to the right of the menu is probably not going to be fixed. But the rest, I might look into.

Just to sum up, these are the issues reported:

- Several problems with native menus
- Window focus issue with Qt menus. WA_Toolbox propable solution?
- Crash when printing in qpdfview
- Form of commands added to user-startup
- Size of download archive


Anything else?

@alfkil

"Anything else?"

- Debug messages when using QtWebkit programs

@zzd10h

Oh, all right.... Yeah, I tried to turn on the NDEBUG flag, but apparently it has not solved the issue...??

@alfkil
WA_Toolbox may not solve it. It'll prevent window grabbing focus, but I'm not sure it'll effect obtaining events from the window (but worth checking anyway).

@ChrisH

I am pretty sure, I checked it out very thoroughly in the past and eventually decided, that this was not a solution. In fact, I am pretty sure, that I decided, that there was not going to be a solution at all.

EDIT: From the autodocs:



So, ToolBox windows will only receive input, as long as a gadget is pressed. This is absolutely no use at all, as it will prevent any communication with the Qt menus.

EDIT: I could spoof input.device for input, ruling out intuition communication with windows and translating all input directly. This sounds attractive, but will end up being a very, very bad idea.

@Chris

Is there an online example of how to use the menu.class?? I have just modelled after the ReAction examples in the SDK. I don't think those have the kinds of features, that you are looking for??

@alfkil

if you haven't already, check out the BOOPSI menu class page on the developer wiki: http://wiki.amigaos.net/wiki/Intuition_Menu_Class

-- eliyahu

@eliyahu

Thank you!

@someone

I am feeling a little behind still on uptodate issues. I have had a problem with extremely slow file copying times on OS4.1 Final Edition. Is this a known issue, and is there anything I can do to prevent it from happening? ATM I am still using Update 6 mostly, primarily because of this issue.

@alfkil

What filesystem are you using ? FFS is rather slow unfortunately.

@K-L

But is it slower than under Update 6? I am doing the same copying across the same partitions, and FE is significantly slower than Update 6!

[Edit]
Content moved to the new thread - didn't see it before posting initially.

Best regards,

Niels

@alfkil
I'm not aware of any known issue with copying in Final Edition being noticably slower than earlier versions of OS4. Although that doesn't mean much, so I also did a *quick* check of OS4's bug tracker, and could not find anything relevant that contained the word "slow".

Some info that might help others/OS4-beta-testers/Hyperion reproduce your problem:
* What Amiga hardware are you using? (motherboard & RAM)
* What filing system(s) are you using? (e.g. FFS-Internantional, or SFS/02, or whatever)
* What hard drive are you using? (make, model & size)
* What size file(s) are you copying & how many files? (approximate!)
* What software are you using to copy the files? (e.g. Workbench with AsyncWB commodity running, Filer, DOpus5, Shell copy, something else?)
* Any other details that might be relevant?

@alfkil
I ran some tests by copying system partitions to a directory in RAM. My FE partition is at the bottom of the hard disk(lowest address) and my Update6 partition is at the top of the hard disk (highest address). I cold booted into my Update6 partition and performed copies of both partitions to RAM and then cold booted into my FE partition and performed the same copies. Both partitions are SFS2 filesystem. The FE partition is 430MB and the Update6 partion is 390MB. I used the timer command from OS4Depot for all tests.

DH0: - OS4.1FE partition at the lowest hard-disk address (430MB)
DH8: - OS4.1Update6 partition at the highest hard-disk address (390MB)

Booting with OS4.1u6 partition:
makedir ram:test
timer copy DH0: TO ram:test all quiet
Command duration: 45.8506 sec.
delete ram:test/#? all quiet force
timer copy DH8: TO ram:test all quiet
Command duration: 130.0572 sec.

Booting with OS4.1FE partition:
makedir ram:test
timer copy DH0: to ram:test all quiet
Command duration: 12.2425 sec.
delete ram:test/#? all quiet force
timer copy DH8: to ram:test all quiet
Command duration: 17.0091 sec.

Both sets of tests showed that copying from a partition at a low hard-disk address is faster that copying from one at a high hard-disk address. I repeated the tests numerous times with the same result (plus or minus a half a second).

I can't explain why booting from the partition at the top of the hard-disk address space is so slow and it makes no sense to me. My conclusion is that if you want to compare OS4.1FE copy speed to OS4.1Update6 copy speed you need to run tests with both versions being booted from the same partition and copying the same data.

When I tested copying a spare system partition that is FFS, the speed was 50% slower that from an SFS partition (both partitions at the lowest hard-disk address space).

@ChrisH
Quote:
As you can see in my previous post, the location of boot and data partitions seems to be more relevant than the version of the OS being used.

@xenic

Thanks for the report. It is strange, because my setup with regards to partition addresses is similar to yours, but my timing results seem to be opposite. I will try and do a little more testing to see, if I can pinpoint the pattern.

@alfkil
The time difference difference between booting with Update6 from the high partition and booting with FE from the low partition seems to be valid.

However, the time difference between copying FROM the high partition and FROM the low partition is less valid because I discovered that the Update6 partition has a complete AISS tbimages directory (5000+ tiny files) while the FE partition only has about 54 files in the tbimages directory. I moved my main TBImages directory to another partition for FE. Copying thousands of small files seems to make a big difference in the copy time.

I tested copying using Dopus4 and copying my DH0: (low partition) when booting from the Update6 partition (high partition), took twice as long as copying the DH0: partition after booting from the FE partition (high partition).

Either copying when booting from a high partition is slower or copying when booting form Update6 is slower. I would need to repartition my hard-disk to really determine the cause but I really don't want to repartition my main hard-disk.

@xenic

I am sure, that there is something with the place of the partitions on the disk. Now, the problem is, why does it slow down the copy process, that I have *booted* from another partition??! I think, the copy executable itself must have been copied to ram, so why does the fact, that I booted from a different partition influence copy time?? Also, the amount of buffers on a disk is written in the RDB and is not influenced by the boot procedure.

I have discovered, that there is way more strangeness here, than first anticipated.

1) I have confirmed, that Update6 will result in slower copy times, along the lines that you have described. Now, the strange thing is, that it is pretty extreme, how big fluctuation, there is on the speed. Here are my copy times when using your proceedure:

DH0=FinalEdition (706MB)
DH3=Update6 (648MB)

Boot from DH3:
Copy DH0 to ram: 350.1602 sec.
Copy DH3 to ram: 243.6344 sec.

Boot from DH0:
Copy DH0 to ram: 20.4267 sec
Copy DH0 to ram: (second time) 15.7683 sec
Copy DH3 to ram: 16.9921 sec

This, to me, is completely insane.

2) Now, the reason i mentioned slowness on Final Edition, is because of the following. Qt Makefiles have a proceedure of copying and linking .so libraries at the end of the make process. I have done a cooked down verison of this for testing. The dummy makefile looks like this:

(------dummy.makefile--------)
MOVE = mv -f
DEL_FILE = rm -f

TARGET = libQtCore.so.4.7.0
TARGET0 = libQtCore.so
TARGET1 = libQtCore.so.4
TARGET2 = libQtCore.so.4.7

all:
-$(DEL_FILE) /qt/lib/$(TARGET0)
-$(DEL_FILE) /qt/lib/$(TARGET1)
-$(DEL_FILE) /qt/lib/$(TARGET2)
-$(DEL_FILE) /qt/lib/$(TARGET)
-$(MOVE) $(TARGET) /qt/lib/
-ln -s /qt/lib/$(TARGET) /qt/lib/$(TARGET0)
-ln -s /qt/lib/$(TARGET) /qt/lib/$(TARGET1)
-ln -s /qt/lib/$(TARGET) /qt/lib/$(TARGET2)
(----------------------------)

On OS4.1 Final:
timer gmake --makefile=dummy.makefile all
Command duration: 8.6299 sec.

On Update6:
Command duration: 1.1364 sec.

This looks completely silly, when you are used to a certain 'animated' image of the commands at the end of a make call.

3) Last, but not least, there is a big issue with USB sticks. This was one of the killers for me on installing Final Edition in reverting back to Update 6. I had to do a backup of Qt code archive, and constantly, constantly, the copy process would a) slow down to a completely insane low speed and b) elicit warnings, that there was an 'illegal object lock' in Filer or whatever copy utility, I was using. In general, it gave me the impression of complete lack of useability.

Now, on Update 6, there are no warnings, but still the speed issue persists. Let me describe:

Update6:
(Info from DOpus4: Size of svg = 3263556 bytes)
cd MainHD:CODE/large/qtamigaosnative/trunk/src/3rdpartywebkit/WebCore
timer copy svg TO USB0:CODE/large/qtamigaosnative/trunk/src/3rdparty/webkit/WebCore/svg all quiet
Command duration: 221.0624 sec. (!!!)
timer copy svg TO RAM:svg all quiet
Command duration: 1.7640 sec.
timer copy svg TO USB0:svg all quiet (!!)
Command duration: 20.1393 sec.

So there seems to be an issue with USB sticks an long path names, although I was not able to predict, when the slowdown would happen based on path lengths. All in all, it should *not* take 4 minutes to copy 3MB of reasonably sized files from one place to another.

4) I must admit, that I have been a little disappointed with my experience with Final Edition. First of all these 'Illegal object lock' warnings and following GrimReapers, that will show up all the time when using a USB stick. Then on installing the Enhancer Pack, I would get series of GrimReapers on first and second boot, resulting in me removing most of what had been added to my startup proceedure by the installer. Have the developers gone flakey, or what has happened since I took a break for 2 years??

@alfkil

2) I remember reading about an issue with "make" being slow.
Ah, here: http://forum.hyperion-entertainment.biz/viewtopic.php?f=27&t=2848

@Srtest

Updates to BananaBar will happen as soon as i get bored with everything else currently in my basket .