Bug 189630

This works. Please have a look at this over 1 year old video:

http://www.youtube.com/watch?v=ZpqcpOW6m18

Or did I misunderstand you?

No, you're right. I was talking about this kind of feature.

But there's something I still don't understand. When I draw a molecule with Kalzium molecular editor (version 2.2.1 on Pardus 2008.2 / KDE 4.2.2), I can add new atoms and new bonds with a left click on my mouse, delete atoms and bonds with a right click and zoom on the molecule with the central button. But I'm not able to do rotations as you do in the video. Or, in better words, I don't see how you do this.

Could you, please, explain me ?

Best regards,

Linuxcomics

Well, I click on the black area, press the left mouse button and move the mouse.

As you might know the 3D editor is based on Avogadro. Could you try Avogadro as well?

   http://avogadro.openmolecules.net/wiki/Main_Page

We are trying to fix final issues for version 1.0 which is the one Kalzium of KDE 4.4 will be based on. Your tests would be very welcome!

1 - When I click on the black area with the left button, a new atom appear on the screen. A move of the mouse create a bond between a second atom and the first one. But the molecule doesn't move at all. It's very strange ....

2 - Indeed, I have notice that the 3D editor is based on Avogadro. But I encountered problems with its installation on Pardus 2008.2. 
Pisi package of OpenBabel is currently for version 2.2.0 (even in Pardus 2008 test repository). So I update to version 2.2.1 in order to install Avogadro 0.9.3. It works fine but, unfortunately, it's not the same thing for Avogadro installation. I already do a bug report on Avogadro bug tracking system and I also plan to do some tests on Mandriva in order to see if I have the same kind of problem.

3 - It would be a great pleasure for me to help improve Kalzium. I am not a programmer but I can look at Kalzium from a teacher point of view.

Best regards,

Linuxcomics.

This functionality was the first to be implemented. In KDE 4.0 Kalzium had a molecular viewer that could navigate around the molecule. The editing functionality came later in KDE 4.1. You need to have the display tab selected to be able to navigate around the molecule, when the edit tab is selected you are in edit mode. Perhaps this is a documentation issue that we should try to address before the 4.3 freeze?

It certainly works. Tested on Gentoo using OpenBabel 2.2.1, KDE 4.2.2. Also at home using KDE trunk and OpenBabel 2.2.1 (still Gentoo) it works and has all the enhancements from the latest 0.9 series in the Avogadro library.

Well, I have find the answer so I can say it is not a documentation issue.

But, first of all, I have to thank you, Marcus, because you give me an idea that help me to find the answer.

I'm a French KDE user and so, I use Kalzium in French. When doing this, I encountered the problem reported earlier : I'm not able to navigate in space and to do rotations.

To be sure of what Marcus means by "display tab", I change settings in order to launch Kalzium in English. When doing this, the molecular editor works fine. Indeed, when I select the display tab, I obtain two yellow arrows that allow me to change my point of view of the molecule.

So the next question is : is this problem related to KDE or do you think that this bug is specific to Pardus ?

This could be a localization bug. I was just looking at the code to change modes. Now these strings are not user visible, but the tool names were getting localized. I will dig into this, but I think we fixed this recently. So now we have a unique name which is not localized, and a user visible name and description which is localized.

void MoleculeDialog::setViewEdit(int mode)
{
    if (mode == 0) ui.glWidget->toolGroup()->setActiveTool("Navigate");
    else if (mode == 1) {
      ui.glWidget->toolGroup()->setActiveTool("Draw");
      ui.glWidget->toolGroup()->activeTool()->readSettings(*m_drawSettings);
    }
    else if (mode == 2) ui.glWidget->toolGroup()->setActiveTool("Measure");
}

This is in the tools/moleculeview.cpp file in Kalzium's source. I would need to install some alternate languages here to confirm this, but I suspect this is the source of the problem.

I did the same test on Mandriva 2009.1 RC2 and I obtained the same results. It doesn't work when Kalzium is used in French while everything works fine when I choose English.

Yes, I think this is a localization issue. I need to do some testing, but I think this is fixed in KDE 4.3/trunk due to it being fixed at a more fundamental level in the Avogadro library. I am not sure what the best way to fix it in KDE 4.2 is, can I wrap the strings, i.e. i18n("Navigate"), or would that require translation and introduce new strings? I am not sure how clever i18n is about recognizing identical strings.

You could try replacing the lines I reference above with,

void MoleculeDialog::setViewEdit(int mode)
{
    if (mode == 0) ui.glWidget->toolGroup()->setActiveTool(i18n("Navigate"));
    else if (mode == 1) {
      ui.glWidget->toolGroup()->setActiveTool(i18n("Draw"));
      ui.glWidget->toolGroup()->activeTool()->readSettings(*m_drawSettings);
    }
    else if (mode == 2)
      ui.glWidget->toolGroup()->setActiveTool(i18n("Measure"));
}

Does Kalzium (version 4.2) work with these modifications ?

Best regards,

Linuxcomics.

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

This bug has had its resolution changed, but accidentally has been left in NEEDSINFO status. I am thus closing this bug and setting the status as RESOLVED to reflect the resolution change.