Contest logging project

Contest logging project

[Nate Bargmann]

Hi all.

I've starting hacking on a contest logger.  I am writing it in C++ and
wxWidgets and primarily targeting Linux at this time.  I've been working
on this on and off for about six weeks and have reached a point where I
am running up against my inexperience in both C++ and application
development.

I am looking for whomever may be interested in helping to develop this
thing into something that actually works!  I am looking specifically for
persons with knowledge of C++ and wxWidgets and who are interested in a
contest logger with a logging UI based on the classic CT.

My motivation is to be able to use the UI I and many others are
comfortable with.  TR and N1MM's ESM UI are just not comfortable to me.
Beyond that requirement the only other requirement is data integrity
using some sort of database container.

At this point the program is nothing more than a few windows that are a
sort of prototype of where I want to go.  The program does not accept
nor store data at this time and such niceties as duping and country
verification are far off as is rig control, et. al.

Given sufficient interest in the project I will push it up to Github and
look into starting a development mailing list.  At this time it is not
useful so potential users will be disappointed.

Please reply to me direct if interested.

73, de Nate, NØNB >>

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Ham radio, Linux, bikes, and more: http://www.n0nb.us
--
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Ubuntu-hams] Contest logging project

[Martin Ewing]

[-- Attachment #1: Type: text/plain, Size: 2666 bytes --]

Nate,

Good luck on this.  If it was me, and I've thought about it from time to
time, I would have done it in Python first. The syntax and high level
aspects are so much easier than C/C++ IMO, and execution speed probably
isn't critical.

It seems that logging is a very personal thing.  I haven't found an ideal
answer for my own needs, but I'm not sure my needs match anyone else's.
This is mainly a front-end issue (GUI, KB interface), while the backend
(db, data exchange, LOTW, what have you) is probably a lot more generic.
Which might suggest a two-part solution that would appeal to a wider
audience?

73
Martin AA6E

On Tue, Feb 28, 2012 at 6:25 PM, Nate Bargmann <n0nb@n0nb.us> wrote:

> Hi all.
>
> I've starting hacking on a contest logger.  I am writing it in C++ and
> wxWidgets and primarily targeting Linux at this time.  I've been working
> on this on and off for about six weeks and have reached a point where I
> am running up against my inexperience in both C++ and application
> development.
>
> I am looking for whomever may be interested in helping to develop this
> thing into something that actually works!  I am looking specifically for
> persons with knowledge of C++ and wxWidgets and who are interested in a
> contest logger with a logging UI based on the classic CT.
>
> My motivation is to be able to use the UI I and many others are
> comfortable with.  TR and N1MM's ESM UI are just not comfortable to me.
> Beyond that requirement the only other requirement is data integrity
> using some sort of database container.
>
> At this point the program is nothing more than a few windows that are a
> sort of prototype of where I want to go.  The program does not accept
> nor store data at this time and such niceties as duping and country
> verification are far off as is rig control, et. al.
>
> Given sufficient interest in the project I will push it up to Github and
> look into starting a development mailing list.  At this time it is not
> useful so potential users will be disappointed.
>
> Please reply to me direct if interested.
>
> 73, de Nate, NØNB >>
>
> --
>
> "The optimist proclaims that we live in the best of all
> possible worlds.  The pessimist fears this is true."
>
> Ham radio, Linux, bikes, and more: http://www.n0nb.us
>
> _______________________________________________
> Mailing list: https://launchpad.net/~ubuntu-hams
> Post to     : ubuntu-hams@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ubuntu-hams
> More help   : https://help.launchpad.net/ListHelp
>



-- 
Martin Ewing
Branford, Connecticut
martin.s.ewing@gmail.com

[-- Attachment #2: Type: text/html, Size: 3484 bytes --]

Re: [Ubuntu-hams] Contest logging project

[Paula Keezer]

[-- Attachment #1: Type: text/plain, Size: 4707 bytes --]

Nate,  I thought I would share some thoughts with you on the logistics of building a logging program, contest or or otherwise.  

As the author of the very first windows based logging program back in 1989 (logview, rigview, hamview and packview) I can tell you that developing and keeping a logging program alive is a daunting task.  I was able to maintain it until 1997 when y2k became an issue and the amount of effort for one individual to keep up with the changing demands of the community was simply to much.  It was written in C and was one of the better offerings for both general logging and contest logging for its time.  


Over the years I've looked at a number of contemporary programs that are feature rich to see if I could contribute and provide some of my expertise gained with 8 years of log program experience.  Unfortunately, they all use rather difficult or under powered development environments.  N1MM for instance, is a dedicated Win platform and to work on that code one would have to make a heavy investment in the latest win dev platform.

I've thought at length about how an open source solution might be constructed that could attract a large number of Hamix developers.  As Martin, AA6E pointed out, it would be very important to split the effort into two projects:  A frontend project and a backend project.  Ideally, the frontend project would welcome anyone who wished to make a logging/shackcontrol/cluster user interface to participate using the language/development and perhaps even computing platform of their choice.  The backend for logging/dxcc/prefix/callpartial databases, rigcontrol/rotatorcontrol/antennaswitch and cluster/telnet/packet/web should be in the form of services, preferably communicated  through tcpip sockets or even better, a web api.  Ideally this code should be fast, but if a standard socket or web api were used, it could be built in virtually any language and on top of any db platform and still be compatible.

I think an open source effort like this, where new comers can easily participate and add value to a growing body of code, would be an long term winner.

I think the challenge is in defining the back end services so that all the features and functions could be easily extended while preserving backward compatibility and keeping it open so new developers can step in and fill in gags as time moves forward.
The front end becomes an open field where anyone with a little programming knowledge and access to open source tools can build a new look and feel for the community.

Just my .02!

Paula, NX1P





________________________________
 From: Nate Bargmann <n0nb@n0nb.us>
To: Debian Users <debian-user@lists.debian.org>; Ubuntu Hams Group <ubuntu-hams@lists.launchpad.net>; Linux Hams <linux-hams@vger.kernel.org> 
Sent: Tuesday, February 28, 2012 3:25 PM
Subject: [Ubuntu-hams] Contest logging project
 
Hi all.

I've starting hacking on a contest logger.  I am writing it in C++ and
wxWidgets and primarily targeting Linux at this time.  I've been working
on this on and off for about six weeks and have reached a point where I
am running up against my inexperience in both C++ and application
development.

I am looking for whomever may be interested in helping to develop this
thing into something that actually works!  I am looking specifically for
persons with knowledge of C++ and wxWidgets and who are interested in a
contest logger with a logging UI based on the classic CT.

My motivation is to be able to use the UI I and many others are
comfortable with.  TR and N1MM's ESM UI are just not comfortable to me.
Beyond that requirement the only other requirement is data integrity
using some sort of database container.

At this point the program is nothing more than a few windows that are a
sort of prototype of where I want to go.  The program does not accept
nor store data at this time and such niceties as duping and country
verification are far off as is rig control, et. al.

Given sufficient interest in the project I will push it up to Github and
look into starting a development mailing list.  At this time it is not
useful so potential users will be disappointed.

Please reply to me direct if interested.

73, de Nate, NØNB >>

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Ham radio, Linux, bikes, and more: http://www.n0nb.us

_______________________________________________
Mailing list: https://launchpad.net/~ubuntu-hams
Post to     : ubuntu-hams@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-hams
More help   : https://help.launchpad.net/ListHelp

[-- Attachment #2: Type: text/html, Size: 6180 bytes --]

Re: [Ubuntu-hams] Contest logging project

[Nate Bargmann]

* On 2012 29 Feb 11:30 -0600, Paula Keezer wrote:
> Nate,  I thought I would share some thoughts with you on the logistics
> of building a logging program, contest or or otherwise.  

Hi Paula.

> As the author of the very first windows based logging program back in
> 1989 (logview, rigview, hamview and packview) I can tell you that
> developing and keeping a logging program alive is a daunting task.  I
> was able to maintain it until 1997 when y2k became an issue and the
> amount of effort for one individual to keep up with the changing
> demands of the community was simply to much.  It was written in C and
> was one of the better offerings for both general logging and contest
> logging for its time.  

Which is why I'm trying to guage the interest in collaboration before
giving up on this idea completely.

> Over the years I've looked at a number of contemporary programs that
> are feature rich to see if I could contribute and provide some of my
> expertise gained with 8 years of log program experience. 
> Unfortunately, they all use rather difficult or under powered
> development environments.  N1MM for instance, is a dedicated Win
> platform and to work on that code one would have to make a heavy
> investment in the latest win dev platform.

IMO, sticking with GNU tools and wxWidgets means the financial barrier
to entry is $0 and each is available for all popular platforms.  Some
may argue that there exists no IDE for Linux.  Perhaps so (although
there are several that make the claim), but I consider my entire desktop
to be the IDE.  ;-)

> I've thought at length about how an open source solution might be
> constructed that could attract a large number of Hamix developers.  As
> Martin, AA6E pointed out, it would be very important to split the
> effort into two projects:  A frontend project and a backend project. 
> Ideally, the frontend project would welcome anyone who wished to make
> a logging/shackcontrol/cluster user interface to participate using the
> language/development and perhaps even computing platform of their
> choice.  The backend for logging/dxcc/prefix/callpartial databases,
> rigcontrol/rotatorcontrol/antennaswitch and cluster/telnet/packet/web
> should be in the form of services, preferably communicated  through
> tcpip sockets or even better, a web api.  Ideally this code should be
> fast, but if a standard socket or web api were used, it could be built
> in virtually any language and on top of any db platform and still be
> compatible.

Whew!  Rig control is covered by Hamlib.  But really, I didn't plan for
this project to cover any more ground than CT which I'm most familiar
with.  To me that means maintaining a contest log and nothing more than
Cabrillo and ADIF export (let the other apps deal with LoTW/eQSL
uploads/tracking and the like).  Things like cluster/bandmap support and
multiop stuff is long term.

My idea is to specify contests using a definition file for each event
and from that the program configures the entry/display fields and
scoring.  As I see it, if done smartly the program doesn't need much
rewriting as contest rules change.

> I think an open source effort like this, where new comers can easily
> participate and add value to a growing body of code, would be an long
> term winner.
> 
> I think the challenge is in defining the back end services so that all
> the features and functions could be easily extended while preserving
> backward compatibility and keeping it open so new developers can step
> in and fill in gags as time moves forward.  The front end becomes an
> open field where anyone with a little programming knowledge and access
> to open source tools can build a new look and feel for the community.

Perhaps I see that as a bit too heavy of a solution?  There have been a
few false starts of something comprehensive on the various ham
radio+Linux mailing lists over the years that have come to nothing.  I'm
looking more in the direction of "do one thing and do it well".

BTW, I now have a mailing list at:

https://lists.sourceforge.net/lists/listinfo/ctestlogger-developer

Later I'll upload my personal Git repository where interested parties
can take a look.  The project page is at:

https://sourceforge.net/projects/ctestlogger/

I chose SourceForge as I'm familiar with it and they offer a Media Wiki
and PHP BB, both of which I've enabled.

Thanks for writing.

73, de Nate >>

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Ham radio, Linux, bikes, and more: http://www.n0nb.us


-- 
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/20120229194402.GD8615@n0nb.us