 |
Thanks to Andrew. |
|
|
I re-read as much of the included notes as I could and I believe that everything that was mentioned has been resolved. That includes: 1) attach transitions saved in english 2) reset button in the Titler Mentioned but not the title of this BT and not sure should be done. If someone really wants, they can open a separate BT instead. 1) have the Title plugin show both translated and english names for style options But a problem still is the font tag error which existed in the original Title has to be debugged yet and is discussed in the Mailing List |
 |
Hi @PhyllisSmith, yes, when I realized that sometimes it took me more work to reset by hand than what I was going to enter with this effect, I made a "RESET" preset with title keyframe to quickly set the wizard as a starting point. departure. Hi @Andrew, I'm going to test your latest patch that you add. I'll comment on you later. |
 |
@PhyllisSmith Yeah .... those warnings apparently can easily turn into errors depending on compiler Try attached combo patch? (I hope it will not crash on you ...some values still off, but I'll fix them later) Yes, this video (30052016465.mp4) has my dog Grey in it .... RIP ....
TITLER_reset_plus_eng_tags.diff (9,282 bytes) |
|
|
@Andrew-R When I use the current checked in Title plugin and apply the patch TITLER_wrong-2.diff and run make, i get the following errors so can not test. [root@keystone titler]# make g++ `cat x86_64/c_flags` -DMSGQUAL=titlerwindow -c titlerwindow.C -o x86_64/titlerwindow.o In file included from ../../cinelerra/cwindowgui.h:36, from titlerwindow.C:30: titlerwindow.C: In member function ‘virtual int TitleCurSubMenuItem::handle_event()’: titler.h:26:22: warning: ISO C++ forbids converting a string constant to ‘char*’ [-Wwrite-strings] 26 | #define KW_NUDGE N_("nudge") | ^~~~~~~ ../../guicast/language.h:29:29: note: in definition of macro ‘gettext_noop’ 29 | #define gettext_noop(msgid) msgid | ^~~~~ titlerwindow.C:1482:38: note: in expansion of macro ‘N_’ 1482 | strreplace(item_text, _(KW_NUDGE), N_(KW_NUDGE)); | ^~ ../../guicast/language.h:30:19: note: in expansion of macro ‘gettext_noop’ 30 | #define N_(msgid) gettext_noop(msgid) | ^~~~~~~~~~~~ titler.h:26:19: note: in expansion of macro ‘N_’ 26 | #define KW_NUDGE N_("nudge") | ^~ titlerwindow.C:1482:41: note: in expansion of macro ‘KW_NUDGE’ 1482 | strreplace(item_text, _(KW_NUDGE), N_(KW_NUDGE)); @RafaMar You can get back to default in the Titler plugin (or any other plugin not already on the timeline and saved in your project) by deleting the file $HOME/.bcast5/titler.xml or the specific plugin.xml. However, having a reset button would be very advantageous. @Andrew-R Speaking of dogs -- is that "Grey" in 30052016465.mp4 that you supplied as test media the other day? Anyway that is a good looking dog and if it is Grey, I am sure he is sorely missed. |
|
|
I'm looking at commit where some reset buttons were added .. https://git.cinelerra-gg.org/git/?p=goodguy/cinelerra.git;a=commit;h=54cc56bff09f5004b2a6cd454375f06e56acf5a0 I did something similar yet it doesn't work completely for me ;/ probably mystery for another day! |
|
|
@Andrew-R I don't understand programming... but if you have to try something, count on me. Sorry @PhillisSmith, I ate an "s" when referring to you. |
|
|
also found reason of warnings in my patch: https://stackoverflow.com/questions/20944784/why-is-conversion-from-string-constant-to-char-valid-in-c-but-invalid-in-c/20944858 so just adding (char*) before N_(some_constant) in calls to my newly added function silenced them ..... |
|
|
@RafaMar: > - The html tags inserted in the text are seen in English. Yeah, this is what I wanted ...... I think Phyllis is she .... > (A possible solution would be for the menu to show the local language along with English, for example in Spanish I would see this in the margin: this will make menus wider .. (/me still at 1440 wide monitor) > Oh my god, I think I just burned my food!!! this usually happens when I focus on something and leave something in the oven. Totally like me!!!! > My dog is very happy, whenever I burn my food he eats it. Him is fan of Cinelerra GG. :-D I seriously wish all good things (and beings) to your dog .... |
|
|
@Andrew-R I have already tried the new patch. Result. - The html tags in the menu are in the local language. - The html tags inserted in the text are seen in English. (Check this point with @PhyllisSmith, because I think he wants them to be seen in the local language. I personally do not care, html tags are always in English, but for video editing it is not necessary to know html and for someone it might be a problem). (A possible solution would be for the menu to show the local language along with English, for example in Spanish I would see this in the margin: margen = nudge -> margen dx, dy /margen In Bold I would see: negrita = bold -> negrita 1 negrita 0 /negrita ) - The only problem has been given to me by the font tag, the local name has been changed to English when I have inserted it and in some lines the close tag has not worked for me, and the source has been changed to all the text and not only to between <font nameOfTheFont> and </font>. It's funny that if instead of using the closing tag properly </font> I use this <font> tag the latter works like closing tag ... strange things about programming ... Oh my god, I think I just burned my food!!! this usually happens when I focus on something and leave something in the oven. Conclusions: If Phyllis likes this solution, it seems perfect to me, in Spain we have a saying that says, where there is a captain, the sailors do not command, and I am a low-ranking sailor in Cinelerra GG. To give facilities to people who do not know English, the proposal that I have commented could be used, if it is not difficult to implement, it would be something like this local tag name = English tag name It would only be to add to the main menu that is opened with the right mouse button an = followed by the name of the tag in English, in the translated versions of Cinelerra. With this your solution would be perfect for people who don't know English. My dog is very happy, whenever I burn my food he eats it. Him is fan of Cinelerra GG. :-D |
|
|
Oh, I simply don't want localized parameter names in CONFIG files and projects ..:/ But making this reality apparently not very easy ... at least in generic manner. |
|
|
@Andrew-R But if it works well, it is just that if you change your local language to another or to English, you must put the labels in English or the new local language for them to work well. Ideally, the tags should always be in the local name, but internally Cinelerra would see them in English, so when we switch from one language to another the html tags will also be translated, as the new folder creation wizard does automatically, where I can create parameters in Spanish for a folder, but if I change the language, the command lines for, for example, separate audio and video files into exclusive folders, are automatically translated into the new language. For example try to create a new folder, then in target choose "Track type", in value, audio or video ... now you configure Cinelerra with any language the term "audio" or "video" is automatically updated to the new language. Perhaps the method used in this wizard can help you. In a few moments I am going to test this new code and comment on the result. |
|
|
@RafaMar I like to have this menu working :} So far only 'font name' submenu resist me .... Yeah, I switch poor menuitem back and forth between english and localized on the fly .....
TITLER_wrong-2.diff (5,932 bytes) |
|
|
@Andrew-R The labels menu comes out in the local language (Spanish in my case). But when I insert a tag, the name of this tag changes to its English name, in the menu. The labels appear in English in the text, but also change their name in the menu. If I close the wizard and reopen it, the menu is again correctly translated into the local language. Honestly, I think this issue is not important and can be left as it was before, but people who do not know English will be confused. Thanks a lot. |
|
|
@Andrew-R now I'm going to try this new code that you have sent me. I will tell you the result shortly. |
|
|
@Andrew-R I must say that the problem with "italic" labels is because if it is assigned to a font that does not accept this style, the labels are displayed. It is not an error in your code. The same thing happens with the unmodified file. I have restored the original file and checked it and the problem persists in fonts that do not accept italics. |
|
|
@RafaMar Oh yes, found popup remained translated (as in - sending transtalted version of its rag down the pipe) Yet italics works for me in Russian ..and in Spanish, as far as I can find them ..o.O Be sure you have closing tag (</>) Strange, for me this popup remain fully translated .... (with this patch).
TITLER_wrong-1.diff (4,062 bytes) |
|
|
@Andrew-R I have tested the patch for the text style html tags, and the result has not been good. Many errors, for example the font closing tag no longer works, neither in Spanish nor in English, italics have stopped working. In Spanish some labels are in Spanish, others in English. As @PhyllisSmith has said, this matter can remain as it was before, since a user who does not know other languages will always use her local language. It is not worth spending your precious time on this matter. Better to spend your precious time on the reset button of titel wizard and the help button to open the batch render wizard quick guide. (As long as @PhyllisSmith agrees, first check with him before doing so) And most importantly, thank you very much for your excellent work. |
|
|
@RafaMar > Would it be easy to include a reset button to defaults in the title wizard? I'll try (after all I did some square hole /checkbox/ for batchrender!), but I code quite slowly ..:/ |
|
|
@PhyllisSmith I have tried the transitions again, opening projects made in English and Spanish, playing with other languages such as French and Italian, of which I have notions, and the result has always been good. Now I'm going to test what @Andrew-R proposes from the title assistant. @Andrew-R, Would it be easy to include a reset button to defaults in the title wizard? If it is difficult, it does not matter, but if it is easy, it would be a very good option. Thaks. |
|
|
@RafaMar, @PhyllisSmith can you test this patch/hack for Titler? It backtranslates (by giant switch and stackoverflow magic!) keywords back into english, so inserted commands remain in english. Yet menus show translated names for commands It generates few new warnings, not sure what I should do with them .... titlerwindow.C:1482:41: warning: ISO C++11 does not allow conversion from string literal to 'char *' [-Wwritable-strings] strreplace(item_text, _(KW_NUDGE), N_(KW_NUDGE)); ^ strreplace is a new function I copied from https://stackoverflow.com/questions/779875/what-function-is-to-replace-a-substring-from-a-string-in-c
TITLER_wrong.diff (3,704 bytes) |
|
|
Ok, thanks for the clarification @PhyllisSmith, I'll leave these html tags in Spanish. Since we have talked about the title assistant I would like to make a suggestion. Would it be possible to put a reset button for defaults values in the title wizard? Sometimes it takes me more work to remove the settings from the previous use than to put the text I want :-D. Yesterday I had a busy day and cannot test with Cinelerra. Today I will try again what you say about transitions. Then I will comment on the result. |
|
|
@Andrew-R True. Will mark this BT resolved in a couple of days. @RafaMar About: "This is also true of the caption plugin text styling commands. ... if Cinelerra's language is changed to something other than Spanish, they stop working. ...Maybe I should put them back in English?" The above was discussed in February 2017 when the html-like style commands were added. If I remember correctly, IgorUbuntu concluded with us that it is much better to leave this in the user's native language for a very good reason. The reason being to make it easy for non-english users who are in the majority so they do not have to "guess" what the english words mean. 1) For example, if "nudge" was left in english, a Spanish user looking it up in google translate would see it as empujar (push) rather than margen (which is what your current translation is to margin). The user understands the Spanish but "nudge" is just a weird english word with little meaning. If the user goes out of their way to switch from Spanish to english, they most likely know enough english and could do the translation fix to english themselves. 2) In addition, if the Spanish user writes the title text words (not the styles) in Spanish and then switches to using english, you would think that they already have to translate all of the title text words to english anyway. 3) Most likely if written in non-english, switching to english is probably just a temporary thing. So if after much discussion 4 years ago, that was the decision I think it has long-lasting merit. |
|
|
yeah, apparently because previous (to this patch) version of Cin was saving localized DEFAULT_VTRANSITION in Cinelerra_rc. patched one saves this variable in English, as far as I can tell. Unability to recover localized names are another bug I encountered and was unable to fix so far. So, yes, if you used CinGG for setting def. video transition in non-english, and made few projects using this feature ... they will show this unability to find transitions. But as far as I can see they will not work in unpatched (for this bug) CinGG , too ? |
|
|
@Andrew-R Tested with transitions_ru_utf8.xml while I am working in English as always. Attached shows an example of the Transition problem I saw last night when I was almost asleep.
example_problem.png (57,620 bytes) |
|
|
@Andrew-R @Andrea_Paz OK, I must be wrong or else I already had a bad Transition in French that I had created. Also when I edited my Cinelerra_rc (in English, of course) it had the DEFAULT_VTRANSITION ---" there was --- instead of dissolve. It will have to remain a mystery and the mod will stay in. Thanks to all for re-testing to verify. |
|
|
@Phyllis_Smith, I just installed and compiled the latest version of Git. In my usual desktop, in English, I have opened a project with transitions, I have put Cinelerra in Spanish and everything has worked correctly. On my desktop in Spanish, I did it months ago when it was the only way to have Cinelerra in Spanish to do the tutorials, I have opened old projects in Spanish, with many transitions and they work perfectly, even if now from here I put Cinelerra in English, everything still works fine. @Andrea_Paz thanks for prove in Italian and confirm that the solution is good. @Andrew-R as usual has solved this problem brilliantly. |
 |
I confirm that the patch works. Without there are errors, with the patch everything is OK. |
|
|
Try this project, created in cinelerra-goodguy-20201101-i486-40_cin.txz (where bug described here was present, so I dragged those transitions from Resources) It opens without trouble and show transitions in cinelerra-goodguy-20210121-i486-41_cin.txz (with my patch) both cin version were run with those environment variables set: LANGUAGE=ru LANG=ru_RU.utf8 cin If you still see troubles with default state of default transition in English - try to un-comment those tree lines I commented? - strcpy(transition_title, data_type == TRACK_AUDIO ? - mwindow->edl->session->default_atransition : - mwindow->edl->session->default_vtransition); +// strcpy(transition_title, data_type == TRACK_AUDIO ? +// mwindow->edl->session->default_atransition : +// mwindow->edl->session->default_vtransition); Be sure you don't have any mwindow patches from me in tree ..... transitions_ru_utf8.xml (11,209 bytes) |
|
|
@PhyllisSmith > When Plugins were changed from translated names to being stored in english, the code was also modified to accept the translated names also. Then it doesn't work for me without patches :/ At least in this specific case (both 'Attach transition' (and thus 'set default' subpart of it) and titler's popup actually broken in way RafaMar described in both utf8 and cp1251 ...) |
|
|
@Andrew-R I checked in the patch of menuattachtransition.h and menuattachtransition.C into GIT, but I may have to just back it out because... Did anyone check to make sure this works on previously existing projects that were NOT in English? I did not think of it until after a problem came up after I checked it out from GIT and ran it. I think it is better to have the problem going forward with only a very small percentage of users switching languages than to break all of the existing projects of a large percentage of people. I plan on backing this mod out tomorrow. When Plugins were changed from translated names to being stored in english, the code was also modified to accept the translated names also. |
|
|
@Andrew-R Finally I had time to test this and looked at the code a little. It works well with your patch: fix_menuattachtransition_3.diff I will check it into GIT next time I power up the main computer. About the URL reference comment of: "There even was interesting chapter on translating GUI programs, where same string may have different meaning in different menus/windows, but I still not wrapped my head around it ..." This was another implemented feature suggested by IgorUbuntu and you can read about using it in the current PDF Manual in the Translations chapter starting on page 592 (or 612 in pdf page numbers). It starts out with: NOTE: some words and abbreviations can lead to ambiguous language trans- lations. Therefore, the usage of C_ and D_ in the program code was added to represent Contextual and Definitional exceptions to the usual _ and N_ . You will see the following: ... |
|
|
@Andrew-R MY MOST SINCERE CONGRATULATIONS. It works perfectly. Also the default transition and always in the language that I have Cinelerra configured. When the wizard is reopened, the default name reverts to English, but this does not matter. THANKS A LOT. I think @PhyllisSmith can include these changes in Cinelerra and this bug is now resolved. Honestly, the name of the default transition has no relevance and the wizard works like this perfectly. |
|
|
@RafaMar, try those ? menuattachtransition.h (2,794 bytes) menuattachtransition-2.C (7,475 bytes) |
|
|
@Andrew-R If I made the changes to the two files before compiling. I'm not very good at these things, maybe the mistake is mine. If you can pass me the modified files I will change them and try again. Thanks |
|
|
@RafaMar Make sure you have patched menuattachtransition.h too ... You can 'edit' c file (add/remove space in comment, for example) a bit so recompilation will be forced ... or rebuild whole thing like this: cinelerra-goodguy-20210112/cinelerra-5.1/cinelerra# make clean && make -j 5 it worked for me with clang-10 (i686) |
|
|
@Andrew-R I must have done something wrong because it gave me an error in the compilation. ------------------------------------- g++ `cat x86_64/c_flags` -DMSGQUAL=menuattachtransition -c menuattachtransition.C -o x86_64/menuattachtransition.o menuattachtransition.C: In member function ‘void TransitionDialogThread::start()’: menuattachtransition.C:86:16: error: ‘transition_title’ was not declared in this scope if( !strcmp(transition_title, title) ) number = i; ^~~~~~~~~~~~~~~~ menuattachtransition.C:86:16: note: suggested alternative: ‘transition_names’ if( !strcmp(transition_title, title) ) number = i; ^~~~~~~~~~~~~~~~ transition_names menuattachtransition.C: In member function ‘virtual void TransitionDialogThread::handle_close_event(int)’: menuattachtransition.C:121:15: error: ‘transition_title’ was not declared in this scope if( !strcmp(transition_title, title)) { ^~~~~~~~~~~~~~~~ menuattachtransition.C:121:15: note: suggested alternative: ‘transition_names’ if( !strcmp(transition_title, title)) { ^~~~~~~~~~~~~~~~ transition_names menuattachtransition.C:126:41: error: ‘transition_title’ was not declared in this scope mwindow->paste_transitions(data_type, transition_title); ^~~~~~~~~~~~~~~~ menuattachtransition.C:126:41: note: suggested alternative: ‘transition_names’ mwindow->paste_transitions(data_type, transition_title); ^~~~~~~~~~~~~~~~ transition_names menuattachtransition.C: In member function ‘virtual int TransitionSetDefault::handle_event()’: menuattachtransition.C:156:41: error: ‘class TransitionDialogThread’ has no member named ‘transition_title’; did you mean ‘transition_names’? const char *transition_title = thread->transition_title; ^~~~~~~~~~~~~~~~ transition_names menuattachtransition.C: In member function ‘virtual int TransitionDialogName::selection_changed()’: menuattachtransition.C:276:17: error: ‘class TransitionDialogThread’ has no member named ‘transition_title’; did you mean ‘transition_names’? strcpy(thread->transition_title, ^~~~~~~~~~~~~~~~ transition_names |
|
|
@RafaMar what about this patch? It contains some seriously bad code duplication, but appear to work ... Try setting 'Default transition' too!
fix_menuattachtransition_3.diff (3,256 bytes) |
|
|
Hello @Andrew-R I have tried the two options you send, both compile fine and work fine, but in both the translation is lost. As an anecdote, now in Titles, with the Spanish language, the labels are in English, but the projects carried out in Spanish work well with the labels in Spanish. I'm sorry I can't contribute more because I don't know about code, it would be perfect if translations could be maintained and that a project made in one language could work well in another, perhaps this is asking too much. |
|
|
@RafaMar: >> This is also true of the caption plugin text styling commands. Maybe it's my fault because I translated these commands into Spanish, and they work perfectly, but if Cinelerra's language is changed to something other than Spanish, they stop working. === well, I added same N_ to those, so they remain untranslated. Not really solution, and you need to recompile and reinstall titler plugin. Something probably can be done about this ..keeping translated version for menu, yet pasting untranslated one (so it will be saved and loaded as such ..)
title_untranslate_popup.diff (4,735 bytes) |
|
|
After reading gettext manual [0] I came up with MUCH simpler patch, this doesn't mess with locale at all (but still doesn't allow you to have both working dialog and translated transition names :/ ). Attached. [0] - https://www.gnu.org/software/gettext/manual/gettext.html#Programmers There even was interesting chapter on translating GUI programs, where same string may have different meaning in different menus/windows, but I still not wrapped my head around it ....
fix_menuattachtransition_2.diff (583 bytes) |
|
|
@PhyllisSmith >> 1. Plugin names saved in the EDL are now retained in the original english language. Yes, I see this commit https://git.cinelerra-gg.org/git/?p=goodguy/history.git;a=commit;h=723142d62d61cde588e961426440f839ca9dcda9 But for some reason we still getting translated _transition_ titles in https://git.cinelerra-gg.org/git/?p=goodguy/cinelerra.git;a=blob;f=cinelerra-5.1/cinelerra/menuattachtransition.C even if they saved in same plugindb ??? |
|
|
@ Andrew-R I can't help you with the code topic because I don't understand programming, I'm sorry. A good friend who does understand told me that the Cinelerra code was very dense and required a lot of study of its functions to be able to successfully intervene in it. The pity is that this friend does not have time to dedicate himself to trying to solve these problems. @PhyllisSmith This is also true of the caption plugin text styling commands. Maybe it's my fault because I translated these commands into Spanish, and they work perfectly, but if Cinelerra's language is changed to something other than Spanish, they stop working. So the texts that have been styled with these commands when translated into Spanish, totally my fault in this case, stop working. Maybe I should put them back in English? I did it thinking that it would not be a problem, but precisely these days doing tests I opened a file that I had made for the tutorials, where I gave style to the text, and I did it with Cinelerra in Spanish, when opening it in Cinelerra in English the text showed the Spanish labels instead of stylish text. |
|
|
@Andrew-R About "something strange happens with transition's names" -- this is true. The same problem was discovered by IgorUbuntu with the plugins. They were being translated to a language and being stored in the EDL that way. Then if the user switched to another language, they no longer worked. So it was fixed as shown below from the releasenotes in January 2018.. I suspect that transitions will need a similar type of fix. 5.1 Release Notes for changes from 01/01/2018 to 01/31/2018 for these builds ------------------------------------------- 1. Plugin names saved in the EDL are now retained in the original english language. Previously saved XML files will automatically be translated back and when saved again, will be saved in english. |
|
|
something strange happens with transition's names - *plugins* get their attach dialog translated and it works. 'Dump plugins' from main menu also show all their names untranslated (like it should be, for moving projects between machines with different language settings). But in this specific dialog I can only get translated names, and when they send down to other module it can't find them because they used different (translated and untranslated) names .... And trying to teach some other function to eat unicode (utf8) was not very successfull ..... |
|
|
@Andrew-R Thank you very much, I have tried with this file that you have sent me. The result is that it works but the translations have been lost, set Cinelerra in any language the name of the transitions always comes out in English. I imagine that now we will have to add these translations to the .po file? Although this is better than before, because although the names are not translated, the wizard works in other languages. In English it always worked. Thank you very much for your excellent work. |
|
|
Added complete file, as @RafaMar requested ..... menuattachtransition.C (6,894 bytes) |
|
|
Oh, I mostly give up and just set locale in this dialog to C ..... Idea/code from https://stackoverflow.com/questions/34345622/getlocale-function-in-c
fix_menuattachtransition_locale.diff (1,386 bytes) |
|
|
@Andrew-R sorry I can't help solve the problem beyond testing. The only thing that a friend taught me to make, he does understand code, is to replace the modified file in the place where I have the files to compile Cinelerra, compile it and test it. I do not understand these files that you send, my friend, if he understands them, he has tried to explain to me, via email, how I should modify the original file with the changes that you make. But I do not quite understand. Can you pass me the file with the changes made? So I can replace in the folder to compile Cinelerra with this file and thus be able to test. I tried to do this with the first change file you sent, but I must have done something wrong because now when I open the Cinelerra transitions option it closes. |
|
|
This debug patch print into console: root@slax:/dev/shm/tmp/cinelerra-goodguy-20210112/cinelerra-5.1/cinelerra# LANG=ru_RU.utf8 ../bin/cin Cinelerra Infinity - built: Jan 15 2021 05:00:01 git://git.cinelerra-gg.org/goodguy/cinelerra.git (c) 2006-2019 Heroine Virtual Ltd. by Adam Williams 2007-2020 mods for Cinelerra-GG by W.P.Morrow aka goodguy Cinelerra is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. There is absolutely no warranty for Cinelerra. ff_aspect_ratio, 0.000000 interlace from demux: 0 ff_aspect_ratio, 0.000000 ff_aspect_ratio, 0.000000 ff_aspect_ratio, 0.000000 ff_aspect_ratio, 0.000000 ff_aspect_ratio, 0.000000 ff_aspect_ratio, 0.000000 Wide string 3: A?KH:0 in fix_plugin_title 2 Wide string 3: KB5A=5=85 in fix_plugin_title 2 Wide string 3: KB5A=5=85 ?>;>A0<8 in fix_plugin_title 2 Wide string 3: 0<5I5=85 in fix_plugin_title 2 Wide string 3: 0<5I5=85 ?>;>A0<8 in fix_plugin_title 2 Wide string 3: ▒204@0BC@0 in fix_plugin_title 2 Wide string 3: 0?;K2 in fix_plugin_title 2 Wide string 3: 0000025;8G5=85 in fix_plugin_title 2 Wide string 3: $83C@=>5 2KB5A=5=85 in fix_plugin_title 2 Session time: 0:00:21 Cpu time: user: 0:00:10.848 sys: 0:00:01.196 so, _I think_ it compares correctly now .. Just ... strcpy will crash, so i need to convert wchar back to char ?
WRONG_menuattachtransition_fix.diff (5,436 bytes) |
|
|
so, i'm trying to get standard conversion running ... so far this diff doesn't crash (but this is uncomplete thing, I completely lost with c++! ) diff --git a/cinelerra-5.1/cinelerra/mwindow.C b/cinelerra-5.1/cinelerra/mwindow.C index 04549fde..2aa7ab7e 100644 --- a/cinelerra-5.1/cinelerra/mwindow.C +++ b/cinelerra-5.1/cinelerra/mwindow.C @@ -138,6 +138,10 @@ #include "zwindowgui.h" #include "exportedl.h" +#include <cwctype> +#include <locale> +#include <vector> + #include "defaultformats.h" #include "ntsczones.h" @@ -930,12 +934,27 @@ PluginServer* MWindow::scan_plugindb(char *title, // repair session files with xlated plugin titles void MWindow::fix_plugin_title(char *title) { + const char *lang = getenv("LANG"); + if (!strcmp(lang, "ru_RU.utf8")) { + + const char* my_title= title; + + std::mbstate_t state = std::mbstate_t(); + std::size_t len = 1 + std::mbsrtowcs(NULL, &my_title, 0, &state); + std::vector<wchar_t> wtitle(len); + + int ret = std::mbsrtowcs(&wtitle[0], &my_title, wtitle.size(), &state); + printf ("mbsrtowcs returns, %i \n", ret); + return; +} for(int i = 0; i < plugindb->total; i++) { PluginServer *server = plugindb->get(i); if( !server->title ) continue; const char *server_title = server->title; + //printf("in fix_plugin_title 1 , %s \n", _(server_title)); if( !bstrcasecmp(title, _(server_title)) ) { strcpy(title, server_title); + //printf("in fix_plugin_title 2\n"); return; } } === ref0: https://www.globalyzer.com/gzserver/help/reference/localeSensitiveMethods/strcasecmp.html says "I18n Issues The single-byte version of the function, strcasecmp, should not be used for equality comparison, because it will only work with single-byte characters. On ANSI UTF-8 platforms, convert the UTF-8 strings to wide character strings and then call wcscasecmp on the wide strings. " Conversion supposed to be done with https://www.globalyzer.com/gzserver/help/reference/localeSensitiveMethods/mbstowcs.html ref1: https://en.cppreference.com/w/cpp/string/multibyte/mbstowcs says "Notes / In most implementations, this function updates a global static object of type std::mbstate_t as it processes through the string, and cannot be called simultaneously by two threads, std::mbsrtowcs should be used in such cases." so for me in CinGG it crashed badly! ref2: https://en.cppreference.com/w/cpp/string/multibyte/mbsrtowcs |
|
|
There is also https://github.com/fltk/fltk/blob/master/src/fl_utf8.cxx - it says to include "UTF-8 aware strcasecmp - converts to Unicode and tests." |
|
|
There is utf8.h header, it says to provide utf8casecmp (but license is "public domain", not sure what this mean to GPL softaware willing to include such header) https://github.com/sheredom/utf8.h/blob/master/utf8.h |
|
|
Oh, sorry, apparently this function ( fix_plugin_title) works only in non-utf-8 locale .. :/ So, it worked in cp1251 (8bit old russian) but not if I set LANG=ru_RU.utf8 ../bin/cin :( And in itself MWindow::fix_plugin_title uses bstrcasecmp - Cinelerra's specific function supposedly comparing unicode strings ...well, it fails in my case ..:/ And case-insensitive string compare apparently not THAT simple in unicode .. :/ https://stackoverflow.com/questions/11635/case-insensitive-string-comparison-in-c :/ |
|
|
@Andrew-R I have been able to reproduce reliably with the outlined steps. Also, for testing purposes, I uncommented the 2 printf statements to see where it was when it crashed: printf("Title: %s\n", title); mwindow->fix_plugin_title(title); printf("Title_fixed: %s\n", title); It did print out "Title: Auflösen" but never got to "Title_fixed:" P.S. I was using the GIT version as it existed/checked in yesterday with just this patch applied. |
|
|
@Andrew-R In testing this patch I got a SEGV. I will try to repeat the results, but the steps I used are shown below. Thread 1 "cin" received signal SIGSEGV, Segmentation fault. 0x00007ffff7298d28 in __strcpy_avx2 () from /lib64/libc.so.6 Missing separate debuginfos, use: dnf debuginfo-install OpenEXR-libs-2.3.0-5.fc32.x86_64 alsa-lib-1.2.3.2-1.fc32.x86_64 bzip2-libs-1.0.8-2.fc32.x86_64 dbus-libs-1.12.20-1.fc32.x86_64 elfutils-libelf-0.181-1.fc32.x86_64 expat-2.2.8-2.fc32.x86_64 flac-libs-1.3.3-2.fc32.x86_64 fontconfig-2.13.92-9.fc32.x86_64 freetype-2.10.2-1.fc32.x86_64 glibc-2.31-4.fc32.x86_64 gsm-1.0.18-6.fc32.x86_64 ilmbase-2.3.0-4.fc32.x86_64 jbigkit-libs-2.1-18.fc32.x86_64 libICE-1.0.10-3.fc32.x86_64 libSM-1.2.3-5.fc32.x86_64 libX11-1.6.12-1.fc32.x86_64 libX11-xcb-1.6.12-1.fc32.x86_64 libXau-1.0.9-3.fc32.x86_64 libXcursor-1.2.0-2.fc32.x86_64 libXdamage-1.1.5-2.fc32.x86_64 libXext-1.3.4-3.fc32.x86_64 libXfixes-5.0.3-11.fc32.x86_64 libXft-2.3.3-3.fc32.x86_64 libXi-1.7.10-3.fc32.x86_64 libXinerama-1.1.4-5.fc32.x86_64 libXrender-0.9.10-11.fc32.x86_64 libXtst-1.2.3-11.fc32.x86_64 libXv-1.0.11-11.fc32.x86_64 libXxf86vm-1.1.4-13.fc32.x86_64 libasyncns-0.8-18.fc32.x86_64 libdrm-2.4.102-1.fc32.x86_64 libedit-3.1-32.20191231cvs.fc32.x86_64 libffi-3.1-24.fc32.x86_64 libgcc-10.2.1-6.fc32.x86_64 libgcrypt-1.8.5-3.fc32.x86_64 libglvnd-1.3.2-1.fc32.x86_64 libglvnd-glx-1.3.2-1.fc32.x86_64 libgpg-error-1.36-3.fc32.x86_64 libpng-1.6.37-3.fc32.x86_64 libsndfile-1.0.28-12.fc32.x86_64 libstdc++-10.2.1-6.fc32.x86_64 libusbx-1.0.23-1.fc32.x86_64 libuuid-2.35.2-1.fc32.x86_64 libvdpau-1.4-2.fc32.x86_64 libxcb-1.13.1-4.fc32.x86_64 llvm-libs-10.0.1-4.fc32.x86_64 lz4-libs-1.9.1-2.fc32.x86_64 mesa-dri-drivers-20.2.2-1.fc32.x86_64 mesa-libGL-20.1.9-1.fc32.x86_64 mesa-libGLU-9.0.1-2.fc32.x86_64 mesa-libglapi-20.1.9-1.fc32.x86_64 numactl-libs-2.0.12-4.fc32.x86_64 pcre2-10.35-7.fc32.x86_64 pulseaudio-libs-13.99.1-4.fc32.x86_64 sssd-client-2.3.1-2.fc32.x86_64 xz-libs-5.2.5-1.fc32.x86_64 (gdb) bt #0 0x00007ffff7298d28 in __strcpy_avx2 () from /lib64/libc.so.6 0000001 0x0000000000bdd4c5 in MWindow::fix_plugin_title (title=0x7fffe9204aad "Auflösen") at mwindow.C:938 0000002 0x0000000000baa12a in TransitionDialogThread::start (this=0x6e77140) at menuattachtransition.C:87 0000003 0x0000000000ba9f10 in MenuAttachTransition::handle_event (this=0x6e76cb0) at menuattachtransition.C:54 #4 0x0000000000d9ecaf in BC_MenuItem::dispatch_button_release (this=0x6e76cb0, redraw=@0x7fffffffc23c: 0) at bcmenuitem.C:223 0000005 0x0000000000da01af in BC_MenuPopup::dispatch_button_release (this=0x6dfab10) at bcmenupopup.C:171 0000006 0x0000000000d9ca58 in BC_Menu::dispatch_button_release (this=0x6dfbb80) at bcmenu.C:128 0000007 0x0000000000d9db9a in BC_MenuBar::button_release_event (this=0x6e91c60) at bcmenubar.C:149 0000008 0x0000000000dd6da4 in BC_WindowBase::dispatch_button_release (this=0x6e91c60) at bcwindowbase.C:1613 #9 0x0000000000dd6cb0 in BC_WindowBase::dispatch_button_release (this=0x6974060) at bcwindowbase.C:1599 0000010 0x0000000000dd5673 in BC_WindowBase::dispatch_event (this=0x6974060) at bcwindowbase.C:1078 0000011 0x0000000000dd4579 in BC_WindowBase::run_window (this=0x6974060) at bcwindowbase.C:743 #12 0x0000000000be5ac1 in MWindow::run (this=0x7fffffffc410) at mwindow.C:2962 #13 0x0000000000b9a012 in main (argc=2, argv=0x7fffffffdf38) at main.C:391 Steps: 1) in English, brought up small video with 2 audio tracks 2) cut out spot in middle and dragged IrisSquare transition from Resources window 3) checked Video pulldown, Attach Transition, just to see that default transition was Dissolve and then took down that menu 4) in Settings->Preferences, switched language from en to de (German) 5) used Video pulldown for Attach Transition and got SEGV |
|
|
Please try this patch (it restores English transition names in dialog regardless of lang. settings, probably I can apply it at very send event, but for now it seems to workaround issue as is) Also, thanks for testing!
fix_menuattachtransition_multilang_c.diff (844 bytes) |
|
|
imagen.png (30,905 bytes) |
- Anonymous
