From 0c3cd9027c87db4ed1c01aacc8e7f2b4b3506f49 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Fri, 5 Sep 2025 20:33:10 +0200 Subject: [PATCH] DOC: clarify UI / discussion - indicate clearly that a ''past discussion'' is documented here - point out what is the primary focus for UI design ''currently'' - arrange some links better - use cross-links / Linkfarm; especially cross-link to the discussion regarding Wouter's Workflow proposals (2025) --- .../GuiBrainstormingReviewed.txt | 273 ++++++++++++------ .../GuiBrainstormingWontImplement.txt | 157 +++++++--- .../{MenuAndShortcuts.txt => PieMenu.txt} | 0 .../{scrolling.txt => Scrolling.txt} | 0 .../{TimelineDiscussion.txt => Timeline.txt} | 22 +- doc/design/gui/GuiDiscussion/index.txt | 25 +- doc/design/gui/index.txt | 34 ++- .../workflow/Verwijlen/FrosconMeeting.txt | 2 +- doc/design/workflow/index.txt | 3 +- wiki/thinkPad.ichthyo.mm | 76 +++++ 10 files changed, 447 insertions(+), 145 deletions(-) rename doc/design/gui/GuiDiscussion/{MenuAndShortcuts.txt => PieMenu.txt} (100%) rename doc/design/gui/GuiDiscussion/{scrolling.txt => Scrolling.txt} (100%) rename doc/design/gui/GuiDiscussion/{TimelineDiscussion.txt => Timeline.txt} (96%) diff --git a/doc/design/gui/GuiDiscussion/GuiBrainstormingReviewed.txt b/doc/design/gui/GuiDiscussion/GuiBrainstormingReviewed.txt index 5e63fa8af..f091031d5 100644 --- a/doc/design/gui/GuiDiscussion/GuiBrainstormingReviewed.txt +++ b/doc/design/gui/GuiDiscussion/GuiBrainstormingReviewed.txt @@ -5,7 +5,7 @@ GUI Brainstorming Reviewed State of the GUI ---------------- -image:{l}/media/img/design.gui/screenshot090124-resources.jpg[Screenshot 090124] +image:/media/img/design.gui/screenshot090124-resources.jpg["Screenshot 090124",width="80%"] Updated 18/01/09 @@ -20,7 +20,8 @@ One Window can be tiled (horizontally/vertically) giving areas where screen elem * Multiple windows + Can open multiple windows on one head and (optionally) tile them as above --- link:ct[] [[DateTime(2008-02-07T20:42:54Z)]] ++ +ct:: '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) @@ -42,7 +43,8 @@ High Priority * 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 + 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)]] ++ +JoelHoldsworth:: '2008-07-22T20:48:03Z' Medium Priority @@ -50,17 +52,25 @@ Medium Priority * Fullscreen Support + Windows can be made fullscreen with no decorations (but tiling left intact) --- link:ct[] [[DateTime(2008-02-07T20:42:54Z)]] ++ +ct:: '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)]] ++ +-- +joelholdsworth:: '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)]] ++ +MichaelPloujnikov:: '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)]] ++ +-- +joelholdsworth:: '2008-07-21T21:58:48Z' +-- * Window configurations can be stored/restored in customizable presets and are part of the project (see blender again) @@ -68,19 +78,25 @@ I propose that the future Lumiera GUI is designed without too much (or anything) 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)]] ++ +joelholdsworth:: '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)]] ++ +ct:: '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)]] ++ +Tree:: '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)]] ++ +-- +JoelHoldsworth:: '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. @@ -89,14 +105,21 @@ There needs to be a way of giving the user the choice to see the movie at full q 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)]] ++ +Tree:: '2008-05-07T17:30:00NZ' + -- -* 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)]] + ** 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. ++ +-- +JoelHoldsworth:: '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. ++ +-- +Ichthyostega:: '2008-08-08T15:18:31Z' +-- -- @@ -106,12 +129,14 @@ 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)]] + - 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 _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. ++ +joelholdsworth:: '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)]] + ++ +ct:: '2008-07-22T07:11:11Z' * Xinerama and twinView test comparison -> https://www.phoronix.com/review/387[see @Phoronix...] -- @@ -120,16 +145,21 @@ Can open Windows on different heads of the same server, and is aware of the exis 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)]] ++ +joelholdsworth:: '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)]] . ++ +Tree:: '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)]] ++ +-- +JoelHoldsworth:: '2008-07-24T16:41:02Z' +-- More Discussion Needed @@ -142,40 +172,66 @@ 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)]] +ct:: '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? ++ +-- +joelholdsworth:: '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 ++ +-- +ct:: '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. +-- +Tree:: '2008-05-23T16:59:00NZ' +-- - - 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)]] +** 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. ++ +-- +joelholdsworth:: '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. ++ +rexbron:: '2008-05' ++ +-- +* 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. ++ +-- +joelholdsworth:: '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)]] +** 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. ++ +-- +joelholdsworth:: '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. ++ +-- +Ichthyostega:: '2008-07-27T23:20:19Z' +-- Widgets @@ -204,43 +260,69 @@ All faders are the same kind of custom widget, that is: -- + for the application all faders provide a float (or double) value, nothing else. --- link:ct[] [[DateTime(2008-02-07T20:42:54Z)]] ++ +ct:: '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)]] +joelholdsworth:: '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 ++ +-- +ct:: '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 https://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)]] ++ +-- +Ichthyostega:: '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). ++ +-- +joelholdsworth:: '2008-07-21T21:58:48Z' +-- ++ +*** This concept of "magnifying faders", is well explained in https://thorwil.wordpress.com/2007/05/01/fan-sliders/[Thorsten Wilms Fan-sliders Article], the Article also links to an implementation. ++ +-- +oracle2025:: '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. ++ +-- +joelholdsworth:: '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)]] ++ +-- +Tree:: '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)]] +-- +JoelHoldsworth:: '2008-07-22T21:58:22Z' +-- + + ** See also rcbarnes compound filters proposal. ++ +-- +JoelHoldsworth:: '2008-07-24T16:25:57Z' +-- Others @@ -248,10 +330,14 @@ 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)]] ++ +Tree:: '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:: '2008-07-24T16:24:50Z' +-- Joelholdsworth is Skeptical @@ -259,40 +345,58 @@ 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)]] ++ +ct:: '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)]] +joelholdsworth:: '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. ++ +-- +ct:: '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)]] ++ +ct:: '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)]] +joelholdsworth:: '2008-07-21T21:58:48Z' ++ + +** not only me, but ichthyo and simav too and anyone i talked with liked this idea but you ++ +-- +ct:: '2008-07-22T07:11:11Z' +-- -- -* User Precautions get built out of user interface and into program.+ +* 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)]] ++ +Tree:: '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)]] --- +JoelHoldsworth:: '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. ;-) ++ +-- +Ichthyostega:: '2008-07-27T23:04:42Z' +-- +-- May Implement Some Day ~~~~~~~~~~~~~~~~~~~~~~ @@ -300,14 +404,19 @@ 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)]] ++ +ct:: '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)]] +joelholdsworth:: '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. ++ +-- +ct:: '2008-07-22T07:11:11Z' +-- -- diff --git a/doc/design/gui/GuiDiscussion/GuiBrainstormingWontImplement.txt b/doc/design/gui/GuiDiscussion/GuiBrainstormingWontImplement.txt index 55c0fdddc..49b63eacc 100644 --- a/doc/design/gui/GuiDiscussion/GuiBrainstormingWontImplement.txt +++ b/doc/design/gui/GuiDiscussion/GuiBrainstormingWontImplement.txt @@ -7,15 +7,24 @@ GuiBrainstorming Reviewed - Won't Implement 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)]] ++ +-- +JoelHoldsworth:: '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 ``BrainStorming'' page like this one (but marked specifically for the panel they were in). --- link:Tree[][[DateTime(2008-05-26T12:01:00NZ)]] ++ +-- +Tree:: '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)]] ++ +-- +JoelHoldsworth:: '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. @@ -27,66 +36,117 @@ Because of the creative effort needed when composing video projects, there is qu 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)]] ++ +-- +Tree:: '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)]] ++ +-- +JoelHoldsworth:: '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)]] ++ +-- +Tree:: '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)]] ++ +-- +JoelHoldsworth:: '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)]] ++ +-- +Tree:: '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)]] ++ +-- +JoelHoldsworth:: '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)]] ++ +-- +Tree:: '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)]] ++ +-- +JoelHoldsworth:: '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)]] ++ +-- +joelholdsworth:: '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 core 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)]] ++ +-- +joelholdsworth:: '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)]] +Tree:: '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! ++ +-- +joelholdsworth:: '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. ++ +-- +ct:: '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)]]. ++ +-- +Tree:: '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)]] ++ +-- +joelholdsworth:: '2008-07-19T19:42:04Z' +-- -* GUI development - flexible approach - using "Skin Methods" + +* 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). @@ -94,10 +154,16 @@ GUI design could be available for release for whoever wants to do a spin-off pro 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)]] ++ +-- +Tree:: '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)]] ++ +-- +JoelHoldsworth:: '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). @@ -105,17 +171,26 @@ Tooltips are really valuable items, they should not be wasted for simple things 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)]] +ct:: '2008-04-08T01:26:06Z' -- -* Default settings after install set to most reliable and least requirements + +** 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. ++ +-- +JoelHoldsworth:: '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. ++ +-- +ct:: '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. @@ -133,16 +208,28 @@ A similar colour coding for speed could be used ; blue for low speed, green for 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)]] ++ +-- +Tree:: '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)]] ++ +-- +JoelHoldsworth:: '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)]] ++ +-- +Tree:: '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)]] ++ +-- +JoelHoldsworth:: '2008-07-24T16:47:08Z' +-- diff --git a/doc/design/gui/GuiDiscussion/MenuAndShortcuts.txt b/doc/design/gui/GuiDiscussion/PieMenu.txt similarity index 100% rename from doc/design/gui/GuiDiscussion/MenuAndShortcuts.txt rename to doc/design/gui/GuiDiscussion/PieMenu.txt diff --git a/doc/design/gui/GuiDiscussion/scrolling.txt b/doc/design/gui/GuiDiscussion/Scrolling.txt similarity index 100% rename from doc/design/gui/GuiDiscussion/scrolling.txt rename to doc/design/gui/GuiDiscussion/Scrolling.txt diff --git a/doc/design/gui/GuiDiscussion/TimelineDiscussion.txt b/doc/design/gui/GuiDiscussion/Timeline.txt similarity index 96% rename from doc/design/gui/GuiDiscussion/TimelineDiscussion.txt rename to doc/design/gui/GuiDiscussion/Timeline.txt index 502cd8f21..b0ad5835f 100644 --- a/doc/design/gui/GuiDiscussion/TimelineDiscussion.txt +++ b/doc/design/gui/GuiDiscussion/Timeline.txt @@ -1,9 +1,11 @@ -Timeline: Discussion -==================== +Timeline: Extended Discussion +============================= :Author: Joel Holdsworth :Date: Fall 2008 -This is Joel Holdsworth's attempt to amalgamate all the ideas from all the brainstorming to one consistent idea that makes sense, can be implemented, and seems like it would be nice to use. Comments are welcome. +This is Joel Holdsworth's attempt to amalgamate all the ideas from all the brainstorming +to one consistent idea that makes sense, can be implemented, and seems like it would be nice to use. +Comments are welcome. * Avid vs FCP 2006 - http://www.fini.tv/articles/avidfcp2006.html[] Archived 2008 from https://web.archive.org/web/20071211184722/http://www.fini.tv/articles/avidfcp2006.html[fini.tv] @@ -222,14 +224,14 @@ Christian asked "why then not also controlling plugin parameters by placement?". I must admit, both of you have a point. Christians proposal goes even beyond what I proposed. It is completely straight forward when considered structurally, but it is also clearly beyond the meaning of the term/idea/concept "placement". -But what, if we re-adjust the concepts and think in terms of ''Advice'' ? +But what, if we re-adjust the concepts and think in terms of _Advice_ ? Thus, a placement would bind an media object into the session/sequence and also attach additional advice? As an example, to apply this re-adjusted Idea to the gain control: When a track group head has an gain/fade control this would just denote an advice to set the -gain. It does ''not'' mean that signal data has to flow "through" this -track/track group, it does ''not'' mean the gain is actually applied at this -point and it does ''not'' mean that any routing decision is tied to this gain. +gain. It does _not_ mean that signal data has to flow "through" this +track/track group, it does _not_ mean the gain is actually applied at this +point and it does _not_ mean that any routing decision is tied to this gain. Even signal chains being routed to quite different master busses can receive this advice, given the source clips are placed within the scope of this track group. The only difference needed on the GUI to implement this approach would be @@ -294,7 +296,7 @@ otherwise just normal effects in a master sequence)? Regarding effects, I should point out that in our concept, mask, "camera" and "projector" (Cinelerra's terms) are just some specific effects. Given that, it -is clear that effects need to be applicable ''both'' pre transition and post +is clear that effects need to be applicable _both_ pre transition and post transition. But the following limitation seems reasonable to me and seems to match the actual use: @@ -314,14 +316,14 @@ Btw. I very much agree with you that putting clips on group head tracks would be rather confusing, while I think placing an effect at a group head track is OK and feels natural. It will just be applied post-transition to all media within the covered range. And, note again the power of the placement+advice concept: -this does ''not'' mean the data need to be merged together and piped through the +this does _not_ mean the data need to be merged together and piped through the effect at this point. Rather, it means that each signal processing chain in the covered range will get an instance of this plugin wired in at a position equivalent to the place the effect is found on the group track with respect to the track hierarchy. I.e. after wiring in the transition(s), instances for effects placed at tracks are wired in order and ascending the track tree, and finally the connection will be made to the mixing step or output destination -according to the output advice found for ''this individual'' object (but in most +according to the output advice found for _this individual_ object (but in most cases this output destination advice will be inherited from the context, i.e. some root track) diff --git a/doc/design/gui/GuiDiscussion/index.txt b/doc/design/gui/GuiDiscussion/index.txt index ce300e896..f6479285b 100644 --- a/doc/design/gui/GuiDiscussion/index.txt +++ b/doc/design/gui/GuiDiscussion/index.txt @@ -1,11 +1,18 @@ GUI Design and Feature Discussion ================================= +//Menu: prepend child GuiBrainstormingWontImplement +//Menu: prepend child GuiBrainstormingReviewed //Menu: put child ConceptProposals after GuiBrainstormingWontImplement -//Menu: put child TimelineDiscussion after ConceptProposals +//Menu: put child GuiDiscussion/Timeline after ConceptProposals -In the early days of the Lumiera project, there was a lot of debate regarding -GUI concepts, -features and proposals. +In the early days of the Lumiera project, there was an extended debate regarding +GUI concepts and -features, including many proposals from the community. +Bearing in mind that we have meanwhile gained a clearer understanding what wee +need to build for the GUI, this _brainstorming phase_ is completed. + +However, a more focused discussion regarding »Workflow« +link:/x/Verweijlen.html[ensued in 2025]. GUI Brainstorming:: We got a lot of proposed cool features. In order to channel this great influx of ideas, @@ -22,13 +29,15 @@ GUI Proposals:: * link:ConceptProposals/Alcarinque.html[Alcarinque] * link:ConceptProposals/Barnes.html[Clay Barnes] * link:ConceptProposals/RichardSpindler.html[Richard Spindler] + +Feature discussion:: + Some topics spurred some heightened interest and (controversial) discussion * link:Workspaces.html[about Workspace organisation] - * link:scrolling.html[about scrolling..] - * link:MenuAndShortcuts.html[Ideas for menus and shortcuts] + * link:Scrolling.html[about scrolling..] + * link:PieMenu.html[menu / shortcuts] Timeline Discussion:: In 2008, Joel reviewed all the available proposals and distilled a more coherent vision - especially about the timeline, which certainly is at the heart of any video editor. - This page with link:TimelineDiscussion.html[Conclusions by Joel Holdsworth] is - _must read_ for anyone engaged into Lumiera GUI development. + especially about the timeline, which certainly is at the heart of any video editor. + + 💡 Note the link:Timeline.html#_joel_conclusions[Conclusions by Joel Holdsworth] as a summary. diff --git a/doc/design/gui/index.txt b/doc/design/gui/index.txt index 082c70684..eebcd27fa 100644 --- a/doc/design/gui/index.txt +++ b/doc/design/gui/index.txt @@ -1,20 +1,38 @@ Design Documents: GUI ===================== -In the early stages of the project, there was a lot of debate regarding -GUI concepts and -features and proposals. +//MENU: append child GuiDiscussion -link:GuiDiscussion/index.html[Here] is a collection of documents from these early + +In the early stages of the project, there was a lot of debate regarding +GUI concepts and -features and proposals. Extended discussions ensued on +the Mailinglist and several people provided concept drawings. + +-> link:GuiDiscussion/index.html[Here] is a collection of documents from these early discussions. +'''' + +In the current phase of the project, the UI conception focuses on a way +to build the interface in a systematic way, to support complex workflows +with low friction. The following questions need to be addressed: + +- How to use _Perspectives_, Views, Docking Panels and Layout +- how to adapt the Layout, ranging from a single Laptop screen to multiple monitors +- how to allocate and place new views and property panes intelligently +- how to allow for a coherent navigation scheme that works seamlessly + and intuitively over a mixture of several _Control Systems_.footnote:[The term »Control System« + refers to one technical realisation of an human-computer-interface, which is used coherently and + can coexist with other such interfaces + -> link:/x/InteractionControl.FoundationConcepts.html[more here]... + + The most relevant control systems are: Mouse, keyboard, pen, hardware controls, ...] +- how to build such a link:/x/InteractionControl.html[Layer of Interaction-Control] + without interfering with the evolution of the underlying UI toolkit ⚠ ... -.[red]#TODO# more contributions please... ;-) -We had several additional discussions and contributions on the mailinglist, -several people did even concept drawings. Collect these and add them here NOTE: We use the term *Workflow* in our discussions to denote the more integral concerns of how to achieve given tasks within the application in the most suitable and stringent fashion. We tend to separate those more global - considerations from the discussion of individual GUI features. - -> link:../workflow/index.html[read more here...] + considerations from the discussion of individual GUI features. + + -> link:/x/Workflow.html[more about Workflow...] diff --git a/doc/design/workflow/Verwijlen/FrosconMeeting.txt b/doc/design/workflow/Verwijlen/FrosconMeeting.txt index 6eca551c3..16027e1fd 100644 --- a/doc/design/workflow/Verwijlen/FrosconMeeting.txt +++ b/doc/design/workflow/Verwijlen/FrosconMeeting.txt @@ -30,7 +30,7 @@ shares similar goals but its scope is more far-reaching. We consider _Magnetic T important advancement to legacy track oriented GUI schemes; but it is more mouse confined and does not support several Control Systems footnote:[The term »Control System« refers to one technical realisation of an human-computer-interface, which is used coherently and can coexist with other -such interfaces -> link:{ldoc}/design/gui/InteractionControl.html#_foundation_concepts[more]. + +such interfaces -> link:/x/InteractionControl.FoundationConcepts.html[more]. + The most relevant control systems are: Mouse, keyboard, pen, hardware controls, ...] on an equal footing, which is our vision. diff --git a/doc/design/workflow/index.txt b/doc/design/workflow/index.txt index abfc5248d..9e2c03a0f 100644 --- a/doc/design/workflow/index.txt +++ b/doc/design/workflow/index.txt @@ -11,6 +11,7 @@ so we tend to treat it as a distinct effort, separate from the design of individ * link:LumieraWorkflowOutline.html[Workflow/Requirements outline by BJMR] * link:InterfaceConcept_Varga.html[Interface Concept by Christoph Varga] +* link:/x/Verweijlen.html[Workflow Proposals by Wouter Verweijlen] --> see also link:../gui/index.html[general GUI discussion...] +-> see also link:/x/GuiDiscussion.html[general GUI discussion...] diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index 19d878fb1..948fdda74 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -163213,6 +163213,23 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + + + + + + + + +

+ man kann Exclusions von Exclusions definieren; das klappt aber nur, wenn diese doppel-Exclusions spezieller sind als die allgemeine ignore-Regel. Insofern wird empfohlen, solche Regeln paarweise zu definieren +

+ + + + + + @@ -163244,6 +163261,65 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + + + + + + + + + +

+ klar machen: Diskusssion ist abgeschlossen +

+ + + + + + + + + + + + + + + + + + + + + + + + +

+ Name + Datum als Asciidoc-Delimited-Block +

+ + + + + + + + +

+ also mit + einleiten und dann mit -- umschließen +

+ + + + + + + + +