Re: [CenterIM-devel] Upcoming disconnection of centerim.org
On 9. Aug 21 22:51, Frank Altpeter wrote: > This doesn't mean that the code itself will vanish, but I'm going to shut > down the related mailing lists centerim-devel (7 emails in 2019, 8 in > 2020, 0 in 2021) and centerim-users (no traffic since 01/2017), as well as > the wiki on www.centerim.org and the download directory. > CenterIM 4 is dead for more than 10 years now and CenterIM 5 is hosted on > github (https://github.com/petrpavlu/centerim5) as I just learned, so > nothing important gets lost. This GitHub location was created some time ago by me to have a mirror of the CenterIM 5 repository and to be able to use Travis CI for automated testing. The project page for CenterIM remained at centerim.org and is linked from the GitHub page. I'm not sure if someone from the community is willing to take over the hosting but as I am myself not able to do so, my general thinking was to use services provided by GitHub. It can be under this mentioned location or a GitHub organization could be set up for the project. > I really enjoyed being part of this community, but since it looks that > there's almost no one left, I think it's time to move on. > Well, at least for me. Thank you again for running the CenterIM infrastructure for so long! Best regards, Petr -- ___ Centerim-devel mailing list Centerim-devel@centerim.org http://centerim.org/mailman/listinfo/centerim-devel http://www.centerim.org/
Re: [CenterIM-devel] Skype conversation rooms
On 15. Sep 20 11:38, Siim Salonen wrote:
> Still there were some issues. After a few days it forgot the topic and
> started using 19: names again.
> After investigating a bit more it seems better idea to patch skypeweb and
> use PurpleConversation->title instead of PurpleConversation->chat->topic.
> It's not enough to call purple_conversation_set_title() in skypeweb because
> the title is set after labels are already drawn. So I added a signal
> handler for "conversation-updated".
Tracking changes to conversation titles looks sensible to me and is something
that would be good to add. Below are proposed changes to the patch.
> diff --git a/src/Conversations.cpp b/src/Conversations.cpp
> index 16891b7..4f5b65e 100644
> --- a/src/Conversations.cpp
> +++ b/src/Conversations.cpp
> @@ -145,6 +145,10 @@ Conversations::Conversations()
> handle, "buddy-typing", this, PURPLE_CALLBACK(buddy_typing_), this);
>purple_signal_connect(
> handle, "buddy-typing-stopped", this, PURPLE_CALLBACK(buddy_typing_),
> this);
> + purple_signal_connect(
> +handle, "chat-topic-changed", this, PURPLE_CALLBACK(topic_changed_),
> this);
> + purple_signal_connect(
> +handle, "conversation-updated", this,
> PURPLE_CALLBACK(conversation_updated_), this);
>
>// Setup callbacks for connections in relation to conversations.
>void *connections_handle = purple_connections_get_handle();
> diff --git a/src/Conversations.h b/src/Conversations.h
> index 51129f8..240c142 100644
> --- a/src/Conversations.h
> +++ b/src/Conversations.h
> @@ -153,6 +153,16 @@ private:
>}
>void buddy_typing(PurpleAccount *account, const char *who);
>
> + static void topic_changed_(PurpleAccount *account, const char *who, const
> char *topic, void *data)
> + {
> +// reinterpret_cast(data)->updateLabels();
> + }
Handler for "chat-topic-changed" can be removed.
> +
> + static void conversation_updated_(PurpleConversation *conv,
> PurpleConvUpdateType type, gpointer data)
> + {
> +if(type==PURPLE_CONV_UPDATE_TITLE) reinterpret_cast *>(data)->updateLabels();
> + }
> +
Handler for "conversation-updated" can be sped up by calling updateLabel() to
update only the changed conversation title. Something as follows should work:
static void conversation_updated_(PurpleConversation *conv,
PurpleConvUpdateType type, gpointer data)
{
reinterpret_cast(data)->conversation_update(conv, type);
}
.. and in Conversations.cpp:
void Conversations::conversation_updated(PurpleConversation *conv,
PurpleConvUpdateType type)
{
if (type != PURPLE_CONV_UPDATE_TITLE)
return;
int i = findConversation(conv);
if (i == -1)
return;
updateLabel(i);
}
Thanks,
Petr
--
___
Centerim-devel mailing list
Centerim-devel@centerim.org
http://centerim.org/mailman/listinfo/centerim-devel
http://www.centerim.org/
Re: [CenterIM-devel] Skype conversation rooms
On 5. Sep 20 19:05, Siim Salonen wrote: > Hello, > skype sets room names as 19:d63d0c3cb720464097dede7d05e42a68, > 19:db9b301c259f4da1b99f2f6cecdcd210 etc. > Does other protocols face same issue? Not that I'm aware of. > I made a patch to use topic as conversations label, but shoud I make it > skype specific or global? I think the change should not be made global because other protocols use sensible room names. Could you please post the patch to the list? Thanks, Petr -- ___ Centerim-devel mailing list Centerim-devel@centerim.org http://centerim.org/mailman/listinfo/centerim-devel http://www.centerim.org/
Re: [CenterIM-devel] Emoticon rendering bug
On 16. Dec 19 17:30, Wade Berrier wrote: > Seems to definitely be affected by tmux :( > > Various terms outside of tmux work, various inside don't work. > > Also it looks like I couldn't reproduce this inside of screen. > > Any ideas? I still have no luck reproducing the issue on my side. If the problem appears only with tmux then my first suggestion is to collect logs from the program as described on its GitHub page [1]. The logs should contain information about on-screen width of all characters as determined by tmux. There is possibly some mismatch what CppConsUI, ncurses, tmux and the terminal emulator calculate as on-screen width of the displayed emojis. [1] https://github.com/tmux/tmux/blob/master/.github/ISSUE_TEMPLATE.md Petr -- ___ Centerim-devel mailing list Centerim-devel@centerim.org http://centerim.org/mailman/listinfo/centerim-devel http://www.centerim.org/
Re: [CenterIM-devel] Emoticon rendering bug
On 16. Dec 19 09:07, Wade Berrier wrote: > Looks like there's still an issue. See the attached screenshots. I seem to be unable to reproduce this issue. I did a clean installation of Fedora 31 and tested the behaviour in gnome-terminal, xfce4-terminal, konsole and xterm without issues. Could you please provide information what terminal emulator you use and some steps how to reproduce the problem? Thanks, Petr -- ___ Centerim-devel mailing list Centerim-devel@centerim.org http://centerim.org/mailman/listinfo/centerim-devel http://www.centerim.org/
Re: [CenterIM-devel] Emoticon rendering bug
Dne 2019-12-03 01:59, Wade Berrier napsal: I'm running ba658ba (current mob) and wanted to report that emoticons are not getting rendered correctly. It appears they are taking 2 "spaces" but the drawing system thinks it's only one. Thanks for the report. This should be now fixed by b03a616. Let me know if there is still some issue. Cheers, Petr -- ___ Centerim-devel mailing list Centerim-devel@centerim.org http://centerim.org/mailman/listinfo/centerim-devel http://www.centerim.org/
Re: [CenterIM-devel] UI hangs while loading log history
On 19. Apr 17 23:30, Wade Berrier wrote: > I noticed this after the big merge these last few weeks. > > I did some minor profiling and it looks like loading conversations with a > lot of history hangs the UI for a couple of minutes. > > It wasn't apparent what exactly has changed. > > Any ideas? Hi Wade, I have added a small optimization to TextView in 4937fba714c6ab5e1ff075a47aa9355e3f103962 to address this problem. Please let me know if you still observe some issues after this change. Note that a new implementation of TextView that I work on is also not so far from being completed. That should make the speed of this widget in general much better because it reworks how screen lines get calculated. The current implementation prepares screen lines for all content, which gives a bad performance when the widget is resized and also requires extra memory to store data about all screen lines. The new implementation calculates screen line data only for the lines that are actually displayed by the widget. Regards, Petr -- ___ Centerim-devel mailing list Centerim-devel@centerim.org http://centerim.org/mailman/listinfo/centerim-devel http://www.centerim.org/
Re: [CenterIM-devel] UI hangs while loading log history
On 19. Apr 17 23:30, Wade Berrier wrote: > I noticed this after the big merge these last few weeks. > > I did some minor profiling and it looks like loading conversations with a > lot of history hangs the UI for a couple of minutes. > > It wasn't apparent what exactly has changed. > > Any ideas? Hi Wade, Thank you for reporting the issue. This is certainly an unintended change. I will investigate the problem in the next few days. Regards, Petr -- ___ Centerim-devel mailing list Centerim-devel@centerim.org http://centerim.org/mailman/listinfo/centerim-devel http://www.centerim.org/
Re: [CenterIM-devel] [PATCH] Re-join conversations on account reconnect
Hi Wade,
The patch generally looks ok, feel free to land it. Inlined are
some suggestions to improve the solution.
On 5. Feb 16 13:37, Wade Berrier wrote:
> diff --git a/src/Conversations.cpp b/src/Conversations.cpp
> index 58a0c81..c35f232 100644
> --- a/src/Conversations.cpp
> +++ b/src/Conversations.cpp
> @@ -148,6 +148,13 @@ Conversations::Conversations()
>PURPLE_CALLBACK(buddy_typing_), this);
>purple_signal_connect(handle, "buddy-typing-stopped", this,
>PURPLE_CALLBACK(buddy_typing_), this);
> +
> + // setup the callbacks for connections in relation to conversations
> + void *connections_handle = purple_connections_get_handle();
> + purple_signal_connect(connections_handle, "signed-on", this,
> + PURPLE_CALLBACK(account_signed_on_off_), this);
> + purple_signal_connect(connections_handle, "signed-off", this,
> + PURPLE_CALLBACK(account_signed_on_off_), this);
Only signed-on could be connected because
Conversations::account_signed_on_off() does not do any processing
for the signed-off signal.
> }
>
> Conversations::~Conversations()
> @@ -432,6 +439,44 @@ void Conversations::buddy_typing(PurpleAccount *account,
> const char *who)
>updateLabel(i);
> }
>
> +void Conversations::account_signed_on_off(PurpleConnection *connection)
> +{
> +// If signed on
> +if(PURPLE_CONNECTION_IS_CONNECTED(connection)) {
I think this check can be avoided if only the signed-on callback
is registered.
> +
> +for(ConversationsVector::iterator conv_child =
> conversations.begin(); conv_child != conversations.end(); ++conv_child) {
> +
> +if(!conv_child->conv)
> +continue;
This check is not necessary, conv_child->conv cannot be NULL.
> +
> +PurpleConversation *purple_conv =
> conv_child->conv->getPurpleConversation();
> +
> +// Only process chats for this connection
> +if(purple_conversation_get_gc(purple_conv) == connection) {
> +
> +// TODO: add and consult "want-to-rejoin" configuration
> parameter?
> +
> +// Look up the chat from the buddy list
> +PurpleChat * purple_chat = purple_blist_find_chat(
> +purple_conversation_get_account(purple_conv),
> +purple_conversation_get_name(purple_conv)
> +);
> +
> +if(!purple_chat)
> +continue;
What if the chat does not exist in the buddy list? Should the
chat be reconnected by using chat_info_default()? Pidgin [1] and
Finch [2] do that.
> +
> +GHashTable *chat_components =
> purple_chat_get_components(purple_chat);
> +
> +if(chat_components) {
> +serv_join_chat(connection, chat_components);
> +} else {
> +LOG->error(_("Unable to re-join chat '%s'"),
> purple_conversation_get_name(purple_conv));
> +}
This check does not seem to be needed,
purple_chat_get_components() should never return NULL.
[1] https://hg.pidgin.im/pidgin/main/file/fa3c41b69e47/pidgin/gtkconv.c#l7573
[2] https://hg.pidgin.im/pidgin/main/file/fa3c41b69e47/finch/gntconv.c#l340
Thanks,
Petr
--
___
Centerim-devel mailing list
Centerim-devel@centerim.org
http://centerim.org/mailman/listinfo/centerim-devel
http://www.centerim.org/
Re: [CenterIM-devel] [PATCH] Conversation Room List
On 12. Mar 15 23:20, Wade Berrier wrote: Hello, I've finished a rough implementation of conversation room lists. I didn't know where to post, so I posted to my github account: https://github.com/wberrier/centerim5 Some questions: 1. how's the placement of the room list? Another idea I had was to put the roomlist in the buddy list in a similar treeview, collapsible per room. 2. For the list, is ListBox the most appropriate widget to use? It seems so, because eventually it would be nice if the roomlist could take focus, scroll, and provide context menus for each member. Can someone propose a recommended widget hierarchy for this? 3. Is it possible to get ListBox to not pad between names/widgets? 4. There was a small bug in VerticalLine that prevented it's use 5. sorting of the room list is pretty messed up Comments? Feedback? Hi Wade, Thank you for the patch. I will have a look next week and answer your questions. Petr -- ___ Centerim-devel mailing list Centerim-devel@centerim.org http://centerim.org/mailman/listinfo/centerim-devel http://www.centerim.org/
Re: [CenterIM-devel] German translation
On 28. led 13 13:19, Jonas wrote: Good morning, Yes I'm using centerim5 and could translate it. But how? I have never translated a program. Jonas, CenterIM 5 uses a system called GNU gettext [1] for its internationalization and localization support. This is a standard system for this task which is used by most open-source programs. The official GNU gettext documentation [2] is a comprehensive source about this system. It is a good idea to read the first several sections of this manual and then sections that describe how to work with PO and MO files. Note that the documentation describes raw gettext commands which you have to use for creating translations. The CenterIM 5 build system has some automatization for these tasks, for example, you do not have to run msgfmt to compile your PO file to an MO file, instead just run make in your CenterIM 5 build directory and the build system does the PO compilation for you. Another important thing to know is that CenterIM 5 picks its MO files only from the installation directory. If you run the program directly in your build directory then translations stored in this directory will not be found. I hope this helps, let me know if you have any questions. [1] http://www.gnu.org/software/gettext/ [2] http://www.gnu.org/software/gettext/manual/gettext.html Regards, Petr -- ___ Centerim-devel mailing list Centerim-devel@centerim.org http://centerim.org/mailman/listinfo/centerim-devel http://www.centerim.org/
Re: [CenterIM-devel] German translation
On 23. Jan 13 18:53, Jonas wrote: Hi, sorry, my mistake. I asked if somebody is interested in a german translation of the wiki. Hello Jonas, I'm not sure if it's worth translating the wiki but if you use CenterIM 5 then you might be interested in updating its German translation. It seems to be a bit outdated. Kind regards, Petr Pavlu -- ___ Centerim-devel mailing list Centerim-devel@centerim.org http://centerim.org/mailman/listinfo/centerim-devel http://www.centerim.org/
Re: [CenterIM-devel] commit 35badcdd72909ef5f306b88aee9582f4f0c565be
On 2. led 13 00:53, CBke wrote: 3) more similar messages #: src/Accounts.cpp:401 and #: src/Accounts.cpp:404 we have msgid + [%s] %s: New add request from %s (%s) and msgid + [%s] %s: New add request from %s while in #: src/Accounts.cpp:424 and #: src/Accounts.cpp:427 we have msgid + [%s] %s: New authorization request from %s (%s) and msgid + [%s] %s: New authorization request from %s add or leave out the word 'authorization' in both cases. I'm not sure if I correctly understand this suggestion. There are two types of requests: add and authorization. The add request happens when someone you don't have on your list added you, in this case you are prompted to add them to your list too. The authorization request is used when someone adds you to their list and then you are asked to give them authorization to see your account's presence. I could probably merge the two messages for each request into one message if that's what you mean. That is the suggestion, since I do not rally see a difference from a (end)user perspective. There is a difference. I'm personally more interested in authorization requests because they mean that someone new is trying to communicate with me while add requests aren't so important. If, for example, I configure that friends should be authorized to see my status / send me messages, and I am already on their list (historically), but did not yet authorize them. In this case an authorization request would be the same as an add request if I configured the account everybody can see my status / send me messages. I'm not sure if I understand you correctly. Authorization request = ask for authorization + ask for adding the user to your buddy list (if he isn't in your list already), add request = ask for adding the user to your buddy list. I'm not sure how this manifests itself in the different protocols. So technically these are two totally different things, I just don't know if you want to make this distinction in the UI. I have not found how to see if I only have a fiend in my list, or am also authorized by that friend. There is currently no easy way how to get this information in the Cim5 UI. However if you aren't authorized by your friend then there should be an item in the context menu to request the authorization. -- Petr Pavlu -- ___ Centerim-devel mailing list Centerim-devel@centerim.org http://centerim.org/mailman/listinfo/centerim-devel http://www.centerim.org/
Re: [CenterIM-devel] New admin
On 29. Jun 12 14:58, Frank Altpeter wrote: Hi list, For your information: Petr Pavlu aka Setupji has been granted administrator rights to the wiki and upload permission to the download directory to keep up the good work on cim5. As a matter of fact, he's now also reachable as setu...@centerim.org and will be reading webmas...@centerim.org as well. As always, please use these addresses for related topics only. Thank you, much appreciated! -- Petr Pavlu -- ___ Centerim-devel mailing list Centerim-devel@centerim.org http://centerim.org/mailman/listinfo/centerim-devel http://www.centerim.org/
Re: [CenterIM-devel] Contributions: Hide header, typing notifications
On 11. čen 12 08:23, Alexander Matz wrote: Hi centerim 5 developers, the homepage said you should send a mail when you make any commits, so here it is. I added an option to hide the header because I like to use the space available. I about hiding the footer, too. Is there anything wrong with this? The commit is kind of screwed up (two commits, one with the title merge branch 'mob'..., because I was a bit too fast when merging and pushing the commit, sorry for that. Sending and receiving typing notifications is added also. The implementation is close to the one in pidgin. Receiving the notification is done via signals, because I couldn't find any Ui Ops for this. The trigger to send a typing notification is Conversation::ProcessInput (when the view didn't handle the input). This seemed like the most suitable place. So far from my side and thank you all for this great instant messenger. Hello, the code looks good, I polished it only a bit. Thank you for your contribution! -- Petr Pavlu -- ___ Centerim-devel mailing list Centerim-devel@centerim.org http://centerim.org/mailman/listinfo/centerim-devel http://www.centerim.org/
Re: [CenterIM-devel] Buddylist colorization
Hello On 13. Dec 11 11:53, Per-Henrik Lundblom wrote: I just started using cim5 migrating from centerim4 because of UTF-8 functionality. Previously I have used (through own patches or offical support, don't remember) separate color configs for contacts with different online status. This is a really good way to get a good overview over the contacts. Buddy-list colorization is a part of the official cim4 code. Besides colorization based on online statuses, it also allows colorization based on buddy protocols. Noticed that this feature is missing in cim5 and started looking at how to implement this. I guess such customizations should be done using seperate colorschemes for contacts with different status. That is, instead of having all BuddyListBuddies belonging to colorscheme buddylistbuddy there should be something like buddylistbuddy_away etc? Either that or adding more colorscheme properties to the button widget. what is the way that most conforms to current cim5 design? I prefer the first option, using buddylistbuddy_away, etc. It seems similar to what cim4 does. Here are some hints: Buddy list is driven by libpurple callbacks, these callbacks are set in src/BuddyList.cpp: BuddyList::BuddyList(). The update callback is important in this case, it's handled by the BuddyList::update() method, which in turn calls an Update() method of used BuddyListNode (BuddyListBuddy, BuddyListChat, BuddyListContact, BuddyListGroup). That means the best place to change current colorscheme is probably in BuddyListBuddy::Update() and in BuddyListContact::Update(). See BuddyListNode::GetBuddyStatus() and src/Utils.cpp:GetStatusIndicator() how to get a primitive status. Note: contact is a group of one or more buddies. Cim5 hides buddies by default, you can use the plus key (`+') to display buddies associated with a contact. Colors are currently hardcoded, they can be altered in src/CenterIM.cpp: CenterIM::ColorSchemeInit(). Thank you for taking interest in cim5, I'm looking forward to your patch. -- Petr Pavlu -- ___ Centerim-devel mailing list Centerim-devel@centerim.org http://centerim.org/mailman/listinfo/centerim-devel http://www.centerim.org/
Re: [CenterIM-devel] CenterIM 5 progress
On 12. kvě 11 20:16, Jostein Berntsen wrote: On 10.05.11,12:27, Jostein Berntsen wrote: Thanks. I ran the command and got this output: objdump -T /usr/lib/libxml2.so | grep -E \ '(xmlSAXUserParseMemory|xmlStrcmp)' 0009e250 gDF .text 0077 BasexmlStrcmp 00040120 gDF .text 00e4 BasexmlSAXUserParseMemory I will check more regarding my libxml2 installation. I have tried to reinstall my libxml2, libxml2-devel, libpurple and libpurple-devel packages, but with no difference. The same installation error occurs. Do you have any clue to what I should try here? Output of that command on my computer: 0009cd40 gDF .text 006d LIBXML2_2.4.30 xmlStrcmp 0003e320 gDF .text 00d7 LIBXML2_2.4.30 xmlSAXUserParseMemory Note the difference in the next to last column. /usr/local/lib/libpurple.so: undefined reference to `xmlStrcmp@LIBXML2_2.4.30' /usr/local/lib/libpurple.so: undefined reference to `xmlSAXUserParseMemory@LIBXML2_2.4.30' I think the problem lies in the symbol version, `Base' (your version) != LIBXML2_2.4.30 (required version). -- Petr Pavlu -- ___ Centerim-devel mailing list Centerim-devel@centerim.org http://centerim.org/mailman/listinfo/centerim-devel http://www.centerim.org/
Re: [CenterIM-devel] Hello!
On 30. Mar 11 15:10, Ion Cebotari wrote: Hello, My name is Ion and I'm a beginning programmer. I have small experience in programming C/C++ and Python. Centerim has been my favourite IM software for almost three years, so i've decided to join the development mail list and help with anything I can. Hello, and welcome, it's always nice to see new people interested in cim development. I still have no experience in working with libpurple, ncurses or other libs in use with centerim, so now i'm just trying to read and understand the code of Centerim 5. Libpurple API should be relatively easy to pick up. It's well documented in header files. You shouldn't need any curses knowledge unless you are going to write new widgets (or edit drawing methods of current ones). As soon as I would understand your code, I'll try to help you with its development. Or if there are some things that could be done by me and your hands simply didn't get there, please tell me. Thank you very much for your attention. Here are some suggestions (from easier tasks to harder ones): * Implement a user info window that is opened for a currently focused contact/buddy when the user presses a specified key. You can inspire yourself in finch or pidgin. For finch see draw_tooltip_real() in gntblist.c, for pidgin see pidgin_retrieve_user_info() in gtkutils.c and pidgin_notify_userinfo() in gtknotify.c. Pidgin implementation may be a bit harder. * Buddy list customization. Implement Mode1, Mode2 and flat mode as known from cim4. See how buddy list is rebuilt in pidgin: redo_buddy_list() in gtkblist.c. * Implement account UI ops, especially request_add(), request_authorize() and close_account_request(). -- Petr Pavlu -- ___ Centerim-devel mailing list Centerim-devel@centerim.org http://centerim.org/mailman/listinfo/centerim-devel http://www.centerim.org/
Re: [CenterIM-devel] CenterIM5 patches
* It's preferred (im cim5) to use C++ containers instead of GLib containers. Hmm.. I am not very found of STL/C++ containers myself and rather like GLib functions. I can change this but would it not be better to use GLib functionallity since cim is interfacing pidgin? I have not looked in to pidgin much but I guess they will deliver GLib lists etc. If STL/C++ is used that would mean conversion functions for all these or mixed types where pidgin is using GLib and cim is using C++. What do you think? GLib list functions are used where libpurple provides GList but own data in cim5 are stored in C++ containers. No conversion is needed because usually only some kind of mapping between libpurple struct pointer and UI is done (PurpleAccount* - Label, PurpleConversation* - Conversation object, ...). C++ containers are preferred because they are easier to use (ok, this is relative) and safer (no explicit conversion from void* is needed). * Protocol name cannot be used as a key in a `statuses' GList because cim5 is aiming to support more than one account per a protocol. Agree; this was more of a let's get it working first with generic (one per proto) support. It does not break multi-per-proto but makes the indicators wrong in that case. I thought about this and could not come up with a nice UI model for multi-per-proto. Could this be a TODO? PurpleAccount* can be used as a key. It will also speed up the searching in the list because only pointers are compared, not strings. Yes, it can be a todo but it should be mentioned in the code. One thought, does this ::width() support utf8? strlen does not so it needs to be changed anyway but maby GLib utf8 functions might be better? Yes, it supports UTF-8 and it also takes into account that some characters occupy two cells on the screen. Hmm. I don't think I have commit rights to mob branch? I'd rather you use git am -s on patches until I am trusted with commit rights. :) Mob is a branch where everyone can push, it's a special feature of repo.or.cz, see http://repo.or.cz/h/mob.html. I currently use mob branch for my work, I don't have an access to master branch. However I'll contact Mark (original author of cim5) to ask him for the access to master branch and I'll leave mob branch for you and other potential contributors. It'll be slightly better this way because there are people that from time to time try current devel version and they usually drop a note about found bugs in #centerim channel so you can get more feedback. So; here goes an Idea. Sorry it is quite looong, please skip if you are not interested. [snip] I'm giving it a try.. I know it is a big rework of the UI layer so I understand if you don't want it. But I see it as fun so I'll send patches later if you want and I can get it to work. :) Sounds great. You can commit your progress to mob branch. However I'll merge it to master branch after it's finished. I currently try to clean the code, round all corners and complete the program to the state where I can actually use it for real. So I don't want to have experimental code in my branch. Subject: [PATCH 06/13] Make header greay-ish Subject: [PATCH 07/13] Add HBox and make smaller changes. Subject: [PATCH 08/13] Remove space from indicator and add to generator Subject: [PATCH 09/13] Add Clock and make Header use HBox Subject: [PATCH 10/13] Add Seperator and use in HBox. Color Background. Subject: [PATCH 11/13] Update Header to fix layout and text. Subject: [PATCH 12/13] Only use background if requested. Subject: [PATCH 13/13] Remove ugly text I reviewed the new patches only quickly because as you mentioned above they need cleanup. Here are some notes anyway: * C++ comment style for single lines comments. * Methods should be const where possible (Label::Width() - const). * I think that HBox::MoveResize() should be virtual. * There is a CoreManager::TimeoutConnect() that wrapps g_timeout_add(). * Correct spelling is sepArator, not sepErator. ;) * Consider moving wbkgd() call to it's own method, not extending attron(). * Check purple_utf8_strftime() (util.h). -- Petr Pavlu -- ___ Centerim-devel mailing list Centerim-devel@centerim.org http://centerim.org/mailman/listinfo/centerim-devel http://www.centerim.org/
Re: [CenterIM-devel] CenterIM5 patches
Hello, nice to see patches for cim5. Here are some issues you should work on before pushing these patches to a mob branch. 0001-Add-LineStyle-without-borders.patch I wrote a similar patch a while ago but I abandoned it and instead I splitted Window class into two classes -- FreeWindow and Window, where Window derives from FreeWindow. The difference between them is that only Window contains a Panel that draws borders. The idea behind splitting the Window class was that border style settings will be configurable in the future (read from a config file), then a lack of split pane widgets and advanced widget autoresizing would cause that there needs to be extra if/else blocks in MoveResize() code in many places based on if a window currently has got a border or not. However I'm only about 60:40 inclined to the current solution so if you can come with good arguments for this patch I'll gladly change my opinion because this code is easier than having two classes. 0002-Add-signal-on-status-changes.patch I would rather see Header class connecting to libpurple account-status-changed signal so Header doesn't depend on Accounts. Using libpurple signals also provides a higher granularity in case you need it (grep purple_signal_register libpurple/account.c), maybe account-added and account-removed could be useful here. 0003-Make-Status-to-string-indicator-its-own-function.patch This function should be probably moved to something like src/Utils.cpp. 0004-Add-header-window-with-generic-information.patch * I think there is a typo in CenterIM::ScreenResized() where HeaderArea's height is `3'. * HeaderStatusItem struct declaration should be placed inside the class declaration in the header file. * SetColorScheme(panel) - SetColorScheme(header) ? * It's preferred (im cim5) to use C++ containers instead of GLib containers. * Protocol name cannot be used as a key in a `statuses' GList because cim5 is aiming to support more than one account per a protocol. * On-screen text width shouldn't be calculated using strlen() call, there is a ::width() function for it. (Yes, I know the name of this function is a bit vague. It's on my todo list to rename it to something that doesn't collide with Widget's `width' var so using :: isn't needed.) * I think there are some unnecessary includes in Header.h that could be removed. * There is no need to use extra Container because the Window is already a Container. 0005-Add-Swedish-Language.patch Looks ok, I can see Swedish translation after setting correct locales. Go ahead and commit this change to the mob branch. -- Petr Pavlu -- ___ Centerim-devel mailing list Centerim-devel@centerim.org http://centerim.org/mailman/listinfo/centerim-devel http://www.centerim.org/
