Roadmap to 1.0

Development
1

I actually think it’s worth discussing what will make a “1.0” release
for us.

In the near term, we’ve got a great 0.3 release shaping up. Marcus and
Donald have both put in some great work, and I think the new force
field work from Tim (largely in Open Babel) will impress people.

Personally, I’d like to see these before we declare a “1.0.”

  • Support for properties mapped onto van der Waals surfaces
  • Orbital surfaces
  • Simple animations (using OBMol conformers as frames)
  • Something like the GAMESS interface for MOPAC and/or Gaussian.
    (This makes sure we’re not seen as only for GAMESS.)
  • A real file format of our very own. (Or at least a set of extensions
    on top of CML.)

I think we also need to make a conscious effort to clean up the code,
document headers, and provide the best possible performance.

But we’re really, really close IMHO. What else should we include in
our “gotta have it” criteria for a 1.0 release?

-Geoff

2

One thing I would really like to see in the near future is support for
multiple molecules and conformers. Would it be possible to have the
following tree structure in the projectDock:

+Molecule (1)
++Atoms
+++Atom (1)
+++…
++Bonds
+++Bond (1, 2)
++Conformers
+++Conformer 1 (see note)
+++…
+Molecule (2)

note: could the energy of the molecule be displayed there?

By clicking a molecule or conformer, this would be shown in the 3D
widget. This is just a way I think we could support multiple
molecules/conformers, if you have better ideas, let me know. I’m
willing to spend some time on this if needed… (Need to get more
familiar with avogadro code anyway)

I’ll also try to cleanup/update code, comments and documentation for my code.

Tim

On Dec 3, 2007 6:51 PM, Geoffrey Hutchison geoffh+@pitt.edu wrote:

I actually think it’s worth discussing what will make a “1.0” release
for us.

In the near term, we’ve got a great 0.3 release shaping up. Marcus and
Donald have both put in some great work, and I think the new force
field work from Tim (largely in Open Babel) will impress people.

Personally, I’d like to see these before we declare a “1.0.”

  • Support for properties mapped onto van der Waals surfaces
  • Orbital surfaces
  • Simple animations (using OBMol conformers as frames)
  • Something like the GAMESS interface for MOPAC and/or Gaussian.
    (This makes sure we’re not seen as only for GAMESS.)
  • A real file format of our very own. (Or at least a set of extensions
    on top of CML.)

I think we also need to make a conscious effort to clean up the code,
document headers, and provide the best possible performance.

But we’re really, really close IMHO. What else should we include in
our “gotta have it” criteria for a 1.0 release?

-Geoff

SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4

Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
avogadro-devel List Signup and Options

3

Am Montag, 3. Dezember 2007 18:51:17 schrieb Geoffrey Hutchison:

But we’re really, really close IMHO. What else should we include in
our “gotta have it” criteria for a 1.0 release?

