Hello
I've just noticed that the "GUI: Input methods" component in JIRA has got an
update now saying "(Non-Latin languages)". That is, it seems the purpose of
that component has changed to mean complex input methods only.
I've been reassigning to that component anything that is related to *any*
>
>
>
> >>> While your proposed approach is rather clean, it carries one drawback,
> >>> which is the lack of type information, with all its consequences.
>
PRO:
*- Can data-clean/input-validate on either C++ or QML side, can add more
custom validators in different places
*- ?More fine-grain
On Friday 25 of April 2014 13:03:33 Richard Moore wrote:
> On 25 April 2014 11:51, Alberto Mardegan wrote:
> > For instance, I would like to have a GeoPoint type with "latitude" and
> > "longitude" properties; if I exposed it as a QVariantMap, I wouldn't be
> > able to prevent the QML code from doi
On Apr 25, 2014, at 7:28 AM, Dominik Holland
wrote:
>
> Am 25.04.14 15:05, schrieb Joshua Kolden:
>>
>> On Apr 25, 2014, at 3:51 AM, Alberto Mardegan
>> wrote:
>>
>>> On 04/24/2014 03:11 PM, Joshua Kolden wrote:
>>> [...]
We have a solution that works very well for us using QVariantMa
Am 25.04.14 15:05, schrieb Joshua Kolden:
>
> On Apr 25, 2014, at 3:51 AM, Alberto Mardegan
> wrote:
>
>> On 04/24/2014 03:11 PM, Joshua Kolden wrote:
>> [...]
>>> We have a solution that works very well for us using QVariantMaps and an
>>> MVC pattern / strong separation between data objects an
On Apr 22, 2014, at 12:10 PM, Thiago Macieira wrote:
> Em ter 22 abr 2014, às 19:34:48, Denis Shienkov escreveu:
>> 1. or keep it as is, but then bytesWritten() will be "tell lies"
>
> It's not lying. It's telling the user that the bytes were written from the
> QIODevice to the underlying devic
On Apr 25, 2014, at 3:51 AM, Alberto Mardegan
wrote:
> On 04/24/2014 03:11 PM, Joshua Kolden wrote:
> [...]
>> We have a solution that works very well for us using QVariantMaps and an
>> MVC pattern / strong separation between data objects and view. It
>> appears to me that most people are ha
On 25 April 2014 11:51, Alberto Mardegan wrote:
> For instance, I would like to have a GeoPoint type with "latitude" and
> "longitude" properties; if I exposed it as a QVariantMap, I wouldn't be
> able to prevent the QML code from doing stuff like:
> p.latitude = 60
> p.longitde = 10 // note the t
On 04/24/2014 03:11 PM, Joshua Kolden wrote:
[...]
> We have a solution that works very well for us using QVariantMaps and an
> MVC pattern / strong separation between data objects and view. It
> appears to me that most people are having this issue because it’s not
> common to use MVC with QtWidge
On 25-Apr-14 04:21, Sze Howe Koh wrote:
> I consider QML and JavaScript to be different languages. JavaScript
> can be embedded into QML to extend QML's capabilities, just like how
> it can be embedded into HTML to extend HTML's capabilities.
Yep, I hear people keep repeating the mantra "QML is d
> After playing a bit with Xamarin (yes, I know, but put aside the C# hate for
> a minute),
> it's quite striking what different approaches can result in (and it also made
> it quite clear what Qt is doing better - but also worse than other cross
> platform solutions).
Have you elaborated on t
+1
N.
Il giorno 24/apr/2014, alle ore 21:15, Attila Csipa ha
scritto:
> It's a bit tricky. Traditionally, Qt did UIs by mimicking/drawing the UI
> elements itself. This is cool, as it's allows for those native looking,
> but also super-customizable (and quite fast) UIs. Or, rather, this use
12 matches
Mail list logo