Op 20-12-2012 12:11, Shawn Rutledge schreef:
> So ultimately at that company all the abstract actions you would have
> wanted to create would still have to be converted into gui-oriented
> actions anyway, right? How would you avoid writing code to bridge or
> augment them into actions which can
On 20 December 2012 11:51, André Somers wrote:
> Op 20-12-2012 11:40, Shawn Rutledge schreef:
>> On 19 December 2012 09:13, André Somers wrote:
>>> Well, I disagree with that view of what an action represents. To me, the
>>> core of an action really is bundling a bit of state with a trigger for
>
Am 18/12/2012 00:53, schrieb André Pönitz:
> But back to the original issue, within the intended context: The
> point is that with the existence of arbitrary imperative blobs with
> arbitrary side effects and full access to global data a language's
> claim to be "declarative" is hard to defend - b
Op 20-12-2012 11:40, Shawn Rutledge schreef:
> On 19 December 2012 09:13, André Somers wrote:
>> Well, I disagree with that view of what an action represents. To me, the
>> core of an action really is bundling a bit of state with a trigger for
>> something to happen (I try to avoid the word 'actio
Op 20-12-2012 11:10, Bache-Wiig Jens schreef:
>>> I find the idea of adding a new QCoreAction base class that is shared
>>> between QML Action and QAction and only carries a small subset of
>>> properties an unnecessary layer of abstraction. The idea of QAction is to
>>> have the convenience of
On 19 December 2012 09:13, André Somers wrote:
> Well, I disagree with that view of what an action represents. To me, the
> core of an action really is bundling a bit of state with a trigger for
> something to happen (I try to avoid the word 'action' here) in a
> convenient API. That piece of stat
>> I find the idea of adding a new QCoreAction base class that is shared
>> between QML Action and QAction and only carries a small subset of properties
>> an unnecessary layer of abstraction. The idea of QAction is to have the
>> convenience of icons, text and shortcuts predefined for you in a
On Wed, Dec 19, 2012 at 5:17 AM, Rutledge Shawn
wrote:
> On 19 Dec 2012, at 12:57 PM, Stephen Kelly wrote:
>> I agree. In particular, using objectName for both the name of the action and
>> automatically for part of the name of the icon seems like a bad idea to me.
>
> Well objectName has such lit
On 19 Dec 2012, at 12:57 PM, Stephen Kelly wrote:
> I agree. In particular, using objectName for both the name of the action and
> automatically for part of the name of the icon seems like a bad idea to me.
Well objectName has such little use that it's usually left blank, whereas it
would be nic
On 19 Dec 2012, at 11:59 AM, André Somers wrote:
> And that new action is also integratable with QtWidgets somehow?
Not that we are planning, but I wonder if we could get that eventually by
having a common base class, or some sort of converter/bridge thing.
> Or is that an action type that only
On Tuesday, December 18, 2012 10:35:04 Alan Alpert wrote:
> > But I still think the action needs a name, which can be used by the
> > image provider to find the icon. (This is independent of whether the
> > image provider uses files or resources; the icon will be found by name
> > either way.) Ma
Op 19-12-2012 11:52, Rutledge Shawn schreef:
> On 19 Dec 2012, at 9:13 AM, André Somers wrote:
>
>> Op 14-12-2012 8:45, Bache-Wiig Jens schreef:
>>> What I would propose is that we keep the QAction exactly as it is and make
>>> it possible to use it from QML as well as introduce a new slightly
>>
On 19 Dec 2012, at 9:13 AM, André Somers wrote:
> Op 14-12-2012 8:45, Bache-Wiig Jens schreef:
>> What I would propose is that we keep the QAction exactly as it is and make
>> it possible to use it from QML as well as introduce a new slightly
>> simplified QML Action component as previously sugg
Op 14-12-2012 8:45, Bache-Wiig Jens schreef:
> I have been lurking in the discussion a bit but I guess it is time for me to
> pitch in. It is hard to keep up with 10 different threads at once. :)
>
> I find the idea of adding a new QCoreAction base class that is shared between
> QML Action and QA
On Tue, Dec 18, 2012 at 11:26 AM, Shawn Rutledge
wrote:
> On 18 December 2012 19:35, Alan Alpert <4163654...@gmail.com> wrote:
>> How is this going to work? If no iconSource or imageSource exists on
>> the Action then the delegate in QtQuickControls uses
>> "image://icons/.png"?
>
> Yes that's wha
On 18 December 2012 19:35, Alan Alpert <4163654...@gmail.com> wrote:
> How is this going to work? If no iconSource or imageSource exists on
> the Action then the delegate in QtQuickControls uses
> "image://icons/.png"?
Yes that's what I was thinking.
Pros:
- after you name the action, you don't r
On Tue, Dec 18, 2012 at 10:18 AM, Shawn Rutledge
wrote:
> On 18 December 2012 18:39, Alan Alpert <4163654...@gmail.com> wrote:
>> Used like Jens suggested for components:
>>> RowLayout { Repeater { model: myActions ; ToolButton { action: modelData} }
>>> }}
>>>
>>> Granted, a bit too verbose. Howe
On 18 December 2012 18:39, Alan Alpert <4163654...@gmail.com> wrote:
> Used like Jens suggested for components:
>> RowLayout { Repeater { model: myActions ; ToolButton { action: modelData} }
>> }}
>>
>> Granted, a bit too verbose. However with a little bit of convenience, we can
>> for instance red
With all the discussion about the C++ API and the C++ compatibility
let me clarify that it is a different topic to the QML API. They're
both important topics and I'd like to see both implemented perfectly,
but they are separate topics with potentially separate
implementations.
The exposed QML API
On Tuesday 18 December 2012 13:33:59 Robin Burchell wrote:
> On Tue, Dec 18, 2012 at 12:55 PM, Stephen Kelly
wrote:
> >> The details of the split
> >> was just following Andre's suggestion. text/secondaryText might fit
> >> into CoreAction, icon will not.
> >
> > Why not? Because QML doesn't do
On Tuesday 18 December 2012 13:24:59 Stephen Kelly wrote:
> That's why it was a mistake to not extract a QGuiAction from QAction imo,
> but it's a mistake we have to live with and deal with as best we can (for
> both C++ and QML APIs).
I would like to mention that one can still consider the possib
On Tue, Dec 18, 2012 at 12:55 PM, Stephen Kelly wrote:
>> The details of the split
>> was just following Andre's suggestion. text/secondaryText might fit
>> into CoreAction, icon will not.
>
> Why not? Because QML doesn't do QIcons? The reason for that is not clear
> either to me.
I don't think t
On Sunday, December 16, 2012 21:12:18 Bache-Wiig Jens wrote:
> > But if you are writing a 100% declarative UI you'd probably wish to
> > avoid linking against widgets. So I guess you're saying regular old
> > QActions should be exposed just for putting a declarative UI onto
> > legacy apps, and al
On Monday, December 17, 2012 08:39:14 Alan Alpert wrote:
> On Sun, Dec 16, 2012 at 4:38 PM, Bache-Wiig Jens
>
> wrote:
> >>> What is so terrible about it? QtWidgetEnables would be private API, only
> >>> used by components internally and we would not need to load the module
> >>> on embedded, or
On Monday, December 17, 2012 01:11:55 Bache-Wiig Jens wrote:
> >> How about having ToolBar.addAction() for convenience? It is exactly what
> >> we do for widgets.>
> > Widgets is a toolkit for an imperative language. Looping over lists
> > and adding things individually is acceptable there. In a d
On Tuesday, December 18, 2012 12:55:50 Stephen Kelly wrote:
> Some of this came up before by the way, so it's another discussion to
> review when designing this:
>
> http://thread.gmane.org/gmane.comp.lib.qt.devel/957/focus=1883
Another funny thread from almost a full year ago:
http://thread.
On Thursday, December 13, 2012 13:18:35 you wrote:
> On Thu, Dec 13, 2012 at 8:18 AM, Stephen Kelly
wrote:
> > The reason for the split is not clear to me. Do you suggest that UIAction
> > would be a QML element, not a creatable C++ class? Do you suggest that
> > CoreAction would be a creatable C
>
> Right, but referring to a file (bundled or in the resources) is still
> referring to the icon by name, no?
One of them is a logical icon-name the other one is a file-name. The logical
name refers to an icon outside of the application, the file name refers to a
file bundled inside the appli
On Tuesday, 2012-12-18, Bache-Wiig Jens wrote:
> > Now, you've most likely seen way more Qt apps than I have, but all I have
> > seen were shipping icons, most of them as part of their resources, some
> > as files.
>
> I am pretty sure this is a misunderstanding. We do not bundle the icons
> insid
> Now, you've most likely seen way more Qt apps than I have, but all I have
> seen
> were shipping icons, most of them as part of their resources, some as files.
I am pretty sure this is a misunderstanding. We do not bundle the icons inside
the Qt libraries. People bundle it with their applica
On Sunday, 2012-12-16, Bache-Wiig Jens wrote:
> >> Sure. But we don't actually have support for logical icon names on
> >> Windows, Mac or Embedded since we don't have pixmaps for those.
> >
> > I'm not sure what you mean.
>
> This is really sidetracking the discussion but Windows and Mac do not
On Mon, Dec 17, 2012 at 08:33:47AM -0800, Alan Alpert wrote:
> On Sun, Dec 16, 2012 at 5:12 PM, André Pönitz
> wrote:
> > On Sun, Dec 16, 2012 at 03:42:59PM -0800, Alan Alpert wrote:
> >> On Sun, Dec 16, 2012 at 1:12 PM, Bache-Wiig Jens
> >> wrote:
> >> >> If you create the actions in C++, you'd
On Sun, Dec 16, 2012 at 4:38 PM, Bache-Wiig Jens
wrote:
>>>
>>> What is so terrible about it? QtWidgetEnables would be private API, only
>>> used by components internally and we would not need to load the module on
>>> embedded, or am I missing something?
>>
>> I don't see how you'd avoid loadin
On Sun, Dec 16, 2012 at 5:12 PM, André Pönitz
wrote:
> On Sun, Dec 16, 2012 at 03:42:59PM -0800, Alan Alpert wrote:
>> On Sun, Dec 16, 2012 at 1:12 PM, Bache-Wiig Jens
>> wrote:
>> >> If you create the actions in C++, you'd still have to repeat each and
>> >> every one in QML, unless we provide a
On Sunday, 2012-12-16, Shawn Rutledge wrote:
> It doesn't bother me to put icon names in the C++ code, either. The
> widget way of using resources works great, because you don't have to
> think about the path to the image on disk. If you don't want to use
> resources then some kind of image prov
On Sun, Dec 16, 2012 at 03:42:59PM -0800, Alan Alpert wrote:
> On Sun, Dec 16, 2012 at 1:12 PM, Bache-Wiig Jens
> wrote:
> >> If you create the actions in C++, you'd still have to repeat each and
> >> every one in QML, unless we provide a way to iterate over the ones
> >> that should be in a menu,
>> How about having ToolBar.addAction() for convenience? It is exactly what we
>> do for widgets.
>
> Widgets is a toolkit for an imperative language. Looping over lists
> and adding things individually is acceptable there. In a declarative
> language it is really not the right way to go. Even if
>>
>> What is so terrible about it? QtWidgetEnables would be private API, only
>> used by components internally and we would not need to load the module on
>> embedded, or am I missing something?
>
> I don't see how you'd avoid loading the module on embedded. Because
> the components are writte
On Sun, Dec 16, 2012 at 1:12 PM, Bache-Wiig Jens
wrote:
>> If you create the actions in C++, you'd still have to repeat each and
>> every one in QML, unless we provide a way to iterate over the ones
>> that should be in a menu, or a toolbar.
>
> How about having ToolBar.addAction() for convenience
On Sun, Dec 16, 2012 at 6:32 AM, Bache-Wiig Jens
wrote:
>> Having a common base class was something I thought of last summer or
>> so. I still think maybe it can work. But we won't get the benefit of
>> it unless we change the QWidget menu system to take the base class
>> pointers, and deal with
> But if you are writing a 100% declarative UI you'd probably wish to
> avoid linking against widgets. So I guess you're saying regular old
> QActions should be exposed just for putting a declarative UI onto
> legacy apps, and also there should be a new QQuick action, which is an
> unrelated class
On 16 December 2012 20:05, Bache-Wiig Jens wrote:
> On Dec 16, 2012, at 4:55 PM, Shawn Rutledge
> wrote:
>> How can you expose it without needing to link to the widgets library?
>> or without sharing implementation?
>
> Your C++ application adds it's widget actions to the root context. Your
> a
On Dec 16, 2012, at 4:55 PM, Shawn Rutledge wrote:
> On 16 December 2012 15:32, Bache-Wiig Jens wrote:
>> I did not say the idea was not useful. My point was that it is not required
>> since we already have access to everything the common base class would give
>> you. Action is a QObject, so
On 16 December 2012 15:32, Bache-Wiig Jens wrote:
> I did not say the idea was not useful. My point was that it is not required
> since we already have access to everything the common base class would give
> you. Action is a QObject, so when we expose it to QML, we can already access
> text, to
> Having a common base class was something I thought of last summer or
> so. I still think maybe it can work. But we won't get the benefit of
> it unless we change the QWidget menu system to take the base class
> pointers, and deal with them polymorphically; or deprecate the old
> QAction and hav
On 14 December 2012 20:06, Alan Alpert <4163654...@gmail.com> wrote:
> On Thu, Dec 13, 2012 at 11:45 PM, Bache-Wiig Jens
> wrote:
>> I have been lurking in the discussion a bit but I guess it is time for me to
>> pitch in. It is hard to keep up with 10 different threads at once. :)
>>
>> I find t
On Thu, Dec 13, 2012 at 11:45 PM, Bache-Wiig Jens
wrote:
> I have been lurking in the discussion a bit but I guess it is time for me to
> pitch in. It is hard to keep up with 10 different threads at once. :)
>
> I find the idea of adding a new QCoreAction base class that is shared between
> QML
I have been lurking in the discussion a bit but I guess it is time for me to
pitch in. It is hard to keep up with 10 different threads at once. :)
I find the idea of adding a new QCoreAction base class that is shared between
QML Action and QAction and only carries a small subset of properties an
On Thu, Dec 13, 2012 at 8:18 AM, Stephen Kelly wrote:
> On Wednesday, December 12, 2012 11:41:27 Alan Alpert wrote:
>> The original Action API I proposed was approaching it as a UI logic
>> element. Let's see what we come up with when we split it into UI and
>> business elements
>>
>> CoreAction:/
On Wednesday, December 12, 2012 11:41:27 Alan Alpert wrote:
> The original Action API I proposed was approaching it as a UI logic
> element. Let's see what we come up with when we split it into UI and
> business elements
>
> CoreAction://Names are for illustrative purposes only
> QtObject { //Prot
On Wed, Dec 12, 2012 at 12:44 AM, André Somers wrote:
> Op 11-12-2012 21:59, Alan Alpert schreef:
>> On Tue, Dec 11, 2012 at 10:49 AM, Shawn Rutledge
>> wrote:
>>> On Tue, Dec 11, 2012 at 09:48:22AM -0800, Alan Alpert wrote:
Why can't this be QML-only? For the set of controls exposed in
Op 12-12-2012 18:35, Stephen Kelly schreef:
> On Wednesday, December 12, 2012 09:44:10 André Somers wrote:
>> Op 11-12-2012 21:59, Alan Alpert schreef:
>>> On Tue, Dec 11, 2012 at 10:49 AM, Shawn Rutledge
>>>
>>> wrote:
On Tue, Dec 11, 2012 at 09:48:22AM -0800, Alan Alpert wrote:
> Why ca
On Wednesday, December 12, 2012 01:15:14 André Pönitz wrote:
> On Tue, Dec 11, 2012 at 03:20:35PM -0800, Alan Alpert wrote:
> > On Tue, Dec 11, 2012 at 2:57 PM, André Pönitz
> >
> > wrote:
> > > On Tue, Dec 11, 2012 at 09:48:22AM -0800, Alan Alpert wrote:
> > > ...
> > >
> > >> But there are other
On Tuesday, December 11, 2012 23:57:48 you wrote:
> On Tue, Dec 11, 2012 at 09:48:22AM -0800, Alan Alpert wrote:
> > > We also need to find out whether we can come up with something which
> > > QtWidgets users can migrate to (the QWidget* in the QAction API is
> > > quite niche, and not necessarily
On Wednesday, December 12, 2012 09:44:10 André Somers wrote:
> Op 11-12-2012 21:59, Alan Alpert schreef:
> > On Tue, Dec 11, 2012 at 10:49 AM, Shawn Rutledge
> >
> > wrote:
> >> On Tue, Dec 11, 2012 at 09:48:22AM -0800, Alan Alpert wrote:
> >>> Why can't this be QML-only? For the set of controls e
On Tuesday, December 11, 2012 09:48:22 you wrote:
> On Tue, Dec 11, 2012 at 6:07 AM, Stephen Kelly
wrote:
> > For comparison, you could look at what we did with QML1 based
> > kdepim-mobile.
> Great, thanks! It's always good to see how this can is handled in real
> applications. I just hope that
Op 11-12-2012 21:59, Alan Alpert schreef:
> On Tue, Dec 11, 2012 at 10:49 AM, Shawn Rutledge
> wrote:
>> On Tue, Dec 11, 2012 at 09:48:22AM -0800, Alan Alpert wrote:
>>> Why can't this be QML-only? For the set of controls exposed in
>>> C++-only we have a C++-only Action API. When we add a set of
On Tue, Dec 11, 2012 at 03:20:35PM -0800, Alan Alpert wrote:
> On Tue, Dec 11, 2012 at 2:57 PM, André Pönitz
> wrote:
> > On Tue, Dec 11, 2012 at 09:48:22AM -0800, Alan Alpert wrote:
> > ...
> >
> >> But there are other ways to support those use cases than adding a
> >> C++ API for the new Actions
On Tue, Dec 11, 2012 at 2:57 PM, André Pönitz
wrote:
> On Tue, Dec 11, 2012 at 09:48:22AM -0800, Alan Alpert wrote:
> ...
>
>> But there are other ways to support those use cases than adding a
>> C++ API for the new Actions. My initial thought is something like a
>> QActionBridge which can take a
On Tue, Dec 11, 2012 at 09:48:22AM -0800, Alan Alpert wrote:
> >
> > We also need to find out whether we can come up with something which
> > QtWidgets users can migrate to (the QWidget* in the QAction API is
> > quite niche, and not necessarily ideal API anyway). Possibly even
> > investigating wh
On Tue, Dec 11, 2012 at 10:49 AM, Shawn Rutledge
wrote:
> On Tue, Dec 11, 2012 at 09:48:22AM -0800, Alan Alpert wrote:
>> Why can't this be QML-only? For the set of controls exposed in
>> C++-only we have a C++-only Action API. When we add a set of controls
>> exposed in QML-only we can have a QML
On Tue, Dec 11, 2012 at 09:48:22AM -0800, Alan Alpert wrote:
> Why can't this be QML-only? For the set of controls exposed in
> C++-only we have a C++-only Action API. When we add a set of controls
> exposed in QML-only we can have a QML-only Action API. We don't
Because it seems likely that the b
Tirsdag 11. desember 2012 09.25.37 skrev Alan Alpert:
> On Tue, Dec 11, 2012 at 5:12 AM, Stephen Kelly
wrote:
> > Hi Alan,
> >
> > Thanks for your initiative in pointing out what is still missing in
> > QtQml/QtQuick.
> >
> > On Monday, December 10, 2012 19:39:36 Alan Alpert wrote:
> >> Note th
On Tue, Dec 11, 2012 at 6:07 AM, Stephen Kelly wrote:
> On Monday, December 10, 2012 19:39:36 Alan Alpert wrote:
>> Here's a hypothetical example of how it could work
>> in practice.
>>
>> MenuControl {
>> //Default property is property list actions
>> ActionGroup {
>> id: fileActi
On Tue, Dec 11, 2012 at 5:12 AM, Stephen Kelly wrote:
>
> Hi Alan,
>
> Thanks for your initiative in pointing out what is still missing in
> QtQml/QtQuick.
>
> On Monday, December 10, 2012 19:39:36 Alan Alpert wrote:
>> Note that it has no-where near as many properties as QAction. toolTip
>> and w
On Mon, Dec 10, 2012 at 9:05 PM, Martin Jones
wrote:
> On Tue, Dec 11, 2012 at 1:39 PM, Alan Alpert <4163654...@gmail.com> wrote:
>> QAction served widgets well as an abstraction for an "Action" which is
>> exposed to the UI in a platform specific manner. This was shared
>> between menus and toolb
On Tue, Dec 11, 2012 at 11:39:26AM +, Davet Jacques wrote:
> Shawn Rutledge :
> > On Mon, Dec 10, 2012 at 07:39:36PM -0800, Alan Alpert wrote:
> >> Note that it has no-where near as many properties as QAction. toolTip
> >> and whatsThis for example are very desktop centric so not needed
> >> an
On Monday, December 10, 2012 19:39:36 Alan Alpert wrote:
> Here's a hypothetical example of how it could work
> in practice.
>
> MenuControl {
> //Default property is property list actions
> ActionGroup {
> id: fileActions
> text: "File"
> collapsible: true
>
Hi Alan,
Thanks for your initiative in pointing out what is still missing in
QtQml/QtQuick.
On Monday, December 10, 2012 19:39:36 Alan Alpert wrote:
> Note that it has no-where near as many properties as QAction. toolTip
> and whatsThis for example are very desktop centric so not needed
> anymo
Shawn Rutledge :
> On Mon, Dec 10, 2012 at 07:39:36PM -0800, Alan Alpert wrote:
>> Note that it has no-where near as many properties as QAction. toolTip
>> and whatsThis for example are very desktop centric so not needed
>> anymore. Because it's not actually doing the rendering it doesn't need
>> e
On Mon, Dec 10, 2012 at 07:39:36PM -0800, Alan Alpert wrote:
> Note that it has no-where near as many properties as QAction. toolTip
> and whatsThis for example are very desktop centric so not needed
> anymore. Because it's not actually doing the rendering it doesn't need
> enabled, visible or font
Op 11-12-2012 4:39, Alan Alpert schreef:
> QAction served widgets well as an abstraction for an "Action" which is
> exposed to the UI in a platform specific manner. This was shared
> between menus and toolbars and some other things. I think we'll need
> something similar for QML, so that the QtQuic
On Tuesday, 2012-12-11, Alan Alpert wrote:
> Action type:
> QtObject {
> property string text
> property url imageSource
> property string shortcut
> property bool checkable: false
> property bool checked: false
> signal triggered(bool checked)
> }
>
> Note that it has no-
On 12/11/2012 04:39 AM, Alan Alpert wrote:
> The QMenu API allows for adding menu separators too, but I haven't
> seen those in apps for a while. Is it worth adding another type or
> flag to integrate separators into the Action API?
Couldn't menu separators automatically be added between each
non
On Tue, Dec 11, 2012 at 1:39 PM, Alan Alpert <4163654...@gmail.com> wrote:
> QAction served widgets well as an abstraction for an "Action" which is
> exposed to the UI in a platform specific manner. This was shared
> between menus and toolbars and some other things. I think we'll need
> something s
QAction served widgets well as an abstraction for an "Action" which is
exposed to the UI in a platform specific manner. This was shared
between menus and toolbars and some other things. I think we'll need
something similar for QML, so that the QtQuick controls can provide
platform styled menus, too
76 matches
Mail list logo
