We're porting to Linux: and paying!

[Crise 26]

Please refer to our new jobs page regarding the Linux port.

• Get current StrongDC core to compile under mingw (to resolve compiler related issues)
• Fix any win32 specific parts in StrongDC core to compile under linux, to list a few
  1. Certain ulitity and other functions
  2. Possibly DHT and Webserver related code

[*]Rewrite UI with wxwidgets (at least code::blocks has wxwidgets related tools that can be used, might help)

Any questions/feedback can be discussed below please.

[Lee 84]

Bumping this because it was in our staff room.

Just a heads up that the whole DC++ core does not need porting over, it should compile easily already. It's just our and StrongDC++'s modifications (since we're based on them) that need porting.

[Big Muscle 1]

Neither DHT norr webserver code are Win32 specific and I don't see any reason why they should be. Both are platform independent.

[Crise 26]

Neither DHT norr webserver code are Win32 specific and I don't see any reason why they should be. Both are platform independent.

Actually the webserver code has some win32 dependant bits, see WebServerSocket::accept and the use of ServerSocket::incoming (also it has some unused members like a HWND that is never used anywhere that are win32 specific).

There is also at least one win32 specific bit in DHT code in UDPSocket::run().

The there are for example PopupManager. the initialization of this can just be moved to MainFrame without any consequences afaik though. Then there is Util::fileExists. These I can name at the top of my head.

[Big Muscle 1]

There is also at least one win32 specific bit in DHT code in UDPSocket::run().

Ah, you're right. I forgot about it, because I have already fixed it in my local code. That code doesn't have to be there for Linux, because it's fix for Windows bug.

[Mforce 0]

I've already started a port of LinuxDC++ to Qt and I intend to make it cross-platform. Preliminary results can be seen here : http://onyxdc.sourceforge.net/

I think Qt is a much better choice for cross-platform ,it's activerly manintained by Nokia, has very good performance on all platforms and it has more useful libraries which can eventually be used, not only GUI ( it has an XML parser for instance ). Also I intend to remake the build system using cmake.

I'm going to continue development whether it's paid or not but of course some payment would be nice and also some help and support from the ApexDC development staff would also help.

Let me know if you want to talk about this.

[Oyashiro 3]

I used both Qt and wxWidgets and IMHO

1. wxWidgets is easier than Qt
   
2. wxWidgets takes less time to build
   
3. wxWidgets uses native platform functions to draw GUI so it is a bit faster than Qt which draws everything by itself
   
4. both wxWidgets and Qt have different non-GUI-related classes
   

However, I think it is possible to develop both wxWidgets and Qt versions to leave the decision of what version to download to users who don't like to install lots of packages.

[Crise 26]

wxWidgets uses native platform functions to draw GUI so it is a bit faster than Qt which draws everything by itself

This is the main point which I like about wxWidgets.

[GenTiradentes 0]

Sounds interesting, I'd like to take a shot at helping port the core.

A little information about the scope of the project would be nice. What sort of obstacles would one be facing in the port? Are there any non-standard compiler extensions used? Platform specific graphical, audio, threading, or networking APIs or libraries used?

Cheers.

[Mforce 0]

We can debate this about wxWidgets and Qt but in the end I don't think wxWigets has anything better to offer that Qt doesn't. Important software projects already use Qt for cross-platform one of them being Google Earth. And I don't think Google Earh is slow. Yes , Qt does indeed do its own drawing but there are various backends it can use to do that including one using OpenGL and improvements are always considered to make it faster.

Anyway my experience is with Qt and that's what I want to learn. I've already used it in my project, found it to be appropriate for my needs and it's what I'd use for ApexDC. I also like the way Qt looks and the fact that its appearance can be easily changed.

[Crise 26]

A little information about the scope of the project would be nice. What sort of obstacles would one be facing in the port? Are there any non-standard compiler extensions used? Platform specific graphical, audio, threading, or networking APIs or libraries used?

Core here means dcpplib, which is already compiling on linux in its unmodified form, only things that need porting are any differences to it that originate from us and StrongDC that may not compile on linux. So stuff like basic networking and threading code as well as third party libraries should very much be platform independent already. Regarding compiler extensions I am not aware of the code relying on any of those.

The scope of points one and two isn't anything overwhelming I would think because of the reasons stated above and the fact that while there are plenty of modifications they are mostly adding functionality and thus using the existing code that is already linux friendly where possible.

The third point is what's the overwhelming part... however, without the first two steps done we won't be able to work on that at all.

[DerLeiter 0]

I've already started a port of LinuxDC++ to Qt and I intend to make it cross-platform. Preliminary results can be seen here : http://onyxdc.sourceforge.net/

We already have Qt based DC++ client - EiskaltDC++ (http://code.google.com/p/eiskaltdc/). There is ChangeLog

[Big Muscle 1]

I saw WTL->wxWidgets port guide somewhere but I'm not able to find it now. I don't know how QT code looks, but wxWidgets are very similar to WTL, so it should be much easier.

[kas 0]

We're porting to Linux: and paying!

1)Why!?

Cross-platform full-featured client has already written - it EiskaltDC++, it is licensed under GPLv3 or later with the additional exemption that compiling, linking, and/or using OpenSSL is allowed. EiskaltDC++ based on Qt. You can be united to the EiskaltDC++ team.

2)Why wxWidgets!? You've seen programs written using wxWidgets? For example, FileZilla, aMule - they look ugly.

