Re: [Development] How to get winid from qprocess id for QProcess
On Thu, Feb 20, 2020 at 5:36 PM Sujan Dasmahapatra
wrote:
> I am running an external app, which I want to fit onto my QScrollArea, for
> this I am writing code like this.
>
> // launch weasis
> QProcess *process = new QProcess();
> process->start("./viewer-win32.exe");
> if (process->waitForFinished())
> {
> return;
> }
>
> QWindow *window = QWindow::fromWinId(211812356);
> window->setFlags(Qt::FramelessWindowHint);
> _patient_gui->scrollArea_1->setWidget(QWidget::createWindowContainer(window));
>
> But how can I get the wind id? it is hard coded here, is there any way to get
> the id from process id.
>
> any help is highly appreciated.
>
Dear Sujan
The direction is to enumerate currently running windows of a particular process
and to find the right one, i.e. by title.
You can start here:
https://docs.microsoft.com/en-us/windows/win32/psapi/enumerating-all-processes
https://stackoverflow.com/questions/42589496/getting-a-list-of-all-open-windows-in-c-and-storing-them
Take care,
Robert Iakobashvili
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] How to get winid from qprocess id for QProcess
I think this question is better suited to the qt-interest mailing list.
It has been decades since I did Win32 programming, but I would assume that you could ask Windows to find the window for you and give you the HWND. I don't think you can map from process to HWND, you'd have to map HWND to process?
But my days of programming Win32 are long over. Thank you, Qt!
Sent: Thursday, February 20, 2020 at 9:36 AM
From: "Sujan Dasmahapatra"
To: development@qt-project.org
Subject: [Development] How to get winid from qprocess id for QProcess
hi friend
I am running an external app, which I want to fit onto my QScrollArea, for this I am writing code like this.
// launch weasis
QProcess *process = new QProcess();
process->start("./viewer-win32.exe");
if (process->waitForFinished())
{
return;
}
QWindow *window = QWindow::fromWinId(211812356);
window->setFlags(Qt::FramelessWindowHint);
_patient_gui->scrollArea_1->setWidget(QWidget::createWindowContainer(window));
But how can I get the wind id? it is hard coded here, is there any way to get the id from process id.
any help is highly appreciated.
___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
[Development] How to get winid from qprocess id for QProcess
hi friend
I am running an external app, which I want to fit onto my QScrollArea, for
this I am writing code like this.
// launch weasis
QProcess *process = new QProcess();
process->start("./viewer-win32.exe");
if (process->waitForFinished())
{
return;
}
QWindow *window = QWindow::fromWinId(211812356);
window->setFlags(Qt::FramelessWindowHint);
_patient_gui->scrollArea_1->setWidget(QWidget::createWindowContainer(window));
But how can I get the wind id? it is hard coded here, is there any way to
get the id from process id.
any help is highly appreciated.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
[Development] Commercial support for Coin and related infrastructure
Hello, Are there any options available for subject? I've tried to use official contacts page, but it forces use of corporate email, but my request has nothing to do with any commercial development. -- Regards, Konstantin ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Co-maintainer of QtNetwork
Hi Jack, > Can someone remove me from this list please Yes - you can. Every mail to it ends in this footer: > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development The last line's link has a form on it that you can use to unsubscribe. Do you know how you came to be subscribed ? If someone else subscribed you without your knowledge, you should have been sent a confirmation e-mail; if you've been added to the list without you clicking on a link in that e-mail, we probably need to get our list admins to review how subscriptions are done ... Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
> -Original Message- > From: Development On Behalf Of > Marc Mutz via Development > Sent: Saturday, February 15, 2020 3:24 PM > To: development@qt-project.org > Subject: [Development] A modest proposal: disable lower-case keywords > (emit, foreach, forever, signals, slots) by default > > Hi, > > C++20 will contain new classes with emit() member functions > (wg21.link/P0053). While that will only pose problems for users that include > the new header after (almost) any Qt header, this should serve > as a second shot across the bows (after namespace > boost::signals) that we should change something. > > To that effect, I'd like to propose that we switch the default for > QT_NO_KEYWORDS around. As a counter proposal that (I hope) would get broader consensus, I suggest to just do this for 'emit': QTBUG-82379 . This keyword always seemed a bit odd to me anyway, because it has no semantics that's ensured by the compiler. I understand the ratio behind it, and there's obviously tons of code that uses it. But if I have the choice between Q_EMIT somethingChanged(); and just somethingChanged(); I personally prefer the second. My 2 cents, Kai ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: more Jira states to track stages of the work on an issue
On Mon, 2020-02-17 at 09:13 +, Edward Welbourne wrote: >> We currently have an "In Progress" state. In practice when I work on an >> issue, I initially do the work, then put that up for review; the review >> phase takes up fragments of my time for a while, unlike the main work >> phase, which is closer to full-time. I have more control over (and a >> better ability to estimate) how long the actual work takes, while review >> (and subsequent integration) depends on factors outside my control, that >> are harder to estimate. Tobias Hunger (20 February 2020 10:00) replied: > If the review process does not ever result in a significant amount of > work (== no patch is ever rejected or significantly changed do to a > review process), then we should reevaluate the review process. If this > is indeed the case, then Gerrit has degenerated into a place to > discuss formatting -- something we could have clang-format take care > of automatically! > > If our review process is more than a formality then it might result in a > significant amount of work -- the patch can be rejected or you might end up > redoing significant parts of the code. In that case I do not see how you can > consider your original task done before the review is complete. > > In both cases, IMHO having a separate state in JIRA provides very limited > benefit. I'm not suggesting or claiming either of those things, nor are they any part of the case I'm making for having a separate state in Jira. I'm better able to estimate how long I'll take to do the work before review than to estimate the time it'll take for that work to get through review; but, usually, the amount of *my* time that'll be taken up by the work during review is small compared to the amount of work I do before sending it for review. So, when it comes to planning my work and communicating what I'm doing and when I expect it to be done, there is a vast difference between the work I do before review and the work I do in review. * Before review: more or less full-time work, taking relatively predictable large amounts of my time over a relatively predictable calendar duration. * In review: sporadic work, usually cumulatively smaller than the previous, happens reactively, I can only guess roughly how much of my time that'll take before reviewers tell me what to fix and I don't know how much calendar delay it'll involve. Distinguishing these two phases of the work is useful to me, it's useful to management and product management, it's potentially useful to others. Users affected by what I'm fixing may also benefit from being alerted to the start of review, if they're in a position to apply my patch and gain its benefits right away (albeit with some risk that, hopefully, review serves to reduce). > The code review process is meant to improve code quality. If this benefits is > outweighted by reduced productivity due to the review overhead, then we should > re-examine the topic of code review, not work around the issue in JIRA. > > We did introduce the code review process we use today in Nokia when we were a > much different organization. Maybe we need to adjust our processes to the > environment we work in nowadays? That's a whole other question and, if you believe either of the concerns you described above is in fact a real issue, I encourage you to start a separate thread, giving your reasons for believing our code review process costs us more than it gains us. I don't believe that, but if you do then we need to discuss it and perhaps change our process, which might indeed make my proposal redundant, Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Co-maintainer of QtNetwork
Can someone remove me from this list please Sent from my iPhone > On 20 Feb 2020, at 13:00, Konstantin Tokarev wrote: > > > > 20.02.2020, 08:48, "Timur Pocheptsov" : >> Hi all, >> >> I want to propose a colleague of mine, Mårten Nordheim, as a co-maintainer >> of QtNetwork module with him >> becoming the maintainer of „High-Level network access (HTTP)"* (which >> essentially means QNetworkAccessManager >> and related classes/code, sub-module 'access' etc.) component and me >> continuing as the maintainer of "Low-level >> access (Sockets, SSL, Hostname resolution, Bearer mgmt, etc)"**. Since the >> first day he joined the Qt Core >> and Network team several years ago, Mårten is making a significant >> contribution to the QtNetwork module, which >> includes numerous improvements and fixes in QNetworkAccessManager and also >> new developments (among other things >> he is the author of SChannel TLS backend on Windows). He has a good, solid >> knowledge of QtNetwork code/components >> and making him the maintainer "de jure" will help us (the Qt Core and >> Network team) to optimise and streamline the >> future developments in QtNetwork module. >> >> Best regards, >>Timur. >> >> * and ** - these are names taken from our wiki page on the Qt maintainers. > > +1 > > > -- > Regards, > Konstantin > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: more Jira states to track stages of the work on an issue
On 17/02/2020 10:13, Edward Welbourne wrote: >> We currently have an "In Progress" state. In practice when I work on >> an issue, I initially do the work, then put that up for review; the >> review phase takes up fragments of my time for a while, unlike the >> main work phase, which is closer to full-time. I have more control >> over (and a better ability to estimate) how long the actual work >> takes, while review (and subsequent integration) depends on factors >> outside my control, that are harder to estimate. >> >> (Sometimes, under the present branching model, I also have to put >> work on hold until other work merges up for me to rebase it onto. >> However, that complication shall go away soon, so I'll ignore it.) >> >> When my team is planning sprints, our scrum master wants to know what >> tasks I'll be working on, and what counts as "Done" for each of them. >> Having a separate state for "In Review", distinct from "In Progress", >> would let us distinguish the relatively plannable, and intense, part >> of the work from the part that (often happens in a later sprint, and) >> takes up a smaller proportion of my time but may take longer. Oliver Wolff (20 February 2020 09:12) > I have never worked in scrum, but what difference does it make there? > The task is not done, as long as it is not in the done state. If the > review takes to long, give people from your scrum team more time for > review. If the major hassle is CI, we would need an "Integrating" > state to see how bad our CI is. But in the end your task is not > done. Isn't that what your scrum master (and other stakeholders) are > interested in? It's a fair point: however, a strict adherence to each work item in the sprint being a whole Jira Task would mean that many of the tasks I aim to get done for Qt 6 can't be attempted, because they won't fit into a single sprint. A major reworking of a complex body of code can sometimes be fitted into a fortnight, but getting the review (and integration) done in the same fortnight is unlikely (especially at present, when I'm doing some parts of the work on 5.15 or earlier and having to wait for them to merge up to dev before I can continue with the work that's only for Qt 6). So the only way to make the Definition of Done be that the Jira task is closed is to artificially make lots of sub-tasks, that ask for code to be written and sent for review and are Done when that happens, regardless of whether it's been reviewed or integrated. This would mean creating artificial sub-tasks where really they'd be better represented by just one task that has an extra transition. I should note that we're not dogmatically following scrum; we're only lifting methods and approaches from it, to see what works for our work and the ways it can progress. >> So I'd like to modify our Jira work-flows to include a distinct "In >> Review" state for when I've completed the main work and am either >> waiting for review or responding to reviewers' comments. Of course, if >> those comments prompt me to go back and start over, I'll also want to be >> able to go back to the "In Progress" state from it. >> >> Does anyone have any objection to this, or suggestions for a better way >> to handle the relevant work-flow transition ? If not, I'm hoping Alex >> can work out how to implement what I want ... > I am afraid that this will just lead to more mails sent by JIRA. I do > not see a clear benefit, as (as said before) the task is not done. Being > in review and in integration does not need any new state, because it > does not give useful additional information. I believe this *is* useful additional information, though: code has been written, or reworked, and I've tested it to at least my satisfaction. The remaining work to be done - and there typically shall be some - is the work that arises in response to review. > If I am bored and want to do reviews, I can just go to codereview and > will find more than enough open patches that are waiting for reviews. > There is no need to take a detour via JIRA for that. On the other hand, if you could search Jira for it, you'd be able to take into account the priority of the issue the reviewed change resolves; you could prioritise review in response to the significance of the bugs being fixed. Equally, you could search by component or any of the other ways that Jira distinguishes tasks. So, while you can surely find things to review in Gerrit, Jira would be able to give you better ways to refine your search. Albeit this is only a secondary win, rather than the initial point of the exercise. > All in all I am with Andre' here. It looks like this is just for the > sake of following some process. To some degree it is indeed for the sake of following a process: on the other hand, that process has its value and can be made more effective if the tools we use - notably Jira in this case - help us to make clear what work is at what stage in the process. Process is important: good
Re: [Development] Co-maintainer of QtNetwork
20.02.2020, 08:48, "Timur Pocheptsov" : > Hi all, > > I want to propose a colleague of mine, Mårten Nordheim, as a co-maintainer of > QtNetwork module with him > becoming the maintainer of „High-Level network access (HTTP)"* (which > essentially means QNetworkAccessManager > and related classes/code, sub-module 'access' etc.) component and me > continuing as the maintainer of "Low-level > access (Sockets, SSL, Hostname resolution, Bearer mgmt, etc)"**. Since the > first day he joined the Qt Core > and Network team several years ago, Mårten is making a significant > contribution to the QtNetwork module, which > includes numerous improvements and fixes in QNetworkAccessManager and also > new developments (among other things > he is the author of SChannel TLS backend on Windows). He has a good, solid > knowledge of QtNetwork code/components > and making him the maintainer "de jure" will help us (the Qt Core and Network > team) to optimise and streamline the > future developments in QtNetwork module. > > Best regards, > Timur. > > * and ** - these are names taken from our wiki page on the Qt maintainers. +1 -- Regards, Konstantin ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Patch workflow in qt5 supermodule (provisioning)
Hello, In the light of recent changes, should provisioning patches be merged to dev first now and then cherry-picked, or previous workflow remains? -- Regards, Konstantin ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Co-maintainer of QtNetwork
On 20/2/20 3:46 PM, Timur Pocheptsov wrote: >> I want to propose a colleague of mine, Mårten Nordheim, as a >> co-maintainer of QtNetwork module with him becoming the maintainer of >> „High-Level network access (HTTP)"* (which essentially means >> QNetworkAccessManager and related classes/code, sub-module 'access' >> etc.) component and me continuing as the maintainer of "Low-level >> access (Sockets, SSL, Hostname resolution, Bearer mgmt, etc)"**. Lorn Potter (20 February 2020 07:28) replied: > +1 and a +1 from me, too. (Full disclosure: also in TQtC's C team, with Mårten and Timur.) Eddy. Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: more Jira states to track stages of the work on an issue
TL;DR: I struggle to find any substance in André's objections. Meanwhile, I'd really like to hear from folk more familiar with Jira: * Would a new state actually make it possible to show a useful distinction, on Jira's scrum boards, between tasks in progress and those in review ? Or is Jira's scrum board too tied to "In Progress" for a new state to be any help at all ? * If that *is* viable, would a tag suffice to achieve the same effect ? A clear answer from a Jira expert on either of those would be more interesting than the present discussion. There are other uses for the "In Review" distinction, but my current purpose in proposing it is as a way to make Jira's scrum boards more useful. On Wed, Feb 19, 2020 at 09:45:48AM +, Edward Welbourne wrote: >> I very much doubt the distinction between In Progress and In Review is >> going to involve much bike-shedding. André Pönitz (19 February 2020 22:34) > *shrug* > > Assuming that JIRA states are meant to be disjoint and that the names > actually bear some meaning, "In Review" would mean "Not in Progress". That's silly. Does "In Progress" mean "No longer Accepted" ? Does "Accepted" means "No longer Reported" ? I doubt anyone is so silly as to read it that way. Nor would any read "In Review" as "Not in Progress". > Which already would be an interesting message to the reviewer. Like, > "whatever you do here, that's not considered 'Progress'". > > Of course, nobody intents to bui^H^H^Hsend such message, and that's > easily solvable, by either dropping the connection between state names > and meaning, or by dopping the disjointness of states. > > What do you prefer? That folk not wilfully misinterpret state names for the sake of vacuous rhetorical grand-standing. Already now there are tasks that get prioritized, and assigned, and re-prioritized, re-assigned, "Fix-for-version"-ed, closed, re-opened several times. Watchers that e.g. wait for a "Done" there get notified each time on such unprogressing transitions, and skipping these sums up to quite a bit of unproductive time already now. >>> >>> True enough; this would introduce one more transition, so one more >>> e-mail per bug. None the less, it's a transition that does mean >>> something useful to those watching - especially those waiting for a fix >>> - we are a significant step closer to a fix, > Is is? > > First, being on review might still not mean getting closer to 'Done'. > Patches get rejected or delayed for real or imagined reasons, nobody > might actually review, a successful review might not be convincing > enough for CI to let it pass etc, etc. The fact that sometimes we think we've fixed a bug but later have to re-open it doesn't persuade anyone - unless perhaps you - that we shouldn't have a Closed state. Likewise, the fact that sometimes we do a bunch of work in an attempt to fix something, but it all come to nothing, doesn't mean it's useless to have the In Progress state - even if the progress we thought we were making proved vain, it was meaningful to say we were trying to solve the problem. In the same way, when we think we've solved the problem, it's meaningful to make that clear, even if we haven't yet got past review and integration, which might throw us back to having to hack on the code some more. > Second, water-level reports on how close something is to being done > is practically never the reason why I watch tasks, I watch them > because I may need to act once it is resolved. And only then. Jira does not exist only for you, or indeed only for developers. It facilitates communication between all stakeholders. It serves purposes for some stakeholders that are of no value to others; and the resulting e-mails that matter to some are thus a cost to those who don't find those messages interesting. What matters is whether, on balance, it provides a net benefit. >>> and there's a patch they might even be interested in applying >>> locally. And, as Lorn pointed out, issues don't have to go through >>> every stage; it'd just be there for the benefit of those who find it >>> useful. > And to the distraction to those that don't. That's why the 'Verified' > state was removed not that long ago. Presumably we concluded that the benefit of the state didn't outweigh the cost. The reason I've started this discussion is that I believe an In Review state would outweigh its cost. You clearly disagree, although the reasons you give for disagreeing don't sound at all persuasive to me; they sound more like wilful curmudgeonliness, thus far: raising objections that would apply just as robustly to the basic "Reported -> Fixed" work-flow that a minimal bug-tracker would have. Is a Fixed bug no longer Reported ? Of course not, it's both Reported and Fixed. Is it pointless to have a Fixed state just because sometimes we re-open bugs ? Of course not, it's better to claim it's fixed when we think it is, and admit our error when it turns out we were
Re: [Development] Proposal: more Jira states to track stages of the work on an issue
> On 20 Feb 2020, at 00:08, André Pönitz wrote: > On Wed, Feb 19, 2020 at 10:43:17AM +, Volker Hilsheimer wrote: >> Even when doing development (as opposed to the pointy-haired work), I >> benefit from having tools that help me to maintain a work-in-progress >> limit, that allow me to see what state the work someone else is doing >> is in (because I might depend on it or just be curios about it), or >> allow me to signal to customers waiting for the fix that they might >> want to have a look at a proposed change, even if they don't have an >> account on Gerrit. > > *Customers*, *without an Account*, to *look* at changes on Gerrit? > > Sometimes I really regret having dropped out of university before > finishing basic maths. Don’t worry, you don’t need to know about the really big numbers for that one :P >> The Qt Project defines “code review” as an explicit step that >> contributions have to go through. > > Correct. > >> Given that it takes a substantial amount of time to get things >> through review, > > A review, even a *proper review* by *your standards*, does not have > to "take substantial amounts of time". > > It's technically completely feasible (and I guess one could dig out > practically examples) where an issue goes from "Someone mentioned > a problem on IRC" to "Fix is integrated" in less then five minutes. Yes, and this proposal doesn’t affect that kind of work. Just as JIRA doesn’t affect this kind of work. > The undeniable fact that it actually *does* take a substantial amount > of time *in a lot of cases* is not the result of having "not enough > JIRA states" but actually that of a lot of causes, none of which that > I am aware are of of the sort that would benefit from changes to the > JIRA process. In this case, the proposal is not about “making work get done faster”, but “making work more visible”. This is valuable, for some people, and not only pointy haired ones. >> I think it would make the JIRA-model of how work happens a bit more >> useful if it would reflect the way that work actually happens. > > That's an interesting puzzle to solve when "the way that work actually > happens" is actually "outside JIRA, for a reason" > > And that happens to be rather normal when e.g. > - the issue is not coming via JIRA, like normal reviews, If there is no JIRA ticket, then we don’t have to worry about how many states a non-existent JIRA ticket could be in. > - the issue is urgent so JIRA would be too slow to use, Ditto. I don’t experience this to be the case, to be honest. > - the issue is small, so the overhead would be prohibitive >compared to the cost of the actual work. > - the issue is big, so wind direction would change to often >before this is done. Contributors that don’t use JIRA today because they don’t want to plan their work this way, don’t need to coordinate their work with other members in the team, are not subject to customers' or customer representatives’ inquiries, or always only work on stuff from your list can ignore this discussion. FWIW, I personally much prefer reviewing changes where I can look up the description of the problem that the change is trying to solve. Sometimes the commit message is good enough, but often the discussion of the problem in JIRA is very helpful. And from my experience, it seems that a lot of discussions happening during code review would have been good to have before code was written. JIRA is a good place for this. Volker ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: more Jira states to track stages of the work on an issue
On Mon, 2020-02-17 at 09:13 +, Edward Welbourne wrote: > We currently have an "In Progress" state. In practice when I work on an > issue, I initially do the work, then put that up for review; the review > phase takes up fragments of my time for a while, unlike the main work > phase, which is closer to full-time. I have more control over (and a > better ability to estimate) how long the actual work takes, while review > (and subsequent integration) depends on factors outside my control, that > are harder to estimate. If the review process does not ever result in a significant amount of work (== no patch is ever rejected or significantly changed do to a review process), then we should reevaluate the review process. If this is indeed the case, then Gerrit has degenerated into a place to discuss formatting -- something we could have clang-format take care of automatically! If our review process is more than a formality then it might result in a significant amount of work -- the patch can be rejected or you might end up redoing significant parts of the code. In that case I do not see how you can consider your original task done before the review is complete. In both cases, IMHO having a separate state in JIRA provides very limited benefit. The code review process is meant to improve code quality. If this benefits is outweighted by reduced productivity due to the review overhead, then we should re-examine the topic of code review, not work around the issue in JIRA. We did introduce the code review process we use today in Nokia when we were a much different organization. Maybe we need to adjust our processes to the environment we work in nowadays? Best Regards, Tobias ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Co-maintainer of QtNetwork
+1 El jue., 20 feb. 2020 a las 8:18, Alex Blasche () escribió: > +1 > > -- > Alex > > > From: Development on behalf of Timur > Pocheptsov > Sent: Thursday, 20 February 2020 06:48 > To: qt-dev > Subject: [Development] Co-maintainer of QtNetwork > > Hi all, > > I want to propose a colleague of mine, Mårten Nordheim, as a co-maintainer > of QtNetwork module with him > becoming the maintainer of „High-Level network access (HTTP)"* (which > essentially means QNetworkAccessManager > and related classes/code, sub-module 'access' etc.) component and me > continuing as the maintainer of "Low-level > access (Sockets, SSL, Hostname resolution, Bearer mgmt, etc)"**. Since the > first day he joined the Qt Core > and Network team several years ago, Mårten is making a significant > contribution to the QtNetwork module, which > includes numerous improvements and fixes in QNetworkAccessManager and also > new developments (among other things > he is the author of SChannel TLS backend on Windows). He has a good, solid > knowledge of QtNetwork code/components > and making him the maintainer "de jure" will help us (the Qt Core and > Network team) to optimise and streamline the > future developments in QtNetwork module. > > Best regards, >Timur. > > * and ** - these are names taken from our wiki page on the Qt maintainers. > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QtLocation / QtPositioning and Web Assembly
On donderdag 20 februari 2020 03:01:19 CET Lorn Potter wrote: > On 19/2/20 6:49 PM, Sebastian Kügler wrote: > > I'd like to create an application using the MapView QtQuick plugin and > > deploy that application using the Web Assembly platform. It seems, > > though, that the QtPositioning and QtLocation modules are not (yet?) > > available for WASM. > > > > - Did anybody already get it to work? > > Most likely not yet. > > > - Is this planned by anybody? > > It has been in the back of my mind for some time now, but I just created > a JIRA task if you want to comment, or vote for it. > > https://bugreports.qt.io/browse/QTBUG-82358 > > > - What would be the steps / likely time investment, etc. to be able to use > > these modules in a WASM-deployed application? > > The hard part would be implementing the positioning backend using > javascript API, which is quite limited in comparison to other sources. > It lacks satellite info for one. So at least it would not take all that > much work to get basic functionality. On par for the serialnmea plugin. Thanks Lorn, we'll digest your info. :) Are there any example how the positioning backend JS API would be implemented? -- sebas http://www.kde.org | http://vizZzion.org ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: more Jira states to track stages of the work on an issue
Hi, On 17/02/2020 10:13, Edward Welbourne wrote: > Hi all, > > We currently have an "In Progress" state. In practice when I work on an > issue, I initially do the work, then put that up for review; the review > phase takes up fragments of my time for a while, unlike the main work > phase, which is closer to full-time. I have more control over (and a > better ability to estimate) how long the actual work takes, while review > (and subsequent integration) depends on factors outside my control, that > are harder to estimate. > > (Sometimes, under the present branching model, I also have to put work > on hold until other work merges up for me to rebase it onto. However, > that complication shall go away soon, so I'll ignore it.) > > When my team is planning sprints, our scrum master wants to know what > tasks I'll be working on, and what counts as "Done" for each of them. > Having a separate state for "In Review", distinct from "In Progress", > would let us distinguish the relatively plannable, and intense, part of > the work from the part that (often happens in a later sprint, and) > takes up a smaller proportion of my time but may take longer. I have never worked in scrum, but what difference does it make there? The task is not done, as long as it is not in the done state. If the review takes to long, give people from your scrum team more time for review. If the major hassle is CI, we would need an "Integrating" state to see how bad our CI is. But in the end your task is not done. Isn't that what your scrum master (and other stakeholders) are interested in? > > So I'd like to modify our Jira work-flows to include a distinct "In > Review" state for when I've completed the main work and am either > waiting for review or responding to reviewers' comments. Of course, if > those comments prompt me to go back and start over, I'll also want to be > able to go back to the "In Progress" state from it. > > Does anyone have any objection to this, or suggestions for a better way > to handle the relevant work-flow transition ? If not, I'm hoping Alex > can work out how to implement what I want ... I am afraid that this will just lead to more mails sent by JIRA. I do not see a clear benefit, as (as said before) the task is not done. Being in review and in integration does not need any new state, because it does not give useful additional information. If I am bored and want to do reviews, I can just go to codereview and will find more than enough open patches that are waiting for reviews. There is no need to take a detour via JIRA for that. All in all I am with Andre' here. It looks like this is just for the sake of following some process. If reviews and integrations take too long actions should be taken to fix that, but adding another JIRA task as a dumping ground will not help anyone. BR, Olli > > Eddy. > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
