
The first tab is to add/remove files.
The second tab (the process) you can add process (like xnview 1.97) in the toolbox, and you can view the result on a picture (from filelist).
What do you think?
Moderators: XnTriq, helmut, xnview
You have already the layout of process layout here????JohnFredC wrote: There are other, more specific, things also needed, but I'll wait to suggest them until we see mockups of the final tab layouts...
No, when you click on the header, the subpanel is opened below (like you can see in my screenshot for resize). I think that it's important to have a picture view to be able to view the result!JohnFredC wrote:How will that process list work?
Does clicking on a "step" header (such as resize) display a subpanel a la the "outlook control" metaphor?
Yes, that's what I thought and I don't recommend it. It is very inefficient for GUI interaction. I've embedded similar controls in my own software in the past and conclude they require too many clicks, too much scrolling. The sliding panel metaphor seems to work much better for toolbar-like requirements. It is not good for settings panels.xnview wrote:No, when you click on the header, the subpanel is opened below (like you can see in my screenshot for resize).
What result are you referring to? Is the entire batch applied in real-time to the "picture view" image so that a change in a setting changes the appearance of the preview? With the large images most of us work with these days, that would be 'way too slow to be useful.I think that it's important to have a picture view to be able to view the result!
That is the way I would do it. Output is a separate component of the batch, has many possible settings (more than show in your example, for instance).You think that output must be in a separate tab??
Yes scrollbar but you have always only ONE setting opened, if you click on 'Rotate', settings for 'Resize' are closed...JohnFredC wrote: What will happen if there are too many settings to fit in the little panel? Require the user to scroll?
Many users want to view the result of their actions, so it's a picture from your filelist. This preview is updated when you want.What result are you referring to? Is the entire batch applied in real-time to the "picture view" image so that a change in a setting changes the appearance of the preview? With the large images most of us work with these days, that would be 'way too slow to be useful.I think that it's important to have a picture view to be able to view the result!
Actions list + settings would be my personal very strong preference.So all actions+settings in a toolbox (like first screenshot) or actions list + settings??
The preview is the result of ALL batch actions. In v1.97, you can't see a preview of actions added...JohnFredC wrote: OTOH, if there are many batch actions in the script, what benefit is there for seeing the "after" of just one action? There would be no relationship to the final output! Indeed, the "After" could be very misleading!
Also, what would you show for Resize or DPI (for instance) in the "after" tab? Some actions have no meaningful "after" preview.
Yes more thoughtMP is an opportunity to finally get this dialog exactly right. No point in rushing the design. The UI needs more thought.
Really!?!xnview wrote:The preview is the result of ALL batch actions. In v1.97, you can't see a preview of actions added...
Some actions can be slowJohnFredC wrote:Well, then, that could be very cool if the rendering was very fast.
You means when you select an action to change some settings? Yes i would like to work like that...If a user selects an action in the list, will the preview show the results at that place in the sequence of actions?
Like this?
If it works this way, then I would be very enthusiastic. Excited, even.
- Click on Action 1 -> Preview shows Action 1 results
Click on Action 2 -> Preview shows Action 1 + Action 2 results
Click on Action 3 -> Preview shows Action 1 + Action 2 + Action 3 results