XnView Software

As John has pointed out above, during the past versions XnView has become more and more complex. Rather than putting more and more into the user interface (by including the Paint feature), XnView should come back to its basic tasks and do them very well. Currently, those basic tasks are provided and supported, but support and user interface could be improved and made more complete. There are many suggestions in the forum that point into this direction, already, e.g.
- Rotation: Grid display, Automatic cropping
- Cropping: Darkening the background
- Selection: Dashed Selection which is easier to see, even on grey background
- White balance: White balance using a colour picker (new feature)
- Installation: Enhanced Installer with some basic, but essential settings, e.g. "Add to menu 'Send To'".
- Fast and smooth zooming and scrolling
- ...

XnView is a fast graphic viewer, image manager, and converter with many formats supported. And it may provide basic functionality for image correction (hue, lightness, saturation, white point, contrast, red eye, ..) and prepartion for image development and publishing (resizing, cropping, ..). These features should be available and useable as easily as possible, so let's focus on these and leave the Paint tool as add-on feature.

What about a vertical paint button toolbar? It would be intuitive and clear, customizable and with ability to disable it.

I don't like a separate design, since I can do (almost) the same in another editor - Paint looks almost useless in this case.

Example when integrated Paint would be very useful - you need to make a like/arrow to 10 images (screenshots), you could do it very easy and quickly with integrated paind, just make a line, save (ctrl+s or click the save button), use a mouse wheel to switch to the next image, make another line, save, wheel, line, save...

Edit: Of course, I agree, there are more important things to do, advanced paint tools should not be integrated and I even think Pierre should focus on Viewer (and browser) features, not the paint features, but he said it would be even easier for him to do it integrated - so JUST THE BASIC paint tools would be useful, but only integrated (IMHO).

helmut

• Hi !

…and leave the Paint tool as add-on feature.

• Sorry, you might write :
“…and leave the Paint tool as a useless add-on feature.”
… with which it's even impossible to remove an inopportune cursor on a screen shot, or to correct a typo,
remove any area because no selection…
and so on…
- The most basic tools are missing, so it's indispensable to get them.
- Then, an INI improvement should allow each user to make his¦her tool according to his¦her own needs.

“To govern is to plan” hence a built-in solution is easier to handle for future text languages files, among other benefits.

G.
Claude
Clo

seems pretty ok for me as an add-on.
if i'll feel i don't need it (like some might) it'd be easier to remove it so it won't make xnview heavier.
and about easier integration.. pressing R is totally ok for integration, if you ask me.

the only reason i can agree to if it is easier for Pierre to implement it as a part.

I wonder what a full integration means: Toolbar buttons of Paint mixed with toolbar buttons for navigation might be a good idea and vision, but Paint brings much more with it: There's user interface for indicating forecolour, backcolour, parameters, modes, and so on. This is "a lot of interface", in my point of view too much user interface for designing a combined, simple user interface with existing View functionality. The result would be something like Corel PhotoPaint or Adobe PhotoPaint with everything reachable with one click, both products target mainly professional users.

Pressing a shortcut or choosing a menu for Paint is a good level of integration, I think. A bit further integration which still makes sense would be having non-modal subdialogs (a special type of toolbar?) as proposed above. Those subdialogs could display the parameters of the Paint tool.

Before, we didn't have Paint at all and there were some, but not too many requests for it in the forum. So let's keep the balance and not make Paint more heavy and present in XnView than it actually should.

Last not least: If some few things are missing in Paint, perhaps these could be added there?

Maybe the poll question is ambiguous.

Is the question: Paint functionality as a plugin (a la 8bf) VS paint functionality integrated with XnView?

or

Is the question: Paint functionality in the separate (floating) window VS paint functionality embedded in the XnView Viewer?

Do you see the distinction?

It seems adequately possible for Pierre to write a private plugin (ie. an external dll) that implements paint functionality directly in XnView instead of implementing it (also as an external dll) via the Adobe protocol for plugins, which require the separate window.

I vote for the XnView main window AND plugin architecture.

—> helmut

• Hi !

…Last not least: If some few things are missing in Paint, perhaps these could be added there?