** Strigi support: Making it easy to find files related to chemistry ** Avogadro-as-a-KPart-in-Konqueor ** DBus-interface so that I can "remote-control" strigi ** Handbook for users ** Better ribbon suppport (look here http://jmol.sourceforge.net/screenshots/) ** Better crystallography support: http://jmol.sourceforge.net/screenshots/crystal-1.png

Carsten

4

Do do this it’s just a matter of adding that to the PrimitiveItemModel
class.

However, I really think what might be better is two separate docks, one
to select the conformer and one to select the atoms/bonds.

As far as I understand it, conformers dont’ change structure, just
positions. Thus it’s redundant to copy them multiple times.

–
Donald

(Mon, Dec 03, 2007 at 07:48:56PM +0100) Tim Vandermeersch tim.vandermeersch@gmail.com:

One thing I would really like to see in the near future is support for
multiple molecules and conformers. Would it be possible to have the
following tree structure in the projectDock:

+Molecule (1)
++Atoms
+++Atom (1)
+++…
++Bonds
+++Bond (1, 2)
++Conformers
+++Conformer 1 (see note)
+++…
+Molecule (2)

note: could the energy of the molecule be displayed there?

By clicking a molecule or conformer, this would be shown in the 3D
widget. This is just a way I think we could support multiple
molecules/conformers, if you have better ideas, let me know. I’m
willing to spend some time on this if needed… (Need to get more
familiar with avogadro code anyway)

I’ll also try to cleanup/update code, comments and documentation for my code.

Tim

On Dec 3, 2007 6:51 PM, Geoffrey Hutchison geoffh+@pitt.edu wrote:

I actually think it’s worth discussing what will make a “1.0” release
for us.

In the near term, we’ve got a great 0.3 release shaping up. Marcus and
Donald have both put in some great work, and I think the new force
field work from Tim (largely in Open Babel) will impress people.

Personally, I’d like to see these before we declare a “1.0.”

  • Support for properties mapped onto van der Waals surfaces
  • Orbital surfaces
  • Simple animations (using OBMol conformers as frames)
  • Something like the GAMESS interface for MOPAC and/or Gaussian.
    (This makes sure we’re not seen as only for GAMESS.)
  • A real file format of our very own. (Or at least a set of extensions
    on top of CML.)

I think we also need to make a conscious effort to clean up the code,
document headers, and provide the best possible performance.

But we’re really, really close IMHO. What else should we include in
our “gotta have it” criteria for a 1.0 release?

-Geoff

SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4

Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
avogadro-devel List Signup and Options

SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4

Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
avogadro-devel List Signup and Options

5

On Dec 3, 2007, at 12:51 PM, Geoffrey Hutchison wrote:

I actually think it’s worth discussing what will make a “1.0” release
for us.

I agree that we are certainly getting close and are in great shape for
a 1.0 release early next year.

In the near term, we’ve got a great 0.3 release shaping up. Marcus and
Donald have both put in some great work, and I think the new force
field work from Tim (largely in Open Babel) will impress people.

It would be great to get a 0.3 release out before the holiday period.
I think there is more than enough new stuff to warrant it.

Personally, I’d like to see these before we declare a “1.0.”

  • Support for properties mapped onto van der Waals surfaces
  • Orbital surfaces

For me these two are must haves and I will be doing what I can to make
it happen.

  • Simple animations (using OBMol conformers as frames)

I don’t think this would be too difficult and I would like to examine
animation in general.

  • Something like the GAMESS interface for MOPAC and/or Gaussian.

I would love to get MOPAC working as I think this is quite widely used
and I have had people ask me whether we planned to support it.

(This makes sure we’re not seen as only for GAMESS.)

  • A real file format of our very own. (Or at least a set of extensions
    on top of CML.)

I think we also need to make a conscious effort to clean up the code,
document headers, and provide the best possible performance.

I have got my pending white space commit :slight_smile: I have also been working
through a few of the more central classes and trying to improve the
documentation. Hopefully people see it as an improvement. I will be
working through some other stuff too.

But we’re really, really close IMHO. What else should we include in
our “gotta have it” criteria for a 1.0 release?

I have started work on a periodic table graphics view. I would like to
get that in but will hopefully get the initial version done pretty
quickly. It should be a lot more compact, colour based on element
colour and offer a pane with further details.

I think the biggest one I see on the list is surface support which we
can hopefully get sorted soon and then getting the API docs in order
and adding some user docs.

6

On Dec 3, 2007 8:10 PM, Donald Ephraim Curtis d@milkbox.net wrote:

Do do this it’s just a matter of adding that to the PrimitiveItemModel
class.

However, I really think what might be better is two separate docks, one
to select the conformer and one to select the atoms/bonds.

But is anyone working on this. Otherwise I will try to add
conformerDock tonight and see how far I get :slight_smile:

As far as I understand it, conformers dont’ change structure, just
positions. Thus it’s redundant to copy them multiple times.

–
Donald

(Mon, Dec 03, 2007 at 07:48:56PM +0100) Tim Vandermeersch tim.vandermeersch@gmail.com:

One thing I would really like to see in the near future is support for
multiple molecules and conformers. Would it be possible to have the
following tree structure in the projectDock:

+Molecule (1)
++Atoms
+++Atom (1)
+++…
++Bonds
+++Bond (1, 2)
++Conformers
+++Conformer 1 (see note)
+++…
+Molecule (2)

note: could the energy of the molecule be displayed there?

By clicking a molecule or conformer, this would be shown in the 3D
widget. This is just a way I think we could support multiple
molecules/conformers, if you have better ideas, let me know. I’m
willing to spend some time on this if needed… (Need to get more
familiar with avogadro code anyway)

I’ll also try to cleanup/update code, comments and documentation for my code.

Tim

On Dec 3, 2007 6:51 PM, Geoffrey Hutchison geoffh+@pitt.edu wrote:

I actually think it’s worth discussing what will make a “1.0” release
for us.

In the near term, we’ve got a great 0.3 release shaping up. Marcus and
Donald have both put in some great work, and I think the new force
field work from Tim (largely in Open Babel) will impress people.

Personally, I’d like to see these before we declare a “1.0.”

  • Support for properties mapped onto van der Waals surfaces
  • Orbital surfaces
  • Simple animations (using OBMol conformers as frames)
  • Something like the GAMESS interface for MOPAC and/or Gaussian.
    (This makes sure we’re not seen as only for GAMESS.)
  • A real file format of our very own. (Or at least a set of extensions
    on top of CML.)

I think we also need to make a conscious effort to clean up the code,
document headers, and provide the best possible performance.

But we’re really, really close IMHO. What else should we include in
our “gotta have it” criteria for a 1.0 release?

-Geoff

SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4

Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
avogadro-devel List Signup and Options

SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4

Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
avogadro-devel List Signup and Options

7

Some questions about the user manual:

  • In what kind of format will the user manual be distributed? webpage,
    wiki, pdf? Are there packages to produce this (OpenOffice?)
  • Could we also add video tutorials to the user manual. If yes, do we
    have webspace to place them on?
  • Will the manual only contain info on how to use the program, or
    background info as well?

As a general note: I think the user manual is very important as
avogadro gets more complex. Otherwise it might scare users away who
will never try the program again.

Tim

8

Am Montag, 3. Dezember 2007 20:53:05 schrieb Tim Vandermeersch:

Some questions about the user manual:

  • In what kind of format will the user manual be distributed? webpage,
    wiki, pdf? Are there packages to produce this (OpenOffice?)

No! Docbook. I attached Kalziums handbook.

Docbook can be used to create PDF, html, txt, … It is the standardformat
for documentation.

  • Could we also add video tutorials to the user manual. If yes, do we
    have webspace to place them on?
  • Will the manual only contain info on how to use the program, or
    background info as well?

Both I guess

As a general note: I think the user manual is very important as
avogadro gets more complex. Otherwise it might scare users away who
will never try the program again.

Full ack.

Carsten

9

On Dec 3, 2007, at 2:53 PM, Tim Vandermeersch wrote:

Some questions about the user manual:

  • In what kind of format will the user manual be distributed? webpage,
    wiki, pdf? Are there packages to produce this (OpenOffice?)

This is something that has not been decided. As Qt4.4 should have
WebKit built in would HTML help documents be the best option? Would be
good to know what people think. Another tempting option is LaTeX and
PDF but that is not as interactive if we wanted to have sections users
could click on from the tools etc.

I would like to have the option of adding a help section for the draw
tool which would then open up a help browser at the draw tool section.

  • Could we also add video tutorials to the user manual. If yes, do we
    have webspace to place them on?

We have done screencasts in the past and I think this would be an
excellent option to back up the help documentation. We have just been
putting them up on youtube so far. Not sure what would be the best
option longer term but I am sure we can find space to host them.

  • Will the manual only contain info on how to use the program, or
    background info as well?

It could contain some background but I would have thought it would
want to remain pretty focussed on the Avogadro application. There is
also the API documentation for developers which is already in pretty
good shape and I have been doing some work on improving it more
recently.

As a general note: I think the user manual is very important as
avogadro gets more complex. Otherwise it might scare users away who
will never try the program again.

I totally agree and we must have a user manual in place by the 1.0
release and I think this should be a blocker to getting the release
out. Since I joined the project Avogadro has increased in features and
hence complexity significantly and will only continue to do so.

It would be good to hear what other peoples thoughts are on the
documentation. I think the initial questions we must answer are what
format the help documentation should be written in. Certainly a
section for each tool, tutorial on a typical workflow, sections for
the engines and extensions.

Thanks,

Marcus

10

(Mon, Dec 03, 2007 at 09:12:10PM +0100) Carsten Niehaus cniehaus@gmx.de:

Am Montag, 3. Dezember 2007 20:53:05 schrieb Tim Vandermeersch:

Some questions about the user manual:

  • In what kind of format will the user manual be distributed? webpage,
    wiki, pdf? Are there packages to produce this (OpenOffice?)

No! Docbook. I attached Kalziums handbook.

I just had to reply to this cause I found it halarious. The tone of
that “No!” just cracked me up and I’m laughing. Just out of Carsten it
seems great. Oh boy. When is the Avogadro meetup.

Also, is anyone interested in setting up a few days to do some like
“group coding” where we talk about things and each person codes some
little part and then we join up the code. There are some editors that
support this but I’m not sure which ones. It is just a fun idea to have
an official Avogadro coding day.

–
Donald

11

I guess what I was saying was not “what would I dream to have in 1.0”
but “what must absolutely, positively, guaranteed be in 1.0?” (I could
add a nice list to the “dreaming” category too.) I’m trying to be
realistic about getting this in people’s hands.

I think some users are worried about the “0.3” version number.

** Handbook for users

Yes, we absolutely need integrated help and tutorials. Docbook is
great, but we also need to update the wiki.

** Better ribbon suppport (look here Jmol screenshots)

If someone will step up to do these sorts of ribbons, great. But we
already have some of them. Personally, I’m hoping that a 1.0 release
will get more contributors.

** Better crystallography support:
http://jmol.sourceforge.net/screenshots/crystal-1.png

We can certainly do that now. I think that’s fair enough – otherwise
it’s not very useful to solid-state people.

Cheers,
-Geoff

P.S. Let’s keep this list on the TODO wiki:
http://avogadro.sourceforge.net/wiki/To_Do

12

Hi everyone,

I guess we will need a translation of the manual, especially because it
is educational software… :slight_smile:

Therefore I would be happy to start translating the manual into German,
as soon as somebody gives me a sign.

Currently I can keep the German translation of Avo not lagging more than
approx. 36 hours behind development, I hope I can keep that up.
Depends on how much code you guys develop. :stuck_out_tongue:

One thing: How big is the possibility of problems if we depend on Qt >=
4.4? Because afaik KDE won’t depend on Qt > 4.3 due to compatibility
concerns … we would have to check how many distributions have the
policy to not upgrade Qt if KDE doesn’t need it … in the worst case we
would have to ship Qt with Avoagdro. But I don’t really know how big the
effect will be.

Hope you had great days in Paris!

Bye

Simon

13
  • Could we also add video tutorials to the user manual. If yes, do we
    have webspace to place them on?

YouTube is generally pretty good, particularly if you screencast with
a small window.

http://youtube.com/view_play_list?p=311F236AAD6D3F35

Some of these obviously need updating, but what do you think?

Cheers,
-Geoff

14

Am Montag, 3. Dezember 2007 23:02:24 schrieb Geoffrey Hutchison:

I guess what I was saying was not “what would I dream to have in 1.0”
but “what must absolutely, positively, guaranteed be in 1.0?” (I could
add a nice list to the “dreaming” category too.) I’m trying to be
realistic about getting this in people’s hands.

Ok, I agree with you. I will update the TODO as soon as it it back online.
Currently I am getting

Can’t contact the database server: Can’t connect to MySQL server on ‘mysql4-a’
(110) (mysql4-a)

I think some users are worried about the “0.3” version number.

** Handbook for users

Yes, we absolutely need integrated help and tutorials. Docbook is
great, but we also need to update the wiki.

You mean creating a tutorial for “How to use docbook”? I will try to add
docbook-support this week, lets see how easy that is.

** Better ribbon suppport (look here
Jmol screenshots)

If someone will step up to do these sorts of ribbons, great. But we
already have some of them.

I agree. Beside new “looks” there is one real issue. On a 1800 MHz Intel Core
2 M notebook I got between 0.1 and 1.0 fps on this protein (ball and sticks,
ribbon, debug engine):

  http://www.pdb.org/pdb/explore.do?structureId=1iwg

I am not sure if for a certain size or speed Avogadro should issue a
warning: “Attention, this molecule is to big to be rendered at good speeds”
or something like that…

Carsten

15

Am Montag, 3. Dezember 2007 23:23:16 schrieb Simon Ochsenreither:

One thing: How big is the possibility of problems if we depend on Qt >=
4.4? Because afaik KDE won’t depend on Qt > 4.3 due to compatibility
concerns … we would have to check how many distributions have the
policy to not upgrade Qt if KDE doesn’t need it … in the worst case we
would have to ship Qt with Avoagdro. But I don’t really know how big the
effect will be.

I disagree:
Avogadro won’t be out until at least Q2/2008, I bet.
KDE 4.0 is scheduled for Jan 2008.
Qt 4.4 is scheduled for Q1/2008.
KDE 4.0 will work with Qt 4.3 and 4.4
Most distros will not ship 4.0 as the default desktop anyway (but wait for
4.1.x). At least that is was I heard in Paris. Therefore I guess they will
provide KDE 4.0.x with the latest Qt 4 in some kind of test-repository
(Cooker, Buildservice…)

Furthermore, for Mac and Windows this KDE-thing doesn’t matter at all because
there, Qt is linked statically into the binary anyway. (Not sure about Mac,
but on Windows it is).

Carsten

16

Hi,

As you may have noticed in my previous mails, I was unaware that you
can select an engine’s primitives using the primitive tab. I only
found this out when Donald added the “Assign Engine to selected
primitives” button. Now I know how it works, it works great :-).
I added the Primitives dock to menuDock, so you can get it back when
you closed it. But would it not make more sense to have a single
Engines Dock with 3 tabs (Engine, Configuration, Primitives)? Like we
have for the tools.

