Paint & next release

[xnview]

What do you think?
If Paint is not a plugin, it's more easy to integrate it in toolbar, menu, shortcut, ....

[Clo]

—> Pierre

Good evening,

• I voted in favour of the built-in solution, I think it's better, especially if that makes the job easier for you,
and also because I guess it's more flexible.
- It should be in the right way for later, when changing to text files for the languages,
having an internal known usual command number…

KR
Claude
Clo

[Dreamer]

It should be integrated in XnView if possible, it would be much better, intuitive and faster (now we have to do some tasks in xnview viewer window, some in paint window) - and if it's also easier for you, it's clear.

[Drahken]

First off,

(now we have to do some tasks in xnview viewer window, some in paint window)

Correct me if I'm mistaken, but I don't think integrating it would change that. Even just sharpening & color adjusting filters run in a seperate window, and with drawing you have to be able to work on the full image, so the little thumbnail sized preview windows in the filter dialogs wouldn't cut it. If it can be done where thbe dialog just has the controls for line, circle, square, text, etc and you do the drawing in the main image window, that'd be great, but I don't think that's what pierre is talking about.

Assuming that you would still need to do the drawing in the seperate window as you do now, I don't see it making a significant difference to the end user one way or the other. For the most part, it would just change which menu item it appears under.

I couldn't vote in the poll itself because there's no "six of one, half a dozen of the other" option.

[Clo]

—> Drakhen

Hello !

…For the most part, it would just change which menu item it appears under. …

• But that's an important feature from my point of view.

1. Currently, I dislike the location in the Filters menu, that is right technically, but not obvious for the average user…

2. In fact, till now there is no entry in the menu - I mean in the resource-script - this entry appears “dynamically”
when an image is displayed (as far as I understood).
- It's annoying because in a certain case, there is not any entry using another language
than the built-in English, that bores me a lot…
- Like I said prior above, menus as text need normal command-numbers and entries actually written in these menus.

• BTW, yes, options are missing in that poll, like “I don't care” and¦or “I don't know”…

KR
Claude
Clo

[ckit]

I voted "No" but I really don't care as I would use PhotoFiltre Studio for this job.
I treat XnView as a file manager for pictures nothing more

[JohnFredC]

Though some simple form of "paint" in XnView would be OK, there are so many good painting solutions out there (I have and use many of them already) that I question the diversion of valuable developer resources toward a "half" solution that most of us will bypass anyway because: there is no way an XnView painting component could catch up with those tools except years down the road.

I personally would rather see improvements to the user interface in general, to the browser, to the grid, to the compare screen, to the thumbnail customization, to metadata display and management, to the built-in filters and effects, etc, etc, etc, and an implementation of VERSIONING!!!

In lieu of a dedicated painting functionality, perhaps an enhancement to how XnView communicates/integrates with external tools would be a better use of developer resources. For instance, if I open a file shown in XnView into PhotoFiltre and save it there, it would be great if XnView detected that and automatically reloaded the file.

[JohnFredC]

Just continuing with my previous thought. I first discovered XnView years ago and adopted it immediately. It stood out in the crowd of image browsers as uniformly superior. XnView has evolved since then and improved greatly because Pierre has listened to our requests (thank you Pierre!). It is still superior and my "main man", but keep reading.

Because of our requests and the difficult (sometimes conflicting) design decisions that have to be made to accomodate them, XnView 1.9 seems to me to have become a tool in transition from simplicity to complexity. For instance, I think many would agree favorites and categories aren't yet as well integrated as they could be, and the layouts/behaviors need work.

Furthermore, the alternatives available to users (the "competition") are getting better. Most would agree that Fastone is pretty good and Picasa, though addressing a slightly different user base (those less technically oriented), is really an outstanding/incredible piece of free software. I personally use all 3: XnView for file management, FastStone for viewing large images (that magnifier is the ticket!) and Picasa for browsing through my images, categorizing and tweaking them. (I also use LightRoom, LightZone, Photoshop, PSP, PhotoFiltre et al, but that is a different category of function entirely).

So my advice (repeating what I posted above) is to focus on what XnView does best and not try to expand into areas that will drain resources from that. There are only 27 hours in Pierre's day, after all.

[Lesmo16]

There are only 27 hours in Pierre's day, after all.

Yeah, and he spends 125% of the day for xnView!

[Drahken]

Though some simple form of "paint" in XnView would be OK, there are so many good painting solutions out there (I have and use many of them already) that I question the diversion of valuable developer resources toward a "half" solution that most of us will bypass anyway because: there is no way an XnView painting component could catch up with those tools except years down the road.

Xnview shouldn't waste time with a full painting function, it's main function is viewing & converting images, but having a basic paint ability is good. The idea of the basic paint function is to annotate images without having to load up some full blown image editor. Things like highlighting a specific part of a screenshot, or adding a humorless tagline onto a photo.

Still... the paint function as it currently exists serves these purposes just fine, and doesn't need much more tweaking. The only two things I'd like to see added are a freehand drawing tool and to have it work in the main window, just like drawing a selection (although I doubt that'd be possible without a total rewrite of the program, which just wouldn't be worth it).

[Clo]

—> Drahken

Hello !

Xnview shouldn't waste time with a full painting function …

• Nobody asked for “full” painting.
- Only retouch-tools have been requested, and till today, except to draw lines and rectangles-elipses,
the rest was already existing in the main programme.

