On Thu, Oct 20, 2011 at 5:28 PM, Georg Zotti <[email protected]> wrote: > Dear core team, > [snip]
> My other branch is the scenery3d walkthrough plugin, which was quite > successfully demonstrated at SEAC. This undergoes further improvements by > a student until January, then I would like to contribute it to the > project. For optimal integration I have a few questions: > > Where in the branch shall I put plugin data files, i.e. some demo > sceneries? I know plugin data files in the final application should go into > <USER_DATA>/modules/scenery3d/<scene_name>. There is however currently no > directory <BZRbranch>/modules/<plugin_name> in the project structure, the > other plugins just create new files in the user's > <USER_DATA>/modules/<plugin_name>. This is a good question. As Alex Wolf said, you can put the files in a resource file. There is a problem, though - this will embed the files in Stellarium's executable file. While this is OK for small files like button textures, adding everything to the executable will continue to bloat it in the long run. We need a standardized file locations and install scripts for the plug-in resources. > For walkaround with keyboard controls, I had to modify > StelMovementMgr::getCallOrder(), thereby breaking the pure "plugin" > concept. However, I feel that plugins should be allowed keyboard > interaction intercepting the main application. There is something like that done in the Oculars plug-in. I haven't looked at your code yet, so I don't know if you have used the same mechanism. > A few months ago, there was discussion on the list on the buttons > behaviour of plugins. Has there been a decision/solution yet? No. Timothy Reaves wrote some code in this direction, but in the discussion, different people turned out to have different ideas on what exactly it should look like. I was going to write a resume of the positions and post it here or on the Wiki, but got distracted with "real life" issues, including the lack of a permanent Internet connection. > It would be > helpful to have a right-click behaviour like "open config panel" - > currently I must use 2 buttons. Overriding the right click will be tricky, because it is currently used to de-select objects. You can have a look at my branch for plug-in GUI improvement - https://code.launchpad.net/~daggerstab/stellarium/plugins-gui-improvement Using the same method you can add a command GUI on the screen similar to the existing toolbars. > > The PDF manual is somewhat outdated (10.2). Is there documentation on the > scripting language? The files on sourceforge SVN are about 3 years old. > Where are the (Are there?) current LaTeX/LyX files, maybe I can add some > details on landscapes, refraction, extinction and scenery3d. The LaTeX > sources could be likewise developed on the BZR. I think, one complete, > up-to-date english manual should always be available, and new visible > features could be easily added by the respective author if this manual was > also on BZR. "Outdated" is an understatement. It was decided to migrate the manual to the Wiki, supposedly to make it easier to use/edit/translate. Alex Wolf did a lot of work on importing it in the Wiki, but a lot of the information is still either not up-to-date, incomplete or misleading. One of the reasons of the migration is that there is a MediaWiki extension that can export a collection of wiki pages as a PDF file. Unfortunately, it doesn't work with our site because of SourceForge's hosting policies. The Wiki was supposed to be moved together with the site on a seprate server When We Enable the DSS Background, but I don't know what's the current state of this, as Fabien has dropped off the radar. > > Some time ago I had understood Stellarium moved from Sourceforge to > Launchpad. Now I understood something is still kept at Sourceforge. What > is the reason for the dichotomy BZR/SVN? The SVN repository is kept mainly as an archive, the same way the CVS repository is. There is also some code that wasn't in the trunk and wasn't migrated to Bazaar or elsewhere - the telescope servers and the last surviving examples of stand-alone, dynamically loaded plug-ins. > > Stellarium has high potential as education tool, and I think the scenery3D > plugin is opening new possibilities for archaeoastronomy. For the latter, > however, astronomical accuracy need to be improved for times long gone. I > hope I can contribute something more in this field. Generally however, > some source files need better documentation of algorithms and data sources > (papers, books?). If you know more than is currently available, please > consider improving documentation to help contributors. That will be somewhat hard. Stellarium is optimized for fast rendering, not accuracy. There are some fudge factors included in the code, as well as some outright "nobody will care about that". Hight accuracy generally means more calculations and a lower frame-per-second rate. When Fabien was working on the Nokia N900 port, he even made some parameters to use a lower precision format (float instead of double). Also, I think that the person responsible for some of the orbital modeling code no longer hangs around. :) > > On Launchpad, most branches are in state of "Development". However, many > of the branches have no description, and some seem to be dead. Consider > marking "Abandon" for those, "Mature" for the ready-to-merge ones, and > "Merged" for, well, merged ones without further use. The description can > include a description of current state. Of course, only the branch owners > should do that. Only the branch owners _can_ do that. :) There are also some apparently abandoned branches and merge proposals that should have been done ages ago. I'll try to comment/update my branches anyway. Regards, Bogdan Marinov ------------------------------------------------------------------------------ The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev _______________________________________________ Stellarium-pubdevel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel
