Pandora Pandora Sync Suite

Is it worth to make Pandora Sync Suite for windows?

  • Yes

    Votes: 1 100.0%
  • No

    Votes: 0 0.0%

  • Total voters
    1

Agree as others have said:

Windows Only = Irrelevant
Closed Source = Irrelevant

I could understand it if the other development environments cost money. When they are free, it is hard to believe if you were sharp enough to do what you have already done that you are not sharp enough to be able to share it with the rest of us. Oh well. Don't want to appear as criticizing anyone who is giving their time to make the Pandora more useful. I think you will find a larger than average number of Linux users among Pandora buyers.
 
Last edited by a moderator:
'dflemstr' said:
'bencoder' said:
Because it's done in delphi, which uses win32, and it's just drag and drop(like VB, except with a far superior language behind it)
Look at QtCreator. Drag and drop, and you have C++ as the backing language. Come on, it can't become easier than that. (And Delphi > VB? yeah ok I can agree on that but it's a very small difference)Listen to dflemstr, he's a wise guy. In a way. Or maybe both.

Anyway Qt has a nice designer that allows you to draw GUIs. After that, you can write the actual code in whatever language you please, as long as it has a Qt binding. And it's all cross-platform. Best GUI toolkit on earth, by far.
 
Last edited by a moderator:
General Qt tutorial (not specific for QtCreator):
doc.trolltech.com/4.3/tutorial.html

Or for QtCreator, but you need some experience with Qt to follow some of this:
doc.trolltech.com/qtcreator-0.9.1-beta/creator-writing-program.html

Youtube playlist with QtCreator demo:
www.youtube.com/view_play_list?p=22E601663DAF3A14
 
dflemstr said:
Look at QtCreator. Drag and drop, and you have C++ as the backing language. Come on, it can't become easier than that.
It can be a hell of a lot easier to use Delphi than QT if you know Pascal and don't know C++. It's Streak's program. If he wants to compile it for Windows (or Mac, or BeOS, or whatever), that is his perogative.

Delphi isn't exactly a "Windows-only" language. If you want to run this on a Linux box, install Lazarus and port it yourself. It can't become easier than that.

www.lazarus.freepascal.org
 
Last edited by a moderator:
Chip said:
It can be a hell of a lot easier to use Delphi than QT if you know Pascal and don't know C++. It's Streak's program. If he wants to compile it for Windows (or Mac, or BeOS, or whatever), that is his perogative.


Yes, I just don't like code duplication. Delphi is non-common and therefore not AS portable as say C++/Qt. There will be platforms where the suite will simply not run, and someone would have to develop a separate tool for that platform. Other problems include for example that it becomes difficult to use the (standard) libpnd in Delphi, so the app won't stay up-to-date to PXML changes.

And I'm not forcing anyone to do anything, it IS his prerogative after all, I'm just saying that alot of people here use Linux and therefore will not use the sync suite if it's windows only (which it might be because of other things, granted I don't know much about Pascal even if my mother used to teach the language (for real), but there might be unportable libraries).

And yes, I can be pretty direct about things sometimes, but when people have spoken about Qt in this thread mutiple times without reaction (except on the last page or so) from StreaK whether it would be a good idea or not, then I just felt like presenting the 'other side'. I think StreaK looks like a pretty competent programmer and thought he knew C++ because of that (yea, sue me) so it didn't occur to me that that would be a problem.
 
Last edited by a moderator:
'Chip' said:
Delphi isn't exactly a "Windows-only" language. If you want to run this on a Linux box, install Lazarus and port it yourself. It can't become easier than that.

www.lazarus.freepascal.org
Thanks for the tip. My preference would be that the Pandora just support Conduit which is one of the better Linux sync apps.

Conduit
 
Last edited by a moderator:
I Voted yes, I use Windows at work.

But i should also say that if an Sync application is written for Pandora, it should be Cross Platform compatible code (SDL?) to be available both on windows as on*nix platforms. Because it feels better to be independent of Operating Systems.

But this is only my opinion ;)
 
Last edited by a moderator:
w1ll14m said:
But i should also say that if an Sync application is written for Pandora, it should be Cross Platform compatible code (SDL?) to be available both on windows as on*nix platforms.


SDL isn't the only cross-platform API you know :p It is very tedious to write something in SDL like this.

But yeah, cross-platform is important as stated previously. If we can't port this app, then could we please use open standards or get the Delphi source so that we can make a new one for all the other platforms?
 
Last edited by a moderator:
Username said:
I think so.

