klog-devel
[Top][All Lists]
Advanced

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

[Klog-devel] Comments on sqllite, dxcluster and some more...


From: Jaime Robles
Subject: [Klog-devel] Comments on sqllite, dxcluster and some more...
Date: Tue, 6 Oct 2009 20:18:31 +0200 (CEST)
User-agent: SquirrelMail/1.4.15

>> 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?

-- 
Un saludo,
        Jaime Robles, EA4TV
        address@hidden

Visita:
   http://jaime.robles.es



reply via email to

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