Nicolas Weeger (Laposte | 4 Feb 11:27 2007
Picon

Changelog for maps and archetypes

Hello.

What about we create a ChangeLog file for maps and archetypes too? This way we 
could track what happens more precisely than commit messages.

Also, I suggest we resurrect the Crossfire Traffic 
(http://wiki.metalforge.net/doku.php/crossfire_traffic), for gameplay and 
such changes.

We should could changes like:
* gameplay whanges (like: wraith patch)
* new features (like: apply -b)
* bugfixes
and maybe
* development side (refactoring, ...)

Nicolas
--

-- 
http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref 
de l'aléatoire !]
Mark Wedel | 5 Feb 09:58 2007
Picon

GtkV2 client theme support.


  I've just committed a change to the GTK2 client so it now supports different 
themes.  There are only 2 now (Standard & Black), but should be easy to make 
more.  Various notes:

- The various hard coded values in the client are gone, and are now in the 
themes (fonts and in some places colors).  This means that if you don't install 
the themes, you'll have a plainer looking client.  If you do a 'make install', 
it will install the themes where the client expects to find them.  Your theme 
preference will be stored in the gdefaults2 file, and can be changed in the 
config window.  If no default is specified, it defaults to the Standard theme.

- The 'Standard' theme is a theme that I wrote that tries to match the previous 
hardcode values (red for cursed inventory items, matching colors for text, etc). 
  In addition to the Standard & Black themes, there is also a 'None' theme, 
which basically means don't use any special theme - just get all values from 
system wide theme.  Effect on this is you won't see any colored text in the text 
panes, the inventories won't differ based on magic/cursed/etc status, and stat 
bars will use system default color for progressbars.

- The client does support switching between themes on the fly - no restart 
needed.  Even things like style of the text messages will get updated.  However, 
if you go to the None theme, and then go to another theme, the text messages 
will still all appear in the default color - this is because when switching to 
the None theme, it deletes all the color text tags, where as when switching 
between actual themes, it updates the text tags with new values.

- One case where the new system is slightly lacking compared to old is compound 
status on inventory items - old code had special logic for cursed & magic items 
(drawn in dark navy).  Given there are 5 different status of items right now, I 
(Continue reading)

Lalo Martins | 5 Feb 10:07 2007
Picon

desktop file: help request

Not for the first time, someone came to #crossfire today, requesting help
to install crossfire, and it turned out he already had it, but couldn't
find it.  It turns out we don't ship a .desktop file for the gtk-v2
client, and distros such as ubuntu and fedora won't modify the package to
add one.  There is such a file for the gtk client, but it refers to a
non-existent icon file.

So here's a very simple battle plan:

1: Write a proper .desktop file for gtk-v2; possibly use it as a model to
update the one for gtk too.  I already committed that file.

2: Hook up the build system to install this file to
$PREFIX/share/applications or whatever is the appropriate autotools magic.
I really don't have time to relearn what little autotools I used to know
to do this, so if someone who knows has a few minutes, please help here.

3: The icons should be the ones in pixmaps/*.png, but they are corrupted
-- probably need the right propset to be recognised as binaries.  Could
someone with the svn fu please do this one?

4 (optional): The aforementioned icons are about as pretty as a dog inside
out.  Seems they were drawn at 16 and scaled up.  So if someone with the
talent wants to draw new ones, be my guest.

5: Again, they need to be hooked up to the build system, so that one of
them (presumably the higher resolution) gets installed to
$PREFIX/share/pixmaps/crossfire-client.png

This is somewhat low priority, or I'd take the time to learn how to do it
(Continue reading)

Mark Wedel | 6 Feb 08:31 2007
Picon

Re: desktop file: help request

Lalo Martins wrote:
> Not for the first time, someone came to #crossfire today, requesting help
> to install crossfire, and it turned out he already had it, but couldn't
> find it.  It turns out we don't ship a .desktop file for the gtk-v2
> client, and distros such as ubuntu and fedora won't modify the package to
> add one.  There is such a file for the gtk client, but it refers to a
> non-existent icon file.
> 
> So here's a very simple battle plan:
> 
> 1: Write a proper .desktop file for gtk-v2; possibly use it as a model to
> update the one for gtk too.  I already committed that file.

  Looks good.  I wonder if we should include something to differentiate the gtk1 
& 2 clients.

  On my system, I do have the icon with the gnome menus for the crossfire 
client.  And all it says is 'Crossfire Client'.  If I hover my mouse over it, it 
gives me a description, but still doesn't say anything about what client is.

  Often times on the channel, it is recommended someone use a particular client. 
  As the things go now, other than the person running it, there really isn't 
much client what client they would get.  Even calling it something like 
'Crossfire Client (Gtk2)' would be much more useful.

> 
> 2: Hook up the build system to install this file to
> $PREFIX/share/applications or whatever is the appropriate autotools magic.
> I really don't have time to relearn what little autotools I used to know
> to do this, so if someone who knows has a few minutes, please help here.
(Continue reading)

Mark Wedel | 6 Feb 08:36 2007
Picon

Re: Changelog for maps and archetypes

Nicolas Weeger (Laposte) wrote:
> Hello.
> 
> What about we create a ChangeLog file for maps and archetypes too? This way we 
> could track what happens more precisely than commit messages.

  Perhaps not a bad idea.  There actually is a CHANGES file in the arch 
directory, but tends not to get updated.  One problem is that often times, the 
changes in those seem more trivial, so you get the question of whether there 
should be a change message for them.  There is some understanding that really 
minor changes in the server/client code don't require an update to the changelog 
- I'd say for arch & maps, more trivial changes should be recorded, because the 
number of changes that otherwise match the criteria are not very many.

> 
> Also, I suggest we resurrect the Crossfire Traffic 
> (http://wiki.metalforge.net/doku.php/crossfire_traffic), for gameplay and 
> such changes.

  That seems like a good idea.
Mark Wedel | 6 Feb 09:03 2007
Picon

Re: Data File (Maps, Archetypes) Encodings

Christian Hujer wrote:
> Hello dear co-devs.
> 
> 
> We have a common problem with the text encodings of data files.
> 
> Examples:
> * Daimonin used (until a few minutes ago) the ISO paragraph character 0xA7 for 
> separating a map's sound spec from its name.
> * Daimonin uses the ISO degree character 0xB0 for highlights in messages.
> * Crossfire uses the a circumflex character 0xE2 for the name of a wine in 
> map /maps/scorn/houses/house3.bas2.

  Not sure if still the case, but at one time there were some objects that also 
used special characters - Mjølnir  comes to mind.

> 
> This leads to some problems.
> * Crossfire x11 client displays 0xE2 as a circumflex.
> * Crossfire gtk client displays 0xE2 as ? (tested by Ragnor).

  And it appears in the GTK2 client, it won't draw the entire line/message that 
has the bad character.

> 
> For both projects, it makes sense to rethink the file formats. I see three 
> possible solutions:
> 
> 1. Use US-ASCII text only.
> That means, only data files with bytes 0x13, 0x20-0x7E are valid.
(Continue reading)

tchize | 6 Feb 10:26 2007
Picon

Re: Data File (Maps, Archetypes) Encodings

En l'instant précis du 02/06/07 09:03, Mark Wedel s'exprimait en ces termes:

(OT: Did not post for a long time, hello to everyone)
>   #3 probably makes the most sense, and at least for the gtk2 client, looks like 
> it would actually be handled properly (as the message generated on the wine 
> bottle is about invalid utf8 character).
>
>   Also, I'm not sure how easy #2 is - it is easy from a person writing the maps 
> or archetypes, but as demonstrated, pretty much all clients would have to do 
> special string handling.
>   
Well, it's just a 256 entries table to convert those character to
destination system.
>   #3 does make it harder for people putting the strings in (I'd think the map 
> editors could try to do the right thing in those cases and covert ISO 8859 15 
> characters to unicode)
>   
At least for java editor, it's not a problem. Java natively supports
UTF-8 strings. On the onther hand, java does not support easily
iso-8859-1 or iso-8859-15. Java supports UTF-8 and US-ASCII, the other
encoding formats support is platform dependent.
>   So I'd vote unicode.  I'd suspect that for clients that don't support utf8, 
> things won't really be any more broken than right now - the client would display 
> a funky character instead of the correct one.  But I don't believe that would 
> break any portion of the clients or protocol.
>   
Here is how some special utf-8 characters looks like when drawn in
iso-8859-1
utf-8 stored string: é - à - µ - ù - €
iso-8859-1 read string: é - à - µ - ù - €
(Continue reading)

Nicolas Weeger (Laposte | 6 Feb 19:29 2007
Picon

Re: Data File (Maps, Archetypes) Encodings

Hello.

> My favorite solution would be 3. UTF-8, followed by 1. US-ASCII. I dislike
> 2. ISO-8859-15 very much.

Favorite solution is 3, UTF-8 :)
It works nicely even with non utf8-aware functions (strlen & such), and is 
international so we'll not have any more issues with that :)

Nicolas
--

-- 
http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref 
de l'aléatoire !]

_______________________________________________
crossfire mailing list
crossfire <at> metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
Alex Schultz | 7 Feb 01:34 2007
Picon

Re: Data File (Maps, Archetypes) Encodings

Nicolas Weeger (Laposte) wrote:
>> My favorite solution would be 3. UTF-8, followed by 1. US-ASCII. I dislike
>> 2. ISO-8859-15 very much.
>>     
>
> Favorite solution is 3, UTF-8 :)
> It works nicely even with non utf8-aware functions (strlen & such), and is 
> international so we'll not have any more issues with that :)
Agreed again here, UTF-8 seems like a good idea to me. Seems there's a
strong consensus of most people towards UTF-8

Alex
Lalo Martins | 8 Feb 01:40 2007
Picon

Re: desktop file: help request

On Mon, 05 Feb 2007 23:31:26 -0800, Mark Wedel wrote:
>   Looks good.  I wonder if we should include something to differentiate the gtk1 
> & 2 clients.
> 
>   On my system, I do have the icon with the gnome menus for the crossfire 
> client.  And all it says is 'Crossfire Client'.  If I hover my mouse over it, it 
> gives me a description, but still doesn't say anything about what client is.
> 
>   Often times on the channel, it is recommended someone use a particular client. 
>   As the things go now, other than the person running it, there really isn't 
> much client what client they would get.  Even calling it something like 
> 'Crossfire Client (Gtk2)' would be much more useful.

Since (a) this is the client that we recommend primarily and (b) people's
desktops will more likely be gtk2 than gtk1, I'd argue to leave it as it
is and change the gtk1 entry instead.

The guidelines for writing desktop entries out there generally call for
more descriptive, less technical details.  On that spirit, I used the text
from the homepage for the "comment" field, rather than the text in the gtk
client's desktop file.

Another alternative is to use Name and GenericName keys:

Name=Crossfire gtk-v2 Client
GenericName=Crossfire Client

Although that sounds to me like a stretch of the intended usage.

See also below for more on that.
(Continue reading)


Gmane