openknights-neverdev Mailing List for OpenKnights

I just did some larger checkins to the old openknights repository and  
then an import/export of the neveredit module into the new  
repository. I will soon remove all files from the old repository and  
replace them with a note to please use the new repository.

Please check out the source from the new location and make sure  
everything got transferred ok.

The new CVSROOT for developers is

:ext:cvs.sf.net:/cvsroot/neveredit

This also marks the last message I intend to send to the openknights  
mailing list. I'll probably shut it down soon.

As for new features, I added lazy loading of notebook pages to avoid  
the long delays on map loading where possible. There's also a new  
menu item for adding a file as a resource into a module. Both are  
likely still buggy.

Peter

Hello,
I'm maybe the other than you two that uses the cvs version,
but I don't bother if you break it as I always keep one or two
working version under my hand (just in case, I rarely have to
use them).
but as i'm not suscribed here, I wasn't aware of that change.
I won't suscribe here, but instead one the new lists, which
will probably stay longer.

I'm happy to see plans for future, as it's a guarantee for
longer existence.

but before you release one 0.8.1, I'd like to have you
consider just two changes. those are not heavy (one line
each), but may prove very useful from a user point of view.
Maybe they go against your planed changes, and then I would
understand it :)

I'd propose to insert one line in game/Module.py, between
lines 16 an 17 (to preserve alphabetical order) :

    ifoPropList =3D {
>       "Mod_CustomTlk":"CExoString",
        "Mod_DawnHour":"Integer,0-23",

Given the way you've written neveredit, that automatically add
one text box in the module propreties (but here, i won't learn
you anything...). That doesn't allow you to load the custom
tlk, but just to add, remove or change it in the module. And
that would be really useful, for a one line change.

The second changes the way the on_* scripts are chosen. It
replaces the wx.Choice control (in which you can only choose
in the existing proposition), with a wx.ComboBox, which allows
you to either choose in the list, or type it in a text field.
It changes the ui/PropWindow.py, the 3rd line of the function
PropWindow.makeResRefControl :

            control =3D wx.Choice(parent,-1,choices=3DkeyList)   
            


would be replaced by

control =3D wx.ComboBox(parent,-1,choices=3DkeyList,
style=3Dwx.CB_DROPDOWN)

And the line      
            wx.EVT_CHOICE(self,control.GetId(),self.controlUsed)

would be replaced by

wx.EVT_COMBOBOX(self, contro.getId(), self.controlUsed)
wx.EVT_TEXT_ENTER(self, contro.getId(), self.controlUsed)

(though for the event handling, I'm not really sure, I'm just
beginning in wx)

There would be a third such change, but I didn't yet find how
to do it.

I hope I don't annoy you too much!=0A=0AAcc=E9dez au courrier =E9lectroni=
que de La Poste : www.laposte.net ; =0A3615 LAPOSTENET (0,34=80/mn) ; t=E9=
l : 08 92 68 13 50 (0,34=80/mn)=0A=0A

On 3 ao=FBt 05, at 16:52, nev...@ma... wrote:

> Not entirely sure. I have some changes sitting in my working copy =20
> that I'd like to check in, but that are still so buggy that I'm =20
> embarrassed. I'll switch over CVS either when I overcome my =20
> embarrassment or fix the bugs :).

I don't think anyone, except us, is using code from CVS (otherwise =20
speak up now! ;-) ), so I think you should go away and make the =20
commit and the switch.

Alan

--=20
The hacker: someone who figured this out and made something cool happen.
.O.
..O
OOO

>
>> 3) I have some pending checkins to the current CVS repository.  
>> After that, the CVS repository will move to the new sourceforge  
>> project. Alan, please let me know if you have pending changes that  
>> you can't commit yet.
>>
>
> I have nothing uncommitted. When do you plan to switch CVS?

Not entirely sure. I have some changes sitting in my working copy  
that I'd like to check in, but that are still so buggy that I'm  
embarrassed. I'll switch over CVS either when I overcome my  
embarrassment or fix the bugs :).

Peter

On 2 ao=FBt 05, at 19:29, nev...@ma... wrote:

> Hello.
>
> There will be major changes in how neveredit is publicly =20
> represented and hosted in the next month or so. As only Alan is =20
> actively doing development it'll mainly affect him, but I wanted to =20=

> post here for the record
>
> Here are some of the things that will change:
> 1) neveredit will move to its own sf project called - you guessed =20
> it, 'neveredit

