aMule Forum
English => Feature requests => Topic started by: JuanC on May 12, 2007, 01:24:29 PM
-
I think Qt4 is by the far better than wxwidgets.
Some projects that use wxwidgets are port the GUI code to Qt4.
Qt4 use better look and feel on the operating system you are using.
-
No?
-
Feel free to support the planned QT-Remote-GUI and use amuled+this GUI (once it is finished).
-
Feel free to support the planned QT-Remote-GUI and use amuled+this GUI (once it is finished).
A question, wxwidgets is remote-gui too? I mean, there is no possibility to have a different gui without wxwidgets dependencies?
-
?
EC is independant from wxWidgets. You can code a remote GUI in whatever you want.
-
Feel free to support the planned QT-Remote-GUI and use amuled+this GUI (once it is finished).
Fell free to support already being implemented C# (.NET) remoge-GUI. EC is already ported, and GUI is being developed. Since it will work (hopefully) under mono, I see no reason to start with Qt.
Regarding "Qt is far better". Actually, only Qt Designer is better. Rest is virtually the same, unless QString sounds better wxString :). And both (unfortunately) completely fall behind "Visual C# basic edition". C# is standatd and free (as freedom) and "Visual C#" is also free (now as a beer).
-
And lfroen loves C#. You are still welcome to develop in QT if you feel like it. The more the merrier.
-
?
EC is independant from wxWidgets. You can code a remote GUI in whatever you want.
I mean, the amule default GUI is REMOTE GUI or not? I mean, if there is another GUI i need wxwidgets to compile amule or not.
-
You'll need wxbase for amuled.
-
You'll need wxbase for amuled.
Ok, so is not independant. That was my question...
-
You were asking GUI.
-
And lfroen loves C#. You are still welcome to develop in QT if you feel like it. The more the merrier.
You wrong (in "loves C#" part). It just happens to have best GUI design tools out of all alternatives.
I mean, the amule default GUI is REMOTE GUI or not?
As the name suggests, "remote" GUI is used to control amule remotely, which means that core and GUI can run separately. In "default" amule (one that started by "amule" command) core and GUI are compiled together.
-
There is already a wxWidgets based remote gui...
-
Who is we? You and ...?
-
I still fail to see the advantages of doing such thing. You assume eMule or aMule wants to merge with someone else, or between themselves. That's your first mistake.
-
Oh good lord in heaven.
EARTH TO MULINEX. WE DON'T WANT TO DO THAT. NEITHER WANTS EMULE.
-
Fell free to support already being implemented C# (.NET) remoge-GUI. EC is already ported, and GUI is being developed. Since it will work (hopefully) under mono, I see no reason to start with Qt.[/quote ]
Reason
C# will only "hopefully" work under mono. While WxWidgets and Qt are 100% supported and 100% free in freedom.
And both (unfortunately) completely fall behind "Visual C# basic edition". C# is standatd and free (as freedom) and "Visual C#" is also free (now as a beer).
Visual C# is just the ide, it doesn`t matter much what license is used.
Also interesting: to see the incompatibilities: http://johnhaller.com/jh/useful_stuff/dotnet_portable_apps/. Also a not installed or not installable net framework will cause a lot new support requests and users switching to other clients. Also no more way to use this app on the go (usb).
And C# is not really free in freedom. Patent bomb: http://en.wikipedia.org/wiki/.NET_Framework#Standardization_and_licensing
-
Fell free to support already being implemented C# (.NET) remoge-GUI. EC is already ported, and GUI is being developed. Since it will work (hopefully) under mono, I see no reason to start with Qt.[/quote ]
Reason
C# will only "hopefully" work under mono. While WxWidgets and Qt are 100% supported and 100% free in freedom.
One word: FUD. Qt is not exactly free and Wx is not exactly supported and not exactly works on Windows.
And both (unfortunately) completely fall behind "Visual C# basic edition". C# is standatd and free (as freedom) and "Visual C#" is also free (now as a beer).
Visual C# is just the ide, it doesn`t matter much what license is used.
Yea, it is just ide for C# and not for Wx/Qt. And this "just IDE" is a very reason to use C#. What was your point again?
Also interesting: to see the incompatibilities: http://johnhaller.com/jh/useful_stuff/dotnet_portable_apps/. Also a not installed or not installable net framework will cause a lot new support requests and users switching to other clients. Also no more way to use this app on the go (usb).
And C# is not really free in freedom. Patent bomb: http://en.wikipedia.org/wiki/.NET_Framework#Standardization_and_licensing
Even more FUD. Search this forum for "amule crashed because of broken wx install" and stop the BS.
Patents are completely irrelevant here. First of all, we're not developing C# compiler. I'm using completely legal software any way you put it. Freely redistributed by MS and in compliance with their EULA. Let Mono people to deal with the issue, OK?
-
Why use Windows Forms for multi platform amule if not even Windows Forms are nearly finished in mono project?
One word: FUD. Qt is not exactly free and Wx is not exactly supported and not exactly works on Windows.
Qt is free in freedom. There is a gpl version you can use with all freedom given by gpl, you can even fork it, everything. Just if you want to keep your source closed you need to buy a commercial license. What`s not free about the gpl version?
Yea, it is just ide for C# and not for Wx/Qt. And this "just IDE" is a very reason to use C#. What was your point again?
The license of the ide doesn`t matter because anyone can build it even without ide or with alternative ide. But the license of buildtools does matter.
Even more FUD. Search this forum for "amule crashed because of broken wx install" and stop the BS.
Patents are completely irrelevant here. First of all, we're not developing C# compiler. I'm using completely legal software any way you put it. Freely redistributed by MS and in compliance with their EULA. Let Mono people to deal with the issue, OK?
Oh, just follow an eula. Which just forbids a bounce of stupid things like posting speed tests without asking microsoft before. Isn`t really the idea of free software to support such things.
There are only 3 ways for microsoft to deal with a free in price version of mono running on other systems then windows.
1) them don`t care because to less people are using it (not the case)
2) accept it, be happy with it, not to sue it. That`s also not the case. If this would have been the case them could just put their netframework under an open source approved license and withdrawn their own patents on it. But them don`t even do so with the patents.
3) not accept it, sue it or try to get money out it
What way did them chose? It`s obvious.
At lawyer`s option the success of the mono project is questionable because of this license problems. Only novel has an pact with microsoft to use their technologies and not to sue their costumers, all other distributions don`t have.
Anyone who is really convinced about free software wouldn´t use anything from .net for free software projects.
You either care about free software and don`t use it, or you don`t care and use it. But dot net is currently definitely not compatible with free software.
-
Why use Windows Forms for multi platform amule if not even Windows Forms are nearly finished in mono project?
It's finished enough for given purpose (yes, I tested it). Anyway, you have no real alternative - calling GTK# cross-platform is ridiculous.
Qt is free in freedom. There is a gpl version you can use with all freedom given by gpl, you can even fork it, everything. Just if you want to keep your source closed you need to buy a commercial license. What`s not free about the gpl version?
Qt is dual licensed. If tomorrow I want to sell aMule in any way (GPL does not prevent making money), you have to buy license. Not exactly free. I say it just for argument sake, it's not the reason I turned Qt down.
The license of the ide doesn`t matter because anyone can build it even without ide or with alternative ide. But the license of buildtools does matter.
Complete nonsense. It does not. I can publish code in ANY language, whatever I have compiler or not. I can publish code in let's say Matlab despite the fact, that language is not a standard, and need completely proprietary very expensive tool to run.
Oh, just follow an eula. Which just forbids a bounce of stupid things like posting speed tests without asking Microsoft before. Isn't really the idea of free software to support such things.
You bring ideological discussion here? That's off topic. Really.
There are only 3 ways for microsoft to deal with a free in price version of mono running on other systems then windows.
<snip>
What way did them chose? It`s obvious.
Thank you, not interested.
At lawyer`s option <snip> . Only novel <snip>.
Are you lawyer?
Anyone who is really convinced about free software wouldn´t use anything from .net for free software projects.
Nobody force you. Let's leave alone one's beliefs for sake of technical discussion. I will choose my tools as I see fit, thanks.
You either care about free software and don`t use it, or you don`t care and use it.
I care. I use. Does it prohibit running some none-free software as well. Don't think so.
But dot net is currently definitely not compatible with free software.
Says who? You must be adding "IMHO" here.
As one can see, you clearly run out of technical arguments and shifted to very shaky one like "not care for free software". I choose Microsoft C# because it's better that alternatives.
-
You may sell programs which use Qt. You just need to publish the source code. No need to buy a commercial license. You just need a commercial license if you want to keep the source closed.
It`s also technically discussion. Disadvantages have already been discussed (Not portable as usb on windows, mono is still not ready with windows forms. The day paint.net will run on on mono it`s done but this will take some time.
But it`s also ideology. Sure, I could have add imho to every sentence.
Not only my opinion. If you want the option of someone important from the free software scene, then what about Richard Stallman. He also says we better don`t use it. Link (don`t worry, it`s english, if not click english on the top) (http://www.germany.fsfeurope.org/documents/rms-fs-2006-03-09.en.html#q1) [comparison: no one ever from fsf or gnu official said 'don`t use' or 'better don`t use' C++ or Qt]
-
Why this whole discussion? aMule is free software. If someone wants a feature, he can ask to get it implemented. If he gets a yes, all's fine. If he gets a no, he can discard the suggest, or implement it be himself. But trying to convince the devs shouldn't be an option.
-
Anyone else getting tired of this?
mulinex: Switching to QT is not as easy as saying "Hey, this Cutey thingy is cool, let's switch over!" even if everyone else is doing this.
QT is nice and a couple of other developers are not against using QT at all, too, but there's no one willing to do the work necessary to switch to QT.
Because it means rewriting the whole application.
You'ld have to fscking pay someone (not me) if you want to see this happening anytime soon. Unless you have a couple of thousand euros lying around waiting to be spend for a coder's rent and food, stop requesting insane things, OK?
-
The main linux mail applications like fetchmail, sendmail, postfix or exim?
Or do you mean MUAs like mutt or pine?
-
Or Evolution. Or thunderbird.
-
I do like to speak with the users, but I do not like when they don't read the forum first to see if they were answered before, or even the responses in this very same thread.
We don't want serverless chat, bittorrent, or a integrated mediaplayer, or F2F downloads. We, as the team, don't want it. That's it. Nothing else to discuss. aMule is a ed2k/Kad client to download and upload files. We don't want to bloat it. We don't want to change the toolkit. That's what it is, and that's what it will stay being, even if you don't like it.
You can have all the opinions in the world, but the development team (not me alone) make the decisions about what to include or not in the client. And you have to accept them.
QT is no better than wxWidgets, it is a pain in the ass to port, and it's not native. We won't change it. The end.
-
ok thanks, that makes it more clear. for the corporate decision users then can accept this.
and for all others, we appreciate to adress again to you.
cu later. but still think, what makes amule a difference to emule on windows...
-
It`s also technically discussion. Disadvantages have already been discussed (Not portable as usb on windows, mono is still not ready with windows forms. The day paint.net will run on on mono it`s done but this will take some time.
But it`s also ideology. Sure, I could have add imho to every sentence.
Not only my opinion. If you want the option of someone important from the free software scene, then what about Richard Stallman. He also says we better don`t use it. <> comparison: no one ever from fsf or gnu official said 'don`t use' or 'better don`t use' C++ or Qt
That's funny post.
Technical reasons you provide are null and void. (amule doesn't use USB and winforms are working good enough in mono). And I really don't interested in Stallman opinion. His ideas like "proprietary software is immoral" are ridiculous.
cu later. but still think, what makes amule a difference to emule on windows...
As you said: emule - on windows, amule - on linux. Good enough for me.
-
Would amule join the QT-development, if imule starts?
I seriously doubt it. We (I) would probably support a remote GUI using QT, but aMule itself is very unlikely to switch.
-
Ditto.
-
remote gui means a gui for the deamon?
-
Yes and no. It can be used with aMule and with the daemon and can be run both on the local computer and on a remote computer.
-
and this will be QT? so it is a universal gui. What are you telling me, then the old one might exist until the new one fits.. and everyone will use that.. so this is a clear yes to QT gui... and here the suggestion is to start with a simple gui quick and dirty to go then deeper to the details instead of waiting for the release with all schnickschnack.
is there an estimated due date? I mean, 4 frames and these could be taken from qbittorrent.sf.net
-
...
No.
You don't understand it. IT's a remote GUI. it's not the aMule gui. We ahve a remote GUI in wx, which is the same as the amule gui, we have a text-mode system, a webserver, soon a C# gui (I think already functional on cvs), also someone si working on a ncurses one.
Someone coding a QT remote gui for aMule doens't mean anything about the aMule development. Nothing. Zero. Nil. Our wx gui is a universal AND NATIVE GUI.
-
who is making the remote one?
-
...
Which one of them?
-
No one. There is NO QT remote gui and no, there are currently NO plans to develop such a remote GUI.
A quick lesson in English grammar: We would probably support a remote GUI using QT
would + infinitive is used to form the conditional I for actions which might take place. As in: They are not reality yet, but they might be real at one time in the future.
So, when you take a look at our example you'll see that author used the following construction: "we would support". Taking into consideration our last session in English grammar, we see that we've got a conditional I. And a conditional I means that the author was talking about an action which might take place.
I think I'm going back to simply saying "No", there are less blissfully ignorant misunderstandings to be involved...
-
Would amule join the QT-development, if imule starts?
amule can not "join" QT development (if you mean "develop QT itself) since we're not employees of Trolltech. What kind of question is that anyway.
I think that what you actually wanted to ask is "will amule move to QT if imule will"? And the answer is "WTF?". We don't share codebase or coders (AFAIK) with imule, so I can't see how is that relevant.
who is making the remote one?
I coded original version of wx-based one, and now working on c# based. As I explained earlier, I choose C# over QT due to numerous technical reasons.
You, for example may have another point of view, so please go ahead, and write your own in QT. This is Open Source, and we're accepting patches.
-
ahead is this: a start has been made
http://sourceforge.net/tracker/index.php?func=detail&atid=886242&aid=1814590&group_id=178712
I attach the file, rename it from .txt to .ui
any ideas how to go on?
-
ahead is this: a start has been made
http://sourceforge.net/tracker/index.php?func=detail&atid=886242&aid=1814590&group_id=178712
I attach the file, rename it from .txt to .ui
any ideas how to go on?
Rework it for a start:
* The way you organized controls in pages is completely counter-intuitive. aMule preferences page with categories in left column is match better. Even old-style paged notebook is better, because it shows all available categories simultaneously.
* Alignment of controls and frames is broken everywhere.
* What's that placeholder in "Shared files" page? You suggesting to create it in run-time?
* Port numbers can have 5 digits.
-
thanks that you want to rework for a start.
* the left side menue or the pull down way, is just a choice. I can put each QT page into one own QT Sheet, this is just copy and paste.
* Shared files dialog is here: http://retroshare.svn.sourceforge.net/viewvc/retroshare/rs-Qt-gui/src/gui/Preferences/
* so as you see, the pull down preferences are sized for the window, that it is a sub-frame of the preferences tab of retoshare.
(as I learned that Open Source is a question of choice, I choosed the pull down way, because the other one was to difficult. Maybe if you want it in the left menue style, we can copy and paste the now designed pages?.
* "alignement": Think all icons and frames are adjusted in the right way to each other?
* Port numbers, ok, is just a placeholder, that needs 5 digits, but that needs as well still the code for the functionality, maybe in this process we can change it to 5-digits layout-icons.
the rest of the gui is here: http://retroshare.svn.sourceforge.net/viewvc/retroshare/rs-Qt-gui/src/gui/
(Search tab or Transfer tab and Library Tab and network tab)
Statistics and Message tab are not needed now.
Please consider implementing Imule and Amule into this gui?
And: the general purpose of QT is to bring retroshare messenger under the gui.
QT has only this purpose, so don´t forget the core ;-), which is here:
http://retroshare.svn.sourceforge.net/viewvc/retroshare/rs-core/
-
Please consider implementing Imule and Amule into this gui?
Uhm...no?
the general purpose of QT is to bring retroshare messenger under the gui
As we told you already a couple of times, we have no intention to switch to QT nor using the retroshare messenger.
Seriously, what do we have to do in order to make you understand this? Do you have problems understanding the English language? - no problem, I can surely find someone to translate it in your native tongue.
But I'll give you yet another summary:
- aMule will use wxwidgets and there are NO plans to change this.
- We have NO plans to include i2p-mule, retroshare, Friend-to-Friend or anything else eMule doesn't have.
- aMule is an P2P-application - we have NO plans to include any messenger or chat modules.
- We would be happy about a QT-remote-GUI¹, but someone has to do it - not only the design, but the code as well.
¹ a remote gui is a graphical user interface to control aMule remotely using a network connection. It is possible to control both aMule and the daemon with such a GUI and you can use it on your local computer as well (i.e. not remotely) as over the internet or a local network. The protocol used by aMule for the communication is called "External Connections" short "EC".
-
thanks that you want to rework for a start.
Hilarious. I mean you have to rework it before making any use.
Please consider implementing Imule and Amule into this gui?
Can you please stop trolling? You've got your answer, it was "no", and it actually means "no".
aMule will use wxwidgets and there are NO plans to change this.
If you ask me, next major version of aMule is better move away from wx to QT. But that's topic for another discussion
We would be happy about a QT-remote-GUI
That's good only as coding exercise.
aMule is an P2P-application - we have NO plans to include any messenger or chat modules.
How about removing that damned "Chat" page, which is used solely for spam?
-
aMule will use wxwidgets and there are NO plans to change this.
If you ask me, next major version of aMule is better move away from wx to QT. But that's topic for another discussion
Totally agree.
aMule is an P2P-application - we have NO plans to include any messenger or chat modules.
How about removing that damned "Chat" page, which is used solely for spam?
Totally agree too.
-
cool.
(1) why should amule have not feature, that emule has not?
(2) Isn´t that here the thread for the QT gui of the next major Amule release?
(3) actually ?
(4) maybe messages could be replaced through an symmetric approved chat of friends?
-
I agree with everything (moving some day to QT, etc) but I disagree with removing the chat thingie. It has served me in the past for files that have only one source, I snd a message to that source, he sets file to release, file is well spread. I think the messages filter works OK for spam :)
Regards.
-
This is my personal opinion and does not reflect the opinion of the aMule developers.
First of all: Kry's argument that QT doesn't use native widgets is not true anymore. QT is really nice, too - but I wouldn't use it anyway.
I would love to have a minimalistic design¹ with a core/gui separation by default. (Similar to e.g. xmms2, i.e. you don't even notice that there's a separation unless you want to use the advantages of this system)
I could imagine using POCO (http://www.appinf.com/poco/info/) statically linked for the core and I personally would use FLTK2 or maybe a future version of Ultimate++ for the GUI, but cli, web, wx, QT, Juce, Fox, smartwin++,... or even "real" native GUIs are of course possible as well. (And could be built relatively fast on top of a GUI skeleton not deeply integrated with any toolkit.)
¹ Although I have neither time nor sufficient network/application design knowledge to actually realize it.
-
(1) why should amule have not feature, that emule has not?
Because I think chat in mule is stupid idea.
(2) Isn´t that here the thread for the QT gui of the next major Amule release?
Not so far.
(4) maybe messages could be replaced through an symmetric approved chat of friends?
That's called IM and there's dozens of better programs for that purpose.
-
@ leo: it is not about chat, but about f2f secure filestransfer.
-
First of all: Kry's argument that QT doesn't use native widgets is not true anymore. QT is really nice, too - but I wouldn't use it anyway.
You sound clueless. Every cross-platform toolkit ever created suffer from "not-really-native widgets" problem. I will ignore your "I wouldn't use it" due lack of technical argument.
I would love to have a minimalistic design¹ with a core/gui separation by default.
Same lack of technical argumentation. Minimalistic design of what? Of GUI? Of core? Of both ? What's "minimalistic" anyway?
I could imagine using POCO statically linked
Extremely wrong. Non-standard libraries are out of discussion. Static link is bad idea anyway.
I personally would use FLTK2 or maybe a future version of Ultimate++ for the GUI ... or even "real" native GUIs are of course possible as well.
Yet another bad idea. Let me explain it one more time: GUI toolkit without decent RAD tool is useless crap. By "decent" I mean something close to Microsoft Visual. QT Designer come close. GTK have some good ideas. But "Ultimate whatever" ? Something 3 people done over weekend? Please, let's not waste time on pointless discussion.
"Native" widgets are definitely out of question, unless we take route to separate core and GUI completely.
Although I have neither time nor sufficient network/application design knowledge
Sorry, but if you have no knowledge on the subject, why enter discussion?
-
@ leo: it is not about chat, but about f2f secure filestransfer.
I ask you once again: please stop trolling. "f2f whatever" is not going to enter amule in any form or kind. There's dedicated applications that do that.
-
devide et imule.
This thread is about the QT gui. When do we start, and wuischke, will you help us though to short time?
-
You sound clueless. Every cross-platform toolkit ever created suffer from "not-really-native widgets" problem.
You've surely followed the thread, haven't you? Kry mentioned various times that he critizes QT for not being native and prefers wx because it uses a native look (i.e. GTK2 on *nix, Cacoa/Carbon on Mac and MFC (or however it's called nowadays) on Windows.)
QT used to emulate the look of the platforms instead of using the native toolkit. Whilst it will still use its own look on *nix (QT is after all an established toolkit on *nix, besides GTK2), it uses a native look on Windows and Mac in recent versions.
I will ignore your "I wouldn't use it" due lack of technical argument.
There is no argument, only my personal opinion after using it for a little while. It just doesn't fit my personal preference. That's why I wrote in the first sentence that I only state my personal opinion, because I know that all of you think different. I wouldn't use C# or Java either - just because I don't like them, not because they are bad.
What's "minimalistic" anyway?
Hideously complex and hard to design.
To explain it very shortly: The application is divided into little parts, each one doing only one little job (here's the minimalistic) and giving/receiving tasks from/to others. Add the latest buzzwords like "pluggable" and "multithreaded" and you get a "minimalistic" design similar to a microkernel, which is complex to design, but once (well) designed very maintainable.
NOTE: This will never be done and I couldn't design it (yet). It is OT anyway, so you don't have to tell me how stupid the idea is. ;) (Note: A smiley indicates that I'm not entirely serious.)
Extremely wrong. Non-standard libraries are out of discussion. Static link is bad idea anyway.
Correction: In your opinion this is extremely wrong.
In my opinion this is a nice way of getting all necessary cross-platform operations of the gui (file access and network) with only a small overhead in terms of binary size and without having to load (and install) megabytes of libraries where you only use a small part of it. I like the design of POCO, so it's a personal preference thingy again.
Yet another bad idea.
Nope, personal preference. "i" and "personally" indicate this pretty clearly. ;) I'm well aware that aMule won't use it and I know your reasons to use C# as well - and I can comprehend them.
Sorry, but if you have no knowledge on the subject, why enter discussion?
I obviously love to hear myself talk. Although the only thing I actually hear is my keyboard. ;)
Seriously: I said "not sufficient", not "no knowledge". ;) I'm well aware of my limitations and I use the opportunity to learn.
mulinex:
This thread is about the QT gui. When do we start, and wuischke, will you help us though to short time?
I will try to help you, but be aware that I have little free time since university started and that I'm not "fluent" in QT and the design of aMule and EC.
-
QT used to emulate the look of the platforms instead of using the native toolkit. Whilst it will still use its own look on *nix (QT is after all an established toolkit on *nix, besides GTK2), it uses a native look on Windows and Mac in recent versions.
Actually, it doesn't matter as long as it's consistent behavior.
Extremely wrong. Non-standard libraries are out of discussion. Static link is bad idea anyway.
Correction: In your opinion this is extremely wrong.
In my opinion this is a nice way of getting all necessary cross-platform operations of the gui (file access and network) with only a small overhead in terms of binary size and without having to load (and install) megabytes of libraries where you only use a small part of it. I like the design of POCO, so it's a personal preference thingy again.
Let's make some definitions here. When I say "it's better", it means "I checked the subject, have an opinion and actual technical argument to back it up", and not "it have nice name and website".
So, due to your lack of knowledge and experience, you can't make argument in terms of "personal preferences". Your personal preference is simply irrelevant as long as you can't back it up in technical terms. I, on a contrary do have knowledge and experience.
Yet another bad idea.
Nope, personal preference. "i" and "personally" indicate this pretty clearly. ;)
Seriously: I said "not sufficient", not "no knowledge".
Same argument here. You just can't grasp an idea that Fltk is simply not suitable for given purpose.
I'd like to summarize discussion so far:
* It would be nice to move to Qt
* This, however, is huge task, not just find-replace operation
-
You are of course right - I'm more of an dreamer in this regard, because I don't have to (not yet) make things actually work in reality and you know that you have to make the work in reality.
This doesn't hinder me from trying (provided I have the time) - and most probably failing miserably.
I'd like to summarize discussion so far:
* It would be nice to move to Qt
* This, however, is huge task, not just find-replace operation
I'm not opposed to such a switch (after 2.2.0 of course) and if Kry should change his opinion then I guess I'll follow your advice:
We would be happy about a QT-remote-GUI
That's good only as coding exercise.
-
I don't know much about toolkits, but I definitely noticed when wxWidgets decided to disable sideway (x-axis) scrolling in 2.8.5. WTF is up with that? As aMule often has a lot of information to display, it was really nice to be able to scroll sideways, but I can't do that any longer. It's a very strange decision, as practically all Macs sold in the last two years actually support sideway scrolling out of the box. Either through the trackpad, or the mighty mouse.
Switching to a toolkit which doesn't restrict features would be a good idea.
-
Why is it again that we would be willing to drop support for a LOT of platforms, especially BSD, and reqork everything with a new framework, which so far I haven't seen an advantage about it, and has a lot of new problems for us?
-
Why is it again that we would be willing to drop support for a LOT of platforms, especially BSD, and reqork everything with a new framework, which so far I haven't seen an advantage about it, and has a lot of new problems for us?
Why spread FUD? Qt does support BSD. http://trolltech.com/developer/notes/changes/changes-3.3.4/ (http://trolltech.com/developer/notes/changes/changes-3.3.4/) Which means, that ALL major platforms are supported (Linux, Win, OSX, BSD).
Qt as gui toolkit is times better that WX. You actually have a chance to rework GUI in minimal effort. And GUI should be reworked in many places. Don't you see an advantage? I do.
and has a lot of new problems for us
At least you don't have to instruct users to rebuild/reinstall WX because of random crashes.
-
wxgtk cannot handle special (unicode) characters, even with unicode compile. That's really bad.
and wxwidgets 2.8.5 was buggy too.
http://forum.amule.org/index.php?topic=13212
-
wxGTK CAN handle unicode perfectly, so don't spread FUD either.
-
Why is it again that we would be willing to drop support for a LOT of platforms, especially BSD, and reqork everything with a new framework, which so far I haven't seen an advantage about it, and has a lot of new problems for us?
Why spread FUD? Qt does support BSD. http://trolltech.com/developer/notes/changes/changes-3.3.4/ (http://trolltech.com/developer/notes/changes/changes-3.3.4/) Which means, that ALL major platforms are supported (Linux, Win, OSX, BSD).
Qt as gui toolkit is times better that WX. You actually have a chance to rework GUI in minimal effort. And GUI should be reworked in many places. Don't you see an advantage? I do.
and has a lot of new problems for us
At least you don't have to instruct users to rebuild/reinstall WX because of random crashes.
As for the "FUD" I'm just quoting QT's website, which says Windows, Mac, Linux and embedded systems. No more, no less.
As for the "crashes", I don't see how it can be wx at fault that the packagers don't update or patch their versions.
-
As for the "FUD" I'm just quoting QT's website, which says Windows, Mac, Linux and embedded systems. No more, no less.
Pleeeeeese. Let me quote: from http://trolltech.com/products/qt/features (http://trolltech.com/products/qt/features):
Qt is available for the following platforms:
* Qt/Windows (Microsoft Windows Vista™, Server 2003, XP, 2000, NT 4, Me/98)
* Qt/Mac (Mac® OS X, 10.3 and 10.4)
* Qt/X11 (Linux®, Solaris®, HP-UX, IRIX, AIX, many other Unix variants)
* Qtopia Core - Learn more about the embedded Linux port of Qt.
As for the "crashes", I don't see how it can be wx at fault that the packagers don't update or patch their versions.
Why do you put "crashes" in quotation marks is beyond my comprehension. Wx really crashes. On left and right. In released versions. And this is versions that packages use. You can't expect them to compile CVS snapshots.
-
So QT never crashes?
-
So QT never crashes?
Apparently every software crashes. However, according to my limited personal experience, Qt have order of magnitude less problems, compared to WX.
-
I see. Don't have much experience with it, but then again, didn't have that many crashes with wx either, save the url update one.
I do however doubt we could just switch a framework like that without TONS of work and free time, so I doubt it would be feasible at all.
-
to estimate time and how much work it could be, i suggest a roadmap plan.
a basic version would be the best start.
So which maintabs has amule? and which are needed for QT? and which functions should be ported to QT ?
There are different approaches to work, from abstract to fine or from fine to the next part as well done fine.
I prefer the quick and dirty implementation, so from main Frames to the details,
We need only these frames:
Network (1) / Search (2) / Transfer (3) / Filelist-Library (4) / Settings (5).
This means to drop in the first QT version of amule: Partial-Import, Messages, Statistics.
A swell in the 5 mentioned tabs we can drop several adjustments.
The gui design of preferencers was posted:
http://sourceforge.net/tracker/index.php?func=detail&aid=1814590&group_id=178712&atid=886242
( the suggestion was to make it left menue-tabbed, so copy paste the layout)
Network Imho does not need server settings, just one button to connect to one random server or not,
All other gui desings can be taken from here:
http://retroshare.svn.sourceforge.net/viewvc/retroshare/rs-Qt-gui/src/
the c++code has to be added and linked, of course, the wxwidgets from core have to be removed.
All other adjustments, which are not in the new QT gui, then can be left as is ?! as they have all a default setting.
If a core wxwidget is lef in the code, a compilation with qt gui should not be harmed?
@wuische: which tab is yours ?
I suggest each one is taking a tab from 1-5.
Any volunteering?
-
I'm sorry but I would suggest you don't talk what you don't know about. You're jsut embarassing yourself in front of the people that actually know what this work entails.
-
Also, you might notice you're not an aMule developer if you look at the list.
-
I do however doubt we could just switch a framework like that without TONS of work and free time, so I doubt it would be feasible at all.
Definitely true. That's why I'm not talking in terms of "let's do it now".
-
@wuische: which tab is yours ?
Yesterday: The bar tab.
Fortunately we had cheap (but good) czech beer.
Unfortunately I've already forgotten all the Czech I've learned yesterday.
Regarding your actual question: DON'T EVEN THINK ABOUT ASKING AGAIN BEFORE THE RELEASE OF AMULE 2.2.0. (Sorry for shouting, but it seems like you didn't understand me the numerous times I tried to answer politely.)
-
to estimate time and how much work it could be, i suggest a roadmap plan.
Should I quit my day job to keep up with suggested roadmap?
-
I think we all should, for the good of the Empire!
-
(1) first, the discussion has rised to left the "no" for a QT-gui
(2) it is not about speed, not about beer, yes, not about coding, and not about "duck and cover".
http://www.youtube.com/watch?v=C0K_LZDXp0I
(3) because we do not want to quit day jobs, we (for kry: you) should coordinate the steps, that should be normal.
as wuischke needs one day+ after the bar, we wait until he has a focus of half and not double of the fun.
(4) leon, there is no roadmap plan, but if there is sparetime, can you make one with the steps?
-
Someone's not getting the hints.
-
you mean leon not to do it? but what, if wuischke makes a frame as well (after 2.2.0. of course)?
-
mulinex: I'll close this topic now and I don't want you to mention QT4 again until it has been reopened by a developer.
I appreciate your help on this subject and I'll personally get in touch with you once we start any development regarding QT4, OK?