This together with the recent talks about avogadro and the reference
on the GAMESS website got me thinking again about the User Manual. I
assume that no one has started on this? I have some time to work on
this, but first I would like to hear what others have to say about the
multiple engine docks. Having a single tabbed engine dock would also
make it easier to document in the user manual I think.

Tim

17

I have thought about this previously. What is nice about the current
way is that they can be separated. It is possible the user will want to
pull these apart and have them floating around the screen or possibly on
the right side of the screen just to make access easier. If we embed
them in a TabWidget this will not be immediately possible. Using
separate dock widgets gives us a lot of freedom. I think the main
problem is that we have the dock called “Primitives” and it’s not
“Engine Primitives” or something like that. I’m not sure how to fix
this but I do think being able to separate them because if you’re doing
a lot of this “specialized” rendering stuff, it’s going to be really
convenient to have them as separate docks. For me, I think having the
engine list and the configuration tab un-docked.

Summary: I don’t want to FORCE those three tabs to be docked just
because by default they are. That’s just me.

It is also not fair to compare the engines dock with the tools because
tools work in the manner that only ONE tool at a time can be selected.
That means a non-separating tab widget makes sense.

It would be nice to see a user manual start to come together (right now?
over me?). I think you could easily explain the three dock system
though. Just have an initial section that explains what docks are for
what purpose. We do have a “Project” dock that will easily NOT be
confused for the Primitives dock. Again I think this just goes back to
not having a better title for those three engine-related docks. I also
think the whole “assign engine to selected primitives” needs some more
work. I want to add a button that does “set selected to assigned engine
primitives” so you can reverse it.

