[Kde-games-devel] Freeze in 6 weeks
Albert Astals Cid
aacid at kde.org
Wed Jan 28 19:47:44 UTC 2015
El Dimecres, 28 de gener de 2015, a les 14:04:14, Inge Wallin va escriure:
> 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?
Really? Who promised you that? That's never been the promise, the promise of
KF5 is that it's more modular, and yes there's some libs that don't need extra
daemons and some that do need them.
> > 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?
What is "the full KDE desktop infraestructure" for you?
Cheers,
Albert
>
> 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
>
> _______________________________________________
> kde-games-devel mailing list
> kde-games-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-games-devel
More information about the kde-games-devel
mailing list