Good news.

> 2) the new neveredit homepage is up (but still under development) =20
> at neveredit.sourceforge.net. It's a wiki again, so feel free to =20
> contribute.

It looks nice.

> 3) I have some pending checkins to the current CVS repository. =20
> After that, the CVS repository will move to the new sourceforge =20
> project. Alan, please let me know if you have pending changes that =20
> you can't commit yet.

I have nothing uncommitted. When do you plan to switch CVS?

> 4) Soon after the CVS move, I'll package up a neveredit 0.8.1 and =20
> release it so that there's a file release on the new site. I'm =20
> hoping this can include a preliminary version of the new =20
> conversation editor. Alan?

It's usable to look at a conversation, correct the strings, create =20
strings for new languages (there are a couple small bugs that I =20
should look at, one of them require Python expertise). What one =20
cannot do is: create a new conversation (easy), add a child node =20
(easy), add a link (easy for the code, harder for the UI), and =20
deletions (tricky).

> 8) there are 4 new mailing lists on the new site. I will shut down =20
> the old ones (including the one I'm posting on) soon. The new ones are
>    neveredit-users - general discussion, problem reports (replaces =20
> forums, BW forums, centralized)
>    neveredit-devel - for people working on/with neveredit code
>    neveredit-announce - I'll announce released and other big new here
>    neveredit-commits - CVS commits
>    Please subscribe yourself to any/all of these if you want to =20
> stay informed.

Will do ;-)

> Exciting times are ahead!

And congratulations for you PhD.

Alan

--=20
The hacker: someone who figured this out and made something cool happen.
.O.
..O
OOO

Hello.

There will be major changes in how neveredit is publicly represented  
and hosted in the next month or so. As only Alan is actively doing  
development it'll mainly affect him, but I wanted to post here for  
the record

Here are some of the things that will change:
1) neveredit will move to its own sf project called - you guessed it,  
'neveredit
2) the new neveredit homepage is up (but still under development) at  
neveredit.sourceforge.net. It's a wiki again, so feel free to  
contribute.
3) I have some pending checkins to the current CVS repository. After  
that, the CVS repository will move to the new sourceforge project.  
Alan, please let me know if you have pending changes that you can't  
commit yet.
4) Soon after the CVS move, I'll package up a neveredit 0.8.1 and  
release it so that there's a file release on the new site. I'm hoping  
this can include a preliminary version of the new conversation  
editor. Alan?
5) I currently only have Alan added as a developer on the new sf  
site. Let me know if (and why) anybody else still on this list should  
be added.
6) after the the web page is moved, I will take most neveredit  
related material out of the old openknights site and link to the new  
site instead.
7) after the CVS tree has moved, I'll delete the old tree (CVS  
delete, old versions will be retrievable)
8) there are 4 new mailing lists on the new site. I will shut down  
the old ones (including the one I'm posting on) soon. The new ones are
    neveredit-users - general discussion, problem reports (replaces  
forums, BW forums, centralized)
    neveredit-devel - for people working on/with neveredit code
    neveredit-announce - I'll announce released and other big new here
    neveredit-commits - CVS commits
    Please subscribe yourself to any/all of these if you want to stay  
informed.

Exciting times are ahead!

Peter

Le 11 juil. 05 =E0 22:51, nev...@ma... a =E9crit :

> BTW,
>
> why does nevercommand need to execute as pythonw? It shouldn't use =20
> the windowing system...

It's not so much running with the windowing system but making sure =20
I'm running OS X (and not Fink) python.

I guess replacing pythonw by /usr/bin/python would also work. Is it =20
costing more to call pythonw?

Alan

BTW,

why does nevercommand need to execute as pythonw? It shouldn't use  
the windowing system...

Peter

On Jul 9, 2005, at 4:23 AM, Alan Schmitt wrote:


> Update of /cvsroot/openknights/neveredit/run
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv21220/run
>
> Modified Files:
>     nevercommand
> Log Message:
> nevercommand re-executes as pythonw on the Mac
> (I needed to extract a bunch of DLG resoures out of a mod, and it  
> worked great)
>
>
>
> Index: nevercommand
> ===================================================================
> RCS file: /cvsroot/openknights/neveredit/run/nevercommand,v
> retrieving revision 1.2
> retrieving revision 1.3
> diff -C2 -d -r1.2 -r1.3
> *** nevercommand    12 Mar 2005 17:46:15 -0000    1.2
> --- nevercommand    9 Jul 2005 08:23:05 -0000    1.3
> ***************
> *** 34,37 ****
> --- 34,43 ----
>   from optparse import OptionParser
>
> + def reexec_with_pythonw():
> +     if sys.platform == 'darwin' and\
> +            not sys.executable.endswith('MacOS/Python'):
> +         print >>sys.stderr,'re-executing using pythonw'
> +         os.execvp('pythonw',['pythonw',__file__] + sys.argv[1:])
> +
>   def lookup(extensions):
>       global r
> ***************
> *** 67,73 ****
> --- 73,87 ----
>           parser.add_option('-- 
> devel',action='store_true',dest='devel',
>                             help='run in development mode (does not  
> use installed version)')
> +         parser.add_option('-- 
> disable_pythonw',action='store_true',dest='no_pythonw',
> +                           help='disable automatically running  
> pythonw on Mac')
> +
>           (options,args) = parser.parse_args()
> +
> +         if not options.no_pythonw:
> +             reexec_with_pythonw()
> +
>           if options.devel:
>               sys.path.insert(0,getNeverDir(os.getcwd()))
> +
>           try:
>               from neveredit.file.ERFFile import ERFFile
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the 'Do More With Dual!' webinar  
> happening
> July 14 at 8am PDT/11am EDT. We invite you to explore the latest in  
> dual
> core and dual graphics technology at this free one hour event  
> hosted by HP,
> AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
> _______________________________________________
> Openknights-commits mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openknights-commits
>
>

Le 9 juil. 05 =E0 17:00, nev...@ma... a =E9crit :

> It's been quiet, but won't be for long anymore.
>
> I'm scheduled to finish my Ph.D. this month. I'll be home in =20
> Germany for much of August, partially working on neveredit when I =20
> feel like it. Generally, I'll have more time to commit to it again.

Great news, good luck for your Ph. D. Are you doing it in the US?

> I'm also going to move neveredit to its own sourceforge project and =20=

> give it its own website so it's easier to find and talk about. I've =20=

> already registered 'neveredit' as an sf project.

It sounds great.

By the way, after migrating to Tiger (Mac OS 10.4) I reinstalled =20
everything from scratch, and it was almost easier than last time:
- The good: after installing some compatibility package (that adds =20
the python path that Panther used), I was able to install every =20
package from http://pythonmac.org/packages/ . So there is no package =20
that needs to be installed from source anymore.
- The bad: to compile nwnsscomp, one need cocom, and this does not =20
compile anymore on the Mac. However it fails after msta is compiled, =20
so copying the binary to somewhere it can be found makes the =20
compilation of nwnsscomp possible. It would be great not to have to =20
depend on cocom (or have a binary release of nwnsscomp if it does not =20=

change too often).

I'm going to keep working on the conversation editor, but as you can =20
see I have not contributed much. But as I'm using it for some things, =20=

I will have to improve it ;-)

Alan

It's been quiet, but won't be for long anymore.

I'm scheduled to finish my Ph.D. this month. I'll be home in Germany  
for much of August, partially working on neveredit when I feel like  
it. Generally, I'll have more time to commit to it again.

I'm also going to move neveredit to its own sourceforge project and  
give it its own website so it's easier to find and talk about. I've  
already registered 'neveredit' as an sf project.

Exciting times are ahead,

Peter

Le 8 mai 05, =E0 18:59, neveredit a =E9crit :

> Jason seems right - Remove is supposed to destroy the child, but=20
> doesn't for some reason in the non-sizer case. It might be that the=20
> python version only actually deletes the C++ object when it's garbage=20=

> collected in python, rather than immediately like in C++. I'd have to=20=

> look at the wxPython code.
>
> In any case, Alan, can you try replacing Remove() by Detach()?
>
> See=20
> http://www.wxwidgets.org/manuals/2.6.0/wx_wxsizer.html#wxsizerremove

OK, I did that, and it seems to work great. It's committed. Thanks for=20=

the explanation.

My only issue is: how am I supposed to destroy my own control that is=20
built out of a bunch of BoxSizers and a few controls? For the moment I=20=

do:

     def Destroy(self):
         self.label.Destroy()
         self.textCtrl.Destroy()
         self.langIDChoice.Destroy()
         self.genderChoice.Destroy()
         wx.BoxSizer.Destroy(self)

in the definition of my Control (which extends BoxSizer), but I do not=20=

detach nor destroy any of the inner boxes, and I don't know if it's a=20
good thing.

Alan

Jason seems right - Remove is supposed to destroy the child, but 
doesn't for some reason in the non-sizer case. It might be that the 
python version only actually deletes the C++ object when it's garbage 
collected in python, rather than immediately like in C++. I'd have to 
look at the wxPython code.

In any case, Alan, can you try replacing Remove() by Detach()?

See http://www.wxwidgets.org/manuals/2.6.0/wx_wxsizer.html#wxsizerremove

Peter

On May 8, 2005, at 12:47 PM, jason mazzotta wrote:

> Of course, I guess that does then beg the  question, why didn't the 
> loop just prior to it raise the same exception?
>
> Jason
> On May 8, 2005, at 4:31 AM, Alan Schmitt wrote:
>
>> Hi,
>>
>> In order to be able to extend the CExoLocString control, I create a 
>> new class that embeds the textCtrl in a BoxSizer (so that we can 
>> easily add labels or buttons or other things).
>>
>> Unfortunately I have some trouble with the following piece of code:
>>
>>     def cleanPropPage(self):
>>         '''Clean up the prop page, removing all labels and 
>> controls.'''
>>         for l in self.propLabels:
>>             self.propGrid.Remove(l)
>>             l.Destroy()
>>         for c,p in self.propControls.values():
>>             self.propGrid.Remove(c.control)
>>             c.control.Destroy()
>>
>> The problem is the following: with my CExoLocString control, it seems 
>> that the self.propGrid.Remove destroys something, because I get:
>>
>> Traceback (most recent call last):
>>   File "/Users/schmitta/src/neveredit/ui/NeverEditMainApp.py", line 
>> 765, in treeSelChanged
>>     self.props.makePropsForItem(data,self)
>>   File "/Users/schmitta/src/neveredit/ui/PropWindow.py", line 106, in 
>> makePropsForItem
>>     self.cleanPropPage()
>>   File "/Users/schmitta/src/neveredit/ui/PropWindow.py", line 405, in 
>> cleanPropPage
>>     c.control.Destroy()
>>   File "//Library/Python/2.3/wx-2.5.3-mac-unicode/wx/_core.py", line 
>> 10728, in __getattr__
>>     raise PyDeadObjectError(self.attrStr % self._name)
>> wx._core.PyDeadObjectError: The C++ part of the CExoLocStringControl 
>> object has been deleted, attribute access no longer allowed.
>>
>> So I tried not to remove it (that is have the c.control.Destroy() 
>> call if the object is _not_ a CExoLocStringControl), but then I still 
>> see the TextCtrl embedded in the CExoLocStringControl when I switch 
>> pages.
>>
>> The solution that I've found is very ugly:
>>
>>     def cleanPropPage(self):
>>         '''Clean up the prop page, removing all labels and 
>> controls.'''
>>         for l in self.propLabels:
>>             self.propGrid.Remove(l)
>>             l.Destroy()
>>         for c,p in self.propControls.values():
>>             # FIX: this is very ugly, but I don't know how to make it 
>> work otherwise
>>             if c.control.__class__ == CExoLocStringControl:
>>                 c.control.destroy()
>>             self.propGrid.Remove(c.control)
>>             # Somehow the CExoLocString control is already destroyed 
>> here
>>             if c.control.__class__ != wx._core._wxPyDeadObject:
>>                 c.control.Destroy()
>>
>> where c.control.destroy() is a function of CExoLocStringControl that 
>> destroys the TextCtrl widget.
>>
>> I don't know what is going on. If someone can explain me how I should 
>> do this, I'd be very glad.
>>
>> Alan
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.
> Get your fingers limbered up and give it your best shot. 4 great 
> events, 4
> opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
> win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
> _______________________________________________
> openknights-neverdev mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openknights-neverdev

Of course, I guess that does then beg the  question, why didn't the 
loop just prior to it raise the same exception?

Jason
On May 8, 2005, at 4:31 AM, Alan Schmitt wrote:

> Hi,
>
> In order to be able to extend the CExoLocString control, I create a 
> new class that embeds the textCtrl in a BoxSizer (so that we can 
> easily add labels or buttons or other things).
>
> Unfortunately I have some trouble with the following piece of code:
>
>     def cleanPropPage(self):
>         '''Clean up the prop page, removing all labels and controls.'''
>         for l in self.propLabels:
>             self.propGrid.Remove(l)
>             l.Destroy()
>         for c,p in self.propControls.values():
>             self.propGrid.Remove(c.control)
>             c.control.Destroy()
>
> The problem is the following: with my CExoLocString control, it seems 
> that the self.propGrid.Remove destroys something, because I get:
>
> Traceback (most recent call last):
>   File "/Users/schmitta/src/neveredit/ui/NeverEditMainApp.py", line 
> 765, in treeSelChanged
>     self.props.makePropsForItem(data,self)
>   File "/Users/schmitta/src/neveredit/ui/PropWindow.py", line 106, in 
> makePropsForItem
>     self.cleanPropPage()
>   File "/Users/schmitta/src/neveredit/ui/PropWindow.py", line 405, in 
> cleanPropPage
>     c.control.Destroy()
>   File "//Library/Python/2.3/wx-2.5.3-mac-unicode/wx/_core.py", line 
> 10728, in __getattr__
>     raise PyDeadObjectError(self.attrStr % self._name)
> wx._core.PyDeadObjectError: The C++ part of the CExoLocStringControl 
> object has been deleted, attribute access no longer allowed.
>
> So I tried not to remove it (that is have the c.control.Destroy() call 
> if the object is _not_ a CExoLocStringControl), but then I still see 
> the TextCtrl embedded in the CExoLocStringControl when I switch pages.
>
> The solution that I've found is very ugly:
>
>     def cleanPropPage(self):
>         '''Clean up the prop page, removing all labels and controls.'''
>         for l in self.propLabels:
>             self.propGrid.Remove(l)
>             l.Destroy()
>         for c,p in self.propControls.values():
>             # FIX: this is very ugly, but I don't know how to make it 
> work otherwise
>             if c.control.__class__ == CExoLocStringControl:
>                 c.control.destroy()
>             self.propGrid.Remove(c.control)
>             # Somehow the CExoLocString control is already destroyed 
> here
>             if c.control.__class__ != wx._core._wxPyDeadObject:
>                 c.control.Destroy()
>
> where c.control.destroy() is a function of CExoLocStringControl that 
> destroys the TextCtrl widget.
>
> I don't know what is going on. If someone can explain me how I should 
> do this, I'd be very glad.
>
> Alan

Hi,
	If I'm reading the wxPython API docs right, the behavior you're seeing 
from Remove is correct.  However,  all Controls are a subclass of 
Window, and Window has a Hide  method.  If you call Control.Hide before 
rcsizer.Remove, will that work?  So, something like :

  for c,p in self.propControls.values():
	   c.control.Hide()
             self.propGrid.Remove(c.control)

Jason


On May 8, 2005, at 4:31 AM, Alan Schmitt wrote:

> Hi,
>
> In order to be able to extend the CExoLocString control, I create a 
> new class that embeds the textCtrl in a BoxSizer (so that we can 
> easily add labels or buttons or other things).
>
> Unfortunately I have some trouble with the following piece of code:
>
>     def cleanPropPage(self):
>         '''Clean up the prop page, removing all labels and controls.'''
>         for l in self.propLabels:
>             self.propGrid.Remove(l)
>             l.Destroy()
>         for c,p in self.propControls.values():
>             self.propGrid.Remove(c.control)
>             c.control.Destroy()
>
> The problem is the following: with my CExoLocString control, it seems 
> that the self.propGrid.Remove destroys something, because I get:
>
> Traceback (most recent call last):
>   File "/Users/schmitta/src/neveredit/ui/NeverEditMainApp.py", line 
> 765, in treeSelChanged
>     self.props.makePropsForItem(data,self)
>   File "/Users/schmitta/src/neveredit/ui/PropWindow.py", line 106, in 
> makePropsForItem
>     self.cleanPropPage()
>   File "/Users/schmitta/src/neveredit/ui/PropWindow.py", line 405, in 
> cleanPropPage
>     c.control.Destroy()
>   File "//Library/Python/2.3/wx-2.5.3-mac-unicode/wx/_core.py", line 
> 10728, in __getattr__
>     raise PyDeadObjectError(self.attrStr % self._name)
> wx._core.PyDeadObjectError: The C++ part of the CExoLocStringControl 
> object has been deleted, attribute access no longer allowed.
>
> So I tried not to remove it (that is have the c.control.Destroy() call 
> if the object is _not_ a CExoLocStringControl), but then I still see 
> the TextCtrl embedded in the CExoLocStringControl when I switch pages.
>
> The solution that I've found is very ugly:
>
>     def cleanPropPage(self):
>         '''Clean up the prop page, removing all labels and controls.'''
>         for l in self.propLabels:
>             self.propGrid.Remove(l)
>             l.Destroy()
>         for c,p in self.propControls.values():
>             # FIX: this is very ugly, but I don't know how to make it 
> work otherwise
>             if c.control.__class__ == CExoLocStringControl:
>                 c.control.destroy()
>             self.propGrid.Remove(c.control)
>             # Somehow the CExoLocString control is already destroyed 
> here
>             if c.control.__class__ != wx._core._wxPyDeadObject:
>                 c.control.Destroy()
>
> where c.control.destroy() is a function of CExoLocStringControl that 
> destroys the TextCtrl widget.
>
> I don't know what is going on. If someone can explain me how I should 
> do this, I'd be very glad.
>
> Alan

Le 7 mai 05, =E0 23:03, neveredit a =E9crit :

> I think we should try it out. I actually like the idea of this=20
> preference not being hidden, but we have to make sure it's not=20
> annoying (like having to switch every single pull down to the language=20=

> you want to edit individually if you only want to edit one language).=20=

> So maybe you're right - a local pulldown and a global way to default=20=

> all the local pulldowns to a specific language might be best.

I'll give it a try. Unfortunately I'm going to be immensly busy for the=20=

next 10 days, but it's exciting to be working on Neveredit again. So=20
I'll try to find some time in the evenings.

Alan

Hi,

In order to be able to extend the CExoLocString control, I create a new 
class that embeds the textCtrl in a BoxSizer (so that we can easily add 
labels or buttons or other things).

Unfortunately I have some trouble with the following piece of code:

     def cleanPropPage(self):
         '''Clean up the prop page, removing all labels and controls.'''
         for l in self.propLabels:
             self.propGrid.Remove(l)
             l.Destroy()
         for c,p in self.propControls.values():
             self.propGrid.Remove(c.control)
             c.control.Destroy()

The problem is the following: with my CExoLocString control, it seems 
that the self.propGrid.Remove destroys something, because I get:

Traceback (most recent call last):
   File "/Users/schmitta/src/neveredit/ui/NeverEditMainApp.py", line 
765, in treeSelChanged
     self.props.makePropsForItem(data,self)
   File "/Users/schmitta/src/neveredit/ui/PropWindow.py", line 106, in 
makePropsForItem
     self.cleanPropPage()
   File "/Users/schmitta/src/neveredit/ui/PropWindow.py", line 405, in 
cleanPropPage
     c.control.Destroy()
   File "//Library/Python/2.3/wx-2.5.3-mac-unicode/wx/_core.py", line 
10728, in __getattr__
     raise PyDeadObjectError(self.attrStr % self._name)
wx._core.PyDeadObjectError: The C++ part of the CExoLocStringControl 
object has been deleted, attribute access no longer allowed.

So I tried not to remove it (that is have the c.control.Destroy() call 
if the object is _not_ a CExoLocStringControl), but then I still see 
the TextCtrl embedded in the CExoLocStringControl when I switch pages.

The solution that I've found is very ugly:

     def cleanPropPage(self):
         '''Clean up the prop page, removing all labels and controls.'''
         for l in self.propLabels:
             self.propGrid.Remove(l)
             l.Destroy()
         for c,p in self.propControls.values():
             # FIX: this is very ugly, but I don't know how to make it 
work otherwise
             if c.control.__class__ == CExoLocStringControl:
                 c.control.destroy()
             self.propGrid.Remove(c.control)
             # Somehow the CExoLocString control is already destroyed 
here
             if c.control.__class__ != wx._core._wxPyDeadObject:
                 c.control.Destroy()

where c.control.destroy() is a function of CExoLocStringControl that 
destroys the TextCtrl widget.

I don't know what is going on. If someone can explain me how I should 
do this, I'd be very glad.

Alan

On May 6, 2005, at 3:25 AM, Alan Schmitt wrote:

> Le 5 mai 05, =E0 23:44, neveredit a =E9crit :
>
>> Hi Alan,
>>
>> 1) I believe the windows toolset lets you globally switch the=20
>> language you're currently editing. Do you think a per-string setting=20=

>> is better? Maybe a global setting would be cleaner?
>
> Well, both would be good I guess. I thing a default global preference=20=

> is nice for the display, and allowing to switch languages for a given=20=

> string is very useful when doing the translation of a module. Are you=20=

> afraid this might clutter the interface?
>

I think we should try it out. I actually like the idea of this=20
preference not being hidden, but we have to make sure it's not annoying=20=

(like having to switch every single pull down to the language you want=20=

to edit individually if you only want to edit one language). So maybe=20
you're right - a local pulldown and a global way to default all the=20
local pulldowns to a specific language might be best.

>> 2) I don't totally understand your second point. Neveredit is a=20
>> module editor, so I never intended it to edit parts of modules as=20
>> individual files. But you are reading .dlg resources for you=20
>> conversation editor already, right? So I'm unclear as to what you're=20=

>> asking here. Maybe you can expand on this?
>
> TonyK's AI overrides some of the henchmen conversations, and it does=20=

> so independently of the module. So it uses a ".dlg" file that is=20
> basically just the DLG part of a module (i.e., the DLG GFF written on=20=

> disk). I don't know how to import such a file to be able to edit it in=20=

> a module, or just to open it. (This is not very urgent nor important=20=

> as the person who started the translation already imported it in an=20
> empty module, which is what I'm editing at the moment.)
>

I understand now. We could easily add an option like the 'merge in erf=20=

file' menu item that's 'merge in file resource'. Merging in an erf file=20=

simply loops through the resources in the erf file and adds them one by=20=

one, anyway. I'll try to find time to look into this.

Thanks for all the check-ins, btw!

Peter

Le 5 mai 05, =E0 23:44, neveredit a =E9crit :

> Hi Alan,
>
> 1) I believe the windows toolset lets you globally switch the language=20=

