Make QuickLaunch part of Haiku

[diver]

Several devs suggested making QuickLaunch an official app. Personally, I use it all the time and it makes my Haiku expearence a breeze.

​https://github.com/humdingerb/quicklaunch

[pulkomandy]

Ideally we would integrate it with the DeskBar, I guess. But as a start we could include it in the release profile, and maybe in the nightly one. Does it come with a launch daemon script allowing to configure it to autostart easily (like LnLauncher)?

[diver]

It doesn't, but does it have to? Normally I assign a hotkey to quickly launch QuickLaunch :)

[pulkomandy]

Ah right, a shortcut could make more sense.

Well, the idea is mostly the same, I dont consider it integrated if it doesn't come with a default shortcut, I guess. It makes little sense if invoked from the icon? Unless you put the icon in some easily accesible place, eg. a dock.

[diver]

Agree, default shortcut is a must.

[humdinger]

Currently QuickLaunch does a quick query on every launch and quits after launching the chosen app. I plan to make QL aware of localized app names. As getting all the localized app names is too slow to do on every launch, I'll have to change QL to become a background app, so I create the list of localized app names only once on first start.
This may mean that I'll have to do the show-window-via-shortcut with an input_server-device and let the user choose the shortcut keys from the QL settings, instead of using the Shortcuts prefs.

Not sure when I'll have that ready... I expect R1/beta2 to be still a ways off... :)

[pulkomandy]

Alternatively, a shortcut could run the app again, if it's set to B_SINGLE_LAUNCH the existing instance will be notified then (through a BMessage).

[humdinger]

Alternatively, a shortcut could run the app again, if it's set to B_SINGLE_LAUNCH the existing instance will be notified then (through a BMessage).

Yes, that was the alternative I planned to investigate. I'd prefer to have the shortcut set in the Shortcuts prefs...

I'm wondering if a background app is the way to go here. It would mean a slower startup time, as QuickLaunch will have to do this processing everytime it starts. This will feel like Windows :(

I don't quite follow. QL right now is not a background app and does the processing every time it's started. That's no problem, as it just dos a simple query which seems to be cached to boot, so it's very fast.
But once I have to get the localized name for every app, it becomes too slow. It's about .5 to 1s, depending on your hardware (ssd <-> usb-stick). Doesn't sound like much - certainly tolerable when doing once at system boot - but if you're used to its current immediate start, it's unbearable.
Therefore the idea to have QL keep running in the background. Then I'll only have to do the processing once when it auto-starts on boot. (And keep the list of apps up-to-date with a live query).

[pulkomandy]

What I'm saying is that 1s at boot time is a quite large part of our boot time already. By caching the localized names to a file, it could maybe start faster. But then again, maybe the extra disk io to load this file makes this not worth it.

In either case, I'd say if we really want to use localized application names, we should make them faster, because this delay is also noticeable in other places (eg. showing the Application menu in DeskBar). And ideally we would not duplicate this caching in both DeskBar and QuickLaunch (and any other app needing the same info, eg Debugger, Slayer, ProcessController, ...). So it would be great if there was a single central place making this happen for all apps, right?

[humdinger]

Yes. I suppose it's really an R2 thing, but it'd be brilliant if it were transparent for the user. For example, a query for a file name would return the localized one, if that setting in the Locale prefs is on. Same for querying some date format etc.

If, for now, BLocaleRoster's GetLocalizedFileName() can be optimized is something for you code wizards to decide. :)

[pulkomandy]

I don't think this is really required for beta2 (or R1, for that matter), even if it is a "nice to have". I'd prefer we keep a very clear status of what *needs* to be done for beta2.