maemo file manager hook

[danny...@gmail.com]

Hi,

so after a long hiatus, I tried to forward-port my file manager
registration patch to fbreader 0.8.2c:

<http://www.scratchpost.org/patches/fbreader-0.8.2c-file-type-
association.patch>

However, I don't understand how ZLMessage* stuff works.
I can see how it is sending messages, alright, but where is it
_receiving_ messages and what does it do with them? (this is for IPC,
yes?)

What I want to do is in ZLMaemoCommunicationManager, register a mime
handler callback (using set_mime(osso_context)), and in it, somehow
wind up calling fbreader->openFile() (or openBook).

Helppp :-)

btw, maybe you remember that I said I would ask maemo about how to
register multiple programs for one mime type. I did that (posted on
maemo-developers), the question got mentioned (repeated) for a few
weeks, and nothing much else happened. Sigh. I'll try again, I guess.

cheers,
Danny

[geometer]

Hi Danny,

> However, I don't understand how ZLMessage* stuff works.
> I can see how it is sending messages, alright, but where is it
> _receiving_ messages and what does it do with them? (this is for IPC,
> yes?)

You're absolutely right, ZLCommunicatorManager SHOULD contain methods
to receive messages. But it doesn't contain. :( Currently in zlibrary/
fbreader there is no way to receive messages. Sorry, it's still 0.8.2,
not 1.0. ;)

So, if you'll made patch for ZLCommunicationManager (it can be
implemented for maemo platform only -- not a problem), it will be very
useful patch.

> btw, maybe you remember that I said I would ask maemo about how to
> register multiple programs for one mime type. I did that (posted on
> maemo-developers), the question got mentioned (repeated) for a few
> weeks, and nothing much else happened. Sigh. I'll try again, I guess.

;)

-- Nikolay Pultsin

[danny...@gmail.com]

Hi,

On May 5, 9:20 pm, geometer <geome...@mawhrin.net> wrote:
> So, if you'll made patch for ZLCommunicationManager (it can be
> implemented for maemo platform only -- not a problem), it will be very
> useful patch.

Ok, done:
<http://www.scratchpost.org/patches/fbreader-0.8.2c-file-type-
association-and-rpc.patch>

Not tested yet, first I have to find out how to create a debian
package. The usual "dpkg-buildpackage -us -uc -rfakeroot" doesn't
work :-(

It does compile and link, though :-)

cheers,
Danny

[danny...@gmail.com]

Hi,

On May 5, 9:20 pm, geometer <geome...@mawhrin.net> wrote:

> So, if you'll made patch for ZLCommunicationManager (it can be
> implemented for maemo platform only -- not a problem), it will be very
> useful patch.

Ok, done:

[geometer]

Danny,

thank you!

I hope to apply your patch in the next major version (0.8.4).

-- Nikolay Pultsin

[danny...@gmail.com]

Hi,

there is a problem with my patch:

I added
+ this->communicator-
>registerReceiver(weak_ptr<ZLMessageReceiver>(this));
to the FBReader class constructor (in the above patch you already
have), but that made C++:

1) construct temporary shared_ptr with refcount 1, pointing to this.
2) construct weak_ptr, pointing to shared_ptr 1
3) register that with the communicator
4) destroy temporary shared_ptr
5) Segfault.

Sigh...

Workaround:
FBReader.h
+ shared_ptr<ZLMessageReceiver> receiver;

FBReader.cpp constructor
- this->communicator-
>registerReceiver(weak_ptr<ZLMessageReceiver>(this));
+ this->receiver = new FBReaderMessageReceiver(*this);
+ this->communicator-
>registerReceiver(weak_ptr<ZLMessageReceiver>(this->receiver));

class FBReaderMessageReceiver : public ZLMessageReceiver
{
private:
FBReader& reader;
public:
FBReaderMessageReceiver(FBReader& reader);
virtual void stringMessageReceived(const std::string& command,
const std::string& message);
};

void FBReaderMessageReceiver::stringMessageReceived(const std::string&
command, const std::string& message)
{
this->reader.stringMessageReceived(command, message);
}

FBReaderMessageReceiver::FBReaderMessageReceiver(FBReader& reader) :
reader(reader)
{
}

