2010-05-07 04:47:10 -05:00
|
|
|
/*
|
|
|
|
* Copyright 2009-2010, Pier Luigi Fiorini. All rights reserved.
|
|
|
|
* Distributed under the terms of the MIT License.
|
|
|
|
*
|
|
|
|
* Authors:
|
|
|
|
* Pier Luigi Fiorini, pierluigi.fiorini@gmail.com
|
|
|
|
*/
|
|
|
|
|
Explicitly tie Conversations, Contacts, and Users to their ProtocolLoopers
Previously, all Conversations/Contacts/Users were stored in the Server,
each in their respective KeyMaps, identified solely by their
identifiers. This leads to the glaring problem of overlap― if the user
has multiple accounts, some users/rooms might be used or present in multiple
accounts at the same time.
Now, each accounts' Contacts, Conversations, and Users are stored in
its ProtocolLooper, making this overlap impossible. An oversight of only
allowing one user identifier to be stored (fMySelf) in Server was also fixed
this way.
This is the bulk of the work required for multi-account support― now,
the user can join the same XMPP room on two seperate accounts, and it
works perfectly.
2021-06-10 15:16:43 -05:00
|
|
|
#include "PreferencesWindow.h"
|
|
|
|
|
2010-05-07 04:47:10 -05:00
|
|
|
#include <Button.h>
|
2021-07-19 09:54:27 -05:00
|
|
|
#include <Catalog.h>
|
2010-05-07 04:47:10 -05:00
|
|
|
#include <ControlLook.h>
|
2010-10-24 01:27:09 -05:00
|
|
|
#include <LayoutBuilder.h>
|
2010-05-07 04:47:10 -05:00
|
|
|
#include <TabView.h>
|
|
|
|
|
|
|
|
#include "PreferencesAccounts.h"
|
2010-05-19 13:05:30 -05:00
|
|
|
#include "PreferencesBehavior.h"
|
2012-03-01 20:23:21 -06:00
|
|
|
#include "PreferencesChatWindow.h"
|
2012-03-08 16:55:13 -06:00
|
|
|
#include "PreferencesReplicant.h"
|
2010-05-07 04:47:10 -05:00
|
|
|
|
Explicitly tie Conversations, Contacts, and Users to their ProtocolLoopers
Previously, all Conversations/Contacts/Users were stored in the Server,
each in their respective KeyMaps, identified solely by their
identifiers. This leads to the glaring problem of overlap― if the user
has multiple accounts, some users/rooms might be used or present in multiple
accounts at the same time.
Now, each accounts' Contacts, Conversations, and Users are stored in
its ProtocolLooper, making this overlap impossible. An oversight of only
allowing one user identifier to be stored (fMySelf) in Server was also fixed
this way.
This is the bulk of the work required for multi-account support― now,
the user can join the same XMPP room on two seperate accounts, and it
works perfectly.
2021-06-10 15:16:43 -05:00
|
|
|
|
2021-07-19 09:54:27 -05:00
|
|
|
#undef B_TRANSLATION_CONTEXT
|
|
|
|
#define B_TRANSLATION_CONTEXT "PreferencesWindow"
|
|
|
|
|
|
|
|
|
2010-05-09 01:27:48 -05:00
|
|
|
const uint32 kApply = 'SAVE';
|
2010-05-07 04:47:10 -05:00
|
|
|
|
|
|
|
|
Explicitly tie Conversations, Contacts, and Users to their ProtocolLoopers
Previously, all Conversations/Contacts/Users were stored in the Server,
each in their respective KeyMaps, identified solely by their
identifiers. This leads to the glaring problem of overlap― if the user
has multiple accounts, some users/rooms might be used or present in multiple
accounts at the same time.
Now, each accounts' Contacts, Conversations, and Users are stored in
its ProtocolLooper, making this overlap impossible. An oversight of only
allowing one user identifier to be stored (fMySelf) in Server was also fixed
this way.
This is the bulk of the work required for multi-account support― now,
the user can join the same XMPP room on two seperate accounts, and it
works perfectly.
2021-06-10 15:16:43 -05:00
|
|
|
PreferencesWindow::PreferencesWindow()
|
2021-07-19 09:54:27 -05:00
|
|
|
: BWindow(BRect(0, 0, 500, 615), B_TRANSLATE("Preferences"),
|
2021-07-24 13:25:44 -05:00
|
|
|
B_TITLED_WINDOW, B_AUTO_UPDATE_SIZE_LIMITS | B_NOT_RESIZABLE
|
|
|
|
| B_NOT_ZOOMABLE | B_CLOSE_ON_ESCAPE)
|
2010-05-07 04:47:10 -05:00
|
|
|
{
|
|
|
|
BTabView* tabView = new BTabView("tabView", B_WIDTH_AS_USUAL);
|
|
|
|
tabView->AddTab(new PreferencesAccounts());
|
2010-05-19 13:05:30 -05:00
|
|
|
tabView->AddTab(new PreferencesBehavior());
|
2012-03-01 20:23:21 -06:00
|
|
|
tabView->AddTab(new PreferencesChatWindow());
|
2012-03-08 16:55:13 -06:00
|
|
|
tabView->AddTab(new PreferencesReplicant());
|
2010-05-07 04:47:10 -05:00
|
|
|
|
2021-07-24 13:25:44 -05:00
|
|
|
// Tab resizing here is a bit wonky. We want each tab to be visible,
|
|
|
|
// but we don't want the tab-view to be too wide…
|
|
|
|
float charCount = 0;
|
|
|
|
for (int i = 0; i < tabView->CountTabs(); i++)
|
|
|
|
charCount += strlen(tabView->TabAt(i)->Label());
|
|
|
|
|
|
|
|
// These values account for the decreasing amount of padding within tabs,
|
|
|
|
// Ignucius forgive me.
|
|
|
|
float textWidth = be_plain_font->Size();
|
|
|
|
switch ((int)textWidth) {
|
|
|
|
case 8: case 9: charCount += 14; break;
|
|
|
|
case 10: case 11: charCount += 5; break;
|
|
|
|
case 12: break;
|
|
|
|
case 13: case 14: case 15:
|
|
|
|
charCount -= 4; break;
|
|
|
|
default: charCount -= 10;
|
|
|
|
}
|
|
|
|
tabView->SetExplicitMinSize(BSize(charCount * textWidth, B_SIZE_UNSET));
|
|
|
|
|
2021-07-19 09:54:27 -05:00
|
|
|
BButton* ok = new BButton(B_TRANSLATE("OK"), new BMessage(kApply));
|
2010-05-07 04:47:10 -05:00
|
|
|
|
2010-10-24 01:27:09 -05:00
|
|
|
BLayoutBuilder::Group<>(this, B_VERTICAL)
|
2010-05-07 04:47:10 -05:00
|
|
|
.Add(tabView)
|
|
|
|
.AddGroup(B_HORIZONTAL)
|
2021-07-24 13:25:44 -05:00
|
|
|
.SetInsets(0, 0, B_USE_HALF_ITEM_SPACING, B_USE_HALF_ITEM_SPACING)
|
2010-05-07 04:47:10 -05:00
|
|
|
.AddGlue()
|
|
|
|
.Add(ok)
|
2021-07-24 13:25:44 -05:00
|
|
|
.End()
|
|
|
|
.End();
|
2010-05-07 04:47:10 -05:00
|
|
|
|
|
|
|
CenterOnScreen();
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
void
|
Explicitly tie Conversations, Contacts, and Users to their ProtocolLoopers
Previously, all Conversations/Contacts/Users were stored in the Server,
each in their respective KeyMaps, identified solely by their
identifiers. This leads to the glaring problem of overlap― if the user
has multiple accounts, some users/rooms might be used or present in multiple
accounts at the same time.
Now, each accounts' Contacts, Conversations, and Users are stored in
its ProtocolLooper, making this overlap impossible. An oversight of only
allowing one user identifier to be stored (fMySelf) in Server was also fixed
this way.
This is the bulk of the work required for multi-account support― now,
the user can join the same XMPP room on two seperate accounts, and it
works perfectly.
2021-06-10 15:16:43 -05:00
|
|
|
PreferencesWindow::MessageReceived(BMessage* msg)
|
2010-05-07 04:47:10 -05:00
|
|
|
{
|
|
|
|
switch (msg->what) {
|
2010-05-09 01:27:48 -05:00
|
|
|
case kApply:
|
2010-05-07 04:47:10 -05:00
|
|
|
Close();
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
BWindow::MessageReceived(msg);
|
|
|
|
}
|
|
|
|
}
|
2021-05-30 22:04:45 -05:00
|
|
|
|
|
|
|
|