Screenshot EiskaltDC++

ChangeLog

[Big Muscle 1]

1) It looks like that EiskaltDC++ is DC++ mod. Since it is licensed under GPLv3, it violates DC++ license.

2) I have seen wxWidgets app, I already made some. And if someone says that it looks ugly, it is because his OS theme looks ugly. My app looks like any other app http://img819.imageshack.us/f/screenshotck.png/

[kas 0]

1) It looks like that EiskaltDC++ is DC++ mod. Since it is licensed under GPLv3, it violates DC++ license.

2) I have seen wxWidgets app, I already made some. And if someone says that it looks ugly, it is because his OS theme looks ugly. My app looks like any other app http://img819.imageshack.us/f/screenshotck.png/

1)core DC++ licensing under GPLv2 or later.

ChangeLog - you read it? - EiskaltDC++ is already very functional, and it is only the beginning.

That ApexDC++ - is not DC++ mod ?

2)"it is because his OS theme looks ugly" - i am use standart theme in KDE - and programs on wxWidgets looks ugly(they looks non standart in current DE - it does not fix):

FileZilla

aMule

My screenshot FileZilla - looks non standart in KDE

[Big Muscle 1]

Where did you take "or later"?

DC++ license file says:

This program is licensed under GPL-2 with the notable exception

that you may compile and link it with OpenSSL (www.openssl.org)

and WTL (wtl.sourceforge.net).

It is true that each file contains:

* This program is free software; you can redistribute it and/or modify

* it under the terms of the GNU General Public License as published by

* the Free Software Foundation; either version 2 of the License, or

* (at your option) any later version.

but this text doesn't specify the license version. It is only pure copy of statement from FSF. Important thing is "or (AT YOUR OPTION) any later version", but, according to license.txt, this option hasn't been selected.

to theme: how does default KDE theme look like? wxWidgets use native theme drawing - it looks normal on all Windows version. So I am interested how the app theme is different from KDE theme.

[Oyashiro 3]

It seems that Apex forum is invaded by PR group of Eiskalt

2)"it is because his OS theme looks ugly" - i am use standart theme in KDE - and programs on wxWidgets looks ugly(they looks non standart in current DE - it does not fix):

so what? use alternative apps based on Qt instead of wxGTK-based or if you want them to look good change from glamourous fat KDE to GNOME and find a nice theme, as Qt still cannot render GTK apps normally (at contrary GNOME with small qgtkstyle renders Qt-based apps perfectly)

2 Lee, Crise and other developers: don't listen to this KDE fans and continue developing Apex. Apex is one of several software (and maybe the most important of them) which makes me using Windows more than Linux

to theme: how does default KDE theme look like? wxWidgets use native theme drawing - it looks normal on all Windows version. So I am interested how the app theme is different from KDE theme.

there is no native wxWidgets version for Qt, right name of Linux version of wxWidgets is wxGTK, so it is renders as native only in GNOME

[kas 0]

Where did you take "or later"?

DC++ license file says:

It is true that each file contains:

but this text doesn't specify the license version. It is only pure copy of statement from FSF. Important thing is "or (AT YOUR OPTION) any later version", but, according to license.txt, this option hasn't been selected.

to theme: how does default KDE theme look like? wxWidgets use native theme drawing - it looks normal on all Windows version. So I am interested how the app theme is different from KDE theme.

1)DCPlusPlus-0.762-src/COPYING.TXT:

...

you can redistribute it and/or modify

it under the terms of the GNU General Public License as published by

the Free Software Foundation; either version 2 of the License, or

(at your option) any later version.

...

That is enough. 2)All files from directory DCPlusPlus-0.762-src/dcpp/ have a lines:

/*

 * Copyright (C) 2001-2010 Jacek Sieka, arnetheduck on gmail point com

 *

 * This program is free software; you can redistribute it and/or modify

 * it under the terms of the GNU General Public License as published by

 * the Free Software Foundation; either version 2 of the License, or

 * (at your option) any later version.

 *

 * This program is distributed in the hope that it will be useful,

 * but WITHOUT ANY WARRANTY; without even the implied warranty of

 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the

 * GNU General Public License for more details.

 *

 * You should have received a copy of the GNU General Public License

 * along with this program; if not, write to the Free Software

 * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.

 */

