Simpler Panda modules hierarchy...

General Discussion
1

Which hierarchy do you want?

  • The current one (direct, pandac…)
  • The proposed one (panda3d.xxx like modules)

0 voters

Do you also think that the current modules hieararchy is confusing? You never know where some class is located? Or you just dislike the current setting?

In the current setting some classes are in direct.(other modules), something is in pandac and so on. I think it’s just confusing, at least for newbies. It is like that because of historical reasons, but now it’s not needed like that, so I think the hierarchy should be overhauled.

My idea:
panda3d package - in it modules for video, audio, net, physics etc. In them the appropriate classes. Like this:
panda3d.video.Camera
panda3d.audio.MusicManager
panda3d.net.NetAddress
panda3d.gui.Button
…
(This is not how it should exactly look… Just an example to get the idea)

Thx for your votes :wink:

2

Personally, I would only support a new hierarchy if backwards-compatibility was maintained… seems like too small a reason to break compatibility.

3

Hm, we would of course keep the old structure for backward compatibility. We could have both.

4

i personally think that a abstraction layer could help new panda3d users. as pro-rsoft said the old structure has to be kept for backward compatiblity. but i agree that some functions (especially some direct stuff) could be accessable more easily, by using something as suggested in the first post.

in panda3d 5.0 in 2020 backwards compatiblity could be broken :wink:

5

I’d keep the old hiearchy but I’d modernize it.

Like direct.camera.settings or something like that :slight_smile:

6

there is a rough hierarchy in direct, but a structure in pandac would be nice - structure as visible from python. i have no idea of the C/C++ code.

also i don’t get the idea of the name ‘direct*’. there is directbase, directd, directnotify, directutil and many more. a file structure guide would be very nice. especially while MUCH stuff is not properly documented.

about backwards compatibilty i think it’s very important, so i tend to an abstraction layer as suggested by Hypnos

another thing: for me it sounds like the disney ppl just wanted to have some of their game specific stuff in the repos. i mean, there are even a few files for ship control only and many other files where you think “hey, that looks like a part of a game and not like general purpose code”. those very specific classes shouldn’t be mixed with very generic ones

7

what i just forgot:
in python packages are usually imported by their names, so how about a panda(3d) package as root for all imports? i’m okay with ‘pandac’, but ‘direct’ is not appropriate IMHO. also it may easily collide with other python packages

8

I think that’s because historically, “direct”, “dtool” and “panda” were really separate trees.

Actually, I know which classes you are talking about, and they are just not documented. I don’t think that the fact they aren’t documented is a good enough reason to remove them from the Panda3D CVS.

Why does it bother you that there is Disney stuff in there? I mean, dmodels is full of it.

9

it doesn’t really bother me but if they’re absolutely undocumented and very specific, they’re useless. also disney (or other developers, i don’t really know) has abandoned many of their files which now don’t even work anymore and ghost through the repos.

don’t get me wrong, this is not meant as criticism or offense on disney. it was just a hint for all devs to make some cleanup. that would be the first reasonable step to increase the clarity of panda’s sources