Frédéric Marchal wrote:
> I was looking at how QString::toLocal8bit works and, on Windows, it
> looks like it may enter an infinite loop.
>
> If I got it right, QString::toLocal8Bit_helper calls
> QTextCodec::fromUnicode which, on Windows, calls
> QWindowsLocalCodec::convertFromUnicode in qwindows
I mentioned:
>> merge-base - if you have a strict tree, this isn't a merge, so it's
>> where one was branched off the other, but nothing about the merge-base
>> or any of its ancestors contains any hint as to which branch it was on
>> when it was committed.
René J.V. Bertin replied:
> In short, th
> Forgot - maybe a stupid question, but can you set up a topic branch to
> track a remote branch (and would that make sense)?
$ git checkout -b topic remote/branch
will, by default, set up topic so that, while it's checked out, git pull
fetches remote/branch to merge with it (or rebase it onto) a
René J.V. Bertin
> I've seen graphical utilities that attempt to show the branch
> hierarchy in some kind of tree,
You can even use: git log --graph
if you can cope with ASCII art ;-)
> but apparently miss from `git help branch` if it's possible to know
> the origin branch of a topic branch. Is i
In response to:
>>> What works well for me e.g. before doing a commit is what I think of
>>> as manual rebasing: I remove my patches one way or another, git-pull,
>>> and then reapply the patch(es).
I offered:
>> That's pretty much exactly what
>>
>> $ git pull -r
>>
>> (a.k.a. --rebase) will do f
> On 01/04/16 07:49, Thiago Macieira wrote:
>> I want to point this out:
>>
>> On quinta-feira, 31 de março de 2016 22:48:35 PDT Thiago Macieira wrote:
>>> On sexta-feira, 1 de abril de 2016 05:16:33 PDT Tvete Paul wrote:
>>
>> It's still March 31st.
Lars Knoll replied:
> You’re just living in the
Rolland Dudemaine said:
> Actually, git-gpush will update the whole history of changes that may
> be on your checkout, not only the single one you're pushing. Just been
> bitten by that this morning again, and that invalidates all your
> reviews on gerrit.
Well, any way of pushing is subject to th
On quarta-feira, 30 de março de 2016 22:23:35 PDT Konstantin Tokarev wrote:
>> Hello,
>>
>> Are there any plans to reimplement QThreadStorage via thread_local for
>> compilers which support it?
Thiago Macieira replied:
> I haven't investigated whether it's possible. Probably not.
Konstantin: try
I said:
>>> That's pretty much exactly what
>>>
>>> $ git pull -r
>>>
>>> (a.k.a. --rebase) will do for you, automagically. It might not play
>>> ideally with merges in all cases, but I'm guessing you don't have a
>>> surfeit of those.
To which:
> Op 30/03/2016 om 19:09 schreef René J.V. Bertin:
> Thanks for such a lengthy and detailed overview - I hope you had that
> sitting around somewhere! :)
heh - I touch-type at speed and have all of that in my head.
I learned git under demanding circumstances, so learned it thorouhgly.
> It also illustrates very nicely why I'll keep thinking that
René J.V. Bertin said:
> I'm not exactly familiar with using branches; I just tried to create
> one, apply a patch, commit it and then push to gerrit. That was a bit
> of a failure; the commit to my local branch was also applied to the
> branch I thought I'd branched off, and the push to gerrit wa
René J.V. Bertin said:
> I've got a few things I'd like to put up for code review, which I've
> been putting off because I can only think of doing them either one by
> one (carrying each to completion before moving on to the next) or by
> using parallel working copies. Neither is what I'd call effi
Thiago Macieira said:
> We have a qdoc generator. We don't have a markdown generator.
>
> More importantly, we know how to write qdoc syntax.
There is also an "eat our own dog-food" argument somewhere here: we ask
developers to document their code in qdoc, so we should be happy to use
it ourselves
Kai Koehne said:
> I've been contemplating whether we should instead use some more
> formalized decision process. We could have a document uploaded in git,
> and every change needs to be reviewed and approved by Lars.
This sounds like an eminently sensible way to document a consensus: we
can have
Giuseppe D'Angelo:
>>> The question is, can/should we get the HTML output of these documents
>>> published somewhere, for ease of access?
All the HTML generated from QDoc in all of our code should be visible in
some public way. This would just be one more page of that.
>>> Do they need their own
Mitch asked:
>> Is this worth mentioning in the documentation?
Andre' P replied:
> I think it would make sense to list the features that are affected so
> that users can decide whether they actually need one of them, or not,
> instead of having this unspecific (and untrue) "strange things may
> ha
> Why do we insist on testing for something that proxies the real need?
> We need X and we know that Y provides X, so we test for Y. Why can't
> we just test for X?
Indeed. It reminds me of the web-sites that used to test with a few
browsers and refuse access to anything but the known-good versio
Andreas Hartmetz said:
> Arcminutes are a really good idea. The size of screen elements isn't
> really about physical dimensions, it's about size on retina (the
> actual biological thing ;) really, or legibility.
[...]
> If the system had "known" that the typical user to screen distance was
> 2-3 m
> What's wrong with in that case defining the conversion? Or resetting
> the default conversions and defining everything in "space-time"?
By all means provide the means for the user to define context-specific
conversion. I'm mostly arguing against trying to automagically do it
all for them.
Koehne Kai added, to the discussion of priorities and LTS,
> The current descriptions of the priorities in JIRA [1] IMO aren't too
> helpful, since they focus too much on impact on a release.
The release is in the (possibly distant) future when prioritising; and,
when doing triage, I don't know wh
André Somers used m* for minutes and metres, footnoting:
> )* Note the first clash already...
I think it is fairly sane to just insist that SI units take precedence,
especially given that we support multi-letter unit names (e.g. pt, px,
mm, cm), so min will do fine for minutes.
> Numerical values
On quarta-feira, 24 de fevereiro de 2016 22:38:56 PST Michael Möllney wrote:
>> - Is there or should there be a Wiki-Page giving rules of thump, what
>> inconsistent between API docs and actual behavior is a bug that
>> should be fixed in 5.6 LTS?
(I like the concept of a "rule of thump", but
> Simon Hausmann wrote:
>> Hmm, change https://codereview.qt-project.org/#/c/147846/ was
>> supposed to fix this issue.
>>
>> The subject of the email refers to 5.6 but in the body you say that
>> you are building the dev branch. If it is the latter, could it be
>> that the fix hasn't hit dev yet
Shawn said:
> So maybe the best way to design the visual aspect of most applications
> is to use font-based units (like the em space) for physical sizes, but
> for touch UIs, to also use physical measurements as a minimum.
> e.g. width: Math.max(7mm, 3em) - will it be possible, or can we have
> nic
> Of course I am going slightly off-topic with this thoughts...
So let's have a change of Subject.
> The QML based DSL driving it would benefit greatly if one could easily
> express the physical unit of each number (ampere, newton, meters, ...)
> and if one could preserve this information during c
> On Thu, Feb 18, 2016 at 10:50:22AM +, Simon Hausmann wrote:
>> What do you think?
Oswald Buddenhagen replied:
> that it's a bit silly that we're having this discussion *yet again*. ;)
> http://thread.gmane.org/gmane.comp.lib.qt.devel/6572/focus=6807
I was amused that the discussion related t
Very much a digression but ...
> TUIO models the touchpoint as a rotated ellipse though, right? [snip
> URL] And I think that’s nice, for finger touchpoints at least
> (although markers could be any shape). It can be assumed to be the
> ellipse inscribed in a rect
Traditional graphics always th
>>> 2. Also lookup qt.conf in all of QLibraryInfo::libraryPaths() (this is
>>> how we got the plugins found)
>>
>> Potentially problematic if plugins might install a qt.conf that isn't
>> what your application needs.
>
> I have full control of the content of my application bundle and the
> libraryP
Maximilian Hrabowski (28 January 2016 10:47):
> What we need is a way to look up the qt.conf at another location as well.
[...]
> I thought about the following ways (order gives my personal opinion’s
> priority):
>
> 1. Add a new public API: static void QLibraryInfo::setQtConfFilePath(
> const QSt
> On Fri, Jan 22, 2016 at 11:59 AM, Marc Mutz wrote:
>> I'm not sure about what outcome to expect, and I don't remember any
>> numbers posted by anyone else, either.
Cristial replied:
> From the David Stone's Writing Robust Code page 34:
However, see what Marc said about how to do a proper comp
> AFAIK C++11/14 compilers have zero-cost exception, so, is there any
> reason why not start using them in Qt 6.0 ?
Any "zero cost" claim is with respect to some assumed base-point. ISTR
exceptions require RTTI (run-time type info, as used by dynamic_cast<>),
so I guess this "zero cost" claim tak
>>> The build is done every Saturday on a Ubuntu 14.04 system and
>>> the result is then uploaded to coverity
>>
>> What's the specific URL ?
>
> You will need to join the "project" and then can see the results.
I take it that's something I can do once the site is back up.
If not, where do I need
> The build is done every Saturday on a Ubuntu 14.04 system and
> the result is then uploaded to coverity
What's the specific URL ?
> the build is always done from the dev branch and I wonder if in front
> of a release we shouldn't be tracking the release branch instead.
I'm surprised the releas
Hi again Mandeep,
Thanks for that.
> Accepted: 1446367200
> Ignorant of DST (-> 1): Sun Nov 1 01:40:00 2015
> Accepted: 1446370860
> Ignorant of DST (-> 0): Sun Nov 1 01:41:00 2015
OK, fun - now I know when at least one implementation changes over within the
hour !
Eddy.
> If you're willing to compile and run the attached simple C program,
> please let me know its output and your platform's details - ideally
> off-list - I'll give a summary in a few days' time.
Thanks to those who responded, I now know:
* that all the platforms below do the same thing if tm_isdst
> SEP?
Sorry, reference to hitch-hiker's guide to the galaxy:
Someone Else's Problem.
Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
IIUC, the problem Thiago is discussing is a crash on exit(), or after
main() has returned. This limits the scope of the problem (we don't
make applications crashy while running), but only somewhat. There may
be things in the application loading a plugin that rely on clean
shutdown, including dest
Kevin Kofler wrote:
> The EU actually defines the switchover time in UTC,
That's a surprise. Do you have a reference for that ?
> so which hour is duplicated depends on the actual
> time zone. It's the 3:mm hour in CET/CEST.
I distinctly remember, the weekend before last, seeing the 2:mm hour
d
Hi John,
I was hoping to hear from you - thanks for getting in touch.
> I'm the original author of a lot of the current QDateTime/QTimeZone code,
Indeed; git blame told me this and you'd shown up in my googling for
references to the topic, which is why I've added you to some
code-reviews.
> I'm
Hi all,
I'm looking into QTBUG-49008 and need to work out how diverse
implementations of mktime handle DST transitions: at one end of the year
there's a gap (where 1:59 is followed by 3:00), at the other end there's
a duplicated hour (where 2:59 is followed by a reprise of 2:00 in
Europe, or 1:59
Thiago said:
> And if it's that easy for you to create it, I think you should create
> that yourself in your project.
It might, all the same, be worth documenting the recipe for the benefit
of anyone else with similar needs, to save them having to work out the
details afresh.
Eddy.
__
Alexander said:
> Qt officially supports the following platforms that use libxcb:
> OpenSuSE 13.1 (libxcb 1.9.1, xcb-proto 1.8)
> Red Hat Enterprise Linux 6.6 (libxcb 1.9, xcb-proto 1.8)
> Ubuntu 14.04 - 64bit (libxcb 1.10, xcb-proto 1.10)
For reference, Debian stable (Jessie) is also on 1.10
>>> Did I simply hit a "feature" Qt won't ever encounter because it
>>> doesn't use C (nor va_arg)?
is what I was referring back to when I said:
>> Well, it's nice to hear we don't use var-args.
Perhaps I misunderstood ! I'm relatively new to Qt myself.
On grep-ing code, I see we do in fact us
> A bit of a generic question, [...] about the preferred use of 0 instead of
> NULL.
One of the habits of C++ that a C programmer always finds weird.
> Now I remembered having to modify some of my own code to use NULL
> instead of 0 to avoid crashing, on 64bit (capable) hardware. I cannot
> reme
44 matches
Mail list logo
