Re: [Klog-devel] Klog-devel Digest, Vol 4, Issue 3

[Andrew Goldie]

Jaime,

A couple of things:

1. Is it worth making QLinedit's that are read only a different background  
colour so as users know they can't enter data into them? i.e. the ones on the 
search tab.

2. The import TLF is still in the menu.

3. Frequency cannot be updated manually. Probably got something to do with 
hamlib. Perhaps not a bug but feature request?

I have been thinking about how we go about installing files that Klog needs 
(ie klog-contest-cabrillo-formats.txt). The options I have found so far are:

1. Use KConfig class - this would mean that we could copy or access these 
files in the $KDEHOME directory. It would be fairly easy to use but if we want 
to use Klog on Windows or possibly other X11 window managers then this method 
probably wouldn't work.

2. Create a CMake install line that creates and installs the files in the 
users home directory when the run make install. This would be easy and would 
work on both Windows and Linux but if another user runs Klog then the 
directory wouldn't be there for that user.

3. Get Klog to create a dummy file when it creates the first .klog directory 
and then give the users the opportunity to download the file from somewhere. 
This would be fairly easy but we would have to add another setup option to add 
download sites.

4. Hard code in the INSTALL_DIR. This can be done using CMake. Create a file 
that holds Klogs global defines i.e. define.h :

#define INSTALL_DIR "${CMAKE_INSTALL_PREFIX}"
#define CABRILLO_FILE "${CMAKE_INSTALL_PREFIX}/etc/klog-contest-cabrillo-
formats.txt"

then as part of the build add the following line to the CMakeLists.txt:

configure_file(${CMAKE_SOURCE_DIR}/definitions.h 
${CMAKE_SOURCE_DIR}/definitions.h1)

This will replace the INSTALL_DIR define with the installation path as 
configured by -DCMAKE_INSTALL_PREFIX=

We could then refer to file paths from within the code using this define i.e 
QFile installFile (INSTALL_DIR + "/etc/klog-configurations.txt"). This way the 
installation directory would always be hard coded in and so we would always 
know where to reference a file.

What do you think? Do you have a preference? Option 4 is probably a little bit 
more work but it would mean that there is a better chance of Klog working on 
Windows.

After Wednesday this week I won't be around until after the New Year as I'm 
off on holiday for Xmas and New Years. I'll also won't have access to a 
computer so no email!  Please let me know if there is anything else you would 
like me do do before then.

Thanks

Andrew

On Mon, 21 Dec 2009 00:01:06 address@hidden wrote:
> Send Klog-devel mailing list submissions to
>       address@hidden
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>       https://lists.berlios.de/mailman/listinfo/klog-devel
> or, via email, send a message with subject or body 'help' to
>       address@hidden
> 
> You can reach the person managing the list at
>       address@hidden
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Klog-devel digest..."
> 
> 
> Today's Topics:
> 
>    1. KLog 0.5.0 RC2 (Jaime Robles)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Sun, 20 Dec 2009 11:45:49 +0100 (CET)
> From: "Jaime Robles" <address@hidden>
> Subject: [Klog-devel] KLog 0.5.0 RC2
> To: address@hidden
> Message-ID:
>       <address@hidden>
> Content-Type: text/plain;charset=iso-8859-1
> 
> Good morning Andrew,
> 
> I have just updated new code that tries to fix the last pending bug.
> 
> In my opinion what we should try is to:
> 
> 
> 1.- Remove ALL the code regarding the DXMap.
> 2.- Extract the po information and email to the translators asking for
> translation. (already done)
> 3.- Test the code without adding ANY new feature.
> 4.- Fix any important last-minute bug that may appear.
> 
> What do you thing?
> Maybe next week we can release 0.5.0.
> 


Attention:
This email may contain information intended for the sole use of
the original recipient. Please respect this when sharing or
disclosing this email's contents with any third party. If you
believe you have received this email in error, please delete it
and notify the sender or address@hidden as
soon as possible. The content of this email does not necessarily
reflect the views of Solnet Solutions Ltd.