42 replies to this topic

[Crise]

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
  • Certain ulitity and other functions
  • 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]

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]

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

[Crise]

Big Muscle, on 07 June 2010 - 02:58 PM, said:

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]

Crise, on 07 June 2010 - 03:25 PM, said:

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]

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]

I used both Qt and wxWidgets and IMHO

• wxWidgets is easier than Qt
  
• wxWidgets takes less time to build
  
• wxWidgets uses native platform functions to draw GUI so it is a bit faster than Qt which draws everything by itself
  
• 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]

Oyashiro, on 07 June 2010 - 09:20 PM, said:

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]

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]

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]

GenTiradentes, on 08 June 2010 - 07:13 AM, said:

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]

Mforce, on 07 June 2010 - 04:37 PM, said:

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]

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]

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) 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.images...reenshotck.png/

[kas]

Big Muscle, on 12 June 2010 - 12:11 PM, said:

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.images...reenshotck.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]

Where did you take "or later"?

DC++ license file says:

Quote

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:

Quote

* 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]

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

kas, on 12 June 2010 - 12:39 PM, said:

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

Big Muscle, on 12 June 2010 - 03:09 PM, said:

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]

Big Muscle, on 12 June 2010 - 03:09 PM, said:

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]

Big Muscle, on 12 June 2010 - 03:09 PM, said:

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