Man, so little to do and so much time to do it in. Wait, reverse that.

–
Donald

(Sat, Feb 16, 2008 at 06:32:06PM +0100) Tim Vandermeersch tim.vandermeersch@gmail.com:

Hi,

As you may have noticed in my previous mails, I was unaware that you
can select an engine’s primitives using the primitive tab. I only
found this out when Donald added the “Assign Engine to selected
primitives” button. Now I know how it works, it works great :-).
I added the Primitives dock to menuDock, so you can get it back when
you closed it. But would it not make more sense to have a single
Engines Dock with 3 tabs (Engine, Configuration, Primitives)? Like we
have for the tools.

This together with the recent talks about avogadro and the reference
on the GAMESS website got me thinking again about the User Manual. I
assume that no one has started on this? I have some time to work on
this, but first I would like to hear what others have to say about the
multiple engine docks. Having a single tabbed engine dock would also
make it easier to document in the user manual I think.

Tim

This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
avogadro-devel List Signup and Options

18

On Feb 16, 2008 7:00 PM, Donald Ephraim Curtis d@milkbox.net wrote:

I have thought about this previously. What is nice about the current
way is that they can be separated. It is possible the user will want to
pull these apart and have them floating around the screen or possibly on
the right side of the screen just to make access easier. If we embed
them in a TabWidget this will not be immediately possible. Using
separate dock widgets gives us a lot of freedom. I think the main
problem is that we have the dock called “Primitives” and it’s not
“Engine Primitives” or something like that. I’m not sure how to fix
this but I do think being able to separate them because if you’re doing
a lot of this “specialized” rendering stuff, it’s going to be really
convenient to have them as separate docks. For me, I think having the
engine list and the configuration tab un-docked.

