This is about dock for vibrations. I think it’ll be reasonable to show it if molecule has vibration data and hide otherwise. But I didn’t manage to do it using hide() of dockWidget, returned by extension. What should I do?
Regards,
Konstantin
This is about dock for vibrations. I think it’ll be reasonable to show it if molecule has vibration data and hide otherwise. But I didn’t manage to do it using hide() of dockWidget, returned by extension. What should I do?
That should work. I’d make sure the code is being called. If it’s called, but the dock widget doesn’t hide(), try close() – not what you want, but at least you’ll be able to work out the bug.
If you’re still having problems, let me know and I’ll grab your code from GitHub and try it myself.
Cheers,
-Geoff
On Feb 11, 2010, at 4:53 AM, Konstantin Tokarev wrote:
Thanks, almost everything works fine with close(). However, if dock was opened before closing Avogadro, it’s opened next time before loading of any molecule. I’ve added qDebug() << “hide it!” and “show it!” in places, where I manage dock, and on startup “hide it!” appears, but dock isn’t hided
Qt tries to help with hiding/showing dock windows automatically. I believe that happens when handling the “polish” event, where we adjust other interface elements in MainWindow.
Also, I don’t understand how to set up correct stretching behaviour for dock elements (e.g, width must follow width of dock, list must expand on all free space). It seems to me different from behaviour in dialog. I’ve tried with or without layout, but without results. File is ‘vibrationwidget.ui’
I’m afraid I can’t help – this seems like a Qt question we should ask in at a place like QtCentre or labs.trolltech.com.
Hope that helps,
-Geoff
Thanks, almost everything works fine with close(). However, if dock was opened before closing Avogadro, it’s opened next time before loading of any molecule. I’ve added qDebug() << “hide it!” and “show it!” in places, where I manage dock, and on startup “hide it!” appears, but dock isn’t hided
Qt tries to help with hiding/showing dock windows automatically. I believe that happens when handling the “polish” event, where we adjust other interface elements in MainWindow.
That’s really annoing. Can’t it be tricked in core? E.g. add property “needHideOnStartup” or so, and hide all docks with this property==true after UI adjustment of MainWindow
Also, I don’t understand how to set up correct stretching behaviour for dock elements (e.g, width must follow width of dock, list must expand on all free space). It seems to me different from behaviour in dialog. I’ve tried with or without layout, but without results. File is ‘vibrationwidget.ui’
I’ve figured it out - I tried to return my widget drawn in ui file as dock, but right way is to create new dockWidget and use setWidget() on it. In this case VBoxLayout in widget works properly (in first case it collapses).
The dock widget has a set of preferences for where it will appear
I can use setAllowedAreas, but this doesn’t influence where dock appears for the first time, because in mainwidow.cpp there is
addDockWidget(Qt::RightDockWidgetArea, dockWidget);
I think plugins should have additional member like defaultDockArea() to be used in mainwindow
–
Regards,
Konstantin
On Feb 15, 2010, at 4:44 AM, Konstantin Tokarev wrote:
Qt tries to help with hiding/showing dock windows automatically. I believe that happens when handling the “polish” event, where we adjust other interface elements in MainWindow.
That’s really annoing. Can’t it be tricked in core? E.g. add property “needHideOnStartup” or so, and hide all docks with this property==true after UI adjustment of MainWindow
I don’t know. My suggestion is to post either to StackOverflow.com or QtCenter.org forums and ask for help.
I can use setAllowedAreas, but this doesn’t influence where dock appears for the first time, because in mainwidow.cpp there is
addDockWidget(Qt::RightDockWidgetArea, dockWidget);
Then let’s change this behavior and remove the line from mainwindow.cpp. Instead of adding a new virtual method, we can just tell extensions to run setAllowedAreas themselves.
Sound OK?
-Geoff
On Feb 19, 2010, at 4:31 PM, Konstantin Tokarev wrote:
Then let’s change this behavior and remove the line from mainwindow.cpp. Instead of adding a new virtual method, we can just tell extensions to run setAllowedAreas themselves.
Sound OK?Not entirely. If setAllowedAreas is set to one place, move by user will be impossible; if several places, dock will appear where Qt wants. To give maximum flexibility, I propose Extension::prefferredDockArea to return default place for dock; if author of extension wants, he also can run setAllowedAreas to restrict possible places
The problem is that we’ve then broken binary compatibility by adding a new virtual function to our extensions. We need to think if there’s a better way to do this.
-Geoff
The problem is that we’ve then broken binary compatibility by adding a new virtual function to our extensions. We need to think if there’s a better way to do this.
Do you mean pure virtual (=0)? But it may be non-pure. Not every extension is forced to override Extension::dockWidget(), because it’s defined as
QDockWidget * Extension::dockWidget()
{
return 0;
}
We could do something like this
Regards,
Konstantin
On Friday 19 February 2010 16:59:16 Konstantin Tokarev wrote:
The problem is that we’ve then broken binary compatibility by adding a
new virtual function to our extensions. We need to think if there’s a
better way to do this.Do you mean pure virtual (=0)? But it may be non-pure. Not every extension
is forced to override Extension::dockWidget(), because it’s defined as
QDockWidget * Extension::dockWidget()
{
return 0;
}
We could do something like this
Adding a new virtual method to a class will break the ABI.
http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B
and,
http://techbase.kde.org/Policies/Binary_Compatibility_Examples#Add_new_virtuals_to_a_non-
leaf_class
Could we add a property that is queried possibly?
Marcus
19.02.10, 17:18, “Marcus D. Hanwell” :
On Friday 19 February 2010 16:59:16 Konstantin Tokarev wrote:
The problem is that we’ve then broken binary compatibility by adding a
new virtual function to our extensions. We need to think if there’s a
better way to do this.Do you mean pure virtual (=0)? But it may be non-pure. Not every extension
is forced to override Extension::dockWidget(), because it’s defined as
QDockWidget * Extension::dockWidget()
{
return 0;
}
We could do something like this
Adding a new virtual method to a class will break the ABI.
Policies/Binary Compatibility Issues With C++ - KDE TechBase
and,
Policies/Binary Compatibility Examples - KDE TechBase
leaf_class
Could we add a property that is queried possibly?
- Is preserving of ABI so important for Avogadro? API will be preserved, so recompilation is enough for all extensions. I don’t know that there are some closed-source extensions for Avogadro, I believe there aren’t any. AFAIK, Kalzium uses its own version of libavogadro, not upstream
- Is preserving of ABI so important for unstable version of Avogadro?
–
Regards,
Konstantin
On Saturday 20 February 2010 05:01:32 Konstantin Tokarev wrote:
19.02.10, 17:18, “Marcus D. Hanwell” :
On Friday 19 February 2010 16:59:16 Konstantin Tokarev wrote:
The problem is that we’ve then broken binary compatibility by adding
a new virtual function to our extensions. We need to think if
there’s a better way to do this.Do you mean pure virtual (=0)? But it may be non-pure. Not every
extension is forced to override Extension::dockWidget(), because it’s
defined as QDockWidget * Extension::dockWidget(){
return 0;}
We could do something like this
Adding a new virtual method to a class will break the ABI.
Policies/Binary Compatibility Issues With C++ - KDE TechBase
and,
Policies/Binary Compatibility Examples - KDE TechBase
rtuals_to_a_non- leaf_class
Could we add a property that is queried possibly?
- Is preserving of ABI so important for Avogadro? API will be preserved,
so recompilation is enough for all extensions. I don’t know that there are
some closed-source extensions for Avogadro, I believe there aren’t any.
AFAIK, Kalzium uses its own version of libavogadro, not upstream 2. Is
preserving of ABI so important for unstable version of Avogadro?
API and ABI stability was one of the major goals of the Avogadro 1.0
release, which we worked on for many years. In the 1.0 line we should never
break API compatibility, and should only break ABI if it is absolutely
necessary.
Kalzium is moving to use the system installed library, this was always a goal
and one thing holding it back was API/ABI stability. Think Linux packagers.
QUI is an out of Avogadro extension that I know of, and I think we should be
working to accommodate this model.
We can break ABI, but it should not be done lightly. In this case, to be
honest, I would rather add a property or a new extension class. Many
extensions are simply not affected by this, and it does not seem to warrant
breaking ABI. Kalzium should depend on Avogadro 1.0+, if packagers need to
rebuild against 1.2 then that would be a real shame.
Marcus
In this case, to be
honest, I would rather add a property or a new extension class.
Maybe extensions with dialogs and docks should be inherited from different classes (e.g., DialogExtension and DockExtension)? Dock extension doesn’t need all stuff related to actions, functions with empty bodies look unnatural, and dialog extension don’t need to inherit dockWidget()
To presere API, Extension class could be inherited from both of them
–
Regards,
Konstantin
On Saturday 20 February 2010 10:30:33 Konstantin Tokarev wrote:
In this case, to be
honest, I would rather add a property or a new extension class.Maybe extensions with dialogs and docks should be inherited from different
classes (e.g., DialogExtension and DockExtension)? Dock extension doesn’t
need all stuff related to actions, functions with empty bodies look
unnatural, and dialog extension don’t need to inherit dockWidget()To presere API, Extension class could be inherited from both of them
That sounds reasonable, although I think to minimize porting effort I would
just create a DockExtension that inherits from Extension. Then keep the
current extension doing what it was mainly designed and tested for - dialog
based extensions. This could be documented in the headers - DockExtension
becomes a further specialization of Extension, and API/ABI are preserved (no
problem in adding a new class, even inheriting from the old ones).
This seems like the most reasonable course of action to me. Thoughts from
anyone else about this? I think we can break ABI, but it should not be done
lightly. In my opinion creating a more specialized plugin type that dock
extensions derive from is preferable in this instance at least. I have done a
lot of packaging for Gentoo Linux, and breaking ABI in minor releases is a
major headache for source and binary distros. It means all applications
using that library have to be locked to minor versions, rebuilt and bumped at
the same time. If we want Avogadro to be a useful and easy to use library we
should be doing our best to preserve both API and ABI.
Marcus
20.02.10, 12:10, “Marcus D. Hanwell” :
On Saturday 20 February 2010 10:30:33 Konstantin Tokarev wrote:
In this case, to be
honest, I would rather add a property or a new extension class.Maybe extensions with dialogs and docks should be inherited from different
classes (e.g., DialogExtension and DockExtension)? Dock extension doesn’t
need all stuff related to actions, functions with empty bodies look
unnatural, and dialog extension don’t need to inherit dockWidget()To presere API, Extension class could be inherited from both of them
That sounds reasonable, although I think to minimize porting effort I would
just create a DockExtension that inherits from Extension. Then keep the
current extension doing what it was mainly designed and tested for - dialog
based extensions. This could be documented in the headers - DockExtension
becomes a further specialization of Extension, and API/ABI are preserved (no
problem in adding a new class, even inheriting from the old ones).
If DockExtension doesn’t need actions, it’s illogical to inherit pure virtual functions related to actions
This seems like the most reasonable course of action to me. Thoughts from
anyone else about this? I think we can break ABI, but it should not be done
lightly.
IMHO, Avogadro is not so ready for production to be so worried about ABI 
Moreover, it’s not Java, and recompilation is inevitable in many situations (e.g., update of Qt in distribution)
In my opinion creating a more specialized plugin type that dock
extensions derive from is preferable in this instance at least. I have done a
lot of packaging for Gentoo Linux, and breaking ABI in minor releases is a
major headache for source and binary distros.
Distros often include outdated version of Avogadro or doesn’t include at all (only in 3rd party repositories)
It means all applications
using that library have to be locked to minor versions, rebuilt and bumped at
the same time.
Do you think there are lots of them right now?
If we want Avogadro to be a useful and easy to use library we
should be doing our best to preserve both API and ABI.
If we will not make reasonable changes to ABI/API now, we will face horrible problems with refactoring some years later
–
Regards,
Konstantin
P.S. Who is admin of the list? Do you need any help with setting “Explicit Reply-To: header” in Maiman Admin?
On Saturday 20 February 2010 12:30:31 Konstantin Tokarev wrote:
20.02.10, 12:10, “Marcus D. Hanwell” :
On Saturday 20 February 2010 10:30:33 Konstantin Tokarev wrote:
In this case, to be
honest, I would rather add a property or a new extension class.Maybe extensions with dialogs and docks should be inherited from
different classes (e.g., DialogExtension and DockExtension)? Dock
extension doesn’t need all stuff related to actions, functions with
empty bodies look unnatural, and dialog extension don’t need to
inherit dockWidget()To presere API, Extension class could be inherited from both of them
That sounds reasonable, although I think to minimize porting effort I
would just create a DockExtension that inherits from Extension. Then
keep the current extension doing what it was mainly designed and tested
for - dialog based extensions. This could be documented in the headers -
DockExtension becomes a further specialization of Extension, and API/ABI
are preserved (no problem in adding a new class, even inheriting from
the old ones).If DockExtension doesn’t need actions, it’s illogical to inherit pure
virtual functions related to actions
Then make a new extension class that doesn’t inherit from it.
This seems like the most reasonable course of action to me. Thoughts from
anyone else about this? I think we can break ABI, but it should not be
done lightly.IMHO, Avogadro is not so ready for production to be so worried about ABI
Moreover, it’s not Java, and recompilation is inevitable in many
situations (e.g., update of Qt in distribution)
I disagree. Qt does guarantee API/ABI stability (as does kdelibs), and so
recompilation is not necessarily required. Very pleased it is not Java, but I
disagree with your premise that we should give up ABI stability.
In my opinion creating a more specialized plugin type that dock
extensions derive from is preferable in this instance at least. I have
done a lot of packaging for Gentoo Linux, and breaking ABI in minor
releases is a major headache for source and binary distros.Distros often include outdated version of Avogadro or doesn’t include at
all (only in 3rd party repositories)
I am not sure what point you are making here. It is being included in more and
more places, shouldn’t we try to make a high quality, stable library that is
easy to package?
It means all applications
using that library have to be locked to minor versions, rebuilt and
bumped at the same time.Do you think there are lots of them right now?
No, does that mean we should not try?
If we want Avogadro to be a useful and easy to use library we
should be doing our best to preserve both API and ABI.If we will not make reasonable changes to ABI/API now, we will face
horrible problems with refactoring some years later
I am all for making reasonable changes when necessary. I think you are too
willing to break ABI. After having worked on Avogadro for several years, and
worrying about these issues. I never wanted to rule out ABI breaks, but making
them every minor revision would IMHO be a poor development philosophy.
In this case you can simply make a new DockExtension class, derive from
Plugin. What is wrong with doing that and preserving the ABI as well? As a
community we decided ABI stability was important, and a milestone of 1.0. As a
dependency of Kalzium we made promised to provide an ABI stable library for
use in KDE. I think we should do our best to honor that promise.
Marcus
I have done a
lot of packaging for Gentoo Linux, and breaking ABI in minor releases is a
major headache for source and binary distros.
Out of curiosity, why ABI is meaningful for Gentoo where everything is built from source? Isn’t API stability enough?
AFAIK, some Gentoo users make world with every GCC minor release
It means all applications
using that library have to be locked to minor versions, rebuilt and bumped at
the same time.
AFAIK, for binary distributions always rebuild and bump software versions for release. Gentoo is always in move, and software versions are controlled by user
–
Regards,
Konstantin
On Saturday 20 February 2010 16:46:00 Konstantin Tokarev wrote:
I have done a
lot of packaging for Gentoo Linux, and breaking ABI in minor releases is
a major headache for source and binary distros.Out of curiosity, why ABI is meaningful for Gentoo where everything is
built from source? Isn’t API stability enough? AFAIK, some Gentoo users
make world with every GCC minor release
They are not the norm… Say you have a library that is used by ten
applications. You upgrade the library, and they silently broke their binary
interface. The next time you come to run any of those applications they crash
on startup (normally). Then a revdep-rebuild is required to figure out which
applictions need to be rebuilt.
In binary distros this is usually worse. Package Kalzium 4.5.0, then the
Avogadro lib is bumped, breaks ABI, no one notices… User comes to start up
Kalzium and it segfaults everytime they open it. This is why Qt and KDE work
so hard to maintain a stable ABI. It is true that they can (and often do)
rebuild everything. As more and more libraries break ABI the problem explodes.
It means all applications
using that library have to be locked to minor versions, rebuilt and
bumped at the same time.AFAIK, for binary distributions always rebuild and bump software versions
for release. Gentoo is always in move, and software versions are
controlled by user
What about Arch Linux? Rolling binary distro. Say your library gets very
popular, and then forces a full rebuild. I work and talk to a lot of packagers
who still feel that binary stability is necessary. That said, a balanced
approach is required where ABI is broken if it is really needed. It should not
be done lightly IMHO. KDE has a policy of not depending on libs that do not
maintain stable ABI, or at least bump their SO version if they break ABI.
Avogadro is one of many libraries that might be on a system. The easier we
make it to package the more likely packagers are to bump it and keep up with
our releases. Trust me, I ignored badly behaved upstreams when they became
time sinks…
I agree that API stability is the most important, but I think that ABI
stability is important. We did a lot of work ensuring our classes had d-
pointers etc to allow this. It is still very much possible to add new
functionality, you just need to be a little more careful about it. Qt and KDE
libs grow with each new release.
Marcus
26.02.10, 16:51, “Konstantin Tokarev” annulen@yandex.ru:
Qt tries to help with hiding/showing dock windows automatically. I believe that happens when handling the “polish” event, where we adjust other interface elements in MainWindow.
That’s really annoing. Can’t it be tricked in core? E.g. add property “needHideOnStartup” or so, and hide all docks with this property==true after UI adjustment of MainWindow
I don’t know. My suggestion is to post either to StackOverflow.com or QtCenter.org forums and ask for help.
I’ve found string in code which causes problems:
mainwindow.cpp: 2783 (in function readSettings())
if(!ba.isEmpty())
{
restoreState(ba); // here all old docks are opened
}
I’ve called readSettings() before loadExtensions(), and everything works fine now
Hm, not everything if fine. Custom placement of DockWidget is not reproduced after its opening
–
Regards,
Konstantin
Great news! Thanks for your debugging.
-Geoff
On Feb 26, 2010, at 7:33 AM, Konstantin Tokarev wrote:
Qt tries to help with hiding/showing dock windows automatically. I believe that happens when handling the “polish” event, where we adjust other interface elements in MainWindow.
…
I’ve found string in code which causes problems:
mainwindow.cpp: 2783 (in function readSettings())
if(!ba.isEmpty())
{
restoreState(ba); // here all old docks are opened
}I’ve called readSettings() before loadExtensions(), and everything works fine now
Regards,
Konstantin