So basically I introduced a dummy class for the sole purpose of
keeping a shared_ptr to it that doesn't go the way of the dodo when
I'm not looking...

Somehow this solution irks me, but it does work...

Any suggestions?

cheers,
Danny

[danny...@gmail.com]

Hi,

I just wrote an additional patch that will present (raise) the window
when a file is opened by the file manager.
(Similar code probably works on all gtk based zlibrary platforms, but
I didn't do that yet, need sleep first :-))

<http://www.scratchpost.org/patches/fbreader-0.8.2c-present-
window.patch>

cheers,
Danny

[geometer]

Hi Danny,

are you sure weak_ptr is good idea in your case? Why do you use
weak_ptr, not shared_ptr?

-- Nikolay Pultsin

PS Looks like I need more time to understand your idea, so 0.8.4 will
be released (today or tomorrow) without your patch, sorry. Anyway, it
will be applied in the near future.

-- NP

[danny...@gmail.com]

Hi,

On Jun 5, 6:52 pm, geometer <geome...@mawhrin.net> wrote:
> Hi Danny,
>
> are you sure weak_ptr is good idea in your case? Why do you use
> weak_ptr, not shared_ptr?

Where?

ZLCommunicationManager::registerReceiver(weak_ptr<ZLMessageReceiver>
receiver)
has a weak_ptr, because otherwise just because you registered
something as a message receiver, it (that something) would stay around
infinitely, extending its lifetime until someone deregisters it from
message-receiverdom (which nobody usually does).

For example, this hypothetical code would have this problem:

ZLCommunicationManager::registerReceiver(shared_ptr<ZLMessageReceiver>
receiver)
{
...
}

class MainWindow : public ZLMessageReceiver
{
}

MainWindow::stringMessageReceived(...)
{
....
}

main()
{
shared_ptr<MainWindow> mainWindow = new MainWindow();
foobar.registerReceiver(mainWindow);
....
// mainWindow stays around until hell freezes over, because hey, it
could be receiving messages sometime
}

Of course, if such a behaviour were intended, by all means, we should
use shared_ptr.

The _actual_ (broken) usage in my patch was:

ZLCommunicationManager::registerReceiver(weak_ptr<ZLMessageReceiver>
receiver)
{
...
}

class MainWindow : public ZLMessageReceiver
{
shared_ptr<ZLCommunicator> communicator;

}

MainWindow::MainWindow()
{
this->communicator =
ZLCommunicationManager::instance().createCommunicator("osso-rpc",
this->communicator->registerReceiver(this);
// now we have a funny problem because "this" is not a
shared_ptr, but weak_ptr constructs a (very) temporary copy, so we
crash (eventually)

}

MainWindow::stringMessageReceived(...)
{
....
}

main()
{
shared_ptr<MainWindow> mainWindow = new MainWindow();
....
// mainWindow stays around until its normal life is over. It doesn't
"gain eternal life to be able receive messages" (like the next version
does)
}

The actual (broken) usage in my patch, just modified to use a
shared_ptr registerReceiver function would be:

ZLCommunicationManager::registerReceiver(shared_ptr<ZLMessageReceiver>
receiver)
{
...
}

class MainWindow : public ZLMessageReceiver
{
shared_ptr<ZLCommunicator> communicator;

}

MainWindow::MainWindow()
{
this->communicator =
ZLCommunicationManager::instance().createCommunicator("osso-rpc",
this->communicator->registerReceiver(this);
// now we have a cyclic reference between "this" and "this-
>communicator"

}

MainWindow::stringMessageReceived(...)
{
....
}

main()
{
shared_ptr<MainWindow> mainWindow = new MainWindow();
....
// mainWindow stays around until hell freezes over, because hey, it
could be receiving messages sometime. Or was it that the communicator
stays over until the window is done? The window until the communicator
is done?
}

> PS Looks like I need more time to understand your idea, so 0.8.4 will be released (today or tomorrow) without your patch, sorry.
>Anyway, it will be applied in the near future.

No problem. I only have a passing understanding of zlibrary
architecture, so it's better that you check what weird stuff I did
first :-)

cheers,
Danny

[danny...@gmail.com]

Hi,

so in order to keep it all orderly I updated my patches to
fbreader-0.8.4a:

<http://www.scratchpost.org/patches/fbreader-0.8.4a-file-manager-
integration-and-rpc.patch>

Apply it to a clean "fbreader-sources-0.8.4a.tgz" download.

It does the following:
- add the ability to receive RPC messages to zlibrary
- register file manager callback for handling "text/plain" and "text/
html" files.
- add the ability to present (raise) the FBReader window to zlibrary

I tested it on the N800 and it works fine EXCEPT when doing these
steps:
1) FBReader process is not running, but is remembering a book to open
(let's call the book "R")
2) User clicks another file on file manager
3) file manager (...) starts FBReader process
4) file manager sends name of file (let's call it "N") to open to
FBReader via IPC
5) the FBReader window is presented (raised)
6) FBReader opens this new file "N", you can even see it loading and
the window title changes
7) FBReader opens the file "R", closing the file "N" again
8) book "R" is open

Strange :-)

Working:
1) FBReader process is running, having whatever book "R" open
2) User clicks file on file manager
3) file manager sends name of file (let's call it "N") to open to
FBReader via IPC
4) FBReader opens this new file "N", you can even see it loading and
the window title changes
5) the FBReader window is presented (raised)
6) the book "N" is now open

Something new?

cheers,
Danny

[danny...@gmail.com]

Any idea where I should start looking why that is?
Where does it load the previously open book when starting up?

[geometer]

On Jul 21, 1:11 am, danny.m...@gmail.com wrote:
> Any idea where I should start looking why that is?
> Where does it load the previously open book when starting up?

In FBReader::initWindow()

Sorry, currently I have no time :( for any investigation (and for
applying your path) -- may be, in August.

-- Nikolay Pultsin

[danny...@gmail.com]

Hi,

On Jul 21, 6:55 am, geometer <geome...@mawhrin.net> wrote:
> On Jul 21, 1:11 am, danny.m...@gmail.com wrote:
>
> > Any idea where I should start looking why that is?
> > Where does it load the previously open book when starting up?
>
> In FBReader::initWindow()

Ah, yeah.

It seems that "stringMessageReceived" is called even before
"initWindow" was called (i.e. the file manager is way too eager and
sends the message even before the gtk_main loop is running? O_o)

I fixed that by introducing a member variable "myInitWindowCalled" and
checking it within "stringMessageReceived", and, if not set, doesn't
do much except setting "myBookToOpen" to the path of the file the file
manager passed.
This seems to work most of the time, but sometimes when clicking a
file in the file manager while FBReader is not open yet:
1) FBReader crashes right after it starts (seldomly), OR
2) everything works fine, except that the window title is wrong
(either "About FBReader" or the title of some previous book) - the
actual book view shows the correct one, the "book info..." menu item
also reports the correct one

strange...

The updated patch: <http://www.scratchpost.org/patches/fbreader-0.8.4a-
file-manager-
integration-and-rpc.patch>

> Sorry, currently I have no time :( for any investigation (and for
> applying your path) -- may be, in August.

I see :(

Well, there's no need to hurry :)

It almost works now, so I'll enable debug info later, maybe the
occasional crash leads to insight... O_o

cheers,
Danny

[geometer]

Danny,

Thank you once more. I've applied your patch in 0.8.6. (With some
minor changes.)

But I've not included mime type bindings in the 0.8.6. I'm not sure if
"open in FBReader" is good DEFAULT action for html files for
all users. Do you have any idea how to install these bindings
OPTIONALLY? May be, we can create the separate package?

-- Nikolay Pultsin

[danny...@gmail.com]

Hi,

> Thank you once more. I've applied your patch in 0.8.6. (With some minor changes.)

No problem :-)

> But I've not included mime type bindings in the 0.8.6. I'm not sure if
> "open in FBReader" is good DEFAULT action for html files for
> all users. Do you have any idea how to install these bindings
> OPTIONALLY? May be, we can create the separate package?

That's what I'd like to know as well, I've posted to the "maemo-
developers" list again <http://lists.maemo.org/pipermail/maemo-
developers/2007-August/011271.html>, let's see if someone steps forth
this time :-)

cheers,
Danny