Re: [Qt-creator] margin
On Thu, 28 Oct 2010 08:08 -0500, Ryan May ryan@eecradar.com wrote: On 10/28/2010 01:21 AM, Max Waterman wrote: Anyway, now I have lost hope of convincing anyone that there can be a better way of improving QtCreator than relying on customers to file bugs. It seems I'm just annoying people, so I'll stop now. What's annoying is that you've spent more time arguing your point on the mailing list than it would have taken to just report the issue. All while complaining that you don't have the time to report the issue. Well, I can understand your point, and I'm sorry that it is annoying, but from my point of view, I see that : a) I decided that filing the bug was not worth my time. It's my responsibility to judge what is and is not worth my time, and of course this varies depending on my current work load and other factors. Perhaps I could have worded it better - something like I'm too busy right now; perhaps later. b) While I might decide that it is not worth spending my time to file a bug, I can also decide that it *is* worth my time trying to convince people that it is worth changing the system so that bugs *are* filed even if some people, for whatever reason, don't file them themselves. Some bugs are a minor annoyance for a individuals and each individual might not consider it worth their time to file bugs, or even post an email, but I would consider that all their minor annoyances *together* make it still worth fixing. It seems other people think that if a bug isn't filed, then the bug isn't worth fixing (irrespective of why the bug isn't filed). c) I saw an opportunity for improving the situation and ensure that issues like this don't go unreported. d) 5 minutes for filing a bug?? yeah, right...I have just had cause to attempt to file a different bug, which I do consider worth my time[1] ...it has taken over an hour already, for one reason or another. Sure, it might be due to exceptional circumstances (I'm not sure), but somehow there seem to be many such exceptional cicrumstances, and over time, one learns just not to bother. [1] No dialog to enter a password for git, requiring the password to be embedded in the URL. It took me 10-15 minutes to to search existing bugs. The system frequently gave me error pages - something about a proxy but I don't think it's my local proxy since the error page was given by the the qt bugreport server. Finally, after typing in my explaination of the problem with nice step-by-step instructions for the specific git repository I am trying to use (on forum.nokia.com, if anyone's interested), it timed out and I lost all the text I entered. I should have done it in a text editor first - which is something I'm starting to learn to do because of just this sort of thing :/ So, another issue goes unreported...unless I remember to try again sometime. Perhaps, while coming from a commercial standpoint having customers report bugs is a little odd, Perhaps a little, but not really. Qt Creator is more of an open source project. As such, having *users* (not customers) report bugs is the norm. Sure. I would say it is also pretty common for customers to not file them, even if they see them - more common, actually. Max. ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator
Re: [Qt-creator] Changes in Maemo Packaging Integration
On 10/29/2010 06:02 AM, ext Jeffery MacEachern wrote: I've been running from Master snapshots of Qt Creator since shortly after 2.0 came out, and I've seen the Maemo packaging functionality go through several iterations in terms of generated code in the project files, and the actual packaging files (i.e. the debian directory). I realize that this is what I get for using unstable software, but I wanted to ask: Once 2.1 is released, are these behaviours likely to change in the future? I would assume that they will at least be stable within a major release, but any rearrangements of this sort makes maintenance somewhat frustrating. The packaging support in 2.0, like other Maemo features, was put together quickly to make simple projects work, but it obviously wasn't a proper solution, as it didn't allow users to influence the packaging process in any way. So obviously, that had to change completely. The main difference in 2.1 is the introduction of a debian directory with the usual set of files to the project, and I think the only major change during the lifetime of the 2.1 branch was the location of that directory. In fact, one of the main reasons for moving it out of the project root and into a dedicated packaging directory was to be able to support other packaging schemes in future versions without breaking compatibility for Fremantle projects created with 2.1, so that change should actually make maintenance *less* frustrating in the long term. Christian ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator
Re: [Qt-creator] Changes in Maemo Packaging Integration
On Fri, Oct 29, 2010 at 00:29, Christian Kandeler christian.kande...@nokia.com wrote: On 10/29/2010 06:02 AM, ext Jeffery MacEachern wrote: I've been running from Master snapshots of Qt Creator since shortly after 2.0 came out, and I've seen the Maemo packaging functionality go through several iterations in terms of generated code in the project files, and the actual packaging files (i.e. the debian directory). I realize that this is what I get for using unstable software, but I wanted to ask: Once 2.1 is released, are these behaviours likely to change in the future? I would assume that they will at least be stable within a major release, but any rearrangements of this sort makes maintenance somewhat frustrating. The packaging support in 2.0, like other Maemo features, was put together quickly to make simple projects work, but it obviously wasn't a proper solution, as it didn't allow users to influence the packaging process in any way. So I surmised. It's nice to see it coming together now, though. Thanks, Trolls! So obviously, that had to change completely. The main difference in 2.1 is the introduction of a debian directory with the usual set of files to the project, and I think the only major change during the lifetime of the 2.1 branch was the location of that directory. In fact, one of the main reasons for moving it out of the project root and into a dedicated packaging directory was to be able to support other packaging schemes in future versions without breaking compatibility for Fremantle projects created with 2.1, so that change should actually make maintenance *less* frustrating in the long term. That would explain the latest changes, and makes perfect sense to me. My initial problems were just due to assuming that the structure earlier on was going to stay fixed, and having to change around things that I had committed. Thanks for the explanation. - Jeffery MacEachern Christian ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator
[Qt-creator] Maemo Packaging QMake VERSION variable
I just tried today's Qt Creator snapshot build, after not having used Qt Creator in a few weeks, and noticed that the Maemo packaging step didn't pick up the VERSION variable from the project file (instead defaulting to 0.0.1). I seem to remember it doing this correctly before, but I'm not certain; can anyone sanity check me on that before I file a regression bug? Thanks, - Jeffery MacEachern ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator
Re: [Qt-creator] Maemo Packaging QMake VERSION variable
On Fri, Oct 29, 2010 at 01:10, Christian Kandeler christian.kande...@nokia.com wrote: On 10/29/2010 09:45 AM, ext Jeffery MacEachern wrote: I just tried today's Qt Creator snapshot build, after not having used Qt Creator in a few weeks, and noticed that the Maemo packaging step didn't pick up the VERSION variable from the project file (instead defaulting to 0.0.1). I seem to remember it doing this correctly before, but I'm not certain; can anyone sanity check me on that before I file a regression bug? We do not evaluate the VERSION variable for the package version (and never have). The problem is that you can have several applications and/or libraries in a project (with potentially different VERSIONs), but only one package will be built. But even with only a single pro file, consider the scenario of a user setting different version strings in debian/changelog (which is where the Debian packaging tools get their version information) and the project file - now what? Do we synchronize them? But then which source takes precedence? Right, I see what you mean. I must have been mistaken, but I wanted to be sure. Thanks, - Jeffery MacEachern Christian ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator
Re: [Qt-creator] dictionary (non-contextual) completion
If I were to implement something like that (not saying I would, I don't have the foggiest where to start on the Creator internals) I would tie dictionary completion to a keystroke so it would (1) be accessible even on something that DOES have contextual completion, and (2) wouldn't use up cycles coming up with a dictionary unless I wanted it. /s/ Adam On Fri, Oct 29, 2010 at 1:43 PM, Cristian Tibirna tibi...@kde.org wrote: Hello Was it ever discussed among the developers of QtCreator, the utility of introducing dictionary completion, as an augmentation to the contextual completion available today? daydreaming What I have in mind is offering vim- (and (X)Emacs- and Kate-) like completion that disregards the context and just returns a list of valid words as found in the current document (or current open documents) in order of proximity. This would be useful in situations when the contextual completion doesn't offer any variant (like inside template class methods). Also, it should only be offered as a last recourse, and never when contextual completion offers at least one variant. I could see also that this kind of completion would be marked differently in the UI (e.g. with a red background). /daydreaming -- Cristian Tibirna KDE developer .. tibi...@kde.org .. http://www.kde.org ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator ___ Qt-creator mailing list Qt-creator@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-creator
