Created attachment 468 [details]
Outline of the fix for lib_vinegret

Created attachment 542 [details]
RTLD symbol clash fix (lib_vinegret.tar.gz)

Created attachment 543 [details]
Working Qt3 and Qt4 example (qt_vinaigrette.tar.gz)

There are several problems and drawbacks with this approach:
1.) This approach would require all Qt4 symbols to be defined somewhere with lines of code similar to this:
*(void **)(&qt4_module_func_orig) = dlsym(qt4_module, "_Z15qt4_module_funcv");

There are over 14,000 symbols in QtGui.so alone, and they can change with each minor version (or even recompilation) of Qt4.  This would be a maintenance nightmare.

2.) With the current TQt approach I can combine Qt3 and Qt4 code in the same source file, and even pass objects back and forth between Qt3 and Qt4.  This is not possible with your example.

3.) I strongly suspect that slots and signals will not function normally with your example, unless convoluted steps are taken to ensure that the Qt3 code and the Qt4 code are processed via different moc binaries.

I am sure there are more problems than listed here, but these three alone are enough to make this approach unworkable in practice.

Tim

(In reply to comment #4)
> There are several problems and drawbacks with this approach:
> 1.) This approach would require all Qt4 symbols to be defined somewhere with
> lines of code similar to this:
> *(void **)(&qt4_module_func_orig) = dlsym(qt4_module, "_Z15qt4_module_funcv");
>  
> There are over 14,000 symbols in QtGui.so alone, and they can change with each
> minor version (or even recompilation) of Qt4.  This would be a maintenance
> nightmare.

No, that is not so. 'qt4_module' depicts TDE module. The one thing that is required is separate code that use Qt4 in different .so file. I believe, that intrusion is by multiple times lighter, than the work with TQt proxying. And proxying of single module in ideal case can be brought to just a single call (object instantiation).

> 
> 2.) With the current TQt approach I can combine Qt3 and Qt4 code in the same
> source file, and even pass objects back and forth between Qt3 and Qt4.  This is
> not possible with your example.

Does it have real usage? Anyway, you can still pass back objects back and forth between Qt3 and Qt4. Different .so files do not forbid that. And you can even intermix Qt3 and Qt4 in single class because class implementation is not required to be in single .so library though this will increase work for proxying.

> 
> 3.) I strongly suspect that slots and signals will not function normally with
> your example, unless convoluted steps are taken to ensure that the Qt3 code and
> the Qt4 code are processed via different moc binaries.

Not quite understand that. Can you be more specific what will prevent signals from work?

> 
> I am sure there are more problems than listed here, but these three alone are
> enough to make this approach unworkable in practice

The approach seem to be workable. But this can only be verified by real application. The method deserves a try because of the profit it promises upon TQt classes.

> 
> Tim

P.S. I could make an example with signals. But we need to discuss details.

At a minimum I would like to see a working example showing:
1.) The #inclusion of both qstyle.h files (Qt3 and Qt4) into the same source file with basic operations on the global application and related QStyle object in that file.  For example, this is generally how it would be done under TQt and Qt4:

#include <tqstyle.h>
#include <QtGui/QtGui>

int main() {
    // Qt and TQt initialization code goes here if needed

    // Create Qt3 and Qt4 widgets without parents
    QWidget qt4widget;
    TQWidget qt3widget;

    // Draw a couple of primitives on those widgets
    qApp->style().drawPrimitive(...);
    tqApp->style().drawPrimitive(...);
}

Think of this as a technical preview--if your solution is satisfactory to this challenge, then there are a couple more tasks I would like to see implementations for.  If they all look good then we can consider this idea; if not any flaws in this approach should stand out to everyone involved. :-)

Tim

But why do you need it in single file? As I said, the requirement is to make separate .so library for Qt4 user. This means Qt4 code in separate file. I do not see any big problems with that. Could you please point TDE code your example goes from.

The code is part of the theme engine which has not yet been released.  However, usage of TQt3 and Qt4 in the same file is by no means limited to that particular use case--it would desirable, for instance, to be able to embed Qt4 child widgets in TQt3 parent widgets, which is feasible with TQt3.

