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

List:       kde-devel
Subject:    Fwd: Re: KEditListBox in trunk
From:       Christoph Burgmer <chrislb () gmx ! de>
Date:       2008-04-18 12:12:58
Message-ID: 200804181412.59564.chrislb () gmx ! de
[Download RAW message or body]

Hello list,

I have a question on a feature of a non editable combo box as input for 
KEditListBox in kdelibs which I already asked to Sebastian Trueg and Urs 
Wolfer as they did the last edits on this class. I know both of them are 
involved in other projects and thus both told me they couldn't really help. 
Urs pointed me to kde-devel and I would like to ask the same question again. 
Though Sebastian had an objection towards the application of the model to my 
use case I would still like to ask about the general case.

To make it short: KEditListBox doesn't allow non-editable combo boxes as input 
and I believe it's a limitation in the underlying design rather of the whole 
model of application.

I'll be happy if there's somebody who could either implement that or tell me, 
why it would violate proper design.

Please cc me in answers as I am not subscribed to the list.

Regards, Christoph

----------  Forwarded message  ----------

> Subject: Re: KEditListBox in trunk
> Date: Donnerstag, 17. April 2008
> From: Urs Wolfer <uwolfer@kde.org>
> To: Christoph Burgmer <chrislb@gmx.de>
>
> Hello Christoph
>
> I'm sorry, but I suppose I cannot really help here. I have just done some
> porting work / fixes in this class.
>
> If Sebastians answer does not help you, you probably better ask on the kde-
> devel mailinglist.
>
> Bye
> urs
>
> On Thursday 17 April 2008 17:55:42 you wrote:
> > Hallo Sebastian, Hallo Urs,
> >
> > I'll just start in english in case you might want to pass this mail on.
> >
> > I am writing to you as you're both involved in changing the KEditListBox
> > widget in kdelibs for the 4.1 branch lately. I would like to ask about a
> > feature I would be happy to see in this class:
> >
> > KEditListBox allows different widgets as input as long as they provide a
> > KLineEdit class on which KEditListBox operates. Setting a KComboBox will
> > result in KEditListBox ::CustomEditor calling the KComboBox::lineEdit()
> > method which returnes the associated KLineEdit instance. Now my point or
> > rather my problem is, that the KComboBox's lineEdit() method will only
> > return an instance, as long as KComboBox is editable. If it's not, the
> > following assertion will not hold. If setting the combobox to non
> > editable afterwards will make the application crash.
> >
> > Is there a point in applying an uneditable widget?
> >
> > I believe yes. The KEditListBox allows for creating a list of strings,
> > adding and removing items, ranking them with an order. That's irrelevant
> > to the special significance of the input widget.
> >
> > In my case I have a list of string encodings, which I like the user to
> > select. Only a subset of given encodings should be selected and I'd like
> > to have a combobox for that. Currently I have coded around the
> > limitations by first setting the combobox as custom editor, later add a
> > second editable lineedit and then set the combobox to non editable (seems
> > to work).
> >
> > I don't know if this in the scope of this class, so please tell me what
> > you think. It seems like some basics needs to be changed then.
> >
> > Christoph
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]