Re: [Telepathy] GSoC idea: Gnome Games + Telepathy Tube
Le Fri, 20 Mar 2009 11:44:49 +0800, Zhang Sen zh.je...@gmail.com a écrit : Thanks to all, for the great hints you gave :) On Thu, 2009-03-19 at 17:31 +0100, Thomas H.P. Andersen wrote: Sudoku should be fairly easy to do I think since transformations (filling in/removing a number) does not depend on the previous state of the board. Lag and locking should not be big problems in sudoku. Yes, that makes it easier. But the undo/redo feature needs some thinking. Roughly we can make undo/redo only works locally, no matter collaborative mode or competitive (also single-player mode). Abicollab has some explanations how they do undo in collaborative editing: http://www.abisource.com/wiki/AbiCollab#Problems_with_undo It would be nice if you can undo your local moves when you are in a different, not related area of the maze. The problem is, do we want a maze to be solvable using the undo feature when you would be stuck if the undo feature was not there? Features I would like to see: - Ultra simple start. Just drag 'n drop a friend from IM app, or fetch a list of online IM friends to show inside the game. Easy set up of a game on LAN would be really nice too. The drag 'n drop is cool! Let me first find out how the general drag/drop works :) For LAN games: two connection managers provide tubes; gabble handles jabber case and salut handles link-local. So just like what empathy does, the contact list can be of two parts, one for jabber(maybe also msn in the future?) and one for 'People Nearby', people can choose respectively. When dragging and dropping, we can also know if the contact is from gabble or salut. This should be quite transparent and there shouldn't be much code dedicated to deal with the different CMs. There should be no code at all dedicated to deal with the different CMs. The Sudoku application do not need to know if the contact's protocol is jabber or link-local. - Game modes (collaborative / competitive) Good idea, but how should the competitive mode be like? We can let a player win if (s)he fills more (different weight with each filed). However, even in collaborative mode, we can also record who fills more and give a grade finally. What happens if a box is pushed in 2 different directions by the 2 players at the same time? Like this: @$ @ @ is a player, $ is a box. A player pushes the box to the right, the second player pushes it to the top. I guess you can decide that the initiator of the game can accept or deny a move. Would the second player's UI update the view only if the move is accepted by the initiator? In this case, the latency will make the game less usable... Or each player update his view immediately, but in case of conflict, it needs to be resolved. [...] Cheers, Alban ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] swapping return/ctrl-return keybindings
On Thu, 19 Mar 2009 21:53:02 +, Brian J. Murrell wrote:
I think I'm close. Here's the patch.
On reflection, never mind.
I don't think empathy is ready enough for me to switch to using it from
pidgin. Don't get me wrong. I really, really like the idea of being
able to use a single client (i.e. empathy) for all of my messaging (both
IM and IRC) and voice (i.e. to my PBX) needs, but on further examination
of the features I use in pidgin I don't think empathy is quite up to
replacing it for me, yet.
I will check back in a few months and hopefully some progress towards the
features I need/use will be {more complete,started,done}.
Cheers, and keep up the great work!
b.
___
telepathy mailing list
telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] GSoC idea: Gnome Games + Telepathy Tube
Le jeudi 19 mars 2009 à 17:31 +0100, Thomas H.P. Andersen a écrit : From my point of view (gnome-games) this would rock. We already know Zhang from earlier sudoku patches and it has always been good work. Sudoku should be fairly easy to do I think since transformations (filling in/removing a number) does not depend on the previous state of the board. Lag and locking should not be big problems in sudoku. Features I would like to see: - Ultra simple start. Just drag 'n drop a friend from IM app, or fetch a list of online IM friends to show inside the game. Easy set up of a game on LAN would be really nice too. - Game modes (collaborative / competitive) - Awareness UI. In collaborative mode it would be nice to have a shadow of the other players focus to avoid both players working in the same area. - Scoring: How would one win in competitive mode? Sudoku can already find a difficulty rating for each field depending on how obvious it is. Some sort of penalty for guessing wrong too? - Versioning. How to implement this to best prevent that future versions become incompatible. All of this sounds great ideas! I'm sure we could have a rocking Sudoku multiplayer experience. :) I think that doing multiplay in sudoku is both very innovative and fun. However most of the games are in C and I would have liked a general solution that could be used in all the games. Perhaps you can even manage both? :) I totally agree that we should have a general solution but think we should focus this SOC on one application. I prefer to have one game properly using tubes and nicely polished than half baked pieces of network code in each game. Lot of soc ends up with not-merge-ready quality code and are finally never integrated which is a bit of a shame. Maybe we should see the Sudoku game as a first attempt of tube integration into gnome-games and from this experience design a more general solution later? G. ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] GSoC idea: Gnome Games + Telepathy Tube
On Fri, Mar 20, 2009 at 04:44, Zhang Sen zh.je...@gmail.com wrote: Thanks to all, for the great hints you gave :) On Thu, 2009-03-19 at 17:31 +0100, Thomas H.P. Andersen wrote: Sudoku should be fairly easy to do I think since transformations (filling in/removing a number) does not depend on the previous state of the board. Lag and locking should not be big problems in sudoku. Yes, that makes it easier. But the undo/redo feature needs some thinking. Roughly we can make undo/redo only works locally, no matter collaborative mode or competitive (also single-player mode). Oh yes. The joy of undo in collaborative applications :) I have a few papers about that laying around if you need more material about that. Features I would like to see: - Ultra simple start. Just drag 'n drop a friend from IM app, or fetch a list of online IM friends to show inside the game. Easy set up of a game on LAN would be really nice too. The drag 'n drop is cool! Let me first find out how the general drag/drop works :) For LAN games: two connection managers provide tubes; gabble handles jabber case and salut handles link-local. So just like what empathy does, the contact list can be of two parts, one for jabber(maybe also msn in the future?) and one for 'People Nearby', people can choose respectively. When dragging and dropping, we can also know if the contact is from gabble or salut. This should be quite transparent and there shouldn't be much code dedicated to deal with the different CMs. - Game modes (collaborative / competitive) Good idea, but how should the competitive mode be like? We can let a player win if (s)he fills more (different weight with each filed). However, even in collaborative mode, we can also record who fills more and give a grade finally. Adam's idea is that players still have different puzzles but compete for speed (telepathy is only there to display the other's game), right? This also works, and we can develop an algorithm to calculate grades based on time and difficulty. This mode of competition is common with tetris games but I think it's less fun for sudoku, which lacks action and fancy stuff. E.g. people generally don't like to watch a guy playing sudoku. Maybe the players can play the same sudoku but only see that the other player has filled in something but not what number.This way you can still get stressed as your opponent gets ahead but not just copy his results. So what about we have just one mode: people complete (or collaborate) to finish the puzzle and in the end, players' credit/contribution is displayed? Sure. We can move on to more game types later if needed. - Awareness UI. In collaborative mode it would be nice to have a shadow of the other players focus to avoid both players working in the same area. Cool, I would include this. - Scoring: How would one win in competitive mode? Sudoku can already find a difficulty rating for each field depending on how obvious it is. Some sort of penalty for guessing wrong too? Sure this difficulty rating can be used, good idea! The rating system can be that, all changes to a filed are considered and become part of final score. A filed has 3 state: None, Right, Wrong. So we can add award and penalty to every state change. I need further thinking into this, because there are issues of network delay, judging which filling is the final one. - Versioning. How to implement this to best prevent that future versions become incompatible. Do you mean a newer sudoku tries to connect to one of older version? We can check version or check tube capacity if tubes are to be made optional. Yes. Basically making sure we announce the version we are running. Also trying to make the protocol general rather than specific for the implementation. This is all pretty vague but it is good to keep in mind that future versions may want to do things differently internally. I think that doing multiplay in sudoku is both very innovative and fun. However most of the games are in C and I would have liked a general solution that could be used in all the games. Perhaps you can even manage both? :) Yes a general solution would be great, I will surely stick with gnome and gnome-games in the future, but I don't know if I can finish both tasks within a summer ;) I think we can implement an interface similar to GGZ's, so existing network games won't need big change and others can be changed in the same manner. Cheers, Zhang ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] GSoC idea: Gnome Games + Telepathy Tube
Hi! On Fri, 2009-03-20 at 08:06 +, Alban Crequy wrote: Abicollab has some explanations how they do undo in collaborative editing: http://www.abisource.com/wiki/AbiCollab#Problems_with_undo It would be nice if you can undo your local moves when you are in a different, not related area of the maze. The problem is, do we want a maze to be solvable using the undo feature when you would be stuck if the undo feature was not there? Yeah, you took sudoku for sokoban :) Sudoku will be easier than sokoban, but sure, network lag and conflict must be considered. Thanks for the great page from AbiCollab. I will think about the problems and come again with what I may get. There should be no code at all dedicated to deal with the different CMs. The Sudoku application do not need to know if the contact's protocol is jabber or link-local. That will be even better. ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Just what is stream directionality?
On Fri, 13 Mar 2009 at 17:51:54 +, Simon McVittie wrote: In the process, I've run into a problem with stream directionality: we don't always know the direction of streams! When StreamAdded is emitted, it doesn't tell the client about the stream direction (although when RequestStreams returns, it does). Stream state (Disconnected, Connecting, Connected) has the same problem, but I propose to solve this by mandating that newly added streams are always in the Disconnected state, and that the connection manager MAY immediately emit StreamStateChanged to set the real state (if different). How Gabble implements it Streams created by the remote contact are created with a direction set by the Jingle content, except that if they asked for us to send, we transform that into Pending_Local_Send so the user can approve it. This basically means that in most cases, remotely-created streams are (Receive, Pending_Local_Send)... Streams created by us are set to Bidirectional immediately; the remote contact might refuse this by changing the direction at their end. ... and locally-created streams are Bidirectional. How telepathy-sofiasip implements it Streams created by the remote contact are receiving and pending local send, which seems right. Consistent with telepathy-gabble. Streams created by the local contact are receiving and pending remote send, which seems to me to be clearly wrong. Surely they should be sending and pending remote send? Not so consistent... What StreamAdded should imply = Possible solutions seem to be: * Arbitrarily pick one of the possible directions (which one?) and declare it to be the default. In all other cases, emit StreamDirectionChanged immediately after StreamAdded. * Require clients to call ListStreams after every StreamAdded to find out what's *really* going on. To keep things simple for clients, I'm inclined to declare that from now on, CMs MUST emit StreamDirectionChanged at least once per StreamAdded, to fill in the missing information. Perhaps a better ordering would be to emit SDC *before* the corresponding SA, to signal you are about to receive StreamAdded for the stream whose ID is 42: when you do, its direction will be...; this means that when dealing with 0.17.22-compliant connection managers, there will not be a limbo period in which we can only guess the direction. Which direction to assume when dealing with pre-0.17.22 CMs is an open question. Having incoming (remotely created) streams send media immediately would be a privacy violation, but having us expect to receive media immediately is fine. I'm inclined to say that when dealing with pre-0.17.22 CMs, the client SHOULD assume that the stream is Receive and Pending_Local_Send; if the client is the one that created the stream, then it will learn the real directionality soon (from the return of RequestStreams). Simon ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] GSoC idea: Gnome Games + Telepathy Tube
On Thu, Mar 19, 2009 at 11:44 PM, Zhang Sen zh.je...@gmail.com wrote: Adam's idea is that players still have different puzzles but compete for speed (telepathy is only there to display the other's game), right? This also works, and we can develop an algorithm to calculate grades based on time and difficulty. This mode of competition is common with tetris games but I think it's less fun for sudoku, which lacks action and fancy stuff. E.g. people generally don't like to watch a guy playing sudoku. I meant that they'd be competing to solve the same puzzle. It wouldn't be too hard to send an array representing an initial board to the other player. The progress of the other player would then be shown in shadow on the same board or on another without revealing the filled in numbers of either. Cheers, Adam ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] swapping return/ctrl-return keybindings
On Fri, 2009-03-20 at 16:29 +0100, Olivier Le Thanh Duong wrote: Hey, Hi. I'm no gtk or empathy expert but I think this error is caused by the fact that input_text_view is a stock TextView and thus don't have the 'message_send' signal and gtk_binding_entry_add_signal doesn't create a signal. Yes. Looking at pidgin's IMHtml widget I think you are right. What you should do is create this signal in EmpathyChat and connect chat_input_text_view_send to it (or a callback which call this function). And then ask your binding to fire up this signal You sound like you could be correct. I am certainly not in a position to tell you you are wrong, but neither do I know enough about gtk programming to carry out your idea. :-( It's moot anyway, given that I cannot realistically start using empathy yet as it doesn't have enough features for me to replace pidgin with it. :-( b. signature.asc Description: This is a digitally signed message part ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] fd.o#20772: Just what is stream directionality?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 20 Mar 2009 at 14:06:11 +, Simon McVittie wrote: To keep things simple for clients, I'm inclined to declare that from now on, CMs MUST emit StreamDirectionChanged at least once per StreamAdded, to fill in the missing information. Perhaps a better ordering would be to emit SDC *before* the corresponding SA, to signal you are about to receive StreamAdded for the stream whose ID is 42: when you do, its direction will be...; this means that when dealing with 0.17.22-compliant connection managers, there will not be a limbo period in which we can only guess the direction. Which direction to assume when dealing with pre-0.17.22 CMs is an open question. Having incoming (remotely created) streams send media immediately would be a privacy violation, but having us expect to receive media immediately is fine. I'm inclined to say that when dealing with pre-0.17.22 CMs, the client SHOULD assume that the stream is Receive and Pending_Local_Send; if the client is the one that created the stream, then it will learn the real directionality soon (from the return of RequestStreams). I've proposed some spec wording in the StreamAdded, StreamDirectionChanged and StreamRemoved documentation: http://git.collabora.co.uk/?p=user/smcv/telepathy-spec-smcv.git;a=shortlog;h=refs/heads/streaming-errata http://people.freedesktop.org/~smcv/telepathy-spec-streaming_errata/spec.html#org.freedesktop.Telepathy.Channel.Type.StreamedMedia For further discussion, see: http://bugs.freedesktop.org/show_bug.cgi?id=20772 Regards, Simon -BEGIN PGP SIGNATURE- iD8DBQFJw9jLWSc8zVUw7HYRAjO7AJ99N9fdPns1dLQoZMYXCnB2wuuBGACg6PmS U68+CuhUSnTGkvqPDjcQC8I= =AqDL -END PGP SIGNATURE- ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
[Telepathy] [Bug 14606] After a channel is closed, you can't tell who was in it (the missed call from, er, someone? bug)
http://bugs.freedesktop.org/show_bug.cgi?id=14606 --- Comment #4 from Simon McVittie simon.mcvit...@collabora.co.uk 2009-03-20 11:06:57 PST --- Do we consider Requests to have solved this bug? Should we close it? Answers on a postcard... -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
[Telepathy] [Bug 17840] Move NAT traversal types to a better API and add STUN/TURN
http://bugs.freedesktop.org/show_bug.cgi?id=17840 Simon McVittie simon.mcvit...@collabora.co.uk changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE --- Comment #2 from Simon McVittie simon.mcvit...@collabora.co.uk 2009-03-20 11:09:30 PST --- This bug and Bug #19958 are basically the same, and #19958 has more discussion, so it wins. Marking this one as a duplicate. *** This bug has been marked as a duplicate of bug 19958 *** -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
[Telepathy] [Bug 19958] nat-traversal should be a property of stream, not channel
http://bugs.freedesktop.org/show_bug.cgi?id=19958 Simon McVittie simon.mcvit...@collabora.co.uk changed: What|Removed |Added CC||simon.mcvit...@collabora.co. ||uk --- Comment #4 from Simon McVittie simon.mcvit...@collabora.co.uk 2009-03-20 11:09:30 PST --- *** Bug 17840 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
[Telepathy] [Bug 17246] Add ability to request Media channels with initial streams
http://bugs.freedesktop.org/show_bug.cgi?id=17246 --- Comment #3 from Simon McVittie simon.mcvit...@collabora.co.uk 2009-03-20 11:12:18 PST --- Review comments from the draft have been addressed in: http://git.collabora.co.uk/?p=user/smcv/telepathy-spec-smcv.git;a=shortlog;h=refs/heads/streamedmedia An implementation is still needed. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
[Telepathy] [Bug 16707] Support for encryption
http://bugs.freedesktop.org/show_bug.cgi?id=16707 Mikhail Zabaluev mikhail.zabal...@nokia.com changed: What|Removed |Added Severity|normal |enhancement -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] swapping return/ctrl-return keybindings
On Fri, Mar 20, 2009 at 12:25:23PM +, Brian J. Murrell wrote: On Fri, 20 Mar 2009 11:01:44 +, Sjoerd Simons wrote: It would be very helpful for us if you could file wishlist bugs against Empathy with the features you're still missing and especially why you're missing them. Yeah I can do that. My experience has been that generally wishlists from users get ignored and FOSS developers develop the features they want (i.e. they scratch their own itch -- which is what I was trying to so my self in this thread, but I don't have enough familiarity with GTK for this particular problem -- or the time to develop enough familiarity), which is most certainly fair enough. It's their time after-all. But since you invited me to, I will. Does empathy just use bugzilla for wishlist items? Bugzilla is used for all issue including wishlist items. It can take a while before we have a good look at them (depending on how urgent we think they are and how much time we can spent on it), but if they are not in bugzilla we'll certainly forget, so it's worth a try :) Sjoerd -- Sometimes even to live is an act of courage. -- Seneca ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
[Telepathy] tq-qt4 refcount proposal
Hi all,
I would like to make a proposal for tp-qt4 refcounted classes.
1 - Rationale:
Many objects (read all high-level DBus interfaces classes AccoutManager,
Account, Channel, Connection, ...) in tp-qt4 are reference counted.
The pattern used is that classes inherit QSharedData and are used
together with QExplicitlySharedDataPointer, that takes care of managing
the reference count.
When the reference count hits 0, the object is deleted.
When instantiating new classes that inherits QSharedData without using
QExplicitlySharedDataPointer the reference count is 0, this is referred
to as the floating state.
This may lead to memory leaks, caused by objects in the floating state
that never get deleted.
2 - Proposal for avoiding objects in floating state as hard as possible:
New objects should be put into a QExplicitlySharedDataPointer as soon as
possible after creation to avoid possibly leaking an object while it’s
in a floating state.
To achieve this we could make the objects constructor protected* and
have public create function that returns a QExplicitlySharedDataPointer.
Why not make the constructor private?
We need to support subclasses, and so we need the constructors to be at
least protected.
2.1 - Problems:
2.1.1 - Circular dependency:
In the ideal world we should use QExplicitlySharedDataPointerObject in
the library, even for objects that needs to know about each other, for
example StreamedMediaChannel that caches the MediaStreams and
MediaStreams that have a pointer to the StreamedMediaChannel. We should
be careful with this, as we hit circular dependency, which can lead to
even more memory leaks when the objects refcount never hits 0.
This can be handled in different ways, and should be done case by case.
Bellow there is a code snippet to illustrate how to manage this on
StreamedMediaChannel/MediaStream case:
class MediaStream : public QSharedData, ... {
public:
MediaStream(const QExplicitlySharedDataPointerStreamedMediaChannel
channel, ...)
: QSharedData(),
mChannel(channel) // channel-ref++
{ }
...
QExplicitlySharedDataPointerStreamedMediaChannel channel() const {
return mChannel; }
...
private:
...
QExplicitlySharedDataPointerStreamedMediaChannel mChannel;
};
class StreamedMediaChannel : public QSharedData, ... {
public:
static QExplicitlySharedDataPointerStreamedMediaChannel create(...) {
... }
...
QListQExplicitlySharedDataPointerStreamedMediaChannel streams()
const { return mStreams; }
...
protected:
StreamedMediaChannel(...); // StreamedMediaChannel should allow inheritance
...
private Q_SLOTS:
void onInvalidated(...) // closed
{
foreach (stream, streams) {
// if nothing else is holding the stream, the stream will be deleted
stream.reset();
}
// no stream is referencing the channel anymore, when the library user
forget about the channel,
// it will be deleted.
}
void onStreamRemoved(...)
{
...
// if nothing else is holding the stream, the stream will be deleted
stream.reset();
...
}
private:
...
QListQExplicitlySharedDataPointerMediaStream mStreams;
};
2.1.2 - Custom classes:
All custom classes should follow this guideline, making the constructor
protected and having a create method, to avoid objects in floating
state, as explained above.
2.1.3 - QObject parent relationship:
All refcounted objects should not have a parent QObject, as when the
QObject gets deleted the children objects are deleted as well.
3 - Naming:
As you can see typing QExplicitlySharedDataPointer all over the place is
not something really nice, and we may want to move to another class
later, a lightweight version or something else, so the ideal is to have
our own class that for now inherits QExplicitlySharedDataPointer, and if
we want to change it later we just change this class.
Note that typedef is not an option here, as you can't typedef template
(just template specializations) and can't forward declare typedef, which
we would need.
So I propose to have a template class SharedPtr that inherits
QExplicitlySharedDataPointer, and a class named SharedData that is a
typedef for QSharedData (in case we want to change to use another class
in the future, we don't need to change all classes). We may want to make
SharedData call deleteLater on ref==0 instead of delete for example.
So the usage would be:
public Account : SharedData
{
public:
...
static SharedPtrAccount create();
...
};
I wrote a experimental branch to ilustrate what it's explained above
http://git.collabora.co.uk/?p=user/andrunko/telepathy-qt4.git;a=shortlog;h=refs/heads/shared
Opinions, suggestions?
BR
Andrunko
P.s.: Some ideas are based on http://webkit.org/coding/RefPtr.html, as
suggested by Kenneth Rohde Christiansen.
___
telepathy mailing list
telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] tq-qt4 refcount proposal
On Friday 20 March 2009 15:50:23 Andre Moreira Magalhaes wrote:
3 - Naming:
As you can see typing QExplicitlySharedDataPointer all over the place is
not something really nice, and we may want to move to another class
later, a lightweight version or something else, so the ideal is to have
our own class that for now inherits QExplicitlySharedDataPointer, and if
we want to change it later we just change this class.
Note that typedef is not an option here, as you can't typedef template
(just template specializations) and can't forward declare typedef, which
we would need.
So I propose to have a template class SharedPtr that inherits
QExplicitlySharedDataPointer, and a class named SharedData that is a
typedef for QSharedData (in case we want to change to use another class
in the future, we don't need to change all classes). We may want to make
SharedData call deleteLater on ref==0 instead of delete for example.
Having a class that inherits QExplicitlySharedDataPointer doesn't really
future proof you, since any replacement must implement the exact same api. I
suppose if you privately inherit you could maybe get away with it, might be a
good idea to get rid of detach() anyways.
So the usage would be:
public Account : SharedData
{
public:
...
static SharedPtrAccount create();
...
};
Regardless I think even if you have a SharedPtr, you should typedef
SharedPtrAccount into AccountPtr because its annoying to use templates in
the code all the time. :)
I wrote a experimental branch to ilustrate what it's explained above
http://git.collabora.co.uk/?p=user/andrunko/telepathy-qt4.git;a=shortlog;h=
refs/heads/shared
Opinions, suggestions?
Well you know I think its a good idea. :)
Ian
signature.asc
Description: This is a digitally signed message part.
___
telepathy mailing list
telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy
