| alex_mayorga | Hi, is there a patch coming to let me tell firefox I want to see notifications even when in full screen? | 05:09 |
|---|---|---|
| vish | alex_mayorga: you need to ask MacSlow ;) he'd probably be here in a fwe hrs | 05:14 |
| vish | alex_mayorga: but it seems to be planned for lucid | 05:15 |
| alex_mayorga | I also believe that the whole urgency level should be left up for we users to decide | 05:16 |
| alex_mayorga | make those available as "System > Preferences > Notifications" | 05:16 |
| vish | alex_mayorga: the min you say "prefs" the idea is most likely to be shot down ;) | 05:19 |
| alex_mayorga | well whomever is in charge might want to take a look at #ubuntu+1 log from moments ago | 05:21 |
| alex_mayorga | I believe this would serve as a summary "I think is plainly arrogant to decide for users, what's important or not or how fast they should read and such" | 05:22 |
| vish | alex_mayorga: i agree the prefs are needed... But , *i think* , what they are trying to do is to get the default settings perfect before allowing the users to tweak at will... the default seems to be the high priority for canonical and the config/prefs are probably not in their schedule [unless someone outside works on them] | 05:25 |
| alex_mayorga | why try to get it to perfect for me, when just I will know what's perfect for *me* | 05:26 |
| alex_mayorga | and then "perfection" would be in the eye of the beholder in the end | 05:26 |
| alex_mayorga | but yeah, from the wiki I can tell configuration is not at the top of the priority list if at all | 05:27 |
| vish | alex_mayorga: well, you can of course switch/use the notification daemon :) | 05:27 |
| alex_mayorga | I've kind of got to that conclusion from what I've seen so far | 05:27 |
| alex_mayorga | just wanted to say once more that if you make it 100% configurable then you're done ;) | 05:28 |
| alex_mayorga | otherwise just get ready to deal with loads of "incorrect urgency" bug reports | 05:29 |
| alex_mayorga | as what is "important" for Jon Doe might not be for Jane Doe | 05:30 |
| ScottK | alex_mayorga: I totally agree with you, but that's not been the perspective of this project. | 05:30 |
| alex_mayorga | this is only being pushed in ubuntu, not upstream right? | 05:31 |
| vish | Ubuntu is upstream for notify-osd | 05:31 |
| alex_mayorga | ScottK, and is not turning over for what I see | 05:32 |
| ScottK | vish: Actually no. Ayatana is upstream for notify-osd. It's a separate project from Ubuntu (but also sponsored by Canonical) | 05:32 |
| alex_mayorga | vish: what are OSD "competitors" then? | 05:32 |
| vish | ScottK: argh! slipped Ubuntu==canonical ;) | 05:32 |
| vish | alex_mayorga: i dont think there are any competitors... unless you consider the gnome3 notifications/ message tray ... | 05:33 |
| vish | alex_mayorga: if you have been following the ayatana discussions.. any mention of a pref/gconf is most definitely shot down.. there is nothing much to say after that.. its their[canonical] money and their choosing of how they spend it... | 05:35 |
| alex_mayorga | I guess the last comment on https://wiki.ubuntu.com/NotifyOSD/Comments should do then | 05:42 |
| RAOF | alex_mayorga: It's already 100% configurable; you've got access to lp:notify-osd. Nothing else will be 100% configurable. | 05:43 |
| alex_mayorga | RAOF, mind elaborating on lp:notify-osd? | 05:44 |
| RAOF | That's the source branch. | 05:46 |
| RAOF | I'm suggesting that “100% configurable” and “useful” are in opposition. | 05:46 |
| alex_mayorga | RAOF, so you mean the only configuration point one has is the source code? | 05:54 |
| RAOF | alex_mayorga: No, I mean the only way that you can have a 100% configurable application is with the source code. But it's also true that the only configuration at the moment is the source code. | 06:01 |
| RAOF | alex_mayorga: I'm just disagreeing with your “if you make it 100% configurable then you're done” statement. | 06:01 |
| alex_mayorga | RAOF: I believe making it that way would render the "problem" non-existant | 06:03 |
| RAOF | At the cost of introducing new problems, yes. | 06:09 |
| ScottK | RAOF: Certainly, but OTOH, it's also equally impossible to design the one true configuration for all users. | 06:15 |
| === MacSlow is now known as MacSlow|lunch | ||
| === bratsche_ is now known as bratsche | ||
| seg|ars | djsiegel1: are you around? | 16:30 |
| djsiegel1 | hey | 16:30 |
| seg|ars | what do you think of this: http://gwibber.com/screenshots/misc/gwibber-navbar.ogg | 16:31 |
| djsiegel1 | seg|ars: dude, ace | 16:35 |
| seg|ars | you like it? :-) | 16:35 |
| djsiegel1 | yeah | 16:35 |
| seg|ars | awesome | 16:36 |
| djsiegel1 | but I don't think you should use colors for the full treeview | 16:36 |
| djsiegel1 | because you have indentation | 16:36 |
| seg|ars | yeah, I agree. I wasn't sure whether to keep it or not | 16:36 |
| djsiegel1 | seg|ars: can you make the message entry like pidgin's? | 16:38 |
| seg|ars | where it auto-expands? | 16:39 |
| djsiegel1 | 1/2 lines tall by default with auto-grow? | 16:39 |
| djsiegel1 | yeah, it's a very tall entry by default (what you have now) | 16:39 |
| djsiegel1 | would be nice to make it lighter | 16:39 |
| seg|ars | yeah | 16:39 |
| seg|ars | I'm not sure that I want to implement the auto-grow | 16:39 |
| djsiegel1 | yeah, would be a nice bonus | 16:39 |
| seg|ars | it's a very non-standard behavior for gtk and it creates tons of technical problems in pidgin | 16:39 |
| djsiegel1 | and it's already implemented, you just need to port from pidgin | 16:40 |
| djsiegel1 | it may only be a few lines | 16:40 |
| djsiegel1 | yeah | 16:40 |
| seg|ars | that's unfortunately not the case | 16:40 |
| seg|ars | the implementation they have is very specific to their UI | 16:40 |
| djsiegel1 | you are sure? | 16:40 |
| seg|ars | yeah, I've looked at it before and I've talked to one of the developers about it | 16:40 |
| djsiegel1 | ok | 16:40 |
| seg|ars | the gwibber team has been discussing that feature for about a year now | 16:40 |
| seg|ars | and it's just not practical to include it in the program at this time | 16:41 |
| djsiegel1 | right | 16:41 |
| djsiegel1 | good call | 16:41 |
| seg|ars | personally, I think that upstream gtk needs to provide native support for it in a way that is not a complete hack | 16:41 |
| djsiegel1 | then maybe go with a static, 2-line entry | 16:41 |
| djsiegel1 | yeah upstream gtk needs to move forward | 16:42 |
| djsiegel1 | they limit the imaginations of all app developers | 16:42 |
| seg|ars | it's really a very bad toolkit. Some of my recent experimentation with Qt has left with the impression that gtk is a dead end | 16:42 |
| seg|ars | the new sidebar that I showed you was built entirely with webkit | 16:43 |
| djsiegel1 | ha! | 16:43 |
| djsiegel1 | nice | 16:43 |
| seg|ars | it would have been a huge pain in the ass to do that with gtk and cairo | 16:43 |
| seg|ars | it's kind of ironic. I made gwibber because I wanted a native alternative to AIR apps, but more and more of the gwibber UI is html | 16:44 |
| seg|ars | wrt to the static 2-line entry, that's something I'll consider | 16:45 |
| djsiegel1 | ok, cool | 16:45 |
| djsiegel1 | 3 is just large | 16:45 |
| seg|ars | a lot of users really like having a resizable entry, but I think it creates too many problems | 16:45 |
| djsiegel1 | yeah | 16:45 |
| seg|ars | at the very least, the default behavior needs to be much better | 16:45 |
| djsiegel1 | ok seg|ars | 16:52 |
| djsiegel1 | seg|ars: this week's paperjam is gwibber | 16:53 |
| djsiegel1 | seg|ars: https://bugs.edge.launchpad.net/hundredpapercuts/+milestone/lucid-round-5 | 16:55 |
| seg|ars | ok | 16:56 |
| seg|ars | the one that interests me most on that list is the one about gwibber jumping to the top of the page | 16:57 |
| seg|ars | I'd love to find a good solution to that problem | 16:57 |
| djsiegel1 | seg|ars: can you assign someone on your team to work with me to collect 10 paper cuts? | 16:57 |
| djsiegel1 | if you have any juicy papercuts that you plan to fix for lucid, you can file them, or tell me and I will file and assign to you. | 16:57 |
| seg|ars | ok | 16:58 |
| seg|ars | for all of the papercuts relating to account management and creation, you can talk to kenvandine. He's working on our new account UI | 16:58 |
| === beuno is now known as beuno-lunch | ||
| seg|ars | I'll help you find other things to fill out the list | 16:59 |
| djsiegel1 | thank you, much appreciated | 17:02 |
| djsiegel1 | the only problem is getting people to hack on gwibber | 17:02 |
| djsiegel1 | since it's not easily hackabale atm | 17:02 |
| seg|ars | yeah | 17:02 |
| djsiegel1 | I think gwibber is an awesome place for newcomers to learn to write patches | 17:02 |
| djsiegel1 | it's so easy to hack and run | 17:02 |
| seg|ars | I've made some fixes to the overhaul branch that might make it runnable | 17:02 |
| vish | djsiegel1: hi... do you want to include this bug > Bug 253452 | 18:24 |
| ubot4 | Launchpad bug 253452 in empathy "Confusing error message when ICQ users have different encodings" [Low,Triaged] https://launchpad.net/bugs/253452 | 18:24 |
| djsiegel1 | vish: we already have ten for the paper jam | 18:25 |
| djsiegel1 | but I would add it as a paper cut but not schedule it | 18:25 |
| vish | ok sure | 18:26 |
| === beuno-lunch is now known as beuno | ||
| tedg | bratsche: What do you think about this API for fallback to StatusIcon? http://bazaar.launchpad.net/~ted/indicator-application/fallback/revision/47 | 20:12 |
| tedg | bratsche: I was figuring folks who want to do custom stuff, they can just subclass. | 20:13 |
| bratsche | tedg: So what would this do exactly? If you don't have the applet installed then it returns a GtkStatusIcon? | 20:15 |
| tedg | bratsche: Yeah. | 20:16 |
| tedg | bratsche: And if it comes back we'd get rid of it. | 20:16 |
| bratsche | tedg: Cool | 20:17 |
| tedg | bratsche: I've been debating signal or function, and I think a function makes the most sense. As the default functionality can be totally removed. | 20:18 |
| bratsche | So then does the application need to check for this and then set the GtkStatusIcon image and menu stuff itself, or does libappindicator do this internally? | 20:19 |
| tedg | The idea is that appindicator would do that automatically. | 20:21 |
| tedg | But, if you wanted to do something different than just having the menu hanging off the icon. | 20:21 |
| tedg | You could do that yourself by subclassing. | 20:21 |
| bratsche | Cool. | 20:21 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!