From: Shaffer, C. <Chris.Shaffer@BellSouth.com> - 2003-08-26 19:35:30
|
Completely agree. The current process is very tiresome. Also, having an APPDIRPATH var would enable communication between apps. For instance: MusicBox calls Songer to edit MP3 tags, while Songer calls MusicBox to play MP3s. Right now, I'd have to setup an option in Songer for the location of MusicBox (I think...). OT ----- I was also thinking it would be nice if the README, CHANGES, etc files where markedup, like docbook, for formatted display. Just a thought. Chris Shaffer -----Original Message----- From: rox...@li... [mailto:rox...@li...] On Behalf Of Guido Schimmels Sent: Tuesday, August 26, 2003 2:00 PM To: rox...@li... Subject: [rox-devel] Proposal: AppInfo.xml MIME-tag Hi, I would like to add a tag like the "mime_types" field of the Gnome application-registry to AppInfo.xml. The purpose is to automatically populate the SendTo directory, either via a script scanning over APPDIRPATH or individually by each application's AppRun. I think the current situation is not particularly user-friendly. Manually creating SendTo entries is tedious, especially for apps which can handle a broad range of file types. And how am I supposed to know which ones? The app itself should tell. Example gThumb: <?xml version="1.0"> <AppInfo> <mime_types>x-directory/normal,image/jpeg,image/gif,image/png, image/tiff,image/x-bmp,image/x-png,image/xpm,image/x-tga</mime_types> <Summary xml:lang="en">gThumb Image Viewer</Summary> ... Please let me know what you think! ------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 _______________________________________________ rox-devel mailing list rox...@li... https://lists.sourceforge.net/lists/listinfo/rox-devel ***** "The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers." |
From: Tilo R. <t.r...@vi...> - 2003-08-27 07:40:39
|
Hello, > Completely agree. The current process is very tiresome. Also, having > an APPDIRPATH var would enable communication between apps. The advantage of Rox is the possibility to install aps somewhere. If we use a path variable this advantage is lost I think. Maybe we should use something a registry? ;-))) Best regards, Tilo |
From: Christopher S. <che...@ya...> - 2003-08-27 11:30:39
|
--- Tilo Riemer <t.r...@vi...> wrote: > The advantage of Rox is the possibility to install aps somewhere. If we use a path variable this > advantage is lost I think. > Maybe we should use something a registry? ;-))) You're right. But its not totally lost. You could still install Apps whereever you wanted. They just would not be in a search path for some functions. But, I, too had thought about a registry <shudder>... Perhaps an XML file that Apps make an entry into when they start? For instance: Songer starts, and checks $CHOICES/ROX-Filer/apps.xml for its entry. There is no entry for Songer, so it appends its own entry with the following info: Name Version Path (Mime-Types supported?) Now, lets say there was an entry for Songer: Songer starts, and checks $CHOICES/ROX-Filer/apps.xml for its entry. Finding an entry, it moves on. This is where I got my mind wrapped around the wheel axel: What do you do when you find an entry for your app, but the path is different? Do you update it with your currrent path? I don't think that will work, because I will commonly have more than one copy of an app installed (one stable, one for tweeking...) Should we just add a second and third entry? Don't think that will work either, cause then the file would grow out of control... I think this is a good conversation to be having... Chris Shaffer __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com |
From: David J. <je...@ch...> - 2003-08-27 16:11:21
|
In the mimetypes area, I recommend AppInfo.xml include the mimetype, possible file extensions, a pleasant name of the filetype, and a relative path to an icon for the mimetype (Which is inside the wrapper). Also, I've been thinking alot about standardization of something like AppInfo.xml and having it contain lots of important information. You can read some of my thoughts here: http://groups.yahoo.com/group/OpenBundle/message/5 http://mozart.chat.net/~jeske/Projects/OpenBundle/ This is the kind of information I'd like to include: I. GUI Applications 1) platform binaries (so you can have multiple binaries, each for a different platform), and binary type (elf binary? python? Java? .NET?) 2) the application icon 3) mimetypes supported, and icons for each mimetype 4) application right-click context menu 5)a Application scripting API (think Win32 DDE) II. Plug-Ins/Libraries Provided 1) shlib/dso/java libraries (per platform/type) 2) plug-in application 3) plug-in type/api III. Dependencies Required 1) system dependencies (rpm? shlib name?) 2) other bundles which are required (shlibs) 3) types of plug-in bundles which are useful IV. Development Kits 1) headers 2) library binaries (per-platform target) 3) source code for source-debugging (zip archive?) V. Servers/Daemons 1) restartable services -- David Jeske (N9LCA) + http://www.chat.net/~jeske/ + je...@ch... |
From: Jaap K. <j.g...@st...> - 2003-08-27 16:38:09
|
On Wed, 27 Aug 2003 09:10:47 -0700 David Jeske wrote: : In the mimetypes area, I recommend AppInfo.xml include the mimetype, : possible file extensions, a pleasant name of the filetype, and a : relative path to an icon for the mimetype (Which is inside the : wrapper). This wouldn't be the right place for that kind of mimetype information. When you look at the structure of the freedesktop shared mime-info database you'll see that it all ready allows you to add xml files with mimetype information to the database very easily. Just provide a xml file that will be copied/linked into the database at install time (or first time you run the program) -- no need to pollute AppInfo.xml with this information. -- ) ( Jaap Karssenberg || Pardus [Larus] : : http://pardus-larus.student.utwente.nl/~pardus ) \ / ( ",.*'*.," " Where computers are concerned _always_ be paranoid " |
From: David J. <je...@ch...> - 2003-08-27 17:02:16
|
On Wed, Aug 27, 2003 at 06:40:02PM +0200, Jaap Karssenberg wrote: > On Wed, 27 Aug 2003 09:10:47 -0700 David Jeske wrote: > : In the mimetypes area, I recommend AppInfo.xml include the mimetype, > : possible file extensions, a pleasant name of the filetype, and a > : relative path to an icon for the mimetype (Which is inside the > : wrapper). > > This wouldn't be the right place for that kind of mimetype information. > When you look at the structure of the freedesktop shared mime-info > database you'll see that it all ready allows you to add xml files with > mimetype information to the database very easily. Just provide a xml > file that will be copied/linked into the database at install time (or > first time you run the program) -- no need to pollute AppInfo.xml with > this information. I understand what you are saying but I disagree. The purpose of a centralized mime-info database is different than AppInfo mime-exports. As an application author, I don't want to have to learn about all the different centralized mime-type databases (of which there are several and always will be), I just care about one thing --> distributing my application. If your system uses the freedesktop shared mime-info database, great, you can build your information from AppInfo.xml files. If my system uses Gnome, KDE, or who knows what else, great, I can teach those systems to read from AppInfo.xml files also. It is not scalable to have every application author update every centralized mime database for their filetypes. It is also not pleasant to have every user manually update the centralized database for every application. However, I should point out that this is not my scheme. This is the scheme developed by Nextstep and now adopted by MacOS X. It works really well, I recommend you go try it before you knock it. Having applications include detailed information about the mimetypes they understand is repetitive, but it assures that once you get the app, your system knows about its filetypes. Allowing every application to suppily icons for the mimetypes they supports allows the filemanager to give the user feedback about which application is the default to open a datafile -- by displaying that application's custom icon for that mimetype. This is another aspect which works really well on Nextstep/MacOS X. -- David Jeske (N9LCA) + http://www.chat.net/~jeske/ + je...@ch... |
From: Jaap K. <j.g...@st...> - 2003-08-27 19:27:06
|
On Wed, 27 Aug 2003 10:01:45 -0700 David Jeske wrote: : The purpose of a centralized mime-info database is different than : AppInfo mime-exports. As an application author, I don't want to have : to learn about all the different centralized mime-type databases (of : which there are several and always will be), I just care about one : thing --> distributing my application. If your system uses the : freedesktop shared mime-info database, great, you can build your : information from AppInfo.xml files. If my system uses Gnome, KDE, or : who knows what else, great, I can teach those systems to read from : AppInfo.xml files also. But the xml for the freedesktop database is almost identical to what you are proposing, only it would be a seperate file in your package instead of being in AppInfo - so why not adopt the freedesktop xml and learn Gnome and KDE that ? Also the freedesktop database can handle multiple source files, so each application can ship it's own extensions I would like to have information in the AppInfo file about which mime-types can be handled by an app, because that is app specific information. : It is not scalable to have every application author update every : centralized mime database for their filetypes. It is also not pleasant : to have every user manually update the centralized database for every : application. I would never dare to ask that effort from anyone, I do applications myself ya know ;) : Having applications include detailed information about the mimetypes : they understand is repetitive, but it assures that once you get the : app, your system knows about its filetypes. Allowing every application : to suppily icons for the mimetypes they supports allows the : filemanager to give the user feedback about which application is the : default to open a datafile -- by displaying that application's custom : icon for that mimetype. This is another aspect which works really well : on Nextstep/MacOS X. Isn't this functionality all ready provided by that AppDir system ? I'm all for bundled information, I just don't think you should put all information in one xml file, using multiple files seems more modular to me. -- ) ( Jaap Karssenberg || Pardus [Larus] : : http://pardus-larus.student.utwente.nl/~pardus ) \ / ( ",.*'*.," " Where computers are concerned _always_ be paranoid " |
From: David J. <je...@ch...> - 2003-08-27 19:51:14
|
On Wed, Aug 27, 2003 at 09:28:55PM +0200, Jaap Karssenberg wrote: > On Wed, 27 Aug 2003 10:01:45 -0700 David Jeske wrote: > : The purpose of a centralized mime-info database is different than > : AppInfo mime-exports. As an application author, I don't want to have > : to learn about all the different centralized mime-type databases (of > : which there are several and always will be), I just care about one > : thing --> distributing my application. If your system uses the > : freedesktop shared mime-info database, great, you can build your > : information from AppInfo.xml files. If my system uses Gnome, KDE, or > : who knows what else, great, I can teach those systems to read from > : AppInfo.xml files also. > > But the xml for the freedesktop database is almost identical to what you > are proposing, only it would be a seperate file in your package instead > of being in AppInfo - so why not adopt the freedesktop xml and learn > Gnome and KDE that ? Sounds fine. When I look at the freedesktop site all I find is lots of information about the centralized mimetype database. Can you tell me where I can find this simple mimetype info file, and information encouraging application authors to just passivly put it in a relocatable package like AppInfo? Seems like it should be added here: http://rox.sourceforge.net/Manual/Manual/Manual.html#AppDir > : Having applications include detailed information about the mimetypes > : they understand is repetitive, but it assures that once you get the > : app, your system knows about its filetypes. Allowing every application > : to suppily icons for the mimetypes they supports allows the > : filemanager to give the user feedback about which application is the > : default to open a datafile -- by displaying that application's custom > : icon for that mimetype. This is another aspect which works really well > : on Nextstep/MacOS X. > > Isn't this functionality all ready provided by that AppDir system ? I'm > all for bundled information, I just don't think you should put all > information in one xml file, using multiple files seems more modular to > me. It seems like with XML and namespaces it would be simpler if we could teach application developers about one file "AppInfo.xml", and then just have lots of different types of sections they can include in this file. However, this point does not really matter. I can't find the definition of this mimetype xml file. -- David Jeske (N9LCA) + http://www.chat.net/~jeske/ + je...@ch... |
From: Stephen W. <wa...@ue...> - 2003-08-28 07:43:05
|
In message <200...@mo...> David Jeske <je...@ch...> scribbled: > On Wed, Aug 27, 2003 at 09:28:55PM +0200, Jaap Karssenberg wrote: > > On Wed, 27 Aug 2003 10:01:45 -0700 David Jeske wrote: > > : The purpose of a centralized mime-info database is different than > > : AppInfo mime-exports. As an application author, I don't want to have > > : to learn about all the different centralized mime-type databases (of > > : which there are several and always will be), I just care about one > > : thing --> distributing my application. If your system uses the > > : freedesktop shared mime-info database, great, you can build your > > : information from AppInfo.xml files. If my system uses Gnome, KDE, or > > : who knows what else, great, I can teach those systems to read from > > : AppInfo.xml files also. > > > > But the xml for the freedesktop database is almost identical to what you > > are proposing, only it would be a seperate file in your package instead > > of being in AppInfo - so why not adopt the freedesktop xml and learn > > Gnome and KDE that ? > > Sounds fine. When I look at the freedesktop site all I find is lots of > information about the centralized mimetype database. Can you tell me > where I can find this simple mimetype info file, and information > encouraging application authors to just passivly put it in a > relocatable package like AppInfo? For a concrete example look at how the filer installs a type definition for .DirIcon files. It copies rox.xml into ${SHAREDIR}/mime/packages and runs update-mime-database. Look at install.sh and rox.xml in the source distribution. This is covered in the Shared MIME-info Database spec. -- Stephen Watson Physicist Ultra Electronics Ltd - Signature Management Systems (UESMS) Tel: +44 (0)1543 878888 (switchboard) Fax: +44 (0)1543 878249 Email: wa...@ue... |
From: Stephen W. <st...@ke...> - 2003-08-27 17:12:36
|
David Jeske <je...@ch...> wrote: > In the mimetypes area, I recommend AppInfo.xml include the mimetype, > possible file extensions, a pleasant name of the filetype, and a > relative path to an icon for the mimetype (Which is inside the > wrapper). No. That belongs in the share MIME database. > Also, I've been thinking alot about standardization of something like > AppInfo.xml and having it contain lots of important information. You > can read some of my thoughts here: > > http://groups.yahoo.com/group/OpenBundle/message/5 > http://mozart.chat.net/~jeske/Projects/OpenBundle/ > > This is the kind of information I'd like to include: > > I. GUI Applications > 1) platform binaries (so you can have multiple binaries, each for a > different platform), Already handled by the AppRun for compiled languages, not needed for intepreted. > and binary type (elf binary? python? Java? > .NET?) > 2) the application icon We use application directories, so that is already defined as $APP_DIR/.DirIcon > 3) mimetypes supported, and icons for each mimetype The icons for mime types are going to be available from the icon theme. > 4) application right-click context menu Already implemented. > 5)a Application scripting API (think Win32 DDE) Never heard of it. > II. Plug-Ins/Libraries Provided > 1) shlib/dso/java libraries (per platform/type) > 2) plug-in application > 3) plug-in type/api LibDir's are just a specialized version of AppDirs. > III. Dependencies Required > 1) system dependencies (rpm? shlib name?) > 2) other bundles which are required (shlibs) > 3) types of plug-in bundles which are useful I've already started putting this information in my programs. The problem is how to make use of it. I run ROX at work on Solaris machines which has a totally different package naming scheme to Linux. > IV. Development Kits > 1) headers > 2) library binaries (per-platform target) > 3) source code for source-debugging (zip archive?) > V. Servers/Daemons > 1) restartable services You seem to have missed out the kitchen sink... -- Stephen Watson http://www.kerofin.demon.co.uk/ I woke up and I had a big idea/To buy a new soul at the start of every year I paid up and it cost me pretty dear/Here's a hymn to those that disappear |
From: David J. <je...@ch...> - 2003-08-27 19:29:59
|
On Wed, Aug 27, 2003 at 06:12:28PM +0100, Stephen Watson wrote: > > 3) mimetypes supported, and icons for each mimetype > > The icons for mime types are going to be available from the icon theme. IMO - Expecting every applciation author to update every theme when they make a document type is unrealistic. Expecting every theme author to include icons for every document type is also unrealistic. Even if BOTH of those things happened, the chance that the user has re-installed the new version of the theme which contains the mimetype is unrealistic. This mentality centralized repeated maintenance needs to end -- it does not scale. Allowing applications to supply a default filetype icon is a simple way to insure that the filer will always have an icon to display for a filetype. If the user wants to override these icons with a theme-pack, let that be his choice. > You seem to have missed out the kitchen sink... You can laugh all you want but most of this information is already stored in MacOS X app-wrappers and bundles. I'd just like to make a simpler standard for doing it on Linux instead of jamming it into custom Mach-O binary sections and directory catalogs like they do. -- David Jeske (N9LCA) + http://www.chat.net/~jeske/ + je...@ch... |
From: Guido S. <gui...@fr...> - 2003-08-27 22:30:00
|
Am 27.08.2003 21:29:28 schrieb(en) David Jeske: > On Wed, Aug 27, 2003 at 06:12:28PM +0100, Stephen Watson wrote: > > > 3) mimetypes supported, and icons for each mimetype > > > > The icons for mime types are going to be available from the icon > theme. > > IMO - Expecting every applciation author to update every theme when > they make a document type is unrealistic. Expecting every theme > author > to include icons for every document type is also unrealistic. Even if > BOTH of those things happened, the chance that the user has > re-installed the new version of the theme which contains the mimetype > is unrealistic. > > This mentality centralized repeated maintenance needs to end -- it > does not scale. > > Allowing applications to supply a default filetype icon is a simple > way to insure that the filer will always have an icon to display for > a > filetype. If the user wants to override these icons with a theme- > pack, > let that be his choice. I think David is right. Themes can only provide common "standard" filetypes. Each application has to provide the mime-resources for its document types. So far I planned to let the AppRun scripts upgrade the mime-database if necessary. I hadn't thought of adding this to AppInfo.xml. Your suggestion implies the filer (automagically) keeping the mime-stuff up to date? David, please explain how exactly this is done in MacOS X. |
From: David J. <je...@ch...> - 2003-08-27 23:01:11
|
On Thu, Aug 28, 2003 at 12:31:39AM +0200, Guido Schimmels wrote: > Each application has to provide the mime-resources for > its document types. Yes, and it is much safer if the application supply simple mime-resources for all mimetypes they load, that way it is always available. > So far I planned to let the AppRun scripts upgrade the mime-database > if necessary. I hadn't thought of adding this to AppInfo.xml. Your > suggestion implies the filer (automagically) keeping the mime-stuff > up to date? David, please explain how exactly this is done in MacOS > X. In Nextstep, each time the user logs into the desktop, the File Manager scans a set of known locations for app-wrappers. (/Apps, /LocalApps, ~/Apps, and all apps in the Doc -- although you can extend this list). It find the mimetype and icon information inside these wrappers and makes it part of the Filer's centralized Mime-Type -> Application launch database. When it comes across any filetype, it looks in it's cache of info, and displays the icon for the application which will open the document. This gives the user great feedback about what will happen when they click on it. This behavior also happens in windows, but the mechanism is different. Obviously scanning the filesystem is a compromise implementation of the goal, which is 'knowing about all application wrappers'. Using "locate" or some lower-level database-like indexing hooks would allow you to do this faster. The goal is to track all applications no matter where they are. Storing a persistant central-mime registry does not get rid of the need to do something here, because users can move around applications, and they should still work. If you don't do something, we end up with the broken-ness of the Windows registry where you can't move an app after it is installed because none of the pointers get updated. -- David Jeske (N9LCA) + http://www.chat.net/~jeske/ + je...@ch... |
From: Stephen W. <wa...@ue...> - 2003-08-28 07:46:11
|
In message <200...@mo...> David Jeske <je...@ch...> scribbled: > You can laugh all you want but most of this information is already > stored in MacOS X app-wrappers and bundles. I'd just like to make a > simpler standard for doing it on Linux instead of jamming it into > custom Mach-O binary sections and directory catalogs like they do. RISC OS also had this stuff set up by each app. The problem came when two (or more) apps tried to claim the same type. -- Stephen Watson Physicist Ultra Electronics Ltd - Signature Management Systems (UESMS) Tel: +44 (0)1543 878888 (switchboard) Fax: +44 (0)1543 878249 Email: wa...@ue... |
From: Thomas L. <ta...@ec...> - 2003-08-28 10:35:27
|
On Wed, Aug 27, 2003 at 12:29:28PM -0700, David Jeske wrote: > On Wed, Aug 27, 2003 at 06:12:28PM +0100, Stephen Watson wrote: > > > 3) mimetypes supported, and icons for each mimetype > > > > The icons for mime types are going to be available from the icon theme. > > IMO - Expecting every applciation author to update every theme when > they make a document type is unrealistic. The themes all inherit from a default theme. Applications install their icons in the default theme. -- Thomas Leonard http://rox.sourceforge.net tal00r at ecs.soton.ac.uk tal197 at users.sourceforge.net GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 |
From: Tilo R. <t.r...@vi...> - 2003-08-28 14:18:42
|
Hello, > > III. Dependencies Required > > 1) system dependencies (rpm? shlib name?) > > 2) other bundles which are required (shlibs) > > 3) types of plug-in bundles which are useful For what should handling of dependencies be good? There are many programs with optional dependencies. How do you want to decide which optional lib is desired and which not? I don't want to start an app and automatically a lot of libs is fetched/installed. I want to have control about my system. Best regards, Tilo |
From: Jaap K. <j.g...@st...> - 2003-08-27 07:54:27
|
On Tue, 26 Aug 2003 15:16:20 -0400 Shaffer, Chris wrote: : Completely agree. The current process is very tiresome. Also, having : an APPDIRPATH var would enable communication between apps. For : instance: MusicBox calls Songer to edit MP3 tags, while Songer calls : MusicBox to play MP3s. Right now, I'd have to setup an option in : Songer for the location of MusicBox (I think...). As I understand the docs (and after discussing this topic before) dirs with AppDirs in them should be simply appended to the PATH variable. No need for a new variable for this. Personally I like to keep AppDirs separated from "normal" executables on my system (in /usr/local/apps) but you can also simply throw AppDirs into /usr/local/bin or even /usr/bin - no problem there. -- ) ( Jaap Karssenberg || Pardus [Larus] : : http://pardus-larus.student.utwente.nl/~pardus ) \ / ( ",.*'*.," " Where computers are concerned _always_ be paranoid " |
From: Thomas L. <ta...@ec...> - 2003-08-27 09:54:16
|
On Tue, Aug 26, 2003 at 03:16:20PM -0400, Shaffer, Chris wrote: > > Completely agree. The current process is very tiresome. Also, having an > APPDIRPATH var would enable communication between apps. For instance: > MusicBox calls Songer to edit MP3 tags, while Songer calls MusicBox to play > MP3s. Right now, I'd have to setup an option in Songer for the location of > MusicBox (I think...). You need an option anyway, since the user might want a different application. However, you can set a good default command easily, eg: 0run "songer.sourceforge.net/apps/Songer/latest 2003-08-01" "$thefile" That will run Songer (2003-08-01 release or later), downloading it automatically if required, or running it directly from the cache if not. (actually, Songer isn't available via 0install yet, but I'm sure that can be fixed) > I was also thinking it would be nice if the README, CHANGES, etc files where > markedup, like docbook, for formatted display. Just a thought. For the changes, we should probably just use subversion's log format (once SF offer it, anyway). Might need a NEWS file to summarise changes. The AppInfo already has some of this info marked up, of course. -- Thomas Leonard http://rox.sourceforge.net tal00r at ecs.soton.ac.uk tal197 at users.sourceforge.net GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 |