Considering a MacOS X Client

[egg]

a couple of months.

In IRL time or 0.6 time?

[PetriW]

irl time

I mean like, I can't really get a job with delphi in sweden but there's plenty for c++.

[WoLpH]

To be honest I'd love to work on a full client for mac os x but I lack a critical component... A macintosh, solve that and I'll release one in a couple of months.

http://pearpc.sf.net/

[PetriW]

http://pearpc.sf.net/

You have any idea how slow PearPC is?

[WoLpH]

Yes

I was just saying that it is possible without a mac, you don't have to do it for me anyway, I only run linux (and I don't have a mac)

[zosky]

i didnt realize PetriW almost burst a nut putting together the winblows client. props for the hard work. thumbs up

why dont we make a *nix full client. from what i understand its not rocket science to then port it to darwin (aka osX)

is that a possable solution ?

[rant] still hate bill. the fooker should burn. who else puts out such buggy shnat and markets it globally. yeah he has brain washed the common folkes into thinking thier is no alternative, thats good business. but since he is amarican he has no ethics. sorry to all you poor folkes south of the border that dont fit in the same bucket as him. i like my igloo, come up here some time, youll notice a diffrence [/rant]

[WoLpH]

Actually, its even easyer than that, since you can use the same compilers and the same libraries its not even needed to port it.
If you build a program that works in x.org (linux/bsd/*n?x) then it will work in OS X aswell.

[phip]

If you build a program that works in x.org (linux/bsd/*n?x) then it will work in OS X aswell.

Ugh... X11 integration is nearly nonexistent on OS X. X apps run in their own little world. No standard GUI widgets, keyboard shortcuts, or even drag and drop (a must for a file-based application)

To be good enough, it really has to be a native application with the Cocoa API. I'm prepared to do it. Maybe I should seen EXP some cookies. Hm, maybe I really should. Does anyone know if he likes oatmeal, sugar, or chocolate chip?

[WoLpH]

If you build a program that works in x.org (linux/bsd/*n?x) then it will work in OS X aswell.

Ugh... X11 integration is nearly nonexistent on OS X. X apps run in their own little world. No standard GUI widgets, keyboard shortcuts, or even drag and drop (a must for a file-based application)

Ok I have to admit that I can't speak out of my own experience (because of the lack of macs around here) but I'm sure that I've read something like that some time ago.
It was even possible to run KDE and such on a mac, so..... those stories aren't correct?

[nich]

My idea of a multiplatform client is a wxBase based (note: not wxGTK, wxWin or wxMac, but wxBase only!) backend that can communicate with anidb and manage the local copy. Basically, do what aom does without the GUI.

And then some documentation about how to use that lib, so it'd be possible to have multiple front-ends to multiple OSes.

And it doesn't look like writing the GUI is the problem, right?

[WoLpH]

My idea of a multiplatform client is a wxBase based (note: not wxGTK, wxWin or wxMac, but wxBase only!) backend that can communicate with anidb and manage the local copy. Basically, do what aom does without the GUI.

Actually, I am planning on building such a client.

I'm currently PM'ing with EXP about the TCP API, and thats mostly because I don't want to use UDP. UDP isn't meant for stuff like this, its unreliable as hell and with something like this you want your messages to arrive correctly

[phip]

It was even possible to run KDE and such on a mac, so..... those stories aren't correct?

This is absolutely correct, in fact I've done it, running KDE over OS X. Apple has done an admirable job of implementing the X window system. But X apps still don't feel like regular ones. They're rather awkward, and lack the standard elements I pointed out.

My idea of a multiplatform client is a wxBase based (note: not wxGTK, wxWin or wxMac, but wxBase only!) backend that can communicate with anidb and manage the local copy. Basically, do what aom does without the GUI.

Actually, I am planning on building such a client.

WoLpH, keep us informed of your progress with this! I'd be willing to help, and write the Mac frontend. Hmm, how to design the API - there will be tons of data to pass back and forth...

But argh! If you intend to use wxBase, you'll be using C++. I can't help you there. A nice POSIX C AniDB library. Now that's what we need!

[zosky]

yall sound like eminem in the last 10 minutes of 8mile
blahbitee-bloo-blah blah blah blah blah

but thats wicked, nice to see some progress
im gettin exited

[WoLpH]

But argh! If you intend to use wxBase, you'll be using C++. I can't help you there. A nice POSIX C AniDB library. Now that's what we need!

I have to admit I'm a console junky anyway, I do have X running but I do most of my work in a console.
Besides that, I'm a horrible designer so doing anything besides console clients will be a disaster

Here is a part of my PM to EXP

The client I'm planning on creating will contain the following features

• Create a hash of the local files (by scanning the directories recursively)
• Renaming files according to the data on AniDB
• Autoscan for additions to the directories and exporting them to a list
• Saving the comments placed on AniDB in the folder where the anime is located
• Exporting all files to different formats where the user can select what info he wants (csv, xml, sql)
• Autoadd files to AniDB if added to one of the folders

[exp]

Well,

I still think that the UDP API is exactly what you need.
The idea behind using UDP is that it reduces server load and bandwith usage and that is very important for clients which want to do file-adding-to-mylist-by-hash without a complete local copy of all anidb file data.
So basically there are two way of accessing anidb, lightweight via UDP or heavy via TCP. Where heavy means that you will have to cope with a potentially 100MB+ local database even if you want to add no more than a single file to your mylist.

BYe!
EXP