KDEPim/Pi official announcement

[padishah_emperor]

I keep "thinking about" having a go at the dual pdaxrom with Sharp rom posted on a thread elsewhere. Just looks a little too daunting (reading through the thread, never mind actually doing it )

Yeah Zuber, if I thought I could do it without dying of old age while reading all the appropriate threads I would, maybe a good samaritan would post an idiot's guide to getting C series machines /w Cacko QT ROM to dual boot pdaXrom off SD or CF?

then again, pigs might fly...
   

[lardman]

I could understand you more if OZ/OPIE was a mature platform with good applications but I've tried it twice on two machines and for me it just isn't there yet, bits didn't work or crashed or something, always something was wrong.

I feel this way about the current incarnation of pdaXrom (stability is not the best, ipkg is broken, light & power not good). However as with OZ, the pdaXrom developers are improving things. It's horses for courses I'm afraid just as with most things.

Will your new ROM run pdaXrom apps?

OZ/GPE should do without any troubles, yes.

or HancomWord without witchcraft and hacking?

It already does, just as long as you don't use an ipk file which has a broken control file. That said this is something which ought to be changed in the ipkg code which OZ uses (so it ignores poorly created ipk files).

Anyway as you said, this is not the place for this discussion.


Si

[bluedevils]

hmmm... I'm not sure but I think there is a little miscommunication between zautrix and mickeyl.  I certainly did not want to cause a ruckus.  Maybe it would be better if you guys communicated in German.

I think mickeyl is basically saying that zautrix benefitted from the opie mail app as a base for development and he would appreciate it if the opie team could benefit from any enhanced functionality.

I do not wish to see another "cacko vs proto" argument.

[padishah_emperor]

yes. lets keep this on topic. subject closed.

[zautrix]

The point seems to be, that the Opie developers do not understand what I am doing. Some weeks ago I got a mail from an Opie Pim developer:
I was invited to use their new database backend as storage of KO/Pi.
And the writer said, that he does not see any benefit from the platform independend approach.

But that is just the purpose of all I am doing:
To have an application running on Zaurus, Linux and Windows.
With easy data exchange and syncing.

And when I take an OPie application, the first work is to make it Opie and Qtopia independent.
And I will take, when making it better, the classes of the microkde library, of course .
I don't think, that OPie wants to have a KToolBar, KAction or a KDialog in its Code.

For that reason it would not make any sense to give the changes to the Opie team.
(My program will be open source, such that everybody can have a look at the changes).
Ok, I could have written this as an answer to Mickeys post, but writing my other answer was more fun for me! ( Because of the polemic in it ).

I am just not interested in the Opie approach of writing software only for a PDA.
And I am not fragmenting the community, I am collecting quite nice programs and I free them to be a prisoner of their platform.

When I am done with OpieMail it would be compileable even for the Linux desktop and for pdaXrom for example. I am not using pdaXrom, but I think to have a quite fast mail app on it would be nice.
I consider this approach as to be the future!  For me, writing non-platform independent software is just a waste of time.

But after all, I think this thread was fun! ;-)

z.

[tg]

Variety is great. The new OZ will ship with GPE/X11 _and_ Opie while being open for other GUI environments. This is variety. Variety strenghtens the community, because you have many possibillities.

Fragmentation, on the other hand, is something different. From all the mails and posts I've read in the past years since I am working on Zaurus software, I got the impression that people would like to have fewer ROMs of higher quality - and less applications of higher quality.

Do you really see it as a good thing if you have 5 ROMs and each one has a nice feature which you absolutely love, however you can't get them all because the developers don't cooperate? I consider this not to be variety, I consider this waste of effort. This is fragmentation. Fragmentation weakens the community because nothing works really great - just pieces and bits work good and the rest is average or even below average.

(Oh btw, it's funny that you ask me this, because I've just seen a thread where you wrote "I can't help wishing pdaXrom and Cacko QT ROM were integrated though...") 

Philosophically I agree with you. In practice however, the problem at least on Z is that
most Sharp based ROMs so far have (unfortunatelly) been more stable than any OZ I've tried (on SL5500 or c860).
Also, you guys have not had a release in a long time. So for those
of us who can't hack and/or dont have time to join the projects what do you expect us to do? Maslovsky and Sash stamp out releases more frequently than you guys and each
release brings some visible improvement. qpdf2 and similar apps are only there because
some guy decided it was worth it his time to improve original GPL apps but did not find
it worth his time to submit upstream patches. That is too bad but it's the reality. Again,
as end users we have no choice but to use what is most functional or stable.
I symphatise with you and understand that OZ needs work on kernel, apps etc but the
reality is that in this case the GPL approach does not seem to work as efficiently and/or
quickly as time and time again in the case of Z one or two individuals (i.e. Sash,Maslovsky,Proto,Zautrix) seem to be able to pick things up into their own hands and put out improved releases quickly where the GPL approach seems to be very slow. Where have I gone wrong in my analysis? By the way, from my point of view as soon
as you have a REAL new release of OZ out (not one of these pre releases that have
been out there forever) I'll be switching to OZ in a heartbeat.

