Note: Moving this discussion to the qt-components mailinglist as suggested by
Henrik.
I fully agree that we should let the API drive the implementation and not the
other way around. But to make this work, you might have to add new properties
(i.e adjoining-corner) to Button so the ButtonGroup could tell it which corners
were attached to what. So in a way, because of the initial simplicity of using
Button, you might get into the situation where the implementation starts
leaking back into the public API.
And I am also concerned that we might make the API misleading when we pretend
that those segments are full featured buttons, when we in effect really only
use them as data models for the parent item, ignoring any other properties and
behavior they may have. In traditional Qt there was something called a
QButtonGroup which was a purely logical element. It could be used to
enable/disable a group of buttons and control their exclusivity. It did not
affect the appearance in any way. In this case, both Button and RadioButton
would work fine. However, the SegmentedButton seems more like a widget by
itself that has more in common with a Tab Bar than a button.
Cheers,
Jens
________________________________________
From: Sachse Torsten (Nokia-MS/Berlin)
Sent: Friday, December 17, 2010 5:27 PM
To: Bache-Wiig Jens (Nokia-MS-Qt/Oslo); Malmqvist Mathias (Nokia-MS/London)
Subject: RE: api Proposal SplitButton
Hi Jens,
if developers mainly would create a segmentedbutton from a dynamic
datasource(model) then i would go for a model. In our case i'm sure developers
want just describe/declarate the situation once so i prefer the declarative way.
You're right, using a normal button means that you have to set some styling
from outside. Correct me if i'm wrong, you guys are working on that (?).
USING NORMAL BUTTON:
- pro: less components
- pro: easier for developers
- con: maybe increases button a little bit (?)
- con: you can manipulate button in some unexpected way like anchors - here i'm
not sure if we should work against this. If the developer want to this, why not
?
USING SEGMENTEDBUTTON:
- pro: clean and secure interface
- pro: don't touch button
- con: new component - a button with different ui
- con: developer have to deal with that.
It looks like a general question for with paradigm we want go.
If i take a look onto TabBatButton, ToolBarButton, SmallButtons then we have
just a button with different layout depends on the container. I'm not sure as
an developer i want deal with that instead of just putting a button everywhere.
Btw. we are talking about the api, not about the implementation . the api
should not implementation driven :D
Thanks
Torsten
________________________________________
From: Bache-Wiig Jens (Nokia-MS-Qt/Oslo)
Sent: Friday, December 17, 2010 4:35 PM
To: Sachse Torsten (Nokia-MS/Berlin); Malmqvist Mathias (Nokia-MS/London)
Subject: RE: api Proposal SplitButton
I am not sold on the idea of using Buttons instead of a model to describe this
widget.
It requires some nasty hooks into button to support this and It leads to lots
of inconsistencies:
ButtonGroup {
Button { text: "GPRS"; }
Button { text: "WLan" ... }
Button { text: "Usb" ... }
}
What happens if you anchor one of those buttons? What happens if you move them,
scale them, rotate them and so on.
Which properties can you touch and which can you not and still have it look
like a segmented button? If I change the button
type to "accept", will it override the custom button styling imposed by the
fact that it is inside a group? Will all button types
have to support grouped styling?
I think the cleaner approach is to use non-visual descriptor objects along the
lines of:
ButtonGroup{
ButtonSegment{text:"button 1" ; onChecked:...}
ButtonSegment{text:"button 2"}
ButtonSegment{text:"button 3"}
}
Or perhaps stick with the model.
Regards,
Jens
________________________________________
From: Sachse Torsten (Nokia-MS/Berlin)
Sent: Friday, December 17, 2010 3:40 PM
To: Malmqvist Mathias (Nokia-MS/London)
Hi Mathias,
it looks different but with your changes it sounds that its not so far from my
proposal. can we agree on a api?
(btw. i would rename "orientation" to "direction" in the proposal)
Thanks
Torsten
On 12/17/2010 12:17 PM, Malmqvist Mathias (Nokia-MS/London) wrote:
Hi Torsten,
Yes, there's already an implementation on the "custom" branch.
It's called a ButtonBlock and you can find it here
http://qt.gitorious.org/qt-components/qt-components/trees/custom/components
It doesn't do exclusive selection at the moment, but I have a patch for that
here.
Also it doesn't take a set of Button elements to add to the block (as you
suggest)
at the moment, but I plan to support it once we've had some supporting things
added to QtQuick 1.1.
Cheers
Mathias
------------------------------------------------------------
Mathias Malmqvist
UX Prototype Lead
10 Great Pulteney Street, London, W1F 9NB, UK
Got no reply? Try giving me a call:
Mobile: +44 (0)77 6522 2738
http://www.nokia.com
________________________________________
From: Hartz Henrik (Nokia-MS-Qt/Oslo)
Sent: Friday, December 17, 2010 9:25 AM
To: Sachse Torsten (Nokia-MS/Berlin); Bache-Wiig Jens (Nokia-MS-Qt/Oslo);
Malmqvist Mathias (Nokia-MS/London)
Cc: Karlsson Erik.B (Nokia-MS/Helsinki); Mikola Tapani (Nokia-MS/Tampere);
Junnonen Tomas (Nokia-MS/Helsinki); Lundqvist Petrus (Nokia-MS/Helsinki); Cunha
Leo (Nokia-MS-Qt/Oslo)
Subject: Re: api Proposal SplitButton
Hi,
AFAIK the splitbutton is also being implemented in the custom branch. IMO the
API discussion should happen on the Jira task or on the mailing list so others
can join in. I suggest at the very least aligning with Jens Bache-Wiig and
Mathias Malmqvist who have been working on this so far.
Cheers,
Henrik
On Dec 15, 2010, at 10:14 PM, Karlsson Erik.B (Nokia-MS/Helsinki) wrote:
> Adding Tomas into loop
>
> - erik
>
> ________________________________________
> From: Sachse Torsten (Nokia-MS/Berlin)
> Sent: Wednesday, December 15, 2010 5:20 PM
> To: Hartz Henrik (Nokia-MS-Qt/Oslo); Mikola Tapani (Nokia-MS/Tampere)
> Cc: Karlsson Erik.B (Nokia-MS/Helsinki); Lundqvist Petrus
> (Nokia-MS/Helsinki); Cunha Leo (Nokia-MS-Qt/Oslo)
> Subject: api Proposal SplitButton
>
> Hi,
>
> Here is my API Proposal for SplitButton/ SegmentedButton / ButtonGroup
> extended from qt-200-ticket
>
> ButtonGroup {
> property int orientation: Qt.Horizontal(default) or Qt.Vertical (or
> expression)
> property Item selected: settings==="gprs" ? gprsButton:
> settings==="wlan" ? wlanButton : usbButton
> property string selectionMode: "none" or "one" (default) or "many"
> Button { id: gprsButton text: "GPRS"; }
> Button { text: "WLan" ... }
> Button { text: "Usb" ... }
> }
>
> As user i have full control about the display-behavior like: orientation:
>
> orientaton: runtime.orientation===Orientation.Landscape ? Qt.Horizontal
> : Qt.Vertical
>
> to get the automatic behavior. (easy assignment "orientaton =
> runtime.orientation" is'nt working because of different <int> values
> representations)
>
> Q: Do we need the "many" selection mode ?
>
> Cheers
> Torsten
>
> --
> Torsten Sachse
> OviJS Core/Ui (http://nforum.nokia.com/index.php?board=282.0)
> Mail: torsten.sac...@nokia.com<mailto:torsten.sac...@nokia.com>
> Phone: +49 151 55155730
>
> Nokia gate5 GmbH
> Unter den Linden 21
> 10117 Berlin
> Germany
>
> Sitz der Gesellschaft: Berlin, Amtsgericht Charlottenburg: HRB 106443 B,
> Steuernr.: 37/222/20817, ID/VAT-Nr.: DE812 845 193
> Gesch�ftsf�hrer: Dr. Michael Halbherr, Karim T�htivuori
>
--
Torsten Sachse
OviJS Core/Ui (http://nforum.nokia.com/index.php?board=282.0)
Mail: torsten.sac...@nokia.com<mailto:torsten.sac...@nokia.com>
Phone: +49 151 55155730
Nokia gate5 GmbH
Unter den Linden 21
10117 Berlin
Germany
Sitz der Gesellschaft: Berlin, Amtsgericht Charlottenburg: HRB 106443 B,
Steuernr.: 37/222/20817, ID/VAT-Nr.: DE812 845 193
Geschäftsführer: Dr. Michael Halbherr, Karim Tähtivuori
_______________________________________________
Qt-components mailing list
Qt-components@qt.nokia.com
http://lists.qt.nokia.com/mailman/listinfo/qt-components
