From: Juan De V. <jua...@gm...> - 2009-01-28 08:45:20
|
Hi, Just a brief intro of myself: I'm a ktechlab enthusiast that, since I'm just learning to program, I've been only quietly following the developments of the project, but, since my failed attempt to compile under KDE 4 a couple of weeks ago (maybe someone remembers the e-mail I sent? =P) and also the growing interest that many people in showing in the project, I thought that migrating the code to Qt 4 is something that should be done. I saw several e-mails with people talking about doing something like this, so I'm really curious to know if this is actually on the process of happening. The reason for my interest is that I've been thinking that maybe it would be a good learning exercise for me to work/help on this. I'm aware that a great amount of work would be involved, mostly if you think of the fact that I'm just diving into the Qt world, but I'll learn most by doing than just reading books (I'm currently with Foundations of Qt Development, and as soon as I'm done with that one I'll go to The Book of Qt 4 by Daniel Molkentin). Could anyone give me some pointers in regards to where to start? Maybe I could get some small tasks to carry out? Or should I just pick up a .cpp file and start to try to figure out what changes would be necessary? I mean, I already printed the Porting to Qt 4 guide from the Trolltech docs. ;) For example a question that comes to my mind now is: would you use the qt3toqt4 porting tool or rather rewrite the code around Qt 4? In the meantime, like Alan Grimes suggested back on December, I'm taking a look at the small stuff in the current code and trying to get use to it. Thanks in advance! |
From: Chitlesh G. <chi...@wa...> - 2009-01-28 20:07:03
|
On Wed, Jan 28, 2009 at 9:45 AM, Juan De Vincenzo wrote: > > For example a question that comes to my mind now is: would you use the > qt3toqt4 porting tool or rather rewrite the code around Qt 4? > Hello, I would say, does it take a lot of time to port it with qt3qt4 ? If it is about 4hrs of work, maybe you can give it a try and upload it somewhere for testing. I have here for testing. Kind regards, Chitlesh |
From: Juan De V. <jua...@gm...> - 2009-01-29 03:50:00
|
Thanks for your feedback. I've been taking a look at the porting tool and what I understand, based on what I've been reading[1], is that in order to do it all at once the whole project should count with a qt project file (*.pro). AFAIK Ktechlab doesn't use that, so I guess it is a file by file job that needs to be done. I'll keep researching the way to pull this off and send an update as soon as I have something. I guess the first thing I'll try is porting one or two files, maybe one small and another large (ktechlab.cpp) and learn how the process works. I'll also see if maybe a bash script can help automate the process for the whole source code. =) There's also the fact that .ui files also have to be ported to Qt4. Regards, Juan [1]http://doc.trolltech.com/4.0/qt3to4.html#qt3to4 On Wed, Jan 28, 2009 at 6:06 PM, Chitlesh GOORAH <chi...@wa...> wrote: > On Wed, Jan 28, 2009 at 9:45 AM, Juan De Vincenzo wrote: >> >> For example a question that comes to my mind now is: would you use the >> qt3toqt4 porting tool or rather rewrite the code around Qt 4? >> > > Hello, > I would say, does it take a lot of time to port it with qt3qt4 ? > If it is about 4hrs of work, maybe you can give it a try and upload it > somewhere for testing. > > I have here for testing. > > Kind regards, > Chitlesh > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Ktechlab-devel mailing list > Kte...@li... > https://lists.sourceforge.net/lists/listinfo/ktechlab-devel > |
From: Juan De V. <jua...@gm...> - 2009-02-03 19:25:57
|
I'm sending the e/mail one more time without the attachment, since it is too big, please don't hesitate to let me know if you want to receive the file. Regards, Juan On Wed, Jan 28, 2009 at 6:45 AM, Juan De Vincenzo <jua...@gm...> wrote: > Hi, > > Just a brief intro of myself: I'm a ktechlab enthusiast that, since > I'm just learning to program, I've been only quietly following the > developments of the project, but, since my failed attempt to compile > under KDE 4 a couple of weeks ago (maybe someone remembers the e-mail > I sent? =P) and also the growing interest that many people in showing > in the project, I thought that migrating the code to Qt 4 is something > that should be done. > > I saw several e-mails with people talking about doing something like > this, so I'm really curious to know if this is actually on the process > of happening. The reason for my interest is that I've been thinking > that maybe it would be a good learning exercise for me to work/help on > this. I'm aware that a great amount of work would be involved, mostly > if you think of the fact that I'm just diving into the Qt world, but > I'll learn most by doing than just reading books (I'm currently with > Foundations of Qt Development, and as soon as I'm done with that one > I'll go to The Book of Qt 4 by Daniel Molkentin). > > Could anyone give me some pointers in regards to where to start? Maybe > I could get some small tasks to carry out? Or should I just pick up a > .cpp file and start to try to figure out what changes would be > necessary? I mean, I already printed the Porting to Qt 4 guide from > the Trolltech docs. ;) > > For example a question that comes to my mind now is: would you use the > qt3toqt4 porting tool or rather rewrite the code around Qt 4? > > In the meantime, like Alan Grimes suggested back on December, I'm > taking a look at the small stuff in the current code and trying to get > use to it. > > Thanks in advance! > |
From: Richard R. <ron...@gm...> - 2009-02-03 20:09:38
|
Hi, Well, while we're talking about Qt 4, I would also be glad to help. I'm quite familiar with Qt 4 (especially with Java but I shouldn't have any trouble going from Java to C++). I just recently suscribed to the mailing list in order to see if there was any work in this direction thanks to this blog post: http://clunixchit.blogspot.com/2009/01/help-ktechlab-if-you-can.html Regards, Richard On Tue, Feb 3, 2009 at 7:25 PM, Juan De Vincenzo <jua...@gm...> wrote: > I'm sending the e/mail one more time without the attachment, since it > is too big, please don't hesitate to let me know if you want to > receive the file. > > Regards, > Juan > > On Wed, Jan 28, 2009 at 6:45 AM, Juan De Vincenzo > <jua...@gm...> wrote: >> Hi, >> >> Just a brief intro of myself: I'm a ktechlab enthusiast that, since >> I'm just learning to program, I've been only quietly following the >> developments of the project, but, since my failed attempt to compile >> under KDE 4 a couple of weeks ago (maybe someone remembers the e-mail >> I sent? =P) and also the growing interest that many people in showing >> in the project, I thought that migrating the code to Qt 4 is something >> that should be done. >> >> I saw several e-mails with people talking about doing something like >> this, so I'm really curious to know if this is actually on the process >> of happening. The reason for my interest is that I've been thinking >> that maybe it would be a good learning exercise for me to work/help on >> this. I'm aware that a great amount of work would be involved, mostly >> if you think of the fact that I'm just diving into the Qt world, but >> I'll learn most by doing than just reading books (I'm currently with >> Foundations of Qt Development, and as soon as I'm done with that one >> I'll go to The Book of Qt 4 by Daniel Molkentin). >> >> Could anyone give me some pointers in regards to where to start? Maybe >> I could get some small tasks to carry out? Or should I just pick up a >> .cpp file and start to try to figure out what changes would be >> necessary? I mean, I already printed the Porting to Qt 4 guide from >> the Trolltech docs. ;) >> >> For example a question that comes to my mind now is: would you use the >> qt3toqt4 porting tool or rather rewrite the code around Qt 4? >> >> In the meantime, like Alan Grimes suggested back on December, I'm >> taking a look at the small stuff in the current code and trying to get >> use to it. >> >> Thanks in advance! >> > > ------------------------------------------------------------------------------ > Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) > software. With Adobe AIR, Ajax developers can use existing skills and code to > build responsive, highly engaging applications that combine the power of local > resources and data with the reach of the web. Download the Adobe AIR SDK and > Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com > _______________________________________________ > Ktechlab-devel mailing list > Kte...@li... > https://lists.sourceforge.net/lists/listinfo/ktechlab-devel > |
From: Juan De V. <jua...@gm...> - 2009-02-04 15:07:36
|
Hello everyone, I have uploaded the partially ported code here: http://www.gigasize.com/get.php?d=mosmvyvm9pb Inside of each directory you'll find a portinglog.txt, that's the log that qt3to4 automatically generates when executed. Also, this is what's done at the moment: - Using the am2cmake script included in KDE 4, the project has been migrated from the old build system to cmake. - Using the qt3to4 tool the code has been migrated to Qt 4, but with the functions from the Qt 3 Support library, the best would be to go through the code for it to be fully Qt 4. -Using Qt Designer, all the .ui files have been turned to Qt4 format. Regards, Juan On Tue, Feb 3, 2009 at 6:09 PM, Richard Rondu <ron...@gm...> wrote: > Hi, > > Well, while we're talking about Qt 4, I would also be glad to help. > I'm quite familiar with Qt 4 (especially with Java but I shouldn't > have any trouble going from Java to C++). > > I just recently suscribed to the mailing list in order to see if there > was any work in this direction thanks to this blog post: > > http://clunixchit.blogspot.com/2009/01/help-ktechlab-if-you-can.html > > Regards, > Richard > > > > On Tue, Feb 3, 2009 at 7:25 PM, Juan De Vincenzo > <jua...@gm...> wrote: >> I'm sending the e/mail one more time without the attachment, since it >> is too big, please don't hesitate to let me know if you want to >> receive the file. >> >> Regards, >> Juan >> >> On Wed, Jan 28, 2009 at 6:45 AM, Juan De Vincenzo >> <jua...@gm...> wrote: >>> Hi, >>> >>> Just a brief intro of myself: I'm a ktechlab enthusiast that, since >>> I'm just learning to program, I've been only quietly following the >>> developments of the project, but, since my failed attempt to compile >>> under KDE 4 a couple of weeks ago (maybe someone remembers the e-mail >>> I sent? =P) and also the growing interest that many people in showing >>> in the project, I thought that migrating the code to Qt 4 is something >>> that should be done. >>> >>> I saw several e-mails with people talking about doing something like >>> this, so I'm really curious to know if this is actually on the process >>> of happening. The reason for my interest is that I've been thinking >>> that maybe it would be a good learning exercise for me to work/help on >>> this. I'm aware that a great amount of work would be involved, mostly >>> if you think of the fact that I'm just diving into the Qt world, but >>> I'll learn most by doing than just reading books (I'm currently with >>> Foundations of Qt Development, and as soon as I'm done with that one >>> I'll go to The Book of Qt 4 by Daniel Molkentin). >>> >>> Could anyone give me some pointers in regards to where to start? Maybe >>> I could get some small tasks to carry out? Or should I just pick up a >>> .cpp file and start to try to figure out what changes would be >>> necessary? I mean, I already printed the Porting to Qt 4 guide from >>> the Trolltech docs. ;) >>> >>> For example a question that comes to my mind now is: would you use the >>> qt3toqt4 porting tool or rather rewrite the code around Qt 4? >>> >>> In the meantime, like Alan Grimes suggested back on December, I'm >>> taking a look at the small stuff in the current code and trying to get >>> use to it. >>> >>> Thanks in advance! >>> >> >> ------------------------------------------------------------------------------ >> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) >> software. With Adobe AIR, Ajax developers can use existing skills and code to >> build responsive, highly engaging applications that combine the power of local >> resources and data with the reach of the web. Download the Adobe AIR SDK and >> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com >> _______________________________________________ >> Ktechlab-devel mailing list >> Kte...@li... >> https://lists.sourceforge.net/lists/listinfo/ktechlab-devel >> > > ------------------------------------------------------------------------------ > Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) > software. With Adobe AIR, Ajax developers can use existing skills and code to > build responsive, highly engaging applications that combine the power of local > resources and data with the reach of the web. Download the Adobe AIR SDK and > Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com > _______________________________________________ > Ktechlab-devel mailing list > Kte...@li... > https://lists.sourceforge.net/lists/listinfo/ktechlab-devel > |
From: P Z. <zol...@gm...> - 2009-02-04 22:11:01
|
On Tue, 03 Feb 2009 21:09:33 +0100, Richard Rondu <ron...@gm...> wrote: > Hi, > > Well, while we're talking about Qt 4, I would also be glad to help. > I'm quite familiar with Qt 4 (especially with Java but I shouldn't > have any trouble going from Java to C++). > You should consult with Julian Bäume, he has done some work on the qt4 port. > I just recently suscribed to the mailing list in order to see if there > was any work in this direction thanks to this blog post: > > http://clunixchit.blogspot.com/2009/01/help-ktechlab-if-you-can.html > > Regards, > Richard > > > |
From: Richard R. <ron...@gm...> - 2009-02-05 00:39:02
|
Are we gonna have a svn repository for updating the changes to qt4 or we're just gonna send patches/updated files around? It would be great if we could have one. On Wed, Feb 4, 2009 at 11:15 PM, P Zoltan <zol...@gm...> wrote: > On Tue, 03 Feb 2009 21:09:33 +0100, Richard Rondu > <ron...@gm...> wrote: > >> Hi, >> >> Well, while we're talking about Qt 4, I would also be glad to help. >> I'm quite familiar with Qt 4 (especially with Java but I shouldn't >> have any trouble going from Java to C++). >> > > You should consult with Julian Bäume, he has done some work on the qt4 > port. > > >> I just recently suscribed to the mailing list in order to see if there >> was any work in this direction thanks to this blog post: >> >> http://clunixchit.blogspot.com/2009/01/help-ktechlab-if-you-can.html >> >> Regards, >> Richard >> >> >> > > ------------------------------------------------------------------------------ > Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) > software. With Adobe AIR, Ajax developers can use existing skills and code to > build responsive, highly engaging applications that combine the power of local > resources and data with the reach of the web. Download the Adobe AIR SDK and > Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com > _______________________________________________ > Ktechlab-devel mailing list > Kte...@li... > https://lists.sourceforge.net/lists/listinfo/ktechlab-devel > |
From: Juan De V. <jua...@gm...> - 2009-02-05 03:46:26
|
As far as I know there's an svn repository, but that's where the currently development version is hosted. It is my understanding that you can have several branches in the same repository, but I'm not familiar with that. I will research about it, but maybe it would be faster if someone already familiar with the one being used either explains the procedure to me or just uploads the source code. This is assuming that the code I provided you actually is of any good. Julian, You've been already working on the migration to Qt4? Since you seem to have more experience and knowledge, just let me know what you think and how can I help. IMHO, I really consider that moving Ktechlab to Qt 4 should be a priority, so the work can be focused on QT 4.x code instead of working with the old version of the libraries, which will be deprecated in some time. Regards, Juan On Wed, Feb 4, 2009 at 10:38 PM, Richard Rondu <ron...@gm...> wrote: > Are we gonna have a svn repository for updating the changes to qt4 or > we're just gonna send patches/updated files around? > It would be great if we could have one. > > On Wed, Feb 4, 2009 at 11:15 PM, P Zoltan <zol...@gm...> wrote: >> On Tue, 03 Feb 2009 21:09:33 +0100, Richard Rondu >> <ron...@gm...> wrote: >> >>> Hi, >>> >>> Well, while we're talking about Qt 4, I would also be glad to help. >>> I'm quite familiar with Qt 4 (especially with Java but I shouldn't >>> have any trouble going from Java to C++). >>> >> >> You should consult with Julian Bäume, he has done some work on the qt4 >> port. >> >> >>> I just recently suscribed to the mailing list in order to see if there >>> was any work in this direction thanks to this blog post: >>> >>> http://clunixchit.blogspot.com/2009/01/help-ktechlab-if-you-can.html >>> >>> Regards, >>> Richard >>> >>> >>> >> >> ------------------------------------------------------------------------------ >> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) >> software. With Adobe AIR, Ajax developers can use existing skills and code to >> build responsive, highly engaging applications that combine the power of local >> resources and data with the reach of the web. Download the Adobe AIR SDK and >> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com >> _______________________________________________ >> Ktechlab-devel mailing list >> Kte...@li... >> https://lists.sourceforge.net/lists/listinfo/ktechlab-devel >> > > ------------------------------------------------------------------------------ > Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) > software. With Adobe AIR, Ajax developers can use existing skills and code to > build responsive, highly engaging applications that combine the power of local > resources and data with the reach of the web. Download the Adobe AIR SDK and > Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com > _______________________________________________ > Ktechlab-devel mailing list > Kte...@li... > https://lists.sourceforge.net/lists/listinfo/ktechlab-devel > |
From: Juan De V. <jua...@gm...> - 2009-02-03 19:23:58
Attachments:
ktechlab_migration_short
|
Hi there, Well, after a lot of reading I finally found the time to sit in front of the machine and I was able to complete part of the porting. Overall the process took around one hour and a half. Attached you have a small log file I've created during the process to document what I was doing. Hope it is clear enough, even though you should keep in mind that it was done on the fly. I'll try to give it some format when I have the time. The thing is that now the remaining task (among others) is one with which I require some assistance because it involves modifying the code, which I'm still not ready to do. This is migrating the code from DCOP to DBUS, and of course there will be some more things to fine tune, but those can be handled at its time. Anyone could help with that? Also, please let me know if you think that there's anything missing or that I didn't do properly. By the way, I have the ported code here on my machine, would you like to take a look at it? How can I pass it over to you? Maybe I can upload it somewhere? By the way, this was my main guide for carrying this out: http://techbase.kde.org/Development/Tutorials/KDE4_Porting_Guide I'm really keen for your feedback. =) Regards, Juan On Thu, Jan 29, 2009 at 1:49 AM, Juan De Vincenzo <jua...@gm...> wrote: > Thanks for your feedback. > > I've been taking a look at the porting tool and what I understand, > based on what I've been reading[1], is that in order to do it all at > once the whole project should count with a qt project file (*.pro). > AFAIK Ktechlab doesn't use that, so I guess it is a file by file job > that needs to be done. > > I'll keep researching the way to pull this off and send an update as > soon as I have something. I guess the first thing I'll try is porting > one or two files, maybe one small and another large (ktechlab.cpp) and > learn how the process works. > > I'll also see if maybe a bash script can help automate the process for > the whole source code. =) > > There's also the fact that .ui files also have to be ported to Qt4. > > Regards, > Juan > > [1]http://doc.trolltech.com/4.0/qt3to4.html#qt3to4 > > On Wed, Jan 28, 2009 at 6:06 PM, Chitlesh GOORAH <chi...@wa...> wrote: >> On Wed, Jan 28, 2009 at 9:45 AM, Juan De Vincenzo wrote: >>> >>> For example a question that comes to my mind now is: would you use the >>> qt3toqt4 porting tool or rather rewrite the code around Qt 4? >>> >> >> Hello, >> I would say, does it take a lot of time to port it with qt3qt4 ? >> If it is about 4hrs of work, maybe you can give it a try and upload it >> somewhere for testing. >> >> I have here for testing. >> >> Kind regards, >> Chitlesh >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by: >> SourcForge Community >> SourceForge wants to tell your story. >> http://p.sf.net/sfu/sf-spreadtheword >> _______________________________________________ >> Ktechlab-devel mailing list >> Kte...@li... >> https://lists.sourceforge.net/lists/listinfo/ktechlab-devel >> > |
From: Richard R. <ron...@gm...> - 2009-02-08 20:23:15
|
did you took a look at those mailing lists threads? http://sourceforge.net/mailarchive/forum.php?thread_name=200...@sv...&forum_name=ktechlab-devel http://sourceforge.net/mailarchive/forum.php?thread_name=498...@sp...&forum_name=ktechlab-devel Might be useful for not going the wrong way. Cheers, Richard On Tue, Feb 3, 2009 at 7:23 PM, Juan De Vincenzo <jua...@gm...> wrote: > Hi there, > > Well, after a lot of reading I finally found the time to sit in front > of the machine and I was able to complete part of the porting. Overall > the process took around one hour and a half. > > Attached you have a small log file I've created during the process to > document what I was doing. Hope it is clear enough, even though you > should keep in mind that it was done on the fly. I'll try to give it > some format when I have the time. > > The thing is that now the remaining task (among others) is one with > which I require some assistance because it involves modifying the > code, which I'm still not ready to do. This is migrating the code from > DCOP to DBUS, and of course there will be some more things to fine > tune, but those can be handled at its time. Anyone could help with > that? > > Also, please let me know if you think that there's anything missing or > that I didn't do properly. By the way, I have the ported code here on > my machine, would you like to take a look at it? How can I pass it > over to you? Maybe I can upload it somewhere? > > By the way, this was my main guide for carrying this out: > http://techbase.kde.org/Development/Tutorials/KDE4_Porting_Guide > > I'm really keen for your feedback. =) > > Regards, > Juan > > On Thu, Jan 29, 2009 at 1:49 AM, Juan De Vincenzo > <jua...@gm...> wrote: >> Thanks for your feedback. >> >> I've been taking a look at the porting tool and what I understand, >> based on what I've been reading[1], is that in order to do it all at >> once the whole project should count with a qt project file (*.pro). >> AFAIK Ktechlab doesn't use that, so I guess it is a file by file job >> that needs to be done. >> >> I'll keep researching the way to pull this off and send an update as >> soon as I have something. I guess the first thing I'll try is porting >> one or two files, maybe one small and another large (ktechlab.cpp) and >> learn how the process works. >> >> I'll also see if maybe a bash script can help automate the process for >> the whole source code. =) >> >> There's also the fact that .ui files also have to be ported to Qt4. >> >> Regards, >> Juan >> >> [1]http://doc.trolltech.com/4.0/qt3to4.html#qt3to4 >> >> On Wed, Jan 28, 2009 at 6:06 PM, Chitlesh GOORAH <chi...@wa...> wrote: >>> On Wed, Jan 28, 2009 at 9:45 AM, Juan De Vincenzo wrote: >>>> >>>> For example a question that comes to my mind now is: would you use the >>>> qt3toqt4 porting tool or rather rewrite the code around Qt 4? >>>> >>> >>> Hello, >>> I would say, does it take a lot of time to port it with qt3qt4 ? >>> If it is about 4hrs of work, maybe you can give it a try and upload it >>> somewhere for testing. >>> >>> I have here for testing. >>> >>> Kind regards, >>> Chitlesh >>> >>> ------------------------------------------------------------------------------ >>> This SF.net email is sponsored by: >>> SourcForge Community >>> SourceForge wants to tell your story. >>> http://p.sf.net/sfu/sf-spreadtheword >>> _______________________________________________ >>> Ktechlab-devel mailing list >>> Kte...@li... >>> https://lists.sourceforge.net/lists/listinfo/ktechlab-devel >>> >> > > ------------------------------------------------------------------------------ > Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) > software. With Adobe AIR, Ajax developers can use existing skills and code to > build responsive, highly engaging applications that combine the power of local > resources and data with the reach of the web. Download the Adobe AIR SDK and > Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com > _______________________________________________ > Ktechlab-devel mailing list > Kte...@li... > https://lists.sourceforge.net/lists/listinfo/ktechlab-devel > > |
From: Julian B. <ju...@sv...> - 2009-02-08 21:13:12
|
On Tuesday 03 February 2009 20:23:51 Juan De Vincenzo wrote: > Hi there, > > Well, after a lot of reading I finally found the time to sit in front > of the machine and I was able to complete part of the porting. Overall > the process took around one hour and a half. The build-system (you started porting the old one to cmake) KTechLab uses at the moment is not the way we should go in the future. I worked on that and I think I found a nice way to manage it. I removed static linkage to reduce binary sizes. This makes it possible to integrate new features as plugins. The situation now is like this: Every new features results in a recompilation and re-linking of at least the belonging part and the ktechlab-binary. This takes time, eats memory and results in larger binaries for each new feature. There are also some design (or as Zoltan called it: some sort of "anti- design") decisions that need to be fixed. > Attached you have a small log file I've created during the process to > document what I was doing. Hope it is clear enough, even though you > should keep in mind that it was done on the fly. I'll try to give it > some format when I have the time. > > The thing is that now the remaining task (among others) is one with > which I require some assistance because it involves modifying the > code, which I'm still not ready to do. This is migrating the code from > DCOP to DBUS, and of course there will be some more things to fine > tune, but those can be handled at its time. Anyone could help with > that? Since there will be some redesign, there is no need to create a DBUS interface, now. Another thing I really don't want to have in the KDE4 port is the old visualization system. It uses the old QCanvas architecture from Qt3 and is really a mess. Porting a mess to QGraphicsView really isn't worth the effort, since you need to touch the code not only in terms of making it compile. > Also, please let me know if you think that there's anything missing or > that I didn't do properly. By the way, I have the ported code here on > my machine, would you like to take a look at it? How can I pass it > over to you? Maybe I can upload it somewhere? Are you familar in using git? I'll see to have something running tomorrow. It's not this hard. > By the way, this was my main guide for carrying this out: > http://techbase.kde.org/Development/Tutorials/KDE4_Porting_Guide That's a nice one, IMHO it doesn't fit for KTechLab as it is in the moment... > I'm really keen for your feedback. =) > > Regards, > Juan bye julian |
From: Alan G. <ag...@sp...> - 2009-02-08 20:41:35
|
Juan De Vincenzo wrote: [...] > I'm really keen for your feedback. =) Yes, I'm in favor of a more direct port of Ktechlab to 4.x. The idea of integrating it with kdevelop to a greater extent is interesting and has a great deal of potential... (wonder if you could flowpart a C program or something. =P) But it is good dicipline to keep to the smallest number of incremental changes at a time, even if the intermediate results aren't optimal. Right now the tree is frozen for release. I'm not sure what the best practices are with SVN, but I hope the SVN administrator will create a 0.4 fork as soon as possible so that the multitude of efforts at the 4.x port can be integrated and testing can begin. My own system is somewhat messed up from installing 4.2, but I think I have a working tree. I'm going to make a from-scratch build and push a few fixes into SVN. I just found some problems in Makefile.in... Anyway. -- New president: Here we go again... Chemistry.com: A total rip-off. Powers are not rights. |
From: Julian B. <ju...@sv...> - 2009-02-08 21:17:24
|
On Sunday 08 February 2009 21:40:00 Alan Grimes wrote: > Juan De Vincenzo wrote: > [...] > > > I'm really keen for your feedback. =) > > Yes, I'm in favor of a more direct port of Ktechlab to 4.x. I thought about that. But the more I read in the code, the more I saw the need of some design changes, that are needed sooner or later. > The idea of integrating it with kdevelop to a greater extent is > interesting and has a great deal of potential... (wonder if you could > flowpart a C program or something. =P) It won't integrate directly into kdevelop, just use some of their infrastructure. But basically your right, of course. > But it is good dicipline to keep to the smallest number of incremental > changes at a time, even if the intermediate results aren't optimal. True, but hard to manage if each change you need to do is a quite large step in the project. > Right now the tree is frozen for release. I'm not sure what the best > practices are with SVN, but I hope the SVN administrator will create a > 0.4 fork as soon as possible so that the multitude of efforts at the 4.x > port can be integrated and testing can begin. There already is a branch in SVN containing the next stable release. I manually backported all bug-fixes from trunk. If this branch is considered stable, we can tag it as released and create packages from that copy. Trunk could be opened for development again. I don't see anything against doing so. If there is the need to create bug-fixes for the new stable release, we could easily provide fixes and release another bug-fix release in the 0.3.x series. > My own system is somewhat messed up from installing 4.2, but I think I > have a working tree. I'm going to make a from-scratch build and push a > few fixes into SVN. I just found some problems in Makefile.in... Anyway. I partly broke my gentoo, too, when upgrading from KDE4.1 to 4.2. It was way more easy to install 4.x and remove old KDE3 packets. ;) I think I need to go home now. Getting quite late here. I will write some more on the whole topic tomorrow and hopefully will have cgit running on one of my machines. Bye then julian |
From: Glen C. <gca...@gm...> - 2009-02-08 21:49:15
|
> I partly broke my gentoo, too, when upgrading from KDE4.1 to 4.2. It was > way more easy to install 4.x and remove old KDE3 packets. ;) I can't compile KDE3 apps, period. Installing the dev libs after I wiped clean and went to kubuntu 8.10 wrecked my KDE4 builds, so... I started over again. /me points to his silence of late. It's looking like Julian is making headway, so I suppose soon I should check out the newest svn. I'm also in favor of a total QT4/KDE4 port.. especially since I got nada to contribute until I can compile what everyone else can. I have new filter designs to test and geda ain't simulating them. I might have to go pspice/orcad under wine for the time being, and that just @*(&%s. G |
From: Julian B. <ju...@sv...> - 2009-02-08 22:32:14
|
On Sunday 08 February 2009 22:39:05 Glen Canaday wrote: > > I partly broke my gentoo, too, when upgrading from KDE4.1 to 4.2. It was > > way more easy to install 4.x and remove old KDE3 packets. ;) > > I can't compile KDE3 apps, period. Installing the dev libs after I wiped > clean and went to kubuntu 8.10 wrecked my KDE4 builds, so... I started over > again. > > /me points to his silence of late. It's looking like Julian is making > headway, so I suppose soon I should check out the newest svn. > > I'm also in favor of a total QT4/KDE4 port.. especially since I got nada to > contribute until I can compile what everyone else can. If you followed the KDE4.x development, you mentioned, that it took them a whole year, until they got something useful... (KDE4.2) So don't expect to much from the first KTechLab KDE4 steps in SVN. > I have new filter designs to test and geda ain't simulating them. I might > have to go pspice/orcad under wine for the time being, and that just > @*(&%s. I haven't touched the simulator, yet. I'm also sure, I won't for some time. I don't know if everything will work as it should, but I am sure, that it will look good ;P bye then julian |
From: P Z. <zol...@gm...> - 2009-02-09 14:31:07
|
On Sun, 08 Feb 2009 22:11:41 +0100, Julian Bäume <ju...@sv...> wrote: >> The idea of integrating it with kdevelop to a greater extent is >> interesting and has a great deal of potential... (wonder if you could >> flowpart a C program or something. =P) > It won't integrate directly into kdevelop, just use some of their > infrastructure. But basically your right, of course. Does this mean that besides kdelibs, kdevelop will also be a dependency of ktechlab? That won't make non-kde users happy. >> But it is good dicipline to keep to the smallest number of incremental >> changes at a time, even if the intermediate results aren't optimal. > True, but hard to manage if each change you need to do is a quite large > step > in the project. Base on what I've seen in the code, I prefer a rewrite. (an the KDE guy also did the same :)) ). But first, we need a _design_, instead of starting coding directly. >> Right now the tree is frozen for release. I'm not sure what the best >> practices are with SVN, but I hope the SVN administrator will create a >> 0.4 fork as soon as possible so that the multitude of efforts at the 4.x >> port can be integrated and testing can begin. > There already is a branch in SVN containing the next stable release. I > manually backported all bug-fixes from trunk. If this branch is > considered > stable, we can tag it as released and create packages from that copy. > Trunk > could be opened for development again. I don't see anything against > doing so. > If there is the need to create bug-fixes for the new stable release, we > could > easily provide fixes and release another bug-fix release in the 0.3.x > series. > Since the release-candidate version is branched separately, we could mess up the trunk, right? :D My opinion is that we should start a new "trunk" for the kde4 port from zero, and when it reaches the level of functionalty of the 0.3 versions, that should become the new trunk version. |
From: Julian B. <ju...@sv...> - 2009-02-09 16:07:43
|
On Monday 09 February 2009 16:35:48 P Zoltan wrote: > On Sun, 08 Feb 2009 22:11:41 +0100, Julian Bäume <ju...@sv...> wrote: > >> The idea of integrating it with kdevelop to a greater extent is > >> interesting and has a great deal of potential... (wonder if you could > >> flowpart a C program or something. =P) > > > > It won't integrate directly into kdevelop, just use some of their > > infrastructure. But basically your right, of course. > > Does this mean that besides kdelibs, kdevelop will also be a dependency > of ktechlab? That won't make non-kde users happy. Nope, not KDevelop. It would be KDevPlatform, which is a quite small lib used by programms that provide IDE-like functionality. I'm not sure, if it's really needed, or we should ship the needed parts from the lib ourselfes. I'm playing around with it to find out. > >> But it is good dicipline to keep to the smallest number of incremental > >> changes at a time, even if the intermediate results aren't optimal. > > > > True, but hard to manage if each change you need to do is a quite large > > step > > in the project. > > Base on what I've seen in the code, I prefer a rewrite. (an the KDE guy > also did the same :)) ). But first, we need a _design_, instead of > starting coding directly. +1 ;) > >> Right now the tree is frozen for release. I'm not sure what the best > >> practices are with SVN, but I hope the SVN administrator will create a > >> 0.4 fork as soon as possible so that the multitude of efforts at the 4.x > >> port can be integrated and testing can begin. > > There already is a branch in SVN containing the next stable release. > Since the release-candidate version is branched separately, we could mess > up the trunk, right? :D Before we do that, I suggest to create another branch for a new feature release for the KDE3 version. This should be 0.4 and the last larger development branch for KDE3. ATM trunk is tagged as 0.4, so it would only mean to copy/move the trunk. > My opinion is that we should start a new "trunk" for the kde4 port from > zero, and when it reaches the level of functionalty of the 0.3 versions, > that should become the new trunk version. We can do that, also this would mean, that trunk will be unuseable for some time. But well, this will IMHO push the development of a KDE4 version. bye then julian |
From: Richard R. <ron...@gm...> - 2009-02-09 16:21:14
|
On Mon, Feb 9, 2009 at 4:02 PM, Julian Bäume <ju...@sv...> wrote: > On Monday 09 February 2009 16:35:48 P Zoltan wrote: >> On Sun, 08 Feb 2009 22:11:41 +0100, Julian Bäume <ju...@sv...> wrote: >> >> The idea of integrating it with kdevelop to a greater extent is >> >> interesting and has a great deal of potential... (wonder if you could >> >> flowpart a C program or something. =P) >> > >> > It won't integrate directly into kdevelop, just use some of their >> > infrastructure. But basically your right, of course. >> >> Does this mean that besides kdelibs, kdevelop will also be a dependency >> of ktechlab? That won't make non-kde users happy. > Nope, not KDevelop. It would be KDevPlatform, which is a quite small lib used > by programms that provide IDE-like functionality. I'm not sure, if it's really > needed, or we should ship the needed parts from the lib ourselfes. I'm playing > around with it to find out. > >> >> But it is good dicipline to keep to the smallest number of incremental >> >> changes at a time, even if the intermediate results aren't optimal. >> > >> > True, but hard to manage if each change you need to do is a quite large >> > step >> > in the project. >> >> Base on what I've seen in the code, I prefer a rewrite. (an the KDE guy >> also did the same :)) ). But first, we need a _design_, instead of >> starting coding directly. > +1 ;) +1 > >> >> Right now the tree is frozen for release. I'm not sure what the best >> >> practices are with SVN, but I hope the SVN administrator will create a >> >> 0.4 fork as soon as possible so that the multitude of efforts at the 4.x >> >> port can be integrated and testing can begin. >> > There already is a branch in SVN containing the next stable release. >> Since the release-candidate version is branched separately, we could mess >> up the trunk, right? :D > Before we do that, I suggest to create another branch for a new feature > release for the KDE3 version. This should be 0.4 and the last larger > development branch for KDE3. ATM trunk is tagged as 0.4, so it would only mean > to copy/move the trunk. > >> My opinion is that we should start a new "trunk" for the kde4 port from >> zero, and when it reaches the level of functionalty of the 0.3 versions, >> that should become the new trunk version. > We can do that, also this would mean, that trunk will be unuseable for some > time. But well, this will IMHO push the development of a KDE4 version. > > bye then > julian > > ------------------------------------------------------------------------------ > Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) > software. With Adobe AIR, Ajax developers can use existing skills and code to > build responsive, highly engaging applications that combine the power of local > resources and data with the reach of the web. Download the Adobe AIR SDK and > Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com > _______________________________________________ > Ktechlab-devel mailing list > Kte...@li... > https://lists.sourceforge.net/lists/listinfo/ktechlab-devel > |
From: Juan De V. <jua...@gm...> - 2009-02-11 19:00:46
|
Hi everyone, First of all, sorry that it took me a couple of days to reply to this particular thread, second, thanks a lot for your feedback. I really appreciate it. =) I'd like to also say that I'm as well in favor of a redesign or rewrite of the code wherever it is necessary, and the reason why I didn't started such a task myself is because, how I stated on my first e-mail, I'm only in the first learning stage. I actually started learning C++ just on mid-December and it is not that I already have programming experience with others languages, because I already tried Python for example, but couldn't find it interesting (I'm really liking C++ though), so I still have ahead of me tasks as, besides learning the language, also learning the use of the Qt libraries, learn good programming style, design and debugging skills, learn how to use CMake, KDevelop and Designer. Of course the list goes on but I'll leave it there so I don't panic. =P Bottom line is, that IMO, I won't be able to contribute any actual useful code for at least a couple of months. So, by this means I'd like to ask you to please don't save words when describing the work you're doing. =) I'd like to tell you as well to please don't hesitate to throw at me any "homework" you might think can be useful for my learning process, as well as for the project. I'll be also following the bugs to learn from them. This doesn't mean at all that I'll be going mute, I'll keep helping on what's at my reach, like with the site and ideas that I might have. But I wanted to let you know why I haven't said anything else about this, mostly because I don't want anybody to interpret this as a lack of interest on my side. Finally, I'd like to state that I'm really happy to see where KTechLab is heading right now. =D Regards, Juan On Mon, Feb 9, 2009 at 2:21 PM, Richard Rondu <ron...@gm...> wrote: > On Mon, Feb 9, 2009 at 4:02 PM, Julian Bäume <ju...@sv...> wrote: >> On Monday 09 February 2009 16:35:48 P Zoltan wrote: >>> On Sun, 08 Feb 2009 22:11:41 +0100, Julian Bäume <ju...@sv...> wrote: >>> >> The idea of integrating it with kdevelop to a greater extent is >>> >> interesting and has a great deal of potential... (wonder if you could >>> >> flowpart a C program or something. =P) >>> > >>> > It won't integrate directly into kdevelop, just use some of their >>> > infrastructure. But basically your right, of course. >>> >>> Does this mean that besides kdelibs, kdevelop will also be a dependency >>> of ktechlab? That won't make non-kde users happy. >> Nope, not KDevelop. It would be KDevPlatform, which is a quite small lib used >> by programms that provide IDE-like functionality. I'm not sure, if it's really >> needed, or we should ship the needed parts from the lib ourselfes. I'm playing >> around with it to find out. >> >>> >> But it is good dicipline to keep to the smallest number of incremental >>> >> changes at a time, even if the intermediate results aren't optimal. >>> > >>> > True, but hard to manage if each change you need to do is a quite large >>> > step >>> > in the project. >>> >>> Base on what I've seen in the code, I prefer a rewrite. (an the KDE guy >>> also did the same :)) ). But first, we need a _design_, instead of >>> starting coding directly. >> +1 ;) > > +1 >> >>> >> Right now the tree is frozen for release. I'm not sure what the best >>> >> practices are with SVN, but I hope the SVN administrator will create a >>> >> 0.4 fork as soon as possible so that the multitude of efforts at the 4.x >>> >> port can be integrated and testing can begin. >>> > There already is a branch in SVN containing the next stable release. >>> Since the release-candidate version is branched separately, we could mess >>> up the trunk, right? :D >> Before we do that, I suggest to create another branch for a new feature >> release for the KDE3 version. This should be 0.4 and the last larger >> development branch for KDE3. ATM trunk is tagged as 0.4, so it would only mean >> to copy/move the trunk. >> >>> My opinion is that we should start a new "trunk" for the kde4 port from >>> zero, and when it reaches the level of functionalty of the 0.3 versions, >>> that should become the new trunk version. >> We can do that, also this would mean, that trunk will be unuseable for some >> time. But well, this will IMHO push the development of a KDE4 version. >> >> bye then >> julian >> >> ------------------------------------------------------------------------------ >> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) >> software. With Adobe AIR, Ajax developers can use existing skills and code to >> build responsive, highly engaging applications that combine the power of local >> resources and data with the reach of the web. Download the Adobe AIR SDK and >> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com >> _______________________________________________ >> Ktechlab-devel mailing list >> Kte...@li... >> https://lists.sourceforge.net/lists/listinfo/ktechlab-devel >> > > ------------------------------------------------------------------------------ > Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) > software. With Adobe AIR, Ajax developers can use existing skills and code to > build responsive, highly engaging applications that combine the power of local > resources and data with the reach of the web. Download the Adobe AIR SDK and > Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com > _______________________________________________ > Ktechlab-devel mailing list > Kte...@li... > https://lists.sourceforge.net/lists/listinfo/ktechlab-devel > |
From: Julian B. <ju...@sv...> - 2009-02-11 22:36:10
|
On Wednesday 11 February 2009 20:00:42 Juan De Vincenzo wrote: > I'd like to also say that I'm as well in favor of a redesign or > rewrite of the code wherever it is necessary, and the reason why I > didn't started such a task myself is because, how I stated on my first > e-mail, I'm only in the first learning stage. I actually started > learning C++ just on mid-December and it is not that I already have > programming experience with others languages, because I already tried > Python for example, but couldn't find it interesting (I'm really > liking C++ though), so I still have ahead of me tasks as, besides > learning the language, also learning the use of the Qt libraries, > learn good programming style, design and debugging skills, learn how > to use CMake, KDevelop and Designer. Of course the list goes on but > I'll leave it there so I don't panic. =P Quite a huge list ;) > Bottom line is, that IMO, I won't be able to contribute any actual > useful code for at least a couple of months. So, by this means I'd > like to ask you to please don't save words when describing the work > you're doing. =) I learned a lot from discussions on mailing-lists. So keep on reading.. ;) Another thing I can recommend is reading developer blogs. planetkde.org is quite good for reading about interesting stuff going on in Qt and KDE world. > I'd like to tell you as well to please don't hesitate to throw at me > any "homework" you might think can be useful for my learning process, > as well as for the project. I'll be also following the bugs to learn > from them. Fixing smaller issues is a good way to get into the code. And be sure, there will be so called "junior-jobs" for you, to get in. If you have some special ideas about what to do, tell them and I can keep my eyes and may be find something for you. > This doesn't mean at all that I'll be going mute, I'll keep helping on > what's at my reach, like with the site and ideas that I might have. > But I wanted to let you know why I haven't said anything else about > this, mostly because I don't want anybody to interpret this as a lack > of interest on my side. Fine! Feedback, testing, discussing ideas... That's the way most of us start... bye julian |