Computing posts

The list view of the finder is good for looking at information about files. I use the column view for browsing, as it shows the hierarchy better and is faster to use, but for information I list. I find myself frequently changing the view settings of a window in list view depending on the information I am interested in. I might want to calculate folder sizes and sort by folder size to see where all my disk space is used. I might want to look at the comments field to see what I’ve said about the files. I don’t always want the processing power usage to calculate folder sizes or the screen real estate of all these columns viewable at once. It’s a pain to set these list views up each time. The dsStore files will save the settings for a single folder, but in general I’d want these settings the same for all folders. All folders contain files and folders, and I have similar information to view about all of them.

I think one should be able to save a view setup that can be applied to any window. Setting a window to the view should be simple, such as with a submenu off the list view menu item, a small menu icon somewhere on the window, and/or a contextual menu. They’d simply have user designated names preferably describing their function. This all would become much more relevant if the list view could have columns with other metadata, such as author, status, or owner.

The OS would have a standard system for developers to implement an auto-update feature for their 3rd party apps, making it easy for them, consistant, and simple to ensure all apps are up to date for the user.

Each installed app would register its name, .app path, current version, url for update information, etc. For all apps released prior to this OS and library feature, much of this info would have to be added manually by the user. New apps could possibly add themselves on first launch, asking the registry on launch if they are registered. This would not allow currently existing software to register, so these apps would have to be registered by some other means. Probably a better solution that would support both new and old apps, as well as not need a specific call to be added in the apps code, would be to have the registry check for the name of the app every time an app is launched. If it is not in the database, it could ask the application for the information. Current apps wouldn’t provide this, so it would have to bring up a dialog alert window in which the user would enter as much of it as known. It could be updated by the user later. Since some people download apps just to try them, then delete them, these apps should be removed from the database. This could be implemented to be done automatically. On each update check, if no .app is at the path specified, then the app was probably deleted and can be removed from the registry. Also, the user could specify an interval after which dormant apps could be removed from the list, something like a month or so. If either of these remove apps that are still desired by the user, they will be re-added to the registry on next launch, and will then be checked on next check anyway.

The developer would use a standard method, perhaps one of several, to post the current version and the files for download on their website. The url would be provided by the app, as stated above. The information at the url would have to be standardized so that the updater could parse it to get the information needed. It might contain just the current version in a tab delimited text file, listing version number, url to file parts or perhaps script to get them, update history (in case the user wants to review the update before doing it), etc. It might also be a list of all versions with this information, each version seperated by a new line appended to the file. Some developers would add the new line to a text file by hand, while others could have a script update it, or a script serve it. The file parts would have to be in a standard format as well, so that the updater app could handle them easily. It could be simply a .pkg, with all modified files stored in their destination paths inside.

The funcionality would probably be added to the software update application already used for the OS vendors software. The third party stuff would be kept somewhat seperate, to ensure things like security updates to the OS were given greater precedence and what not. The user would have seperate preferences to set for handling 3rd party apps, including whether to maintain a database at all, whether to update automatically or ask permission first, seperate update interval (could be ‘same as system updates’ though). The user would be able to view a table of all registered apps with information on them such as current version, if installed version is current, and an editable list of the app name, path, and update url. Clicking on each line item would provide additional information provided from the server, such as a revision history. All information would be stored in a database to save on disk space and be faster than a collection of files for each app.

in finder: create new file by hitting command-n. type in name with extension, opens editor of that extension set in preferences with new file with that name. also enter in keywords describing new files contents. based on setup, system will know “where” to put file: example – create a new file, type in keywords Lizard Bobson; system knows file is for Bobson account in work ‘folder’.

for every file extension, there is a systemwide set default editor and default viewer. If file opened for viewing, opened in view mode, in which viewing tools are available, editing tools generally disabled. If opened for editing, editing tools are made available and viewing tools are hidden/made less available.

Example: text editor viewing mode – up down left right arrows move view (up, down, page up, page down). character keystrokes do find for typed characters.

text editing mode – up down left right move input/editing cursor. keystrokes type text.

database/image app that allows one to drag images into it, have it automatically file as regular images (with tags as extra data in file) in file system based on user set fields. defaul fields simply image and image name and image type(jpeg, etc.), but can add any fields, any number of them, and create personal organization system.set what organization system is used for filing files. has folder style interface type deal, allowing images to be grouped togethor in folders, then subfolders, etc., but the folders can be created on the fly based on criteria. related images of the same thing can be grouped togethor.

to user, related information given togethor, but is really stored in most efficient means possible, best balance of factors such as access time (search, sort, etc), modification time (change data and append), new item time, storage space, number of accesses to storage media.

all instances of data in any format should be able to be looked at from ‘finder’ level and relatable

redundant and inconsistant data can be eliminated using spare cpu time during idle time

relatable in hierarchial type view, getting more specifically related as go deeper in hierarchy, very generally related near top.

search time reduced using hierarchy by eliminating items in unrelated branches: searching for a friend named Amy would search through a friends subdir before/instead of business partner dir.

file browser (like finder) has built-in/plug-in capabilities to read and work with basic document formats. Images would appear as thumbnails, with preferences, that can be easily viewed at full size in a self controlled slide show type thing by folder. Movies would be viewable full size in the browser as well. audio files would be listenable toable, including being able to leave them play while doing other browsing. Text files would be completely viewable, possible editable. PDF’s would be viewable. Other formats would have plugins available from the maker of the app that produces them.

Allows viewing of files while still maintaining a file-browser like appearance and functionality at all times.

Controls would be provide when necessary from an easily accessible location, such as at the top of the window or in a floating window that disappears with no mouse movement. Proper controls would appear for the proper file-type.

All files would be able to be given tags, including user created tags, that are simply data about the file for informative and searching use. For example mp3 tags would be editable from the browser, as well as JPEG EXIF data.

Files could be organized in multiple directory setups without the use of aliases or anything, just an additional centrally located database directory file. Each media type would or could be given its own database so that one could look at all images at once in the image database while still have those images grouped with related other media in the regular directory system. This could perhaps be automated, having all images automatically put into the image database, which would then be able to be queried by its tags to show categories or specific dates or what-have-you.

All controls would be easily navigable and accessible with the keyboard as well as with the mouse, allowing speed and flexibility. This would include at least the major preference settings.

The browser would be very customizable to fit most peoples needs and tastes.

The browser would be designed to be slim and fast, taking up as little disk space, memory, and processor power as possible.

It would also be very plug-inable, so that users who don’t want certain features could easily remove them to save resources. Plug-ins would be able to be developed by third parties, so that alternatives for each file-type or function could be provided. If someone doesn’t like, say, the regular image browser, they could remove it and install a third party one easily that would integrate with the browser.

/****** the following is sort of a reworded, newer, and a bit different version of the above *****/

The independent application that handles specific document types is generally no longer needed, in my opinion. All files can be handled from within a single application, allowing the difference in file types to not affect the similarity in content (one should be able to view both text files and images relating to a given subject without having to change applications).

Plug-ins would provide the capabilities for multiple file-types: a plugin would essentially be the application for viewing and editing a given file-type, but would be opened within the ‘finder’ instead of separately. Each plugin would be loaded when opened, and taken back out of memory when no longer needed, possibly a specified time after the last opening of that doc type, with the amount of time weighted based upon the frequency of opening that given doc type.

Each document would be stored in the database like an object of an inherited class in an object oriented programming language. Every file would have certain attributes, such as disk location, creation and modification dates, name, user, group, as well as functions, such as rename, modifyContent, view. These would be part of the ‘file’ class. General categories of files may have more attributes and functions than that: ex ‘media’ category may contain author, date media was created. The ‘media’ category would contain some specific file types, or perhaps more specific of categories, such as pictures, movies, music. Each specific file type, what would be the instances created in the database, would have the most specific attributes and functions. A photo might have attributes size, color profile, shutter speed, and functions resize, contrast. Each specific file type, like in any OO inherited object, would have all attributes and functions of the more general categories of file type in addition to its own.

With standard setting, the document by default is opened in viewing mode. In this mode, no changes can be made to the file. All commands are designed to aid in the viewing of the file. A certain command would enter editing mode (likewise in editing mode, a certain command would bring you to view mode). In editing mode, all commands are set-up for editing. As an example, for a text document, typing ‘apple’ might put ‘apple where the cursor is currently when editing, but live-search for that text when viewing (another entry has more on this).

If anyone is interested in helping me build such a thing, contact me at public@tobymackenzie.com. I have only a little programming experience and have done almost nothing towards creating this project. I plan to start by making an application for Mac OS X that is like any other application and doesn’t affect the finder or its database, instead having an additional database that is its own and working through/with the systems database.

related thought

folders are not really files. they are used only for organization, so would not exist if there was no organization. files containing your content are a different kind of file from the organizing folders.