Re: Dialogs, QPT and Qt5
Hello, On Friday 29 November 2013 21:05:42 Albert Astals Cid wrote: > El Divendres, 29 de novembre de 2013, a les 12:22:48, Kevin Ottens va > escriure: > > Overall my point is that it's mostly features which really belongs > > upstream. > > Right, but they don't exist at the moment, do they? Nope. They're not really gone either in the interim. It's not a shame for an application to keep using kde4support for a little while if needed. We got apps using kde3support for a while. > Why do you hate those features and need to kill them now? I hope you realize that painting that in love/hate is overly simplistic. > What about apps that use those features? What are we going to tell the > developers? If it's really essential to them: help us get the feature upstream, use kde4support in the meantime. And to get back to the set of features mentioned initially. We can have all of them without kde4support (KFontChooser being available in kwidgetsaddons) except two: * Having a revert button in QColorDialog to get back to the default color; * Loading a list of palettes in QColorDialog. AFAICT both don't have API, but are features provided by the GUI. So if/once we upstream applications will get it as Qt releases are rolled out. Nothing to block a release for IMO. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter 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: Dialogs, QPT and Qt5
Hi! 2013/11/29 Albert Astals Cid > El Divendres, 29 de novembre de 2013, a les 12:22:48, Kevin Ottens va > escriure: > > On Friday 29 November 2013 12:00:38 Christoph Feck wrote: > > > On Friday 29 November 2013 08:53:06 Kevin Ottens wrote: > > > > KColorDialog and KFontDialog are out of the picture. We contributed > > > > to the upstream QColorDialog and QFontDialog so that they have the > > > > features we needed out of the box. We only need to do something > > > > for the file dialog. > > > > > > Not sure if we can silently drop the K classes. > > > > > > KFontDialog: > > > - allows the application to specify a list of fonts to show > > > > To upstream if that's used (IIRC we didn't find users of that). > > > > > - allows the application to request fixed-width fonts only > > > > That's upstream. > > > > > - allows limiting to only change family, style, or size > > > > To upstream if that's used (IIRC almost no user again). > > > > > - supports fractional point sizes, e.g. 9.4 pt. > > > > To upstream if needed. > > > > > - word wraps and scrolls big sample texts > > > > To upstream. > > > > > KColorDialog: > > > - allows the application to specify a default color, where the user > > > can revert to > > > > To upstream. > > > > > - supports both RGB and HSV color models > > > > Looks like QColorDialog does too, or I'm missing something? > > > > > - has support for loadable palettes (editable via kcoloredit) > > > > OK, that one is indeed missing. And if we want to upstream that it'll > > require more work than the rest. > > > > > - appearantly the color picker and hex line edit have been upstreamed, > > > but I just tried Qt 5.3 Designer, and those features did not appear. > > > > Odd, I see them here. > > > > > > Overall my point is that it's mostly features which really belongs > upstream. > > Right, but they don't exist at the moment, do they? > > Why do you hate those features and need to kill them now? > > What about apps that use those features? What are we going to tell the > developers? "Sorry but your feature was not really important so we killed > it, > but don't worry KDE loves you!" > > Maybe I'm totally wrong, but If those developers think that those features are really important, perhaps they can wait for the next version of KF5, which I suppose that will be based on Qt5.3, which can have all those features upstreamed. It doesn't have to be "include them right now or kill them forever" :-) The transition to KF5 won't be as fast as to have all the developers changing their code the day after the release of KF5, will they? Is there any possibility to find a solution between the two? Cheers, David Gil Doesn't feel right. > Cheers, > Albert > > > And they're either stuff we can contribute at any point or stuff which is > > unused. The only exception seems to be the loadable palettes, but that's > > not enough to warrant having a full fledged color dialog on our side IMO. > > So if that's really important, it's something to design properly to be > able > > to plug those loadable palettes into QColorDialog. > > > > Regards. > > ___ > 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: Dialogs, QPT and Qt5
El Divendres, 29 de novembre de 2013, a les 12:22:48, Kevin Ottens va escriure: > On Friday 29 November 2013 12:00:38 Christoph Feck wrote: > > On Friday 29 November 2013 08:53:06 Kevin Ottens wrote: > > > KColorDialog and KFontDialog are out of the picture. We contributed > > > to the upstream QColorDialog and QFontDialog so that they have the > > > features we needed out of the box. We only need to do something > > > for the file dialog. > > > > Not sure if we can silently drop the K classes. > > > > KFontDialog: > > - allows the application to specify a list of fonts to show > > To upstream if that's used (IIRC we didn't find users of that). > > > - allows the application to request fixed-width fonts only > > That's upstream. > > > - allows limiting to only change family, style, or size > > To upstream if that's used (IIRC almost no user again). > > > - supports fractional point sizes, e.g. 9.4 pt. > > To upstream if needed. > > > - word wraps and scrolls big sample texts > > To upstream. > > > KColorDialog: > > - allows the application to specify a default color, where the user > > can revert to > > To upstream. > > > - supports both RGB and HSV color models > > Looks like QColorDialog does too, or I'm missing something? > > > - has support for loadable palettes (editable via kcoloredit) > > OK, that one is indeed missing. And if we want to upstream that it'll > require more work than the rest. > > > - appearantly the color picker and hex line edit have been upstreamed, > > but I just tried Qt 5.3 Designer, and those features did not appear. > > Odd, I see them here. > > > Overall my point is that it's mostly features which really belongs upstream. Right, but they don't exist at the moment, do they? Why do you hate those features and need to kill them now? What about apps that use those features? What are we going to tell the developers? "Sorry but your feature was not really important so we killed it, but don't worry KDE loves you!" Doesn't feel right. Cheers, Albert > And they're either stuff we can contribute at any point or stuff which is > unused. The only exception seems to be the loadable palettes, but that's > not enough to warrant having a full fledged color dialog on our side IMO. > So if that's really important, it's something to design properly to be able > to plug those loadable palettes into QColorDialog. > > Regards. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Dialogs, QPT and Qt5
On Friday 29 November 2013 12:45:42 Hugo Pereira Da Costa wrote: > On 11/29/2013 12:22 PM, Kevin Ottens wrote: > > On Friday 29 November 2013 12:00:38 Christoph Feck wrote: > >> - allows limiting to only change family, style, or size > > > > To upstream if that's used (IIRC almost no user again). > > If I understand right, this is really usefull in KCM font selection when > you want to change all fonts at once, but for instance only the size. > Would be quite an issue if this was to go ... KFontChooser is in kwidgetsaddons. KFontDialog is almost just wrapping it in a dialog. That's usable from the font selection KCM of course. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter 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: Dialogs, QPT and Qt5
On Fri, Nov 29, 2013 at 12:45 PM, Hugo Pereira Da Costa < hugo.pere...@free.fr> wrote: > On 11/29/2013 12:22 PM, Kevin Ottens wrote: > > On Friday 29 November 2013 12:00:38 Christoph Feck wrote: > > On Friday 29 November 2013 08:53:06 Kevin Ottens wrote: > > KColorDialog and KFontDialog are out of the picture. We contributed > to the upstream QColorDialog and QFontDialog so that they have the > features we needed out of the box. We only need to do something > for the file dialog. > > Not sure if we can silently drop the K classes. > > KFontDialog: > - allows the application to specify a list of fonts to show > > To upstream if that's used (IIRC we didn't find users of that). > > > - allows the application to request fixed-width fonts only > > That's upstream. > > > - allows limiting to only change family, style, or size > > To upstream if that's used (IIRC almost no user again). > > If I understand right, this is really usefull in KCM font selection when > you want to change all fonts at once, but for instance only the size. > Would be quite an issue if this was to go ... > > > - supports fractional point sizes, e.g. 9.4 pt. > > To upstream if needed. > > > - word wraps and scrolls big sample texts > > To upstream. > > > KColorDialog: > - allows the application to specify a default color, where the user > can revert to > > To upstream. > > > - supports both RGB and HSV color models > > Looks like QColorDialog does too, or I'm missing something? > > > - has support for loadable palettes (editable via kcoloredit) > > OK, that one is indeed missing. And if we want to upstream that it'll require > more work than the rest. > > > - appearantly the color picker and hex line edit have been upstreamed, > but I just tried Qt 5.3 Designer, and those features did not appear. > > Odd, I see them here. > > > Overall my point is that it's mostly features which really belongs upstream. > And they're either stuff we can contribute at any point or stuff which is > unused. The only exception seems to be the loadable palettes, but that's not > enough to warrant having a full fledged color dialog on our side IMO. So if > that's really important, it's something to design properly to be able to plug > those loadable palettes into QColorDialog. > > Regards. > > > > ___ > Kde-frameworks-devel mailing > listKde-frameworks-devel@kde.orghttps://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 > > Should we maybe use KFontChooser in this case? I have the intuition that it will do that, but I'm unsure. The documentation is not very clear and I don't see a test. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Dialogs, QPT and Qt5
On 11/29/2013 12:22 PM, Kevin Ottens wrote: On Friday 29 November 2013 12:00:38 Christoph Feck wrote: On Friday 29 November 2013 08:53:06 Kevin Ottens wrote: KColorDialog and KFontDialog are out of the picture. We contributed to the upstream QColorDialog and QFontDialog so that they have the features we needed out of the box. We only need to do something for the file dialog. Not sure if we can silently drop the K classes. KFontDialog: - allows the application to specify a list of fonts to show To upstream if that's used (IIRC we didn't find users of that). - allows the application to request fixed-width fonts only That's upstream. - allows limiting to only change family, style, or size To upstream if that's used (IIRC almost no user again). If I understand right, this is really usefull in KCM font selection when you want to change all fonts at once, but for instance only the size. Would be quite an issue if this was to go ... - supports fractional point sizes, e.g. 9.4 pt. To upstream if needed. - word wraps and scrolls big sample texts To upstream. KColorDialog: - allows the application to specify a default color, where the user can revert to To upstream. - supports both RGB and HSV color models Looks like QColorDialog does too, or I'm missing something? - has support for loadable palettes (editable via kcoloredit) OK, that one is indeed missing. And if we want to upstream that it'll require more work than the rest. - appearantly the color picker and hex line edit have been upstreamed, but I just tried Qt 5.3 Designer, and those features did not appear. Odd, I see them here. Overall my point is that it's mostly features which really belongs upstream. And they're either stuff we can contribute at any point or stuff which is unused. The only exception seems to be the loadable palettes, but that's not enough to warrant having a full fledged color dialog on our side IMO. So if that's really important, it's something to design properly to be able to plug those loadable palettes into QColorDialog. Regards. ___ 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: Dialogs, QPT and Qt5
On Friday 29 November 2013 12:00:38 Christoph Feck wrote: > On Friday 29 November 2013 08:53:06 Kevin Ottens wrote: > > KColorDialog and KFontDialog are out of the picture. We contributed > > to the upstream QColorDialog and QFontDialog so that they have the > > features we needed out of the box. We only need to do something > > for the file dialog. > > Not sure if we can silently drop the K classes. > > KFontDialog: > - allows the application to specify a list of fonts to show To upstream if that's used (IIRC we didn't find users of that). > - allows the application to request fixed-width fonts only That's upstream. > - allows limiting to only change family, style, or size To upstream if that's used (IIRC almost no user again). > - supports fractional point sizes, e.g. 9.4 pt. To upstream if needed. > - word wraps and scrolls big sample texts To upstream. > KColorDialog: > - allows the application to specify a default color, where the user > can revert to To upstream. > - supports both RGB and HSV color models Looks like QColorDialog does too, or I'm missing something? > - has support for loadable palettes (editable via kcoloredit) OK, that one is indeed missing. And if we want to upstream that it'll require more work than the rest. > - appearantly the color picker and hex line edit have been upstreamed, > but I just tried Qt 5.3 Designer, and those features did not appear. Odd, I see them here. Overall my point is that it's mostly features which really belongs upstream. And they're either stuff we can contribute at any point or stuff which is unused. The only exception seems to be the loadable palettes, but that's not enough to warrant having a full fledged color dialog on our side IMO. So if that's really important, it's something to design properly to be able to plug those loadable palettes into QColorDialog. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter 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: Dialogs, QPT and Qt5
On Friday 29 November 2013 08:53:06 Kevin Ottens wrote: > KColorDialog and KFontDialog are out of the picture. We contributed > to the upstream QColorDialog and QFontDialog so that they have the > features we needed out of the box. We only need to do something > for the file dialog. Not sure if we can silently drop the K classes. KFontDialog: - allows the application to specify a list of fonts to show - allows the application to request fixed-width fonts only - allows limiting to only change family, style, or size - supports fractional point sizes, e.g. 9.4 pt. - word wraps and scrolls big sample texts KColorDialog: - allows the application to specify a default color, where the user can revert to - supports both RGB and HSV color models - has support for loadable palettes (editable via kcoloredit) - appearantly the color picker and hex line edit have been upstreamed, but I just tried Qt 5.3 Designer, and those features did not appear. Christoph Feck (kdepepo) ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Dialogs, QPT and Qt5
Hello, On Thursday 28 November 2013 17:53:14 Aleix Pol wrote: > I've seen that when we ask for a QFileDialog in KF5 we get a generic > QFileDialog at the moment. The reason is simple, KFileDialog is deprecated > in KDE4Support and we are not implementing > QPlatformDialogHelper *QPlatformThemecreatePlatformDialogHelper(DialogType > dialogType). *And* KFileDialogQtOverride got moved in kde4support too. That's the reason why we used to get a KFileDialog for the static calls previously. Got broken during the move to kde4support. We shouldn't use that technique anymore though (covers only the static case and is rather intrusive IMO). So using a QPlatformDialogHelper is definitely the way forward. > I would like to make it happen, my only question is then what should we do? > Should we have a framework for KFileDialog, KColorDialog and KFontDialog? KColorDialog and KFontDialog are out of the picture. We contributed to the upstream QColorDialog and QFontDialog so that they have the features we needed out of the box. We only need to do something for the file dialog. > Should we fork them and get a copy in PlatformIntegration? Yes, we need something in the platform theme plugin. Be it a full fledged KFileDialog fork or a leaner QDialog which contains a KFileWidget I let you judge. I've a slight preference for composition (QDialog + KFileWidget), especially as the resulting class will be completely internal with no public API. Cheers. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter 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: Dialogs, QPT and Qt5
On 28/11/13 16:53, Aleix Pol wrote: > Dear frameworkers, > I've seen that when we ask for a QFileDialog in KF5 we get a generic > QFileDialog at the moment. The reason is simple, KFileDialog is > deprecated in KDE4Support and we are not implementing > QPlatformDialogHelper > *QPlatformThemecreatePlatformDialogHelper(DialogType dialogType). > > I would like to make it happen, my only question is then what should we do? > Should we have a framework for KFileDialog, KColorDialog and KFontDialog? > Should we fork them and get a copy in PlatformIntegration? Ideally, I guess we would make the versions in KDE4Support shims for the Qt versions, which would then delegate to the platform plugin. That might mean ditching some of the more esoteric functions. Alternatively, I'd propose just forking it, given that KFileDialog probably contains a bunch of code that's not really relevant to the platform plugin, for example. I know that copying code is generally A Bad Thing, but I think it would be reasonable in this instance. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Dialogs, QPT and Qt5
On Thursday 28 November 2013 17:53:14 Aleix Pol wrote: > Dear frameworkers, > I've seen that when we ask for a QFileDialog in KF5 we get a generic > QFileDialog at the moment. The reason is simple, KFileDialog is deprecated > in KDE4Support and we are not implementing > QPlatformDialogHelper *QPlatformThemecreatePlatformDialogHelper(DialogType > dialogType). > > I would like to make it happen, my only question is then what should we do? > Should we have a framework for KFileDialog, KColorDialog and KFontDialog? > Should we fork them and get a copy in PlatformIntegration? A third option would be making this a not "source compatible" change and force applications to switch from K*Dialog to Q*Dialog. That way, we could move the code directly to platformintegration. Cheers ! ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
