[Panel-devel] Superkaramba Qt4 Port

Thu Sep 1 15:01:25 CEST 2005

forgot to mention that I didn't have xmms-devel installed, so perhaps xmms 
part is not compiled. And because qxembed hence systray is not ready, I have 
commented out systray things and left its class.
Once QX11Embed porting is done in Kicker, I think, it should be easy to port 
here.

On 9/1/05, Vinay Khaitan <vkhaitan at gmail.com> wrote:
> 
> 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/20050901/affbbcbe/attachment.html