After encouragement from two people, I finally ported everything :)<br>
I am attaching is a screenshot......<br>
it is available at the same link, which I posted earlier.<br>
<a href="http://k.domaindlx.com/vkhaitan/superkaramba.tar.bz2">http://k.domaindlx.com/vkhaitan/superkaramba.tar.bz2</a><br>
<br>
BTW, it may crash somewhere. I have not tested yet. I had to fix initial crash, which was actually due to a uic3 bug.<br>
if any font property is changed, but pointsize is not changed, then uic3 sets pointsize to zero, which crashes the app.<br>
There may be other bugs. good luck.<br>
<br>
<br><br><div><span class="gmail_quote">On 9/1/05, <b class="gmail_sendername">Matt Rogers</b> <<a href="mailto:mattr@kde.org">mattr@kde.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Thursday 01 September 2005 01:06, Ryan Nickell wrote:<br>> On Wed, 2005-08-31 at 21:39 -0600, Vinay Khaitan wrote:<br>> > Hi people,<br>> ><br>> > [mX] told me that superkaramba port has not happened and it doesn't
<br>> > compile with qt4, so I can help with it.<br>><br>> You're right about the port not being done yet, and we appreciate the<br>> help!<br>><br>> > I started doing the same. Ran qt3to4 porting tool and then using
<br>> > Qt3Support layer, I started changing code manually to make it<br>> > compile(with keeping an eye over changed KdelIbs api like<br>> > kdatastream.h).<br>> > Then I happen to talk to werr in #superkaramba and he told me that
<br>> > there is no use of porting it to Qt4 so, as most of it will be<br>> > rewritten, when integrating with plasma.<br>><br>> This isn't entirely true. It will need ported over at some point before<br>
> integration into Plasma. We need to first find a location to branch SK<br>> so that all this can take place in a sane environment that won't effect<br>> the 3.5 branch. Maybe into /trunk/work/ as [mX] and I talked about the
<br>> other day on IRC?<br>><br><br>i don't understand why a new branch is needed when trunk can just be used like<br>everybody else is doing.<br><br>> > So I finally left doing that.<br>> > But Half of that was already done. If any one is interested in that,
<br>> > get it from<br>> > <a href="http://k.domaindlx.com/vkhaitan/superkaramba.tar.bz2">http://k.domaindlx.com/vkhaitan/superkaramba.tar.bz2</a> .<br>><br>> I'll try to look over this as soon as I can, but until we get a new
<br>> branch someplace it can't be checked in unfortunately.<br>><br><br>what's wrong with trunk/KDE/kdeutils? trunk is for KDE 4 now.<br><br>> > files ported are<br>> ><br>> > bar.o cpusensor.o
<br>> > imagelabel_python.o memsensor.o programsensor.o<br>> > sensorparams.o textfilesensor.o<br>> > bar_python.o<br>>
>
datesensor.o karamba.o meter.o richtextlabel.o<br>>
>
sensorsensor.o textlabel.o
clickarea.o disksensor.o<br>> > karambarootpixmap.o meter_python.o richtextlabel_python.o<br>> > showdesktop.o textlabel_python.o<br>> > clickmap.o graph.o<br>> > karambasessionmanaged.o
networksensor.o rsssensor.o<br>> > taskmanager.o uptimesensor.o<br>> > (35 files)<br>> ><br>> > (put .cpp instead of .o)<br>> ><br>> > I found when talking with werr, that Most of the trouble now is that
<br>> > Design is not finalized. We dont know what will remain, what will be<br>> > ousted. The previoius task I left because of the same reason, because<br>> > Design would be different.<br>><br>> The design will change, but not before the code cleanup, dptrs and Qt4
<br>> port happens.<br>><br>> > In my personal opinion, after akademy is finished, we should first<br>> > make a clear outline of design of kicker,kdesktop,superkaramba<br>> > integration(possibly with full flow chart and tentative class
<br>> > hierarchy). It will help people like me to understand what developers<br>> > have things in mind.<br>><br>> This is a good idea. It will also give us a timeline to go by when<br>> doing the above mentioned tasks.
<br>><br>> Here's a very broad plan courtesy of [mX] and I with Petri's agreeance:<br>> 1) code cleanup<br>> 2) getting the widgets used into a correct hierarchy (our naming<br>> convention)<br>> 3) ported all over to qt4
<br>> 4) then we will move those into libplasma, without having any<br>> SuperKaramba type stuff in plasma _at all_<br>> 5) just get it to a point where we can test with a sample applet that<br>> uses those widgets
<br>> 6) have some backward compatibility wrapper or application that can<br>> handle older themes so that there are already many that can be ran when<br>> kde4 ships<br>><br>> > Thanks<br>> > Vinay Khaitan
<br>><br>> This weekend I don't have anything planned and we have a 3 day weekend<br>> because of a holiday on Monday here in the USA. So, I plan to get at<br>> least some of this out of the way before the weekend is over. I'm not
<br>> well versed in respect to dptrs, so you'll probably see me on IRC asking<br>> many questions. ;)<br>><br>> cheers,<br>> -Ryan<br>><br>> _______________________________________________<br>> Panel-devel mailing list
<br>> <a href="mailto:Panel-devel@kde.org">Panel-devel@kde.org</a><br>> <a href="https://mail.kde.org/mailman/listinfo/panel-devel">https://mail.kde.org/mailman/listinfo/panel-devel</a><br><br>--<br>Matt<br>_______________________________________________
<br>Panel-devel mailing list<br><a href="mailto:Panel-devel@kde.org">Panel-devel@kde.org</a><br><a href="https://mail.kde.org/mailman/listinfo/panel-devel">https://mail.kde.org/mailman/listinfo/panel-devel</a><br></blockquote>
</div><br>