porting DC++ to Linux?
Moderator: Moderators
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?
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
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...
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.
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21: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é!).
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.
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? =)
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.
Re: Porting to wxWindows
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.Who wrote:What ideas have you got about the GUI? (you say there are things you don't like from current DC++).
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
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?
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Not many people use the dev hub, but only people of note use it. Fusbar, cologic, Opera, Sandos, Sedulus, aDe, mo, yilard, and even arne gets on once every couple days.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. =)
You can check out wincvs.org or many other places for information on CVS. It's stunningly popular for source management.
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.
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.
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. =)
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.
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.
I was half joking there, I should have indicated it.Windrider wrote: Volkris: Xul is simply too much, it's bigger than wxWindows or QT, slow, and bloated.
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.
Once you have the XUL engine running it's really fast.Windrider wrote: Xul apps faster than QT? Surely that's bad coding of QT apps.
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.
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
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?
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.
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...
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.
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21: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.
Well, this is kind of funny to me.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...
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.
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.
I'm not a programmer, but have been dabbling with Wine and DC++ works fine in Linux using Wine. Would it be possible to use Winelib to make a port in Linux?
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
Re: Starting port...
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++?Who wrote: so this will end up being more a DC++ clone by itself than a DC++ port.
Wish me luck!
Who
features
Hi,
sure I'll add new features... but there is still a very long way
My first aim is being able to connect to a hub, and do some basic functions.
Meanwhile, you can submit your suggestions here.
Who
sure I'll add new features... but there is still a very long way
My first aim is being able to connect to a hub, and do some basic functions.
Meanwhile, you can submit your suggestions here.
Who
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Re: Starting port...
*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.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++?
-
- Posts: 6
- Joined: 2003-03-30 18:18
-
- Forum Moderator
- Posts: 1420
- Joined: 2003-04-22 14:37
Re: Starting port...
Just out of curiosity, has this happened yet?Who wrote:ok, I'm requesting a sourceforge project.
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Re: Starting port...
I see Mac DC++ as a SF project... And they have stuff in CVS.TheParanoidOne wrote:Just out of curiosity, has this happened yet?
Unixman also hinted that he'd solicit for serious help for his linux port here.
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
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: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.
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 wrote:Another thing is this port/clone project that was discussed dead or...?
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>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?
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 ) programmer I'm not sure.