ste_167
Well-Known Member
DaveC said:
You've started something here, given that you actually like the PND system!
Last edited by a moderator:
Ok I Tried The Whole Separate Appdata Dir Thing
- Thread starter DaveC
- Start date
You've started something here, given that you actually like the PND system!
illusionx
Still Fresh
I think pnd and the appdata dir are very decent solution for the type of device we're talking about here.
The big problem isn't the system it's knowing what random crap the pnd is going to use as the appdata.
Examples
angrydd.EvilDragon
fheroes2.pickle
ioquake3.pickle
quake3.pickle
snes9x.skeezix.alpha
psx4pandora-1
fuse.cosam.0.9.0.0
Now I'm not going too bent out of shape about it because in general I can move the stuff about so it's in the right place and not every app needs extra files.
That said I can understand why it's annoying.
What to me makes more sense is that it should be more consistent in naming so you know what is related to what and also I shouldn't need to go put my files for Quake or whatever anywhere specific it should just ask me where I have them and quietly store that location in the config in appdata.
That way I can have 42 versions of quake2 and they can all find my pak files and if the little check script notices they're gone for any reason it could ask me where to find them.
So PNDs have my vote because I think they're a pretty good solution but like so many good tools when its rushed they can cause problems.
People want apps now and the devs are churning them out probably a bit faster than they'd like themselves. I'm sure they'd love them to be 100% perfect but they're getting them into our hands so we've got software to use now hopefully as time goes on the build and release process will become more refined and perhaps stuff will appear on the appstore in a beta section until it's polished to the point where there aren't these little annoyances hanging about.
The big problem isn't the system it's knowing what random crap the pnd is going to use as the appdata.
Examples
angrydd.EvilDragon
fheroes2.pickle
ioquake3.pickle
quake3.pickle
snes9x.skeezix.alpha
psx4pandora-1
fuse.cosam.0.9.0.0
Now I'm not going too bent out of shape about it because in general I can move the stuff about so it's in the right place and not every app needs extra files.
That said I can understand why it's annoying.
What to me makes more sense is that it should be more consistent in naming so you know what is related to what and also I shouldn't need to go put my files for Quake or whatever anywhere specific it should just ask me where I have them and quietly store that location in the config in appdata.
That way I can have 42 versions of quake2 and they can all find my pak files and if the little check script notices they're gone for any reason it could ask me where to find them.
So PNDs have my vote because I think they're a pretty good solution but like so many good tools when its rushed they can cause problems.
People want apps now and the devs are churning them out probably a bit faster than they'd like themselves. I'm sure they'd love them to be 100% perfect but they're getting them into our hands so we've got software to use now hopefully as time goes on the build and release process will become more refined and perhaps stuff will appear on the appstore in a beta section until it's polished to the point where there aren't these little annoyances hanging about.
skeezix
Internal Development
yeah, app data directory names will get better; its my fault they're goofy named currently, since I enocuraged that pre-release, but fiscouraged goofy names in the last few months before release. So old ports from waaay back have goofy names, and the 'templates' carried forward.
ie: In the past we only had 'unique-id', and it was used for the appdata directory name; I had a good reason for it I think. But it became clear later that appdata directory names should be mergable (ie: two or more unique apps may want ot share the same appdata), and should also have the option to a sensible name. (Also, a few people like dflemstr suggested it too, they cut right to the chase3 quicker than I did on that one
So the system 'fails sensibly' -- if a PXML advertises only a unique-id, that will be used for appdata name; but if it advertises a appdata name (like it should), thats what gets used, and usually is a normal name.
A few PXMLs still don't have appdata names in them (the old way), but most should (the new way), and look sensible.
jeffhurried
ie: In the past we only had 'unique-id', and it was used for the appdata directory name; I had a good reason for it I think. But it became clear later that appdata directory names should be mergable (ie: two or more unique apps may want ot share the same appdata), and should also have the option to a sensible name. (Also, a few people like dflemstr suggested it too, they cut right to the chase3 quicker than I did on that one
So the system 'fails sensibly' -- if a PXML advertises only a unique-id, that will be used for appdata name; but if it advertises a appdata name (like it should), thats what gets used, and usually is a normal name.
A few PXMLs still don't have appdata names in them (the old way), but most should (the new way), and look sensible.
jeffhurried
Dunny
Exophase Approved® Forum Troll
mindlord said:
Been using Slackware for about a week now, and I hate packages with a passion. I just cannot get my head around them, and they seem to spray files all over the file system in places I couldn't even guess. Building them is even worse! I'd rather not use a package system if at all possible, they're just too confusing for someone who isn't an uber-geek (for "geek" read: no-life, lives at home with parents past 35 years old). I mean, I've got linux to do what I want it to, but I've used GBs of disk space doing so, don't know where the files are that I should delete to clean up and have no idea what's changed in the filesystem. I assume that unpacking a package and manually installing the files myself is one of the more advanced topics that I'll likely get to later?
D.
Last edited by a moderator:
skeezix
Internal Development
traditional package systems are a bit messy/historical; every distro has different rules for where to put things, and switchig distros youmay not know where to look. (As a BSD guy, I'm forever surprised ot find debian putting so much stuff in /etc/APPNAME, for instance.)
To be fair, in comparing package/repo to PND, we should assume that the packages are very much custom tailored to Pandora -- ie: to putting everything in one directory, for safe storage on SD and not spitting stuff to /usr/lib on NAND, etc.
One of the benefits of PND is that it requires/forces the dev to think in those terms; its not like another packager, you have to do _this_ and _that_.
If using a traditional repoi/packager, devs might get lazy, but thats not a technology thing.
Certainly, historical package systems defaults cannot be used, but likewise.. ubuntu and debian and others have their own guidelines, so we'd have to have our own for our Pandora repository.
(See, I'm not anti repository, we just came up with a system, we thought would be easy for everyone to work with. But I'm not anti anything else, and I _really_ don't know where people get the idea I am. *boggle*
jeff
To be fair, in comparing package/repo to PND, we should assume that the packages are very much custom tailored to Pandora -- ie: to putting everything in one directory, for safe storage on SD and not spitting stuff to /usr/lib on NAND, etc.
One of the benefits of PND is that it requires/forces the dev to think in those terms; its not like another packager, you have to do _this_ and _that_.
If using a traditional repoi/packager, devs might get lazy, but thats not a technology thing.
Certainly, historical package systems defaults cannot be used, but likewise.. ubuntu and debian and others have their own guidelines, so we'd have to have our own for our Pandora repository.
(See, I'm not anti repository, we just came up with a system, we thought would be easy for everyone to work with. But I'm not anti anything else, and I _really_ don't know where people get the idea I am. *boggle*
jeff
mindlord
Notices Two Things
Slackware's package management is not modern in any sense of the word. Slackware is not a friendly Linux in any sense of the word. Slackware is a TERRIBLE Linux to try if you're new the the Linux world. I don't know your level of Linux experience, but if you're new to it, Slackware was a bad choice. Pick something less intense like Fedora, Mandriva, or Ubuntu.Dunny said:
The whole idea of package management is to take the worry out of it, and to prevent you from having to build anything. I far better example of package management is Redhat's RPM (yum), Debian's DEB (apt-get), or even Angstrom's .IPK (opkg).
As for "file spray" Why sweat it? If the package manager knows what goes where, and what gets yanked when an app is unistalled who cares where it goes? This isn't windows. The Package Manager takes care of all the custodial tasks for you. Do you care where the contents of a PND gets mounted to when you activate it? All you as a user should care about is your home folder and it's contents (configs, data, documents, desktop). You click the icon, or type foo on the command line.. program runs.
It's hard coming from Windows where you have to keep tabs on your applications to make sure the clean up after themselves, but with proper package management, everything works, and you are relieved of this responsibility.
Last edited by a moderator:
Dunny
Exophase Approved® Forum Troll
mindlord said:
I spent a lot of time around other Linux users and forums, asking questions like "I'm a total newbie to Linux - what distro do you recommend if I want to learn this OS?" and I was almost unanimously told to get Slack and avoid distros like Ubuntu. So I downloaded and installed Slackware 13.1, 64bit.
The whole point of learning linux was that I would learn how the system works - and that includes knowing where the files are for the packaged apps I install.
Hell, it would be nice if it actually informed me of where it was going to put stuff - but most things seem to install their configs into hidden directories somewhere in my /home architecture. Hidden even from the shell, by god. Almost as if linux doesn't actually want me knowing where these things are! How very ... Windows it seems to behave.
So if I'd installed a distro that made things easier, do you think more would have been hidden from me, or less? How much would I have learnt about where files go by using Ubuntu?
FWIW, yes, Linux is hard for someone coming from Windows 7, and let's face it - the UI in any of the desktops is just horrible, as each one badly supports apps written for the others. GTK apps look bad under KDE, KDE and GTK look bad in e17, etc etc. But that's just eye-candy, and nothing really to do with the underlying OS. Which is what I wanted to learn. And it seems that packages and linux itself deliberately make that harder than it needs to be.
At least with Slackbuilds I'm actually downloading source and compiling my own packages, which gives me some measure of control that I wouldn't have if I just downloaded packages. My poor /tmp directory is straining at the seams now though
Mind you, at least I know where those files are and can delete accordingly!D.
Last edited by a moderator:
WizardStan
Mega GP Mania
- Joined
- May 24, 2008
- Messages
- 16,731
At least Ubuntu, the package manager has a properties button for the packages you can install that lists directories files go into, but not the files themselves. Synaptic will list out all files in a package and where they go if you don't mind the command line.Dunny said:
Last edited by a moderator:
I'll try to clear up the whole package manager vs. installer vs. PND issue by explaining the various application management strategies in modern desktop computing.
In general there are three approaches to application management among the major OSes:
Windows trusts the installer to manage where to put files and how to get rid of them later. Actually, the installer is an application that may do anything anywhere, is not really standardized (there are still many installers that don't use MSI) and doesn't neccessarily remove anything it installed when operated in reverse. This may even include the start menu entries, which are usually installer-managed. Decently-written installers will clean up most of their junk, though.
Linux tends towards package managers. Your distribution's maintainers build all software (except for proprietary programs, of course) for you and manage what goes where. When you want to install something you just tell the package manager what you want and it takes care of what do download, where the files go and how to put the program into the program menu if applicable. If you want something uninstalled the package manager knows which files to remove and whether this will break other installed packages. The big advantage is that the maintainers know exactly how everything works so everything meshes well and the files are all easily managed – by the package manager. If you need to access them directly you can usually get the package manager to tell you their location, though.
Mac OS X uses self-contained application bundles. Each app bundle is actually a directory structure that includes all binaries, libraries and other resources the application needs, save for those guaranteed to be provided by the operating system. The Finder (OS X's file manager) presents app bundles as single files to the user, although you can explore them via a context menu entry. App bundles are distributed via easily mounted image files. Installation means copying the bundle from the image to somewhere else (although most apps can be run from their image). Uninstallation means deleting the app bundle. There is no application menu, only a standard directory and a desktop search engine, thus menu management is nonexistent. Organization is up to the user.
There are also some programs that require installation, usually because they need to interact with the system on a low level. These are roughly similar to Windows installers, although it's much less common to not use the OS X default installer framework.
All three operating systems usually leave user preferences in place when you uninstall something. On Windows the uninstallers may offer to delete them for you and on Linux and OS X user preferences are stored as regular files in well-known locations so you can easily delete them yourself. Linux and OS X make migration of preferences easy as you simply need to copy over one or two directories.
Under no major operating system is the user expected to directly interact with program files. OS X comes the closest by letting you choose where to put the application bundle but the bundle's contents are considered not to be of interest to the average user.
The Pandora uses an approach similar to that of OS X. The reason is simple: By making applications self-contained the system doesn't have to manage them past noticing they're there and exposing their location to unser interface tools (such as XFCE's mprogram menu). This is important in a device where any number of apps may spontaneously disappear whenever someone unmounts a removable disk.
Of course we still need a well-defined place to put application data in. Since SD cards should be self-contained (no application should stop working because data outside the card has gone away) the only logical place is in a designated directory on the same card. Hence the appdata directory.
In general there are three approaches to application management among the major OSes:
Windows trusts the installer to manage where to put files and how to get rid of them later. Actually, the installer is an application that may do anything anywhere, is not really standardized (there are still many installers that don't use MSI) and doesn't neccessarily remove anything it installed when operated in reverse. This may even include the start menu entries, which are usually installer-managed. Decently-written installers will clean up most of their junk, though.
Linux tends towards package managers. Your distribution's maintainers build all software (except for proprietary programs, of course) for you and manage what goes where. When you want to install something you just tell the package manager what you want and it takes care of what do download, where the files go and how to put the program into the program menu if applicable. If you want something uninstalled the package manager knows which files to remove and whether this will break other installed packages. The big advantage is that the maintainers know exactly how everything works so everything meshes well and the files are all easily managed – by the package manager. If you need to access them directly you can usually get the package manager to tell you their location, though.
Mac OS X uses self-contained application bundles. Each app bundle is actually a directory structure that includes all binaries, libraries and other resources the application needs, save for those guaranteed to be provided by the operating system. The Finder (OS X's file manager) presents app bundles as single files to the user, although you can explore them via a context menu entry. App bundles are distributed via easily mounted image files. Installation means copying the bundle from the image to somewhere else (although most apps can be run from their image). Uninstallation means deleting the app bundle. There is no application menu, only a standard directory and a desktop search engine, thus menu management is nonexistent. Organization is up to the user.
There are also some programs that require installation, usually because they need to interact with the system on a low level. These are roughly similar to Windows installers, although it's much less common to not use the OS X default installer framework.
All three operating systems usually leave user preferences in place when you uninstall something. On Windows the uninstallers may offer to delete them for you and on Linux and OS X user preferences are stored as regular files in well-known locations so you can easily delete them yourself. Linux and OS X make migration of preferences easy as you simply need to copy over one or two directories.
Under no major operating system is the user expected to directly interact with program files. OS X comes the closest by letting you choose where to put the application bundle but the bundle's contents are considered not to be of interest to the average user.
The Pandora uses an approach similar to that of OS X. The reason is simple: By making applications self-contained the system doesn't have to manage them past noticing they're there and exposing their location to unser interface tools (such as XFCE's mprogram menu). This is important in a device where any number of apps may spontaneously disappear whenever someone unmounts a removable disk.
Of course we still need a well-defined place to put application data in. Since SD cards should be self-contained (no application should stop working because data outside the card has gone away) the only logical place is in a designated directory on the same card. Hence the appdata directory.
Zeno Arrow
Member
- Joined
- Oct 5, 2008
- Messages
- 195
Dunny said:
I strongly dislike packages/package managers too, I don't care if they make things easy, I want to know what files are being put where and why. I really hope GoboLinux takes off, but otherwise I've given up on Linux offering an understandable file system layout. BSD distros are better in this regard, when I'm ready to carry on learning about Unix I'm going straight back to OpenBSD.
The reason Slackware was probably recommended to you is it's as close to a vanilla distro as you're going to get without taking the LFS route. Slackware doesn't try and patch things up and do many custom tweaks to its system, it just provides you with a basic, stable system. The advantage of starting with Slackware is you don't rely too much on custom distro-only tools, learn how to do something in Slackware and you probably can replicate the same thing in most other distros without too much hassle. I personally liked Slackware-based distros (Zenwalk, Wolvix, etc...) more than Slackware itself, but each to their own.
Oh and if you want to see hidden files using Bash, enter ls -a . You'll find hidden files in Linux start with a full stop, so for instance '.settings' is hidden, 'settings' is not. Hope this helps.
Last edited by a moderator:
mindlord
Notices Two Things
It was probably how you phrased the question, you probably wanted to dive right in. I assume you're a Windows Power user, and like to tweak the daylights out of it. Yep, you're going to learn a lot by trying Slackware first, but you're going to give yourself a headache too.Dunny said:I spent a lot of time around other Linux users and forums, asking questions like "I'm a total newbie to Linux - what distro do you recommend if I want to learn this OS?" and I was almost unanimously told to get Slack and avoid distros like Ubuntu. So I downloaded and installed Slackware 13.1, 64bit.
The whole point of learning linux was that I would learn how the system works - and that includes knowing where the files are for the packaged apps I install.
Hell, it would be nice if it actually informed me of where it was going to put stuff - but most things seem to install their configs into hidden directories somewhere in my /home architecture. Hidden even from the shell, by god. Almost as if linux doesn't actually want me knowing where these things are! How very ... Windows it seems to behave.
So if I'd installed a distro that made things easier, do you think more would have been hidden from me, or less? How much would I have learnt about where files go by using Ubuntu?
FWIW, yes, Linux is hard for someone coming from Windows 7, and let's face it - the UI in any of the desktops is just horrible, as each one badly supports apps written for the others. GTK apps look bad under KDE, KDE and GTK look bad in e17, etc etc. But that's just eye-candy, and nothing really to do with the underlying OS. Which is what I wanted to learn. And it seems that packages and linux itself deliberately make that harder than it needs to be.
At least with Slackbuilds I'm actually downloading source and compiling my own packages, which gives me some measure of control that I wouldn't have if I just downloaded packages. My poor /tmp directory is straining at the seams now though
D.
I prefer the walk before you run approach to Linux. I strongly recommend the easier to use Distros at first, so the user can get used to the big sweeping differences between Linux and Windows. Then when they are comforatable, wade into the more technical and mind boggling aspects of the system. When you peel back Ubuntu's shiney veneer you'll find that it's not at all different than Slackware, it's just packaged in a more "end-user" friendly way. The reason you were recommended Slackware was probably because you didn't want any hand-holding from the Distro... Slack is certainly good at that. Easier Distros don't hide any more stuff from you than Slackware, they just give you better tools to deal with problems. I honestly haven't touched Slack in over 10 years, but I assume it's still the gearhead's Linux. Ubuntu and friends still have all the same configuration files as Slack, they just have more GUI tools to get the configuring done. You can still fire up a terminal and vi or emacs away at the /etc folder if you want to, just like Slack.
Configuration files are hidden for the same reasons they are in Windows, yes. Because when you're not administering the system you probably don't want to look at them. In almost all file managers Ctrl-H will toggle hidden files, and ls -a will list all hidden files and directories at the command prompt. This is normal stuff.
I think you'll be hard pressed to find anyone who doesn't agree with you on the choatic state all the varying window managers creates. But that's why most people settle on the one they like most and stick with it, and the apps designed around it. Most common applications are designed to be window manager agnostic, except those designed by the team that made the window manager itself. Although KDE seems to be doing a better job as of late making agnostic applications. Amarok is a good example of that.
WizardStan is right though, you can query the Package Manager database and have it tell you all sorts of information about the Packages you have installed. Size, dependancies, etc. Including what files it will install and where they are to go. Synaptic in Ubuntu does indeed give all locations and files, btw. We all wish InstallShield under Windows was as helpful.
Last edited by a moderator:
And the result for hiding these directories "even from the shell" is that in ye olden days the shell was everything there was and people didn't want to have their `ls ~` cluttered up by a hundred config dirs. Now I don't know why nobody could come up with something like ~/etc/<app name> but the hidden config directories are really there for readability.Zeno Arrow said:
One thing I like about OS X: There, the preferred places are ~/Library/Preferences/<app name> for preferences and ~/Library/Application Support/<app name> for random app-related files. Feels much cleaner. Of course it was also developed much later.
Last edited by a moderator:
Dunny
Exophase Approved® Forum Troll
mindlord said:
Thanks for understanding me and not taking umbrage at my explanation!
I think that it was the way I don't take much interest in how windows does what it does that I became interested in Linux. As for "power user"... :-D
I can make the machine sing and dance or whatever I want it to do. I suppose in that way, I'm above average - but lately I've become less interested in coding and more interested in how the OS works. As the Pandora is "just around the corner", I decided I better learn the OS it uses. Hence, I'm very comfortable in Windows, and was very, very lost in linux. I persevered, and I'm less uncomfortable now. I "get" the idea of config files, and how to edit them (one thing I had to learn was how to actually start an editor!). I'm not scared of packages, but I do dislike them - but that's probably because they don't do things the way that windows does. I shall learn, but there's that niggling feeling at the back of my mind that all this can be done better...
And maybe when I understand enough, I'll either change my mind and see the wisdom, or I'll do it better myself.
The thing the bugs the shit out of me is that GTK/QT apps look like crap in KDE and others. The fonts are wrong (and yes, I've applied all the fixes on the 'net). Buttons are too large, with the text too big when compared to other buttons... scrollbars look wrong. Firefox and Chrome use the wrong fonts for rendering (I installed my windows TTF fonts to no avail - even gp32x.de looks wrong with the lefthand menu wrapping around). It just irritates, but that's a discussion for another thread (or indeed, another forum) and I'm going way off-topic here.
D.
Last edited by a moderator:
mindlord
Notices Two Things
I'm a very patient guy, and usually have no problem seeing another person's point of view.Dunny said:
I totally get where you are coming from I too had a strong Windows background, and could beat the holy hell out of a Windows XP install. I spent years accumulating tweaks, tricks, and hacks to make Windows sing. It took years of back and fourth before I finally dumped Windows as my main OS. I first installed Slackware back in 1997, managed to get Doom running in framebuffer mode without sound, gave up. Installed Mandrake in 1998, stumbled on something, gave up. Went on like that every year. Try another Distro, hit a wall, try another, hit a wall... Along the way I slowly started accumulating tricks and figuring out who does what in Linux, and eventually I tried Ubuntu and the Kool-Aid was very strong with it. I'm hooked. I still try new distros, but now Ubuntu feels like home, just like Windows did. You might eventually find "home" to be some other distro, and that's what's great about Linux.
I appriciate that Slackware, Gentoo, and Arch are good solid Linux distros geared toward the power user. Ubuntu, however - just works, and that's what I want. I can install it, and within 2 hours have a fully loaded development system, tweaked to my liking. Simply couldn't do that in Windows, or with any other distro I've tried. Ubuntu takes care of the fiddly bits, that I could set up on my own by now, but don't want to anymore. If Ubuntu doesn't do something that I really want it to, I can still fire up a terminal and do things the Slackware way, but more often than not I don't have to.
Eventually, I think you'll grow to like Package Managers because it will finally sink in that it's actually a relief that you don't have to sweat the details anymore. The guys who are packaging these applications are just as concerned about stability and speed as you are. They are geeks just like us.
Last edited by a moderator:
I understand how the current pnd system works and I think it's fine.
Two quick question(s):
1) Is it possible for a pnd to look outside of its appdata directory (maybe this is a permission question) for files? For instance, let's say you have multiple emulators for the same console and you don't want to duplicate the roms, is it possible for the emulators to look in the same place (either by default or by browsing for the roms), perhaps under "sd1/roms/snes"?
2) Is there a simple way (without editing the pnd and pxml) to edit where applications show up in the menu and in folders on the desktop? For instance:
Apps:
-Fennec
-Gimp
-Word Processor
Games:
-Battle Jewels
-Hexen
-PandoraPanic
It probably doesn't sound necessary now, but when we start accumulating a lot of different programs, I really like to separate them into places where I know to look so I'm not browsing through a hundred different programs.
Two quick question(s):
1) Is it possible for a pnd to look outside of its appdata directory (maybe this is a permission question) for files? For instance, let's say you have multiple emulators for the same console and you don't want to duplicate the roms, is it possible for the emulators to look in the same place (either by default or by browsing for the roms), perhaps under "sd1/roms/snes"?
2) Is there a simple way (without editing the pnd and pxml) to edit where applications show up in the menu and in folders on the desktop? For instance:
Apps:
-Fennec
-Gimp
-Word Processor
Games:
-Battle Jewels
-Hexen
-PandoraPanic
It probably doesn't sound necessary now, but when we start accumulating a lot of different programs, I really like to separate them into places where I know to look so I'm not browsing through a hundred different programs.
cosam
Active Member
PNDs can look in any directory they like, even their neighbours' appadata, provided the have permission (which is usually the case). One problem at the moment is that SD cards don't have a guaranteed mount point, i.e. you get /media/mmcblkXp1 where the X can change. I'd really love to see that sorted out, maybe by using the volume label as some other Linux distributions do. Personally I keep all my apps on one card and data/ROMs on another. I've not found an app yet that can't work with this set-up and if I did, I'd consider that app to be broken.DasFool said:
Last edited by a moderator:
Caine
Hardcore Member
Naturally. You typically wouldn't place roms in the appdata directory but rather in a special roms directory.DasFool said:
The appdata directory should contain the writeable files of the program itself (e.g. config and saves), not the files it operates upon. You wouldn't store your documents in the appdata directory either. The user normally doesn't need to touch these files at all. There are a few notable exceptions such as adding of files which are not freely distributable (e.g. commercial PAK or WAD files). Without the legal limitations, these files would have been part of the PND itself.
No, this currently requires editing the pxml. I'm sure someone will write an application to edit these. Otherwise I'll probably write one myself.
Last edited by a moderator:
skeezix
Internal Development
You can override the pxml without hacking the pnd
see unifficial user manual on pandorawiki and look up ovr files
you can override name, category, CPU speed, pics, icons etc
jeff
see unifficial user manual on pandorawiki and look up ovr files
you can override name, category, CPU speed, pics, icons etc
jeff