3)EiskaltDC++ is already included in the official repositories Debian (Ubuntu).

Do you think that in Debian are working dilettantes?

to theme: See above answer Oyashiro

[DerLeiter 0]

but this text doesn't specify the license version. It is only pure copy of statement from FSF. Important thing is "or (AT YOUR OPTION) any later version", but, according to license.txt, this option hasn't been selected.

License specified in source code has a higher priority than the license specified in file LICENSE. So EiskaltDC++ has no problems with licenses. Details

[PPK 0]

Where did you take "or later"?

In DC++, where you think they took that. 275 files in DC++ 0.762 contains that. All sources where is that are GNU GPL version 3 compatible.

but this text doesn't specify the license version.

Then read it again, and again and again. Maybe if you read it few times you can notice that it contains "version 2" (yes it is contains license version!) and "or (at your option) any later version" (version 3 is later version than 2)

DC++ code GNU GPL version 3 compatibility was discussed in dc dev private hub. So you can ask your (a)dc friends about that if you always think that DC++ code is not GNU GPL version 3 compatible

[2009-08-06 09:30:23] <cologic> According to http://bazaar.launchpad.net/~dcplusplus-team/dcplusplus/trunk/annotate/head%3A/License.txt DC++ is still GPLv2, but per http://lwn.net/Articles/343608/ it looks like without either changing to GPLv3 or adding a license exemption like that for OpenSSL linking against the GPLv3 libgcc licensing introduced in gcc 4.4 violates the GPLv2.

[2009-08-06 09:31:06] <cologic> (DC++ isn't 'GPLv2 or later' either)

[2009-08-06 17:55:02] <Crise> [00:31:02] <cologic> (DC++ isn't 'GPLv2 or later' either) ??

If that is the case then License text file is inconsistent with the source code headers as they do say ", or (at your option) any later version." whch you can check from pretty much any source file in dcpp or win32 dirs (I only checked a few tho, but the point is these inconsistensies should be fixed)

[2009-08-06 17:56:37] <cologic> oh

[2009-08-06 17:56:53] <cologic> didn't look that far. Guess that solves things.

[Crise 26]

Ok, EiskaltDC++ and it's licensing is not the topic of discussion here... but I have to say that I too am under the impression that (even if it may be copy paste from FSF) the mention about later GPL versions in file headers is valid for anyone wanting to use the code.

1)Why!?

Cross-platform full-featured client has already written - it EiskaltDC++, it is licensed under GPLv3 or later with the additional exemption that compiling, linking, and/or using OpenSSL is allowed. EiskaltDC++ based on Qt. You can be united to the EiskaltDC++ team.

2)Why wxWidgets!? You've seen programs written using wxWidgets? For example, FileZilla, aMule - they look ugly.

Screenshot EiskaltDC++

ChangeLog

Regarding EiskaltDC++ sure it is a nice project but I have addressed the topic of project merges earlier in the topic about this over at news forum (also in the specific case of EiskaltDC++ there could be some language barriers, since I see lot of the stuff regarding it are in russian). I have nothing particularly against Qt but my reasons for favoring wxWidgets is that it can look 100% native on windows (which until proven otherwise is the majority of our userbase).

While easily being able to change appearance (one point mentioned for Qt) might be a point of interest for us regarding future even so I appreciate that my apps can look like native applications if I so wish.

[kas 0]

Regarding EiskaltDC++ sure it is a nice project but I have addressed the topic of project merges earlier in the topic about this over at news forum (also in the specific case of EiskaltDC++ there could be some language barriers, since I see lot of the stuff regarding it are in russian). I have nothing particularly against Qt but my reasons for favoring wxWidgets is that it can look 100% native on windows (which until proven otherwise is the majority of our userbase).

Developers EiskaltDC++ understands English, but ordinary users write their own bug-report and feature-request in Russian. I think that language barrier will not.

The language barrier can be overcome by new rule for the issue tracker EiskaltDC++:

All bug reports and feature-request in English only.

[Oyashiro 3]

I have nothing particularly against Qt but my reasons for favoring wxWidgets is that it can look 100% native on windows (which until proven otherwise is the majority of our userbase).

It looks native not only on Windows but also on GNOME, Windows Mobile, MacOS (not sure about this, but as it has wxMac port I think it should have native look).

Also it has an interesting widget wxAuiNotebook that can help Apex to leave its "classic" look. For example my attempt to write code for Zion style tabs in wxWidgets resulted in success (took about half an hour to understand how it works and to write the needed code):

[DerLeiter 0]

I have nothing particularly against Qt but my reasons for favoring wxWidgets is that it can look 100% native on windows (which until proven otherwise is the majority of our userbase).

Qt 4.6 uses native styles for drawing controls on each operating system such as Mac OS X or Windows.