useless discussion on MinGW/MSVC & releasing apps
Ralf Habacker
ralf.habacker at freenet.de
Mon Dec 24 11:06:12 CET 2007
Ralf Habacker schrieb:
> Ralf Habacker schrieb:
>
>> Christian Ehrlicher schrieb:
>>
>>
>>> Saro Engels schrieb:
>>>
>>>
>>>
>>>> Andreas Pakulat schrieb:
>>>>
>>>>
>>>>
>>>>> On 21.12.07 11:34:13, Christian Ehrlicher wrote:
>>>>>
>>>>>
>>>>>
>>>>>> I wonder why we need such a dicussion every now and then. Imho we
>>>>>> decided to support both compilers - so no discussion here any more.
>>>>>>
>>>>>>
>>>>>>
>>>>> Agreed.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> The only thing you could discuss is wheter we should (officially)
>>>>>> support gcc4.2.1 and msvc2008. As gcc4.2.1 is only a technology preview
>>>>>> I personally would not even consider them using it in anything other
>>>>>> than a test environment...
>>>>>>
>>>>>>
>>>>>>
>>>>> Well, for now thats probably Ok, but I hope we can switch to gcc4.2 or
>>>>> even 4.3 for the first release already.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> I also don't understand why someone thinks about releasing any kde4 app
>>>>>> before 4.1. There're so much open issues in kdelibs and I did not see a
>>>>>> *single* checkin to fix them! Looks like you only want to get some
>>>>>> public attention without thinking about what you want to release.
>>>>>>
>>>>>>
>>>>>>
>>>>> Do we have a list of all these issues? I suspect I can find out some
>>>>> things by simply building and trying a kde app, but having them written
>>>>> down might be a good thing.
>>>>>
>>>>> Maybe we should ask for a bugzilla component for kde-win specific issues
>>>>>
>>>>>
>>>>>
>>>> There is
>>>> http://techbase.kde.org/Projects/KDE_on_Windows/Missing/features/functions/kdelibs
>>>> already which is not to much yet. If you find something, please add it
>>>> below.
>>>>
>>>>
>>>>
>>>>
>>> Plz add the showstopper 'kfilewidget'. You can't change the current
>>> drive and I'm curently unable to solve this problem. I already tried it
>>> without sucess. It should show the same directory tree like the native
>>> file open dialog. Desktop -> Arbeitsplatz -> C:, D:, ... but the current
>>> url-based implementation does not allow this.
>>>
>>> We should also disable the dbus-commandline window. Ralf?
>>>
>>>
>>>
>> Thats somehow curios, if you run kdeinit4 first, it runs dbus-daemon in
>> the background and there is no console window.
>> in kdelibs there is code to start kdeinit4 if no dbus-daemon is running,
>> but it looks the the autostart feature in libdbus overrides this, which
>> means it looks to be called first .
>> As far as i can see does the CreateProcess in the libdbus autostart code
>> opens this window and I have no idea how to disable it.
>>
>>
> I should add some notes for clarification: CreateProcess has a process
> creation flag to disable the console windows but this disables also
> debug message printing, which is not really what we want.
>
> The conclusion is that dbus-daemon should be started by kdeinit4 and no
> by dbus autostart option.
>
I found at least a workaround: I have committed a little patch to
windbus svn trunk. libdbus does now not open a console window when
starting dbus-daemon.
If someone like to see dbus verbose messages the following sequence is
recommended:
set DBUS_VERBOSE=1
start dbus-daemon --session
<start your prefered application>
Ralf
More information about the Kde-windows
mailing list