| I was discussing about the widget set we should use with Winrar the last days and to make the whole thing more community like, here is a log of the discussion. Anyone is free to comment, especially with knowledge about widget sets. So here is the log: (edit: sorry, quote highlighting was lost in the copying process) Message Sent from Winrar Yesterday, 6:19 AM About AnimeCollector Hello! I'm a software developer, and I'm interested in joining your very promising AnimeCollector project. I'm currently studying Computer Science and I have previous programming experience with Python, C/C++, Java, JavaScript, Pascal, PHP, ASP and Perl. I usually use GNU/Linux as my main O.S., but it would be nice to see AnimeCollector as a multiplatform application, since it's already written in Python. Therefore, I would be willing to help you port the code to the wxWidgets toolkit, which is a multiplatform API and looks very nice (nicer than GTK, in my humble opinion) on all platforms without having to rewrite the code. I was planning to do this myself since I wanted an open source, lightweight and multiplatform updater. But then I saw your project and I became very excited. Also, AniDB support is an excellent idea. A little question: Did you use a network sniffer to know how MAL Updater worked? It seems Kotori asked for a custom-made XML for retrieving Anime Lists quickly. I would be happy to hear a reply from you. Please ask me whatever you want. Thanks. Best regards, -Winrar Message Sent from skriticos Yesterday, 12:00 PM re: About AnimeCollector Hello Winrar, first I want to tell you that I was really pleased to read your message, as this is exactly the way I want to have the project going. :) As for your questions: A little question: Did you use a network sniffer to know how MAL Updater worked? It seems Kotori asked for a custom-made XML for retrieving Anime Lists quickly. If you poke around the project page, you'll see that I took over the project from Lattyware who became inactive, so as I found the project it was orphaned and because of the beauty of open soure I took it over and maintain it currently :) That said, the server communication functionality was implemented by Lattyware and I have really no idea how he got his hands on the XML interface, but it is a really nice way to fetch anime data. I was planning to do this myself since I wanted an open source, lightweight and multiplatform updater. But then I saw your project and I became very excited. Also, AniDB support is an excellent idea. Something similar here. I was working on a little application myself before I took over this project. The fun part was that it mostly contained the missing links I was at loss. For the time being I dropped the AniDB support. It was only as a placeholder there anyway, but it would be nice if someone would write a module for that too. Right now I'm more concerned about bringing the application into beta state with MyAnimeList first. I usually use GNU/Linux as my main O.S., but it would be nice to see AnimeCollector as a multiplatform application, since it's already written in Python. Therefore, I would be willing to help you port the code to the wxWidgets toolkit, which is a multiplatform API and looks very nice (nicer than GTK, in my humble opinion) on all platforms without having to rewrite the code. In my experience wxWidgets has it's own set of issues and I'm not that much of a fan of it anymore. GTK+ is also available for all major platforms, so it is already quite protable. But hey, it's an open source project, don't let yourself be distracted of what I say, if you want to write a wx interface, then do it, I'm all for it :) Now some information you should know if you want to engage in development: The project sources are currently hosted on github and revision control is done via git. For my experience, git is a really nice distributed scm/rcs and quite easy to use too + multi platform. It would make sense to get yourself familiar with it if you want to collaborate on the code. It has a really good documentation and you'll know how to use it in half an hour if you take a look. You can also browse the current tree via the github web interface and see where we are right now. As for portability: most of the code is written in a portable way, but there is one exception: my playtracker (players.py) module is using procfs to retrieve currently played files. This will work on all UNIXy platforms (including Mac), but not on Windows. I failed to find a nice way to make this platform agnostic. Maybe you can help here ;) For my coding and design style: as this is an open source project aiming to encourage collaboration and portability, the code is geared to being modular with clear interfaces and readable code commenting. You'll find this if you are browsing the current sources in the repository. If you start to play with the code, it would be nice to keep a maintainable state, so no overly smart coding please. Maintainable is the keyword. Also follow the KISS principle :) As I mentioned, I took over the code from Lattyware who did the prototype implementation in a working way, but it was completely obfuscated and overly complex, so I spent my last few weeks to completely rewrite the whole source (yes, everything). Was (and still is) an interesting educational activity, but I'd like to not do it again :p One last thing, as I mentioned, I'm rewriting the entire source code. This means that the currently checked in head revision is in bits and peaces, but I'm mostly done with the core parts, and plan to release a coherent beta in the coming days. If you want to play with the code, then please use the repository version, as it looks completely different than the tarballs. The central organizational platform and community activity is done in the club: http://myanimelist.net/clubs.php?cid=10642 Here you will also find every relevant links to the project (including the soruce repository (where all the coding is tracked), project updates, issue tracker (which nobody uses) and the link to Lattyware original project site (which is inactive). Hope this answered your questions. Feel free to ask if you have more ;) And finally: if you decide to join the project: Welcome to the team! - s Message Sent from Winrar Today, 2:49 AM re: About AnimeCollector it would be nice if someone would write a module for that too. Right now I'm more concerned about bringing the application into beta state with MyAnimeList first. Yeah, that's the first step. GTK+ is also available for all major platforms, so it is already quite protable. But hey, it's an open source project, don't let yourself be distracted of what I say, if you want to write a wx interface, then do it, I'm all for it :) Oh I know about GTK+. I was suggesting wxWidgets since GTK looks pretty much the same on every platform. wx gives it a native look, besides the toolkit is not limited just to GUIs, it also has its own multiplatform sockets, MySQL routines, etc. It would make sense to get yourself familiar with it if you want to collaborate on the code. Haha Don't worry I've worked through git before. the code is geared to being modular with clear interfaces and readable code commenting. Don't worry. I've worked with developers who completely messed up the code and I know how it feels. I spent my last few weeks to completely rewrite the whole source (yes, everything). Was (and still is) an interesting educational activity, but I'd like to not do it again :p Haha that's a REALLY hard work there. If you are talking about wxWidgets, if I ever decide to implement it I would do it so don't worry about that part. I can't force any work on you. If you want to play with the code, then please use the repository version, Oh I was checking the tarballs, I'll check the rep head in a moment. I'll play around with the code right now and see what I can do. If I have anything useful to commit, I'll contact you. Thanks! Best regards, -Winrar Message Sent from skriticos Today, 7:04 AM re: About AnimeCollector Sounds good. As for the code to play around. Right now I'm working on the myanimelist.py file. On a request of mine, Xinil extended the XML app interface of mal yesterday (he added a last updated field which makes syncing nice), and I was doing a quick dirty sync prototype (the login and fetching already works, the diff and sync has to be tested, will do it later the day.) The stuff in animecollector.py (in the sorce directory) is being moved to main.py which connects everything. It is the next thing on my schedule. The rewriting of the configuration file is done, config.py is working fine. The players module is working fine too, but it is not integrated, and I still have to write a matching module against the database (currently it only finds played files). Setup routine is python standard (was none before :p) So if you want to play with the ui, then main.py would be the place to look, but as I mentioned, right now it is in bits and peaces and the setup routine is still installing the old main (animecollector) script which is not working anymore. Have to go now. Later. I'll give you a note when the myanimelist module is done. I'll try to put the peaces together this evening and get rid of some leftover confusing code, as the code right now is a bit embarrassing for me. :p well, later -s Message Sent from Winrar Today, 8:21 AM re: About AnimeCollector Hi I checked the head revision, and the code looks pretty nice. Good job! myanimelist.py doesn't need any change. I'll try and rewrite the GUI into a simple wxWidgets (wxPython) interface to see if you like it, and recycle the very useful code in myanimelist.py. If you don't like it, we can keep GTK+. What were the issues you ran into when using wxWidgets? Message Sent from Winrar Today, 8:41 AM re: About AnimeCollector Sorry I forgot one thing... Another option would be Qt. I haven't used it but I've heard very good comments about it. Do you have experience with it? The reason I want to rewrite the GUI is because GTK is *too* GNOME oriented, so it doesn't look good in anything that isn't Gnome. It would be a good idea to change that now if you're planning to go cross-platform. Message Sent from skriticos 11 hours ago re: About AnimeCollector I checked the head revision, and the code looks pretty nice. Good job! myanimelist.py doesn't need any change. I'll try and rewrite the GUI into a simple wxWidgets (wxPython) interface to see if you like it, and recycle the very useful code in myanimelist.py. If you don't like it, we can keep GTK+. What were the issues you ran into when using wxWidgets? Thanks, as for wx, the promise it gives is nice, but the actual integration for desktop style settings mostly break. For instance I currently use Stani's Python Editor which is written in wx and it totally breaks with my look in various places like the icons and toolbars (not to mention that it completely ignores my system settings for the edit fields, but that is more likely a design glitch.) I observed similar behavior in other wx apps. I did not like the API either. That said, it's just my personal experience (and some insightful comments of others that had experiences with it when I tried to convince other people back when I thought it would be a good thing for me.) But as I said, my opinion is quite biased and I would enjoy it if you prove me wrong. Sorry I forgot one thing... Another option would be Qt. I haven't used it but I've heard very good comments about it. Do you have experience with it? The reason I want to rewrite the GUI is because GTK is *too* GNOME oriented, so it doesn't look good in anything that isn't Gnome. It would be a good idea to change that now if you're planning to go cross-platform. QT is another thing. The library surely is quite powerful, but the default theme qt apps drop at me when I use them on GNOME are horrible. (Again, this is a personal question of taste). Also as far as I know, the pyqt implementation is quite volatile. Promises 'fun' maintenance challenges. GTK+ also has theme support which could be integrated later on, if it really bothers someone. Note that I really don't want to convince you of GTK+. That's why the GUI is (going to be) easily replaceable. We could put in both versions and add a switcher in the preferences for the user to select whichever he/she likes. Or better an installation option in the setup process to make installation less of a hassle (less installation bindings). Best solution that comes to my mind would be to create 2 packages with different default installation routines to make the installation process as smooth as possible. As the current GUI design is 'keeping it to the basics' - it is a viable solution (not that much overhead). This also would have the advantage of learning from each other's code. What do you think? Another thing, right now I'm the only one in the club that actively does community work/code interface. It would be nice if you would introduce yourself there. An active community is an important part of Open Source and it helps if people see activity :) I just made you an officer in the club to show people you are actively involved. I would also like to post our correspondence in a forum topic so future developers won't discuss the same things we already did - but only if you are fine with it. -s Message Sent from Winrar 32 minutes ago APIs Okay I've read a lot about the APIs so here's a synopsis: (All the packages are powerful so I didn't focus on that, although GTK seems to be a little weaker feature-wise and Wx a little bloated documentation-wise) GTK+ (pyGTK): + Perfect for GNOME + Also good if we're using themes - It doesn't look good natively on KDE, Win32 or Mac OS it seems. Only if we don't use themes. Qt (pyQt): + Perfect for KDE, integrates well with Win32 and Mac OS. + Also good if we're using themes. - Doesn't look good natively on GNOME, although there seems to be some applications that integrate it very well with GNOME look-wise. Only if we don't use themes. wxWidgets (wxPython): + Integrates well since it uses Win32 API in Windows, GTK in GNOME, and Cocoa in MacOS. Maybe not too well in KDE since I haven't seen it uses Qt. It also uses X11. - No theme support, so this would be a good choice only if you don't want themes. |
skriticosApr 14, 2009 12:23 PM
| my 1 cent. How about traditional linux program style and make it "two part". First, make AnimeCollector completely CLI while the other - a gui interface to the first. That way anyone is free to implement whatever toolkit/interface/front-end/whatever without messing with main code. But what do i know, i am just a php/js scripter ^_^" |
| tmth meant to write it as command line utility and then wrap the GUI on top of it. Basically not a bad idea, but I don't feel like to push everything plus kitchen sink over a cli pipe. Actually I was thinking more along the line of writing a simple plug-in system that can load optional code from a plugin directory (including a cli). There are a few different wishes for the application from group members and potential users. One is that it should be a no-frills app. This is what the basic thing will do - load a gui and do it's work out of the box. With a plugin system other features and gimmicks will able to be added without compromising the basic design. But I'm still thinking about it. Stable code-base comes first. |
skriticosApr 15, 2009 2:11 AM
| Continuation of the discussion with Winrar: Message Sent from Winrar 1 hour ago Hi again, still talking about toolkits haha Hi ! I was testing the source code on Windows and Slackware and it looks good. GTK+ doesn't look so bad in Win, although it takes a while to start. I wanted to talk about the "lightweight" objective of the program. The code itself is very lightweight, but I'm afraid the use of GUI Toolkits and Multi-platform support won't give us a lightweight result. Without freezing, GTK+: People would have to install the GTK+ runtime, pyGTK, pyCairo and pyGObject (and Glade?). Everything tops around 10MB. Qt: People would have to install pyQt (23 MB). wxWidgets: People would have to install wxPython (10MB). Most people on Mac and Win won't want to install all those dependencies just to run a program, therefore, I thought freezing the script would be a good way to deploy the software. With freezing, GTK+: Libraries were around 16MB Qt: Libraries were around 23MB. wxPython: Libraries were around 16MB. It seems Qt is not an option for a lightweight program. Even if the other toolkits are lighter, they are not suitable either (16MB). I think they can be compressed more though. If we want to make a multi-platform program without having to re-code it again in the native OS API, a Lightweight program is next to impossible (Kotori's MAL Updater is 4MB). Okay. About Qt... It has a lot of features, I was studying it today, but it seems it's too big for a small program. GTK seems to be the best for our purpose, but remember wxWidgets uses GTK when in GNOME so I don't see any reason why we should use GTK over wx. I will investigate if skins are possible in wx. Message Sent from Winrar 1 hour ago Forgot something... Sorry about the double message. I just saw an application where the wxPython library was just 2MB, so don't think too much about my last message. (I guess they found a way to remove useless stuff) Qt is still too big though. Message Sent from skriticos Hello there, you got a good point there. Well, the only inbuilt solution would be Tkiter, but that one looks really terrible. Maybe I keep it in mind as a fallback option, as it has no external dependencies. For now I'm doing the GTK interface. I also started to think about a plugin interface which could override the GUI code and other stuff. Not exactly there yet though. Putting full blown GTK/QT/wx packages in the tarbals is not so much an option, as we only have limited storage in GitHup. Would need another hosting provider, maybe sourceforge. Hm, I'm thinking about it. Ps. please post development design related topics in the club forum. I'm not the only developer here :) |
| Thinking about it a bit more I decided to say with GTK+ as default interface. The porting staff can then create installation routines for whichever platform they want to port it to. Other widget can override the default GUI using the upcoming plug-in system (either by setting a configuration entry or by command line argument - launcher can be made this way). Still not exactly sure about it though, so it may change if someone convinces me of a better solution. |
More topics from this board
Sticky: » AniChou package buildskazooparcel - Apr 30, 2009 |
12 |
by Wile
»»
Apr 12, 2013 12:34 AM |
|
» AniDB supportWile - Nov 27, 2009 |
1 |
by Necrotex
»»
Nov 30, 2009 4:11 AM |
|
Poll: » Searching a new name!skriticos - Apr 29, 2009 |
37 |
by saka
»»
Nov 1, 2009 11:14 AM |
|
» Launchpad and an ideanewagemage - Jul 29, 2009 |
19 |
by Wile
»»
Aug 24, 2009 1:37 AM |
|
Sticky: » Wishlistskriticos - Apr 27, 2009 |
19 |
by skriticos
»»
May 13, 2009 1:45 AM |