[Panel-devel] Superkaramba Qt4 Port

[Matt Rogers]

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