Opened 6 years ago
Last modified 5 years ago
#14841 new enhancement
Make QuickLaunch part of Haiku
Reported by: | diver | Owned by: | nobody |
---|---|---|---|
Priority: | normal | Milestone: | Unscheduled |
Component: | Applications | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description (last modified by )
Several devs suggested making QuickLaunch an official app. Personally, I use it all the time and it makes my Haiku expearence a breeze.
Change History (12)
comment:1 by , 6 years ago
Description: | modified (diff) |
---|
comment:2 by , 6 years ago
comment:3 by , 6 years ago
It doesn't, but does it have to? Normally I assign a hotkey to quickly launch QuickLaunch :)
comment:4 by , 6 years ago
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.
comment:6 by , 6 years ago
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... :)
comment:7 by , 6 years ago
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).
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 :(
Would it be possible to cache the localized names to disk instead?
comment:8 by , 6 years ago
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).
comment:9 by , 6 years ago
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?
comment:10 by , 6 years ago
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. :)
comment:11 by , 5 years ago
Milestone: | Unscheduled → R1/beta2 |
---|
comment:12 by , 5 years ago
Milestone: | R1/beta2 → Unscheduled |
---|
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.
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)?