benn/lumiera_
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Move in the existing documentation outline from the Website-repository

Browse source
This commit is contained in:
Fischlurch 2010-11-14 23:19:07 +01:00
parent 7bc7ae09fc
commit 3bd7c610fc
24 changed files with 800 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

7
doc/design/application/config.txt Normal file
View file

@ -0,0 +1,7 @@
Lumiera Design: Application and Session Configuration
=====================================================
[icon="warning.png"]
WARNING: Website under construction

10
doc/design/application/index.txt Normal file
View file

@ -0,0 +1,10 @@
Design Documents: Application Framework
=======================================
* link:config.html[Configuration]
* link:plugin_loader.html[Plugin Loader]
* Application startup- and shutdown
[icon="warning.png"]
WARNING: Website under construction

7
doc/design/application/plugin_loader.txt Normal file
View file

@ -0,0 +1,7 @@
Lumiera Design: Plugin system
=============================
[icon="warning.png"]
WARNING: Website under construction

7
doc/design/backend/index.txt Normal file
View file

@ -0,0 +1,7 @@
Design Documents: Backend
=========================
[icon="warning.png"]
WARNING: Website under construction

7
doc/design/builddrone/index.txt Normal file
View file

@ -0,0 +1,7 @@
Lumiera Builddrone
==================
[icon="warning.png"]
WARNING: Website under construction

7
doc/design/engine/index.txt Normal file
View file

@ -0,0 +1,7 @@
Design Documents: Renderengine
==============================
[icon="warning.png"]
WARNING: Website under construction

27
doc/design/gui/GuiBrainstorming/MenuAndShortcuts.txt Normal file
View file

@ -0,0 +1,27 @@
Menu and Shortcuts
==================
:Author: Simeon Völkel
:Date: 2008-05-14
link:Lumiera/GuiBrainstorming/MenuAndShortcuts[] should explain most heavily discussed GUI features being related to Lumiera's GUI.
3x3 Menus, Version 1
--------------------
* popping up on click
* look like 1-9 on a numpad
* mouse is located at 5
* 1-46-9 are the items: click here to access them
* if a item is the entry to a second menu the mouse will be at 5 of the new menu
* 5 is cancel
3x3 Menus, Version 2
--------------------
* as Version 1
* popping up as well on pressing 0 on keyboard
* use numpad to navigate through the menus
* all functions can be accessed using this menu

13
doc/design/gui/GuiBrainstorming/Proposal.AkhiL.txt Normal file
View file

@ -0,0 +1,13 @@
GUI Brainstorming Proposal
==========================
:Author: AkhiL
:Date: 2008-30-03
Wiring nodes within the timeline
--------------------------------
In fall 2007, rather then using an external node editor, AkhiL proposed to do wiring
of effect nodes directly within the timeline. He did the following Mockup:
image::AkhiL.proposal.png[]

28
doc/design/gui/GuiBrainstorming/Proposal.RichardSpindler.txt Normal file
View file

@ -0,0 +1,28 @@
GUI Brainstorming Proposal
==========================
:Author: Richard Spindler
:Date: 2008-30-03
Node Graph proposal
-------------------
on 2/6/2008 Richard Spindler wrote:
I've made a little Picture about how I think the User Interface of a
yet to be named Video Editor could be presented. There is no central
notion of the camera/projector Model, which I think could be added
anywhere in the Graphs as a Node with an unlimited Number of inputs.
Automations are not yet part of the Mockup, but could be added.
Cross Bus connections would likely not be represented by Arrows in a
real UI, but rather the Bus would be adressed by Name.
The dotted Lines mean that one element expands to a different View,
for example in a new Window.
The same goes for the rectangles with the slashed outline, they
represent another View, and the connection from the timeline to the
compositing nodes will be by Name, and not by arrows. Default Names
would be "Video Track #1", etc.
image::RichardSpindler.proposal.png[]

104
doc/design/gui/GuiBrainstorming/Workspaces.txt Normal file
View file

