From: Bogdan M. <dag...@gm...> - 2009-07-12 16:49:40
Attachments:
telescope_using_QTcpSocket_vs_r4769_02.diff
|
Hello. The attached patch contains changes made to the Telescope and TelescopeManager classes in order to use Qt's networking classes instead of platform-specific headers. I don't think I've managed to drop a dependency, though. :) The new code is simpler and shorter, but this is more a working demonstration that it could be done than a real patch - some of the parts need polishing, and it follows the old C structure instead of relying more on Qt signals and slots. For example, I am not sure if the prepareCommunication() and performCommunication() routines should be merged. (They used to be prepareSelectFds() and handleSelectFds().) I've tested the code only on Linux, and only with the Dummy server. All the tests I could think of (killing the server while Stellarium is running, unplugging the network cable, etc.) has been successful - errors are handled well and don't cause to Stellarium to die with a segmentation fault. I would be nice if someone tested whether the code compiles and works OK on Windows and Mac OS. Thank you. Bogdan Marinov |
From: Fabien C. <fab...@go...> - 2009-07-13 09:07:19
|
That's great :) The code is at least much more readable now :D I just committed it. It compiles fine on MacOSX, but I didn't tested if it works. Thanks, Fabien On Sun, Jul 12, 2009 at 18:49, Bogdan Marinov<dag...@gm...> wrote: > Hello. > > The attached patch contains changes made to the Telescope and > TelescopeManager classes in order to use Qt's networking classes > instead of platform-specific headers. I don't think I've managed to > drop a dependency, though. :) The new code is simpler and shorter, but > this is more a working demonstration that it could be done than a real > patch - some of the parts need polishing, and it follows the old C > structure instead of relying more on Qt signals and slots. For > example, I am not sure if the prepareCommunication() and > performCommunication() routines should be merged. (They used to be > prepareSelectFds() and handleSelectFds().) > > I've tested the code only on Linux, and only with the Dummy server. > All the tests I could think of (killing the server while Stellarium is > running, unplugging the network cable, etc.) has been successful - > errors are handled well and don't cause to Stellarium to die with a > segmentation fault. I would be nice if someone tested whether the code > compiles and works OK on Windows and Mac OS. > > Thank you. > Bogdan Marinov |
From: Barry G. <bar...@ho...> - 2009-07-13 11:53:43
|
Hi fabien I just compiled 4771 in windows. No problems. I also connected to my LX200 test bed (a full working set of electronics). Works correctly as far as I can see, in fact I have not noticed any difference except the dll is slightly larger. Barry Gerdes Beaumont Hills Observatory S 33' 41' 44" E 150' 56' 32" 12" F10 GPS Polar mounted Home Page http://www.geocities.com/barrykgerdes > From: fab...@go... > Date: Mon, 13 Jul 2009 11:06:54 +0200 > To: ste...@li... > Subject: Re: [Stellarium-pubdevel] [patch/demo] Telescope client refactored to use Qt classes for networking > > That's great :) > The code is at least much more readable now :D I just committed it. > It compiles fine on MacOSX, but I didn't tested if it works. > Thanks, > Fabien > > On Sun, Jul 12, 2009 at 18:49, Bogdan Marinov<dag...@gm...> wrote: > > Hello. > > > > The attached patch contains changes made to the Telescope and > > TelescopeManager classes in order to use Qt's networking classes > > instead of platform-specific headers. I don't think I've managed to > > drop a dependency, though. :) The new code is simpler and shorter, but > > this is more a working demonstration that it could be done than a real > > patch - some of the parts need polishing, and it follows the old C > > structure instead of relying more on Qt signals and slots. For > > example, I am not sure if the prepareCommunication() and > > performCommunication() routines should be merged. (They used to be > > prepareSelectFds() and handleSelectFds().) > > > > I've tested the code only on Linux, and only with the Dummy server. > > All the tests I could think of (killing the server while Stellarium is > > running, unplugging the network cable, etc.) has been successful - > > errors are handled well and don't cause to Stellarium to die with a > > segmentation fault. I would be nice if someone tested whether the code > > compiles and works OK on Windows and Mac OS. > > > > Thank you. > > Bogdan Marinov > > ------------------------------------------------------------------------------ > Enter the BlackBerry Developer Challenge > This is your chance to win up to $100,000 in prizes! For a limited time, > vendors submitting new applications to BlackBerry App World(TM) will have > the opportunity to enter the BlackBerry Developer Challenge. See full prize > details at: http://p.sf.net/sfu/Challenge > _______________________________________________ > Stellarium-pubdevel mailing list > Ste...@li... > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel _________________________________________________________________ POP access for Hotmail is here! Click here to find out more http://windowslive.ninemsn.com.au/article.aspx?id=802246 |
From: Timothy R. <tr...@si...> - 2009-07-13 19:43:59
|
On Jul 13, 2009, at 5:06 AM, Fabien Chéreau wrote: > That's great :) > The code is at least much more readable now :D I just committed it. > It compiles fine on MacOSX, but I didn't tested if it works. > Thanks, > Fabien This is just the client code? It still needs to be used with the telescope server (that's in the separate module)? |
From: Bogdan M. <dag...@gm...> - 2009-07-13 20:03:35
|
On Mon, Jul 13, 2009 at 10:27 PM, Timothy Reaves<tr...@si...> wrote: > > On Jul 13, 2009, at 5:06 AM, Fabien Chéreau wrote: > >> That's great :) >> The code is at least much more readable now :D I just committed it. >> It compiles fine on MacOSX, but I didn't tested if it works. >> Thanks, >> Fabien > > > This is just the client code? It still needs to be used with the > telescope server (that's in the separate module)? Yes, precisely - you still need the server. The code of the client just has been refactored - same behavior, cleaner code based on Qt instead on system calls. I may try to clean up the server side, but I doubt that it will be useful - I'm still working on my telescope control plug-in and I intend eventually to add INDI & ASCOM compatibility (for Linux and Windows, respectively), which will make Stellarium's telescope servers kind of obsolete. Regards, Bogdan Marinov |
From: Timothy R. <tr...@si...> - 2009-07-14 00:44:34
|
On Jul 13, 2009, at 4:03 PM, Bogdan Marinov wrote: > On Mon, Jul 13, 2009 at 10:27 PM, Timothy > Reaves<tr...@si...> wrote: >> >> On Jul 13, 2009, at 5:06 AM, Fabien Chéreau wrote: >> >>> That's great :) >>> The code is at least much more readable now :D I just committed it. >>> It compiles fine on MacOSX, but I didn't tested if it works. >>> Thanks, >>> Fabien >> >> >> This is just the client code? It still needs to be used >> with the >> telescope server (that's in the separate module)? > > Yes, precisely - you still need the server. The code of the client > just has been refactored - same behavior, cleaner code based on Qt > instead on system calls. > > I may try to clean up the server side, but I doubt that it will be > useful - I'm still working on my telescope control plug-in and I > intend eventually to add INDI & ASCOM compatibility (for Linux and > Windows, respectively), which will make Stellarium's telescope servers > kind of obsolete. > > Regards, > Bogdan Marinov You might be suspired (regarding your last statement). I'm sure there are many Linux and Windows users, but I know many more using a Mac. And those ASCOM guys still have their heads stuck... well, anyway, they don't understand cross platform design. Or, really, design. |
From: Fabien C. <fab...@go...> - 2009-07-14 07:07:44
|
On Mon, Jul 13, 2009 at 22:03, Bogdan Marinov<dag...@gm...> wrote: > On Mon, Jul 13, 2009 at 10:27 PM, Timothy > Reaves<tr...@si...> wrote: >> >> On Jul 13, 2009, at 5:06 AM, Fabien Chéreau wrote: >> >>> That's great :) >>> The code is at least much more readable now :D I just committed it. >>> It compiles fine on MacOSX, but I didn't tested if it works. >>> Thanks, >>> Fabien >> >> >> This is just the client code? It still needs to be used with the >> telescope server (that's in the separate module)? > > Yes, precisely - you still need the server. The code of the client > just has been refactored - same behavior, cleaner code based on Qt > instead on system calls. > > I may try to clean up the server side, but I doubt that it will be > useful - I'm still working on my telescope control plug-in and I > intend eventually to add INDI & ASCOM compatibility (for Linux and > Windows, respectively), which will make Stellarium's telescope servers > kind of obsolete. What is the status on the plugin? I start to think of making a release in the next months, and your plugin will be the main new feature :) One of the remaining problem is the way to manage plugin configuration files. Especially in the case where the plugins are statically linked to the program. In this case plugin files are installed in a read only directory along with other stellarium files. So when the plugin needs to write its config options, I see 2 possibilities: 1- On the first start, the plugin creates a new config file in $HOME/.stellarium/modules/MyPlugin/module.ini based on default values hardcoded or stored in a special readonly file (e.g. /usr/share/stellariumt/modules/MyPlugin/defaultModule.ini) 2- On the first start, the plugin adds a new section in the main stellarium config.ini file in $HOME/.stellarium/config.ini based on default values. I would suggest that for the moment we go on with solution 1 which is more in line with what we currently have. What do you think? Practically this mean that all plugin developer must check at starting time that there is already a writable module.ini file. If not a new one must be created. Fabien |
From: Bogdan M. <dag...@gm...> - 2009-07-14 09:31:26
|
On Tue, Jul 14, 2009 at 10:07 AM, Fabien Chéreau<fab...@go...> wrote: > What is the status on the plugin? I start to think of making a release > in the next months, and your plugin will be the main new feature :) The status is "progressing at a snail's pace". I still have exams to take in September, so don't count on anything for the next few months - I may manage to make something finished, but it's not guaranteed. At the moment, the only novel thing that is usable is the GUI for telescope configuration/server launching that you are already familiar with. On Tue, Jul 14, 2009 at 3:44 AM, Timothy Reaves<tr...@si...> wrote: > You might be suspired (regarding your last statement). I'm sure > there are many Linux and Windows users, but I know many more using a > Mac. And those ASCOM guys still have their heads stuck... well, > anyway, they don't understand cross platform design. Or, really, > design. Isn't Mac OS X UNIX-based? AFAIK, INDI is supposed to be able to be compiled on anything UNIX-compatible. Regards, Bogdan Marinov |
From: Bogdan M. <dag...@gm...> - 2009-07-14 15:46:21
|
On Tue, Jul 14, 2009 at 12:31 PM, Bogdan Marinov<dag...@gm...> wrote: > [snip] > On Tue, Jul 14, 2009 at 3:44 AM, Timothy > Reaves<tr...@si...> wrote: >> You might be suspired (regarding your last statement). I'm sure >> there are many Linux and Windows users, but I know many more using a >> Mac. And those ASCOM guys still have their heads stuck... well, >> anyway, they don't understand cross platform design. Or, really, >> design. > > Isn't Mac OS X UNIX-based? AFAIK, INDI is supposed to be able to be > compiled on anything UNIX-compatible. I've looked into it and it seem that it is. For example, this site offers a universal binary of INDI 0.5, though I'm not sure how secure it is - it doesn't seem to be official: http://mac.softpedia.com/get/Utilities/INDI.shtml And I found some threads in INDI's mailing list that discuss compilation on Mac: http://sourceforge.net/mailarchive/forum.php?thread_name=f8983bf40904191107t50e7d6c5k81b86df14ae55e0e%40mail.gmail.com&forum_name=indi-devel http://sourceforge.net/mailarchive/forum.php?thread_name=BBE94DA0-FBB5-411E-BF8D-AF7C3CCF3C83%40mac.com&forum_name=indi-devel So it seems that INDI support will have Mac covered, too. Regards, Bogdan Marinov |
From: Timothy R. <tr...@si...> - 2009-07-14 20:27:27
|
On Jul 14, 2009, at 10:46 AM, Bogdan Marinov wrote: > On Tue, Jul 14, 2009 at 12:31 PM, Bogdan > Marinov<dag...@gm...> wrote: >> [snip] >> On Tue, Jul 14, 2009 at 3:44 AM, Timothy >> Reaves<tr...@si...> wrote: >>> You might be suspired (regarding your last statement). I'm >>> sure >>> there are many Linux and Windows users, but I know many more using a >>> Mac. And those ASCOM guys still have their heads stuck... well, >>> anyway, they don't understand cross platform design. Or, really, >>> design. >> >> Isn't Mac OS X UNIX-based? AFAIK, INDI is supposed to be able to be >> compiled on anything UNIX-compatible. > > I've looked into it and it seem that it is. > > For example, this site offers a universal binary of INDI 0.5, though > I'm not sure how secure it is - it doesn't seem to be official: > http://mac.softpedia.com/get/Utilities/INDI.shtml > > And I found some threads in INDI's mailing list that discuss > compilation on Mac: > http://sourceforge.net/mailarchive/forum.php?thread_name=f8983bf40904191107t50e7d6c5k81b86df14ae55e0e%40mail.gmail.com&forum_name=indi-devel > > http://sourceforge.net/mailarchive/forum.php?thread_name=BBE94DA0-FBB5-411E-BF8D-AF7C3CCF3C83%40mac.com&forum_name=indi-devel > > So it seems that INDI support will have Mac covered, too. > > Regards, > Bogdan Marinov > I'll have a look at this, but it's not ASCOM. Is it related? I'll check more tonight. |