Linux Port :)

[admin]

I have committed some changes around the Gauge. I am not sure it will fix the problem. As I can't reproduce the anomaly it is difficult to know when it is fixed !
If you get it easily you can verify.

[Death Knight]

There is some improvement but not completely remove the issue... But addressed that problem is related to hidden option. Gauge is still hide itself sometimes. And if it's started hidden, ıt appears slightly wrong location. Also Main screen resize itself after process which is annoying... I searched along files but cannot detect where gauge hides itself...

Edit: I found ShowProgressGauge(false); (Mainframe.cpp line 658), commented out. That fixes all problems we have... Gauge doesn't hide itself from now. But It's better than buggy hiding process...

[admin]

The principle was to hide the gaucge when it is not in used. Hence the show / hide operation. I was trying to solve the problem without removing this capability!
I know that I went too far by forcing a complete window re-layout including re-computation of the main window size, I wanted to know if this would solve the problem. The bad news is that the answer is no. Which means that sometime there is a bug in the layout computation or in the window placement. I have found one yesterday testing this change.

When you request sizing a Window to size X then Y and then back to X without letting redraw in the middle you may get Y size as final result. There is probably a bug in the deferred sizing mechanism of wxWidgets (I think that for some reason Y was deferred but the second X wasn't so the sizing commands are switched).

[Death Knight]

Okey okey, since you want original behavior, I revert svn back to 72 (hidden gauge in wxs) than fix the glitch. ;)
The function you needed to look at : wxYield

You have better to merge NewDirectoryStructure to trunk. I will add new branch for packagers from it. Starting to package generation from now.
----
Edit #
Just looked the my old scripts and find wxpic versioning is not tastes good.
Lets talk about it
You followed versioning like
WxPic V1.2.1R194
WxPic V1.2R186
I don't know what R for. Revision?
In GNU versioning scheme : major.minor.revision is really comfortable to build packages.
So your V1.2.1R194 doesn't fits this versioning,
WxPic V1.2R186 might be converted as gnu version 1.2.186. It's simple and better. You can use/format strings as you want in the program. But when using automatic updates, it's better to use gnu versioning...
I am planning to have your source code tarballs in this structure (like wxpic-1.2.186.tar.gz which clearly defines name, version and revision), so you don't needed to change every version string in packager scripts (yes packagers uses scripts in linux). Just updating minor/revision numbers will make the job. What do you think about GNU versioning scheme for wxpic?

Erdem

[admin]

Okey okey, since you want original behavior, I revert svn back to 72 (hidden gauge in wxs) than fix the glitch. ;)
The function you needed to look at : wxYield

Well if wxGauge is buggy it may be better to give up this functionality. Not sure wxYield can fix a redraw problem when the application is idle. It could just make the wxGauge looks better while programming. But if the full re-layout followed by a full refresh that I had added at a moment the application is idle does not restore a correct display, I think that we have a big trouble with the Gauge. This confirms what I observed in the rare cases when I succeeded to produce the problem (when I suffered the problem would be more exact), it stayed once the application was idle even while I was causing refresh.

In GNU versioning scheme : major.minor.revision is really comfortable to build packages.
So your V1.2.1R194 doesn't fits this versioning, WxPic V1.2R186 might be converted as gnu version 1.2.186.

Under Windows the versionning pattern is n.m.p.q. And you have no other choice. Other applications (like TortoiseSVN) use the same pattern as WxPic except that they don't use the R to indicate that the last number refers to the SVN revision.
If you have one number less, you just have to hide the revision from the version number: V1.2.1 instead of V1.2.1R194. The revision is almost redundant with the remaining part of the version number (both are a unique index). There may be another place where you can add it for configuration management information. At least I have put it in the about dialog.
The idea to include the revision as a mandatory part of the version number does not work: You cannot tell in advance which version number will have the next stable release if revision is used (you cannot build a road map that way).

Philippe

[Death Knight]

I think I needed to write "fixed" since wxYield() already fix the problem. Quick update calls after unhide command makes wxGauge couldn't shown at required position. wxYield() works as a "flush", stops program until wxGauge really shown, that fixes problem. So we don't have such problem anymore 8-)

Revisioning handled via addition with _ like wxpic-1.2.1_r186-1.x86_64.rpm
My RPM Spec file is done and uploaded. I am sure there will be problems on some distros, will look them while I setup compile farm.

I fixed SVN versioning path at NewDirectory structure branch. But wx doesn't show any version number in linux just svn number. I think compiled programs needed to have version number in title or about dialog ...
About dialog is also empty...

