[ggo-discussion] Re: PlayerManager & gGo

On 22.03.2004, at 08:04, blunt jackson wrote:

> Well, I installed glGo and playermanager, and turned on "Use glGo's
> Playermanager" in gGo->preferences->advanced.

Ok. Wanted to make sure you didn't get that feature enabled without 
really wanting it. That would be very confusing.

> Still, my custom flags do not show up in gGo, and text is not saved.

Hmm wired. Works here, just tried. Which OS do you use? If Windows, 
which version?

> How do I tell gGo where playermanager and its database actually are?

That *should*  be done automatically. By default the file is in 
$HOME/glGo/players.db or $HOME/.glGo/players.db (that dot is only on 
Unix systems, not Win32). On Unix that should map to 
/home/username/.glGo, on Win NT/2k/XP to C:\Documents and 
Settings\Username\glGo, on Win 9x/ME it's an invalid path and lookup 
will fail. gGo, glGo and playermanager try to find the file there, so 
if one can read it, the others should theoretically, too. Well, 
theoretically... :)

> Or is there some
> requirement that gGo and glGo/playermanager be installed in
> the same location?

No... Only requirement is that something like $HOME exists in the OS 
(not the case on Win9x/ME as mentioned before).

> Note that I had the setting for playermanager set to on previously
> because I thought it was a part of gGo. You could definitely use
> more documentation here.

Agreed. Next gGo release.


> Or maybe settle on a single integrated product?

Actually the idea is to avoid integrating the player database code in 
gGo and glGo, as that would mean to write it twice, and maintain it 
twice if something changes or is added. The code which accesses the 
database is written in Python, and that can be nicely integrated in 
Java and C++. So both gGo and glGo use the same code to access the file 
with minimal boilerplate code in Java/C++. When I integrated the stuff, 
I would basically have two separate built-in modules for gGo/glGo and 
that just calls for some incompatibilities and trouble. Also rewriting 
the same GUI in Java just to have it in Java sounds like unnecessary 
work I rather invest elsewhere.


> In any case, if playermanager is not available, or cannot
> be found, some sort of warning that the functionality won't work
> would be very handy!

Agreed. Good point. Actually gGo should be able to create the database 
file and use it. But without the playermanager functionality is 
limited, so some user feedback would be needed.


> Any ideas what might be going on here?

Not right now, it works here for me. I don't want to say it also must 
work for you, but I cannot help with what I cannot reproduce at the 
moment. You could look at the gGo logfile ($HOME/.ggo.log), which 
should have some line like this when the IGS terminal window is opened 
(then it is decided if the playermanager or built-in list is used and 
the friends/bozo lists are loaded):

Using glGo PlayerDB system
Using playerdatabase /Users/peter/.glGo/players.db

Look what it prints for you and if that directory exists. Please tell 
me what that line reads on your box, what operating system is running 
and where the real file is. There must be a real file somewhere 
according to your next sentence:


> PS. playermanager *does* work in glGo, and glGo itself looks fairly 
> nice.

Then gGo should work as well. In theory. Obviously not in practice. 
Let's figure out why. If you send me the part of your gGo logfile, it 
should help.


> I would be tempted to use that instead of qGo, but
> it doesn't seem to have a 'tabbed' view -- and I detest all those
> blasted windows.

Tabbed mode for glGo is currently in work. Probably not ready for next 
release, it is quite some tricky work to get tabbed and windowed mode 
into the same interface and not produce too many problems. It's the 
most asked for feature request for glGo I get at the moment, I am aware 
most users prefer the tabbed mode. I personally detest blasted tabs, I 
prefer the multiple windows. As I am my first user, multiple windows 
were implemented first. :) But that is a matter of taste, and can 
hardly be discussed as "right" or "wrong". I think the solution like in 
gGo to let the user decide himself is good.
Overall glGo isn't finished yet and very much work in progress. 
Certainly not as mature and stable as gGo, though it should be usable 
by now.


  Peter

Other related posts: