Dear Bogdan, thank you for you answers, commented further below.
On Mo, 24.10.2011, 21:40, Bogdan Marinov wrote: > On Thu, Oct 20, 2011 at 5:28 PM, Georg Zotti <[email protected]> > wrote: >> Dear core team, >> [snip] > >> Where in the branch shall I put plugin data files, i.e. some demo >> sceneries? >> [snip] > 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. OK, so the resource file is a clear no-go here. I speak of 3D models, which are large, exchangeable and loadable via a GUI list similar to "Landscapes". I think an install script is not necessary, just unpack and copy into your Stellarium data folder. The question is, shall I add a folder "modules" into the main folder, in which I now add "scenery3d" (because it's a plugin and plugin data go into subfolders of "modules"), or shall I add a "scenery3d" folder directly, because it's a concept similar to "landscapes". >> 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. Ah, I have to look inside there! >> 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. Sounds difficult... >> 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. Then maybe with double-click? Or can a button "grab" the right-click event before forwarding to the main app? > 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. OK, must look inside. >> [Manual is outdated] > "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. Yes, following Alex' response I added some details on recent changes in Landscapes. > 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. Uh, that's bad to read! Who else in the team is OpenGL expert now? >> [accuracy, documentation] > 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). I had seen this change, but did not know exactly why. OK, it's not a problem for landscapes, but definitely for long-term computations. It will be an important point to consider for me. > Also, I think that the person responsible for some of the orbital > modeling code no longer hangs around. :) Yes, what a pity! >> [unmerged/"dead"(?) branches] > 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. OK, thanks! Kind regards, Georg -- DI Dr Georg Zotti Archaeoastronomy / ASTROSIM VIAS-Vienna Institute for Archaeological Science University of Vienna ------------------------------------------------------------------------------ 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
