> > Still a pretty unusual setup. Doesn't your Linux have X? > unfortunatelly I dont have/cannot add X on my setup, that's why I'm cross-debugging...
> Anyway, there is nothing wrong with that per se, but maybe > try to > understand that the focus is on more common or even > "normal" setups. And > I'd go so far and call Windows->Linux crosscompilation > and debugging > "normal" even if it's not well supported right now. > the pontential is right there I thing qt-creator should consider this scenario. There are applications out there doing exactly the same thing as a VisualStudio Add-on; (WinGdb) it is a pay app + you cannot use the VS express versions. > > Cross-debugging Android is another very > > interesting scenario for qt-creator.... > > [And maybe already even supported by Bogdan's port? I > haven't seen > it in real life so far, though.] > I haven't seen it either. > > You are abusing the tool. Start and Attach to Remote > Application was > meant for "Let's have a quick look on what does this app on > that > device", without the need to have a proper project. By > deciding to > not use projects and sessions you are depriving yourself of > the > possibility to use project information to start the > debugger. > I think this does not make much sense; when you start a remote application, you allways need: the debugger, the local app binary, the sysroot, the "sources", etc, etc. A bunch of info for every start, Can't you see that that info should come from a project file? that dialog box has 7 fields and the missing current directory gives 8, there's nothing quick about a test that requieres a dialog box with 8 fields in order to run... > > > > 3) qt-creator does not save the breakpoints > to the project file, > > > > it would be very handy saving them, if not I > have to reset > > > > breakpoints every time I start a new > debugging session.... > > > > > > Breakpoints are saved in the session. See > > > > > > http://doc.qt.nokia.com/qtcreator-snapshot/creator-project-managing-sessions.html > > > in my humble opinion I think the "sesion" file should > be the project > > file itself, here Visual Studio does a good job. Why > to split the > > project data on a project file and a "sesion" file > independently > > handled??? I don't know, am I missing some point > here? > > Breakpoint data is not "project data". > > > The project file is meant to be shared with colleagues and > to > be put into revision control systems. That's not the place > where > _your_ breakpoints should go. Still you'd like to persist > them for > your own convenience. That's what the sessions are for. > well, I respectfully disagree... if I have to share a project file I can (if I really want) strip breakpoints in just one command... >From an OO point of view I think IDE development should be project file >centered, the main "object" when I work on my IDE is the project entity and I >expect when I load/save my project, all the info related to my interaction >with the object "myProjectXXX" be stored "within" the "object".... Splitting >the concept of project and session on an IDE app does not sound as good design >to me. A session "object" is a good concept for an app like Putty, where the main object is really a terminal emulation "session" thanks Pat _______________________________________________ Qt-creator mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt-creator
