.deps/chatpanel.Po:206: *** missing separator. Stop.
the only way i found to fix it, is to remove the folder & re-download a fresh copy from the repo, is there a quicker way to fix it?
SpringLobby
Moderators: Moderators, Lobby Developers
-
BrainDamage
- Lobby Developer
- Posts: 1164
- Joined: 25 Sep 2006, 13:56
every time i update the svn i always get troubles with Po files, (missing separators), even when i do run make clean & autogen again i still encounter probs as in make clean stop throwign the same error when compiling
the only way i found to fix it, is to remove the folder & re-download a fresh copy from the repo, is there a quicker way to fix it?
the only way i found to fix it, is to remove the folder & re-download a fresh copy from the repo, is there a quicker way to fix it?
Just so that everyone knows I'm currently working on the chat function of the client but I havent wrote a single line of code for the join battle, singleplayer, replays, and settings parts of the client yet. If any of it seems tempting to grab and start developing feel free to do so 
The source documentation can be generated with doxygen but i have set up a site with it. It can be found here: http://tc.serveftp.net/lobbydoc/index.html
If you have any questions about the code feel free to PM me or ask in this thread.
The source documentation can be generated with doxygen but i have set up a site with it. It can be found here: http://tc.serveftp.net/lobbydoc/index.html
If you have any questions about the code feel free to PM me or ask in this thread.
I have been examining your code and here are a few points:
- functions should only be virtual if they are supposed to be overridden by derived classes. Do not make all functions virtual.
- asserts are heavily used, instead of real error handling. I'd prefer throwing exceptions when necessary and avoiding runtime logic errors whenever possible (by the use of RAII).
- RAII is not used. See http://www.hackcraft.net/raii/ - it's a technique that should be heavily used in all C++ software because it makes the programs much safer (especially in terms of resource leaks) and reduces the need to check for errors everywhere.
- The naming convention (UpperCamelCaseFunctions, etc) is quite strange, but I suppose that you got it from wxWidgets.
- Functors don't need to be classes. Regular functions do just fine (for example, instead of class UserListCompare and its operator(), you could just have a function. Or in fact, since you are using std::strings in ascending order, don't use a custom comparator at all - std::map sorts correctly without one.
- using or using namespace must not be used in headers' file scope, because it will then propagate to the code that uses the header.
- using namespace std is in fact quite dangerous anyway, as it brings to your programs far more symbols than you can think of (some examples include std::min and std::count). Use it with great care.
- do not pass const std::string as function arguments, as it makes little sense (the argument is a local variable, a copy of the original, thus changes to it do not appear to the caller in any case). Instead, pass std::string or std::string const& (a reference to a const string). The latter avoids making a copy, the first makes one, and there shouldn't be much performance difference either way (std::strings are likely to be copy-on-write optimized).
- it is probably a good idea to divide the project in separate modules, each in their own namespace. One module for networking (potentially reusable for other lobbies), other for GUI.
- no license text is not needed in every file and one can instead state this and the developers in the documentation, reducing code clutter (note: the lack of license text == ├é┬® all rights reserved, so Microsoft cannot steal your code even though you don't have the license text in the same file).
- absolute paths aren't very nice is #include "/home/tc/Projects/springlobby/trunk/src/channellist.h"
- trivial functions should be implemented in headers (inside class {}), to reduce useless code and to allow the compiler to inline them.
I'll keep digging and I'll expect to be working on it during this weekend, once I get a hold of it.
- functions should only be virtual if they are supposed to be overridden by derived classes. Do not make all functions virtual.
- asserts are heavily used, instead of real error handling. I'd prefer throwing exceptions when necessary and avoiding runtime logic errors whenever possible (by the use of RAII).
- RAII is not used. See http://www.hackcraft.net/raii/ - it's a technique that should be heavily used in all C++ software because it makes the programs much safer (especially in terms of resource leaks) and reduces the need to check for errors everywhere.
- The naming convention (UpperCamelCaseFunctions, etc) is quite strange, but I suppose that you got it from wxWidgets.
- Functors don't need to be classes. Regular functions do just fine (for example, instead of class UserListCompare and its operator(), you could just have a function. Or in fact, since you are using std::strings in ascending order, don't use a custom comparator at all - std::map sorts correctly without one.
- using or using namespace must not be used in headers' file scope, because it will then propagate to the code that uses the header.
- using namespace std is in fact quite dangerous anyway, as it brings to your programs far more symbols than you can think of (some examples include std::min and std::count). Use it with great care.
- do not pass const std::string as function arguments, as it makes little sense (the argument is a local variable, a copy of the original, thus changes to it do not appear to the caller in any case). Instead, pass std::string or std::string const& (a reference to a const string). The latter avoids making a copy, the first makes one, and there shouldn't be much performance difference either way (std::strings are likely to be copy-on-write optimized).
- it is probably a good idea to divide the project in separate modules, each in their own namespace. One module for networking (potentially reusable for other lobbies), other for GUI.
- no license text is not needed in every file and one can instead state this and the developers in the documentation, reducing code clutter (note: the lack of license text == ├é┬® all rights reserved, so Microsoft cannot steal your code even though you don't have the license text in the same file).
- absolute paths aren't very nice is #include "/home/tc/Projects/springlobby/trunk/src/channellist.h"
- trivial functions should be implemented in headers (inside class {}), to reduce useless code and to allow the compiler to inline them.
I'll keep digging and I'll expect to be working on it during this weekend, once I get a hold of it.
Last edited by Tronic on 19 May 2007, 05:49, edited 1 time in total.
I took the liberty or rewriting userlist.h. This is a drop-in replacement for the old file (the external interface has not changed) and userlist.cpp can be removed when this is used.
However, since this and the conceptually identical channellist are just trivial wrappers over std::map, I would recommend getting rid of these and accessing the std::map directly.
System is, for some reason, inherited from ChannelList and UserList, but this doesn't seem to make sense. Is System a list of channels? Is it a list of users? Nope. Instead, it *contains* those things, which suggests that they should be its data members.
Code: Select all
#ifndef _USERLIST_H_
#define _USERLIST_H_
#include "user.h"
#include <map>
//! @brief std::map<> list that stores User pointers.
typedef std::map<std::string, User*> user_map_t;
//! @brief user_map_t iterator.
typedef user_map_t::iterator user_iter_t;
class UserList
{
public:
void AddUser( User* user ) { m_users[user->GetNick()] = user; }
void RemoveUser( std::string const& nick ) { m_users.erase(nick); }
User* GetUser( std::string const& nick ) {
user_iter_t u = m_users.find(nick);
return u == m_users.end() ? NULL : u->second;
}
bool UserExists( std::string const& nick ) {
return m_users.find(nick) != m_users.end();
}
int GetNumUsers() { return m_users.size(); }
protected:
user_map_t m_users;
};
#endif //_USERLIST_H_
System is, for some reason, inherited from ChannelList and UserList, but this doesn't seem to make sense. Is System a list of channels? Is it a list of users? Nope. Instead, it *contains* those things, which suggests that they should be its data members.
The userlist replacement semms to wok nicley, gj
The reason I use a wrapper for map is that I want the interface to be clean, and sooner or later I will attach more advanced features to it, like filtering and stuff like that.
I'm not sure about the System class myself.It's meant to wrap all the underlaying classes together, classes that has nothing to do with the Ui. It might not be needed though. The UserList and ChanelList objects could just be separeted from it. The only things I'm not sure where to place elseware is the Connect, Disconnect Functions and the connection handling. I could put it i the UI class. I'm open to any sugetsions, the code is not that large yet so its easy to do structural changes in it now, the sooner the better.
The reason I use a wrapper for map is that I want the interface to be clean, and sooner or later I will attach more advanced features to it, like filtering and stuff like that.
I'm not sure about the System class myself.It's meant to wrap all the underlaying classes together, classes that has nothing to do with the Ui. It might not be needed though. The UserList and ChanelList objects could just be separeted from it. The only things I'm not sure where to place elseware is the Connect, Disconnect Functions and the connection handling. I could put it i the UI class. I'm open to any sugetsions, the code is not that large yet so its easy to do structural changes in it now, the sooner the better.
Tronic, I just saw you previous post with your points and they all seem resonable. I will start to try and reformat the places I find. As for the RAII thing, I have no idea what it is but I will look into it now and see what it is as soon as possible.
Thanks a lot, this will help make better code and a better client.. It's easy to overlook things when doing something on your own
Thanks a lot, this will help make better code and a better client.. It's easy to overlook things when doing something on your own
-
BrainDamage
- Lobby Developer
- Posts: 1164
- Joined: 25 Sep 2006, 13:56
i hope this can help, this is a set of raninking icons i edited for unitylobby.
i'm no designer as i can't start from scratch, but if you give me some half-decent drawings, i think i can scale, polish & make them to fit the lobby
http://www.thebestforumintheworld.com/i ... post&id=30
do-as-you-wish-i-don't-care license
i'm no designer as i can't start from scratch, but if you give me some half-decent drawings, i think i can scale, polish & make them to fit the lobby
http://www.thebestforumintheworld.com/i ... post&id=30
do-as-you-wish-i-don't-care license
-
clericvash
- Posts: 1394
- Joined: 05 Oct 2004, 01:05
The rank icons are great and the flags do their job too, but more high quality icons are needed. The application icon should be done in high resolution (at least 32x32, preferrably also 48x48 and 64x64 and/or SVG). The chat and join (battleroom?) icons need to be redone (with clear pictures and antialiased & hinted text). And then there are the bot/op/whatever flags next to the nicklist.
) competition for the linux users! Reminds me of buses here in London, you wait ages for 1 and suddenly 3 come at once!New screenshot with the join tab. It would be nice with some feedback or new ideas.
Well nothing special, pretty straightforward i think. Will add rank icons and maybe flag icon that tells where the host is from. Below the list a list of users on selected server and minimap with some info will be shown later.
Well nothing special, pretty straightforward i think. Will add rank icons and maybe flag icon that tells where the host is from. Below the list a list of users on selected server and minimap with some info will be shown later.