[elvis]

People work on Zaurus software here as a hobby or to fulfill personal needs and they generously share their work. I am very happy that zautrix has taken the time to produce such useful software for a machine that lacks so much in that department.

I am quite happy zautrix is creating a series of programs that can be utilized across the three major systems many of us use: Linux, Zaurus and Windows. It would be a real loss if he incorporated code that restricted the ease of use across all these systems. If you don't want your source code taken and re-used in a different project such as this, don't release it as GPL. Simple as that. Otherwise, be happy people use what you have written to produce useful software.

I just wish Sharp had been smart enough to support developers such as zautrix instead of producing such embarrassing software like they did. Had they done so, in a few months the Zaurus would have had a collection of PIM software vastly better than most of the competition.

[zautrix]

Besides your unwanted polemics which I just ignore, you miserably failed to see the point.

You are right!

I apologize!

I have read "he", but you wrote "we".

Maybe I need new eyes, new glasses or a new brain?

z.

[bluedevils]

agreed elvis.....now where did I put that abxcsv script......

Zautrix, your last post (oops I'm slow to post, I meant the one before the apology) was much better.  I could see how the conflicting mission statements would cause some friction.  I do see that both OZ/opie team and the KDE PIm team can both benefit.

Mickeyl, good that you kept your head cool.  I look forward to the future of the opie project.  I just wished I was a programmer so I could help out on all the projects.

[Mickeyl]

Maybe I need new eyes, new glasses or a new brain?

 

Glad we could sort that out.

Cheers,

Mickey.

[tapjpa]

You don't know how glad I am to see this discussion come to a sucessfull conclusion. I got tired of simular discussions on the Sharp board going south and getting blown way out of proportion, nobody benifits when this happens. As it was said there are so few developers for this platform that forking out in different directions only hurts everyone involved and eventualy could bring this great platform to it's death. I truely think that the opie team and zautrix are both doing great work and I hope this continues for a long time to come. I guess this goes to prove that you both are passionant about your work and are striving to keep this community alive.

Thanks again for your contributions to the Z,

Jim

[Stubear]

Yeah Zuber, if I thought I could do it without dying of old age while reading all the appropriate threads I would, maybe a good samaritan would post an idiot's guide to getting C series machines /w Cacko QT ROM to dual boot pdaXrom off SD or CF?

then again, pigs might fly...
   

I posted the scripts, pdaXrom tarball and (I thought) simple step by step instructions on getting pdaXrom to dual boot from SD.

At least a couple of others have been using my scripts (and they showed up on Japanese site too) so I know they work fro at least the C760 and C860

Stu

[roderickv]

Well said elvis! You perfectly expressed what I was thinking as I read the threads.

Mail added to the already great  KDE Pim/Pi! zautrix I LOVE YOU MAN!!

[Zuber]

Stubear,

I do actually fancy having a go at this. Just found it too daunting to read through al 12 pages of forum posts on it.

What would be best reading material

https://www.oesf.org/forums/inde...?showtopic=1510

or

https://www.oesf.org/forums/inde...?showtopic=3027

OR do I need to read both.

A shorter option would be great  

[Hrw]

OK - I get some time to work on compiling KDEPim/PI in OE enviroment.

You can compile it for Qt3 (for the desktop version ) and Qt2 ( for the embedded version).
Some classes of Qt3 does not exist in Qt2.
For that reason you do need the qtcompat lib and the qtcompat lib path in your include path.

Actually I have QT/E 2.3.7 and your qtcompat in include path - qinputdialog.h conflicts each other so I changed few files to include qtcompat/qinputdialog.h instead of qinputdialog.h

There are two different *.pro files in every directory, e.g. korganizer.pro and korganizerE.pro.

You have to make sure, that always the *E.pro is used for makefile creation when compiling for embedded.

If you use qmake , it will choose the non E *.pro version.

I use qmake but before compile I rename each *E.pro to *.pro (renamed few in CVS snapshot to have them named like directory - for example "kdepim/kabc/formats/binary/kabcformat_binaryE.pro to kdepim/kabc/formats/binary/binaryE.pro")

NOTE: package kdepimpi-1.9.1-r0: task do_compile completed

Now I have to package it, test and then I will send You patches and finally add it into OpenEmbedded (with fetching sources from SF).