KDE Development on Windows

Wed Apr 2 10:13:56 UTC 2014

Hi,

Your are not alone. For digiKam under windows, it's the same problem
to release a version running on this system...

So i'm hear this thread with interrest, to see which solutions are
planed for the future...

Best

Gilles Caulier

2014-04-02 12:08 GMT+02:00 Chris <DeveloperChris at rebel.com.au>:
> Wow
>
> Its great to see I am not alone. You have obviously gone to a great deal of
> effort to get this all working. So I really appreciate the chance to clone
> your kde 'lite' environment.
>
> The KDE learning curve is quite substantial. For example It took a while to
> figure out there was some sort of plugin system over and above the app
> itself  then I thought that the plugin system used qt's plugin manager. It
> took me a fair while to work out my mistake and then I had to devise a way
> around it which led me to discover win7 actually has implemented symbolic
> links. Much of this appears to be assumed knowledge my search for answers
> proved mostly fruitless or misleading.
>
> Thank you you have re-invigorated me
>
> Chris
>
>
> On 2/04/2014 6:37 PM, Boudewijn Rempt wrote:
>>
>> Well, you post it as a rant, but I have to agree... The big problem is
>> that KDE4 is both a platform and a development framework, and the two are
>> mixed together.
>>
>> For Krita, I've stopped using the emerge system to get the dependencies,
>> because it's just too fragile. It's wonderful if you want to setup a
>> system with more than one kde application, but it didn't work for me for
>> creatinga single, standalone application that I could package and
>> distribute.
>>
>> I'm now using a cmake project with a bunch of externals. However, building
>> all the dependencies takes ages, too, so for my co-workers, I just share my
>> dev env with them, binary. I am building with msvc 2012, so there is no
>> pre-built Qt and there is no webkit. Oh, and update-mime-database doesn't
>> build correctly, so I need a pre-prepared mime directory to package. I still
>> haven't managed to strip down the oxygen icon set, either, and that's the
>> biggest part of the download.
>>
>> I am using a stripped-down kdelibs without dbus, kded, soprano -- and I
>> probably should cut out attica and so on as well. Part of this will be
>> solved by kf5, but since kxmlgui still needs dbus, part of it won't, if I
>> continue to use kxmlgui. Feel free to clone and hack:
>> http://quickgit.kde.org/?p=clones%2Fkdelibs%2Frempt%2Fkdelibs-stripped.git
>>
>> Note that I've hardcoded this kdelibs to store settings in
>> AppData\Local|Roaming\krita, not .kde, but still there is one or two things
>> in kde that seems hardcode to .kde.
>>
>> Also, no dbus means no kioslaves.
>>
>> Sysoca is pretty much the biggest bug-bear of my life on Windows. Because
>> krita/calligra actually uses the plugin query language in a lot of places, I
>> cannot replace it with simply loading all local plugins. If you, for
>> kmymoney, would just move to the Qt plugin system instead of the KDE one,
>> you probably would be fine and save a lot of aggravation.
>>
>> My current dev setup is like this:
>>
>> c:\dev\desktop32
>> c:\dev\desktop64
>> c:\dev\desktop32_d
>> c:\dev\desktop64_d
>>
>> i.e., base development directories for 32 and 64 bits builds,
>> relwithdebinfo and debug.
>>
>> Inside, I have an i directory where I install everything, and my source
>> tree, build directories and so on.
>>
>> Because I've hacked kbuildsycoca and krita's main to look for paths
>> relative to the exe, instead of environment variables, all these
>> installations run locally, without setting any environment and without
>> sharing anything.
>>
>> On Wed, 2 Apr 2014, Chris wrote:
>>
>>> <rant>
>>> As a developer who is trying to compile and then improve kmymoney on
>>> windows I must say it is the most painful process.
>>>
>>> If you want portability for KDE apps you need to uncouple applications
>>> from a lot of the hardcore KDE stuff. Just creating a suitable environment
>>> for building kmymoney has proved exhausting to the point of wanting to give
>>> up. Is it really worth the agro?
>>>
>>> I gave up two years ago and I am close to doing so again. What would help
>>> is a way of isolating those libraries that are absolutely necessary AND make
>>> it possible to have both a release copy of an application and a dev copy
>>> running on the same machine. Currently the plugin architecture forbids it
>>> without some serious acrobatics. Why the plugin system can't load a plugin
>>> that is in the same directory as the application I do not know. Thats the
>>> way dll's are loaded. App directory first, shared folders last. Why do I
>>> even need ksycoca4 I'll never know. Are you really trying to emulate windows
>>> registry? one of the worst inventions like ahh ever.
>>>
>>> Now I have to get back to the build process it appears a library that I
>>> was able to build last week cant be built this week. seems it cant find a
>>> header file... sighhhh....
>>>
>>> Oh and keep moving things to git that's is definately a major
>>> improvement.
>>>
>>> Did you hear subversion is moving to git.... No wait 1st of April ;)
>>>
>>> Chris
>>> </rant>
>>>
>>> On 2/04/2014 6:23 AM, Boudewijn Rempt wrote:
>>>>
>>>> On Tue, 1 Apr 2014, Jaroslaw Staniek wrote:
>>>>
>>>>> On 1 April 2014 20:31, Doug <dmcgarrett at optonline.net> wrote:
>>>>>>
>>>>>>
>>>>>> In my experience, there are very few KDE programs that work in
>>>>>> Windows. I
>>>>>> think the only ones I have are Dolphin, Find Files, and Kate, and I
>>>>>> think,
>>>>>> Solitaire.
>>>>>
>>>>>
>>>>> Maybe but I think it's not a technical barrier but missing apps need
>>>>> dedicated mainainers for Windows.
>>>>>
>>>>
>>>> Well, krita, too, but most windows users don't see the KDE part...
>>>> Except in the about box, of course. There were technical barriers though,
>>>> like stripping out dbus, kded, running kbuildsycoca4 after install. Other
>>>> barriers still exist, like translations not working (except, weirdly enough,
>>>> for the choose-language dialog box).
>>>>
>>>> Boud
>>>> _______________________________________________
>>>> Kde-windows mailing list
>>>> Kde-windows at kde.org
>>>> https://mail.kde.org/mailman/listinfo/kde-windows
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Kde-windows mailing list
>>> Kde-windows at kde.org
>>> https://mail.kde.org/mailman/listinfo/kde-windows
>>>
>> _______________________________________________
>> Kde-windows mailing list
>> Kde-windows at kde.org
>> https://mail.kde.org/mailman/listinfo/kde-windows
>>
>>
>
> _______________________________________________
> Kde-windows mailing list
> Kde-windows at kde.org
> https://mail.kde.org/mailman/listinfo/kde-windows