Yuval Levy wrote:
Hi all
I recall there was some reason to keep the old preview next to the new
one. Is this still the case, or can we forego the old preview and work
with the new one only?
At least on my Laptop (no real 3D, uses Mesa) the fast preview (very) often
scrambles the
Hi Yuv,
I don't like the tabbed palette. This a nothing other than a
**ribbon**. So you could use a wxRibbon in wx3.0. But I don't like
this control, it hides to much controls and you have to continously
changing the tab.
E. g. if you want to change output size and crop. First you go to
image
On Mon 12-Oct-2009 at 07:41 -0700, T. Modes wrote:
Other idea: We could add a menu bar. In this case we could remove
the captions of the buttons and use a button size like the main
window. So we would save a lot of space.
The main window button-bar used to have captions, but they got lost
On Sun 11-Oct-2009 at 21:22 -0400, Yuval Levy wrote:
Bruno Postle wrote:
I don't think there is enough functionality here to justify a tabbed
palette, how much space would all this stuff take up in one frame?
not yet. when the fast preview will become the hub, the tabbed palette
will contain
Hi Thomas,
T. Modes wrote:
I don't like the tabbed palette.
OK, I understood. Consider my mockup dead. It's back to the drawing
board. I gained some interesting insights from these discussions.
Yuv
--~--~-~--~~~---~--~~
You received this message because you
Hi Bruno,
as I said, this mockup is dead. That said...
Bruno Postle wrote:
I'm not excited by this idea that the Preview window will require a
permanent floating toolbox. It will take up screen space wherever
you put it, so this functionality should just be properly integrated
into the
On Mon 12-Oct-2009 at 18:18 -0400, Yuval Levy wrote:
Bruno Postle wrote:
Still not convinced. The tabbed widget has been abused by
Hugin/PTGui to indicate workflow, it really is best when it is used
to indicated different 'aspects' or 'views' of the same object.
agree. and we have strictly
AKS-Gmail-IMAP wrote:
Along the lines of transforming the fast preview into the main base
for the final product composition, the crop feature should be expanded
to include cropping individual images in context with the final product.
there are two different crops: input crop (individual
On Sat, Oct 10, 2009 at 09:07:47PM -0400, Yuval Levy wrote:
initial palette mockup attached. Icons will need to be designed. Have
not thought of full screen mode yet - IMO it is a no brainer and when
the fast preview is the hub it should open full screen only.
I hate programs that think
On Sat, Oct 10, 2009 at 09:07:47PM -0400, Yuval Levy wrote:
... we'll have to get around this. Lukas suggested a second, lower
priority thread (in another ML-thread I have yet to answer). The UI
should be functional / responsive even when the images are not loaded in
the preview, with
Rogier Wolff wrote:
I hate programs that think they are the only one on my computer
me too.
and go full-screen automatically.
me not because I try to do one thing at a time. I find it more
efficient, at least when I'm not interrupted.
- just start up the way the user left it last time.
Rogier Wolff wrote:
Really, showing previews should be almost instantaneous. But why
aren't they?
now this one was an excellent piece of analysis. I agree 100%.
As soon as we get told about an image, we should start off
this is what I tried to approximate with my primitive use of the idle
Hi all,
sorry for stepping in so late, I just would like to stress a few things
that are important to me:
Single buttons for images should definitely stay! They could be more
space saving if desired. They are very important for my workflow to be
easily accessible and visible all at the same
On Fri 09-Oct-2009 at 06:36 -0700, T. Modes wrote:
IMO the (Fast) Preview should become the hub and everything else should
float around it.
Performance! (especially with big projects)
With the current implemtation you can open a big project and start
working. When finish the optimising the
On Sat 10-Oct-2009 at 21:07 -0400, Yuval Levy wrote:
mockup attached. please read the (long, sorry) email addressing most
comments expressed. thanks to everybody who participated in this round
of feedback. if there is enough interest, as the next step I will
implement the attached tabbed palette
Bruno Postle wrote:
I don't think there is enough functionality here to justify a tabbed
palette, how much space would all this stuff take up in one frame?
not yet. when the fast preview will become the hub, the tabbed palette
will contain many more functions.
This needs to be a pop-up
Bruno Postle wrote:
So automatically starting with the Preview could only work if Hugin
loads images in the background and allows full editing, saving and
even quitting before the last photo is opened.
that's the goal. I started reading about threading in wxWidgets.
Yuv
From my perspective, which is mostly a user's view, not a programmer's
view, the fast preview could be enhanced with:
-shortcut keys, especially for the different modes that determine what
the mouse does (crop, drag, identify etc). I've always liked the way
Labview implemented this (though you
Along the lines of transforming the fast preview into the main base
for the final product composition, the crop feature should be expanded
to include cropping individual images in context with the final product.
Allan
--~--~-~--~~~---~--~~
You received this
Bruno Postle wrote:
The 'old' Preview is somewhat more accurate, it doesn't have the
problems the Fast Preview sometimes has with images getting
scrambled, but the main thing is that it is currently the only way
to show HDR stacks with tonemapping - It isn't clear that this
could be
On Fri 09-Oct-2009 at 06:48 +0200, Seb Perez-D wrote:
The 'old' Preview is somewhat more accurate, it doesn't have the
problems the Fast Preview sometimes has with images getting
scrambled, but the main thing is that it is currently the only way
to show HDR stacks with tonemapping - It isn't
On Fri 09-Oct-2009 at 02:49 -0400, Yuval Levy wrote:
does this mean that it is unlikely that the accuracy of the Fast Preview
will be improved?
I think it is very dependent on the graphics hardware.
and what was the result of the merger discussion?
..to do it later, after the Layout mode was
On Fri, 2009-10-09 at 09:13 +0100, Bruno Postle wrote:
On Fri 09-Oct-2009 at 02:49 -0400, Yuval Levy wrote:
does this mean that it is unlikely that the accuracy of the Fast Preview
will be improved?
I think it is very dependent on the graphics hardware.
There are a few constants that
how about (STEP 1) merging them visually with one single dropdown,
Output, having three choices: FAST, LDR, HDR. The first one would be in
FP, the other two would be in TP. The non applicable buttons in the
toolbar would be grayed out?
Some points to consider:
Number 1: Currently fast
On Thu 08-Oct-2009 at 17:46 -0400, Yuval Levy wrote:
I recall there was some reason to keep the old preview next to the new
one. Is this still the case, or can we forego the old preview and work
with the new one only?
The 'old' Preview is somewhat more accurate, it doesn't have the
problems
On Thu, Oct 8, 2009 at 23:54, Bruno Postle br...@postle.net wrote:
On Thu 08-Oct-2009 at 17:46 -0400, Yuval Levy wrote:
I recall there was some reason to keep the old preview next to the new
one. Is this still the case, or can we forego the old preview and work
with the new one only?
The
Am Thursday 08 October 2009 schrieb Yuval Levy:
Hi all
I recall there was some reason to keep the old preview next to the new
one. Is this still the case, or can we forego the old preview and work
with the new one only?
The background of my question: I want to continue to move
27 matches
Mail list logo