Summary: I don’t want to FORCE those three tabs to be docked just
because by default they are. That’s just me.

I totally agree. But renaming “Primitives” to “Engine Primitives” and
“Configuration” to “Engine Configuration” would avoid any confusion.

It is also not fair to compare the engines dock with the tools because
tools work in the manner that only ONE tool at a time can be selected.
That means a non-separating tab widget makes sense.

It would be nice to see a user manual start to come together (right now?
over me?). I think you could easily explain the three dock system
though. Just have an initial section that explains what docks are for
what purpose. We do have a “Project” dock that will easily NOT be
confused for the Primitives dock. Again I think this just goes back to
not having a better title for those three engine-related docks. I also
think the whole “assign engine to selected primitives” needs some more
work. I want to add a button that does “set selected to assigned engine
primitives” so you can reverse it.

Man, so little to do and so much time to do it in. Wait, reverse that.

–
Donald

(Sat, Feb 16, 2008 at 06:32:06PM +0100) Tim Vandermeersch tim.vandermeersch@gmail.com:

Hi,

As you may have noticed in my previous mails, I was unaware that you
can select an engine’s primitives using the primitive tab. I only
found this out when Donald added the “Assign Engine to selected
primitives” button. Now I know how it works, it works great :-).
I added the Primitives dock to menuDock, so you can get it back when
you closed it. But would it not make more sense to have a single
Engines Dock with 3 tabs (Engine, Configuration, Primitives)? Like we
have for the tools.

