From: Tony H. <h...@re...> - 2009-08-11 21:04:05
|
I had an idea. How about adding a plugin/extension system to ROX? Then people who would like a GIO extension can have one, and those that don't want one won't have to put up with the bloat or whatever. There could also be a tree view extension. Etc etc. I don't have any thoughts to offer on how to implement it, but I thought it would be worth throwing the idea into the mix. -- TH * http://www.realh.co.uk |
From: Alex A. <cir...@gm...> - 2009-08-12 13:16:41
|
Any plug-in system requires hooks. By their nature, some plugins could be gui-centric, some could provide for other IPC protocols, and other such things. The GIO branch of ROX changes the fundamental nature of the program, so I don't think it could be implemented as a plugin. On Tue, Aug 11, 2009 at 4:03 PM, Tony Houghton <h...@re...> wrote: > I had an idea. How about adding a plugin/extension system to ROX? Then > people who would like a GIO extension can have one, and those that > don't want one won't have to put up with the bloat or whatever. There > could also be a tree view extension. Etc etc. I don't have any thoughts > to offer on how to implement it, but I thought it would be worth > throwing the idea into the mix. > > -- > TH * http://www.realh.co.uk > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > rox-devel mailing list > rox...@li... > https://lists.sourceforge.net/lists/listinfo/rox-devel > |
From: Samuel Dionne-R. <sa...@di...> - 2009-08-12 16:40:17
|
One night, I had a dream, a wonderful dream about the filer I would want to use until death. Such a filer would be a shell, a mighty shell that acts as the plugins wish. Actually, plugins would provide services. Services would have to be standardised for the best interaction between them, but that's not that hard if they all starts in the community. The way those plugins would work is simple. The application is there for one principal purpose, load the needed plugins. There would be base plugins either hardcoded or shipped alongside the binary, obviously, but the facilities would be there to simply override them or hook into them. The first class of plugins would be file view plugins. The fallback plugin would be akin to a graphical `ls`; a simple list of files, vertical, the least amount of things that could go wrong there. Then, the default plugin could be (a clone or) the current view of ROX-Filer. There could be tree view implemented or any kind of view. (Mac os 9 finder-type spatial view could be easily implemented that way. The view would actually control the window's size too.) Those views would call plugins for some utility work, like finding mime-types or icons about files. What would be important (in my view) if to see the most separation of contexts and uses, so that if a common services system is born, those plugins/services could be useable in any application that would implement it. The filer would also call plugins to know what to show in the view. The base or fallback service would simply search into the file system. No frills. Then, the default could be GIO or any other system. Then there would be the actual add-ons. Those are maybe less standardised services that allows the user to have a wonderful experience in the filer. An example of an add-on would be the Address Book Service. It would work in that fashion: When asked to be loaded (through a .dirInfo file or any other way) It looks into the directory. For every vcards it finds, it parses them. It asks to load a grid view, If it has one It changes columns to Name, Surname, Phone number [...] It then asks for editable columns If the gridview allows it Make them editable and hook "onChange" or something like it to save the vcard. Else it would Show the name of the contact instead of the filename And show other infos on a second info line (if available). In any way, the plugin would be hooked into the file opening action (well, it could also be the default for vcard files) and shows a window with the informations (a bit like the ROX software I can't remember the name of). That's it the Address Book Service. Well, I would make the default action for vcard files an "import" utility to actually import the vcard in the configured folder. The plugin might also not be loaded through a .dirInfo, but as a configuration option of either the plugin or the filer (well, the filer could then write a .dirInfo). A .dirInfo file could look like: <directory><!-- descriptions would be choosed as per the localization settings of the user --> <description lang="en"><!-- English description, can be shown when hovering --> This directory holds contact cards. </description> <description lang="fr"><!-- french description, can be shown when hovering --> Ce dossier stocke des cartes de visite de contacts. </description> <plugins><!-- loads the address book service from someone at example.com --> <plugin uri="com.example.someone.addressbook" /> </plugins> <view type="grid"> <preferred><!-- Forces this type of gridview --> <plugin uri="com.example.filer.gridview" /><!-- loads the gridview from filer at example.com --> </preferred> </view> </directory> There could be many more entries into it. The interesting part would be the <preferred> tag, it would ask for this type of gridview to be used. The plugin then should use it (hoping it satisfies all its needs). In another use case, a plugin that needs a certain gridview to actually works (service dependency, let's say it allows for images to be shown in cells) would not use the preferred one if it would not work. A good citizen plugin would not force a service when a preferred one is chosen if it does not hampers the actual usefulness of the plugin. Another use case of plugins would be for music folders. When at the base of a music repository (either documented into a global DirInfo file or a local .dirInfo file), the plugin could show the music and its tags in a gridview (with folders being albums, if a diricon or other file judged suitable is found, the icon would be the album). This plugin could actually add to the filer's window; it would add a control bar (play/pause/seek) and a playlist to the window (in a switchable widget). I haven't thought about how to react when the user exits the music repository (exit the plugin, keep it but continue browsing in normal mode with the new bar and sidebar?) I will make mockups when the time will come on how this could all look. I don't know if the idea is suitable for ROX-Filer, as it could make it unmanageable, but I'm putting my ideas here, as this may actually spark some discussion about it and maybe, I would actually be able to live my desktop experience just as in my dream. Anyway, this message does only scrape some problems, there sure are many things that were not even thought that would be needed in such a system. On Wed, 12 Aug 2009 08:16:29 -0500, Alex Austin wrote : > Any plug-in system requires hooks. By their nature, some plugins could > be gui-centric, some could provide for other IPC protocols, and other > such things. The GIO branch of ROX changes the fundamental nature of the > program, so I don't think it could be implemented as a plugin. > > On Tue, Aug 11, 2009 at 4:03 PM, Tony Houghton <h...@re...> wrote: > >> I had an idea. How about adding a plugin/extension system to ROX? Then >> people who would like a GIO extension can have one, and those that >> don't want one won't have to put up with the bloat or whatever. There >> could also be a tree view extension. Etc etc. I don't have any thoughts >> to offer on how to implement it, but I thought it would be worth >> throwing the idea into the mix. >> >> -- >> TH * http://www.realh.co.uk >> >> >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >> 30-Day trial. Simplify your report design, integration and deployment - >> and focus on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ rox-devel mailing list >> rox...@li... >> https://lists.sourceforge.net/lists/listinfo/rox-devel >> -- Samuel Dionne-Riel |