> you're currently editing. Do you think a per-string setting is better?=20=

> Maybe a global setting would be cleaner?

Well, both would be good I guess. I thing a default global preference=20
is nice for the display, and allowing to switch languages for a given=20
string is very useful when doing the translation of a module. Are you=20
afraid this might clutter the interface?

> 2) I don't totally understand your second point. Neveredit is a module=20=

> editor, so I never intended it to edit parts of modules as individual=20=

> files. But you are reading .dlg resources for you conversation editor=20=

> already, right? So I'm unclear as to what you're asking here. Maybe=20
> you can expand on this?

TonyK's AI overrides some of the henchmen conversations, and it does so=20=

independently of the module. So it uses a ".dlg" file that is basically=20=

just the DLG part of a module (i.e., the DLG GFF written on disk). I=20
don't know how to import such a file to be able to edit it in a module,=20=

or just to open it. (This is not very urgent nor important as the=20
person who started the translation already imported it in an empty=20
module, which is what I'm editing at the moment.)

Alan=

Hi Alan,

1) I believe the windows toolset lets you globally switch the language 
you're currently editing. Do you think a per-string setting is better? 
Maybe a global setting would be cleaner?
2) I don't totally understand your second point. Neveredit is a module 
editor, so I never intended it to edit parts of modules as individual 
files. But you are reading .dlg resources for you conversation editor 
already, right? So I'm unclear as to what you're asking here. Maybe you 
can expand on this?

