Windows Release

[Gengis Dave]

Hi all,

following one of the last bugs opened (https://bugs.kde.org/show_bug.cgi?id=412016) stating that Dolphin has a Windows binary, and the Phabricator task opened by Lydia (https://phabricator.kde.org/T9581), I wanted to test if Krusader could be compiled too.

I managed to get a working executable, well, not too much working: the main window is starting but it's not showing file listing, no Konfigurator at all, no dependencies found, no settings, no menus, no icons.

At the moment, I simply commented out all the Unix-related code; that code should be rewritten by zero as in Dolphin.

While this could be a good goal, I don't want to release an unfunctional or semifunctional version of Krusader; also, this would take away time that could be spent on bugs fixing (as stated by Alex). What do you think about it?

Thank you very much
Davide

[Nikita Melnichenko]

Hi Davide,

Thanks for trying this out. You said that you commented out all the unix-specific code, so it's obvious the app won't have core functionality. If we put the code in appropriate ifdefs instead, we can keep unix and windows versions in a compilable state. Unix version will have full functionality, while for the windows code branch we can put special todo tags stating that it needs implementation. Whenever someone is interested in contributing to the windows build, everything would ready to solve the problem step by step.

I agree with Alex that working on windows branch will take away time if we collectively set bringing windows build to a full functionality as a goal. However, in case somebody shows more enthusiasm in debugging the windows version rather than fixing tail issues with unix version, why stop this person? I think that the most essential part to the success of windows version will be setting everything up for evolutional approach. Since this task is rather big, making environment and code ready for contribution and splitting the task into smaller pieces (fix file listing, fix settings dialog, etc.) should help a lot in attracting developer attention.

To summarize, the proposed items / steps are:

1. #ifndef Q_OS_WIN, #else // todo: needs windows-specific implementation, #endif (compilable for both systems)

2. Describe in wiki / readme how to set up the environment, compile the source code, which tools to use for debugging.

3. Making an initial list of components that are not working (we can use the task page for this). It may be high level for now. Once things getting fixed, it will become more precise.

Since you explored this already, would you mind doing #1, #2? I can help reviewing. I may look why essentials like file listing are not working some time after this.

Thanks,

Nikita.

--
You received this message because you are subscribed to the Google Groups "krusader-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to krusader-deve...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/krusader-devel/b8482a2c-9d2c-435c-a922-7f162ebd9409%40googlegroups.com.

[Gengis Dave]

Hi Nikita,

this is the bare patch to let Krusader compile on Windows. As you can see there are few methods to change, most of them are related to glibc.

In a first phase, I would change the code inline, but I think it will require a new abstraction layer to change all the unix harcoded references and keep the code clean.

I would create a new git branch called 'windows' based on master with the //TODOs and notes relative to the task, also I will put on Phabricator the instructions to set up the environment and compile the code.

In a parallel way, I would like to expand the documentation on the classes, but it should take a lower priority. I think the first approach to the code would be easier with a proper inline documentation. The aim is not to create a complete api reference, but to give to new developers more informations.