WxPic
-------
See Credits and Terms Of Use below .



Terms of Use
--------------

I think you could use wxAboutDialog class to make good looking about dialog. That dialog includes license tab, program name and icon, credits for developers and translators sections...
Erdem

[admin]

Hi Erdem,

I think I needed to write "fixed" since wxYield() already fix the problem. Quick update calls after unhide command makes wxGauge couldn't shown at required position. wxYield() works as a "flush", stops program until wxGauge really shown, that fixes problem. So we don't have such problem anymore 8-)

This is a good news except this is not my own bug. Mine happens when the gauge should be hidden (it is kept displayed)

Revisioning handled via addition with _ like wxpic-1.2.1_r186-1.x86_64.rpm

This seems really perfect.

But wx doesn't show any version number in linux just svn number. I think compiled programs needed to have version number in title or about dialog ... About dialog is also empty...

I suppose that a reason why the About dialog is almost empty is that the files Author.txt and License.txt have been moved in doc directory in the branch. WxPic is looking in .Lang[/<lang>]/ to find those files and display their content in the About dialog. The Windows version is probably broken too, as well as the Windows installing script that use them for several purposes.

I have chosen to group in a single directory all the WxPic files that require translation. In fact there is another directory that requires translation: the Help directory. But I felt that the help needs to be separated (they are read by the browser and not the program and it makes sense to make it possible to export easily the help as a whole).
But I don't see why the license/Author files and the .po/.mo files would need to be separated. Even at the beginning the license and Author texts were included in the .po/.mo. But that was difficult to maintain and impossible to include in the installer. That's why I extracted those strings from .po/.mo but it seems natural to keep these files together.

I think that the reason why your About dialog has no version number is because your version has no number yet and/or you don't have the version number auto-generation script. Once I am ready with a version that all tests are made, I branch the Trunk in the Tags to create the Version Label. Then I export this label content from SVN in a new empty directory. I run all the generation procedures in the new directory so at the end I get the versioned executable fully generated from SVN. My version auto-generation scripts (I posted them here some weeks ago) recognize that the compiled files match exactly a tagged version so they allocate the version number to the executable. In any other case the procedure won't give the version number to the executable.

By the way, while we are talking about Author.txt file, you can add yourself in the English one ;-)
I will add then the translation in the French one.

I think you could use wxAboutDialog class to make good looking about dialog. That dialog includes license tab, program name and icon, credits for developers and translators sections...

I remember to have looked at it and to have discarded it because it did not fit my needs. I am not sure what was the issue. Either it was difficult to use my auto-generated version number in it, or to include the text files or some other reason...

Philippe

[Death Knight]

Himm, I think it's bad idea to load author and license.txt files. They needed to be inside program. I don't even see similar approach anywhere.
You can keep documents in doc directory, but I think proper about needed to be written in the code. My DivFix++ program supports ~13 languages. I don't expect users/translators to translate GPL license or author information nor other translator names... I guess wxAboutDialog fits all of your needing, at least you can indicate versions...You can also load txt files to wxAboutDialog before generation of the dialog. It's super simple but again I don't recommended use of external txt's. It's better to have it inside of po file...

Now I removed your AboutU.cpp & header and replaced it with wxAboutDialogInfo. I wish you like it.

[admin]

Would you like to get a program with an untranslated Japanese License?
Check commercial programs, you will always get a translated license (or your program is not translated at all)

The reason why the License files are necessary in WxPic is that they are also included in the Win32 installer that displays you the right translation and wait for agreement confirmation before installing. I don't want to duplicate the license in every places of the code especially when you have it translated. The .txt file is easy (almost) to include in the installer and in the program. The installer script won't be able to parse a cpp source code.

[Death Knight]

I think you cannot compare commercial programs with opensource and free wxpic. You are not make money from it, but they...
So you not needed to make converted licenses... In reality a Japanese corporation could use your code because of there is no Japanese license notification on source file, since jap. not supported at all... Got the point?
And for users, they even don't read those licenses. If they read, they never install M$ windows, MSN Messenger... etc. They put rules to their EULAS for reading private information on your computer withouth informing you and make it legal! Do you read it? Nope, no one reads it...
So you can leave your license in english, or you could convert it too. I believe no translator wanted to translate those license. If you use GPL license, you can find pre-converted GPL licenses for every language...
And you can also show license on programs first run instead of the installer. You can use a registry key to detect it...
regards, erdem