[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: Character style ui : let me know what you think
From:       Nicolas Goutte <nicolasg () snafu ! de>
Date:       2004-08-27 19:07:16
Message-ID: 200408272107.16699.nicolasg () snafu ! de
[Download RAW message or body]

Yes, but KDE 3.3 is out and KDE 3.4 is potentially after KOffice 1.4, if it 
would exist at all.

Have a nice day!

On Friday 27 August 2004 20:20, p.stirnweiss_koffice@bluewin.ch wrote:
> >-- Message original --
>
> From: David Faure <faure@kde.org>
>
> >To: For developer's discussion about KOffice <koffice-devel@mail.kde.org>
> >Date: Fri, 27 Aug 2004 19:59:27 +0200
> >Subject: Re: Character style ui : let me know what you think
> >Reply-To: For developer's discussion about KOffice
> > <koffice-devel@mail.kde.org>
> >
> >On Friday 27 August 2004 19:53, p.stirnweiss_koffice@bluewin.ch wrote:
> >> If I understood the document about binary compatibility properly, in
> >> order to patch KFontChooser and keep binary compatibility, I should
> >> create a
> >
> >new
> >
> >> constructor which take one more argument "bool showPreview=True", and
>
> indicate
>
> >> in the code to merge it with the default constructor in next binary
> >> compat breaking. I should not just add an extra argument to the default
> >> constructor. Am I correct?
> >
> >Yes, except for the default value of the bool. Before the merging, you
> > can't have the "=true" part, this would lead to ambiguous calls.
> >
> >> I guess I should submit the patch to kde-devel?
> >
> >kde-core-devel, for such a core kdelibs class. But we can talk about it
>
> here
>
> >first if you prefer :-)
>
> Basicelly, my idea is to cut'n'paste the default constructor, adding a bool
> "showPreview". The idea is to use the hide() encapsulated in an if check.
> My first idea was to encapsulate the creation of the lineEdit but I do not
> know if it would not break the setPreviewText function (set the text
> property of a non existent label).
>
> >Of course another approach is to say: well, if we change that font dialog
> >so much,
> >(we added to it the "only scalable fonts" methods already, for koffice)
> >maybe we want to simply roll out our own. Dunno.
>
> I am not too sure about this. We can eventually arange to take ownership
> of the maintenance of that class, but forking it will lead to inconsistency
> within the desktop for no real gain. We would have to maintain a class of
> our own anyway.
>
> >--
> >David Faure, faure@kde.org, sponsored by Trolltech to work on KDE,
> >Konqueror (http://www.konqueror.org), and KOffice
> > (http://www.koffice.org). _______________________________________________
> >koffice-devel mailing list
> >koffice-devel@mail.kde.org
> >https://mail.kde.org/mailman/listinfo/koffice-devel
>
> _______________________________________________
> koffice-devel mailing list
> koffice-devel@mail.kde.org
> https://mail.kde.org/mailman/listinfo/koffice-devel

_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]