[Qt-creator] ideas

[Danny Price]

I think a back-end implementation of virtual groups with a companion file is
doable. The harder part will be making the changes to the UI to make it
usable - the tree needs multiple selection, drag and drop support,
additional menus, to name a few. But even if we have to manually edit the
file (be it XML or whatever) it will be an improvement over the current
workarounds (subdirs, .pri files and filters).

Unfortutunately I cannot spare the time to do this any time soon (too many
projects!) but for an experianced Qt person, the back-end support could be
done a few hours.

Part of frustration is simply not knowing what Nokia is planning to do - the
Source/Header filter thing came as a surprise to me and rendered my existing
.pri file setup (which I had spent several hours laboriously setting up for
my projects) redundant.

I appreciate that this is an LGPL effort, but a little more transparency in
the development of Creator would help - everytime Qt Blogs post a Creator
entry, I see the same feature requests over and over, project hierarchies
among them.


On Wed, Oct 7, 2009 at 10:23 AM, André Pönitz <andre.poenitz at nokia.com>wrote:

> On Wednesday 07 October 2009 10:05:10 ext Matthias Pospiech wrote:
> > Andre Poenitz schrieb:
> > > On Tue, Oct 06, 2009 at 06:13:37PM +0100, Danny Price wrote:
> > >
> > >> The frustrating thing about this situation is that it seems relatively
> > >> simple to fix without compromising the locator system or changing any
> > >> QMake or Creator fundamentals - a second file containing file groups
> > >> is one solution.
> > >>
> > >
> > > *gosh*
> > >
> > > If it is that easy, why don't you simply implement it and submit a
> merge
> > > request? This would save time on both sides.
> >
> > This seams to be a discussion with frustrated people on both sides -
> > users and developers.
>
> Looks like it ;-}
>
> > I personally agree with Danny. Maybe it is not that simple, and I could
> > not implement a patch either, but if there was a single note from the
> > developer team that they are going to implement this and where it is
> placed
> > on the roadmap that could end the discussion and give people like me the
> > option to switch to qtcreator after this has been implemented.
>
> The situation is that the "internal" developer team has a list of things
> to work on. That includes stuff that's required internally as well as
> "stuff
> considered generally usable" as well as "personal itches that need to be
> scratched". This list is long, there are certain deadlines to meet, and in
> general available resources are scarcer than one might wish for.
>
> "Project tree improvements" is neither an internal requirement, nor do the
> "internal" developers generally consider it more usable than Ctrl-K, nor is
> it anybody's personal itch.
>
> As a consequence, it's unlikely that it will show up on a roadmap, and
> we need another means to end this discussion. The obvious choice
> would be an external contribution. After all, a few people seem to like,
> at least one thinks it's simple to implement. Why not work on it together?
>
> Andre'
>
> --
> We are hiring.
> _______________________________________________
> Qt-creator mailing list
> Qt-creator at trolltech.com
> http://lists.trolltech.com/mailman/listinfo/qt-creator
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt-project.org/pipermail/qt-creator-old/attachments/20091007/ba42dfe5/attachment.html