I'm using gtkmm to build a UI. The task I'm trying to accomplish is constructing a radio button from an action that is already part of a menu and a toolbar. I'd like the new button to proxy for the existing action.
One likely candidate is Gtk::Action::create_tool_item(). Its documentation states:
Deprecated: 3.10: Use a Gtk::ToolItem and associate it with a Action using Gtk::Actionable::set_action_name() instead
So, I'd expect that ToolItem and by inheritance RadioToolButton would implment this interface. In gtkmm-3.12 it does not and the stable documentation reflects this as well.
However, the C library gtk-3.0 RadioToolButton does implement this interface. So, my question is this.
Should gtkmm Gtk::RadioToolButton implement Gtk::Actionable? Is the absence of this int erface an oversight, or is there another way that the features of Actionable are supported?
There is a function, set_related_action() which associates the correct icon for the radio button. It doesn't seem to put the button into the group and it is also deprecated.
I had the same question. This is certainly not documented as clearly as it could be. But I found a thread on the mailing list (perhaps also yours!) from a few months after this one, which answers both of your main questions, and I think it's worth posting for future people following the same path.
To summarise:
Is the absence of this int erface an oversight
Of course not: it was a deliberate decision, for an extremely important reason.
or is there another way that the features of Actionable are supported?
Thankfully, yes.
The thread is here - https://mail.gnome.org/archives/gtkmm-list/2014-December/msg00002.html - and this is the official response from a primary maintainer:
However, the gtkmm version, Gtk::Button does not inherit from
Gtk::Actionable. Therefore the functionality is not available. There
is a TODO in button.h:
//TODO: Derive from (and implement) Actionable when we can break ABI.
What does that mean? I thought that gtk3 and gtkmm3 were kept in sync,
i.e. gtkmm3-3.14 would be feature-complete regarding gkt3-3.14? Is
this functionality going to be implemented (when)?
[snip]
We can't add a base class to a C++ class without breaking ABI - that
generally means causing all applications that currently use that ABI
to crash. Obviously we don't want to do that. It can be done when we
do a parallel install such as when we went from gtkmm-2.4 to
gtkmm-3.0, which did not affect currently installed applications.
You can do this in the meantime:
gtk_actionable_set_action_name(theButton.gobj(), "somename");
See:
https://developer.gnome.org/gtkmm-tutorial/stable/sec-basics-gobj-and-wrap.html.en
-- Murray Cumming
Note: that first argument needs to be GTK_ACTIONABLE( theButton.gobj() ). GLib-style objects are opaque pointers only. A C++ compiler can't implicitly convert between such forward-declared C structs (even if they contain each other as 'base classes'). Besides, because here we must cast from an 'object' (GtkButton) to an 'interface' (GtkActionable), an implicit cast wouldn't work: the interface can be located anywhere within its parent object, so the address must be adjusted during the cast. The GTK_BLAH() macros cover this.
Anyway, I digress... gtkmm 4 can break ABI with impunity, and GTK+ 4 development has begun, so the Actionable interface is now implemented by GtkButton. All or most other such TODOs requiring ABI breaks should now be resolved, too. If you find something that was missing in gtkmm 3 and has not yet been added to 4, then please submit a bug report to get it sorted.
Related
In VS Code, with the C++ extension, is there any way I can get the parameter names for functions to be filled out automatically after e.g. selecting a function name suggested by intellisense? The parameters should then be filled out as if they were a snippet. This feature is common in several IDEs, such as Eclipse.
I think this is a perfectly valid question and nothing to do with IDE-like features as some are suggesting in the comments.
Short answer is No.
VS Code's C/C++ extension will not expand the autocompletion feature to the argument list of a function.
The more involved answer is that the authors of the C/C++ extension could do so but for some reason (probably a good one) have chosen not to.
The autocomplete feature is actually handled by the Language Server for C/C++. A Language Server is an implementation of the Language Server Protocol (LSP) which is simply a way to provide programming language-specific features for multiple code editors / IDEs.
The LSP, written by Microsoft originally for VSCode, absolutely permits such types of completion. After all, that is how snippets are handled. If you have a look at LSP's specification page you will see this bit
insertText is just a string so theoretically the server could pass the function name + argument list in the format of a snippet, set the variable InsertTextFormat == 2, marking it as a snippet and then pressing Tab would autocomplete to exactly what you want.
Here is an example of how it looks like (implemented in our Fortran language server)
You might want to open a feature request/ask the question in their repo. They will probably have a better answer as to why it is the way it is. If I had to guess I would say that it is related to overloading.
My company is considering the jump from Qt 4.8.4 to Qt 5.4, but I came across a change that could be a showstopper for us: QMetaType::unregisterType() is removed (http://doc.qt.io/qt-5/sourcebreaks.html).
Our GUI requires plug-ins to be loaded at runtime, with the same plug-in potentially loaded and unloaded more than once during a session of the GUI. In Qt 4, we ran into an issue where when the plug-in was loaded the second time, any signal/slot that used one of the custom types registered by the plug-in would cause access violations because the meta type had been registered by the first instance of the plug-in (which was now unloaded, so the memory space was invalid). We worked around this issue by defining our own macros to register and unregister meta types safely as the plug-in was loaded and unloaded.
With QMetaType::unregisterType() no longer present, I fear that this issue will come back with no real way to solve the problem. Upgrading to Qt 5.4 would be a significant investment to even get to the point that I could test this issue, so I'm hoping I can get some indication from the experts here.
Is there any way to unregister a meta type in Qt 5? If not, does Qt 5 now have some sort of system that can detect when the DLL is being unloaded and unregister the meta types itself (highly unlikely I'd assume)? Alternatively, if we switch to the new Qt 5 signal/slot syntax, does that absolve us of the need for meta types entirely? If so, does the new syntax still allow for queued connections? Please forgive my ignorance on the subject, but I don't see it explicitly listed as supported or not.
Please forgive my ignorance on the subject, but I don't see it explicitly listed as supported or not.
This is currently unsupported, which means that do not unload plugins with Qt 5 as of writing this. Usually, you do not load and unload plugins anyway, as it is done during the launch up in general. The corresponding change in the repository also claims:
The function hasn't been working properly. It was not well tested, for example it is undefined how QVariant should behave if it contains an instance of an unregistered type.
Concept of unregistering types was inspired by plug-in system, but in most supported platforms we do not unload plug-ins.
Idea of type unregistering may block optimizations in meta object system, because it would be not possible to cache a type id. QMetaType::type() could return different ids for the same name.
Thereby, even though you thought it was working, it was unreliable which means you could have observed difficult to find bugs in its operation, resulting unreliable software on your part. I am sure you do not want to release such a software, especially if it is not recommended by the Qt Project to be used.
Is there a good source of information on C++11 standard support in libc++? Its web site says 98% of the standard is supported but I'd like to know what features the other 2% are.
Something similar to this list for libstdc++ would be nice:
http://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2011
Edit: From Howard Hinnant's comment below:
The chart is outdated already. I should update it or take it down. The only thing unimplemented in libc++ right now is 20.7.2.5 shared_ptr atomic access [util.smartptr.shared.atomic]. And I hope to get that done this weekend. [atomics] is there now. Oh, quick_exit is missing. I'm going to let the C library implement that.
The most recent and detailed information is already linked from the front page (doesn't mean it is new enough ☺).
The only major missing piece of C++'0x support is <atomic>.
Here is a by-chapter breakdown of what is passing tests and what isn't.
We can see that 76% of <atomic>, 3% of "[language.support]" and 2% of "[utilities]" are missing.
I don't think there would be more updated/detailed break down like the libstdc++ one.
A frustrating side note on std::quick_exit() and std::at_quick_exit() functions. They are still unimplemented in macOS's libc even after several years. Also there is a possible vulnerability in the C++ standard, where it states you can safely call std::quick_exit() from a signal handler, but it doesn't state the functions that are registered by std::at_quick_exit() must also meet the same requirements a regular signal handler does. I believe that might be the reason behind why those functions are not implemented yet.
Lately as part of my day job I've been learning IBM Rhapsody and using it to generate code in C++ from the UML.
Yesterday it struck me that it might be cool to think about adding state machine support to my C++ compiler, so I jotted a few notes here: http://ellcc.org/wiki/index.php/State_machines_and_Active_Classes
My motivations for doing this are:
It seems like a cool idea.
The compiler could do much better semantic checking (with better error checking) than the current Rhapsody/normal C++ compiler.
There are many optimization possibilities available when the compiler itself understands the state machine structure.
I may try to extend my grammar to except something like the proposal to see how well it works.
What is your opinion of the proposal? Does it seem readable? Does it seem worthwhile?
Edit:
Thanks for the answers recommending specific libraries to do state machines, but that wasn't my question. I've implemented many state machines using both libraries and code that I've written.
I was really looking for ideas, criticism, etc. about the design of a state machine extension to a C++-like language, not whether this change would be appropriate for addition to standard C++. Think of it as a domain specific extension, where my my domain is real-time control applications.
I've started implementation of the extension in my compiler as described here: http://ellcc.org/wiki/index.php/State%5Fmachines%5Fand%5FActive%5FClasses
So far the concept hasn't had to change much going from proposal to implementation but there have been a few changes in details and I'm refining my understanding of the semantics of the problem.
Time will tell whether the whole concept has any value, however. ;-)
With a few exceptions, C++ has traditionally been extended using class libraries, not new keywords. State machines can easily be implemented using such libraries, so I don't think your proposal has much of a chance.
One problem I see in your proposal is the use of 'goto' to go to another state. What happens if I want to use goto in my own code within a state transition?
Excellent work developing what you've done. Something like you've done probably is possible, but I'm doubtful it would ever get into the C++. Most changes that make it into the language itself are included only to allow people to write more useful and powerful libraries.
There's a library here that provides support for state machines. I haven't tried it, but it might interest you, and you may be able to combine your ideas with a library like this to allow other people to make use of it.
http://www.boost.org/doc/libs/1_34_1/libs/statechart/doc/index.html
Or, you could develop your own extension as you suggest, and it would at least be useful for you. Microsoft implement some extension keywords, so there is no reason why you couldn't create your own extended version of C++.
Keep the new ideas coming.
You should take a look at how another smart developer added State machine support to a C-like language: UnrealScript Language Reference. See the section named "States".
UnrealScript supports states at the
language level. In UnrealScript, each
actor in the world is always in one
and only one state. Its state reflects
the action it wants to perform. For
example, moving brushes have several
states like "StandOpenTimed" and
"BumpOpenTimed". Pawns have several
states such as "Dying", "Attacking",
and "Wandering". In UnrealScript, you
can write functions and code which
exist in a particular state. These
functions are only called when the
actor is in that state
It's an interesting idea, but I think you'd actually have better luck creating your own domain-specific language for state machines than officially extending C++. C++ is designed as a very general-purpose programming language. I think Boost has proven that C++ is flexible enough that most features can be implemented nicely using libraries. It also evolves very slowly, to the extent that standard C++ still doesn't even have built-in threading support as of 2009, (it is planned in 0x). So it's unlikely the committee would consider this addition for some time.
Your solution does not look like it has any advantages to a template- or preprocessor-macro-based solution.
I am also not sure, how you can provide better semantic checking. And I doubt that you can apply many useful code optimizations.
However, to allow better optimizations and semantic checking, you should also replace "goto" with a new keyword (e.g. __change__ newState), and disallow goto for state changes! Allow goto for local jumps as usual.
Then the compiler can extract a list of possible transitions.
Read your proposal, have the following comments:
There's actually no keyword to declare and define an actual state machine! Do you assume a single global state machine (and thus a single global state)? How does that relate to __active__ ?
The closest comparable construct in C++ is actually the enum. Why not extend it?
There seems to be some connection between defined events and states, but I fail to see how it's implemented.
Why are threads and timers needed at all? Some use cases of state machines may benefit from them, but a good proposal should keep these seperate. Most importantly this should allow the use of standard C++0x threads.
Personally, I would extend the enum syntax:
enum Foo {
red, blue, green; /* Standard C++ so far - defines states. State list ends with a ; not a , */
Foo() { *this = red; } // Reuse ctor syntax, instead of __initial__
~Foo() { } // reuse dtor syntax, instead of __onexit__
void Bar() {/**/} // Defines an event, no return value. Doesn't need keyword __event__
};
It follows naturally that you can now declare your events in a header, and define them in a .cpp file. I don't even need to suggest the syntax here, any C++ programmer can guess that at this point. Add a bit of inheritance syntax for combined states:
enum DrawingObject : public Shape, public Color { /** } // allows (red && circle)
and you're pretty much at the point where your proposal is, without any new keywords, all by reusing an already familiar syntax.
Is there a way to identify unused attributes/methods in Visual C++ 2008 Professional? If it's not possible by default, recommendations of 3rd-party tools are also much appreciated.
Thanks,
Florian
Edit: nDepend only works for .NET assemblies. I'm looking for something that can be used with native C++ applications.
Try PC-Lint. It's pretty good at finding redundant code.
I haven't tried version 9 yet. Version 8 does take some time to configure.
Try the online interactive demo.
I have not personally used their productivity tools (I use their windows control suit), but it looks like DevExpress has a C++ refactor'er called Refactor! for C++. I didn't immediately spot the features that you are looking for, but maybe they have it?
Coverage Validator can show unused C++ code (but not attributes). It does it dynamically so you have to 'exersize' the app to get the results:
http://successfulsoftware.net/2008/03/10/coverage-validator/
The tricky bit is that many functions in C++ have to exist, even if they are not called.
Boost especially will cause this, but even the regular STL code can do this. And your code has to play along. You might define a copy ctor because std::vector formally requires it. But if you don't instantiate any std::vector member that actually does copy a T, your copy ctor will remain unused.
Even if they don't have to, they often exist for safety. For example, declaring a private copy constructor can prevent an object from unintended copying. Without the private declaration, the compiler would define a public, memberwise copy ctor for you. Now, is this "unused" and do you want to be warned about them?
PC-Lint is very powerful, but hard to lean. Of course that pretty well describes C and C++ doesn't it?
Another tool I think is excellent is Whole Tomato's Visual Assist X which integrates right into the IDE.
There are some big gotchas in C++ when searching for unreferenced code: templates, callbacks, and message handlers may be critical to your project but are never directly called. For example the handler for a thread is not called directly, but is a parameter when you create a new thread. The "On_buttonpress" type messages in MFC or WTL projects will also show up as un-called methods.
Once you find them you can configure PC-Lint to ignore these, but the first time through its a lot of work.
nDepend will do it, along with cleaning your house and taking the dog for a walk. There's a nagware version available for free.
The following code query language statement will get you a list of unused methods
WARN IF Count > 0 IN SELECT TOP 10 METHODS WHERE MethodCa == 0 AND
!IsPublic AND !IsEntryPoint AND !IsExplicitInterfaceImpl AND
!IsClassConstructor AND !IsFinalizer