[Panel-devel] Superkaramba Qt4 Port

[Ryan Nickell]

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?  

>  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.

> 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