[REQUEST] Save File Dialog does not include file-extension when...

[pitoloko]

The current save file dialog will not automaticaly include a file-extension in some cases.

Steps to reproduce the bug:

1. Open a file in Avidemux
2. Press the "Save video" button to open the Dialog.
3. In the filename textbox, type a name that includes a dot and don't type the file-extension.
    Conflictive Filename Examples: "Jason St. Smith", "Mr. Hyde"
4. Press the "Save" button in the Dialog.

It will create/save the file wihout extension.

That's all,
thanks for read.

[Jan Gruuthuse]

The divider between file name and extension is "."
The created files have these file-extension:
- Jason St. Smith
- Mr. Hyde
OS has no idea if 1st full stop it encounters is you giving these file-extensions or not.
Solution: avoid full stop and blanks in file names!

[pitoloko]

The divider between file name and extension is "."
The created files have these file-extension:
- Jason St. Smith
- Mr. Hyde

Of course the divider is the dot but it's not as true as you've commented 'cause the Dialog should append the file-extension even if you put 1 or a thousand of dots in the filename, the Dialog of AviDemux is designed to write the name of the file (not the extension) and then it appends automatically the extension, but if you type a dot it deduces that you've written an extension when is not, that is bad.

OS has no idea if 1st full stop it encounters is you giving these file-extensions or not.

Sorry but it's not correct, AviDemux does not have idea (by the moment), but the Dialog/OS could difference it.

I've used savefile dialogs in my applications and this problem does not happens, that dialog need a reprogramming of the properties of the Dialog.

Thanks for read.

[Jan Gruuthuse]

If you want to use full stop in middle of file name, have the courtesy of adding the extension yourself.
Avidemux has batch processing capabilities from command line in Windows, Linux, perhaps OS X to. This is the reason why Avidemux cannot bother with file names having full stop/spaces in it.
The recommendation still goes: keep paths as short in length/depth as possible and close to the root of the used hard disk. In filenames use standard UK ascii only, no full stop. This will avoid you having issues when processing files in avidemux.

[pitoloko]

If you want to use full stop in middle of file name, have the courtesy of adding the extension yourself.

Is not a courtesy issue, the purpose of a good Software is to reduce as much as possible the manual user intervention (more when it's an innecesary user intervention that could be solved easy by the developer such as this problem), simple as that, and I'm just saying only that.

And as another related cons:
What happens if the user writes an incorrect extension?, for example AviDemux will save an "AVI" video as "MKV" if the user types ".mkv" and AviDemux will not show any informative/advise message about that, and then the video will not be recognized in some specific video-players that are very sensitive, that is another really bad point for this problem, so to resolve this also I need to have the "courtesy" of know what extension is the correct? ...I think not, AviDemux should do every of those things for me 'cause AviDemux is the software, and I'm only the human.

Thanks for read.

[Jan Gruuthuse]

Most Linux recognize the video content of a file without an extension. Extensions are a kind of windows limitations issue.
You just want to see avidemux functioning as you wish and how you see it. I Just did explain why this is happening. You don't care.
Last time I replied to your bug complaints. You never gonna learn are you. See links below.
When you want a change/feature you make a request and don't report anything as a bug.
- Feature requests
- Reporting bugs

[AQUAR]

I wasn't going to respond to yet another post about "Avidemux has a bug".

Definition of a software bug: A problem that causes a program to produce invalid output or to crash (lock up).

As the OP implied programming experience, there should have been some recognition that this issue does not fit the definition of a software bug. With this issue, Avidemux doesn't produce invalid output nor does it crash.

The extension is simply a sneaky bit of metadata for file type identification under M$ windows. Again it in no way equals an invalid file (indeed, files are not changed by changing extensions).

Avidemux does rely on the enduser to correctly save the video file produced. The associated nomenclature for saving files differs across the platforms that Avidemux is able to operate under. So its easier for the enduser to comprehend the platform and deal with this aspect.

This item is simply a case of the enduser needing a tiny bit of effort to correctly use Avidemux.
Can this be better automated with code? Of course.

I am with Jan ie: the proper approach is to point it out by way of making a feature request.

And, since this item/issue has been around for a long time, I suspect the developers are fine with this approach.
In other words "take it or leave it" (totally my opinion of course!).

[pitoloko]

A bug does not have to be strictly a failure that breaks/crash the software.

A software bug is an error, flaw, failure, or fault in a computer program or system that causes it to produce an incorrect or unexpected result.
Some bugs have only a subtle effect on the program's functionality
More serious bugs may cause the program to crash or freeze.

Of course this as a Bug and I consider it as what it is, a very minor bug, I only can say that anyways I've accepted suggestion of turning my "bug" issue into a "request" issue ...starting by changing my post title.

Can this be better automated with code? Of course.

Your phrase does not need more words or points of view, that should be the unique reason for developers to fix/improve it.

Thanks for read

[AQUAR]

@ pitoloko,

You may well decide this issue is an incorrect or unexpected result from your perspective.
Most visitors here welcome such input, as does the developer, hence the provision for feature requests.

It is not your prerogative to factualise your decision by claiming this to be a bug.
That is the prerogative of those who understand the coding intent of the program.

So, if this issue is by design - it cannot be a bug.
Typically only a few (like developers) will know if this issue is by design or not.
And almost invariably, endusers like ourselves are not qualified to make that determination.

Not saying you can't make such a claim.
If you put in the effort to analyse the code, point out the mistake or offer improved code, then you most certainly can.
Others have contibuted many times in this manner, but you are not one of them.

So, stop pretending you have found a bug and instead ask those in the know if this behaviour might be a bug.

All of this is of course a bit of nit picking around the edges.
It is not so much your post that is inciting this nit picking, but the fact that so many people cry out with un-substantiated claims of bugs.

As I said above I wasn't even going to respond, but maybe this helps to foster a more benign and polite way for some endusers to communicate their experiences with this program.

Finally (and again!) you have no right to claim that your perception is a sufficient and unique reason for developers to alter their program code.
As a coder myself I have some perspective on this viz, sorry to say this but they have zero obligation to entertain endusers in this manner.

PS: Your exception to my statement "can this be better automated with code? Of course" does not help your cause.