porting DC++ to Linux?
Moderator: Moderators
-
sploof
- Posts: 3
- Joined: 2003-03-21 01:52
porting DC++ to Linux?
One thing that a friend and i were talking about was porting DC++ to Linux. I use Linux more often than windows. Not to mention the countless others who would like to see something like DC++ for Linux. Well, anyways, I was wondering if there was a project going on to port DC++ to linux. If not, why not start one?
-
GargoyleMT
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-08 02:46
- Location: .pa.us
-
sploof
- Posts: 3
- Joined: 2003-03-21 01:52
-
Who
- Posts: 10
- Joined: 2003-01-28 15:47
Porting it...
Well I was thinking of porting all the GUI to wxWindows myself, so I guess that could be a great step because it would also compile for Linux (and Mac). So if someone wants to join... 
-
Who
- Posts: 10
- Joined: 2003-01-28 15:47
oh I forgot...
>The client code compiles cleanly under linux
compiles != works
I've seen some Windowish stuff lately in DC++ client lib, thank god it's into #define WIN32 blocks, but some features may not have it's *nix counterpart. Nothing to worry much about in any case... now porting the GUI seems much more complicated.
compiles != works
I've seen some Windowish stuff lately in DC++ client lib, thank god it's into #define WIN32 blocks, but some features may not have it's *nix counterpart. Nothing to worry much about in any case... now porting the GUI seems much more complicated.
-
GargoyleMT
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-08 02:46
- Location: .pa.us
compiles != works? fair enough, I haven't tried compiling, and I'd find it a bit hard to use without any type of interface.
At least knowadays you have a couple choices with regards to cross platform GUI toolkits... I heard a hint about someone porting to OS X, but only once, so I assume it didn't get far. In any case, if someone non-experienced tries the porting, it'd be a great learning experience (say hello to mr. resumé!).
At least knowadays you have a couple choices with regards to cross platform GUI toolkits... I heard a hint about someone porting to OS X, but only once, so I assume it didn't get far. In any case, if someone non-experienced tries the porting, it'd be a great learning experience (say hello to mr. resumé!).
-
Who
- Posts: 10
- Joined: 2003-01-28 15:47
read my previous post pal!
I said before I'm trying to port DC++ GUI to wxWindows, so if you wanna join... If you don't, just allow me to give you at least some advice: you will have a very hard time to start on your own if you don't have C++ or Win32-Linux porting experience, though. 
-
distiller
- Posts: 66
- Joined: 2003-01-05 23:05
- Location: Sweden
I've been thinking of learning wxWindows since I don't really like the layout of DC++ or the use of WTL... =) I need to know a good GUI toolkit for my other projects, so I'll help you out with the wxWindows port Sploof! I only have Windows right now, no space for Linux, but it will come on my next 'puter soon. =) If the port works in Windows, it should work on Linux right? =)
-
Who
- Posts: 10
- Joined: 2003-01-28 15:47
Porting to wxWindows
I'm currently comparing wxWindows GUI capabilities to those DC++ needs.
I will prepare a document with the conclusions.
We can start from Windows, and after it works, we'll tackle the Linux version. So it's about rebuilding DC++ GUI.
What ideas have you got about the GUI? (you say there are things you don't like from current DC++).
After we make decisions about what to do with the GUI, we'll start coding.
Meanwhile I'll wait for your opinions.
I will prepare a document with the conclusions.
We can start from Windows, and after it works, we'll tackle the Linux version. So it's about rebuilding DC++ GUI.
What ideas have you got about the GUI? (you say there are things you don't like from current DC++).
After we make decisions about what to do with the GUI, we'll start coding.
Meanwhile I'll wait for your opinions.
-
Jase
- Posts: 1
- Joined: 2003-01-05 09:40
Re: Porting to wxWindows
Who wrote:What ideas have you got about the GUI? (you say there are things you don't like from current DC++).
Current GUI is great. I've been using DC_GUI and it is just awful :D I would be pleased if the GUI would be same as in windows version.
-
Zalk
- Posts: 1
- Joined: 2003-04-03 20:46
Is there or is there not a dc++ for linux???
I wonder if there is a dc++ for linux (Red Hat 8.0)?
If there is one, can anyone give me a set by setp guide how to install it and download it?
Thank Zalk

If there is one, can anyone give me a set by setp guide how to install it and download it?
Thank Zalk
-
distiller
- Posts: 66
- Joined: 2003-01-05 23:05
- Location: Sweden
Hi again, my motherboard fried, waiting for a new one... =/ Will take a week more or so.
I agree with focusing on wxWindows for the Windows plattform, and then make any necessary adjustments for Linux after that.
Here comes my ideas so far for the GUI:
Since I'm interested in bringing segmented downloading to DC++ I want be able to group several downloads under one line in the up/download frame. A "+/-" to the left so that one can expand the group and see individual segments progress and from there modify segments.
I think there should be tabs for the uploads and downloads so that they are not in the same frame at the same time. (I'm not very interested in what others get from me. =))
User should be able to choose and enable/disable tabs in every window type and that info should be saved. I see no reason to have a field with "Directory" to the right in download queue fxp, that is in the left frame. In settings or maybee right click the tab-field and "customize".
That's it I think, the rest of the GUI works pretty well. =)
We need a good place to share code and test-builds, we could use www.lowertech.net , one of my fast domains?
I agree with focusing on wxWindows for the Windows plattform, and then make any necessary adjustments for Linux after that.
Here comes my ideas so far for the GUI:
Since I'm interested in bringing segmented downloading to DC++ I want be able to group several downloads under one line in the up/download frame. A "+/-" to the left so that one can expand the group and see individual segments progress and from there modify segments.
I think there should be tabs for the uploads and downloads so that they are not in the same frame at the same time. (I'm not very interested in what others get from me. =))
User should be able to choose and enable/disable tabs in every window type and that info should be saved. I see no reason to have a field with "Directory" to the right in download queue fxp, that is in the left frame. In settings or maybee right click the tab-field and "customize".
That's it I think, the rest of the GUI works pretty well. =)
We need a good place to share code and test-builds, we could use www.lowertech.net , one of my fast domains?
-
GargoyleMT
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-08 02:46
- Location: .pa.us
-
GargoyleMT
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-08 02:46
- Location: .pa.us
distiller wrote:Never used CVS... =) Don't have my computer on 24/7 either, so no use for me to host it that way. Links for CVS info/programs?
Anyway, not many people use the devhub. =)
Not many people use the dev hub, but only people of note use it.
You can check out wincvs.org or many other places for information on CVS. It's stunningly popular for source management.
-
Who
- Posts: 10
- Joined: 2003-01-28 15:47
To distiller...
mmm... we'll keep this suggestions in mind... but new features should be left for regular DC++ team. I mean we all love segmented dl and so, but first I think there is some work to be done with the buffered sockets problem.
You know, it's impossible that I get 200KB from web or other P2P clients and only 30-40KB from DC++. Something is wrong there. So imagine segmented dl...
I'm currently reading some docs so I'll contact you when we are ready to start. I have very little time these days.
You know, it's impossible that I get 200KB from web or other P2P clients and only 30-40KB from DC++. Something is wrong there. So imagine segmented dl...
I'm currently reading some docs so I'll contact you when we are ready to start. I have very little time these days.
-
distiller
- Posts: 66
- Joined: 2003-01-05 23:05
- Location: Sweden
Additional changes to the DC++ code shouldn't be made by us in this project, we'll just make the GUI work with wx. But we could try to make my ideas possible to implement GUI-wise. I work full-time and have a girlfriend who deserves most of my other free time. =) So I have little time as well, but it will still be possible. I'll ask a friend to put up a CVS when we're ready to start.
-
distiller
- Posts: 66
- Joined: 2003-01-05 23:05
- Location: Sweden
I've started to realize just how much work this is. But I'm still up for it. =)
Some things I've noted that will have to change:
Application Class
Threading
Menues
Dialoges, open, about, settings
Treeview
Tabs - up/downloads, settings
Lists - up/downloads and fileview in queue
Maybee event system (which could mean every "fire"?)
Localization (enumeration)
It's a 6 months project for 2 people. =)
Some things I've noted that will have to change:
Application Class
Threading
Menues
Dialoges, open, about, settings
Treeview
Tabs - up/downloads, settings
Lists - up/downloads and fileview in queue
Maybee event system (which could mean every "fire"?)
Localization (enumeration)
It's a 6 months project for 2 people. =)
-
chrisster
- Posts: 5
- Joined: 2003-03-28 00:50
I didn't see this mentioned in the thread so I figured I'd throw it out.
I have an idea for the GUI (from a coding standpoint). Why not use the Qt toolkit for GUI coding? I know for a fact that the Qt library is availble for both Windows and Linux (I have never done coding on a Mac so I don't know about that). Since the client code compiles under Linux, then that same code (minus the #ifdef WIN32 macros) could be used in conjunction with a Qt application.
I'm not sure how or if the function calls or class structures differ between the Windows and Linux ports, but I'm sure they can't be as different as ATL vs. X-Windows.
Of course, this would mean a complete re-write of the GUI and not a true port of the GUI. Nevertheless, it could make cross-platform development of DC++ easier in the future.
I have an idea for the GUI (from a coding standpoint). Why not use the Qt toolkit for GUI coding? I know for a fact that the Qt library is availble for both Windows and Linux (I have never done coding on a Mac so I don't know about that). Since the client code compiles under Linux, then that same code (minus the #ifdef WIN32 macros) could be used in conjunction with a Qt application.
I'm not sure how or if the function calls or class structures differ between the Windows and Linux ports, but I'm sure they can't be as different as ATL vs. X-Windows.
Of course, this would mean a complete re-write of the GUI and not a true port of the GUI. Nevertheless, it could make cross-platform development of DC++ easier in the future.
-
Windrider
- Posts: 4
- Joined: 2003-01-03 15:55
Well Qt is way different from ATL/MFC although it's one of the best choices for corssplatform programming, but given the fact ATL uses MFC down under and that wxWindows is very similar to MFC, probably that makes wxWindows the best choice over other options (Qt, GTK, FLTK or FOX).
Volkris: Xul is simply too much, it's bigger than wxWindows or QT, slow, and bloated.
Volkris: Xul is simply too much, it's bigger than wxWindows or QT, slow, and bloated.
-
volkris
- Posts: 121
- Joined: 2003-02-02 23:07
Windrider wrote:Volkris: Xul is simply too much, it's bigger than wxWindows or QT, slow, and bloated.
I was half joking there, I should have indicated it.
But I was half serious.
XUL is actually not as bad as you indicate. On my machines it's actually a bit faster than many QT applications (then again, what kind of bechmarks can actually determine what is faster?). And in what terms do you mean bigger?
Especially with the forthcoming GRE, XUL has promise.
-
volkris
- Posts: 121
- Joined: 2003-02-02 23:07
Windrider wrote:Xul apps faster than QT? Surely that's bad coding of QT apps.
Once you have the XUL engine running it's really fast.
This makes sense to me, though. Whether it's on Windows or Linux, often working in the browser happens to be a little snappier than working with applications using native widgits.
But again, what is "faster"? These are just my perceptions on isolated trials. It only shows that XUL CAN feel faster than Qt, that it's not impossible.
-
chrisster
- Posts: 5
- Joined: 2003-03-28 00:50
-
GargoyleMT
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-08 02:46
- Location: .pa.us
-
distiller
- Posts: 66
- Joined: 2003-01-05 23:05
- Location: Sweden
wxWindows is quick in my tests, and doesn't seem to be too hard to learn. =) It also has the needed threading, timing and variable types we need to make the code portable "easily", so I really think it's the best way to go.
I'll be making commercial programs later on that use the library I decide upon now. I won't be using QT then for obvious reasons, so why learn two libraries?
I'll be making commercial programs later on that use the library I decide upon now. I won't be using QT then for obvious reasons, so why learn two libraries?
-
volkris
- Posts: 121
- Joined: 2003-02-02 23:07
Well, why be bound to a specific GUI at all?
Why not follow in DCTC's footsteps and make what amouts to a backend that can be connected to with whatever interface a user wishes? This is more the Linux way to do things anyway.
Once you have something like that working you almost automatically get the ability to connect to the background process with a client actually runnnig on any other windows or Linux computer elsewhere on the Internet.
Actually, why talk about making/porting a new client at all? It might just be easier to improve upon one of the already existant Linux clients than go throught he trouble of porting DC++. But what do I know.
Why not follow in DCTC's footsteps and make what amouts to a backend that can be connected to with whatever interface a user wishes? This is more the Linux way to do things anyway.
Once you have something like that working you almost automatically get the ability to connect to the background process with a client actually runnnig on any other windows or Linux computer elsewhere on the Internet.
Actually, why talk about making/porting a new client at all? It might just be easier to improve upon one of the already existant Linux clients than go throught he trouble of porting DC++. But what do I know.
-
distiller
- Posts: 66
- Joined: 2003-01-05 23:05
- Location: Sweden
DC++ is one of the leading clients, and I believe it will become #1 if it isn't already. DC++ will also get new features that make it more competetive than any other client. If DC++ can be used on more plattforms more users will be able to use the features and they will work better since more online clients support them. We need a port, and we need code that works on all platforms. wxWindows supports sockets, timers, threading and everything else we need for the code to work on all plattforms.
About the idea of separating the GUI from the client, well, it would of course be possible but it isn't anything I'm interested in doing. I know the Linux way: "Make so many different versions that are all half-done that the users can not choose one good client."
Let's not make DC++ that bad favor...
About the idea of separating the GUI from the client, well, it would of course be possible but it isn't anything I'm interested in doing. I know the Linux way: "Make so many different versions that are all half-done that the users can not choose one good client."
Let's not make DC++ that bad favor...
-
Neg
- Posts: 20
- Joined: 2003-01-19 12:05
Im not that experienced with corsscompability GUI code but this is how i sloved my corosscompability isse with threads and sockets.
I created classes for them and seperated them from what ever project i need them in. The only link bethwine them are the header files. This way nerly all my console applicatons is corsscompatible (only a few that use some wery odd functions need to be changed a bit befor compiling). Then if i compile it in a win it use the windows source files for my classes and in linux it use the linux sources (The thure is i use precompiled librarys but you get the picture).
I have no ide if this method is efficent for GUI stuff but it works real nice for sockets and threads.
I created classes for them and seperated them from what ever project i need them in. The only link bethwine them are the header files. This way nerly all my console applicatons is corsscompatible (only a few that use some wery odd functions need to be changed a bit befor compiling). Then if i compile it in a win it use the windows source files for my classes and in linux it use the linux sources (The thure is i use precompiled librarys but you get the picture).
I have no ide if this method is efficent for GUI stuff but it works real nice for sockets and threads.
-
GargoyleMT
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-08 02:46
- Location: .pa.us
that would be "cross-platform"
The standard way would be to only have source base, and then test for the existance and versions of various predefined variables, such as WIN32, etc. This way, you have a single source repository and you're using the existing mechanisms to determine what environment you're being compiled in, and react appropriately.
-
volkris
- Posts: 121
- Joined: 2003-02-02 23:07
distiller wrote:DC++ will also get new features that make it more competetive than any other client. If DC++ can be used on more plattforms more users will be able to use the features and they will work better since more online clients support them. We need a port, and we need code that works on all platforms. wxWindows supports sockets, timers, threading and everything else we need for the code to work on all plattforms.
About the idea of separating the GUI from the client, well, it would of course be possible but it isn't anything I'm interested in doing. I know the Linux way: "Make so many different versions that are all half-done that the users can not choose one good client."
Let's not make DC++ that bad favor...
Well, this is kind of funny to me.
At least two Linux clients have more features than DC++, and are therefore more competitive except that they don't run on windows. Under this reasoning we should be porting THOSE to replace DC++.
Seperation of GUI from client has nothing to do with half finished-ness of software. In fact if often results in multiple-finishedness as the same backend can be finished off in multiple ways.
But in the end, if you're worried about the half-done programs on Linux you'd be picking up one of those projects, not starting another.
-
distiller
- Posts: 66
- Joined: 2003-01-05 23:05
- Location: Sweden
DC++ is more widely used, mostly since it's the best DC-client for the windows plattform. Actually the Linux community doesn't need DC++ at all, but I want it on my Linux machine as I use DC++ on my windows machine. =) And please don't forget that using wxWindows doesn't only give us Linux support but Mac as well. (not that that's a top priority.. =)) Even if we ported a Linux client to windows it would not become as popular as DC++ is, at least not the next couple of years... Can you believe there's still people using NMDC??
Also I am familiar with the DC++ source code and have no time to start studying another dc-client's source code. Yeah, just call me lazy.
Also I am familiar with the DC++ source code and have no time to start studying another dc-client's source code. Yeah, just call me lazy.
-
Who
- Posts: 10
- Joined: 2003-01-28 15:47
Starting port...
ok, I'm requesting a sourceforge project. Things will go slowly first as my laptop is still repairing, but I think it'll be interesting.
I think I'll redo not only the GUI part, but also some of the client one,
because I want to fully use the wx library. This means using wxSockets,
wxTimer and wxThreads...
so this will end up being more a DC++ clone by itself than a DC++ port.
Wish me luck!
Who
I think I'll redo not only the GUI part, but also some of the client one,
because I want to fully use the wx library. This means using wxSockets,
wxTimer and wxThreads...
so this will end up being more a DC++ clone by itself than a DC++ port.
Wish me luck!
Who
-
volkris
- Posts: 121
- Joined: 2003-02-02 23:07
Re: Starting port...
Who wrote:so this will end up being more a DC++ clone by itself than a DC++ port.
Wish me luck!
Who
Well, since you're entering the territory of clone, would you be willing to include some more advaned features that havn't made it into DC++?
-
GargoyleMT
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-08 02:46
- Location: .pa.us
Re: Starting port...
volkris wrote:Well, since you're entering the territory of clone, would you be willing to include some more advaned features that havn't made it into DC++?
*ahem* Like what? Nothing I've seen you propose so far can't be done in DC++, as long as someone's willing to code it.
-
Ryan O'Connell
- Posts: 6
- Joined: 2003-03-30 23:18
-
TheParanoidOne
- Forum Moderator
- Posts: 1420
- Joined: 2003-04-22 19:37
Re: Starting port...
Who wrote:ok, I'm requesting a sourceforge project.
Just out of curiosity, has this happened yet?
-
GargoyleMT
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-08 02:46
- Location: .pa.us
Re: Starting port...
TheParanoidOne wrote:Just out of curiosity, has this happened yet?
I see Mac DC++ as a SF project... And they have stuff in CVS.
Unixman also hinted that he'd solicit for serious help for his linux port here.
-
Naga
- Posts: 45
- Joined: 2003-12-02 16:24
- Location: Sweden
-
GargoyleMT
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-08 02:46
- Location: .pa.us
Naga wrote:Just my two cents but what I would like is a DC++ port not a clone since there are many good hubs out there that just accept DC++ and oDC. Thus I would like a client that is DC++ but runs on Linux.
I'm a little confused, since arne calls DC++ mods clones. Are you saying that you'd much rather have a ported DC++ than one of the existing unix DC clients?
Naga wrote:Another thing is this port/clone project that was discussed dead or...?
The Linux one? No, I don't think so. I don't know what the progress is on it, the main porter wants the code to be in a pretty closed group until it gets usable/stable. As for the Mac DC++ port, you can check the dates on the CVS commits in their sourceforge page, they all seem fairly recent.
-
Naga
- Posts: 45
- Joined: 2003-12-02 16:24
- Location: Sweden
I'm a little confused, since arne calls DC++ mods clones. Are you saying that you'd much rather have a ported DC++ than one of the existing unix DC clients?
Yes for the above reason. I don't enjoy getting banned (yes it has happend) just for connecting to my favorite hub when running Linux. <br>
And since the code contains comments about Linux (or is it Unix) compability I get the feeling that it is supposed to be portable. But since I'm a novice ( but willing to learn
Who is online
Users browsing this forum: Google [Bot] and 0 guests