[Panel-devel] Superkaramba Qt4 Port

[Vinay Khaitan]

After encouragement from two people, I finally ported everything :)
I am attaching is a screenshot......
it is available at the same link, which I posted earlier.
http://k.domaindlx.com/vkhaitan/superkaramba.tar.bz2

BTW, it may crash somewhere. I have not tested yet. I had to fix initial 
crash, which was actually due to a uic3 bug.
if any font property is changed, but pointsize is not changed, then uic3 
sets pointsize to zero, which crashes the app.
There may be other bugs. good luck.



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