Peter


On May 4, 2005, at 3:21 AM, Alan Schmitt wrote:

> I need to translate some .dlg files (TonyK's AI to be precise), and 
> I'm thinking of doing it using NeverEdit. To do so, two things need to 
> be done:
> - allow the editing of multilingual ExoLocStrings. I know how to 
> change the prop widget to allow this and will do it: I will add two 
> drop down selection, one for language and one for gender, and will 
> fetch / modify the edited text accordingly;
> - be able to open .dlg files. I add a quick try this morning and it 
> did not work. I don't really know what needs to be changed to do it. 
> Thoughts?
>
> Alan

I need to translate some .dlg files (TonyK's AI to be precise), and I'm 
thinking of doing it using NeverEdit. To do so, two things need to be 
done:
- allow the editing of multilingual ExoLocStrings. I know how to change 
the prop widget to allow this and will do it: I will add two drop down 
selection, one for language and one for gender, and will fetch / modify 
the edited text accordingly;
- be able to open .dlg files. I add a quick try this morning and it did 
not work. I don't really know what needs to be changed to do it. 
Thoughts?

Alan

Le 27 avr. 05, =E0 00:46, Sumpfork a =E9crit :

> Update of /cvsroot/openknights/neveredit/game
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv2181/game
>
> Modified Files:
> 	ResourceManager.py
> Log Message:
> eliminate import * usage

Sorry about that, I won't do it again.

Alan

You don't necessarily have to use __getattr__ for this, I just thought=20=

it might be fun :).

__getattr__(self,key) gets called when python can't otherwise resolve a=20=

class attribute of name 'key'.

For example,
class Foo:
    def __init__(self):
        self.bar =3D 'this is bar'
    def __getattr__(self,key):
        return key + ' through __getattr__()'

f =3D Foo()
print f.bar
print f.notbar

will produce:
this is bar
notbar through __getattr__()

So I was thinking that you could analyze the method name being called=20
in the generic change listener and call the appropriate generic method=20=

automagically.

Otherwise, defining subclasses and per-subclass methods is a fine way=20
to go, too.

Peter

Alan Schmitt wrote:

> Le 13 avr. 05, =E0 14:28, neveredit a =E9crit :
>
>> Oh, and VisualChangeListener looks used to me:
>
>
> Oops, I had not grepped the correct thing.
>
> I did a baby step: I split out the visual change/resource list=20
> listener and notifier stuff. The problem is that, for the next step=20
> (unification of property listener with visual change listener), I do=20=

> not understand how __getattr__ works.
>
> Alan

Le 13 avr. 05, =E0 14:28, neveredit a =E9crit :

> Oh, and VisualChangeListener looks used to me:

Oops, I had not grepped the correct thing.

I did a baby step: I split out the visual change/resource list listener=20=

and notifier stuff. The problem is that, for the next step (unification=20=

of property listener with visual change listener), I do not understand=20=

how __getattr__ works.

Alan=

Well, same for me. Between a pending Ph.D. defence, a sudden move to a 
new apartment and various conference deadlines I haven't had time to do 
squat. I can't even guarantee that I'll find more time soon, but so 
things go. Do go ahead and continue if you find time, though. I'll keep 
responding to your thoughts here and I'll try to find time to do my own 
side of things whenever I can.

Oh, and VisualChangeListener looks used to me:

[SANDFLEA:~/src/neveredit] pgorniak% grep VisualChange */*.py
game/ResourceManager.py:class VisualChangeListener:
game/ResourceManager.py:        raise 
NotImplementedError("visualChanged in VisualChangeListener")
game/ResourceManager.py:    def addVisualChangeListener(self,l):
game/ResourceManager.py:    def removeVisualChangeListener(self,l):
ui/MapWindow.py:from neveredit.game.ResourceManager import 
VisualChangeListener
ui/MapWindow.py:class 
MapWindow(GLWindow,Progressor,VisualChangeListener):
ui/MapWindow.py:        
neverglobals.getResourceManager().addVisualChangeListener(self)
ui/MapWindow.py:        
neverglobals.getResourceManager().removeVisualChangeListener(self)
ui/ModelWindow.py:from neveredit.game.ResourceManager import 
VisualChangeListener
ui/ModelWindow.py:class ModelWindow(GLWindow, VisualChangeListener):
ui/ModelWindow.py:        
neverglobals.getResourceManager().addVisualChangeListener(self)
ui/ModelWindow.py:        
neverglobals.getResourceManager().removeVisualChangeListener(self)

Peter

On Apr 13, 2005, at 7:57 AM, Alan Schmitt wrote:

> Hi,
>
> I've been very busy recently and I have not been able to make much 
> progress on the listener changes we talked about and on the 
> conversation editor itself. I started looking at the listener things, 
> but I got stuck because the current classes (VisualChangeListener and 
> ResourceListChangeListener) do not seem to be  used anywhere, so I 
> don't understand how to refactor the code.
>
> I should be able to find some time next week to work on the 
> conversation editor itself.
>
> Alan

Hi,

I've been very busy recently and I have not been able to make much 
progress on the listener changes we talked about and on the 
conversation editor itself. I started looking at the listener things, 
but I got stuck because the current classes (VisualChangeListener and 
ResourceListChangeListener) do not seem to be  used anywhere, so I 
don't understand how to refactor the code.

I should be able to find some time next week to work on the 
conversation editor itself.

Alan