This together with the recent talks about avogadro and the reference
on the GAMESS website got me thinking again about the User Manual. I
assume that no one has started on this? I have some time to work on
this, but first I would like to hear what others have to say about the
multiple engine docks. Having a single tabbed engine dock would also
make it easier to document in the user manual I think.

Tim

This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
avogadro-devel List Signup and Options

19

The problem we have is that the combination:
Engine | Engine Configuration | Engine Primitives
takes up a lot of space in the dock.

We actually had it this way at one point but it just doesn’t fit nicely.
What we really need is to be able to use multi-line dock names or to use
icons instead. I’m not sure how to do either with QT at the moment.
I’ll see if I can dig up a better solution. They have some custom
dialog things in qt4.3 I think.

–
Donald

(Sat, Feb 16, 2008 at 07:09:31PM +0100) Tim Vandermeersch tim.vandermeersch@gmail.com:

On Feb 16, 2008 7:00 PM, Donald Ephraim Curtis d@milkbox.net wrote:

I have thought about this previously. What is nice about the current
way is that they can be separated. It is possible the user will want to
pull these apart and have them floating around the screen or possibly on
the right side of the screen just to make access easier. If we embed
them in a TabWidget this will not be immediately possible. Using
separate dock widgets gives us a lot of freedom. I think the main
problem is that we have the dock called “Primitives” and it’s not
“Engine Primitives” or something like that. I’m not sure how to fix
this but I do think being able to separate them because if you’re doing
a lot of this “specialized” rendering stuff, it’s going to be really
convenient to have them as separate docks. For me, I think having the
engine list and the configuration tab un-docked.

Summary: I don’t want to FORCE those three tabs to be docked just
because by default they are. That’s just me.

I totally agree. But renaming “Primitives” to “Engine Primitives” and
“Configuration” to “Engine Configuration” would avoid any confusion.

It is also not fair to compare the engines dock with the tools because
tools work in the manner that only ONE tool at a time can be selected.
That means a non-separating tab widget makes sense.

It would be nice to see a user manual start to come together (right now?
over me?). I think you could easily explain the three dock system
though. Just have an initial section that explains what docks are for
what purpose. We do have a “Project” dock that will easily NOT be
confused for the Primitives dock. Again I think this just goes back to
not having a better title for those three engine-related docks. I also
think the whole “assign engine to selected primitives” needs some more
work. I want to add a button that does “set selected to assigned engine
primitives” so you can reverse it.

Man, so little to do and so much time to do it in. Wait, reverse that.

–
Donald

20

on the GAMESS website got me thinking again about the User Manual. I
assume that no one has started on this?

That’s correct no one has started on a User Manual. Personally I think
we want two things:

  • A user manual giving documentation on features, etc.
  • A set of screencasts for tutorials.

I tend to think of user manuals as a set of screenshots, text –
things that could be printed or read online.

Here, I think it would really help to take some of the videos we’ve
done and keep them on the wiki. I have two great programs for my Mac
to create screencasts, including indications for key commands as well
as mouse clicks. (The only problem is that on the Mac, you see a
“command key” or clover-leaf, rather than a control key.)

Cheers,
-Geoff