• The missing “few things” (sweat euphemism) can be saw HERE.

• Frankly, I think that the “Append Text” and “Watermark” have nothing to do there, they exist in the main programme,
so they are duplicates adding fat to the library.
- Using a built-in solution, there is a gain at size, although they could be used too…

¤ The real basic retouch tools - like they were in UniView for instance- are, by order of necessity :

0. Save the changes on the spot, without closing the tool.
1. The classic selection,
2. The pencil,
3. The paint tin (Fill).

¤ Optional from INI entries (to save GUI stuff), but still useful :
4. Draw lines¦arrows - Draw ellipses¦rectangles.

¤ Optional too perhaps, though rather “Nice to have” :
5. The lasso selection,
6. The rubber.

¤ Finally, whether built-in only :
7.“Append Text” and “Watermark” using the codes already existing in the programme-core.
Just use the existing internal commands to call them.

• Indeed, the general features about the foreground¦background colours must be kept.
They could use the palette of the main programme. Currently the palette invoked by Paint is lame,
it doesn't save the customized colours…

• From the chapter of the Manual linked above, one can see too that some settings are missing
and annoying to add for Pierre since they have to act outside the main programme (that needs duplicate settings),
i.e. the background colour of the Paint window and others…
- Whether built-in, some BG colour of the programme could be used, and doesn't need an addition.
- Ditto for the zoom-step…

• The last but not the least : Change the name i.e. as XPaint,
we have users in the French forum getting totally confused with the current name…

G.
Claude
Clo

JohnFredC wrote:Maybe the poll question is ambiguous.

Is the question: Paint functionality as a plugin (a la 8bf) VS paint functionality integrated with XnView?

or

Is the question: Paint functionality in the separate (floating) window VS paint functionality embedded in the XnView Viewer?

Do you see the distinction?

If Paint will be integrated in XnView, it will be as now, not integrated in view mode but in dialog. I can't...

xnview wrote:If Paint will be integrated in XnView, it will be as now, not integrated in view mode but in dialog. I can't...

Makes a big difference to this discussion, I think. I don't care much whether Paint is offered as plugin or not.

From users perspective, the integration as plugin or fully into xnview.exe makes only a difference to the download size of the minimal version. The user interface would remain identical - right Pierre?

helmut wrote:

xnview wrote:If Paint will be integrated in XnView, it will be as now, not integrated in view mode but in dialog. I can't...

Makes a big difference to this discussion, I think. I don't care much whether Paint is offered as plugin or not.

From users perspective, the integration as plugin or fully into xnview.exe makes only a difference to the download size of the minimal version. The user interface would remain identical - right Pierre?

Yes, and it's more easier for me to develop Paint feature. The possibility to have an icon in toolbar will be possible too.

xnview wrote:Yes, and it's more easier for me to develop Paint feature. The possibility to have an icon in toolbar will be possible too.

Sounds like little disadvantages, only. How much larger would be the xnview.exe (roughly)?

helmut wrote:

xnview wrote:Yes, and it's more easier for me to develop Paint feature. The possibility to have an icon in toolbar will be possible too.

Sounds like little disadvantages, only. How much larger would be the xnview.exe (roughly)?

+~100Ko i think

I repeat what I said originally, from a user's perspective, it makes little difference one way or the other. Being able to have it as an icon in the toolbar could be useful to some people, but it's a minor issue. The increased download size is also a minor issue. Having it located under tools, image, or edit instead of filters would be better, more logical, and easier to find, but again that's a minor issue.

Bottom line, do what you want with it, it'd won't have a major effect on the end users one way or the other.

all

Indeed the way in which the «Paint» must be further developed is important.

- However, that it must contain is pretty important too.

- I guess that the Clo's classification of the tools as above is right.

Removing the useless codes already existing, then embed the thing in the core couldn't increase the global size…
Anyway, 20 Kib more or less… Later, using language-files'll compound largely an eventual size rise from this.

- A quite flexible retouch tool (on demand for each user) is also a good solution.

Friendly

Paul

Salut,

Il existe deja beaucoup de logiciel libre ou non et tres facile d'utilisation pour cette fonction !