Bug 339142

Summary:	Usability suggestions and questions
Product:	[Developer tools] kdevplatform	Reporter:	RJVB <rjvbertin>
Component:	general	Assignee:	kdevelop-bugs-null
Status:	RESOLVED NOT A BUG
Severity:	wishlist
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	Other
OS:	Other
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description RJVB 2014-09-17 11:56:53 UTC

I've been coming to appreciate KDevelop, but there are a few usability issues that could see improvement:

- KDevelop settings (configuration) are (is) a mixed bag of global parameters and session-specific ones. It beats me for instance why the default project directory or coding style would only exist as per-setting parameters. I can see how one could want to override them on even a project level, but it'd be very nice if there were a way to configure these and other settings for all newly created sessions.

- Editor windows. I must be part of a very small minority that prefers an IDE where each file is opened for editing in its own standalone window (as well as the other UI elements). Maybe the consensus is that such an environment wouldn't be an IDE but an EDE :)? Anyway, I've noticed that e.g. the documentation window can already be popped out (at least when it's docked to the side; the button is missing from the bottom dock position!). Why not extend this to edit windows?

- Concerning that documentation window: when popped out, it doesn't get a full window status, but instead becomes floating. At least on OS X that makes it a top-level window that cannot be hidden by e.g. an editor window, making it less useful to pop it out. Also, it disappears when another application is made active, meaning one cannot do side-by-side comparisons between the info shown in the doc window and in a web browser, for instance. Is it technically possible to pop out to a full-featured window?

- Code parsing. I found traces of support for ObjC and ObjC++, but this was apparently removed a few versions ago. That's a serious drawback on OS X, where one is likely to encounter these C and C++ dialects (e.g. in Qt source code). Wouldn't it be possible to treat .m as .c files, and .mm files as .cpp, without attempting to parse the ObjC specifics? That would be really helpful for the ObjC++ files one is likely to encounter in Qt/KDE contexts (= mostly C++ with some inline ObjC thrown in).

If any of the above suggestions/questions can be addressed (in the kde4-legacy branch!) by someone who's not a seasoned Qt/KDE dev (nor a highly expert C++ dev), I'd be happy to get some pointers and start tweaking!

Reproducible: Always

Steps to Reproduce:
NA

Actual Results:
- most settings are session-specific without a possibility to define global defaults
- tabbed editor "windows" that cannot be made standalone
- popped-out doc. window is floating atop all other windows and is hidden when another app gets focus
- renaming a file to .m or .mm means it no longer gets parsed and the quick navigation menu is disabled

Expected Results:
- settings can have global defaults that apply to all new sessions/projects
- file editors (and other UI elements like the documentation toolview) can be in full-featured standalone windows
- ObjC(++) files could at least be parsed as if they were C(++).

Comment 1 Kevin Funk 2014-09-17 13:08:48 UTC

Would be better if you'd created separate bugs for each of the issues.

Anyway: Regarding ObjC/ObjC++ support: That won't come back in kde4-legacy. If at all, that's something where kdev-clang would come in handy, because LLVM obviously also supports those dialects (more info here: http://kfunk.org/2014/08/17/randa-report-hacking-on-kde-and-meeting-friends/. Again, I would love someone giving a hand here, because I can focus on that in the near future)

Comment 2 Milian Wolff 2014-09-17 13:25:00 UTC

Note that the kde4 legacy branch is dead. No work will be done there at all. Only the 1.7/4.7 branches will see work, and that only for bugfixes.

If you want to change features, behavior, usability, layout, ... you'll have to work on master, i.e. KF5/Qt5 version of KDevelop.

Comment 3 RJVB 2014-09-17 15:00:56 UTC

It's been said often enough the last few weeks: KF5 is still a long way off from being ready for regular use on OS X. Until that time, KDE4 is not dead on that platform, and I won't be touching KF5/Qt5. It also means that bug reports and fixes coming from OS X users will concern KDE4 (I'm thinking that will be true also for a majority of Debian users ...)

I'm not expecting anyone not on OS X to do any real work on legacy code, but I think it's not too much to ask for pointers, suggestions, feedback ... any of the things one could expect from a community that identifies itself as such and is not about to leave people who are locked-in to older versions figure out everything by themselves.

Regarding my question concerning ObjC(++): please have another look. I wasn't asking for real language support. I would just like to know how/where I can get the current (non-Clang) parser to treat the language as regular C(++), which should be as simple as accepting a few more extensions as C/C++ (instead of as a not-yet-supported language). I already know it doesn't (necessarily) crash if I rename a .mm file to .cpp . And projects that require a real ObjC parser, I'll be doing those in Xcode anyway...

Last time I tried it, kdev-clang still built against git/kde4-legacy . As long as that's the case I'd love to help out (as far as possible, from what I've seen it's far from the easiest project to deep-dive into ... ).

Comment 4 Kevin Funk 2015-11-29 15:29:48 UTC

Report is too vague; unspecific.

Please report separate issues and/or start a discussion on the mailing list.