On 11/27/05, Reinhard Tartler <<a href="mailto:siretart@gmail.com">siretart@gmail.com</a>> wrote:<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> > I think that what Carlos wanted to point out is that certain > categories of packages need extra, domain-specific work that's not > easily included in the general package management tools. If the software is extensible with extra data, the user should install it in his home. I don't see what apt or other package managment tools can do about that.</blockquote><div> I disagree. In a way, apt already does something -- packages such as freepats and msttcorefonts are just the kind of "application specific" packages that I mentioned in my original post. But they are just "raw" packages that are needlessly hard for the novice to find. What is lacking, in my opinion, is a simple standard to allow specific applications (such as the "System > Settings > Fonts" application) to read the package database in a more inteligent way, selecting only the packages that apply for each application: font management, sound font management, and so on. </div> Please note that I do not propose any change to the existing package management tools; what I propose is to discuss a framework to provide some package management functionality on some of the system settings tools, in a simple and standard way. There is no need for big architectural changes, although packagers would need to follow a few rules just to make sure that the packages would be correctly processed by their specific managers, <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> His example with MIDI instruments means that there are (in theory) an > unlimited number of instrument packages, but there are only a limited > number of instruments that can be installed/configured at the same > time.  This requires extra constraints & configuration that's not > possible with general purpose apt frontends. > > In the case of TrueType fonts, you don't always want all fonts to be > installed at the same time (cluttering the font list in *all* > applications), but you want to have them around in case you need them. I don't quite understand. If a user wants extra fonts the system administrator does not provide for him, he should drop his fonts in ~/.fonts. Same for his MIDI instruments.</blockquote><div> Sincerely, and without irony: my proposal was based on the assumption that ease of use is one of Ubuntu's main goals. Most users never heard about ~/.fonts. Even less users know how to find new fonts to install, or how to preview them. Having a good font management applet would be a worthy goal -- perhaps not for Dapper, but even so, a worthy goal. </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I also think it would be up to his application using the MIDI instruments to provide some interface for easy installing of new instruments, if something like that is desired. </blockquote></div> Again, I disagree. Choice *is* good, and it's fine for the user to be able to choose between a number of music synthetisers, but we stand to gain nothing if every sequencer or softsynth has to provide its own instrument management subsystem. These pieces should be provided and managed in a standard way, allowing all related software to take advantage of them. -- Carlos Ribeiro Consultoria em Projetos blog: <a href="http://rascunhosrotos.blogspot.com">http://rascunhosrotos.blogspot.com</a> blog: <a href="http://pythonnotes.blogspot.com"> http://pythonnotes.blogspot.com</a> mail: <a href="mailto:carribeiro@gmail.com">carribeiro@gmail.com</a> mail: <a href="mailto:carribeiro@yahoo.com">carribeiro@yahoo.com</a>