@ -0,0 +1,104 @@
Workspaces
==========
:Author: JoelHoldsworth, ct, Ichthyostega
2 Conflicting Approaches to Workspace Management
------------------------------------------------
After some debate on IRC last night, it emerged that there are some differing ideas about how projects, sessions, panels and main-windows should work together, and it seems that there are different paradigms for workspaces.
I have my personal preferences, but my thinking is definitely incomplete - I don't think any of us have yet groked all the ramifications of the different ideas, so I'm hoping this will help us elucidate the differences.
Paradigm 1: Super-IDE Style
~~~~~~~~~~~~~~~~~~~~~~~~~~~
This approach is a sort-of free for all. Each window is a bucket for N~d~ docking panels, and any docking panel can be attached to any window. This total state of windows and panels would be a workspace made of N~p~ projects. Any number of windows can be created, and windows can contain as many or as few panels as you like, and panels can be dragged between windows.
The end result would be like getting multiple Xnests of Ion, and bear some similarity to the way some IDEs such as Eclipse, and Visual Studio work, but with a greater emphasis on multiple parent windows.
This would make sense if the normal workflow would involves many projects, and a lot of inter-project work.
There are some plusses:
* It's very orthogonal, and it lets the user configure their window layout to be exactly what they want. Lots of flexibility.
But, this idea has some difficulties:
* How does the user open different sequences and elements of the many projects? In IDEs, the answer is to have a project browser which usually remains open all the time. The user then double clicks on source files to open them. This takes up a lot of screen real estate, but in IDEs this doesn't matter; I think in lumiera we don't want to spend space on this. The alternative would be to put the sequence list into a menu somewhere, but this would quickly become cumbersome even for medium complexity projects.
* Every single panel will have to explicitly state which project it's connected to. It might be possible that this text could double as a drop-down selector, but even so that's pretty cumbersome for something that would otherwise be implicit.
* Closing one of the projects would cause many panels to disappear which would leave a nasty mess behind in UI. The user would have to waste time clearing it up.
* From a usability perspective it's not necessarily desirable to allow various mix-n-match UI because it allows the user to enter a create confusing mixture, where different parts of different project are shown in different places. Even for simple projects the user may end up having to spend a lot of time tending to the window layout - tweaking it. I'd prefer the user not to have to think about that.
* This may not be very helpful for viewing multiple projects which are _not_ inter-connected. It would be very easy for projects which are isolated to end up being mixed panel-wise, and acquiring weird dependencies on each other.
Paradigm 2: SDI Style
~~~~~~~~~~~~~~~~~~~~~
In this approach, every project gets it's own main window. It would be possible to create multiple main windows connected to a single project with View>New Window, but still no more than one project per window. This style is basically Single Document Interface (SDI), as seen in many applications: e.g. Inkscape.
I believe this makes sense if we think that projects are first class citizens. So a given feature film really would just be one project. In this case you'd really never want to look at more than one project at once. Complex projects would have have many sequences, so we'd need to have a good way to make sure the user doesn't get swamped.
Doing inter-project work would require the user to spend time arranging windows, but this paradigm assumes you very rarely want to. The payoff of it is simplicity - the panels of projects are kept together in one place.
joelholdsworths's Conclusion
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I favour this paradigm #2. The freedom from paradigm #1 enables some extra possibilities for window arrangement, but at the cost of a lot of extra complexity, and at the cost of allowing some pretty ugly configurations that both the programmer and the user would rather not have to think about. It seems to me that if you're doing a lot of inter-project work, you can drag windows into a formation - that's pretty normal for this rare case.
I wonder what the proffessional video editors think. Please leave comments.
Comments
--------
Basically I agree/you convinced me with #2, Initially I was more after #1 but you pointed out some problems. But still
I would like to make some execptions from the rule, because I see viable use-cases.
As you suggest, a window is related to a project, I would like to have a \'import' feature there where one can
include/dock a component from another project. This then becomes a \'real' import which means the first project notes
"display the timeline of project 2 in my window". This gives clean semantics for working with projects and windows and
gives a clean abstraction of an \'import' we can even store in the session down. This imported components are then not
part of project 2's session. Usecases are side by side comparsion and work on 2 or more pojects, arrange timelines for
easier drag and drop operations, make this config a project setting (you dont have to open all dependent projects and
arrange a multitude of windows). Prolly the same (to a lesser extent) counts for importing the \'resources' of another
project (hey have you thought about some collection of boilerplace footage, logos, intro sequence etc as clips stored
in a site-wide project withot timeline, but then you have all your production companies \'default' resources at
hand?). Next sharing viewers in one window, possible fullscreen on a 2nd monitor then you can have a 2x2 tiling or
such for all kinds of previews, even external projects. +
-- link:ct[] [[DateTime(2009-01-29T03:03:22Z)]]
- Agreed. A nice "include" feature, so one project could refer to another would cover most of what you could
imagine to do with multiple projects +
-- link:Ichthyostega[] [[DateTime(2009-01-29T03:36:08Z)]]
Ah just to have it noted, I told that often on irc: Dock windows shall not be a second class citizen. You mentioned
that you want one able to open more windows for a project, undocking a pane shall just do that too. All windows can
then be treated equal, can have a (toggleable) menu, toolbar and statusbar etc. Especially when working with big
and/or multiple monitors it becomes really ugly when you have to move the mouse over your whole desktop setup just to
reach a menu entry. (same for looking around to check information on the status bar, which shall represent the status
of the window which has focus anyways). And last but not least, the current GDL docks implement thir own drag handles,
moving windows around has a big performance problem with some window managers, moving windows shall be the job of the
window manager and not the job of the application, the only thing the application may do is hinting positions to the
WM. These second class dock windows are neither ICCCM conforming (http://tronche.com/gui/x/icccm/[]) nor do they add any
extra user experience, instead the user has to learn a new kind of window class. +
-- link:ct[] [[DateTime(2009-01-29T03:15:03Z)]]
To chime in with the commenting... this comparison rather strengthened my preference for paradigm #2 _for our situation here._
But I think we should try to exploit some of the extended possibilities which you usually rather find in those Super-IDE type applications:
perspectives, freely configurable pannels, multiple top level windows, something like palettes or tiling.
When you compare the situation when working on software with the situation when working on a feature film, it seems to me that the situation
don't match up. The rationale of having multiple software projects opened is (a) "lets see how I solved the same problem 2 months ago there..."
and (b) working on a larger software compound, comprised of multiple parts, which may even be deployed distributed.
I think none of these applies to film editing. (Maybe the situation is a bit different for putting together a TV show)
According to my own editing experiences, both film and sound, the "bringing in media into the project"-phase makes only a very small percentage of the overall time spent with a given project. Initially, after bringing in the raw footage, for me there is a long lasting phase where I just explore the material, i.e. I am viewing (or listening) to the footage and maybe try out some possible cuts and combinations in a throwaway fashion, just to get a feeling about the material. Then I build up the backbone of the cut rather quickly (and this is the only time where I could imagine having muliple projects opened at the same time). What follows is a long fine tuning and augmenting phase. So, for me, setting things up so I can work comfortably in a rather focussed and limited part of the application couold be more important then exploring multiple projects at the same time. +
-- link:Ichthyostega[] [[DateTime(2009-01-29T03:31:54Z)]]
Another important thing: Do not automatically pop up windows. Creating a new window (even dialog boxes) must always be a consequence an user action. Even error conditions shall _NOT_ pop up an window (with one exception, that is fatal errors which will block the application until resolved). Otherwise the \'error' window shall be some log (perhaps with filtering capabilities) similar to cinelerra, but when an error happens some big red ERROR might blink in the status bar instead and only clicking on that will open the error log. +
-- link:ct[] [[DateTime(2009-02-01T09:40:08Z)]]

47
doc/design/gui/GuiBrainstorming/scrolling.txt Normal file
View file

@ -0,0 +1,47 @@
Scrolling
=========
:Date: 2008-05-07
This is a draft describing how scrolling with the mouse wheel should work in Lumiera to provide the best possible comfort for long editing sessions.
Scrolling without modifiers
---------------------------
Scrolling without modifiers should jump directly from the current frame to the next/previous frame.
Shift Modifiers
---------------
The Shift modifier should be used to toggle how scrolling with the mouse affects the gui.
So scrolling while holding down Shift should not scroll horizontally but instead let you scroll through the tracks vertically. This is just a very small detail, but it does matter if you want to cut 2 hours of a Musical filmed with several cameras and two or more effects-tracks. Then you will mind whether you have to use your mouse at a border of the timeline or if you can let it stay where it is.
Alt Modifier
------------
The Alt modifier should be used to toggle the degree to which scrolling with the mouse affects the gui.
If you want to scroll a bit through the video by scrolling, you might not want to see every single frame, but you would be satisfied if you see only every 10th.
Windows / Tux / Super Modifier
------------------------------
The Windows / Tux / Super Modifier should give you a special feature often called a shuttle.
Hold down Super and scroll a bit up or down to get a very slow but steady forward / backward play like a extreme slow motion but with changing speed.
(I use the Super/Meta 4 key exclusively for window manager-related operations, as is increasingly common. If we use it in the application, at least let it be unmapped so we don't clobber people's bindings. --rcb)
Ctrl Modifier
-------------
The Ctrl modifier should switch from normal scrolling to zooming like in most other applications.
Here again the Shift modifier held down together with the Control modifier should switch from time-zoom to switching the height of a track.
But in the second case there is a need for another definition: As every track can have it's own height, there should also be the possibility of changing the height of all tracks at one time. Here it would be a good idea to let the modifier change its catchment area to all tracks when the mouse pointer is over a trackhead as this should be a big enough area so that you don't have to care on which pixel the mouse pointer exactly is.

317
doc/design/gui/GuiBrainstormingReviewed.txt Normal file
View file

@ -0,0 +1,317 @@
GUI Brainstorming Reviewed
==========================
:Author: JoelHoldsworth
:Date: 2009-01-24
State of the GUI
----------------
image::images/screenshot090124-resources.jpg
Updated 18/01/09
Done
~~~~
// AsciiDoc doesn't support strikethrough text so I left this as is -- daylife
* Tiled Windows +
One Window can be tiled (horizontally/vertically) giving areas where screen elements can be placed (see blender)
* Multiple windows +
Can open multiple windows on one head and (optionally) tile them as above
-- link:ct[] [[DateTime(2008-02-07T20:42:54Z)]]
* My personal preference would be to produce the GUI in C++ with Gtkmm. Gnome is the most popular desktop for Linux, and GTK now has good support both for Win32, Mac and KDE (except that GTK on Mac still needs X11, probably for some more time)
* This sketch shows the GTK docking system, as seen in Anjuta (and to some extent in Inkscape). The GTK docking system is like a tiling window manager in a window. This allows the layout of panels to be totally rearranged, or even detached into floating windows. These floating panels can be stuck together in a single child window. This would be a perfect way to span the workflow across 2 screens. For me, it's this feature that most attracts me to GTK.
Reviewed Ideas
--------------
High Priority
~~~~~~~~~~~~~
* IMHO it's much better to make an interface out of standard bits (controls, fonts, colours) wherever possible. We really want to make Lumiera "like other apps", rather than making our own unique GUI elements just for this project - the way Cinelerra does. This makes it quicker for new users to begin work, and feel comfortable.
* Tango style icons mean the Lumiera will look consistent with Gnome, Windows, Mac and KDE - and the rest of the free desktop applications.
* Stealing ideas from Windows Movie Maker, it seems better to display transitions and filters in a way that shows the user what the filter will _do_ to the video/audio, rather than using metaphors: like George Bush=Unsharp in Cinelerra.
* A good entry level gui together with an advanced key driven system like about blender (not so much the ui)
- Yes Blender's UI isn't that great a model to follow (though there is some good stuff in there). I agree about good keyboard support. A good place to start would be the standard <Modkeys>+<Letter> accelerators, as well as context menu mnemonics. We should be able cover the entire command set with the these. I don't see us needing anything more advanced than that.
-- link:JoelHoldsworth[] [[DateTime(2008-07-22T20:48:03Z)]]
Medium Priority
~~~~~~~~~~~~~~~
* Fullscreen Support +
Windows can be made fullscreen with no decorations (but tiling left intact)
-- link:ct[] [[DateTime(2008-02-07T20:42:54Z)]]
- Comment: This can be done with relative ease. We should add this feature.
-- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]]
* Work well with tiling window managers +
I propose that the future Lumiera GUI is designed without too much (or anything) about the user's screen apart from what is acceptable based on the X11 protocol(?) in order to work well with tiling window managers. The main problem to watch out for is assuming specific dimensions. The nature of tiling window managers is that most of the time, the windows without focus are dramatically downsized in one or two dimensions. This causes poorly designed GUIs to behave strangely, sometimes as bad as constantly jumping between layouts and thus causing unnecessary CPU load.
-- link:MichaelPloujnikov[] [[DateTime(2008-04-14T22:29:12Z)]]
- Comment: As much as anything this is a case for good testing on tiling window managers. People who use them need to do this, and file bugs, or better yet patches. It would be good for me to start using one as well, I think.
-- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]]
* Window configurations can be stored/restored in customizable presets and are part of the project (see blender again)
* Jog feature +
A jog tool is a sliding ui element that when clicked and held, will play the video at a certain rate as the mouse drags left or right. As the mouse drags the the left the video plays forward faster (It should advance very slowly at first.). It acts the same way when the mouse drags to the right, except that the video plays in reverse. Again, it can be tedious trying to make frame-accurate cuts to long video files. Without a jog tool it makes it more tedious to get to the exact frame you want to cut on because you must scan through, then click the next frame button half a dozen times. A jog tool would remedy this because one could easily vary the playback rate, even reverse it, zeroing in on the frame much more quickly. Together these two features could really increase the speed at which one can edit precisely in Cinelerra.
- Comment: This idea seems feasible, it could be worked together with cehteh shuttle slider proposal.
-- link:joelholdsworth[] [[DateTime(2008-07-19T19:42:04Z)]]
* most numeric value entries (sliders, spinbuttons) can be changed when hovering the mouse over it and turn the scroll wheel (maybe with an additional modifier key?) -- The scroll wheel is accelerated depending on how fast it is operated by the user, snapping it slowly gives frame/interval precise increments, turning it faster will exponentially increases the increment (2,4,8.. frames per click)
-- link:ct[] [[DateTime(2008-02-07T20:42:54Z)]]
* "Render AS" +
The *process for creating a DVD* where Video and Audio have to be rendered separately is laborious. A script could easily handle this, and make the use of the program so much easier, attractive, inviting, productive, time efficient, bla bla. All the user needs to do is set the parameters and file name (once) and then "do". Many commonly used formats for saving could be saved as presets that completely avoid all the questions (say in the "File" drop down menu, as a customizable "Render AS" choice). This could also be done for HDTV, iPod, Ringtones, VCD, Various formats that give the best performance for uploading to Youtube and all the other video sharing sites.
+
When a whole magazine article(s) can be written about the task of exporting a file to make a DVD, you know the process is a long one. mmm ... Any well paid journalists out there want to sponsor programmed task efficiency? - "NO?" - oh well.
-- link:Tree[] [[DateTime(2008-05-07T16:44:00Z)]]
- This could probably be solved by having a series of format presets in the Render dialog. The default set could contain settings for the values you mention. We could even allow the user to save their own presets. Cinelerra already has this functionality - these are called profiles, but it doesn't come with a default set at all.
-- link:JoelHoldsworth[] [[DateTime(2008-07-24T16:13:28Z)]]
* Reduced quality previews +
There needs to be a way of giving the user the choice to see the movie at full quality - computationally expensive, or at reduced quality for times when full framerate would be impossible.
* Track View Height +
Let the user have more flexibility over the track view height. Some tracks can be set to minimal, others to visible (but basically iconic), others enough to see features, and one or two to good resolution. Some may even be blanked.
+
The track view height could be individually selectable , for example, by changing the "draw media" icon from toggle mode to drop down menu. The drop down selection options could include "don't show", followed by track sizes as per the drop down menu at the bottom of track view.
-- link:Tree[][[DateTime(2008-05-07T17:30:00NZ)]]
- Comment: Yes, I was thinking about this idea myself. At first I was thinking of just allowing the user to expand or collapse the track with a +/- button. But then I wondered if it would be good to have the track completely sizable. My current thinking is the best way would be to have it sizable but with a kind of snap-to-grid behaviour so the whole thing doesn't become really messy.
-- link:JoelHoldsworth[] [[DateTime(2008-08-04T16:03:24Z)]]
+
--
* Ardour provides an example for this: the track height can be changed (by buttons or with the mouse wheel + modifyer key), but there is only a fixed set of possible track heights, some of which have a preconfigured layout. For example, in "smallest" size the track head shows only the track label without any buttons and the track is reduced to a tiny waveform.
-- link:Ichthyostega[] [[DateTime(2008-08-08T15:18:31Z)]]
--
Low Priority
~~~~~~~~~~~~
* Multi Head +
Can open Windows on different heads of the same server, and is aware of the existence of different physical monitors (ie. Xinerama-aware)
- Comment: Xinerama seems to be a decreasingly popular way of doing multi-monitor. This probably could be implemented, but I don't have a Xinerama based setup, and I've never talked to anyone who does. I use link:TwinView[], and it seems like a more practical way of doing dual screen to me. Surely RandR based multi-monitor is the main need today.
-- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]]
+
--
* Multi-Head != Xinerama ... This is very important and quite common, We want to support monitors driven at the native Video Format (resolution, framerate, interlacing, overscan, ....). For a professional setup this is really required!
-- link:ct[] [[DateTime(2008-07-22T07:11:11Z)]] +
Xinerama and twinView test comparison http://www.phoronix.com/scan.php?page=article&item=387&num=1[]
--
* Automatic Clip Creation based on video content. +
When scanning through an hour long video clip, it can be tedious to go through it all making clips. It would allow the user to get right to work if Lumiera could split the video into clips based on scene changes. Each clip would begin at precisely the frame the current shot begins and end at the last frame before the next shot. As long as the user could then edit these clips on the timeline, this would decrease the time spent sifting through the raw footage.
- Comment: This seems like a good idea, and quite easy to implement. I think that when we get the video-capture and media manager code working this would a be a good subproject for someone to take on.
-- link:joelholdsworth[] [[DateTime(2008-07-19T19:42:04Z)]]
* Import and Export SMIL files +
Many current cinelerra users probably use kino for their capturing of DV. it uses less resources, so less system demand during capture. Good display monitor while capturing. Open Movie Editor is a good multitrack editor that can share Kino's SMIL files. A good progression in complexity of editing is start with kino, move to OME, then cinelerra (lumiera). A really convenient way to assist stepping up from Kino is to handle the SMIL files.
+
Automatic scene detection is a great feature in Kino. The simpler editors make it easy for less skilled people to look after the selection of preliminary clips, while lumiera is used by the folks who put it all together, and finish it off.
--link:Tree[][[DateTime(2008-05-09T15:10:00NZ)]] .
- Comment: SMIL is quite cool technology. It's not just a Kino thing. It'd be quite good to be able to import this standard format.
-- link:JoelHoldsworth[] [[DateTime(2008-07-24T16:41:02Z)]]
More Discussion Needed
~~~~~~~~~~~~~~~~~~~~~~
Timeline
^^^^^^^^
* Sparse Timeline +
Make the timeline view _sparse_, that means the time on top is not continuous anymore but \'boring' sequences get omitted and \'interesting' sequences get displayed, probably even stretched to cover at least a single thumbnail.
+
This needs an ui (menu or whatever) to turn this feature on and some selection which events the user is interested in (scene cuts, transitions begin/end/mids, keyframes (begin/mid), labels, ...)
-- link:ct[] [[DateTime(2008-05-21T13:46:51Z)]]
- Comment: Do you think we could use view splitting to accomplish this? You can see this sort of thing OpenOffice.org calc. Where you drag a splitter out from the ends of the scrollbar, this allows you compare 2 or 4 parts of a big spreadsheet at the same time. Implementing something like that might be reasonably doable. But if you're talking about hiding periods on the timeline, that sounds a lot less easy to me, and it feels like a bit a bit of an odd thing to do. What do you think ct?
-- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]]
+
--
* No, view-splitting is something different, usually one splits the timeline to few places (2 or 3). Managing those splits requires a lot manual interaction (resizing the splits, zooming into the right time resolution, scrolling to the desired range, ...). In contrast this 'sparse' timeline does that all automatically by possibly adding hundreds of those split points (there should be no split bar on the gui). One just has to select POI's with some menu or such. Well and the timeline ruler needs to adapt to it, that might be tricky
-- link:ct[] [[DateTime(2008-07-22T07:11:11Z)]]
--
* "Sparse Timeline" is in Trackview" - see Track view section lower down the page +
This is the kind of features I have suggested in the Trackview section lower down the page. I like the name you give it - "Sparse" because it allows the user to not have to bother viewing OR scrolling past all the stuff in between two end points (or more items) just to tweak the ends of a segment. But I would emphasize that instead of reducing the width of the timeline because of the narrow time span needs for the one task, that more tasks can be carried out in the same view. This is because the view just misses out all the stuff in between, for each task.
+
I am playing around with a few thoughts and maybe might attach an image of how it might work. But in conjunction with "tabbed views" it would result in the convenient ability to display all the work areas in a concentrated display, meaning a whole lot less scrolling around, and clicking to bring windows to the foreground.
-- link:Tree[][[DateTime(2008-05-23T16:59:00NZ)]]
- Comment: See above. With regards to tabbed based UI in the timeline view, I do have this in mind, and it seems reasonably straightforward to allow two tabs which contain views of the same timeline - just scrolled to different places.
-- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]]
* Clip Mode +
This would be a clone of the clip mode in Apple's iMovie. In this mode, users would be working with discreet (read untrimable) clips. Dragging a new clip into the sequence would cause it to be inserted between two clips, not overwriting them. Once all of the clips are layed out to the users satisfaction, they could then switch to the normal multitrack mode and trim the heads and tails of the clips from there. -- link:rexbron[]
+
The advantage to this sort of work flow is that it allows an editor to very quick create an assembly cut of a film. During this phase of editing, the editor and director are examining the takes and deciding on which ones they like best. As such, it makes sense to be able to easily change the order of clips and add new ones to see how the shots fit together.
- Comment: This sounds a bit odd in some ways. But I'd be interested to find out more. I'll probably do some research into it at some stage. Maybe you can post some screenshots.
-- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]]
* I propose an assembly system where the source material is left untouched where effects are added on the fly similar to html and dtp packages. In this system the system is linked together using an node system similar to gstreamer and jack.
- Comment: Yes the core of lumiera will work on a scen graph of connected nodes, and we want to provide the user with a way of using that power. We need to discuss how node wiring and the timeline-track tree go together. Note that node wiring only seems to make good UI when the node graph is fixed for the duration of the whole project timeline. We need to work out how this fits together with the timeline tree, and if metaclips help this problem at all.
-- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]]
Comment to all those sparse timeline and clip mode proposals: The benefits of those are obvious, as they directly correspond to the working with storyboards. Almost every serious movie uses storyboards to quite some extent. But for the implementation, I'd propose not to see it as an alternative view/mode of the timeline. Rather, I'd treat it like a media/asset folder. Probably we'll have the ability for the user to group the media asset into various "bins" (virtual sub folders). Moreover, pre-cut clips appear as clip assets as well (similar in Cinelerra and most other video editors). Thus, we just need a function to "play" such a clip bin. It could be implemented by defining a ordering on the clips in the bin (from top to bottom and from left to right?). Then, this function would create an transient EDL on-the-fly, containing just these clips, and hand it over to the engine for building/playback. Thus, the user can see his "draft-cut" played back in real time, and thats all what is really needed. When satisfied, he could mark the clips in the bin and drag them to the timeline, which would add them in the same order starting at the current position. I don't think we need to go though all the pain of creating an separate, dedicated UI for this purpose.
-- link:Ichthyostega[] [[DateTime(2008-07-27T23:20:19Z)]]
Widgets
^^^^^^^
* Generalized Fader
+
image:images/fader.png[fader.png]
+
All faders are the same kind of custom widget, that is:
a. a slider to adjust the value with the mouse
.. a level indicator (progress bar?) reflecting the actual level of the signal
.. a spinbutton/text entry to add a value with the keyboard
.. a label showing the measurement unit and other information
.. a popup menu to configure this widget itself
+
--
* enable/disable the things above
* set start and end values (the application gives an absolute allowed range)
* change the measurement unit (byte, percent, dB, ...)
* change between linear/logarithmic behavior
* snap at specific intervals
* horizontal/vertical slider/level
* adaptive scroll wheel (see below)
--
+
for the application all faders provide a float (or double) value, nothing else.
-- link:ct[] [[DateTime(2008-02-07T20:42:54Z)]]
- Comment: I think making some kind standardized fader widget is probably going to be necessary for this project. We need a good way of combining together the artistic "genstural" elements of a slider widget with the precise numerical behavior of an edit widget, and it needs to be compact - the UI will have a lot of these. I'm not sure how often we'll need to see a level meter with these. Most of the time a control is either an input or a readout - very rarely both. Generally speaking I'm against the idea of having a popup menu to configure this widget. I believe that it should be configured to work in a way which is user friendly by default. There may be many of these widgets and asking the user to configure each of these before they behave well seems a bit unfair to me.
-- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]]
+
--
* I agree, the defaults should be reasonable set per-item, that will be that the meter is in most cases off and the spinner will be off on many cases too. I tried to show whats needed for the most generic case with all bells and whistles. When we generalize this we need to support all eventualities even if turned off by default. Note that some things could be done in tooltips, see below "about tooltips and statusbar", the above fader is just an early proposal/brainstorm
-- link:ct[] [[DateTime(2008-07-23T09:41:25Z)]]
--
* Magnifying Glass for the Faders +
Faders should have a "magnifying glass" mode, which can be activated by a key combination or modifier key. When activated, you can fine tune the current value: The step increment is lowered ideally to the real limit of the underlaying parameter, or, if this is too much, at least it should be much smaller than anything you get by dividing the possible value range by the fader length in screen pixels. In this mode, the fader doesn't cover the whole range, rather it is centered at the current value. Changing the value by these small increments should give an obvious visible feedback. Ideally, an accompanying automation curve display will switch to the extreme vertical zoom as well. And it's important that you don't have to zoom, you enter/leave with one keypress.
+
Partially, this is covered by the Adaptive Mouse Wheel too; but, especially when working with sound, the problem is that the parameter range cover several orders of magnitude. For example, even 16bit PCM sound has a volume parameter which can be adjusted in 32768 steps, and yes, there are situations when these fine steps make an audible difference, while most software faders give you not much more then a view hundred subdivisions even under optimal circumstances.
-- link:Ichthyostega[] [[DateTime(2008-02-07T22:34:08Z)]]
- Comment: This is definitely a problem we need a solution to. Is modifier keys the most discoverable way of doing it - I'm not sure. We need ideas for this (see below).
-- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]]
- This concept of "magnifying faders", is well explained in http://thorwil.wordpress.com/2007/05/01/fan-sliders/[Thorsten Wilms Fan-sliders Article], the Article also links to an implementation.
-- link:oracle2025[] [[DateTime(2008-02-08T00:40:05Z)]]
- Comment: In one sense this is bad because it's so incredibly non-standard. Bun in other ways it seems to me like a rather ingenious solution to the problem. Aparently Ardour has these. I must investigate.
-- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]]
Scripting
^^^^^^^^^
* Usability (ease of use) - mouse clicks and motions, inputs decisions, etc required to achieve tasks. Macros are really handy for allowing the user to speed up repetitive tasks that the program designers have not anticipated and made easy to do from the outset. Macros can be shared on a central web site. Plus developers can look and see what the macros are being used for, as this gives a very important indication of where vital tasks are.
-- link:Tree[][[DateTime(2008-05-07T16:44:00NZ)]]
- Comment: We need to have some discussion about scripting. To do macro scripting we'll need to implement a DOM interfaces etc. into 2 or even all 3 layers of the system. If we want to do this, then we'll need to begin planning for it early. We have talked already about making scripting the movie itself AviSynth style. Both are worth talking about.
-- link:JoelHoldsworth[] [[DateTime(2008-07-22T21:58:22Z)]]
+
- See also rcbarnes compound filters proposal.
-- link:JoelHoldsworth[] [[DateTime(2008-07-24T16:25:57Z)]]
Others
^^^^^^
* Time estimates for lengthy Tasks before committing to the action. +
Handy to have time estimates for lengthy task indicated even before committing to the task. Also an estimate for the % increase or reduction in time of adjusting parameters. So you can make a good tradeoff between the result and and the time taken to get it. When a task is carried out, measurements are made to improve the accuracy of future guesses.
--link:Tree[][[DateTime(2008-05-07T21:34:00NZ)]]
- Comment: This would be quite a nice feature if we can do it. Though it's often hard to know how long something will take until you start doing it. For example estimating the time to render a 1000 frame animation might involve rendering the first 10 frames, then multiplying that time by 100. Problem is that could potentially be quite complex to set up - especially when we're working with render farms. The backend guys would need to think about this I think.
-- link:JoelHoldsworth[] [[DateTime(2008-07-24T16:24:50Z)]]
Joelholdsworth is Skeptical
~~~~~~~~~~~~~~~~~~~~~~~~~~~
* Multi server +
Display GUI components on different Xservers, some critical components (GL rendering etc) might be only supported on local displays
-- link:ct[] [[DateTime(2008-02-07T20:42:54Z)]]
- Comment: This doesn't seem like a very common use case. I can't see any immediate advantage in doing this, and I'm struggling to think of a scenario where this would be helpful.
-- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]]
+
--
* Having more than one workstation each driving a display on its own, getting more bang. But I agree this is not a important feature and rather a corner case.
-- link:ct[] [[DateTime(2008-07-22T07:11:11Z)]]
--
* 3x3 Menus +
Have a mostly quadratic 3x3 dialpad like popup menu poping up so that the center is the mouse position (adjusted when near screen corners). The middle field is always the close/cancel functionality and the 8 fields around offer the menu entries. Navigation can be done by mouse, cursor keys or numpad! Menu entries can open 3x3 submenus again, either incremental so that closing brings you up to the higher menu or exclusive that closing aborts the whole menu.
-- link:ct[] [[DateTime(2008-02-07T20:42:54Z)]]
- Comment: Cehteh really want this feature. Personally I'm skeptical. It seems clumsy and non-standard to me, and not good in terms of command discoverability, so I don't want to implement it. But then he does seem to want it pretty badly, so I'm a bit cautious about putting it straight in the "Won't Implement" category.
-- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]]
+
--
* not only me, but ichthyo and simav too and anyone i talked with liked this idea but you
-- link:ct[] [[DateTime(2008-07-22T07:11:11Z)]]
--
* User Precautions get built out of user interface and into program.+
When attaching such and such effect to a track, disable "play" before attaching it, then re-enable play aft attaching it. (we don't tell you this before hand, and we never will, unless you ask the question and search the net, then you might find out in the "secrets manual", And you'll have to remember this (always)!! If there are circumstances that apply to an effect (or for that matter any other part of the program), then the feature could have a flag in it that warns the system to take note of it, and it then reports what its requirement or tweak feature is, so the system can automatically handle it the best way. (A sort of OO process handler). This not only saves potential lengthy wastes of time, but saves concentration on sideline issues, speeds up work, adds to reliability and good time user experience.
--link:Tree[][[DateTime(2008-05-07T21:34:00NZ)]]
- Comment: I'm not sure I quite understand what this is about. Your explanation is a bit hard to read.
-- link:JoelHoldsworth[] [[DateTime(2008-07-24T16:24:50Z)]]
+
--
* I wouldn't even be skeptical, I am against such a proposal. Any feature we add should just work, without crashing the application and trashing the users efforts. If a feature doesn't work, it needs to be fixed, instead of automatically warning the user that this feature is broken. The fact that for Cinelerra you need the "secrets" tells quite a lot about the state of affairs regarding Cinelerra, and because we wanted to change this, Lumiera was born. ;-)
-- link:Ichthyostega[] [[DateTime(2008-07-27T23:04:42Z)]]
--
May Implement Some Day
~~~~~~~~~~~~~~~~~~~~~~
* Widget overlay/Fullscreen +
Some Widgets can be made half transparent and overlay video giving a head up display editing while the video is at native resolution in background.
Window configurations can be stored/restored in customizable presets and are part of the project (see blender again)
-- link:ct[] [[DateTime(2008-02-07T20:42:54Z)]]
- Comment: This is difficult to do. XVideo and Gtk don't really mix. But I can't think of any controls that need to be overlaid.
-- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]]
+
--
* Would be nice but not a primary feature. I'd rather think about some some special on-screen-menu overlay, not necessary gtk (libosd?) maybe this can be implemented with OpenGL overlay or so. As noted before, having a monitor which runs on the native Video resolution is a requirement. Giving this Monitor some (limited) GUI features, like mask editing or other simple manipulations gains extra points. Not a primary/important feature but I'd rather like it seen as "Will implement _someday_" The window configuration customization should be its own point, I think thats easy with GTK (Gimp does that) adding a small Configuration management GUI shouldn't be hard.
-- link:ct[] [[DateTime(2008-07-22T07:11:11Z)]]
--
Won't Implement
~~~~~~~~~~~~~~~
[[Include(/WontImplement, , editlink)]]

147
doc/design/gui/GuiBrainstormingReviewed/WontImplement.txt Normal file
View file

@ -0,0 +1,147 @@
GuiBrainstorming Reviewed - Won't Implement
===========================================
:Author: JoelHoldsworth
:Date:2008-07-23
* Help feedback for quality management +
Sometimes help files and tutorials are improvable. Keeping track of which help is to which amount useful for a majority of users will provide data about which help files are improvable. It will also provide data about which features most often users use help and might be candidate for usability consideration. like: []solved my problem []got me on the right way []needed to find help elsewhere []problem not solved
- This is surprisingly hard to implement (I think), and in a sense it's already obvious to us whether the docs are quality - filled with nice graphics, simple steps, and lots of clear information or whether they need improvement. This feature might have some use on the website.
-- link:JoelHoldsworth[] [[DateTime(2008-07-23T20:47:35Z)]]
* Suggest an improvement Feature - for users to help improvement +
Just like the "Help" feature suggested elsewhere, in which the user can edit the help file as they go, so could the user be able to make suggestions to improve the program. Able to get a panel or window grab, and draw arrows lines to show "where" they are talking about. Online linking - There could also be the facility to click on an email link to send a request for help (want to engage in dialog, rather than just notify - without need for response). Or a relevant search is automatically generated for the forum, chat room, faqs, helpdesk, documentation. Or get sent to a link:BrainStorming[] page like this one (specifically for the panel they were in).
-- link:Tree[][[DateTime(2008-05-26T12:01:00NZ)]]
- This isn't really a GUI issue - much of this is more for the website, which the GUI will probably link to from an item in the help menu.
-- link:JoelHoldsworth[] [[DateTime(2008-07-23T20:45:00Z)]]
* Help System - rolling tips and tutorials +
Sometimes, when a beginner is using the program, they just sit back and look at the general picture. It's a behaviour that gets down naturally. It looks like a "break", but going through their minds are questions like ; "Am I doing this efficiently?", "What would make this easier, and is there already an easy way to do it in the program?", "How long do I think this will take, and what can I do to make it in time?", and much more. Sit back, look at the whole screen, maybe cruise around the menu, conceptualise the project and steps involved - it's a kind of task oriented learning - on the job (self) training.
+
The closest thing so far to something which takes the opportunity to make use of this "looking at the wider picture", is the tips that come up at the start - a kind of "while you are doing something - we thought you might find this helpful".
+
Because of the creative effort needed when composing video projects, there is quite a bit of vision based thinking. It is during these times that a help or instructional item could be presented to the user. (I am not talking pop-up advertising). Then user could set aside space for a window that scrolls help text, flashes tips, plays video tutorials or help. This help function could be optionally set to go on all the time, begin after x seconds of inactivity, or be manually triggered. It might even be a kind of screen saver - leave it running while having a coffee break. But what it does, is run a whole heap of options and new information past the user, in a low prompting mode, to a degree that they are prepared to have the minor distraction.
+
If it was context sensitive, then it would provide relevant information, similar to having a tutor or an expert leaning over your shoulder, explaining further possibilities and applications.
+
Video tips and Tutorials could be available via Youtube, which also doubles as promotion for the project. Users could choose to download groups of videos on selected topics.
-- link:Tree[][[DateTime(2008-06-11T17:04:00NZ)]]
- If the user stops to thing I think we should give them some peace while they get their thoughts together. I'm sure if they want help they'll ask for it. Remember how annoying Clippy was in MS Office? :-P
-- link:JoelHoldsworth[] [[DateTime(2008-07-23T20:45:00Z)]]
* Help and visual prompts use GIFs for visual cue as to time behaviour of feature. +
Icons are handy when they portray some sort of cue for the task that they do. A number of tasks in video editing are time related. It would be handy to have some form of visual que as to what the time related task does. Since Gifs can show motion, they would be very good for this task. PNGs could also do it it they were timed to cycle through their images. Example uses would be to show the difference between "track" and "stabilise" in motion tracker - a strip showing a pogo stick going along a footpath would be suitable to show the differences between track and stabilise (and could also be used to show the differences between the forms of vector calculation. GIFs could also be used to show editing functions that involve several important steps.
--link:Tree[][[DateTime(2008-05-26T08:45:00NZ)]]
- If we did want animated icons we'd be better off with MNG or a PNG image strip because then we'd get transparency. There are 2 reasons why I think this is a bad idea. 1. There's an aweful lot of drawing to be done. We already need to produce perhaps 100 high quality tango style icons for the user interface. If they're animate someone would have to draw 1000s of these, with all the quality control problems that go with it. 2. I'm not sure it's something people will find very helpful. Even if the animation only begins when we hover over the icon, it could even be quite annoying and distracting.
-- link:JoelHoldsworth[] [[DateTime(2008-07-23T20:39:36Z)]]
* Help System - available for user improvement +
_Similar to tool tip and status bar suggestion above._ A *"hover" hint / help* facility would be a major bonus. Just make the function available, the box can start with an index number, and users can type in their own help comments (either in a *help text entry management* section, or directly into the pop-up hover box - in optional help edit mode).
+
These can be pooled at a central web site in to languages, and brevity/completeness (options to links to further help, links to examples, links to video tutorials). So the developers do not have to spend time writing help files - just make it possible for the users to. The developers might like to add a few comments to the verbose files at some later point, or clear up inaccuracies. translators can also do the work for other languages. Very quickly the supporting documentation's usefulness would add to the attractiveness of the program.
-- link:Tree[][[DateTime(2008-05-07T16:44:00NZ)]]
- A wiki style approach is often an effective way to get community input on documentation. This may be a good way to get people working on it. But it's best for us to publish a tidied up documentation set and ship that, instead of creating a complex editable help system - which is vulnerable to vandalism.
-- link:JoelHoldsworth[] [[DateTime(2008-07-23T20:29:25Z)]]
* User selectable Experience Level - Task Oriented Layout +
The user could be asked to choose their experience level, and more complex options then get greyed out. The user could be asked the common tasks that the want to do, and other options could be greyed out. They can choose whether they want "grayed" out options to be available, or viewable, or not. The options which are advanced (or 2 levels greater than their current expertise level) could be "dark grayed" out and the user could have similar choices about their display).
--link:Tree[][[DateTime(2008-05-09T20:50:00NZ)]]
- Comments: I can't see any good reason for this. The user interface ought to be usable for everyone. The problem is that we want to enable everyone to be an "expert" by making power intuitively available even to beginners. The other problems is that light users might use only 10% of the functionality - but different light users use a different 10% from each other. So hiding things doesn't actually help make things simpler. It's much better to have things tidily arranged with clear descriptions etc. to help the user understand what a command might do - rather than hiding the command from them.
-- link:JoelHoldsworth[] [[DateTime(2008-07-22T22:25:58Z)]]
* SVG-based GUI elements (buttons and chevrons) could allow for easy GUI skinning and function calls since one would just have to mod an xml file to create new skins. It also means you could use code from the Webkit project for rendering the interface maybe. My practical reasoning is that if the devs wanted to work on the refining cinelerra/lumeira core technology or add plug-ins to extend its functionality, adding the GUI elements of those plug-ins might be less of a chore. It also may be a practical image format for a node-based compositing interface(if desired) because it supports embedded grouping of vector expressions. It could also be used as the basis for drawing things like masks and vector objects in the compisitor and the xml vector-values of those drawn objects could be communicated back to the programs core for updating events. (Similar to the way some more popular editor/compositors use PostScript to draw objects and place values.) It also the SVG spec supports transparency bluring and the ability to interpolate these events over time...things that can be incorperated into program beyond the the gui. Sorry for the long post...felt I needed to explain my reasoning better.
-- jb [[DateTime(2008-07-21T21:58:48Z)]]
- Comment: I am hoping that we can implement a simple set of skins for Lumiera. But we will be using the GTK based styles system, which is the standard. This allows theming to be done with a simple script file. These styles files are the more natural choice for UI theming, because WebKit is designed primarily for web, and would add a lot of unnecessary bloat to the app. Icons will be drawn as SVGs; a good choice for drawing the graphics, but these will be prerendered into PNGs at compile time as is standard practice for most free-desktop apps.
-- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]]
* Client / Server Model +
The server process will act as the master coordinator for the system, and will accept input from multiple GUI clients, and dictate tasks to multiple slave processes (even on separate physical servers). The GUI client application could be multi-platform. File transfer and communication could take place over SSH and make use of SVN for project management. Proxy editing will be the norm, due to the higher resolutions of final videos (the RED Epic will handle 5K). The entire system could easily work on a single Linux workstation, for easy adaptibility from handling home videos to expand to editing cinema films (which could benefit from dedicated GUIs to handle video, sound, etc.).
- Comment: Because the different parts of a project are so tightly integrated, it won't be possible to have one instance of the GUI that only has audio, and another that only does video etc. Moreover, the controller PC will hold the source video data. It is true that we plan to make a distributed backend, but the proc and GUI layers will remain on the controller PC. It's very hard to make a distributed GUI, and even harder to make lumiera have both a distributed front and backend.
-- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]]
* Navigation Systems +
There may be several methods to make menu selections, and other choices. The Gui could be made quite adaptable/customisable. Using a "skin" approach to the Gui, would provide a system for users who are not programmers, to help develop improved user interfaces. Mouse "gestures" (may be patent considerations) are another option. The way that options are communicated with the program functions could be made so that even as yet undesigned "user chooser systems" can be added.
-- link:Tree[] [[DateTime(2008-05-14T08:40:00NZ)]]
- Comment: Allowing customization is good in some ways. But every customization has a cost; in terms of development effort, debugging, maintenance, user support etc. so one must weight up the cost/benefit of allowing the user to reprogram the UI. IMO it's better for the UI to be right rather than to allow the user to reprogram it. If there's something sub-optimal about the UI then it should be fixed - for everyone. So we should be encouraging users with programming skills to contribute the code to us rather than them all making their own little customizations for themselves. That way lumiera becomes better for everyone!
-- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]]
+
--
* I completely agree, while I have to add that we can't know about all possible workflow scenarios. In sense of workflow Lumiera should be customizeable/scriptable somehow. This might be more intrusive/costly than just customizing a theme but should be less than hacking in the C++ source and have to o recompile.
-- link:ct[] [[DateTime(2008-07-22T07:11:11Z)]]
--
* Burst frames to graphics card. +
I am not sure how the current video play system works, but speed might be increased if several frames got sent to the video card at once. The video card can act as a video cache and play them as required. The number of interrupts to the process is reduced, to much less than one per frame, freeing up more CPU time for calculating the effects etc..
--link:Tree[][[DateTime(2008-07-18T18:18:00NZ)]].
- Comment: Good idea, but not really necessarily. Firstly because XVideo is pretty fast, and the bottle neck is in rendering not drawing. Second, we can't get direct access to video RAM anyway because X abstracts it away.
-- link:joelholdsworth[] [[DateTime(2008-07-19T19:42:04Z)]]
* GUI development - flexible approach - using "Skin Methods" +
In developing a GUI, the approach would normally be for the developers to design the Gui as the project progresses, and it comes out at the end. This is not bad, especially as there is a GUI to be had. But if there is a desire (which there appears to be a healthy desire here) to try new things, and look at options, then it would be quite useful to have a development method that allows for experimentation with options, side by side comparisons and assessments. Assessments by users and developers.
+
GUI design could be available for release for whoever wants to do a spin-off project re-GUI. So a GUI gets made by default by the development team, but the _skin kit_, and _methods of activating/interaction with the "engine"_ are made available. Users can then run their own tests and some sort of concensus arrived at later as to what is considered to work well, in what sorts of different user situations (newbie, small, large/expert).
+
If there is vibrant enthusiasm for teams to work on alternative GUIs, then the developers may even avoid the need to do much of the work on GUI, and just announce what the interface requirements are - the (choices of) GUIs for some sections could be ready before the program is finished. The GUIs could be developed and discussed concurrently (or advance of) the respective program code. On the other hand the GUIs could lag behind the developemnt of the engine, but not hold the engine up. Some GUI groups could be ahead of others in some parts of the program and behind in others - the user could even choose to the GUI (widget appearance) from one theme for one part of the interface, and GUI from another theme for other parts.
+
There could be agreement between GUI teams working on different themes, to cover separate parts of the interface first, so that there is at least some type of theme for the GUI for the whole program ASAP.
--link:Tree[] [[DateTime(2008-06-05T20:33:00NZ)]]
- Comment: To achieve that sort of thing one would normally expect the project to be forked. If our architecture is any good (and I think it will be), then a Lumiera fork would have no problem attaching a different UI to the system because there will be clear separation between the layers. But I can't see any good reason to help people fragment the project. If there are problems with the standard UI then we should fix them for everyone. If people want to write code for better UI they should contribute it patches. We really don't want to encourage people to fork any part of Lumiera.
-- link:JoelHoldsworth[] [[DateTime(2008-07-22T20:56:07Z)]]
* About Tooltips and Statusbar +
Tooltips are really valuable items, they should not be wasted for simple things like brief help texts. Instead they might display the actual state of the underlying widget in a textual form (numeric+unit) with _maybe_ some hints. Long time ago I proposed for Cinelerra to add a special mode to make tooltips editable, that is with a shortcut the actual tooltip becomes a small text input field where the user can enter exact values for some things, this value is committed with the return key and leaving this mode should be really easy (as simple as just moving the mouse, ESC key).
+
The Status bar can show more information but isn't directly in the users view, here we may play help infos like available options on the mouse buttons, important keyboard shortcuts etc. take a look at \'qcad' .. xfig has also static area where it shows available (mouse) options, just not a status bar but in the upper right of the screen.
+
This might be a bit different to some common other user interfaces (M$...) but I think this is much more valuable.
-- link:ct[] [[DateTime(2008-04-08T01:26:06Z)]]
- Comment:The thing about tooltips is that one usually uses them to aid the user in figuring out what a toolbar button (which would otherwise be a crytic icon bitmap) actually does - and so in this sense they're not a waste - they help users figure out how the application works. Users expect to find those hints in tooltips, and so it's rather unkind to the user to do something different and unexpected, and so we should avoid breaking the norms if we can. The actual state of the widget should be visible to see straight off and editing that value should be allowed straight off. That functionality should not be hidden inside a tooltips. People will find it really counter-intuitive to have to edit a value inside a tooltip in order to make a change.
-- link:JoelHoldsworth[] [[DateTime(2008-07-22T21:42:32Z)]]
+
--
* My argument is, that the \'figure out' thing could be done in the status bar, thats slightly less convinient but a user who searches for help will discover it (xfig, qcad and other programs do such kinds of dedicated help places instead tooltips). Popping up Tooltips only help _very_ early beginners, for someone who is even marginally used to the programm they don't add any value anymore, yet to be at a very prominent screenspace, right at your cursor. I think thats really a waste. I want interactive tips and help, but please where they are disciverable for help, but don't waste screen estate with information one might not really need. In contrast, the numeric value of a fader is a very important thing to know, at least when you want to alter it (cinelerra does that with its round knobs). And having a direct enter mode would be even more powerful for experienced users while not disturb anyone else. This might only complement the 'generalized fader' fader above, means when the fader is configured to show only a small scroller entry (to safe screen space) then displaying the numeric value and/or offer to edit it in a tooltip would be a good way to make it precise, without needing to reconfigure the fader, taking more screen space.
-- link:ct[] [[DateTime(2008-07-23T09:41:25Z)]]
--
* Default settings after install set to most reliable and least requirements +
The program may be tweaked to get performance on PC with great graphics systems, plenty of Ram and good hard drive speed. For people with lower spec'd gear, there may be some tuning needed, just to get going. There is the likelihood that people with low spec'd gear are not so able or inclined to read up on their hardware, and "search" for help on their video editor, to find out the solution to a problem (which they may not even have much idea of what the problem is). Consequently, they are likely to give up and not use the program.
+
Everybody enjoys a program that can be easily installed, and is ready to run. Few are upset by a program that is easy to install, setup, and is ready to run. But quite a few have nothing but disappointment with a program that is relatively easy to install, no idea how to set up, won't run or crashes, and not much clue about where to get help which is much further away than a click.
+
So it would do the program a great service to be able to run on just about any gear, straight away. This means using setup defaults which are general and as universal as possible, unless the program is given some sort of intelligent hardware detection function (not a big priority at this stage as it would require more programming work and folks are busy on more important tasks).
+
The tweaking could be left for the experts to get speed, rather than the noobies.
+
The tweak options could have say three general default settings, that progressively ramp up the performance demands, so the user can try the settings to very quickly get an idea of their gears trade-off between speed and reliability. each section of settings that has options, could be laid out so that increasingly demanding options are lower down the choices or colour coded for System requirement.
+
Colour coding may be red for heavy loadings and risk, yellow for low demands, and a colour blend between. The saturation of the colour may also indicate the preference to reach at least that level with your gear, so you know how to "trade off" between parameters that your are going to tweak up. This makes it a little more intuitive for how to drive your gear up to "red line" level.
+
A similar colour coding for speed could be used ; blue for low speed, green for high speed.
+
This colour coding for the two parameters (reliability and speed) means that when new driver/setup options are available that provide a speed increase, (yet are unreliable or unknown reliability at the time), the user has a very easy visual prompt to help them make decisions, and adapt their trial and error path to optimisation.
+
Feature to save different hardware settings, with notes in the hardware specs, and share them. Upload to Lumiera web site, so that better first guesses for new users are available. And if an intelligent system is used for hardware detection in future, then the information for best choices will already be available.
-- link:Tree[] [[DateTime(2008-05-28T09:41:00NZ)]]
- Comment: The problem is that unlike games, in movie editors there isn't very much that can be done in the way of tweaking. With video editing, by and large there are no shortcuts. So the calculations that must take place to render a video on a Quad Core workstation are the same as the ones that need to happen on an EeePC. Lumiera needs to be intelligent about how much RAM it uses etc. but that sort of thing ought to be automatic. The only thing that this could apply to is reduced quality previews, which I've put in the blueprint list.
-- link:JoelHoldsworth[] [[DateTime(2008-07-24T16:34:20Z)]]
* Menu Bar disconnectable from track view +
The menu bar could be made disconnected from the track view. This would allow the track view to be covered by a window, but the menu still kept on top. The menu bar could by default start at the top left and run across the screen. It could remain on top view. It could include easy single click tabs to jump from one window view to another.
+
The menu items that are specific to track view could be separated out and left as dedicated menu attached to the top of the track view.
-- link:Tree[][[DateTime(2008-05-07T21:06:00NZ)]]
- Comment: Actually if you look at the state-of-ui you can see that the menu bar will be shown at the top of workspace. We might make it detachable, but actually it's not very useful to be able to attach the menu bar to the sides or bottoms of windows.
-- link:JoelHoldsworth[] [[DateTime(2008-07-24T16:47:08Z)]]

7
doc/design/gui/index.txt Normal file
View file

@ -0,0 +1,7 @@
Design Documents: GUI
=====================
[icon="warning.png"]
WARNING: Website under construction

7
doc/design/gui/workflow/index.txt Normal file
View file

@ -0,0 +1,7 @@
Design Documents: Workflow
==========================
[icon="warning.png"]
WARNING: Website under construction

2
doc/design/index.txt
View file

@ -6,9 +6,9 @@ Lumiera Design Documents
* link:model/index.html[Model]
* link:engine/index.html[Engine]
* link:backend/index.html[Backend]
* link:application/index.html[Application]
* link:plugins/index.html[Plug-ins]
* link:builddrone/index.html[Lumiera Builddrone]
* link:config-loader/index.html[Config loader]
[icon="warning.png"]

7
doc/design/model/index.txt Normal file
View file

@ -0,0 +1,7 @@
Design Documents: Model
=======================
[icon="warning.png"]
WARNING: Website under construction

7
doc/design/plugins/index.txt Normal file
View file

@ -0,0 +1,7 @@
Design Documents: Plug-In
=========================
[icon="warning.png"]
WARNING: Website under construction

4
doc/index.txt
View file

@ -3,8 +3,8 @@ Documentation
All kinds of documentation goes here, both user and developer documentation.
* link:manual.html[User Manual] _(planned)_
* link:white-papers-presentations.html[Whitepapers and Presentations]
* link:user/index.html[User Documentation] _(planned)_
* link:{l}/media/index.html[Whitepapers and Presentations]
* link:design/index.html[Design Documents]
* link:technical/index.html[Technical and Documentation]

7
doc/technical/backend/index.txt Normal file
View file

@ -0,0 +1,7 @@
Technical Documentation: Backend
================================
[icon="warning.png"]
WARNING: Website under construction

7
doc/technical/gui/index.txt Normal file
View file

@ -0,0 +1,7 @@
Technical Documentation: GUI
============================
[icon="warning.png"]
WARNING: Website under construction

7
doc/technical/proc/index.txt Normal file
View file

@ -0,0 +1,7 @@
Technical Documentation: Proc-Layer
===================================
[icon="warning.png"]
WARNING: Website under construction

11
doc/user/index.txt Normal file
View file

@ -0,0 +1,11 @@
User Documentation
==================
'to be written...'
* link:manual.html[We need to write a user manual....]
[icon="warning.png"]
WARNING: Website under construction

9
doc/user/manual.txt Normal file
View file

@ -0,0 +1,9 @@
Lumiera User Manual
===================
'to be written...'
[icon="warning.png"]
WARNING: Website under construction