Re: Porting KWidgets to Qt5
Hi, 2012/7/9 Иван Комиссаров: Hm, it seems that Qt guys are not very happy seeing KDE features in qt. I would like someone from KDE to participate in discussions about changes. For example, they insist that KTabBar functionality is not needed as it can be easily implemented in subclass:) https://codereview.qt-project.org/#change,29650 If someone from KDE is really interested, they can send me gerrit account, so i can add them as a reviwers IMHO, the constructive criticism that your patch set 4 got from Jeremy Katz makes sense. To me, it looks like the problem is not that Qt guys are not very happy seeing KDE features in qt, but that you did not take his arguments into account. Best regards, Frank ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Porting KWidgets to Qt5
Hm, previos message was rejected as spam:) Ok, if KDE devs can live without tis signal, i can live too. However we could just rename it to something less specific than 'newTabrequested but not confusing with doublClicked(). So, before i start other work with tabbar i would like to ask some questions. 1) I can add property autoHideTabBar to hide it when tab count is equal or less than 1. Is it needed? Should it be added to both QTabBar and QTabWidget? 2) I can add property switchTabsOnDrag to allow automatically changing tabs when user drags something over it. Is it needed? ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Porting KWidgets to Qt5
On Monday 09 July 2012 15:46:25 David Faure wrote: PS: calling people stupid won't get you far in terms of respect within the Qt community. Or the KDE community for that matter: http://www.kde.org/code-of-conduct/ Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud patron of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Porting KWidgets to Qt5
Ok, that's very interesting, but i asked two questions and still don't see any answer. No offence, Kevin, i just prefer discuss code, not my communication skiils. 09.07.2012, в 18:34, Kevin Ottens написал(а): On Monday 09 July 2012 15:46:25 David Faure wrote: PS: calling people stupid won't get you far in terms of respect within the Qt community. Or the KDE community for that matter: http://www.kde.org/code-of-conduct/ Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud patron of KDE, http://www.kdab.com ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Porting KWidgets to Qt5
On Monday 09 July 2012 18:05:07 Иван Комиссаров wrote: Ok, if KDE devs can live without tis signal, i can live too. However we could just rename it to something less specific than 'newTabrequested but not confusing with doublClicked(). And we can also add an if() in the apps when porting them away from KTabBar (and renaming the signal and slots anyway), no big deal. So, before i start other work with tabbar i would like to ask some questions. 1) I can add property autoHideTabBar to hide it when tab count is equal or less than 1. Is it needed? Yes this seems very commonly used. http://lxr.kde.org/ident?i=setTabBarHidden Should it be added to both QTabBar and QTabWidget? I guess so, although if it's deemed too corner-case then having it in QTabBar only is good enough (now that tabBar() is public). 2) I can add property switchTabsOnDrag to allow automatically changing tabs when user drags something over it. Is it needed? Interesting, KTabBar seems to do this by default, without even an option to turn it off? I wonder if this means QTabBar should do the same, or if it should indeed be enabled explicitely. I'm not sure if there's a use case for *not* doing it (especially with a timer, like in KTabBar, so that stuff doesn't jump around all the time). I would try to implement this without a property first, or to ask on the qt development list whether anyone would object. But of course a property is fine with me too. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Some notes from QtCS
Hi, I just want to give some rough notes on a couple of the sessions I attended at QtCS and my impressions on some of the discussions. See the Qt development mailing list for more detailed minutes from most sessions. Locale: --- Minutes posted to list. * ICU will become the Locale backend in 5.1 so will be a requirement on all platforms * Most platforms ship ICU anyway except for Windows, but ICU is required for QtWebKit anyway so not a new problem * Time Zone support comes built-in to ICU so will be used as basis of new QTimeZone support in QDateTime, but will still integrate into the platform * Time Zone api will be a lot simpler, but will be sufficient for needs of KDEPIM Printing: - Minutes posted to list. * In 5.0 QtPrintSupport is just a refactor, clean-up and bug fix release * In 5.1 or 5.2 will be replaced with new module QtPrint that adds new features KDE wants * Can easily fix many problems and add features on Linux/Mac, but Windows printing as always the problem * Bug fix patches welcome! Releasing: -- No minutes posted as yet. * Time based releases favoured after 5.0, perhaps every 6 months? * More release team members needed, short on people * Face many of the same issues as KDE, could learn from us Location: - Presented by a guy from Nokia Commercial / Nokia Maps, none of the actual devs were there so unable to obtain as much detail as I would like. No minutes posted. * Not yet in feature freeze, was a near complete rewrite, not certain if will make 5.0 release date * Still one monolithic module for data containers, location services, and mapping services/widgets * Now depends on Qt3D to draw maps so dependencies heavier than before * QML only in 5.0, C++ in 5.1 (I assume only means gui components?) * Rendering said to be ugly slow, but improvements coming in 5.1 * Still tightly tied to Nokia Maps, other map plugins possible but only Nokia implemented and likely to be supported by Nokia * No layers any more? * Big question over future, but Nokia Maps might be interested in maintaining for potential revenue Now, this is the impression given second-hand from a presenter who openly expressed frustrations around the development and I haven't had time to verify all he said. I have confirmed there are Geoclue and Gypsy backends for position services in master, but no mapping services other than Nokia. In short, there's a big question mark over the continued existence or maintenance of QtLocation, and questions if it's suitable for our needs. Certainly it has failed to alleviate any of the concerns I expressed about it at my Camp KDE talk. QtPim: -- I attended this with Volker who's probably better placed to comment, but the general impression was the same as for QtLocation: a lot of uncertainty over its continued maintenance, and being designed very much around Nokia's limited requirements. No minutes posted as yet. Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
