Opened 9 years ago

Last modified 6 days ago

#5458 in-progress bug

[LaunchBox] can't store apps from other partitions

Reported by: diver Owned by: stippi
Priority: normal Milestone: R1
Component: Applications/LaunchBox Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

If you add an application from another BFS partition to LaunchBox and restart it (LaunchBox) will refuse to show that button. Instead it'll turn to some gray space which you can't click.

Change History (12)

comment:1 Changed 9 years ago by humdinger

FWIW, it works for me in hrev35594. Also, I never had a problem with that in the past...
Currently I have Paladin and HaikuLauncher in my LaunchBox, both on another partition than /boot.

comment:2 Changed 9 years ago by diver

Could you:
unmount your partition with Paladin and restart LaunchBox.
mount it and restart LaunchBox again
Are your icons still there?

I think what happens in my case is:
LaunchBox launches at boot, but before mt other BFS partitions was mounted and that's why it can't read those icons.

comment:3 Changed 9 years ago by humdinger

Seems your assumption is correct.
Unmounting the non-boot partition and restarting LaunchBox shows the empty pads.
Re-mounting the non-boot partition doesn't change that, only again restarting LaunchBox fills the empty pads.

So, apparently my non-boot partition is mounted before LaunchBox, which is started from the config/boot/launch/ folder.

LaunchBox should keep an eye out for the linked objects when a volume becomes available.

comment:4 Changed 9 years ago by stippi

Exactly for this reason I implemented the mount_server a few month ago. During booting the system, all previous partitions are mounted synchronously now, so the only time the problem could show up is when you install links in LaunchBox, then unmount the partition so that the next boot comes up without the partition mounted and then when you mount manually, LaunchBox still misses the links. That's an issue that should be fixed, but it shouldn't be the case that a partition gets mounted *automatically* during boot *after* LaunchBox was started. It was the case when Tracker was still mounting the partitions asynchronously, but it should be solved since the introduction of the mount_server. The boot script specifically waits until all partitions have been mounted before continuing.

comment:5 Changed 9 years ago by diver

This is how I add LaunchBox to launch folder

AddSymlinkToHaikuImage home config boot launch :    /system/apps/LaunchBox : LaunchBox ;

Still after reboot all icons from non-boot partition doesn't show up and pads remains empty.

comment:6 Changed 9 years ago by diver

The problem in my case could be that apps were added to LaunchBox from partition without query support which I use for compiling stuff.

comment:7 Changed 9 years ago by humdinger

That would indeed be a problem, not for the lack of query support (i.e. no indexing), but because of no attributes. LaunchBox starts apps with their signature, which is stored in BEOS:APP_SIG.

comment:8 in reply to:  7 Changed 9 years ago by bonefish

Replying to humdinger:

That would indeed be a problem, not for the lack of query support (i.e. no indexing), but because of no attributes. LaunchBox starts apps with their signature, which is stored in BEOS:APP_SIG.

Actually the missing query support is the problem (I don't think it's even possible to disable attribute support for a BFS volume ATM). If an app is started by signature and the app's path has not been registered with the MIME database (haven't checked, maybe even then), a query for the app's signature is used to find it.

Anyway, from a quick look LaunchBox seems to support both, launching by signature and by app ref. The following code in MainWindow::LoadSettings() looks bogus though:

        entry_ref ref;
        BEntry entry(&ref, true);
        if (entry.Exists())
            button->SetTo(&ref);

comment:9 Changed 9 years ago by stippi

Status: newin-progress

Totally unfinished code... It's meant to use the patch which is extracted from the message in the loop... :-)

comment:10 Changed 9 years ago by stippi

Should be fixed in hrev35845, could you please check?

comment:11 Changed 9 years ago by diver

Thanks! My original bug is indeed fixed. The only remaining issue is described in your comment:4.

comment:12 Changed 6 days ago by diver

Problem mentioned in comment:4 is still here in hrev53129.

Note: See TracTickets for help on using tickets.