El mié, 17-12-2003 a las 16:23, Joe Shaw escribió: > On Wed, 2003-12-17 at 16:19, Manuel Amador (Rudd-O) wrote: > > At least we should > > * provide a way for apps to provide their templates in a system-wide > > fashion, but protected from deletion > > Please no. Every crappy application is going to install one of these, > and the next thing you know I am going to have 50 items in my context > menu, one of which allows me to "New SQL Query document" or something > else crackheaded that I would never use. And then we'll have to go back > to the drawing board because that's definitely not an acceptable > solution. Untrue. If this idea of yours were true, every proprietary linux application would install crap in the K menu as well. I don't see that happening now, and the K menu specification is much more widely implemented. On the negative side, if OEM app providers cannot install templates, it will be so much harder to garner support for this Template initiative. I automatically presumed that vendors and apps would install Sensible, Useful templates. Plus, if you're a sysadmin for a large installation, you'll just open Nautilus as root, go to the System template folder and delete the unwanted template so users cannot be bothered by it. The implementation should automatically hide the Template in question from that point on, or perhaps even delete it from the file system, since you're an administrator. And if you're an individual user, well, evidently you installed the app, so you will get the templates you need. If you don't want the, you can Go to the Templates folder and delete it. The system should hide it from you from that point on. (who the hell would want to create a New SQL Query document? App writers who put these kinds of crap in the Templates menu should be shot in the head) Although I admit this scenario of yours is a possibility =( people are people, so why should it be? > > > * provide a way for users to save and manage their templates, perhaps > > allowing them to personally override (but not system-wide) their > > templates, and revert to the default templates > > * merging system and user templates into one view > > * provide an api just like the desktop-file-install but for templates > > * do our stuff while keeping binary package systems in mind (RPM and > > DEB) > > This all seems way over-engineered and error-prone. As I'm sure anyone > who has worked on the menu system can tell you, trying to sanely merge > the user's changes with the system's settings is very difficult and > arguably not worth it. The merging code has already been written, and can be used, copied, librarized, or based upon to write the merging code for this. I don't say it would be easy. But if people had thought this way when doing the K app menu, we wouldn't have a merged system/user menu, and thus many app writers would be discouraged to integrate their apps into GNOME. > > Joe -- Manuel Amador (Rudd-O) GPG key ID: keyserver.net C1033CAD
Attachment:
signature.asc
Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente