From: Till T. <ro...@tt...> - 2011-01-23 18:05:04
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, as you might have already noticed I replaced the spin boxes for double parameters with a new widget I call "drag value". It is a wrapper around QLineEdit (not inherited) and adds the possibility to change values using the mouse wheel and most importantly by starting to drag horizontal on the widget. This does not only require less space than a slider and can be accessed faster than KoSliderCombo (spinbox with drop down slider used in the title editor) it is also possible to skip large ranges (drag fast) and edit precisely (drag slow) at the same time. It did not invent this type of widget, it is also present in some Adobe products (After Effects, Premiere) and in Blender and possibly in other software, too. However I still doubt whether users will find out how to use it. Maybe a horizontal resize cursor? This will cover the value when the mouse if over the widget ... A blog post won't reach everyone... Any ideas?? If yes we might also consider dropping the slider for parameters. Another issue I have is the stylesheet. If there are multiple parameters the size of the widget decreases with every parameter. Have a look at the slope parameters in the SOP/Sat effect, for example, since they all have the same range. regards Till -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk08beAACgkQzwEyz7QP6nTwiwCeMZYotvK/hFDeehg3ecn0VqI6 T0QAnA8P1p8QREQbpb97OSFvtGnG9l/W =uqNd -----END PGP SIGNATURE----- |
From: Simon E. <sim...@gm...> - 2011-01-26 14:39:21
|
Hi Till, First of all I like the DragValue widget very much. Let's drop the sliders as soon as possible to save some space. Some ideas: * I'm not a big friend of nonlinear scales related to my mouse. (But I know this is a matter of taste.) I find it quite hard to hit a certain value, when I want to change from 400 to 100 I first shoot ways below (ok, only to 0) and when I'm at 90 it takes ages to get to 100, so I move the mouse a little faster and I'm at 140 already. I just have no feeling for this. My wish would be a linear scale, and perhaps slightly less sensitive (2 px per click instead of just one). Ideally the possibility to switch this on/off in the config dialog (linear/nonlinear) and to use a custom sensitivity. (Yes, I _do_ know that I can double-click to enter values directly, but sometimes the mouse is still faster.) * Another reason why this widget is not as easy to use as the slider is (I guess) the missing visual boundaries. For the slider you know when you are at the lowest or highest value (i.e. you can see the position of the current value relative to the min/max values). I currently don't have a good idea how to solve this though. * There are no live updates atm. I'm adjusting the parameter blindly and will not see the result until I release the mouse button. Please do not drop the sliders before this works with the DragValue widget as well :) Regarding users, what we can do is let them know about new changes in the Discover dialog for new releases, in the Changelog, in the kdenlive blog, perhaps even in the Forums. If a user is too lazy to read any of these, his bad. (We don't get paid by them … most of them don't do _anything_ for us.) If a user does not understand the widget but wants to, he will find a way. I would not worry about that. Simon 2011/1/23 Till Theato <ro...@tt...>: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > as you might have already noticed I replaced the spin boxes for double > parameters with a new widget I call "drag value". > It is a wrapper around QLineEdit (not inherited) and adds the > possibility to change values using the mouse wheel and most importantly > by starting to drag horizontal on the widget. This does not only require > less space than a slider and can be accessed faster than KoSliderCombo > (spinbox with drop down slider used in the title editor) it is also > possible to skip large ranges (drag fast) and edit precisely (drag slow) > at the same time. > > It did not invent this type of widget, it is also present in some Adobe > products (After Effects, Premiere) and in Blender and possibly in other > software, too. > However I still doubt whether users will find out how to use it. > Maybe a horizontal resize cursor? This will cover the value when the > mouse if over the widget ... > A blog post won't reach everyone... > > Any ideas?? If yes we might also consider dropping the slider for > parameters. > > Another issue I have is the stylesheet. If there are multiple parameters > the size of the widget decreases with every parameter. > Have a look at the slope parameters in the SOP/Sat effect, for example, > since they all have the same range. > > regards Till > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk08beAACgkQzwEyz7QP6nTwiwCeMZYotvK/hFDeehg3ecn0VqI6 > T0QAnA8P1p8QREQbpb97OSFvtGnG9l/W > =uqNd > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------------ > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! > Finally, a world-class log management solution at an even better price-free! > Download using promo code Free_Logger_4_Dev2Dev. Offer expires > February 28th, so secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsight-sfd2d > _______________________________________________ > Kdenlive-devel mailing list > Kde...@li... > https://lists.sourceforge.net/lists/listinfo/kdenlive-devel > |
From: Gabriel G. <gab...@gm...> - 2011-01-26 15:32:25
|
regarding not seeing the boundaries, this is really not a problem. and by far compensated by the gains in screen real estate! regarding not seeing the value changing while dragging. well, this IS a problem. I think it should be solved. I don't know if it's already implemented, but it'd be good to have the possibility to apply 'modifiers' (SHIFT / CTRL) to be able to drag more slowly (precisely) / faster, when needed. Other thing than could be added is a right click menu with an option to set the lower and upper limits of the virtual slider. For each parameter, reasonable 'default' values should be set to make this system work as comfortable to the user as possible. Thanks for listening!! Gabriel 2011/1/26 Simon Eugster <sim...@gm...> > Hi Till, > > First of all I like the DragValue widget very much. Let's drop the > sliders as soon as possible to save some space. > > Some ideas: > * I'm not a big friend of nonlinear scales related to my mouse. (But I > know this is a matter of taste.) I find it quite hard to hit a certain > value, when I want to change from 400 to 100 I first shoot ways below > (ok, only to 0) and when I'm at 90 it takes ages to get to 100, so I > move the mouse a little faster and I'm at 140 already. I just have no > feeling for this. My wish would be a linear scale, and perhaps > slightly less sensitive (2 px per click instead of just one). Ideally > the possibility to switch this on/off in the config dialog > (linear/nonlinear) and to use a custom sensitivity. > (Yes, I _do_ know that I can double-click to enter values directly, > but sometimes the mouse is still faster.) > * Another reason why this widget is not as easy to use as the slider > is (I guess) the missing visual boundaries. For the slider you know > when you are at the lowest or highest value (i.e. you can see the > position of the current value relative to the min/max values). I > currently don't have a good idea how to solve this though. > * There are no live updates atm. I'm adjusting the parameter blindly > and will not see the result until I release the mouse button. Please > do not drop the sliders before this works with the DragValue widget as > well :) > > Regarding users, what we can do is let them know about new changes in > the Discover dialog for new releases, in the Changelog, in the > kdenlive blog, perhaps even in the Forums. If a user is too lazy to > read any of these, his bad. (We don't get paid by them … most of them > don't do _anything_ for us.) If a user does not understand the widget > but wants to, he will find a way. > I would not worry about that. > > Simon > > 2011/1/23 Till Theato <ro...@tt...>: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Hi, > > as you might have already noticed I replaced the spin boxes for double > > parameters with a new widget I call "drag value". > > It is a wrapper around QLineEdit (not inherited) and adds the > > possibility to change values using the mouse wheel and most importantly > > by starting to drag horizontal on the widget. This does not only require > > less space than a slider and can be accessed faster than KoSliderCombo > > (spinbox with drop down slider used in the title editor) it is also > > possible to skip large ranges (drag fast) and edit precisely (drag slow) > > at the same time. > > > > It did not invent this type of widget, it is also present in some Adobe > > products (After Effects, Premiere) and in Blender and possibly in other > > software, too. > > However I still doubt whether users will find out how to use it. > > Maybe a horizontal resize cursor? This will cover the value when the > > mouse if over the widget ... > > A blog post won't reach everyone... > > > > Any ideas?? If yes we might also consider dropping the slider for > > parameters. > > > > Another issue I have is the stylesheet. If there are multiple parameters > > the size of the widget decreases with every parameter. > > Have a look at the slope parameters in the SOP/Sat effect, for example, > > since they all have the same range. > > > > regards Till > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.11 (GNU/Linux) > > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > > > iEYEARECAAYFAk08beAACgkQzwEyz7QP6nTwiwCeMZYotvK/hFDeehg3ecn0VqI6 > > T0QAnA8P1p8QREQbpb97OSFvtGnG9l/W > > =uqNd > > -----END PGP SIGNATURE----- > > > > > ------------------------------------------------------------------------------ > > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! > > Finally, a world-class log management solution at an even better > price-free! > > Download using promo code Free_Logger_4_Dev2Dev. Offer expires > > February 28th, so secure your free ArcSight Logger TODAY! > > http://p.sf.net/sfu/arcsight-sfd2d > > _______________________________________________ > > Kdenlive-devel mailing list > > Kde...@li... > > https://lists.sourceforge.net/lists/listinfo/kdenlive-devel > > > > > ------------------------------------------------------------------------------ > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! > Finally, a world-class log management solution at an even better > price-free! > Download using promo code Free_Logger_4_Dev2Dev. Offer expires > February 28th, so secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsight-sfd2d > _______________________________________________ > Kdenlive-devel mailing list > Kde...@li... > https://lists.sourceforge.net/lists/listinfo/kdenlive-devel > |
From: Gabriel G. <gab...@gm...> - 2011-01-26 15:17:43
|
well, what can I say... just see this 2006 Krita request I did here<http://dot.kde.org/2006/09/05/koffice-summer-code-students-deliver-goods>(look for Gabriel Gazzán under comments of the news) :) I just LOVE the adobe-style virtual sliders, so I just LOVE what you've done. Thank you very mucho!!! Gabriel 2011/1/23 Till Theato <ro...@tt...> > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > as you might have already noticed I replaced the spin boxes for double > parameters with a new widget I call "drag value". > It is a wrapper around QLineEdit (not inherited) and adds the > possibility to change values using the mouse wheel and most importantly > by starting to drag horizontal on the widget. This does not only require > less space than a slider and can be accessed faster than KoSliderCombo > (spinbox with drop down slider used in the title editor) it is also > possible to skip large ranges (drag fast) and edit precisely (drag slow) > at the same time. > > It did not invent this type of widget, it is also present in some Adobe > products (After Effects, Premiere) and in Blender and possibly in other > software, too. > However I still doubt whether users will find out how to use it. > Maybe a horizontal resize cursor? This will cover the value when the > mouse if over the widget ... > A blog post won't reach everyone... > > Any ideas?? If yes we might also consider dropping the slider for > parameters. > > Another issue I have is the stylesheet. If there are multiple parameters > the size of the widget decreases with every parameter. > Have a look at the slope parameters in the SOP/Sat effect, for example, > since they all have the same range. > > regards Till > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk08beAACgkQzwEyz7QP6nTwiwCeMZYotvK/hFDeehg3ecn0VqI6 > T0QAnA8P1p8QREQbpb97OSFvtGnG9l/W > =uqNd > -----END PGP SIGNATURE----- > > > ------------------------------------------------------------------------------ > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! > Finally, a world-class log management solution at an even better > price-free! > Download using promo code Free_Logger_4_Dev2Dev. Offer expires > February 28th, so secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsight-sfd2d > _______________________________________________ > Kdenlive-devel mailing list > Kde...@li... > https://lists.sourceforge.net/lists/listinfo/kdenlive-devel > |
From: Till T. <ro...@tt...> - 2011-01-26 22:37:51
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/26/2011 04:08 PM, Gabriel Gazzán wrote: > regarding not seeing the boundaries, this is really not a problem. and by > far compensated by the gains in screen real estate! > > regarding not seeing the value changing while dragging. well, this IS a > problem. I think it should be solved. It was already working this way. What Simon meant was that while dragging the video was not updated (only after mouse release). In r5354 I added a context menu with the actions "direct update" and "nonlinear scale". Both settings will be applied to all drag value widgets when changed. > I don't know if it's already implemented, but it'd be good to have the > possibility to apply 'modifiers' (SHIFT / CTRL) to be able to drag more > slowly (precisely) / faster, when needed. Also added in r5354. CTRL: speed up, factor 2 SHIFT: slow down, factor 2 (1/2) > > Other thing than could be added is a right click menu with an option to set > the lower and upper limits of the virtual slider. For each parameter, > reasonable 'default' values should be set to make this system work as > comfortable to the user as possible. Not sure what exactly you mean here. > > Thanks for listening!! Thanks for the good ideas Gabriel and Simon. Btw, Simon there is no need to double click. The edit area is activated on mouse release if the value was not changed by dragging (the mouse position did not change, or only a little). > Gabriel > > > > 2011/1/26 Simon Eugster <sim...@gm...> > >> Hi Till, >> >> First of all I like the DragValue widget very much. Let's drop the >> sliders as soon as possible to save some space. >> >> Some ideas: >> * I'm not a big friend of nonlinear scales related to my mouse. (But I >> know this is a matter of taste.) I find it quite hard to hit a certain >> value, when I want to change from 400 to 100 I first shoot ways below >> (ok, only to 0) and when I'm at 90 it takes ages to get to 100, so I >> move the mouse a little faster and I'm at 140 already. I just have no >> feeling for this. My wish would be a linear scale, and perhaps >> slightly less sensitive (2 px per click instead of just one). Ideally >> the possibility to switch this on/off in the config dialog >> (linear/nonlinear) and to use a custom sensitivity. >> (Yes, I _do_ know that I can double-click to enter values directly, >> but sometimes the mouse is still faster.) >> * Another reason why this widget is not as easy to use as the slider >> is (I guess) the missing visual boundaries. For the slider you know >> when you are at the lowest or highest value (i.e. you can see the >> position of the current value relative to the min/max values). I >> currently don't have a good idea how to solve this though. >> * There are no live updates atm. I'm adjusting the parameter blindly >> and will not see the result until I release the mouse button. Please >> do not drop the sliders before this works with the DragValue widget as >> well :) >> >> Regarding users, what we can do is let them know about new changes in >> the Discover dialog for new releases, in the Changelog, in the >> kdenlive blog, perhaps even in the Forums. If a user is too lazy to >> read any of these, his bad. (We don't get paid by them … most of them >> don't do _anything_ for us.) If a user does not understand the widget >> but wants to, he will find a way. >> I would not worry about that. >> >> Simon >> >> 2011/1/23 Till Theato <ro...@tt...>: > Hi, > as you might have already noticed I replaced the spin boxes for double > parameters with a new widget I call "drag value". > It is a wrapper around QLineEdit (not inherited) and adds the > possibility to change values using the mouse wheel and most importantly > by starting to drag horizontal on the widget. This does not only require > less space than a slider and can be accessed faster than KoSliderCombo > (spinbox with drop down slider used in the title editor) it is also > possible to skip large ranges (drag fast) and edit precisely (drag slow) > at the same time. > > It did not invent this type of widget, it is also present in some Adobe > products (After Effects, Premiere) and in Blender and possibly in other > software, too. > However I still doubt whether users will find out how to use it. > Maybe a horizontal resize cursor? This will cover the value when the > mouse if over the widget ... > A blog post won't reach everyone... > > Any ideas?? If yes we might also consider dropping the slider for > parameters. > > Another issue I have is the stylesheet. If there are multiple parameters > the size of the widget decreases with every parameter. > Have a look at the slope parameters in the SOP/Sat effect, for example, > since they all have the same range. > > regards Till -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1AYzcACgkQzwEyz7QP6nRz6QCg2LVDhMnZpIhXrUvFhJbT2vWS Fz0AoJDqgRSm9pDY4nT6jKyYtZoHmEFv =sBK0 -----END PGP SIGNATURE----- |
From: Gabriel G. <gab...@gm...> - 2011-01-27 04:12:47
|
2011/1/26 Till Theato <ro...@tt...> > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 01/26/2011 04:08 PM, Gabriel Gazzán wrote: > > regarding not seeing the boundaries, this is really not a problem. and by > > far compensated by the gains in screen real estate! > > > > regarding not seeing the value changing while dragging. well, this IS a > > problem. I think it should be solved. > > It was already working this way. > What Simon meant was that while dragging the video was not updated (only > after mouse release). > In r5354 I added a context menu with the actions "direct update" and > "nonlinear scale". Both settings will be applied to all drag value > widgets when changed. > Sorry, it's that I couldn't see it in action yet. Could anyone post a screenshot to see what the UI looks like? (thx!) > > I don't know if it's already implemented, but it'd be good to have the > > possibility to apply 'modifiers' (SHIFT / CTRL) to be able to drag more > > slowly (precisely) / faster, when needed. > > Also added in r5354. > CTRL: speed up, factor 2 > SHIFT: slow down, factor 2 (1/2) > Great! Well done! :) > Other thing than could be added is a right click menu with an option to > set > > the lower and upper limits of the virtual slider. For each parameter, > > reasonable 'default' values should be set to make this system work as > > comfortable to the user as possible. > > Not sure what exactly you mean here. > Well, in some Adobe programs like After Effects when you right click over a parameter value you see a menu entry "Edit Value...". Selecting this option opens a dialog letting you redefine the default span of values the user is allowed to interactively drag this parameter into. The programmer sets this span to what he believes is the useful range of values for that parameter, but if the user needs to go past that span, then he can change that from within this menu (or he could simply enter numerically a greater or lower value directly, of course). This is sometimes handy when the useful values are within a very narrow range (say, 0 to 0.1) or so and then even pressing SHIFT to drag slowly isn't enough. Greetings! g |
From: Alexandre P. <ale...@gm...> - 2011-01-27 02:03:09
|
On 1/26/11, Simon Eugster wrote: > Hi Till, > > First of all I like the DragValue widget very much. Let's drop the > sliders as soon as possible to save some space. I, on the contrary, happen to hate it :) The new widget gives absolutely no clue neither how to change value, nor what is min/max value and where exactly regarding min/max the value currently is. Krita team seems to have implemented a very cool widget for 2.3 that combines a label and a slider, so you can: - have a more compact UI, because you don't need to place a label and a slider next to each other - see where you are now re min/max values - still have numeric input Not knowing possible range of values is so frustrating that I grit my teeth every time I use live path effects in Inkscape. Pretty please let's not repeat this mistake in Kdenlive. Alexandre Prokoudine http://libregraphicsworld.org |
From: Gabriel G. <gab...@gm...> - 2011-01-27 04:18:30
|
On After Effects there is a small triangle to the left of each parameter name. If a user wants to use a visual slider, then he can click on that triangle (it rotates to point downwards) and below the parameter value it appears a visual slider. That seems to be an option for keeping both methods but save screen space. I haven't seen this new Krita widget yet, can you point me to a screenshot showing it? Thanks! g 2011/1/27 Alexandre Prokoudine <ale...@gm...> > On 1/26/11, Simon Eugster wrote: > > Hi Till, > > > > First of all I like the DragValue widget very much. Let's drop the > > sliders as soon as possible to save some space. > > I, on the contrary, happen to hate it :) > > The new widget gives absolutely no clue neither how to change value, > nor what is min/max value and where exactly regarding min/max the > value currently is. > > Krita team seems to have implemented a very cool widget for 2.3 that > combines a label and a slider, so you can: > > - have a more compact UI, because you don't need to place a label and > a slider next to each other > - see where you are now re min/max values > - still have numeric input > > Not knowing possible range of values is so frustrating that I grit my > teeth every time I use live path effects in Inkscape. Pretty please > let's not repeat this mistake in Kdenlive. > > Alexandre Prokoudine > http://libregraphicsworld.org > > > ------------------------------------------------------------------------------ > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! > Finally, a world-class log management solution at an even better > price-free! > Download using promo code Free_Logger_4_Dev2Dev. Offer expires > February 28th, so secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsight-sfd2d > _______________________________________________ > Kdenlive-devel mailing list > Kde...@li... > https://lists.sourceforge.net/lists/listinfo/kdenlive-devel > |
From: Alexandre P. <ale...@gm...> - 2011-01-27 04:42:46
|
On 1/27/11, Gabriel Gazzán wrote: > On After Effects there is a small triangle to the left of each parameter > name. If a user wants to use a visual slider, then he can click on that > triangle (it rotates to point downwards) and below the parameter value it > appears a visual slider. Yes, it comes from Photoshop initially. But it's not exactly tablet friendly :) > I haven't seen this new Krita widget yet, can you point me to a screenshot > showing it? > Thanks! Don't have it around, but it should be something in the lines of: http://mmiworks.net/test/small.png (a prototype by usability guy who worked with them) Alexandre Prokoudine http://libregraphicsworld.org |
From: jb <jb...@kd...> - 2011-01-27 21:53:28
Attachments:
widget.jpeg
|
On Thursday 27 January 2011 05:42:39 Alexandre Prokoudine wrote: > > I haven't seen this new Krita widget yet, can you point me to a > > screenshot showing it? > > Thanks! > > Don't have it around, but it should be something in the lines of: > > http://mmiworks.net/test/small.png The current KOffice implementation is not really efficient in my opinion. It does not support mouse wheel, nor direct value input through keyboard, and the up/down arrow are too small to be useful. About Till's current widget, I also find it disturbing not to see the boundaries, user has no idea whether the max value is 100 or 6000. Also, I prefer linear scale when dragging, but it's not really useful when you need to scroll from 0 to 6000 (yes, some effects have that value range) - you would need to drag 6 times your whole monitor width to go to the may value... After thinking a bit about it, I posted a screenshot showing a possible widget that might come around the limitations noted above. You can see a mockup at: http://kdenlive.org/images/widget_idea.png However I have no idea how hard it would be to implement it, I only thought about the design for the moment. regards jb |
From: Alexandre P. <ale...@gm...> - 2011-01-27 22:51:11
Attachments:
gimp-widget.png
|
On 1/28/11, jb wrote: > The current KOffice implementation is not really efficient in my opinion. It > does not support mouse wheel, nor direct value input through keyboard, > and the up/down arrow are too small to be useful. > > About Till's current widget, I also find it disturbing not to see the > boundaries, user has no idea whether the max value is 100 or 6000. Also, I > prefer linear scale when dragging, but it's not really useful when you need > to scroll from 0 to 6000 (yes, some effects have that value range) - you > would need to drag 6 times your whole monitor width to go to the may > value... > > After thinking a bit about it, I posted a screenshot showing a possible > widget that might come around the limitations noted above. You can see > a mockup at: > > http://kdenlive.org/images/widget_idea.png > > However I have no idea how hard it would be to implement it, I only > thought about the design for the moment. I'm not too sure about the value after spinbox: it makes the widget look a bit busy. Attached is what GIMP currently has in Git master (well, had, because in newer builds every line has Reset buttons now, IIRC). It's not the final design, but rather close to it, as far as I can tell. I also did a video a couple of months ago to demo how the new widget feels: http://vimeo.com/16616760 Alexandre Prokoudine http://libregraphicsworld.org |
From: Gabriel G. <gab...@gm...> - 2011-01-27 23:00:32
|
All contributions are good, without a doubt, and all the ideas presented here have good points. I tend to favor the solution that allows the "controls part" of the interface to be the smallest possible of all, provided it has good usability, naturally. Of them all, I still think the Adobe style sliders are the ones that are better. They provide interactive dragging functionality, they provide direct numeric input and they are the smallest possible expression of a widget. But perhaps most of all, they are extensively proven and familiar to all professional, semi professional and amateur graphics designers, video editors and post producers worldwide that use any Adobe program (and they are a LOT), so we're making them feel at home in Kdenlive. I personally have used extensively this kind of widget and I long for it in every other program I also use. They are so useful and so efficient that I seriously wonder myself, how is that all the other programs haven't implemented it yet!! Regarding the lack of limits awarenes while dragging, this doesn't seem to affect the ability to drag at all. Moreover, there are parameters that doesn't have limits at all, like a position coordinate or a rotation, for example... Regarding the current Kdenlive implementation shown in 'jb' mockup, I like it!! well done!! :) I'd just remove (or hide) the slider by default (perhaps giving the chance to bring it back with an option in the program Preferences) Another thing I'd remove from sight are the Reset icon, substituting it with a 'right click option' over the numeric value. In my opinion anything that allows the UI to devote more size to the actual video and timeline and less to any other controls is a good thing! (I'd of course also hide the top buttons bar by default, and perhaps place a Render button in the already present bottom toolbar to save more space. But that's for another discussion ;) Well, just my 0,0001 cent Gabriel 2011/1/27 jb <jb...@kd...> > On Thursday 27 January 2011 05:42:39 Alexandre Prokoudine wrote: > > > I haven't seen this new Krita widget yet, can you point me to a > > > screenshot showing it? > > > Thanks! > > > > Don't have it around, but it should be something in the lines of: > > > > http://mmiworks.net/test/small.png > > The current KOffice implementation is not really efficient in my opinion. > It does > not support mouse wheel, nor direct value input through keyboard, and the > up/down arrow are too small to be useful. > > About Till's current widget, I also find it disturbing not to see the > boundaries, user has no idea whether the max value is 100 or 6000. Also, I > prefer linear scale when dragging, but it's not really useful when you need > to > scroll from 0 to 6000 (yes, some effects have that value range) - you would > need to drag 6 times your whole monitor width to go to the may value... > > After thinking a bit about it, I posted a screenshot showing a possible > widget > that might come around the limitations noted above. You can see a mockup > at: > > http://kdenlive.org/images/widget_idea.png > > However I have no idea how hard it would be to implement it, I only thought > about the design for the moment. > > regards > jb > > > > ------------------------------------------------------------------------------ > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! > Finally, a world-class log management solution at an even better > price-free! > Download using promo code Free_Logger_4_Dev2Dev. Offer expires > February 28th, so secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsight-sfd2d > _______________________________________________ > Kdenlive-devel mailing list > Kde...@li... > https://lists.sourceforge.net/lists/listinfo/kdenlive-devel > > |
From: Till T. <ro...@tt...> - 2011-01-30 22:10:02
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/27/2011 11:57 PM, Gabriel Gazzán wrote: > All contributions are good, without a doubt, and all the ideas presented > here have good points. > I tend to favor the solution that allows the "controls part" of the > interface to be the smallest possible of all, provided it has good > usability, naturally. > Of them all, I still think the Adobe style sliders are the ones that are > better. > They provide interactive dragging functionality, they provide direct numeric > input and they are the smallest possible expression of a widget. But perhaps > most of all, they are extensively proven and familiar to all professional, > semi professional and amateur graphics designers, video editors and post > producers worldwide that use any Adobe program (and they are a LOT), so > we're making them feel at home in Kdenlive. > > I personally have used extensively this kind of widget and I long for it in > every other program I also use. They are so useful and so efficient that I > seriously wonder myself, how is that all the other programs haven't > implemented it yet!! > > Regarding the lack of limits awarenes while dragging, this doesn't seem to > affect the ability to drag at all. Moreover, there are parameters that > doesn't have limits at all, like a position coordinate or a rotation, for > example... > > Regarding the current Kdenlive implementation shown in 'jb' mockup, I like Not implemented yet. > it!! well done!! :) > I'd just remove (or hide) the slider by default (perhaps giving the chance > to bring it back with an option in the program Preferences) > Another thing I'd remove from sight are the Reset icon, substituting it with > a 'right click option' over the numeric value. > > In my opinion anything that allows the UI to devote more size to the actual > video and timeline and less to any other controls is a good thing! > (I'd of course also hide the top buttons bar by default, and perhaps place a > Render button in the already present bottom toolbar to save more space. But > that's for another discussion ;) Why not use the Ctrl + Enter shortcut ? ;) > > Well, just my 0,0001 cent > I will try to improve the widget soon but I'm a bit busy at the moment. Of course if someone else is willing to have a look at it that would be totally awesome. regards Till > Gabriel > > > > > 2011/1/27 jb <jb...@kd...> > >> On Thursday 27 January 2011 05:42:39 Alexandre Prokoudine wrote: >>>> I haven't seen this new Krita widget yet, can you point me to a >>>> screenshot showing it? >>>> Thanks! >>> >>> Don't have it around, but it should be something in the lines of: >>> >>> http://mmiworks.net/test/small.png >> >> The current KOffice implementation is not really efficient in my opinion. >> It does >> not support mouse wheel, nor direct value input through keyboard, and the >> up/down arrow are too small to be useful. >> >> About Till's current widget, I also find it disturbing not to see the >> boundaries, user has no idea whether the max value is 100 or 6000. Also, I >> prefer linear scale when dragging, but it's not really useful when you need >> to >> scroll from 0 to 6000 (yes, some effects have that value range) - you would >> need to drag 6 times your whole monitor width to go to the may value... >> >> After thinking a bit about it, I posted a screenshot showing a possible >> widget >> that might come around the limitations noted above. You can see a mockup >> at: >> >> http://kdenlive.org/images/widget_idea.png >> >> However I have no idea how hard it would be to implement it, I only thought >> about the design for the moment. >> >> regards >> jb >> >> >> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1F4fMACgkQzwEyz7QP6nTBtQCgtl4kBq1I7oD/hMtButu8+pMD MfYAoJwKg30lyrMSJQpQH0uhSQUwJ/ss =8pWL -----END PGP SIGNATURE----- |
From: Gabriel G. <gab...@gm...> - 2011-01-30 22:43:37
|
Hi Till, > Regarding the current Kdenlive implementation shown in 'jb' mockup, I like > > it!! well done!! :) > > > Not implemented yet. > What I said I liked, was the part of the image that it's suposed to be the 'current' Kdenlive drag value, not what the mockup proposed ;) > > I'd just remove (or hide) the slider by default (perhaps giving the > chance > > to bring it back with an option in the program Preferences) > > Another thing I'd remove from sight are the Reset icon, substituting it > with > > a 'right click option' over the numeric value. > > > > In my opinion anything that allows the UI to devote more size to the > actual > > video and timeline and less to any other controls is a good thing! > > (I'd of course also hide the top buttons bar by default, and perhaps > place a > > Render button in the already present bottom toolbar to save more space. > But > > that's for another discussion ;) > > Why not use the Ctrl + Enter shortcut ? ;) > Yes, of course keyboard shortcuts are the best way to use any program. I refered to that as a way to hide the top toolbar by defaul, but still have the render button visible to new users. :) Thanks for your efforts!! Gabriel |
From: Simon E. <sim...@gm...> - 2011-01-31 07:56:22
|
2011/1/30 Gabriel Gazzán <gab...@gm...>: >> > I'd just remove (or hide) the slider by default (perhaps giving the >> > chance >> > to bring it back with an option in the program Preferences) >> > Another thing I'd remove from sight are the Reset icon, substituting it >> > with >> > a 'right click option' over the numeric value. Nice idea btw. >> > In my opinion anything that allows the UI to devote more size to the >> > actual >> > video and timeline and less to any other controls is a good thing! >> > (I'd of course also hide the top buttons bar by default, and perhaps >> > place a >> > Render button in the already present bottom toolbar to save more space. >> > But >> > that's for another discussion ;) >> >> Why not use the Ctrl + Enter shortcut ? ;) > > Yes, of course keyboard shortcuts are the best way to use any program. I > refered to that as a way to hide the top toolbar by defaul, but still have > the render button visible to new users. :) Just a short remark; I personally would not expect it to be Ctrl-Enter. Fullscreen shortcuts I've seen so far are Alt+Enter (DOS and some games, still today), F11 (Firefox, several other programs), and Shift-Ctrl-F (Not very sure where; perhaps Okular). Ctrl+Enter is, for me, rather a «confirm this dialog now since Enter is used inside the dialog already» shortcut (e.g. titler would be a candidate for this). Simon |
From: Gabriel G. <gab...@gm...> - 2011-01-31 12:16:40
|
Just to bring some background info over the table: In PremierePro 'Ctrl + Enter' is used to build a Preview*** of the transitions and effects so that the timeline can play faster if there are heavy processing applied to clips. Also in Premiere Pro and After Effects the Export Movie (rendering) feature is 'Ctrl + M' In various 3D animation programs 'F9' is used as a shortcut for Rendering. ** basically small clips for the transitions are generated 'under the hood' and saved to disk, then used in place of the transitions. for clips with effects, the full clip is rendered and substituted (for playback purposes only). when a change happens in the timeline for a transition or an effect, the corresponding preview clip gets outdated and discarded. i.e. a new one has to be generated if the user wants it to. * Greetings, g 2011/1/31 Simon Eugster <sim...@gm...> > >> > In my opinion anything that allows the UI to devote more size to the > >> > actual > >> > video and timeline and less to any other controls is a good thing! > >> > (I'd of course also hide the top buttons bar by default, and perhaps > >> > place a > >> > Render button in the already present bottom toolbar to save more > space. > >> > But > >> > that's for another discussion ;) > >> > >> Why not use the Ctrl + Enter shortcut ? ;) > > > > Yes, of course keyboard shortcuts are the best way to use any program. I > > refered to that as a way to hide the top toolbar by defaul, but still > have > > the render button visible to new users. :) > > > Just a short remark; I personally would not expect it to be > Ctrl-Enter. Fullscreen shortcuts I've seen so far are Alt+Enter (DOS > and some games, still today), F11 (Firefox, several other programs), > and Shift-Ctrl-F (Not very sure where; perhaps Okular). > > Ctrl+Enter is, for me, rather a «confirm this dialog now since Enter > is used inside the dialog already» shortcut (e.g. titler would be a > candidate for this). > > Simon > > > ------------------------------------------------------------------------------ > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! > Finally, a world-class log management solution at an even better > price-free! > Download using promo code Free_Logger_4_Dev2Dev. Offer expires > February 28th, so secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsight-sfd2d > _______________________________________________ > Kdenlive-devel mailing list > Kde...@li... > https://lists.sourceforge.net/lists/listinfo/kdenlive-devel > |
From: jb <jb...@kd...> - 2011-02-02 23:07:55
|
On Sunday 30 January 2011 23:11:00 Till Theato wrote: > I will try to improve the widget soon but I'm a bit busy at the moment. > Of course if someone else is willing to have a look at it that would be > totally awesome. > > regards Till I spent some time on it and here is what I came with: http://kdenlive.org/images/new_slider.jpeg I took your widget and added a label with background showing the value. You can drag the value on the label like a slider, and manually enter a value by clicking on the number. I kept the context menu that allows to choose between 3 modes: - Normal scale, means the value will follow your mouse cursor position on the label - Pixel scale means one pixel will increment from one point - Non linear works as before. The reset icon can also probably be moved to the context menu. What do you think about it? I can commit my changes if you think it's going in the right direction. Regards jb |
From: Dan D. <da...@de...> - 2011-02-03 00:03:53
|
On Wed, Feb 2, 2011 at 3:07 PM, jb <jb...@kd...> wrote: > On Sunday 30 January 2011 23:11:00 Till Theato wrote: > >> I will try to improve the widget soon but I'm a bit busy at the moment. >> Of course if someone else is willing to have a look at it that would be >> totally awesome. >> >> regards Till > > I spent some time on it and here is what I came with: > > http://kdenlive.org/images/new_slider.jpeg > > I took your widget and added a label with background showing the value. You > can drag the value on the label like a slider, and manually enter a value by > clicking on the number. My impression is that the numbers appearing like a label looks odd, like it is read-only. Why not include a frame that makes it look like an editable field? (And, no, I do not like hashed underlines!) I dunno - just a though from my gut reaction. Others please voice opinion. > I kept the context menu that allows to choose between > 3 modes: > > - Normal scale, means the value will follow your mouse cursor position on the > label > - Pixel scale means one pixel will increment from one point > - Non linear works as before. > > The reset icon can also probably be moved to the context menu. yes, considering the reset icon and radio button are repeated for each, it does look cluttered. > What do you think about it? I can commit my changes if you think it's going in > the right direction. > > Regards > jb > > > ------------------------------------------------------------------------------ > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! > Finally, a world-class log management solution at an even better price-free! > Download using promo code Free_Logger_4_Dev2Dev. Offer expires > February 28th, so secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsight-sfd2d > _______________________________________________ > Kdenlive-devel mailing list > Kde...@li... > https://lists.sourceforge.net/lists/listinfo/kdenlive-devel > -- +-DRD-+ |
From: jb <jb...@kd...> - 2011-02-08 12:33:31
|
Hello! Here is the result of my last work on the widget: http://kdenlive.org/images/new_slider1.jpeg The label works like a slider, and the box with numbers is editable. Reset value and show in timeline are now in the context menu, the parameter shown in timeline is drawn in a darker color to make is visible. Almost ready to commit if ok for you. The widget appareance will not change whatever theme you use, because we really want to have the smallest possible widget for this, so the decoration is minimal. regards jb |
From: Gabriel G. <gab...@gm...> - 2011-02-08 15:11:32
|
To be honest, I still find it distracting and visually heavy. Perhaps if the background colored slider part only appeared when a user is dragging it'd be much more easy on the eye and still retain functionality. If you are to leave it as it is, then I definitely would invert the colors, making darker all other values but the shown in timeline one. Also I don't find it neccessary to give the value numbers a different background. This contributes to the heaviness of the interface look as there are usually lots of parameters on display. I think if we want to indicate the user that these values accept input, we could just change the color of the value (text, not its background) when the mouse pointer is hovering it. This should be enough for telling him/her that "something happens" with that value. Regarding the "show in timeline" option, I'm thinking that it'd be useful to also have a faster way of setting it, besides the right click menu. Perhaps Ctrl + click, Shift + click, Alt + click (or any combination) over the parameter to make it the shown one. Thank you for your hard work and your time!! Gabriel 2011/2/8 jb <jb...@kd...> > Hello! > > Here is the result of my last work on the widget: > > http://kdenlive.org/images/new_slider1.jpeg > > The label works like a slider, and the box with numbers is editable. Reset > value and show in timeline are now in the context menu, the parameter shown > in > timeline is drawn in a darker color to make is visible. > > Almost ready to commit if ok for you. The widget appareance will not change > whatever theme you use, because we really want to have the smallest > possible > widget for this, so the decoration is minimal. > > regards > jb > > > > > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > _______________________________________________ > Kdenlive-devel mailing list > Kde...@li... > https://lists.sourceforge.net/lists/listinfo/kdenlive-devel > |
From: Simon E. <sim...@gm...> - 2011-02-08 16:52:23
|
2011/2/3 Gabriel Gazzán <gab...@gm...>: > 2011/2/3 Simon Eugster <sim...@gm...> >> But couldn't we optimize the Effect Stack widget as well? Take a look >> at the screenshot above; Half of the space is empty. >> I did a quick sketch, which took about 100 times as long as it should >> have because of the packed unintuitivity in GIMP: >> http://granjow.net/uploads/kdenlive/kdenlive-effect-stack.png >> * Effect Stack list moved to the top, taking only as much room as required >> * Arrow indicating which effect is applied first >> * Reset icon and Radiobuttons removed >> * Parameters can flow side-by-side > > I'm all for saving space (used by controls) on every place we can. > I see a problem though with the arrange of the effect stack and the selected > effect parameters seen in kdenlive-effect-stack.png: > - the effect stack area would tend to require big horizontal room to be > comfortable used/understood. http://granjow.net/uploads/kdenlive/kdenlive-effect-stack-2line.png I want to highlight that it is also possible to make controls _too_ small. They just _do_ require space. Video Editing tends to use more space than other applications, like for example a web browser, this is just a fact. You won't get anywhere with 800x600, for example. Let's not make the error to minimize controls until they cannot be controlled anymore. Simplify yes, but not on the costs of comfort. > - the selected effect parameters area would adapt well to this wide > proportion, no doubt, BUT > - where do we place the panel then? Now, placed behind the Project Tree and > beside the monitor panel, the space we have for that panel is usually more > taller than wide, not the opposite. I don't think devoting more horizontal > space to the effects stack/parameters is a good thing. On my screen I've got plenty of space :P http://kdenlive.org/sites/default/files/images/kdenlive-layout-editing.png > To me After Effects effects stack has the answer for this as well. > http://www.rtraction.com/blog/wp-content/uploads/2009/05/vine-2.gif Collapsible parameters and scroll bars, death of fluent working. > This image shows two effects (named Stroke and Stroke 2), each one showing > its parameters. > The effect has a control in the form of a little triangle to the left of > each effect name (but could be + - signs of course) to expand/collapse the > effect parameter visibility. > This way, we could not only get rid of the current two column arrangement > [effects | parameters of selected effect], but also be able to do something > we cannot currently do: tweak at the same time parameters of several > (expanded) effects! I agree that changing multiple parameters at the same time can be useful. 2011/2/8 Gabriel Gazzán <gab...@gm...>: > To be honest, I still find it distracting and visually heavy. > Perhaps if the background colored slider part only appeared when a user is > dragging it'd be much more easy on the eye and still retain functionality. > If you are to leave it as it is, then I definitely would invert the colors, > making darker all other values but the shown in timeline one. If you mean that there would be no visual clue anymore, except for the value number, when not in mouse-over, then I'm completely against it. I cannot stand controls which disappear as soon as the mouse leaves. But could perhaps all value fields set to the same width? Atm the Offset values are wider than the others (perhaps due to the range); having them all aligned would make the interface look a little more tidy. > Also I don't find it neccessary to give the value numbers a different > background. This contributes to the heaviness of the interface look as there > are usually lots of parameters on display. Here I agree :) > I think if we want to indicate the user that these values accept input, we > could just change the color of the value (text, not its background) when the > mouse pointer is hovering it. This should be enough for telling him/her that > "something happens" with that value. > > Regarding the "show in timeline" option, I'm thinking that it'd be useful to > also have a faster way of setting it, besides the right click menu. Perhaps > Ctrl + click, Shift + click, Alt + click (or any combination) over the > parameter to make it the shown one. Or just click on the number? This would as well not change the value. Looks pretty cool, please commit as soon as possible, jb :) Simon |
From: Gabriel G. <gab...@gm...> - 2011-02-08 17:14:39
|
2011/2/8 Simon Eugster <sim...@gm...> > > http://granjow.net/uploads/kdenlive/kdenlive-effect-stack-2line.png > > I want to highlight that it is also possible to make controls _too_ > small. They just _do_ require space. Video Editing tends to use more > space than other applications, like for example a web browser, this is > just a fact. You won't get anywhere with 800x600, for example. > Let's not make the error to minimize controls until they cannot be > controlled anymore. Simplify yes, but not on the costs of comfort. > > On my screen I've got plenty of space :P > http://kdenlive.org/sites/default/files/images/kdenlive-layout-editing.png > Well, to be honest, you seem to have lots of space at this resolution, but you're not using it to be more productive either. You just have lots of blank spaces here and there (I'm talking of the upper left panel of the interface, of course, the rest is ok) If this "Transition panel" required less space, perhaps you could have another panel opened to the left at the same time (Project Tree, Vectorscope, whatever...) > > To me After Effects effects stack has the answer for this as well. > > http://www.rtraction.com/blog/wp-content/uploads/2009/05/vine-2.gif > > Collapsible parameters and scroll bars, death of fluent working. > That should be the main cause of After Effects having failed miserably as a commercial product all these years. ;) > Regarding the "show in timeline" option, I'm thinking that it'd be useful > to > > also have a faster way of setting it, besides the right click menu. > Perhaps > > Ctrl + click, Shift + click, Alt + click (or any combination) over the > > parameter to make it the shown one. > > Or just click on the number? This would as well not change the value. > Aren't the numbers editable uppon clicking on them? Regards, g |
From: Simon E. <sim...@gm...> - 2011-02-08 18:15:02
|
2011/2/8 Gabriel Gazzán <gab...@gm...>: > > 2011/2/8 Simon Eugster <sim...@gm...> >> >> http://granjow.net/uploads/kdenlive/kdenlive-effect-stack-2line.png >> >> I want to highlight that it is also possible to make controls _too_ >> small. They just _do_ require space. Video Editing tends to use more >> space than other applications, like for example a web browser, this is >> just a fact. You won't get anywhere with 800x600, for example. >> Let's not make the error to minimize controls until they cannot be >> controlled anymore. Simplify yes, but not on the costs of comfort. >> >> On my screen I've got plenty of space :P >> http://kdenlive.org/sites/default/files/images/kdenlive-layout-editing.png > > Well, to be honest, you seem to have lots of space at this resolution, but > you're not using it to be more productive either. > You just have lots of blank spaces here and there (I'm talking of the upper > left panel of the interface, of course, the rest is ok) > If this "Transition panel" required less space, perhaps you could have > another panel opened to the left at the same time (Project Tree, > Vectorscope, whatever...) Yes, I could open plenty other windows. Point is, that does not enhance productivity, at least not for me. Why should I have a vectorscope there? If I do colour correction, I need all scopes anyway and display all of them. I try to put everything away that is not necessary. In order to have maximum size for each widget. Navigation in the Composite is more precise, the Project Tree needs less scrolling and shows more of the file name, and so on. I could also put the Transition and Effect Stack widgets side by side, but I cannot edit a transition and an effect simultaneously anyway, so I stack them (kdenlive automatically displays the correct widget when selecting a clip or a transition). >> > To me After Effects effects stack has the answer for this as well. >> > http://www.rtraction.com/blog/wp-content/uploads/2009/05/vine-2.gif >> >> Collapsible parameters and scroll bars, death of fluent working. > > That should be the main cause of After Effects having failed miserably as a > commercial product all these years. ;) Commercial success does not imply a perfect interface. I would say it is rather the case that After Effects has a little more effects which also are a little better than for example ours. >> > Regarding the "show in timeline" option, I'm thinking that it'd be >> > useful to >> > also have a faster way of setting it, besides the right click menu. >> > Perhaps >> > Ctrl + click, Shift + click, Alt + click (or any combination) over the >> > parameter to make it the shown one. >> >> Or just click on the number? This would as well not change the value. > > Aren't the numbers editable uppon clicking on them? But not changed directly. We could avoid the need to press an additional button. Simon |
From: Gabriel G. <gab...@gm...> - 2011-02-08 18:45:44
|
2011/2/8 Simon Eugster <sim...@gm...> > Yes, I could open plenty other windows. Point is, that does not > enhance productivity, at least not for me. Why should I have a > vectorscope there? If I do colour correction, I need all scopes anyway > and display all of them. > I try to put everything away that is not necessary. In order to have > maximum size for each widget. Navigation in the Composite is more > precise, the Project Tree needs less scrolling and shows more of the > file name, and so on. I could also put the Transition and Effect Stack > widgets side by side, but I cannot edit a transition and an effect > simultaneously anyway, so I stack them (kdenlive automatically > displays the correct widget when selecting a clip or a transition). > I didn't said Effects and Transitions visible side by side. But for example, ProjectTree and Transition options panels opened side by side does makes sense when quickly adding clips to the timeline and transitioning between them. It is clear that Transitions and Effects should probably been one under the other. > >> > To me After Effects effects stack has the answer for this as well. > >> > http://www.rtraction.com/blog/wp-content/uploads/2009/05/vine-2.gif > >> > >> Collapsible parameters and scroll bars, death of fluent working. > > > > That should be the main cause of After Effects having failed miserably as > a > > commercial product all these years. ;) > > Commercial success does not imply a perfect interface. I would say it > is rather the case that After Effects has a little more effects which > also are a little better than for example ours. > No, it does not. And you know what? Premiere has a very similar interface, or at least uses many of the same conecpt that After Effects does, and its workflow for controlling effects or animating various elements on screen is far worse that that of After Effects. The big difference is that After Effects interface allows greater efficiency and flexibility than that of Premiere. That effieciency is given by two main things. One is that you need a really low number of actions to get where you want or to see the parameters you want for editing/animation. The other one is that its interface allows to see lot's of things at the same time. Premiere on the other hand only shows some things simultaneously or requires too many clicks to get where you want, making the workflow suffer. Where Premiere really shines is in the simple editing operations: marking of In/Out Points and get the trimmed clip to the timeline efficiently. But for effects work or animating things on screen it's not efficient at all. That said, I do not expect Kdenlive to be a post production application, of course, but being efficient in screen space use will not hurt by any means. After Effects way of showing parameters is the best and most productive way of handling parameter values and presentation I've seen so far. (I've used a lot of graphics related programs out there to a great extent and my conclusion favors the After Effects way. I'm certified instructor of 3ds Max, Maya, After Effects and Premiere, I've used Lightwave, Photohsop, GIMP, Krita, I'm here since the Amiga days and expecienced many many kind of programs all these years.) This is not to say you can't have a different (and better) opinion than me, but just to say that I've really experienced what I'm sustaining here as a good option, and why I know it really workes well. >> > Regarding the "show in timeline" option, I'm thinking that it'd be > >> > useful to > >> > also have a faster way of setting it, besides the right click menu. > >> > Perhaps > >> > Ctrl + click, Shift + click, Alt + click (or any combination) over the > >> > parameter to make it the shown one. > >> > >> Or just click on the number? This would as well not change the value. > > > > Aren't the numbers editable uppon clicking on them? > > But not changed directly. We could avoid the need to press an additional > button. > mmm.. I don't understand I think. So what would be the procedure to enter a number by hand? say 385 in a parameter? Thanks!! g |
From: Dan D. <da...@de...> - 2011-02-08 19:02:56
|
2011/2/8 Gabriel Gazzán <gab...@gm...>: > After Effects way of showing parameters is the best and most productive way > of handling parameter values and presentation I've seen so far. (I've used a > lot of graphics related programs out there to a great extent and my > conclusion favors the After Effects way. I'm certified instructor of 3ds > Max, Maya, After Effects and Premiere, I've used Lightwave, Photohsop, GIMP, > Krita, I'm here since the Amiga days and expecienced many many kind of > programs all these years.) > This is not to say you can't have a different (and better) opinion than me, > but just to say that I've really experienced what I'm sustaining here as a > good option, and why I know it really workes well. I think Gabriel's background is very good to have available - assuming honesty ;-). With that said, Gabriel, I ask you to also consider the intermediate user base and not just power-user. Maybe you are, but is what you are suggesting fairly obvious and visually consistent with the KDE/Qt widget designs? I am not claiming your suggestions are not; I have done enough recent analysis of the proposals, but I know for example, that dashed underlines under editable values are fairly obvious but not consistent whereas sunken boxes are both obvious and consistent, if somewhat heavy. -- +-DRD-+ |