Re: Toolbar Based UI
Is the bottom image is a "mini player?"
- remain
- Administrator
- Offline
Re: Toolbar Based UI
Re: Toolbar Based UI
Are you sure about discarding the search field? I don't use it a lot, but I do recognise its usefulness for many tasks.
- vspader
- Administrator
- Offline
Re: Toolbar Based UI
- remain
- Administrator
- Offline
Re: Toolbar Based UI
- vspader
- Administrator
- Offline
Re: Toolbar Based UI
The mini mode is currently just the normal view rolled up. If I had the file drawer button in one, it would be in the other.
Re: Toolbar Based UI
Looks great for a mini-player that stays always on top. I don
Re: Toolbar Based UI
- vspader
- Administrator
- Offline
Re: Toolbar Based UI
Re: Toolbar Based UI
- vspader
- Administrator
- Offline
Re: Toolbar Based UI
I'll be sticking with drawers at the moment. Drawers make things easier for plugins to interact nicely with the UI. Imagine if you had 8 plugins that each had a drawer. You can just have a bunch of drawers attached to the window and menu items to open/close them, and the user can decide which ones they want to be open.
Split views do have their use when they are meant to be there all the time, but sadly there is no good way to handle them when it comes to plugins. What if you have two plugins that both want to be a left sidepane? Do you have two sidepanes? Move one of them to the right? At that point, I might as well be making some type of grid-based system to allow plugins to put UI views wherever they want in the main window, but that's not likely to happen.
- haleakalari
- Member
- Offline
Re: Toolbar Based UI
the most recent toolbar ui cog mock-up, looks really sweet. i hope you release a build the moment you have it all compiled. nice stuff.
- vspader
- Administrator
- Offline
Re: Toolbar Based UI
Once I finally package up 0.07 and release it I'll be moving the nightlies to it.
Re: Toolbar Based UI
Another view on the sidebar problem would be to let the user choose which plugin controls the sidebar.
In other words a plugin desides what 'its' sidebar would look like. Since there can only be one sidebar, not every plugin is happy. However just as with drawers you can hide sidebars, so all plugins should be able to interact with 'their' sidebar.
I think I cannot realy make clear what I mean so I give an example:
Suppose I write a plugin that lets you have multiple file-drawers with multiple root-folders (I do not - yet - intend to do so).
Suppose furthermore that my plugin provides some button for each file-drawer.
In the drawer example I think you are able to open two different file-drawers (I vaguely remember that OSX will then give each vertical window-border a drawer). You would get some terrible interface-clutter otherwise.
Now lets see how this would have been done with a sidebar.
When no of my file-bar buttons are pressed, there would be no sidebar.
When one is pressed, a sidebar with the file tree would appear.
When another is pressed, that button pressing also means: "I hand over sidebar control to this instance of the plugin." The contents of the sidebar now seem to change into the newly selected file-tree.
You can also think of this as the 'old' sidebar hiding and the new one taking its place in the interface.
I can see no real down-side on such alternative approach (I don't think its a real advantage to keep two file-views open). I do see some improvements, mainly concerning decent interface design.
A problem would be how to implement plugins that influence the sidebar (insted of having its own). This problem is similar however to interacting with drawers.
I might be wrong about quite some things I said because OSX interface-programming is not one of my specialties. I do know some things however about what a good (OSX or, for that matter, any operating system) interface should look like.
Re: Toolbar Based UI
Wow, I didn't know it had become this long 
