NavigationCy/VOS
Wiki Users |
User /
File system browsing providersAuthor: Telcontar On most graphical interfaces it is necessary to provide a means to browse the contents of mounted volumes. As with all things in Cy/VOS, it is also important to permit the use to have control over whose implemenation of this he or she wishes to use. But this is where it becomes a little complicated. It is not simply a case of switching file system browser, as visual file system access is very pervasive on a modern system, as it shows up:
The above list is not exhaustive. It also cannot be served by a single codebase, and suggests that there is a need for at least two pluggable modules for the graphical interface, detailed below: File system dialog box moduleThis module is responsible for generating extensible Open and Save dialog boxes, or any other type of file selector such as RISC OS-style drag-and-drop Save windows. It will normally rely on the file system browser module to render the file system view -- typically an embedded low-level window context -- although this is not required. The required API will include full customisation of the window including position, size, start directory, hint text, command verbs ("Open", "Choose", "Create" etc) and embedding of a control pane (a low-level window context) for open and save options. Replacement of this module permits a choice of different Open and Save dialog box styles, such as Macintosh-like, Windows-like or EIKON-like. Typically it will be necessary to replace the file system browser module at the same time to achieve the desired effect, although it will be possible to bind this module to a different instance of the browser module as other software uses. File system browser moduleThe file system browser module is responsible for generating visual views of any file system, to be used by software on the system. This module talks not to the file system but any file system provider process via a standard protocol. This can be the file server or any other process. For example, an FTP client can wrap up the remote file system and be the file system provider to a browser pane, giving you system-native rendering of the remote view. The file system browser provider module would service any process that needs a folder view. This would include the desktop, local system browser software and batch image processing tools that want to show all files in a folder. To this end, certain customisations are needed. State control: A set of flags will control what operations are permissible on the given files, for example to mark a folder non-writable (e.g. CD-ROM volumes, read-only folders) or non-readable (e.g. FTP volumes where the file system provider doesn't implement transparent background fetch). Other discrepancies will be allowed via optional fields in the protocol messages, and via return codes. Context menu provider: A context menu handle can be requested that contains a standard context menu for the given file selection (delete, move, open, edit etc) for systems that desire this. Displaying and handling context menus become the client's responsibility, allowing for full client control. This allows the client to overrule menu items, and add and remove items before rendering the menu on screen. For non-custom menu items – those provided by the file system browser provider, whose menu item owner thread ID differs from the client thread ID – the menu item command can be forwarded back to the thread that attached the item, e.g. a global context menu provider or the file system browser module thread. Status bar provider: A status bar window context handle can be provided to draw a standardised filing status bar, e.g. summary of selected files. The client code can add new panes to this as desired, and because it takes over ownership of the window, it intercepts messages and can control the window. All remaining messages should be forwarded to the creating thread. Toolbar provider: Like the status bar, a standard filing toolbar or toolbar set can be created, and a window handle returned. The client thread now owns this window and should forward unhandled messages back to the creating thread. Address bar provider: This provider returns a window context handle to a pane that provides an address bar for the folder panel, following the same behaviour as the toolbar and status bar. This can be integrated anywhere into the client's task window. File manipulation responsibilityBecause the file system browser provider builds the filing context menu (itself calling on any global context menu providers), all default items on the context menu have the provider module as the owning thread, making it by default responsible for obeying the menu items. The client process will by default obey any menu item created by its own thread and any threats it speaks on behalf of, and re-dispatches any items it did not create or does not want to handle. Should the module be responsible for providing filing commands? At a guess, the file system provider itself should service these commands, not the browser module. For example, this way you can display a standardised progress window. For menu commands for private file system providers, the menu commands become meaningless anyway as the browser module cannot perform filing tasks itself. To delete a local file, the file server can handle this. To delete an FTP file, only the file system provider will have any knowledge of the FTP One could argue that the file system provider itself should create the entire set of menu items as only it knows about the peculiarities of the file system being shown and what it can do. For example, the file system mounted under the virtual file server may have features unknown to the browser module. The question is how closely tied, yet how independent the file system and browser module should be. It may be required that changing the file system requires a new browser module to cope with the new feature set. In a similar vein, where do regular menu bar commands in a local system browser come from? They should match the context menu! |