[umbrello] [Bug 358655] Umbrello does not import private class
https://bugs.kde.org/show_bug.cgi?id=358655 --- Comment #16 from Ken Standard --- I am kind of taken back by some of your comments. Why would you need a test case for valid, commonly used, generic GNU C++ syntax? It seems unnecessary, redundant, and easily recreated. I see that umbrello is not as Qt aware as I had first believed. Also strange, since KDevelop, Qt SDK Framework, and even Mono use project descriptor files. This should not have been a surprise. My notes on the comment 8 post here was not, as you describe, "irritation", rather fascination that such a simplistic approach is taken to what should be intuitive. And, yes, a more descriptive choice would have been clearer. I think there is also still a question for projects where headers are in separate folders from source code and where headers and code may be grouped in folders rather than in a flat directory structure with all files together. Maybe a "recursive" option on the file selection? Yes, the import wizard is definitely broken. I discovered the workaround you describe just after my bug post. Maybe now we can change the status from "unconfirmed" to "confirmed" "working" or something? -- You are receiving this mail because: You are watching all bug changes.
[umbrello] [Bug 358655] Umbrello does not import private class
https://bugs.kde.org/show_bug.cgi?id=358655 --- Comment #12 from Ken Standard --- OK, maybe we are having a language barrier - not sure. When talking about "project import" for a Qt project, you cannot ignore the .pro file - it is the project. Are we redefining "project" to mean only the .h,.hpp,/h++, etc. and the .cpp implementations in the "project"? Or are we accepting the "project" definition as is common to Qt and defined by the .pro file. Besides all that. When the actions described are performed and the entire project is imported correctly. It serves no purpose for me to post a bug if I have not performed every options to resolve the problem BEFORE submitting the bug. That should be obvious from comment 8. My point is that I should not have to do half of that. The project files should alreays be displayed according to the filter pattern, instead it must be modified first, then they are displayed. Secondly, folders are included in the selection process but that does not select the files underneath that match the selection pattern - not intuitive. Do one or the other but not both. Even when all the files in a folder are selected, the import to a class diagram is not always 100%. Sometimes files are not converted. I gave the example of a .cpp file where a "//" comment was detected as an error. This syntax is completely valid C++ comment style and should not error. When coverted to a "C" style comment (/* */) there is no error. This is not proper - both are correct. I submitted the bug because your procedure in comment 11 does not work - especially if headers and implementation files are in separate folders or if there are multiple sub-projects. I don't want to get too far afield here but my original bug is still valid and I think I have proven it. -- You are receiving this mail because: You are watching all bug changes.
[umbrello] [Bug 358655] Umbrello does not import private class
https://bugs.kde.org/show_bug.cgi?id=358655
--- Comment #8 from Ken Standard ---
OK, I will be "more specific".
Your #1: This will always be the case with PIMPL coding style. As I mentioned;
after removing the comments (lines with #) from the .pro
after removing the include(myfile.pri) line from the .pro
after modifying the filter patterns in the import Wizard
after selecting specific files in the files list
the private classes were imported properly appearing as private classes in the
logical view list of classes and with the forward declared items as a privately
declared class in the imported class.
Your #3: I made no mention of any other file having an include except for the
.pro. In that context I mentioned it reported as an error in the syntax. This
is not a proper response by the import wizard since it is completely valid for
Qt projects. Not only that, the # mark in the .pro file is also treated as an
error anywhere it appears. This also is not valid since it is the designated
comment mark for Qt project files. If a C++ comment ("//") appears in the code
it too is not ignored as it should be, but treated as a code error as well
being reported in the wizard import log as a syntax error. Interestingly, a "C"
style comment (/* */) does not render an error and IS ignored.
Comment 7: I find no dock window, list, or other window, named or titled
"Protocol". The import wizard has a "Logger" window and the main window has a
"Log" dock window. There is also no menu choice to view any "Protocol"
information.
--
You are receiving this mail because:
You are watching all bug changes.
[umbrello] [Bug 358655] Umbrello does not import private class
https://bugs.kde.org/show_bug.cgi?id=358655 --- Comment #5 from Ken Standard --- I have discovered an interesting phenomenon that affects this situation. If the .pro file contains either comments (lines with #) or an include(include.file) there is a log message that treats it as an error. Also, files are not displayed in the files list of the wizard - only folders - unless the list of filter patterns is modified. Clearing the include line and comments in the .pro and selecting the header files after modifying the filter patterns, the headers will import correctly. Very strange behavior. -- You are receiving this mail because: You are watching all bug changes.
[umbrello] [Bug 358655] Umbrello does not import private class
https://bugs.kde.org/show_bug.cgi?id=358655 --- Comment #4 from Ken Standard --- Not seeing it here. In fact the whole source import process is very rough and is not as intuitive as one would expect. I did not mention this before, to keep the issues separate. But whether you are importing a project or using the import wizard, many things are not imported. I only mentioned this one. Your super simple case may work for you, but a much more complicated multi-folder project is a different story altogether in my experience. The only case I have not tried is the header by header import (a giant pain in a large project) from the wizard. -- You are receiving this mail because: You are watching all bug changes.
[umbrello] [Bug 358655] New: Umbrello does not import private class
https://bugs.kde.org/show_bug.cgi?id=358655
Bug ID: 358655
Summary: Umbrello does not import private class
Product: umbrello
Version: 2.14.2 (KDE Applications 4.14.2)
Platform: Mint (Ubuntu based)
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: general
Assignee: umbrello-de...@kde.org
Reporter: ad...@arrl.net
In a Qt 5.5.1 project, a private class is defined. It is referenced as a data
type for a private variable pointer:
myheader.hpp
private:
class MyPrivateClass;
MyPrivateClass *d_data;
myimplementation.cpp
class MyImplementation::MyPrivateClass
{
. . .
}
only the *d_data variable from the header is imported and not the private class
from the .cpp file.
--
You are receiving this mail because:
You are watching all bug changes.
[umbrello] [Bug 358653] New: Umbrello crashed on close
https://bugs.kde.org/show_bug.cgi?id=358653 Bug ID: 358653 Summary: Umbrello crashed on close Product: umbrello Version: 2.14.2 (KDE Applications 4.14.2) Platform: Mint (Ubuntu based) OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: umbrello-de...@kde.org Reporter: ad...@arrl.net Application: umbrello (2.14.2) KDE Platform Version: 4.14.2 Qt Version: 4.8.6 Operating System: Linux 4.2.0-18-generic i686 Distribution: Linux Mint 17.3 Rosa -- Information about the crash: Diagram save and clicked on close to leave the app. -- Backtrace: Application: Umbrello UML Modeller (umbrello), signal: Segmentation fault Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1". [Current thread is 1 (Thread 0xb4fc8b00 (LWP 12070))] Thread 3 (Thread 0xad985b40 (LWP 12080)): #0 0xb77d8cb0 in ?? () #1 0x0021 in ?? () #2 0x000b in ?? () #3 0x0021 in ?? () #4 0x in ?? () Thread 2 (Thread 0xacf2db40 (LWP 12081)): #0 0xb77d8cb0 in ?? () #1 0xb5f6582b in ?? () from /usr/lib/i386-linux-gnu/libQtCore.so.4 #2 0xb5f658bd in ?? () from /usr/lib/i386-linux-gnu/libQtCore.so.4 #3 0xb532f9b3 in g_main_context_prepare () from /lib/i386-linux-gnu/libglib-2.0.so.0 #4 0xb53302df in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0 #5 0xb5330528 in g_main_context_iteration () from /lib/i386-linux-gnu/libglib-2.0.so.0 #6 0xb5f6595f in QEventDispatcherGlib::processEvents(QFlags) () from /usr/lib/i386-linux-gnu/libQtCore.so.4 #7 0xb5f34823 in QEventLoop::processEvents(QFlags) () from /usr/lib/i386-linux-gnu/libQtCore.so.4 #8 0xb5f34b49 in QEventLoop::exec(QFlags) () from /usr/lib/i386-linux-gnu/libQtCore.so.4 #9 0xb5e2123d in QThread::exec() () from /usr/lib/i386-linux-gnu/libQtCore.so.4 #10 0xb5f14c44 in ?? () from /usr/lib/i386-linux-gnu/libQtCore.so.4 #11 0xb5e23b6f in ?? () from /usr/lib/i386-linux-gnu/libQtCore.so.4 #12 0xb5456f70 in start_thread () from /lib/i386-linux-gnu/libpthread.so.0 #13 0xb5bcbbee in clone () from /lib/i386-linux-gnu/libc.so.6 Thread 1 (Thread 0xb4fc8b00 (LWP 12070)): #0 0xb77d8cb0 in ?? () #1 0x in ?? () -- You are receiving this mail because: You are watching all bug changes.
