#257 closed bug (fixed)
[Expander] first launch
| Reported by: | diver | Owned by: | axeld |
|---|---|---|---|
| Priority: | normal | Milestone: | R1 |
| Component: | Servers/registrar | Version: | |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: | ||
| Platform: | All |
Description (last modified by )
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.
Change History (18)
comment:1 by , 18 years ago
| Summary: | BitmapDrawing->Expander → [Expander] first launch |
|---|
comment:2 by , 18 years ago
| Cc: | added |
|---|
comment:3 by , 18 years ago
comment:4 by , 18 years ago
| Owner: | changed from to |
|---|
comment:9 by , 18 years ago
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?
comment:10 by , 17 years ago
| Platform: | → All |
|---|
Can't reproduce it anymore, it's been probably fixed in meantime.
comment:11 by , 17 years ago
| Description: | modified (diff) |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
comment:12 by , 16 years ago
| Resolution: | fixed |
|---|---|
| Status: | closed → reopened |
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...
comment:14 by , 16 years ago
I think this could even be fixed in hrev25309, 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?
comment:15 by , 16 years ago
| Component: | - General → Servers/registrar |
|---|
Yes, it's seems "fixed". But I think hrev25309 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?
comment:16 by , 16 years ago
| Resolution: | → fixed |
|---|---|
| Status: | reopened → closed |
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.
follow-up: 18 comment:17 by , 16 years ago
+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?
comment:18 by , 16 years ago
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.
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.