klog-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Klog-devel] Dxcluster options


From: Andrew Goldie
Subject: [Klog-devel] Dxcluster options
Date: Thu, 8 Oct 2009 08:15:38 +1300
User-agent: KMail/1.11.4 (Linux/2.6.28-11-generic; KDE/4.2.4; x86_64; ; )

Hi Jaime,

Yes I was thinking about the cluster options. I think probably one of the 
easist is to use a QListWidget. This has an insertItem() funtion:

void insertItem ( int row, QListWidgetItem * item )
void insertItem ( int row, const QString & label )
void insertItems ( int row, const QStringList & labels )

With this we can always insert data at the top of the list by using:

QListWidgetItem *DXItem = new QListWidgetItem;
DXItem->setText(dxData);
dxclusterListWidget->insertItem(0,  DXItem);

The 0 being the top of the listwidget. I have done this before and it works 
well. 

I have also noticed that there is an error in here somewhere that crashes the 
program. It is a very weird one and it only appears sometimes. Its got 
something to do with QString I think the messages are similar to this:

ASSERT: "i >= 0 && i < size()" in file /usr/include/qt4/QtCore/qstring.h

I not sure why this error happens but I have done a little bit of 
investigation and I think it has something to do identfying where the 
callsigns come from, possibly the world class.

Should we change the QTreeWidget to a QListWidget and use the insertItem(row, 
item) function?

Andrew


On Wed, 07 Oct 2009 23:01:41 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. Comments on sqllite, dxcluster and some more... (Jaime Robles)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 6 Oct 2009 20:18:31 +0200 (CEST)
> From: "Jaime Robles" <address@hidden>
> Subject: [Klog-devel] Comments on sqllite, dxcluster and some more...
> To: address@hidden
> Message-ID:
>       <address@hidden>
> Content-Type: text/plain;charset=iso-8859-1
>
> >> When I started KLog I considered using a DB to save the QSOs.
> >> The reason for discarding that option was to make KLog as much
> >> "independant" of other software as possible and avoid all the
> >> configurations problems for the users as possible.
> >
> > Yes this is true but I was perhaps thinking of a DB linu sqllite ot
> > Berkley DB
> > with is really just a set of libraries available on most Linux boxes. Or
> > this could be statically linked to the executable.
>
> Ok.
> I did not know sqllite nor Berkley DB... I was that you were proposing
> something like mysql or postgresql... ;-)
> Let me read a bit about that and check for implications that this may
> have. Today KLog works ok without sqllite... and I wouldn't like to limit
> the portability to MS-Windows :-| as I told you I am planning to reach
> Windows users too in a near future.
>
> I have done a very quick check for sqllite and it seems that it is also
> supported in windows systems so that would not be a great problem.
> Anyway, this would be a big change. Maybe we can add it to the future
> feature list and plan it in a future release... at least as a test. :-)
>
> >>  2.- be a way to show&promote free software and KDE to MS Windows.
> >
> > Yes this fairly easy with a straight QT project, I have done it a few
> > times.
> > In fact all that has to be done to run is for it to be compiled on a
> > windows box and a small DLL included with the exe file.
>
> Great.
> I have no experience on that.
>
> > The problem with KLog is that it includes some KDE and possibly some
> > hamlib stuff that will not compile on windows.
>
> You are right again.
> I did some reading some months ago... and it seems that for a Windows
> port, we should use some compiler directives or something like that to
> avoid trying to add hamlib support in the windows compilation.
>
> I still don't know how to add hamlib-like features to a windows code...
> but today I don't care. Maybe we can add a windows coder to do that part
> when KLog is available for win systems ;-)
>
> > I see that you are using a QTreeWdiget as the main display widget, can I
> > ask
> > why you chose that over a QTableWidget which has a few more functions
> > that would make some stuff a little bit easier?
>
> I have no idea O:-)
> I was reading and checking the classes docs and I saw the QTreeWidget
> class... it was the most similar class to the QListView class that I was
> using in Qt3 so I directly migrated to QTreeWidget.
> I think that QTreeWidget may be very fast if we create and work with QList
> class and then we call the QTreeWidget just for showing the data but it is
> again another optimization.
>
> Maybe using a QTableWidget is also a good idea as we could (I am just
> guessing) allow the users to (quickly)edit the data directly through the
> QTableWidget...
> Again: we should add this to the TODO list and plan it to future releases.
>
> Today I had no time for coding.. :-(
> How do you think can we solve the fact that data comming from the
> dxcluster is hidden as soon as new data arrives from the network?
> It is not very confortable and it is a downgrade from previous (qt3) klog
> release :-\
>
> I am thinking of finding the way to insert instead of add the DXSpots and
> then setting the "focus" to the first element on the list, the top-one but
> I still haven't found how to do it.
>
> Do you have any other idea?



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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]