[00:02] <nnnaji> fagan: thanks! been waiting for unity --replace !
[00:03] <fagan> nnnaji: well unity without switches works the same
[00:03] <fagan> so its only cosmetic
[00:03] <nnnaji> learnability
[00:03] <fagan> yeah that was the idea
[00:03] <nnnaji> ;)
[00:03] <fagan> plus its no harm having
[00:05] <nnnaji> exactly :D
[00:06] <nnnaji> consistency doesn't always require major changes
[00:09] <fagan> well its all didrock's being awesome I just added a line to it :)
[00:33] <coz_> hey all
[06:14] <SteveC_> Hey there.  I am totally new at Ubuntu, and after a few days of using 10.10 with Unity, I realized I am missing my main system menu.  When I right click on the menu bar at the top, nothing happens.  However right clicking works most other places.  Is there a fix for this bug?
[06:56] <kvalo> morning
[10:04] <evaluate> umm, the indicator menu doesn't support text with underscores? You must be kidding me!
[11:12] <ronoc> hyperair, https://bugs.launchpad.net/ubuntu/+source/banshee/+bug/692887
[11:12]  * ronoc turns his attention to banshee integration bugs this week
[12:36] <vish> ronoc: neat..! :)
[12:46] <evaluate> hello
[12:46] <evaluate> any indicator dev here?
[13:51] <ronoc> evaluate, yup
[13:53] <evaluate> hey ronoc
[13:53] <ronoc> hey
[13:54] <evaluate> I noticed that underscores don't appear in indicator menu items, is this behavior intended?
[13:55] <ronoc> evaluate, I had noticed this before, do you mean the dbusmenuitem label string value ?
[13:56] <evaluate> ronoc, sorry, I'm not familiar with the terms you guys use
[13:56] <ronoc> evaluate, how have you noticed this ?
[13:57] <evaluate> ronoc, well, I'm working on a clipboard manager
[13:57] <evaluate> I use the menu to also show a history of the most recent copied items. If I copy items that contain underscores, the underscores don't appear in the menu
[13:57] <evaluate> for example if I copy 'g_gint64_format', in the menu I see: '
[13:58] <evaluate> 'ggint64format'
[13:58] <evaluate> if you want, I could paste you the exact steps I use to create the menu items...
[13:58] <ronoc> evaluate, ah so you are using the application indicator api ?
[13:58] <evaluate> ronoc, yeah
[13:59] <ronoc> evaluate, i have noticed this before but it could be true for some reason, the best thing to do would be to file a bug against application indicator
[14:00] <ronoc> evaluate, i work with the indicator stack but I'm not the owner
[14:00] <ronoc> evaluate, ted is on holiday's
[14:00] <evaluate> ronoc, yeah, I heard this name a lot of times recently. Who is he exactly? :-)
[14:01] <ronoc> evaluate, https://launchpad.net/~ted dx team - foundations
[14:01] <evaluate> btw, there are also problems with the formatting of menu items, which I have explained here: https://lists.launchpad.net/ayatana-dev/msg00052.html
[14:01] <evaluate> I could eventually send a reply to this to also explain the underscore bug...
[15:00] <ronoc> kvalo -> https://code.launchpad.net/~cjcurran/indicator-sound/playlist-integration/+merge/44351
[15:00] <ronoc> or are you on holidays ?
[15:07] <kvalo> ronoc: not yet :) on it
[15:07] <ronoc> kvalo, thx
[15:14] <kvalo> ronoc: why did you remove the vapi file? it shouldn't be in bzr?
[15:15] <joaopinto> which package should I use to file a bug for the global menu ?
[15:15] <ronoc> kvalo,  not using it any more
[15:16] <kvalo> ronoc: ok. approved
[15:16]  * kvalo logs off now. happy holidays everyone
[15:16] <spikeb> you too kvalo
[15:17] <ronoc> kvalo, thanks man, have a nice holiday
[16:20] <kenvandine> joaopinto, indicator-appmenu
[16:22] <joaopinto> kenvandine, bug 693046, should I add task for indicator-appmenu ?
[16:22] <joaopinto> it was reported at appmenu-gtk
[16:23] <kenvandine> that is probably fine
[16:33] <Amaranth> DBO: Remember those small API/ABI changes I was talking about for compiz?
[16:33] <DBO> yes
[16:33] <Amaranth> DBO: I think it's better to think of it more as "I'm ripping the opengl plugin API to shreds and putting something back in"
[16:34] <DBO> Amaranth, please dont break it
[16:35] <Amaranth> DBO: The current API is basically not usable with OpenGL ES unless I build my own OpenGL state machine inside the gles plugin
[16:36] <Amaranth> Well, it's probably not _that_ bad
[16:36] <DBO> yeah its probably not
[16:36] <DBO> either way
[16:36] <DBO> dont break shit
[16:36] <Amaranth> But, for example, GLFragment is exposed to the public API in almost every single function call
[16:36] <Amaranth> GLES doesn't have fragment programs :)
[16:37] <DBO> are you sure about that
[16:37] <DBO> Amaranth, I am looking at the OpenGL ES spec right now
[16:37] <DBO> it can run fragment shaders
[16:38] <Amaranth> shaders are different
[16:38] <DBO> right, so here is what I am saying to you
[16:38] <DBO> there is a functionality that is provided by GLFragment
[16:38] <DBO> that is to say its used to make some rather simple transforms
[16:38] <DBO> (in compiz)
[16:38] <DBO> rather than try to port GLFragment
[16:38] <DBO> you are merely trying to port how it is used in compiz
[16:41] <Amaranth> yeah, perhaps I'll have better luck tossing the current code and just trying to implement the interface from scratch
[16:41] <DBO> Amaranth, in cases like that yes
[16:41] <DBO> Amaranth, my recollection is GLFragment in plugins is only used for a couple of things
[16:42] <DBO> I would suggest attemption to write a fragment shader that can do the same things
[16:42] <Amaranth> DBO: brightness, opacity, saturation
[16:42] <DBO> and exporting a new, similar struct
[16:42] <Amaranth> GLFragment::Attrib
[16:42] <DBO> right
[16:42] <DBO> so its not a hard problem to solve
[16:42] <Amaranth> blur is screwed though :)
[16:42] <DBO> fuck blur
[16:42] <DBO> dont worry about blur right now
[16:43] <DBO> worry about basic plugins
[16:43] <DBO> think "Ubuntu default plugin list"
[16:44] <Amaranth> Right now I'm just worried about the opengl plugin
[17:20] <jcastro> DBO: is bug #692444 bitesizeable?
[17:20] <jcastro> it feels bitesizeable
[17:20] <DBO> yeah
[17:21] <DBO> its a medium to hard bitesize
[17:21] <DBO> but its in the range
[17:39] <jcastro> DBO: the top panel is how many pixels up and down, 22px?
[17:39] <DBO> 24
[18:04] <vish> akshatj: hi, did you figure out how to file the bug in debian?
[19:30] <seiflotfy> kenvandine,
[19:30] <seiflotfy> where do i find some docu for
[19:30] <seiflotfy> IndicatorObjectEntry
[19:31] <kenvandine> should be in the libindicator-doc pacakge
[19:31] <kenvandine> package
[19:31] <seiflotfy> nothing there
[19:31] <seiflotfy> :(
[19:31] <seiflotfy> oh shit
[19:31] <seiflotfy> sorry
[19:32] <seiflotfy> there is only libappindicator docs in trunk
[19:49] <seiflotfy> kenvandine, i can detect indicators that are being removed from the panel
[19:50] <seiflotfy> how can i identify them
[19:50] <seiflotfy> ?
[19:50] <seiflotfy> is there any identifier for an indicator
[19:54] <Amaranth> DBO: So even trying my best there are going to be some API changes
[19:54] <Amaranth> DBO: They'll be additions but you'll have to use them
[19:54] <DBO> explain
[19:54] <Amaranth> GLShader, GLShaderManager, GLVertexBatch I have so far
[19:55] <Amaranth> So instead of glVertex3f and such you'll setup a GLVertexBatch, possibly setup a custom shader, and call batch->draw(shader)
[19:56] <Amaranth> hmm, exposing the shader in the draw method would make us depend on GL 2.0 on desktops too, might want to rethink that part...
[19:56] <Amaranth> I have no idea how nux and it's shaders are going to interact with this yet
[19:56] <Amaranth> err, its
[19:57] <Amaranth> DBO: Basically changes required to make up for there being no fixed function pipeline anymore
[19:57] <DBO> okay lets take it from the other approach here
[19:58] <DBO> lets ignore shaders for a moment and look at only those plugins that modify the transform of windows
[19:58] <DBO> (aka 90% of them)
[19:58] <DBO> with me?
[19:58] <Amaranth> DBO: The simple ones just push matrices around, they likely won't need any change
[19:58] <DBO> correct
[19:59] <Amaranth> If you do any extra drawing or special transformations though...
[19:59] <seiflotfy> kenvandine, where do i find stuff about IndicatorsModel
[19:59] <DBO> Amaranth, so for things like special transforms you need a vertex shader
[19:59] <Amaranth> Yeah
[19:59] <DBO> which means you need a way to either:
[20:00] <DBO> A) define a shader which can be "programmed" by some struct you can pass around
[20:00] <Amaranth> I'm going to need a way to allow plugins to add functions that the main shader will somehow know to call
[20:00] <kenvandine> seiflotfy, dunno, is that from libindicator?
[20:00] <kenvandine> or libappindicator?
[20:00] <DBO> B) Allow plugins to define their own additional shaders
[20:00] <seiflotfy> kenvandine, i am having an issue
[20:01] <seiflotfy> kenvandine, i can connect to entries rmeoved
[20:01] <DBO> Amaranth, A) certainly can cover a large number of cases, but not all
[20:01] <Amaranth> DBO: defining their own shaders entirely wouldn't work as we need to combine them all
[20:01] <seiflotfy> however i can not identify the entry properly
[20:01] <kenvandine> seiflotfy, appindicators?
[20:01] <Amaranth> I'm going to have a few stock shaders though
[20:01] <seiflotfy> nope
[20:01] <seiflotfy> all indicators
[20:01] <seiflotfy> i am working on some panel stuff
[20:01] <DBO> Amaranth, you cant run shaders sequentially?
[20:01] <kenvandine> so using libindicator?
[20:01] <seiflotfy> yeah
[20:01] <Amaranth> DBO: You can only have one main()
[20:02] <kenvandine> seiflotfy, i can't even see where IndicatorsModel come from
[20:02] <DBO> Amaranth, wtf are you talking about
[20:02] <Amaranth> DBO: And no, I don't think you can run them sequentially
[20:02] <DBO> Amaranth, hold on
[20:02] <seiflotfy> yeah
[20:02] <seiflotfy> model = IndicatorsModel.get_default ();
[20:02] <seiflotfy>         var indicators_list = model.get_indicators ();
[20:02] <seiflotfy> this is vala code
[20:02] <seiflotfy>  to get all indicators
[20:02] <seiflotfy> however none of them have a real identifier
[20:02] <Amaranth> DBO: Shaders are C-like, they have a main function
[20:02] <seiflotfy> not even an internal one
[20:02] <kenvandine> seiflotfy, but what library provides IndicatorsModel?
[20:03] <DBO> Amaranth, yes I know, but you can run multiple shaders
[20:03] <DBO> Amaranth, I know this because we do it in nux all the time
[20:03] <Amaranth> DBO: I'll have to look at how that is done
[20:03] <Amaranth> DBO: afaik you can have one vertex and one fragment shader per glDraw* call
[20:03] <seiflotfy> kenvandine, let me ask
[20:04] <DBO> Amaranth, you have to use an intermediate draw to do
[20:04] <DBO> which I suppose is a bit of a problem
[20:04] <Amaranth> DBO: Yeah, that sounds more complicated
[20:04] <seiflotfy> kenvandine, ok nm that
[20:04] <Amaranth> And would use more memory
[20:04] <kenvandine> seiflotfy, oh, that is libunity
[20:04] <seiflotfy> kenvandine, so i have a list of indicators
[20:05] <seiflotfy> kenvandine, how do i identify them uniqeuly
[20:05] <ion> I wonder if it was noticed that bug #686698 isn’t in fact fixed yet? I’m unable to change the status.
[20:05] <DBO> Amaranth, the approach I would take would be to attempt to define a shader that can be parameterized in such a way to replicate existing functionality
[20:05] <seiflotfy> lets say i want to create a hashtable with <id, indicator>
[20:05] <Amaranth> DBO: Yeah, as much as possible
[20:06] <Amaranth> DBO: I imagine I can get most of the way there with that
[20:07] <DBO> Amaranth, yes
[20:07] <DBO> I am trying to raise jaytaoko
[20:07] <DBO> see if I cant get you a better solution
[20:07] <Amaranth> DBO: but afaik there is a limit to the amount of parameters you can pass to a shader
[20:07] <DBO> there are
[20:07] <Amaranth> Unless I want to load data in as a fake texture :)
[20:07] <DBO> ew
[20:07] <Amaranth> Thats how GPGPU stuff works, I agree it's pretty ugly
[20:07] <DBO> well I mean what plugins are we talking about here...
[20:08] <Amaranth> DBO: I dunno, I haven't looked yet, that's why I'm focusing on stock shaders for now
[20:08] <Amaranth> DBO: Or at least I was until you got me in to thinking about the rest of it :)
[20:08] <kenvandine> seiflotfy, why do you need to identify them?
[20:08] <DBO> well I dont want you to have to go back and redo this
[20:09] <Amaranth> the limit is something terribly low though, iirc it's 8 uniforms
[20:09] <kenvandine> get_indicators returns an ArrayList
[20:09] <kenvandine> should be good enough
[20:09] <kenvandine> then iterate over the indicators to do things with them
[20:09] <Amaranth> DBO: I've already tossed out 3 or 4 half ports of the opengl plugin to get to this point, one more won't hurt
[20:10] <Amaranth> DBO: Ideally I could sit down in a room with onestone and smspillaz and hash this out in an hour or so but...
[20:10] <seiflotfy> kenvandine, thanks
[20:10] <DBO> Amaranth, you can compile multiple shader objects into a shader program
[20:10] <kenvandine> seiflotfy, if you really need an id, there is a get_indicator_name in IndicatorsModel
[20:10] <kenvandine> you can always use that to get the name and store that
[20:10] <kenvandine> but i would just use the list if you can
[20:11] <Amaranth> DBO: Yeah, I know the compiler will just concatenate them but I didn't think it would actually work correctly if each one defines a main function
[20:12] <DBO> dont have them define a main, they would need to implement a well known name
[20:12] <DBO> so each plugin defines a shader function name (if any) and then on load compiz makes its shader main call the functions in the right order, if the plugin requests its shader be enabled
[20:13] <Amaranth> DBO: Right, that's what I said a few minutes ago :)
[20:13] <DBO> Amaranth, sorry I must have missed that
[20:13] <Amaranth> DBO: Each plugin provides a function and core somehow figures out what functions to call and modifies the main function
[20:13] <DBO> but still, try to limit the number of plugins requiring that
[20:13] <Amaranth> absolutely, mesa can apparently get a bit weird with that
[20:14] <DBO> I would suggest a bit-field to enable/disable functions
[20:14] <Amaranth> there is a code size limit for the compiler, I think
[20:14] <DBO> so you dont have to recompile the shader
[20:14] <DBO> is the code size limit for the compiler or for the shader objects?
[20:14] <htorque> hello everyone! to which package does the battery indicator belong?
[20:15] <Amaranth> DBO: I don't remember, will have to check
[20:15] <Amaranth> DBO: I don't think it matter anymore anyway, mesa got a new shader compiler
[20:15] <DBO> htorque, I believe its part of gnome-power-manager
[20:16] <DBO> Amaranth, thats true!
[20:16] <htorque> DBO, thanks
[20:16] <Amaranth> Although I'm mostly going to be focusing on specific SoCs
[20:31] <Amaranth> hmm, I think I'm going to apply these changes to the current compiz to verify I've got the right idea before I start porting things to egl/gles
[21:16] <Amaranth> DBO: So, hey, when do we get window previews? You can't say compiz doesn't provide a way for you to get them anymore :)