Project directory structure

[Thiago Macieira]

On quarta-feira, 3 de abril de 2013 11.29.35, Dirk Hohndel wrote:
> > The hardest thing, since we are not sharing the GLib mainloop, is
> > sharing events. This can be done using C callbacks, which can be
> > registered to the core-lib when it's initialized (think of how Linux
> > kernel modules register their methods) or when a specific object is
> > initialized.
> 
> I don't know which events you mean.
> 
> We have "events" which are things that happen during a dive that we
> handle (for example, "diver changed tanks" or "diver violated deco
> ceiling"). But I think the only asynchronous callbacks that we have in
> our code are for the divecomputer download (where we want to update the
> UI while a different thread talks to the divecomputer) and things that
> are triggered from the UI (so those would be signals/slots).
> 
> Am I missing something?

Alberto was talking about notifications / callbacks.

Something I'll have to add to the HACKING file, but here it goes. In Qt 
"speak", an event is a class of notifications that are delivered by sending a 
QEvent object to a specific target object, even though some UI events "bubble 
up" to other objects. Events are usually raw, in the sense that they usually 
don't contain semantic meaning. They are also usually spontaneous, coming from 
the "outside world". Mouse clicks, touchscreen touches, keyboard input and all 
sort of information coming from the windowing system are events (paint events, 
focus events, drag-and-drop events, etc.)

Compare that to "signals", which are semantic notifications that something 
happened, which is why they're named after verbs in the simple past tense. 
Signals are not directed: they are an N:M callback mechanism. Usually, the 
sender of a signal does not even care if anything is receiving the signal (the 
sender of an event could check if it was handled).

Usually, signals are emitted in reaction to events. For example, a QPushButton 
can emit the clicked() signal as a result of the user doing a mouse click on 
the button, but also when the user hits the space bar while the button was 
focused -- if there's such a thing as focus on this device / style. It's also 
emitted as a result of someone calling the click() function.


For Subsurface, the notification that the download from the divecomputer 
finished would be a signal. Since that code is in C, we'd simply do with a 
regular callback that in turn emits the signal. The UI will react soon. 
Similarly for a progress bar, if any: the callback from the download routine 
with the update emits a signal.

However, Dirk mentioned threading, so I'd actually recommend a little 
refactoring here: use QThread, which abstracts away the Win32 threads. The 
download function is a simple, blocking function. The completion of the 
download is simply the fact that the function returned. (I haven't 
investigated whether such a function exists in libdivecomputer and whether 
there are mutexes involved, which would complicate the situation a little)

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20130403/4a9c5f4a/attachment.sig>