GeoXPlanet now available at Sourceforge.net

[rocket357]

can you Upload Binary packages?

While python does "byte-compile" source files to speed things up a bit, Python doesn't have true binary executables (unless you run py2exe on them, which last I checked was windows-only). Python is much like Java in this respect, though gcj (Java compiler that compiles Java to machine code) is unix-only, last I checked.

I can include a convenience file in the top level-directory to launch the entire project if you'd like...though I've considered writing small C or C# programs to launch the project, I haven't decided on the route I'd like to go there, and I wasn't considering including a launcher until around GeoXPlanet-0.5.0. I'll speed up the process, though, since you've requested it.

for me,even /src/configGUI.py failed to start

This one was a definite bug. The script contained a faulty "standalone execution" routine that failed to start the configGUI.py file in "standalone" mode (Python files can be called from other Python files, in which case they run like a library, or they can be run by themselves, in which case they operate like a standalone script). The standalone code was faulty and wouldn't allow configGUI to launch as a standalone.

Fix will be included in 0.4.2.

 

[praka123]

^will download.when will u upload latest?

...and this is :

prakash@localhost:~/Desktop/GeoXPlanet-0.4.1/src$ ./configGUI.py 
  File "./configGUI.py", line 357
    finally:
          ^
SyntaxError: invalid syntax

 

[gary4gar]

I am asking for DEB package

 

[rocket357]

praka123:

look for 0.4.2 sometime in the next few hours...I need to package it up still, and I have a few fixes on my machine at home that I need to get before I can do that. The specific bug you've pointed out (the "finally:" invalid syntax bug) has been fixed and will be in this next release. Also included will be a fix that corrects how GeoXPlanet sets the background in gnome.

gary4gar:

ACK! I run Gentoo on all my Linux boxes, and while I'm sure I *could* create a deb package, I have no clue where I'd put the files other than the user's home directory (hence me not creating a deb, rpm, ebuild, etc...). If I can get someone with considerable experience packaging source packages for Debian/RedHat/Portage/etc... to give me some pointers, I'll step to it and push one out. Until then, though, I'd rather not run the risk.

 

[mehulved]

I am asking for DEB package

distribution specific packages are usually created by package maintainers for their distribution rather than upstream provider providing them.

 

[rocket357]

GeoXPlanet-0.4.2 has been uploaded and should be available for download shortly.

This release fixes a few gnome-specific bugs (undefined global "serf" is fixed, as is a bug dealing with how GeoXPlanet sets the wallpaper in gnome), fixes one Windows-related bug (pop-up in Windows asking if the user is running fluxbox, gnome, or kde...doh?), fixes quite a few configGUI.py bugs (standalone launching works now, and it now properly saves your configuration), and this release adds in a basic framework for the upcoming MySQL and SQLite database support.

NucleusKore, the bugs you reported ("arcFile not found", "markerfile not found") should be fixed now, as well as the bug causing your viewing lat/long to get stuck to 0.0, 0.0 (just off the coast of Africa). Please report if you have any more trouble.

I'm debating on the next release focus. I'm thinking about adding in SQLite support first (since the maxmind GeoLiteCity database is redistributable under the GPL...I just need to import it into SQLite), as it's been my experience that the maxmind database is more accurate than hostip.info (the site used for online lookups). I might work more on the graphical side (i.e. create a tray icon that reports statistics and the like), but I haven't decided yet.

Thoughts?

 

[praka123]

a shell script for installing your application is good(not necessary).
Even I am waiting to install gentoo after 3-4 yrs back got funtoo.org's portage and stage3 balls.

will download geoXplanet now

 

[mehulved]

a shell script for installing your application is good(not necessary).

Sorry, I disagree to that. It is much better to have a GUI config utility since this is intended as a 'eye candy'. It wouldn't be such a nice idea to have it in such a way. It would be a better idea IMHO to have a GUI installer which has configuration options as well. shell script installer can be there as an optional way.

 

[ray|raven]

^Perhaps using gtkdialog with a shell script would be good enough?

 

[rocket357]

This project is intended to run *purely* in non-priv user-space. I do not wish to cross over into a situation where someone needs root priv to install or suid priv to run the program...I just want to have the program running quietly in the background without hassle of su or sudo, etc...

That said, I *am* planning on writing such niceties as a tray icon or runtime GUI...but first things first...let me get this project out of Beta status...heh. Once that's done, and the code is *really* operational, I'll consider packaging for different distros and/or installer scripts. Keep in mind I have a Windows user-base to support, too...imagine how they feel seeing the install directions: "1) Unzip to a directory of your choice 2) navigate to that directory 3) go into the "src" directory there 4) launch GeoXPlanet.py by double-clicking on it or from cmd.exe"...I get responses like "what...no double-click install then Program Files -> GeoXPlanet.exe??" and "wtf is a py file? Is that a virus?"

Patience, my friends...the finer things will come in good time.

Edit - I've considered re-writing GeoXPlanet in C or C++, but I haven't worked very hard on that "sub-project" yet because of time constraints. If/when the C/C++ port becomes (or even writing optimized python modules in C) possible, I'll keep everyone posted on my progress...and I fully intend on the C/C++ port having a no-kidding installer.

 

[ray|raven]

