=== GreySim_ is now known as GreySim | ||
mac_v | mpt: https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/388633/comments/8 | 10:20 |
---|---|---|
mac_v | maybe you could comment there itself | 10:20 |
mpt | mac_v, done | 10:48 |
mac_v | ah... | 10:52 |
SiDi | MacSlow: woot, nice blur :) | 10:58 |
MacSlow | SiDi, brought to you with a lot of pain :) | 10:59 |
SiDi | hehe i can imagine it's not been easy | 10:59 |
SiDi | congratulations :D | 10:59 |
SiDi | btw i think i saw a sync notification with text in the test schemes | 10:59 |
MacSlow | so? | 10:59 |
SiDi | does that mean i could use the sync notification's progress bar for a media player notification where the progress bar would be the advancement of the song ? :P | 10:59 |
MacSlow | argl no! | 11:00 |
MacSlow | :) | 11:00 |
SiDi | :p | 11:00 |
SiDi | now i can harras my family with math formulas via ssh, its great | 11:00 |
mac_v | MacSlow: there have been users complaining that the notify-osd bubble is not obvious on a dark background , how about having a dim grey 1px border? wouldnt that solve the visibility a bit? | 11:06 |
SiDi | mac_v: no :P | 11:07 |
SiDi | I think a border wouldnt look sexy at all | 11:07 |
SiDi | if its not readable for them they-should-be-able-to-change-the-colour | 11:07 |
mac_v | 1px is not a border! | 11:07 |
SiDi | yes it is | 11:07 |
mac_v | its just to differentiate the bubble from a dark background | 11:08 |
SiDi | anyway other users complain they cant read white text on black without massive visual effort, and this has to be fixed :) | 11:08 |
mac_v | SiDi: baby steps ;p | 11:08 |
SiDi | that'd be a fairly old baby then | 11:08 |
MacSlow | mac_v, SiDi: There will probably be some gconf-keys for background-, text- and text-dropshadow-color | 11:09 |
mac_v | \o/ | 11:09 |
SiDi | i hope you remove this probably word :D | 11:09 |
SiDi | MacSlow: i'll begin my xfconf port soon so i might in the same time add code for this, ill tell you if i managed to do it | 11:10 |
MacSlow | the nasty thing about this will be the schema/autotools mayhem | 11:10 |
* MacSlow is not looking forward to this | 11:10 | |
* MacSlow -> lunch | 12:35 | |
=== MacSlow is now known as MacSlow|lunch | ||
mac_v | mpt: haha another dup of the same issue, ;p > https://bugs.launchpad.net/hundredpapercuts/+bug/391404 , http://launchpadlibrarian.net/28266448/Captura_de_tela-Abrir.png , IMO this does not look pretty! | 13:06 |
=== MacSlow|lunch is now known as MacSlow | ||
mac_v | mpt : i'v done a mockup , "you can scroll this!" visual hint mockup> http://launchpadlibrarian.net/29043629/Mockup.png still not convinced? | 13:54 |
SiDi | isnt it possible in gtk to differentiate the prelight one and the active one ? | 13:55 |
mac_v | SiDi: https://bugs.launchpad.net/hundredpapercuts/+bug/388633/comments/6 | 13:57 |
mac_v | its not the decision about the prelight, but the present option needs to be the centre | 13:57 |
SiDi | mac_v: if you can have prelight and selected differently | 13:58 |
SiDi | you can put the "current" value at the top | 13:58 |
SiDi | it'll have the "selected" color and be recognisable | 13:58 |
mac_v | SiDi: i suggested that also , finally we have similar thoughts , ;p | 13:58 |
* SiDi hides | 13:58 | |
mac_v | SiDi: https://bugs.launchpad.net/hundredpapercuts/+bug/388633/comments/7 | 13:59 |
SiDi | :) | 14:02 |
SiDi | that was a bit rude :p | 14:02 |
mac_v | which? | 14:02 |
mac_v | my comment? | 14:03 |
SiDi | yeh | 14:03 |
SiDi | But i'm nonely better than you for that :p | 14:03 |
mpt | mac_v, sorry, I don't understand what that mockup is showing | 14:04 |
mpt | partly because I can't see where the menu started, perhaps | 14:05 |
mac_v | the scroll arrows | 14:05 |
mpt | Those scroll pseudobuttons that GTK uses inside the menu are really quite ugly | 14:05 |
mpt | They don't behave like buttons, so they really shouldn't look like buttons | 14:05 |
mac_v | mpt: but we have to do with what we have :( | 14:06 |
mpt | Well, no, if you're proposing a change in appearance, you can do that for any part of the menu :-) | 14:06 |
mac_v | SiDi: i wasnt trying to be rude :( | 14:07 |
SiDi | mac_v: i didnt say you tried to | 14:09 |
SiDi | what happens is that often when you report a bug you believe you are right (im the first in that case and sometimes i AM rude, but i notice later) | 14:10 |
SiDi | so you explain why things _have to_ change instead of stating that they _could_ change | 14:10 |
SiDi | i dont know if im very clear :P | 14:10 |
mac_v | mpt: a better mockup from bugzilla> http://bugzilla.gnome.org/attachment.cgi?id=47137&action=view | 14:10 |
mac_v | SiDi: ;p | 14:10 |
mpt | mac_v, yes, exactly | 14:11 |
mac_v | mpt: the one on the right is better, and a patch for it exists! | 14:12 |
mpt | Here's a scrolling menu on the Mac: http://developer.apple.com/documentation/userexperience/Conceptual/AppleHIGuidelines/XHIGMenus/XHIGMenus.html#//apple_ref/doc/uid/TP30000356-BABBBABH | 14:12 |
mpt | and on Windows: http://www.prof-uis.com/prof-uis/feature-tour/tour_menu_bar.aspx#Figure7 | 14:12 |
mpt | though I don't think that Windows one is particularly native | 14:13 |
mpt | It looks very Office-XP-ish | 14:13 |
mac_v | mpt: the apple one is better, but i dont understand what you mean? the bugzilla mockup still doesnt do the trick? when a better solution exist for now ,why are we searching for an elusive best solution? | 14:16 |
mpt | mac_v, the Bugzilla mockup is what I had in mind in my first comment in that bug report. | 14:17 |
mpt | (Though I didn't know there was a mockup of it.) | 14:17 |
mac_v | they also have a patch | 14:18 |
=== agateau_ is now known as agateau | ||
SiDi | mpt mac_v as far as i know windows doesnt have native comboboxentries at all | 14:21 |
mpt | SiDi, true, Windows has "drop-down listboxes" instead, but I was looking more at how the OSes show menu scrolling in general | 14:21 |
mpt | (The name "ComboBoxEntry" is a monumental confusion on the part of whichever GTK developer gave it that name. A combo box is already a combination of a menu and a text entry. That's where the "combo" comes from.) | 14:23 |
mac_v | SiDi: see proper naming is needed ;p | 14:23 |
mpt | Ah, here's a more native-looking scrollable menu in Windows: http://vbnet.mvps.org/images/gfx/menu/menuscroll.gif | 14:24 |
mac_v | mpt: do you want to re-think that gtk bug? or is it still invalid | 14:24 |
SiDi | Lets rename it to ScrollableListThatMakesAGoodConversationSubjectForAyatana then | 14:24 |
SiDi | the main problem is filling this white space, right ? | 14:27 |
mpt | mac_v, I have no new facts with which to rethink it. :-P I can see how it could be argued either way, and the GTK developers have chosen one way, and you prefer the other. | 14:27 |
SiDi | Cause actually removing it would make it a loss of vertical space when you do need to scroll :/ | 14:27 |
mac_v | mpt: ok. | 14:28 |
SiDi | What about appending the last items on the top empty space with a big vertical separator between beginning and end ? | 14:28 |
SiDi | and make it possible to scroll to top to reach the bottom faster ? (i wonder how _confusing_ this could be for users, but at least the space would be exploited :/) | 14:28 |
mpt | That would be ... strange | 14:33 |
SiDi | ok, lets put it in the "stupid ideas" box. :D | 14:35 |
SiDi | mpt: mind having a look at https://wiki.ubuntu.com/Ayatana/UpdateIssues and commenting it please ? | 14:36 |
SiDi | mac_v: you didnt add the updates on login/logout to it btw, i was expecting you to do so :D | 14:36 |
mpt | SiDi, thanks, I'm planning to write a design spec for handling updates and this will be good source material | 14:38 |
SiDi | i need to detail it a little more though but i'm being lazy :) | 14:39 |
mac_v | SiDi: i think the better way is to do in-session updates and not disturb the user > https://bugs.launchpad.net/hundredpapercuts/+bug/397324 | 14:41 |
SiDi | mac_v: can you please add this as issue #5 on the UpdateIssues page above and add your solution for it ? | 14:42 |
mac_v | SiDi: sure... BTW what is issue #5? | 14:42 |
SiDi | the issue you describe in your bug report :) | 14:42 |
mac_v | oh... ok | 14:42 |
SiDi | ie. "it MUST be restarted" statement when it should be "changes will be applied after a restart" | 14:43 |
SiDi | We also need to add another issue for apps that do need to be restarted after an update and find a decent compromise for these | 14:45 |
SiDi | (or remove firefox from the repo and close eyes on the problem :X) | 14:45 |
SiDi | i get instant answers from ubottu in our xubuntu chans | 14:51 |
SiDi | wrong channel ~ | 14:51 |
ScottK | SiDi: For Firefox it must be restarted or it won't work. Must is right. | 14:53 |
SiDi | ScottK: indeed | 14:53 |
SiDi | the idea is to tell the user BEFORE it screws his FF | 14:53 |
SiDi | and provide an option to automatically delay the installation of those packages and those that depend on them, on session close | 14:54 |
mac_v | SiDi: why do you insist on NO TOC? | 15:01 |
mac_v | its better to navigate the page | 15:01 |
SiDi | mac_v: it looks ugly. :D | 15:02 |
SiDi | put one if you want its ok ;) | 15:02 |
SiDi | dont put one with an ubuntu-art icon though | 15:02 |
SiDi | and remove the float=right too imo | 15:02 |
mac_v | ;p , i forgot to remove it the last time! | 15:02 |
bratsche_ | Morning! | 15:03 |
SiDi | hi | 15:04 |
djsiegel_ | danrabbit: can you please s/elebuntu/humanity ? | 15:10 |
djsiegel_ | and move the wiki page? | 15:10 |
jblount_ | MacSlow: When you get a free second, I'd love to chat with you about notify-osd via ssh -Y | 15:26 |
MacSlow | jblount_, not this week I'm afraid... best in such a case is email me | 15:27 |
jblount_ | MacSlow: Will do. Thanks! | 15:27 |
mac_v | mpt: oops! i didnt realize i missed a word in #5! it is actually! "Further evidence of" i'll correct it | 15:49 |
=== jblount_ is now known as jblount | ||
=== GreySim is now known as ToolSim |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!