[Kde-games-devel] Freeze in 6 weeks

[Inge Wallin]

On Wednesday, January 28, 2015 07:38:23 laurent Montel wrote:
> Le Tuesday 27 January 2015 23:58:22 Albert Astals Cid a écrit :
> > El Dimarts, 27 de gener de 2015, a les 15:53:32, Ian Wadham va escriure:
> > > Hi Jeremy,
> > > 
> > > Re Save and Load in KMahjongg requiring kded and friends:-
> > > 
> > > On 27/01/2015, at 2:00 PM, Jeremy Whiting wrote:
> > > > Ah, maybe it's the use of kio :/
> > > 
> > > Any game or any app can crash… and then DrKonqi requires KIO
> > > (via XML remote procedure calls) to connect to Bugzilla and submit
> > > a bug report or check for duplicates.  I cannot see DrK for KF5 being
> > > re-worked in any immediate time frame… :-(
> > > 
> > > > Is that strictly required for kmahjongg to save and load files?
> > > 
> > > No.  Actually, KMJ uses getSaveUrl() but then goes on to check that
> > > 
> > > it has a local file name.  On the load(), it uses getOpenUrl() and then:
> > >     KIO::NetAccess::download(url, fname, this);
> > > 
> > > A "braces and belt" approach?
> > > 
> > > I think consistency should be restored, i.e. use getSaveFileName() and
> > > getOpenFileName().  The actual file-I/O code in KMahjongg is using
> > > QFile and QDataStream.
> > > 
> > > > Isn't QFileDialog and such adequate here?
> > > 
> > > Should be!  With the added benefit that QFileDialog gives you a native
> > > file dialog on non-Linux platforms… :-)  This can make Qt-based apps
> > > consistent with other apps on that platform.
> > > 
> > > > I mean are we expecting to save and load the save games over the
> > > > network or something that would require kio?
> > > 
> > > No, not in KMahjongg.  But with some games, who knows?  Do KSudoku
> > > and Palapeli players want to exchange puzzles over the Internet?  Or use
> > > remote locations to save their games?
> > > 
> > > Or are those features there because network-transparent I/O was
> > > fashionable
> > > with KDE Games programmers a few years ago?… ;-)  It is not that hard to
> > > save a file locally and then move it to a remote site… or attach it to
> > > an
> > > email...
> > 
> > This is non-sense, why remove network-transparency? What you should do is
> > fix KF5 on Mac OSX to work instead of removing features from apps.
> 
> I am agree with Albert if there is a problem with network-transparency on
> MacOsX it's better to fix it that remove it.

That is not the issue. The issue is that it was promised that if you developed 
your program with KDE Frameworks 5 instead of KDElibs, you would get a more 
lightweight program that did not need any daemons to run. 

Now this turns out to be not true.   *That* is what we want, not to remove 
network transparency per se. But if the promise from frameworks 5 is not kept, 
what is there to be done?

> And this problem will be in other application.
> It's not just a problem with kdegames so fix it for kdegames will fix for
> all application.
> 
> We can't remove feature each time we need to fix on a specific platform no ?

Yes, it will be in other applications.  But that is the price you have to pay 
for platform portability sometimes.

I never thought it was reasonable to have to start the full KDE desktop 
infrastructure just to run an application from the KDE on, say, Gnome.  But 
that's what we had to do back in the kdelibs days. Frameworks 5 was supposed 
to get rid of that but now it turns out that it doesn't.  The question is: is 
this just not yet implemented or was this design goal abandoned?

This is what we need to focus on. Network transparency is *not* the issue.

> > Cheers,
> > 
> >   Albert
> >   
> > > Cheers, Ian W.
> > > 
> > > _______________________________________________
> > > kde-games-devel mailing list
> > > kde-games-devel at kde.org
> > > https://mail.kde.org/mailman/listinfo/kde-games-devel
> > 
> > _______________________________________________
> > kde-games-devel mailing list
> > kde-games-devel at kde.org
> > https://mail.kde.org/mailman/listinfo/kde-games-devel