^Dude, an installer doesnt really mean root access.
The user could select to have it installed in a specific folder,
and you could automatically add it to the path, and create a .desktop file in his desktop folder to make it easier to launch the app for him.

And yea, as you said, getting a stable release is much more important than everything else.

Btw, whats the min. req's for this?

 

[rocket357]

Btw, whats the min. req's for this?

I haven't really done any "minimum requirements" testing, honestly...I have an amd64 3000+ (Athlon, not the Sempron model) with 2GB RAM. The RAM is no concern, as I stay under 300 MB pretty much at all times (with virtually everything I use opened up), and the big bottleneck is xplanet image generation. If you have a Xinerama dual-head setup (like I do), it's twice as hard on the CPU bottleneck, but even still I'll get a spike in CPU usage that might last between 1/2 - 2 seconds, then it cools back off. The faster I create new connections (surfing around between websites, downloading torrents, etc...), the more CPU it's going to take. (and if I'm not creating or destroying connections, the CPU usage is very low...peaks at about 8% every little bit). That's why I put a "delay" setting in there to let the user choose how much "CPU time" they want to dedicate to their desktop background =)


But whatever you do, don't put GeoXPlanet on a 486 with the delay on 1 second then fire up 4 torrent downloads... heh.

 

[ray|raven]

^Lolz, the only reason i asked is coz , im on a quite ancient setup,
P4 2.4 with 256Megs.

Btw, does this use OpenGL to draw the planet?

 

[rocket357]

P4 2.4 with 256Megs.

Btw, does this use OpenGL to draw the planet?

P4 with 256 MB should suffice, depending on the desktop environment you're using and how you have it set up.

No, GeoXPlanet is just a control script. The XPlanet project is what GeoXPlanet calls out to for image generation, then GeoXPlanet calls the underlying desktop libs (gconftool, dcop, fbsetbg, etc...) to set the background. No OpenGL required...GeoXPlanet really just sorts through connection data, gathers geolocation info on the relevant data, then formats the two together in a way that XPlanet understands and handles setting the desktop background.

 

[ray|raven]

^Cool, Then i might try it.
Am using Xfce and it leaves nearly 70% of the memory free on startup.

 

[rocket357]

70% of the memory free on startup.

Very nice...you'll probably think I'm crazy, but I'm running fluxbox on my machine...yeah, I could handle kde or gnome multiple times over, but I guess I just like flux...alot.

People who use these slick "minimalistic" wm's never have to deal with thrashing...that's for sure haha

XFCE uses the "root" window for drawing the desktop background, right? If it doesn't, then I guess I need to get on the ball and include XFCE when I include enlightenment...

 

[ray|raven]

^Not at all, I used fluxbox for sometime, but cudnt live without the gtk themes and ended up running the xfce processes needed to get it working.

So, i switched to xfce for good, coz i was running a few processes anyway.

Yeah, xfce uses root to display the wallpaper AFAIK.
And enlightenment is one rocking DE.Too bad it isnt as stable,
if you ask me , i doubt it ever will be.
Darn things under alpha for 10 years now

Btw, its funny how you mention fluxbox, i was searching for some good fluxbox themes, was thinkin of getting back to it for sometime.

 

[rocket357]

I found a short howto for setting the xfce background programmatically...I'll put that in the queue for inclusion in a "near-future" release =)

Actually, I probably should just go ahead and roll that out before bothering with KDE4 support (KDE4 switched away from the dcop interface...doh?). As I see it, KDE4 will pick up relatively quickly, but I've got a bit of time before it becomes mainstream.

And I share your thoughts on enlightenment...man, what a gorgeous desktop! If it wasn't so quirky, I'd probably switch to E-17 full time.

 

[ray|raven]

^Please, link me to that how-to.
I was trying to write a script with gtkdialog to allow random wallpaper changes.

The only way i know is to include the single image link in a backdrops.lst file in the user's config files and choose it as the backdrop.
Later on we can change the image link in the file and run xfdesktop --reload for it to take effect.
Xfce has got to have the most clumsiest way to change the wallpaper.

It will quite some time before KDE 4 stabilizes itself.
If you ask me , dont even bother trying to support it, for IMO its gonna go through quite a lot of changes.

And abt e17, yeah dude, same here.
If only they made a beta release atleast.

 

[rocket357]

^Please, link me to that how-to.
I was trying to write a script with gtkdialog to allow random wallpaper changes.

The only way i know is to include the single image link in a backdrops.lst file in the user's config files and choose it as the backdrop.
Later on we can change the image link in the file and run xfdesktop --reload for it to take effect.
Xfce has got to have the most clumsiest way to change the wallpaper.

It will quite some time before KDE 4 stabilizes itself.
If you ask me , dont even bother trying to support it, for IMO its gonna go through quite a lot of changes.

And abt e17, yeah dude, same here.
If only they made a beta release atleast.

*s7dhansh.wordpress.com/2007/04/18/...d-random-desktop-background-wallpaper-option/

I haven't dug into it much yet, so I can't comment on the quality...just that it exists and it looks promising =) I think you pretty much summed it up, though...so I can't say if that link will help you much.

You're probably right about KDE4...no doubt they'll restructure and reorganize a few times in the coming months. Building support now is probably not in my best interest heh.

An E17 *Beta* release...sigh...that'd be the day!