[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xlog-discussion] UTF8 support in 0.9cvs, and other wishes
Re: [Xlog-discussion] UTF8 support in 0.9cvs, and other wishes
Mon, 11 Aug 2003 19:59:34 +0200
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030714 Debian/1.4-2
Stephane Fillod wrote:
I've been doing some work on the CVS version of xlog, like adding
support for TRLog (esp. for TLF) and EDI (VHF and higher contest format
recommanded by IARU region 1). Propagation is amazing on these bands.
Since xlog has been converted to gtk2, the appearance of the font layout is
not the same as in previous versions, and xlog does not support any more
letters with accents. Actually, if I enter accents in the QSO window,
they are handled fine. However, if the accent is autogenerated like the
'DATE' field or is coming from a log file, then the string is truncated
and I get plenty of the following message in the terminal that started
** (xlog:1850): WARNING **: Invalid UTF8 string passed to
I get also some of this:
** (xlog:1850): CRITICAL **: file pango-layout.c: line 1715 (pango_layout_get_cursor_pos):
assertion `index >= 0 && index <= layout->length' failed
anyway, a bit of googling brought me to this page:
which basically instruct to convert strings from local representation to
tmp = g_strdup (g_locale_to_utf8("hello world", -1,
NULL, NULL, NULL));
g_object_set (G_OBJECT(window), "title", tmp, NULL);
Since I don't know much about the gtk part in xlog, I would prefer let you
see what can be done on this topic.
Okay, fixed in CVS, please check-out a new log.c and load a log with
french characters. I am only testing date, name, qth, freefield1,
freefield2 and remarks fields for foreign characters and convert them to
UTF-8. I guess the other fields should be safe. When you save the log,
these fields are converted back again to your locale, so you can keep on
using your favourite text editor.
* When I change the theme color in the preferences, everything is
changed but the locator "window". Is it possible to fix this?
Must have overseen this. Thanks.
* Since the gtk2 convertion, a lot more space is wasted between rows in
the log window. For example, with previous version, I was able to see
35+ rows in the log window. Now, 20 rows barely show, even tough my font
size is 10. This "interline" space gives even more trouble to the
QSO window, where all the fields+DXCC window+locator window do not fit
in the window/screen height. Too bad, on top of that, this leaves no room
for the "worked before" window :( I can send you screenshots if you are
not experiencing this problem.
Fonts are handled by the GTK theme engine. When you use the gnome2
desktop, start up gnome-font-properties. Otherwise, edit ~/.gtkrc-2.0
and add a line like:
gtk-font-name = "Times New Roman 14"
Or whatever. GNOME 2 applies its own settings to GTK2 programs with the
gnome-settings-daemon. When the daemon is running, GTK2 programs will
use the GNOME settings instead of those present in .gtkrc-2.0.
* BTW, the workedb4 feature is great. I love it.
Maybe adding a keyboard shortcut to it would be nice too.
Having the close button of the window much thiner would help
minimizing the previous problem.
Also remembering the window geometry (size and position) would be
nice, as well as starting the find at window opening.
I could remove the close button altogether, so you can close the
workedb4 dialog by clicking on the window-close (top-right) X. This will
save a lot of space.
Okay about the geometry and startup, will put this in the TODO list.
* The "type and find" feature is groovy. I don't know what others would
think of it, but I would prefer the feature to only fill in the
*empty* fields of the QSO window.
Maybe a tooltip over the checkbox in the preference dialog explaining
shortly what is "type and find" may help newcomers.
This was Luc's idea, it behaves like the kpsk's 'type and find'.
* Some kind of atlas window would be pretty darn cool.
In the preferences, an image filename (jpg or png format)
would be specified with the longitude and latitude of its top left
corner. Then the coordinate of the locator/DXCC would be displayed
in this "atlas" window. Yes, I have various maps hanging on my walls,
sometimes it's fun to stare at them, sometime you have less
time during short openings, etc.
To be more picky, having 2 maps would be better. One for distances
less than, say 2000Km, ie. appropriate for VHF and upper band work,
and a second one for any other distances, ie. the whole world
aka our lonely planet (there has not been any DXpedition to the moon
or mars yet, but we'll modify xlog when it's gonna happen :)
Throw in a checkbox to display only the station in QSO window,
or also all the stations in the current log, and this eye candy
gadget will make more than one young ham dream.
Groovy! I already have been looking at the world factbook, see
If you follow the download link, look for a file called maps.zip on the
second page. They are in the public domain, so we could use them for
xlog. A simple 'atlas' window would display every country as you type
ahead or click on a QSO.
There are also some nice reference maps if you follow the link on the
* A last one from Dave kc1di, collected from another mailing list:
It is also helpful if there is some way to select the log enteries you want
to transfer.. X-log can do Adif but there is as yet not selection process
and that is unfortunate because everytime I want to upload my log info to
Eqsl.cc the entire log has to be reuploaded. For me this is not a great
problem but for DX stations that make thousands of qsos it may infact be a
AFAIAC, it would be better to not implement this selection on the
export, but rather add to xlog the ability to copy part of a log pane
to another - eventually new, - log pane. This would be much more
versatile. Or what about a "split" function? A log would be split
in 2 new logs apart the selected QSO. Well, I don't know really what
would be the best. Personnaly, when I have to do that kind of stuff,
I just fire up vim (or any other text editor) and play with the file.
ASCII file formats are your friends in such case.
So, which one will it be :-)? All of these ideas seem feasible. Dave's
idea seems the easiest to program. Anyone want to comment on this?
By the way, I hope to have a new beta before the end of august. And I am
PG4I now, the dutch telecom decided to give away some nice
callsign-blocks, so I thought might as well get myself a real fast one
(in CW that is, but sounds great in phone too).
73 de Joop PG4I
ex - PA4TU PA3ABA