UI feel
From SkyOS
The UI should feel more lively.
Contents |
Viewer redesign
A theoretical Viewer and desktop panel mockup, with emphasis on quick file location in the Viewer, and a dock-style panel for the desktop.
Viewer redesign 2
Relative file/directory size
Maybe viewer could display the file/directory size relatively (in addition to standard absolute size) to the size of current directory. That way you would always know where your disk space has gone and you wouldn't need a separate tool. For example, there's a tool for windows (and other platforms) that does this here, but it's a bit clumsy as it's a separate application.
Robert
Possible, but with a few problems. Computing the size of folders takes time, for top level folders and huge disks it may take multiple minutes. So, the primary question is, when should this computation be made?
Alex
Compute the size upon file creation and modification, and store it as an SQLite entry. SQL's -add()- sum() definitely won't take multiple minutes.
Robert
Well, problem is you have to store this size in multiple localations. If you modify the file in /a/b/c/d/e/f/g/h you have to update 8 nodes. Every update required to lock each of this 8 folders, meaning writing 8 blocks to disk, filling the journal with 8 transactions. Folders may be locked by other applications which means you have to wait. Additionally, modifing just a tiny file will create heavy harddisk usage, as folders may be spread over the entire disk. And now just think about a copy operation with lets say the mozilla source with thousend of files. Keeping track of folder size will generate a lot more disk operations, definitely making the entire copy process way slower. Is the possibility to quickly see how much space is used by a folder worth a slower system? Or is it better to let the user have to wait a few moments when he actually request the folder size? (which is really a rather rare operation imho).
Alex
I didn't mean on a per-folder basis, I meant per-file.
Every file has a unique identifier, doesn't it? Let's say I create a 1kb file "test.txt" whose unique id is 106295. Upon file creation, the following query would be performed:
INSERT INTO files_size (id, size) VALUES (106295, 1024)
Now let's say I duplicate the file twice (thus inserting two entries into the files_size table), and I want to know the total size of all 3. I would issue the following query:
SELECT SUM(size) FROM files_size WHERE id IN (106295, 106296, 106297)
All that is needed from the filesystem is a comma-sepparated-list of the file IDs that need to be summed, whether that be all the files in one folder or all the files in several folders, and SQLite will *very quickly* return a sum.
It's a known benefit to having an sql-driven filesystem which you have not implemented in the SkyFS/SQLite thing you have going currently.
Robert
Sorry, but I don't get it. SkyFS is definitely faster then SQL, as the file size in SkyFS (in opposite to BFS) is fully indexed already. Making a SQL Lite database around out has no sense at all, because not only it completely duplicates the data but also generates disk usage. And don't forget, normally making a SQL query is very fast, but not if you have to query a database (which means disk access) while you are in the middle of iterating a directory (which generates disk access too, of course).
Anyway, getting the file size is not the problem at all, indeed, as soon as you iterate the directory you automatically get its inode id, the file size, and the modification time. (which is also a difference to BFS). And there is no need for a comma separated list because SkyFS itself uses a very, very fast B+Tree to get such values very fast.
The actual problem is, that you have to get this filesize for thousands of files if you want to know the size of lets say /boot or /boot/programs. It doesn't matter where the file size is stored (as long as it is in the filesystem), what really matters is how to get the file size of these thousand of files very quickly. The only really plausible way would be to store the directory size (size of all files inside this directory and in all sub directory) right into the directory node itself. This is the only way you can quickly get the size.
Random guy
(Reformatted my comment to obey conventions)
(This was for Robert's first question)
Well, I don't know anything about branchFS and only a little bit about FSs in general, so I can't comment on this too much, but here are some thoughts. Of course this should be done incrementally when a file is copied/moved/size changes (file system is always empty at first, so the info would be building organically). Parent directories (directories should know their size) probably should only be updated when whole copy/move operation (multiple files) has finished. If application constantly modifies files then it might be wise to wait until no file handles are open.
Maybe the updating could be done incrementally and lazily using some sort of time/size/io-load threshold? Size info wouldn't be accurate, but maybe a good approximation would be enough (relative size is kind of guiding value anyway). But even incrementally this might be fairly heavy operation, if you have a change in deeply nested file as every directory, between root and file, might have hundreds of files.
Or a service/thread updating this stuff on the background. How does the searching/indexing stuff work? Any similarities/leverage?
Mouse
to make it easier to recognize where the mouse is on the screen, there is a feature from Windows, where you click ctrl and it shows something like a bubble around it for a second. in my opinion, the way they chose to do it was far from perfect, but the idea is good. I suggest that it has a certain pulse (configurable), so every few seconds, the mouse's looks changes a bit. right now, the skyos mouse is a sort of black triangle, with a little white border that envelopes it. this white border can change color for half a second. it would be non-obstrusive in this way, but still catches the eye's attention.
a picture's worth a thousand words, this one worths about 200, but it might make clear what I mean.
my graphics skills are pretty low, just imagine this is a flash effect going through the cursor...
or 
Buttons and Other Widgets
- (all) buttons should be colorized to a default color when the mouse is over them.
- After a button is clicked, the user should be certain that it was indeed clicked.
we need a strong visual indication for that.
I suggest that a button will get a thick half-dotted(or other style) colored border around it.
the active widget can also have something like a small border, or colorized in an pre-agreed color. (so the user knows this color marks the focused widget)
Mockup example: 
Would it be possible, using composing, to have a colored shadow fade in, and then out behind the text box, for example, to indicate the active widget?
That would be nice, but perhaps annoying. (if it repeats endlessly) what about if the green color would cover the text input itself as well, only with alpha values? (semi-transparent) would that be a good indication? the widget can even be the opening triangle or a file menu. then you can know from first look what the user did last, and where you're at. and there is no need to start searching around the screen, like in windows (for example, press alt in your browser, and if u didn't notice the file menu is focused, your key presses will act not as you expect)
List View
List View shows the list of items. but when one of the fields is shortened, and the item is 'longitemname' it only shows "longitemna..."
my suggestion is to show instead 'longi..mname' when shortening. meaning to crop it from the middle and not from the end, because I think this way the item names are easier to recognize and possibly have more meaning.
I'll try finding a better image (or a little mockup) to illustrate this, but for now, there is one from an old beos release (R3?) here: look at the subject column
Performance, responsiveness, and disk caching
I haven't used SkyOS myself, so I have no idea what the existing GUI performance is like. But even if it's currently snappy, please keep in mind in future development that responsiveness is the single most important aspect of any GUI. Don't make the same mistakes that Windows and KDE/GNOME have made in this area, sacrificing responsiveness for eye candy.
When the user hovers over something, or clicks something, they should always get an immediate response, rather than having to wait around for something (menu contents, icons, etc) to load from disk before the resultant change can be drawn on-screen.
Most likely this means implementing some sort of generic, efficient, proactive, purpose-specific disk-caching layer, so that things like menu contents can always be held in memory for speedy look-up.
comment: as for that, I trust robert, he likes efficient code
