Thread: [Bashburn-info] bbmenu is now modified
Brought to you by:
bashburn
Menu
▾
▴
bashburn-info
|
From: Steven W. O. <st...@sy...> - 2008-09-09 23:39:39
|
to operate the same way as bbconfmenu. Nick, I don't know what the problem was that you had previously described. I saw it so I know you're not hallucinating, but when I made the change to bbmenu, the problem seemed to have been eliminated. PLEASE let me know if you find any problems. Marcus: At the bottom of BashBurn.sh is a variable assignment: bb_main_menu=MAIN We need to add that to the lang files. It is now no longer legal to pass a string value as the title arg to bbmenu. It must now be the name of a variable. One interesting construct was in dealing with a changing value for BBLANG. The apply function for configure (config_apply) calls set_descriptors, which is a nested function inside bbmenu. But config_apply can't reset the values for its caller which is where the main menu originates. So instead of BashBurn calling bbmenu for the main menu, I caused the action for the invocation of the configure menu to make a return. [BTW, I'm painfully aware that what I'm writing is probably not intelligble. More docs will be needed.] Anyways, the main menu now has to be called in an infinite loop so that the main menu will reinitialize the evaluation of the main menu. -- Time flies like the wind. Fruit flies like a banana. Stranger things have .0. happened but none stranger than this. Does your driver's license say Organ ..0 Donor?Black holes are where God divided by zero. Listen to me! We are all- 000 individuals! What if this weren't a hypothetical question? steveo at syslang.net |
|
From: Nick W. <ni...@uk...> - 2008-09-10 06:54:04
|
On Tue, 9 Sep 2008 19:39:43 -0400 (EDT) "Steven W. Orr" <st...@sy...> wrote: > to operate the same way as bbconfmenu. Nick, I don't know what the > problem was that you had previously described. I saw it so I know > you're not hallucinating, but when I made the change to bbmenu, the > problem seemed to have been eliminated. > > PLEASE let me know if you find any problems. Indeed, the earlier issue now seems fixed; The advanced menu with no help text is still apparent, though. But... In advanced menu, if you change something, 'revert changes' doesn't work, and IF you use 'revert changes', 'apply defaults' then doesn't work either. NOT using 'revert changes', all other options appear to work fine, though. I haven't tested this on the main menu. Also a cosmetic change. Why have 'Configure BashBurn' and Advanced bashBurn config.'? We know it is BashBurn... surely just 'Configuration' and Advanced Configuartion' is required here? Nick -- Free Software Foundation Associate Member 5508 |
|
From: Steven W. O. <st...@sy...> - 2008-09-10 14:40:06
|
On Wednesday, Sep 10th 2008 at 02:54 -0000, quoth Nick Warne: =>On Tue, 9 Sep 2008 19:39:43 -0400 (EDT) =>"Steven W. Orr" <st...@sy...> wrote: => =>> to operate the same way as bbconfmenu. Nick, I don't know what the =>> problem was that you had previously described. I saw it so I know =>> you're not hallucinating, but when I made the change to bbmenu, the =>> problem seemed to have been eliminated. =>> =>> PLEASE let me know if you find any problems. => =>Indeed, the earlier issue now seems fixed; The advanced menu with no =>help text is still apparent, though. But... I have just one word: Oops. It's fixed. :-) =>In advanced menu, if you change something, 'revert changes' doesn't =>work, and IF you use 'revert changes', 'apply defaults' then =>doesn't work either. NOT using 'revert changes', all other options =>appear to work fine, though. I haven't tested this on the main menu. Also fixed. Thanks. =>Also a cosmetic change. Why have 'Configure BashBurn' and Advanced =>bashBurn config.'? => =>We know it is BashBurn... surely just 'Configuration' and Advanced =>Configuartion' is required here? Sure. As the changes to bb start to wind down, there are new text strings creeping in and old ones that might want to change. They should be handled in less of an ad hoc manner; If I change a string now, I'm afraid it'll just leave the other languages out of sync. Which brings up a new topic... The way that we're handling the different language problems right now works but it feels somewhat unwieldy. We have strings in lang/English/somefile.lang and then we have copies of the file in lang/!English/somefile.lang . Some of the files are mostly translated. (Good job BTW.) Some languages are there in good shape, but if a string changes, I don't see a system for *knowing* that the other languages have to be followed up. Also, we have a lot of strings that are duplicated, and changing one instance begs the questions whether followup can be managed. So here's the $64 question: Does anyone here have any experience with gettext/msgfmt/po files/pot files/ etc? Should we keep going the way we are? I ask this with no prior experience using pot files. -- Time flies like the wind. Fruit flies like a banana. Stranger things have .0. happened but none stranger than this. Does your driver's license say Organ ..0 Donor?Black holes are where God divided by zero. Listen to me! We are all- 000 individuals! What if this weren't a hypothetical question? steveo at syslang.net |
|
From: Nick W. <ni...@uk...> - 2008-09-10 15:47:14
|
On Wed, 10 Sep 2008 10:40:14 -0400 (EDT) "Steven W. Orr" <st...@sy...> wrote: > On Wednesday, Sep 10th 2008 at 02:54 -0000, quoth Nick Warne: > > =>On Tue, 9 Sep 2008 19:39:43 -0400 (EDT) > =>"Steven W. Orr" <st...@sy...> wrote: > => > =>> to operate the same way as bbconfmenu. Nick, I don't know what the > =>> problem was that you had previously described. I saw it so I know > =>> you're not hallucinating, but when I made the change to bbmenu, > the =>> problem seemed to have been eliminated. > =>> > =>> PLEASE let me know if you find any problems. > => > =>Indeed, the earlier issue now seems fixed; The advanced menu with > no =>help text is still apparent, though. But... > > I have just one word: Oops. It's fixed. :-) > > =>In advanced menu, if you change something, 'revert changes' doesn't > =>work, and IF you use 'revert changes', 'apply defaults' then > =>doesn't work either. NOT using 'revert changes', all other options > =>appear to work fine, though. I haven't tested this on the main > menu. > > Also fixed. Thanks. OK, now this works, we are back to the garbage in the main menu after changing and reverting two values. > =>Also a cosmetic change. Why have 'Configure BashBurn' and Advanced > =>bashBurn config.'? > => > =>We know it is BashBurn... surely just 'Configuration' and Advanced > =>Configuartion' is required here? > > Sure. I just meant: 5) Configuration 6) Advanced Configuration > > As the changes to bb start to wind down, there are new text strings > creeping in and old ones that might want to change. They should be > handled in less of an ad hoc manner; If I change a string now, I'm > afraid it'll just leave the other languages out of sync. > > Which brings up a new topic... The way that we're handling the > different language problems right now works but it feels somewhat > unwieldy. We have strings in lang/English/somefile.lang and then we > have copies of the file in lang/!English/somefile.lang . Some of the > files are mostly translated. (Good job BTW.) Some languages are there > in good shape, but if a string changes, I don't see a system for > *knowing* that the other languages have to be followed up. Also, we > have a lot of strings that are duplicated, and changing one instance > begs the questions whether followup can be managed. > > So here's the $64 question: Does anyone here have any experience with > gettext/msgfmt/po files/pot files/ etc? Should we keep going the way > we are? I ask this with no prior experience using pot files. Ummm. I have never dealt with po files (being English, I never had the cause to, really), but am aware of them and the general way they work. Good time to learn, I guess :-) Nick -- Free Software Foundation Associate Member 5508 |
Thanks for helping keep SourceForge clean.
X