Good, because it is. Not. At all. Even remotely similar.

You download PND-files but there's no dependency checking, 'source'-trees and added repositories. This is an enhanced download manager if you will.
 
Last edited by a moderator:
Im almost 100% sure that PSyncSuite will run on WINE.

BTW. Im not planning to add funky stuff to prevent running it on WINE :)

'dflemstr' said:
.
...added repositories...
actually theres an option to add "alternative file repo's" if you dont like archive.openpandora.org or archive.openpandora.pl ...
 
Last edited by a moderator:
I want a Repository that works from the get-go - i.e. Craig and co have one that is getting crammed with new games daily, and we can just do an update to see new apps and get them installed through the normal Linux repo management tools.

Forget having another client that doesn't run *on* the Pandora to do the work. Use Linux. Thats what its there for.
 
Last edited by a moderator:
Well, as some people have probably already noticed, Streak is a pretty hard-headed guy. The main "problem" behind "why not do a cross-platform software" is that streak generally is proficient only at Delphi on Windows and doesn't really want to look at any other solutions besides what he personally thinks is best (even if it sometimes clearly isn't, as proven by several people). I know it's a laughable obstacle, but it's the sad truth :). At least some of you managed to convince him to have a try at using Qt, but we have yet to hear what has come of this try-out.

Second, from what I heard recently, the whole program now kinda "clings" to the whole "use RSS" idea and it doesn't look like EvilDragon wants to add streak's proposed scripts to the archive.

In my opinion, the software should itself have means to check for changes on the archive server, without being dependent on some set proxy-like solutions (server-side scripts, etc. included). It's doable. Also, such an approach could simplify to use other future archives/repositories (as "other sources") for Pandora software besides the "main" ones, as they wouldn't need to somehow be set to given "dependency standards" that the "sync suite" would need in order to be compatible and work properly with the other source.

So the whole program kinda goes "blam", because of such seemingly trivial pseudo-problems.

The idea is cool, just the implementation approach is so so bad :(

Just my 3 eurocents ;)
 
. At least some of you managed to convince him to have a try at using Qt, but we have yet to hear what has come of this try-out.
Second, from what I heard recently, the whole program now kinda "clings" to the whole "use RSS" idea and it doesn't look like EvilDragon wants to add streak's proposed scripts to the archive.

In my opinion, the software should itself have means to check for changes on the archive server, without being dependent on some set proxy-like solutions (server-side scripts, etc. included). It's doable. Also, such an approach could simplify to use other future archives/repositories (as "other sources") for Pandora software besides the "main" ones, as they wouldn't need to somehow be set to given "dependency standards" that the "sync suite" would need in order to be compatible and work properly with the other source.

So the whole program kinda goes "blam", because of such seemingly trivial pseudo-problems.

The idea is cool, just the implementation approach is so so bad :(

Just my 3 eurocents ;)


In my (very limited) free time recently, I've been hacking on a web application for PND management.
A REAL web application (not a CGI script) with dynamic XML files etc (so you don't need 'server side scripts' to create the XML; the XML is generated from the database live, on demand, by the web application itself). The XML file is then VERY easy to parse, and contains all the information you *need*, not the information *available*, making it a 5-minute-job to make a front end for the system.

Using Lift (since, as I said, I only have time from time to time to work on the project and won't use a huge framework that requires a thousand lines of code to do basic things. Even RoR isn't as concise as Lift.), Maven and Tomcat 6.
The app would be a replacement for the File Archive (at least for PNDs) but I don't think that this would be a bad thing; the File Archive is an old application and not very well-suited for package management anyways (really, when you think about it).
And what do you say about OpenID integration?
CRUD support?
Comet components that can notify you about the addition of new packages seconds after they get uploaded (no need for F5 spams)?
Automatic metadata loading from the PXML file inside PNDs?
Advanced searching and sorting of packages in a way optimized for PNDs?
AJAX? jQuery? :p

It's still in pre-BETA of course, and probably won't grow into anything official, but at least I will use it when it's done :p
 
Last edited by a moderator:
I'm kinda confused dflemstr, as I don't know who are you asking (and if you're asking anyone particular at all :D).

I find your web application project idea great :) And you are of course right, with a webapp automatically generating dynamic XML files with the "archives" contents, this would make more sense.

Either way, webapps ain't my cup of tea strictly speaking :)

QUOTE
It's still in pre-BETA of course, and probably won't grow into anything official, but at least I will use it when it's done

Maybe you'll find someone to help you out?

Anyway, I think that your project deserves it's own thread :D
 
Back
Top