- So, not a huge time spent at this till now…
- We miss the most basic retouch thingies, and I guess that Pierre opened that poll to know
in which way he'll work to add these simple tools…
- If you don't like retouch-tools in XnView, so don't beat about the bush, let say it frankly.
- There are threads here to discuss the features, this is not the point in that poll.
- I noticed -with bitterness- that another thread¦s (of mine) about “Paint” have been almost ignored…

• Till some months ago, I used the retouchs in UniView, alas for unknown reasons
that programme no longer works here properly in XP…
The author stopped the development, hence I wish to get the equivalent simple tools in XnView, naturally.

KR
Claude
Clo

[Drahken]

Xnview shouldn't waste time with a full painting function …

• Nobody asked for “full” painting.
Clo

Though some simple form of "paint" in XnView would be OK, there are so many good painting solutions out there (I have and use many of them already) that I question the diversion of valuable developer resources toward a "half" solution that most of us will bypass anyway because: there is no way an XnView painting component could catch up with those tools except years down the road.

<--That is what I was responding to.

I think retouching tools really go beyond the scope of what xnview does. It would be better (as mentioned elsewhere in this thread) to improve xnview's integration with other software which is designed specifically for retouching, painting, etc like photobie or photofilter. The current "open with external program" function is half the equation, we just need a simple way to import the image back after it's been edited. Two possible ways to do this would be A ) coordinate with the developers of another prog (ie, have a permanent "export to photobie" option in one of xnview's menus and a corresponding "export to xnview" option in one of photobie's menus) or B ) add some sort of "import from running program" option. I don't know whether or not the second one would be possible, although since the editing prog has to have the current image loaded in the pc's memory, it seems like it should be possible for xnview to scan the active memory for an image file and pull it in (similar to importing from the clipboard).

Just my $0.05 on the matter. (My opinions are worth much more than the measely $0.02 most people charge. )

[Troken]

I say that a basic paint-function would be nice, but personally I would not use it, instead a simple press of "F3" lets me edit the image in my favourite image editing program. Therefore I agree with Drahken, do not waste much time on the paint-function when there is lots of more important stuff on the to-do-list.

[helmut]

Very good pros and cons for integrating the Paint tool so far. From what I can see there are two design styles, an integrative or separative design:

Integrative design
The integrative design allows the user to have all functionality at hand, i.e. he/she can do whatever he/she likes and can start any functionality with one or maximum two clicks. There's no such things as modes.

Pros:
+ Fast to use (once customized properly)

Cons:
- Lots of functionality at users hand, makes usage more complex.
- Application needs some customization, without customization it's likely to be too complex.

Separative design with modes
In the separative design the user starts a specific task/use case. Such as task can be Paint, Cropping, Image correction, Red eye correction, or Image effects, for example. After having started a specific task, only functionality needed to perform this task is provided, e.g. Zooming, setting parameters, preview, ...). Once the user finishes the task, he/she can start the next task/use case.

Pros:
+ Easier to use because user can be supported when performing a specific use case. E.g. during use case "Cropping", parameters for cropping could be shown and non-selected area could be darkened.

I've just listed some few pros and cons. I think the main target of XnView should remain a simple and easy to use interface. The core functionality of XnView which is browsing&file management, converting, and viewing images must not be hidden by functionality that is not needed that often. Because of those reasons I propose to continue with the separative design.

Currently, sub-dialogs (e.g. Adjust colour, Rotate, ...) are available which differ in usage and which have little interaction with the original image. E.g. the original image can no longer be moved, zoomed, or colour picked.
To make separative design work well, the usage of those subdialogs should be enhanced and unified. In the end, "Paint" could be just a special non-modal subdialog just as "Rotate", or "Colour correction".

[JohnFredC]

In the end, "Paint" could be just a special non-modal subdialog just as "Rotate", or "Colour correction".

I prefer non-modal except when the task at hand requires modal sequences.

After using many softwares for many years for many different things, I have concluded that for me the dockable sidebar approach works the best. I personally like Corel's Paintshop Pro's fully dockable and customizeable sidebar palettes and toolbars better than anything else. The modality is mantained by the sidebars, not by the main window, so the same window can be used for all operations. The sidebars are dockable anywhere and can float if that is what you want. They also expand and contract on mouse-over if desired and also collapse to skinny tabs if you want that. They can be docked into one sidebar, or each live in a separate sidebar. Fantastic. This design serves all comers.

For a combined approach LightRoom is not nearly as flexible but does OK, too. It also has sidebars that can show on mouse-over or stay open, but maintains modality via the separate Library/Develop/Slideshow/Print/Web work surfaces. What is cool about LightRoom is that the various modal views are linked together by a common library/thumbs sidebar (docked at the bottom) that is shared by all modules. This works very well and ties all of the modules to the current image selection.

There is an enormous quantity of prior art and human factors GUI research and implementation available for developers to mimic or parallel. One down-side you didn't mention about non-modal interaction is that IMHO if a developer wants to "go it alone" and ignore the prior art, then a non-modal GUI is incredibly difficult to design "right". Yes, the independent souls occasionally come up with good "new" ideas (I challenge you to name such an one, though), but most of the time the go-it-alone interfaces are just frustrating and confusing for the average user.

There is no reason in this day and age that a new user should ever have to "learn" the interface. The job, yes, but the GUI, absolutely not!

So decide what works best, and copy it!!!!