[Expander] first launch

[diver]

OK, i'll try to explain. I have customized bootscript with uncommented tracker. When haiku starts it loads tracker which in turn open /boot/beos/apps. Now, if i start BitmapDrawing -> Alt+w -> Expander -> Alt+w i could see slowness of repainting background (about a second). I don't start any other apps before this to reproduce it.

Tested with rev16575 under vmware.

[diver]

Correction. Don't need to go through those steps written above. There is an easy way. Just start Expander after tracker and close it and you'll see slow background repainting. Maybe Expander tries to wright settings to disk, but under vmware it takes to long? Need to test it under native installation.

[korli]

Is it still valid ?

[diver]

I will retest it ASAP.

[axeld]

And?

[diver]

(In reply to comment #4)

And?

And it still valid in r17797 :-)

[info@…]

Expander write 2 files upon being closed or window-moved:

/boot/home/config/settings/Expander_settings and: /boot/home/config/settings/beos_mime/application/x-vnd.haiku-expander

Specifically, the delay is caused by the MIME type being written.

Is this normal behaviour?

[diver]

Can't reproduce it anymore, it's been probably fixed in meantime.

[diver]

I can reproduce it again on first launch. BTW, the same thing happens on mediaplayer's first launch. So i think it MIME type write related which causing this delays. Reopening...

[axeld]

This might have been fixed with r25719, please check.

[diver]

I think this could even be fixed in r25309, where Ingo added

mimeset -apps -f /boot/beos/apps

mimeset -apps -f /boot/beos/preferences

So now both Expander and MediaPlayer should write their supported MIME types at first boot, regardless of whether you'll launch them of not, right?

[diver]

Yes, it's seems "fixed". But I think r25309 could've been hide this bug and could potentially lead to boot time increase due to a slow MIME type write as stated above. What do you guys think?

[stippi]

That only happens once at the very first boot. I think the general idea behind that is ok. The other option would be to make the build system do this, but think the current solution is more fool proof.

[diver]

+1 to the idea to make the build system take care of this as this will also speed up haiku start up in vmware and also potentially LiveCD boot time. Should I add a new ticket so we don't forget about it, Ingo?

[bonefish]

Replying to diver:

+1 to the idea to make the build system take care of this as this will also speed up haiku start up in vmware and also potentially LiveCD boot time. Should I add a new ticket so we don't forget about it, Ingo?

Please don't; I don't think I'll implement it. The build system can't really prepare the MIME entries for optional packages, so the on-first-boot mechanism is needed anyway.