Review Request 112231: Remove the area switching tabs
Sven Brauch
svenbrauch at gmx.de
Sun Aug 25 10:48:41 UTC 2013
> On Aug. 24, 2013, 7:51 a.m., Vlas Puhov wrote:
> > When in debug mode:
> > there is only two actions:
> > stop all jobs
> > back to code.
> >
> > What if I want to stop only the current debug job?
> >
> > When I choose "back to code" from debug mode how can I return to it afterwards??
> > I think in code mode should be a button like this: "back to debug". Or remove "back to code" action in the first place.
> >
> > Also notice, that disassemble/registers toolview not cleared after debug session ended, so it still keeps useful information. I think it'd be a great thing if we could have access to it too.
>
> Aleix Pol Gonzalez wrote:
> You can go to Run > Stop > job to stop.
>
> Either way, I don't really see how this relates... You'll keep having the same tools you used to have only that they'll be flow-based instead of explicit by the user.
>
> Vlas Puhov wrote:
> Yeah, I understand that tools'll stay the same. What I was trying to say is: When in debug mode if you want to stop something it probably the current debug launch not, let's say background parsing. So, IMO there should be the one and only button like: "stop current debug launch".
I'm not sure such a button is needed. I think the action the user wants to take is "I want to stop debugging", and that involves both stopping the job and going back to the Code tab. So why do we want to offer this as two seperate actions in our newly created UI which only provides like 2 buttons? It's ok that the actions exist seperately, somewhere, but it's clearly not the main worflow to have them separate.
- Sven
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/112231/#review38462
-----------------------------------------------------------
On Aug. 23, 2013, 11:06 p.m., Aleix Pol Gonzalez wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112231/
> -----------------------------------------------------------
>
> (Updated Aug. 23, 2013, 11:06 p.m.)
>
>
> Review request for KDevelop.
>
>
> Description
> -------
>
> The area switching tabs is something that has bothered me quite a bit recently. It's something that is always visible in the screen and we barely use it. There's very little point to explicitly changing to an area, we usually do it from an action: debug, show differences, etc. These are specified by a new Area::addAction(QAction*) method.
>
> This patch changes the current tab interface (inspired from Eclipse IIRC), for a button that tells the user what's the current area and where we can go.
>
> The patch also removes the tabs and some unneeded abstractions in sublime/mainwindow that where only used by the tabs.
>
>
> Diffs
> -----
>
> shell/CMakeLists.txt fe5cd9b
> shell/areadisplay.h PRE-CREATION
> shell/areadisplay.cpp PRE-CREATION
> shell/mainwindow.h 2050219
> shell/mainwindow.cpp d4f4bcb
> shell/projectcontroller.cpp 2186d90
> shell/runcontroller.cpp 4a5a5e4
> shell/uicontroller.cpp 2c0400f
> sublime/area.h 878c120
> sublime/area.cpp df29ce3
> sublime/mainwindow.h 96b9e71
> sublime/mainwindow.cpp f405200
> sublime/mainwindow_p.h 7885d06
> sublime/mainwindow_p.cpp 23c638d
>
> Diff: http://git.reviewboard.kde.org/r/112231/diff/
>
>
> Testing
> -------
>
> Been using it for a couple of days, seems safe.
>
>
> File Attachments
> ----------------
>
>
> http://git.reviewboard.kde.org/media/uploaded/files/2013/08/23/pairs-credits2.png
>
> http://git.reviewboard.kde.org/media/uploaded/files/2013/08/23/pairs-credits2_1.png
>
> http://git.reviewboard.kde.org/media/uploaded/files/2013/08/23/pairs-credits2_2.png
>
>
> Thanks,
>
> Aleix Pol Gonzalez
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20130825/2df2b10d/attachment-0001.html>
More information about the KDevelop-devel
mailing list