Bosbeetle
Terminally lost
We need a pyra version of pandora panic
Please, please, please make it so we can run it (or have it fly out) from a menu rather than plastered to the bloody taskbar.
Every time I reflash my Pandora I have to spend bloody ages working through the configuration options to turn that fucking thing off (because you can't just delete it like most of the other icons, oh hell no, that would be too easy!), and then I have to reboot to get rid of it. Every. Damned. Time. It's not as if there's that much room on the Pandora's task bar to start with, but no, we have to have that bloody icon permanently attached. Who the hell decided it was a good idea to install it by default?
So please, make it less intrusive.
Edit: Looks like you're hoping to make a suite of preferences editors and have them open from the menu. Good man.
D.
It's a tray applet. Iirc, I added a mechanism to block startup years ago, can't remember how though. You could also just remove the autostart .desktop used by DEs to start it.
EDIT: Easier way: menu -> settings -> desktop -> session and startup [click]
application autostart -> uncheck pandora-configtray
I may have misunderstood your idea but thatCrazy idea... if the eMMC and the uSD are both going to be accessible in the main session and you're only going to keep your local mirror of the repository for 'just in case', why not put the 'maybe use' data on a uSD and still boot off of the eMMC? You can mount the repository from the uSD at will. Install might be 50% or so slower due to the contention, but 50% of the 50% of the 90MB/s rated speed of many uSD cards now is still 20+MB/s which is faster than the SD cards were on the Pandora. For an occasional access like that, it should be fine.
I may have misunderstood your idea but that
sounds more complicated to me than having the stuff I need every day on the fastest available storage device while keeping the emergency stuff on the largest available storage device, but still ready to use.
Still don't see the need for going through the extra hassle of providing somewhat up to date dpbs when downloading the deb from the repoistory and putting in on the SD-Card "just in case" should be sufficient. But maybe I am not getting the whole idea: How likely is it, that such an "autobuild" functionality will be working with only minor "hiccups" and how do you see that implemented (locally on a Pyra, or should there be a dedicated server/machine providing such a service) ?For packages you use every day, spending the space on internal memory is probably justified. But if you just want to be prepared for a special occasion, having a dbp on SD card is a good idea. For a lot of larger packages (e.g. Libreoffice, TeX, development tools) it makes sense to have the choice, because every user will have different needs. Having some form of dbp autobuild from upstream would be nice (and IIRC has already been talked about) not only for security critical packages like browsers.
I've been building PNDManager PNDs using Cloudef's makepnd (the tool to convert a recipe to a PND) since quite some time ago. Combined with Urjaman's dchrt build environment it's the best PND developer experience around@_jr_
Cloudef invented PUR that could handle PND building recipes and stored them online for others to use. It wasn't widely used, but it wasn't really advertised much either.. To me it seems like a good method for developers to create one click PND generation. I've been meaning to move my PNDs over to it at some point. I'm just horrible at managing my hobbies. Slashjag has made DBP building a ton easier to manage then generating a PND, implementing PUR to handle DBP building or something similar would be kind of nice too.