But this does not mean without fail that they must be constructed in the same file. Qt4 widgets may be supplied by a factory that lives in separate file (and separate library). This is very simple in practice. The only weak place that I can think of is Qt3 and Qt4 headers clash if the widgets from Qt3 and Qt4 have the same class name. But I'm sure that this is fixable too.

Are there some drafts of that theme engine? What is its goal - Webkit widget?

The question apart from this topic. Why you just hadn't placed Qt4 in different namespace (-qtnamespace)?

I will start to construct an example with drawPrimitive().

(In reply to comment #10)
> But this does not mean without fail that they must be constructed in the same
> file. Qt4 widgets may be supplied by a factory that lives in separate file (and
> separate library). This is very simple in practice. The only weak place that I
> can think of is Qt3 and Qt4 headers clash if the widgets from Qt3 and Qt4 have
> the same class name. But I'm sure that this is fixable too.

It is NOT easily fixable.  I have tried and tried in the past!

> Are there some drafts of that theme engine? What is its goal - Webkit widget?

Visual integration of Qt4 apps into the TDE environment is the primary goal, with the Webkit widget being a secondary goal.

> The question apart from this topic. Why you just hadn't placed Qt4 in different
> namespace (-qtnamespace)?

From what Google tells me qtnamespace is buggy and many distributions don't turn it on.  Please correct me if I am wrong; Qt4 is several hundred megabytes and I don't want to pull down the source just to check this flag. ;-)

(In reply to comment #12)
> (In reply to comment #10)
> > ... The only weak place that I
> > can think of is Qt3 and Qt4 headers clash if the widgets from Qt3 and Qt4 have
> > the same class name. But I'm sure that this is fixable too.
> 
> It is NOT easily fixable.  I have tried and tried in the past!
>

At least there is possibility to confine Qt4 classes into namespace via inheritance:

namespace Qt4
{
  class QWidget : public ::QWidget {};
}

Then use Qt4::QWidget along with Qt3 classes. I know, that this approach technically is not much different from '#define TQWidget QWidget'. But it have a number of advantages over it:

1. C++ correct and debug friendly.
2. Have compatibility with -qtnamespace option.
3. Does not require to embrace full Qt4 API. Only classes that are used in TDE. That is a small number I suspect.
 
> > Are there some drafts of that theme engine? What is its goal - Webkit widget?
> 
> Visual integration of Qt4 apps into the TDE environment is the primary goal,
> with the Webkit widget being a secondary goal.

Do you mean standalone applications? What kind of integration may be done for them? (Any examples?) 

> 
> > The question apart from this topic. Why you just hadn't placed Qt4 in different
> > namespace (-qtnamespace)?
> 
> From what Google tells me qtnamespace is buggy and many distributions don't
> turn it on.  Please correct me if I am wrong; Qt4 is several hundred megabytes
> and I don't want to pull down the source just to check this flag. ;-)

This seem to have been fixed.

Created attachment 976 [details]
inline namespace symbol collision fix

Created attachment 977 [details]
inline namespace: single file collision fix

Here are some my ideas:
New C++11 standard introduces a feature that can transparently fix those collisions: a so called «inline namespace». It's supported by gcc since 4.4.

I've added a couple of examples: it's really easy to use... we can transparatly change nearly any symbol names in Qt.
So what we bye:
+ No symbol collisions
+ Full source-level API compatibility.
+ We should be able to perform this migration step-by step.
+ With small preprocessor stuff we can combine both modules even into a single .cpp file (see attachment #977 [details])
+ If you don't combine different Qt version in a single file
+ Where will be no unclear renames/parameter place swapping etc.
- ABI will be completely broken (does somebody really cares?)
- There could be some more issues on preprocessor and moc levels with combination of different qt modules into a single file.
+ if somebody really cares on the ABI it is possible to generate some sort of proxy libraries.

Anybody: What is the status of this report?

IMO this one can be considered CLOSED/WONTFIX or INVALID cause R14 will uses tqt3 and you can do anything you want with its API.

Agreed.  Closing.

Sorry, I have no time to develop the idea. The core principle of programming -- do not make more work for yourself. Additional layer between app and lib will take efforts to support 4-ever! In conditions of this project's human resources shortage that were very luxurious decision. But I would never accept such kind of decision in ANY project with any resources.

Again: making proxies in C++ is BAD, do them only as a temporary solution!

I would keep this ticket as 'CLOSED', so that someone could find it and develop further...