#pokersource@irc.freenode.net IRC Log for
Monday 11 January 2010

Back to #pokersource@irc.freenode.net Log Calendar

Back to to Sunday 10 January 2010


Poker Free Software http://pokersource.info/ with IRC archives http://pokersource.info/irc/pokersource@irc.freenode.net/"

01:13:00 saqimtiaz quit IRC ("Leaving.").
01:33:32 Lyolik joined #pokersource.
01:34:38 Lyolik: Hello
01:36:41 osivinyuk joined #pokersource.
02:04:56 osivinyuk quit IRC ().
03:27:29 bkuhn quit IRC ("Sleeping.").
04:07:21 Lyolik quit IRC (niven.freenode.net irc.freenode.net).
04:07:21 dachary quit IRC (niven.freenode.net irc.freenode.net).
04:07:22 Sp4rKy quit IRC (niven.freenode.net irc.freenode.net).
04:07:22 thy1 quit IRC (niven.freenode.net irc.freenode.net).
04:07:22 julez quit IRC (niven.freenode.net irc.freenode.net).
04:07:22 Nurbs quit IRC (niven.freenode.net irc.freenode.net).
04:07:22 thy quit IRC (niven.freenode.net irc.freenode.net).
04:07:22 H|- quit IRC (niven.freenode.net irc.freenode.net).
04:07:22 MotherOfCOBOL quit IRC (niven.freenode.net irc.freenode.net).
04:07:22 bleader quit IRC (niven.freenode.net irc.freenode.net).
04:07:22 tarbo2_ quit IRC (niven.freenode.net irc.freenode.net).
04:07:22 brian__ quit IRC (niven.freenode.net irc.freenode.net).
04:07:51 Lyolik joined #pokersource.
04:08:43 dachary joined #pokersource.
04:08:43 thy joined #pokersource.
04:08:43 MotherOfCOBOL joined #pokersource.
04:08:43 Nurbs joined #pokersource.
04:08:43 tarbo2_ joined #pokersource.
04:08:43 H|- joined #pokersource.
04:08:43 bleader joined #pokersource.
04:08:43 brian__ joined #pokersource.
04:08:43 thy1 joined #pokersource.
04:08:43 julez joined #pokersource.
04:08:43 Sp4rKy joined #pokersource.
06:28:57 saqimtiaz joined #pokersource.
08:21:01 mongolito404 joined #pokersource.
08:28:09 mongolito404: Hoi
08:30:13 dachary quit IRC (Read error: 113 (No route to host)).
09:03:28 guyvdb quit IRC ("Leaving.").
09:16:22 dachary joined #pokersource.
09:28:09 emilie joined #pokersource.
09:29:41 proppy joined #pokersource.
09:31:13 dachary: good morning
09:31:20 Sp4rKy: ouaouh
09:31:25 dachary: :-D
09:31:27 Sp4rKy: exactly 9.30
09:31:42 Sp4rKy: mhh, you were waiting since 14 min :)
09:31:57 dachary: ahahah
09:32:06 Sp4rKy: :}
09:32:06 dachary: proppy: are you ready to discuss ?
09:32:07 mongolito404: :D
09:32:30 proppy: dachary: sure
09:33:18 dachary: do you have any question regarding today's integration work ?
09:33:29 proppy: dachary: no
09:33:57 dachary: let's figure out how to skin jpoker then ;-)
09:34:09 dachary: proppy: do you have a suggestion ?
09:34:54 proppy: dachary: we should use css as much as possible, add missing class when there are needed, and evaluate the result with skin/*.html
09:35:18 dachary: the first skin we will get has only image changes
09:35:38 dachary: the question would be (simple skin) where do we put files for this skin and how does it fit with drupal
09:35:59 dachary: mongolito404: probably have suggestions
09:36:08 proppy: dachary: jpoker skin only include image from planc/css/images for now
09:36:10 dachary: jpoker currently lives in the module directory
09:36:24 proppy: dachary: no jpoker does not live the the module directory
09:36:28 proppy: dachary: it lives in planc
09:36:39 proppy: at least on drupal-kez :)
09:36:43 dachary: ah, right
09:37:06 proppy: I don't knwo in drupal-demo not drupal-404
09:37:11 proppy: s/not/nor
09:37:15 dachary: it's the same
09:37:20 dachary: so, at present it is completly unrelated to drupal theming
09:37:24 proppy: yes
09:37:28 mongolito404: So currently, there is no way fro Drupal to provide theme element to jpoker.
09:37:33 proppy: so it can't really include image from the theme
09:37:37 dachary: when the drupal theme changes, it does not change the poker theme
09:37:44 dachary: mongolito404: correct
09:37:45 proppy: like you suggest in http://drupal-dev.pokersource.info/trac/ticket/6
09:37:56 proppy: +'ed
09:38:41 mongolito404: Is there a way to provide external theme information to jpoker ?
09:38:45 proppy: mongolito404: dachary: this is a way for drupal to provide theme lement to jpoker
09:38:50 dachary: :-D
09:38:51 proppy: buy overriding css class
09:38:58 proppy: by
09:38:58 dachary: s/buy/by/
09:39:25 proppy: mongolito404: do you know if a window including an iframe
09:39:27 dachary looking into opensocial and CSS / theming
09:39:31 proppy: can override the css of the iframe ?
09:40:08 mongolito404: Images can be switched in CSS if all image elements are actually divs (or other block elements) wich image-background
09:40:30 dachary: http://code.google.com/p/opensocial-resources/issues/detail?id=286
09:40:35 mongolito404: The parent frame cannot override the iframe CSS unless in use JS to inject its CSS
09:41:18 bruno|taf joined #pokersource.
09:41:37 dachary: http://www.opensocial.org/Technical-Resources/opensocial-spec-v08/gadgets-reference08#gadgets.skins
09:41:46 dachary reading
09:41:49 guyvdb joined #pokersource.
09:43:06 dachary: the properties available are just ridiculous :-D
09:43:18 dachary: anchor_color/bg_color/bg_image/font_color
09:43:20 dachary: ahahah
09:43:45 proppy: so either we move jpoker to the os_poker directory, or we had a way for os_poker to inject css into jpoker iframe
09:44:44 proppy: originaly opensocial gadget allow the widget to lives on a different server than the container
09:45:03 proppy: is that something we should take into consideration ?
09:45:13 mongolito404: Can't the container pass some information to the gadget ?
09:45:49 proppy: mongolito404: there seems to be "no opensocial way" to do it
09:45:52 dachary: mongolito404: that's what gadgets.skins is about
09:45:55 dachary: but
09:46:04 proppy: mongolito404: but you can modify shindig_integrator so it includes a additional css
09:46:15 dachary: it gives specific colors instead of the path to a CSS file which is ridiculous
09:46:37 dachary: example : http://trac.hyves-api.nl/wiki/OpensocialSnippets#GadgetsSkin
09:46:39 proppy: mongolito404: I don't know if there is a way to include an additional css in the iframe declaration
09:47:35 mongolito404: dachary: The the std. skins object.
09:48:02 mongolito404: Maybe the container can pass some gadhet specific data
09:49:24 proppy: mongolito404: what about the style element of an iframe
09:49:41 proppy: could it be used to skin elements inside the iframe ?
09:50:01 dachary: mongolito404: it's easy to solve the problem in a specific way. And we will do that if we don't find a standard way to deal with skinning.
09:51:01 proppy: (09:44:23 AM) proppy: originaly opensocial gadget allow the widget to lives on a different server than the container
09:51:01 proppy: (09:44:42 AM) proppy: is that something we should take into consideration ?
09:51:02 proppy: dachary: ^
09:51:40 dachary: proppy: I don't understand the question
09:51:54 proppy: dachary: if drupal os_poker is running on www.domainA.com
09:51:59 dachary: rather my answer would be : yes, but I miss the point
09:52:10 proppy: opensocial is designed so it can include gadget from www.domainB.com
09:52:19 dachary: yes
09:52:25 proppy: so that something we want to keep ?
09:52:28 dachary: yes
09:52:31 mongolito404: In that case, we can't use JS to communicate between the gadget and the container (Drupal).
09:52:48 proppy: if we assume that both jpoker and os_poker are living on the same server, sharing skin is way more easy
09:52:52 dachary: we don't want to break the opensocial model unless we have a VERY good reason to
09:53:21 mongolito404: And it will breaks what we have done to communicate the gift events
09:53:58 dachary: proppy: I see what you mean now. The answer stands : the cost of breaking the opensocial model is high (and we did break it already in places, we don't want to add to this unless we're forced to).
09:54:27 mongolito404: Does the gadget know the base URL of the container ? If yes, os_poker can provide a known path for the CSS and the gadget can include it
09:54:30 dachary: mongolito404: yes
09:54:38 proppy: dachary: it is not about breaking the opensocial model, it is about taking advantage that currently the gadget and the container lives on the same server
09:54:57 proppy: and about not designing something that it is not used
09:55:38 dachary: which is an excuse to make something that won't survive the inclusion into another opensocial container (we have things that will require that kind of change already)
09:55:46 proppy: mongolito404: the gadget can get it using window.top.document location IIRC
09:55:58 dachary: proppy: if you take that route what's the point of using OpenSocial at all ?
09:56:21 proppy: dachary: it will survive the inclusion into another opensocial container, but it will always use the same skinning
09:56:35 mongolito404: proppy: Not if window.parent is not on the same domain then the iframe.
09:56:38 dachary: proppy: hum, good point
09:56:45 proppy: dachary: we can provide different gadget url, when we need different skin
09:57:04 proppy: mongolito404: the iframe can't include css from a foreign domain ?
09:57:17 dachary: proppy: I agree with you :-)
09:58:23 mongolito404: proppy: The iframe can include CSS from anywhere. But the url can be built in JS using information from the parent frame.
09:59:24 proppy: mongolito404: I don't know if/how the container url should be given to the gadget then
10:00:25 j1b joined #pokersource.
10:01:04 mongolito404: In the code that procude the the iframe URL for a gadget in ShindigIntegrator, gadget settings and user_preferences are passed in the iframe URL as up_$key
10:01:34 mongolito404: I guess this is a way to pass data from the container to the gadget
10:03:40 mongolito404: The $_SERVER['HTTP_HOST'] is also given in the iframe URL in the "parent"
10:04:44 mongolito404: We can pass a user preference which contains the URL of the theme CSS
10:06:34 mongolito404: Ok the URL of a JSON file containing theme information (URLs for CSS, URLs for images, color codes, etc)
10:08:19 mongolito404: s/Ok/Or
10:08:34 proppy: mongolito404: so you suggest that the gadget get the parameters from the iframe query string ?
10:09:08 proppy: or maybe there is a JS API for gadget settings or user_preferences
10:09:23 proppy: mongolito404: I think dachary agreed that (09:56:25 AM) proppy: dachary: we can provide different gadget url, when we need different skin
10:09:39 proppy: mongolito404: that would remove the need to pass any parameters to the gadget don't you think ?
10:09:48 proppy: if the gadget itself is specific
10:10:01 mongolito404: http://wiki.opensocial.org/index.php?title=Gadgets.Prefs_(v0.9)
10:10:37 proppy: mongolito404: for example if we only replace images, it allows not to right css at all
10:11:13 mongolito404: proppy: Different URL for the gadget using different themes is ok for me. But it means the theme data will no be provided by Drupal
10:11:39 proppy: yes, but that doesn't mean we won't be able to theme jpoker either
10:11:51 proppy: mongolito404: do you think that drupal and jpoker share some theme items ?
10:12:18 proppy: I think we identified at least one with http://drupal-dev.pokersource.info/trac/ticket/6
10:12:47 mongolito404: Yes and no. For themer it would be easier to work on a Drupal that also theme the jpoker that to have to work on two themes (one for each application)
10:12:50 proppy: (the default avatar image)
10:13:54 proppy: mongolito404: ah you mean you can't share images nor class between the two themes ?
10:15:00 proppy: mongolito404: in my view jpoker markup is so specific, that there is not so much to share, but I might be wrong
10:15:08 mongolito404: proppy: I don't see how using a different gadget URL for a theme could allow the gadget to get the URL of Drupal provided resources.
10:15:38 proppy: mongolito404: it will not use the URL of Drupal provided resources
10:15:49 proppy: it would mean that each gadget URL as its own ressources
10:16:06 mongolito404: So we will have a theme for jpoker that's separated from the Drupal theme.
10:16:12 proppy: mongolito404: yes
10:16:26 proppy: but we will still be able to have multiple jpoker skin
10:16:29 mongolito404: And themers will have to create both to have their jpoker looks like Drupal
10:16:33 proppy: by choosing the gadget we want to include
10:17:08 mongolito404: And if the jpoker and Drupal themes share the same name, Drupal can easily build the URL for the gedget with the right theme.
10:17:12 proppy: mongolito404: yes but as I argued (I might be wrong) I wonder what can be shared between the drupal theme and the jpoker theme anyway
10:17:32 mongolito404: proppy: We can share many things. Color, page background, etc.
10:18:03 mongolito404: Default avatars is one of trhe things that can be shared
10:18:09 proppy: mongolito404: you're right for page background that would means for example that you must update the image in two places
10:18:12 proppy: if you update it
10:18:43 mongolito404: There is alos the need to sync. the gift images
10:18:44 proppy: mongolito404: also you have to consider that making a new gadget is more easy for things like using the same theme
10:18:49 proppy: but just replacing image
10:19:00 proppy: mongolito404: do you agree ?
10:19:18 proppy: mongolito404: I think we way have an "in between" solution
10:19:27 proppy: i.e use specific gadget url for the base theme
10:19:58 proppy: and allow drupal to add css in the iframe to share css classes definition
10:20:03 proppy: mongolito404: what do you think ?
10:20:10 mongolito404: The user preferences may point to an URL containing a theme JSON. Like this {css: ['css url1', 'css url2"], images: {id1: 'img url1', id2: 'img url2', ...}
10:20:37 mongolito404: css are included by the gadget
10:20:37 proppy: mongolito404: why images is needed ?
10:20:54 proppy: the css can already defined #id .class image association
10:21:15 mongolito404: If you only use CSS, it means that all themable images has to be a block element with a background image
10:21:31 proppy: mongolito404: yes, if not it is a bug
10:21:35 proppy: mongolito404: but
10:21:37 mongolito404: You can swith the src of an img element in CSS
10:21:53 proppy: (can't) ?
10:22:09 proppy: But, it is also handy to be able to create a new theme, by writing no css
10:22:19 proppy: and only replacing images in css/images jpoker directory
10:22:36 proppy: so I think we should keep in mind that the main theme for jpoker and drupal are separated
10:22:40 mongolito404: If the theme provides a list of images indexed by id it means that a) the gadget can refer to this array when it needs an image b) The gadget can replace any existing IMG with a matching id or class name with the provided images.
10:22:53 proppy: but that there is a mecanism to share css between them
10:24:00 mongolito404: So for instance, if you have theme = {images: {'default_avatar' => '...'}}, the gadget knows it can use theme.images['default_avatar'] when it needs the URL of the default avaters. It can also do $('img.default_avatar').attr('src', theme.images['default_avatar']) to update existing images element
10:25:10 proppy: mongolito404: the only
10:25:24 proppy: mongolito404: for default_avatar a css class is used
10:25:33 proppy: IIRC
10:25:45 proppy: the img src is only used when using the actual avatar of the player
10:28:13 mongolito404: So we have two resources to be provided to theme jpoker: An additional CSS files and the url for the default avatars.
10:29:08 proppy: mongolito404: no I believe the url for the default avatar could be provided using css
10:29:12 mongolito404: ok
10:29:26 mongolito404: So we can have only a css url in the preference
10:29:39 proppy: yes
10:29:51 mongolito404: PoC then
10:29:56 proppy: PoC ?
10:30:06 mongolito404: Piece of Cake
10:30:28 proppy: do you agree that it will only be used for css classes that drupal needs to share with the jpoker gadget
10:30:39 proppy: and that most of the theming will occure in the gadget itself
10:30:42 proppy: ?
10:31:05 mongolito404: I can't. Because I don't know the (future) needs for jpoker theme
10:32:40 proppy: mongolito404: do you agree that if we define a new theme from an old one that is only replacing images
10:32:48 proppy: it is more easy to create a new gadget with all the image replaced
10:33:08 proppy: than to write css for each elements for which you wants to replace the image ?
10:35:03 mongolito404: Well I know CSS and HTML but not OpenSocial and the poker gadget. It'll be easier for me to override some images in a defined CSS than to change files I don't even know yet.
10:38:05 mongolito404: But you know jpoker more than me
10:38:24 mongolito404: And but approach have their pro and con.
10:38:35 mongolito404: And any solution is good
10:40:10 proppy: mongolito404: sure, from what dachary said we should still be able to define a new theme by just overriding images
10:40:32 proppy: I believe this is more easy to ask an artist to replace images in a path, than to ask him to write a css declaration for each one
10:41:16 proppy: mongolito404: but I agree with you, than we need to be able to share theme properties between drupal and jpoker
10:41:21 proppy: like default_avatar, background_color, font_color, size etc
10:41:49 proppy: mongolito404: so let's implement a parameter passed to the gadget to include a css
10:41:58 mongolito404: Ok
10:42:11 proppy: mongolito404: I've seen appParam in shindig_integrator.module
10:42:18 proppy: but I'm not sure how it guess defined
10:42:31 proppy: $_REQUEST['appParams']
10:42:32 mongolito404: So, in the gadget, something like http://pastebin.com/d7546b9f7
10:43:50 mongolito404: And in Drupal, we have to update the application_settings table for all user
10:44:07 proppy: ouch
10:44:25 proppy: mongolito404: I think there may be settings global to the application
10:44:34 mongolito404: Yes
10:44:41 proppy: drupal-kez:/usr/src/planc# echo 'describe applications' | mysql -u root drupal6 | more | grep settings
10:44:41 proppy: settings text YES NULL
10:45:07 mongolito404: But in Drupal, the theme is a user settings. If allowed, a user can use a different theme.
10:45:53 proppy: oh ok !
10:45:54 mongolito404: To be complete we need to set the theme in the (serialized) settings in the applications table
10:46:08 proppy: so I believe we should use userPrefs instead then
10:46:22 mongolito404: And for user using a different theme than the default one, we can override this setting in application_settings
10:47:18 proppy: mongolito404: or we could use app data
10:47:41 proppy: we are already using app data in jpoker opensocial integration
10:48:10 mongolito404: Which OS specs are we using 0.8, 0.9 or 1.0 ?
10:48:11 proppy: http://wiki.opensocial.org/index.php?title=UserPrefs_vs_AppData
10:48:15 proppy: 0.8
10:49:35 proppy: mongolito404: I don't know where drupal shindig_integrator set Prefs
10:49:42 proppy: but we already know where it set appdata
10:49:56 proppy: it is in application_settings table
10:49:57 proppy: drupal-kez:/usr/src# echo 'describe application_settings' | mysql -u root drupal6 | more
10:49:57 proppy: Field Type Null Key Default Extra
10:49:57 proppy: application_id int(10) unsigned NO PRI NULL
10:49:57 proppy: user_id int(10) unsigned NO PRI NULL
10:49:58 proppy: name varchar(128) NO PRI
10:49:58 proppy: value text NO NULL
10:50:33 proppy: mongolito404: so you could easily add a new appdata
10:50:36 proppy: called skin for example
10:50:37 proppy: with a css path
10:50:42 proppy: mongolito404: what do you think ?
10:51:50 mongolito404: If gadgets.Prefs are extracted from the "up_*" parameter in the iframe URL built by Shindig, then Prefs are set in both application (settings column) and application_settings.
10:52:05 mongolito404: The first provide global settings, the second user defined one.
10:52:26 saqimtiaz quit IRC ("Leaving.").
10:53:00 saqimtiaz joined #pokersource.
10:53:06 mongolito404: And "up" sounds like "User Preferences" to me
10:53:46 proppy: mongolito404: yes, but you don't have write access to these parameter do you ?
10:54:00 mongolito404: Yes I have
10:54:20 mongolito404: The table I'm speaking are in Drupal so Drupal can write to them
10:54:32 proppy: ah so it is not build from shindig, it is build for shindig
10:55:08 mongolito404: Yes, these are tables from Shindig-Integrator
10:55:28 proppy: mongolito404: but app data already uses application_settings
10:55:38 proppy: so I believe from shindig integrator these are the same
10:55:57 proppy: mongolito404: for example if you take look at shindig_integrator application_settings table
10:56:12 proppy: you will see money, and achievement in to
10:56:14 proppy: in it
10:56:25 proppy: so maybe we only needs to add a "skin" appdata
10:56:29 proppy: mongolito404: what do you think ?
10:56:48 mongolito404: Yes
10:58:06 proppy: I think the difference between prefs and appdata
10:58:07 mongolito404: But it shouldn't be a read/write value, only a read one
10:58:14 proppy: is that Prefs are available without doing any request
10:58:16 mongolito404: (from the geadget PoV)
10:58:23 mongolito404: Yes Prefs should be
10:58:27 proppy: mongolito404: so let's try prefs
10:58:41 mongolito404: According to my understanding of the gadget.Prefs
11:00:29 proppy: mongolito404: I will try to pass prefs in http://drupal-kez.pokersource.vm.gnt/planc/test-poker-opensocial.html
11:00:56 proppy: oups
11:01:05 proppy: http://drupal-kez.pokersource.info/planc/test-poker-opensocial.html :)
11:01:15 mongolito404: Lookig at what we have now, the AppData are passed through up in the iframe URL
11:01:42 mongolito404: money is in "up_money" in the URL
11:02:02 mongolito404: So I guess up_* are not in gadget.Prefs
11:02:02 proppy: yes $prefs .= '&up_' . urlencode($name) . '=' . urlencode($value);
11:02:29 proppy: we could try
11:03:53 proppy: mongolito404:
11:03:57 proppy: shindig do the following
11:03:57 proppy: gadgets.IfrGadget.prototype.getUserPrefsParams = function() {
11:03:58 proppy: var params = '';
11:03:58 proppy: if (this.getUserPrefs()) {
11:03:58 proppy: for(var name in this.getUserPrefs()) {
11:03:58 proppy: var value = this.getUserPref(name);
11:03:59 proppy: params += '&up_' + encodeURIComponent(name) + '=' +
11:04:01 proppy: encodeURIComponent(value);
11:04:03 proppy: }
11:04:05 proppy: }
11:04:07 proppy: return params;
11:04:09 proppy: }
11:04:11 proppy: on the gadget side
11:04:13 proppy: so it should work
11:04:35 mongolito404: ok
11:07:03 proppy: adding up_skin=from_drupal_skin.css in test-poker-opensocial.html iframe decl
11:07:13 proppy: and testing if I get the value in userPrefs
11:08:24 proppy: but shower break first :)
11:21:04 mongolito404: What should be the name of the pref ? skin, poker_skin, poker_external_skin ?
11:21:04 proppy: back
11:21:18 proppy: os_poker_skin ?
11:24:27 proppy: mongolito404: I think adding up_os_poker_skin=http://host/drupal/skin.css in the url is what is needed
11:24:33 proppy: mongolito404: but I may be missing something
11:25:50 proppy: here is my test
11:25:50 proppy: test("os_poker_skin", function(){
11:25:50 proppy: expect(1);
11:25:51 proppy: equals($('head link:last').attr('src'), 'http://host/drupal/skin.css');
11:25:51 proppy: });
11:27:35 mongolito404: equals($('head link[src=http://host/drupal/skin.css]').length == 1); is more robust
11:27:56 mongolito404: It is not required to be the last
11:28:26 mongolito404: But the test should also check that it's after the CSSs it overrides
11:32:37 proppy: mongolito404: may I ask why are u using head.eq(0) ?
11:33:40 mongolito404: To restrict the selector to the first found element
11:33:48 mongolito404: head:first is better
11:34:34 proppy: ok
11:34:46 proppy: mongolito404: there can be multiple head in a document ?
11:35:04 proppy: mongolito404: ah actually the