Tue, Aug 09, 2005 at 10:30:57AM +0300, Andras Mantia wrote:
Since a recent change in KHTMLView, Quanta crashes on startup when it
tries to create a KHTMLView object. The code in Quanta does:
KHTMLPart(new KHTMLView(this, widgetParent, name), parent, name)

dear, I'm very sorry about breaking your application. :-\

Here's how I would fix it (and if no one complains, I'll commit it):

Index: khtmlview.cpp

khtmlview.cpp(revision 445557)
khtmlview.cpp(working copy)
@@ -253,7 +253,9 @@ public:
#endif // KHTML_NTYPE_AHEAD_FIND
accessKeysActivated = false;
accessKeysPreActivate = false;
+ KHTMLFactory::ref();
accessKeysEnabled = ()->accessKeysEnabled();
+ KHTMLFactory::deref();
emitCompletedAfterRepaint = CSNone;
}
void newScrollTimer(QWidget *view, int tid)
Index: khtml_factory.h

khtml_factory.h(revision 445557)
khtml_factory.h(working copy)
@@ -40,6 +40,7 @@ class KDE_EXPRT KHTMLFactory : public K
{
QBJECT
friend class DM::DocumentImpl;
+ friend class KHTMLViewPrivate;
public:
KHTMLFactory( bool clone = false );
virtual ~KHTMLFactory();

Thu, Aug 11, 2005 at 09:42:08AM +0200, Andreas Kling wrote:
Tue, Aug 09, 2005 at 10:30:57AM +0300, Andras Mantia wrote:
Since a recent change in KHTMLView, Quanta crashes on startup when it
tries to create a KHTMLView object. The code in Quanta does:
KHTMLPart(new KHTMLView(this, widgetParent, name), parent, name)

dear, I'm very sorry about breaking your application. :-\

Here's how I would fix it (and if no one complains, I'll commit it):

Well not really complaining, but would adding some comment make sense?
For me, it's not clear why you don't add the ref/deref in
(avoiding using 'friend' also keeps
catching compile time error for eg. abusing a copy ctor).

Koos

Index: khtmlview.cpp

khtmlview.cpp(revision 445557)
khtmlview.cpp(working copy)
@@ -253,7 +253,9 @@ public:
#endif // KHTML_NTYPE_AHEAD_FIND
accessKeysActivated = false;
accessKeysPreActivate = false;
+ KHTMLFactory::ref();
accessKeysEnabled = ()->accessKeysEnabled();
+ KHTMLFactory::deref();
emitCompletedAfterRepaint = CSNone;
}
void newScrollTimer(QWidget *view, int tid)
Index: khtml_factory.h

khtml_factory.h(revision 445557)
khtml_factory.h(working copy)
@@ -40,6 +40,7 @@ class KDE_EXPRT KHTMLFactory : public K
{
QBJECT
friend class DM::DocumentImpl;
+ friend class KHTMLViewPrivate;
public:
KHTMLFactory( bool clone = false );
virtual ~KHTMLFactory();

Thu, Aug 11, 2005 at 09:42:08AM +0200, Andreas Kling wrote:
Tue, Aug 09, 2005 at 10:30:57AM +0300, Andras Mantia wrote:
Since a recent change in KHTMLView, Quanta crashes on startup when it
tries to create a KHTMLView object. The code in Quanta does:
KHTMLPart(new KHTMLView(this, widgetParent, name), parent, name)

dear, I'm very sorry about breaking your application. :-\

Here's how I would fix it (and if no one complains, I'll commit it):

Well not really complaining, but would adding some comment make sense?
For me, it's not clear why you don't add the ref/deref in
(avoiding using 'friend' also keeps
catching compile time error for eg. abusing a copy ctor).

Koos

Index: khtmlview.cpp

khtmlview.cpp(revision 445557)
khtmlview.cpp(working copy)
@@ -253,7 +253,9 @@ public:
#endif // KHTML_NTYPE_AHEAD_FIND
accessKeysActivated = false;
accessKeysPreActivate = false;
+ KHTMLFactory::ref();
accessKeysEnabled = ()->accessKeysEnabled();
+ KHTMLFactory::deref();
emitCompletedAfterRepaint = CSNone;
}
void newScrollTimer(QWidget *view, int tid)
Index: khtml_factory.h

khtml_factory.h(revision 445557)
khtml_factory.h(working copy)
@@ -40,6 +40,7 @@ class KDE_EXPRT KHTMLFactory : public K
{
QBJECT
friend class DM::DocumentImpl;
+ friend class KHTMLViewPrivate;
public:
KHTMLFactory( bool clone = false );
virtual ~KHTMLFactory();

Thursday 11 August 2005 10.30, Andras Mantia wrote:
As I saw ref/deref is done in the constructor destructor, so what about:

KHTMLFactory *factory = new KHTMLFactory();
accessKeysEnabled =
()->accessKeysEnabled();
delete factory;

That's all right, but something like:

KHTMLSettings *settings = new KHTMLSettings();
accessKeysEnabled = settings->accessKeysEnabled();
delete settings;

would create one less object. It still parses the configuration file
another time, though, which is pretty ugly.

Ugh, someone throw me a bone here.
-- Andreas

Friday 12 August 2005 13:52, Andreas Kling wrote:
Thursday 11 August 2005 10.30, Andras Mantia wrote:
As I saw ref/deref is done in the constructor destructor, so what about:

KHTMLFactory *factory = new KHTMLFactory();
accessKeysEnabled =
()->accessKeysEnabled();
delete factory;

That's all right, but something like:

KHTMLSettings *settings = new KHTMLSettings();
accessKeysEnabled = settings->accessKeysEnabled();
delete settings;

would create one less object. It still parses the configuration file
another time, though, which is pretty ugly.

Yeah okay, I was talking out of my socks here.
Creating a new KHTMLFactory is way better than creating a new KHTMLSettings.
Mr. Mantia had it right all along. Sorry ;-)
-- Andreas

David Faure wrote:
Thursday 11 August 2005 10.30, Andras Mantia wrote:

As I saw ref/deref is done in the constructor destructor, so what about:

KHTMLFactory *factory = new KHTMLFactory();
accessKeysEnabled =
()->accessKeysEnabled();
delete factory;

That's all right, but something like:

KHTMLSettings *settings = new KHTMLSettings();
accessKeysEnabled = settings->accessKeysEnabled();
delete settings;

would create one less object. It still parses the configuration file
another time, though, which is pretty ugly.
>>
>>Yeah okay, I was talking out of my socks here.
>>Creating a new KHTMLFactory is way better than creating a new KHTMLSettings.
>>Mr. Mantia had it right all along. Sorry ;-)

I don't see how. The ref/deref solution has the advantage that no factory needs to be
created at all, if there's already one. Can you apply the ref/deref solution instead,
if it works for you?

The ref/deref solution was dropped due to complaints about adding a
friend class, but if you think that's okay, we'll go with that.

So what do you think? ;)
-- Andreas