Attachment 'art-meeting080328.log'
Download--> You are now talking on #gnome-art giusef_ (~Zmax@151.81.9.91) has joined #gnome-art hbons (~hbons@82-169-68-10.ip.telfort.nl) has joined #gnome-art <-- giusef has quit (Read error: 145 (Connection timed out)) vuntz has quit (Ping timeout: 600 seconds) <Gyb> benzea, cool... then svg theming could even be much easier than with plasma's approach (ii just read its theming instructions and am not familiar with it) benzea, have a nice week ;-) --> vuntz (~vuntz@fennas.vuntz.net) has joined #gnome-art <Gyb> benzea, holidays or exams? ;-) has someone tried out gnome circular menu? *g* @ http://www.nanolx.org/free/cam.png erm here: http://code.google.com/p/circular-application-menu/ <hbons> that's pretty cool <-- fargiolas has quit (Ex Chat) <Gyb> hbons, already tried out? looks funny... but haven't tested it yet so i cannot say something about its usability =) <hbons> i haven't tested it <Gyb> it's faster than gimmie *g* <hbons> but it doesn't look very usable yet, specially because there are no labels and it's still a little bit like a maze if you look at the screenshots i did a radial menu mockup a long time ago: http://bomahy.nl/hylke/blog/some-gnome-3-ideas-get-rid-of-panels/ <Gyb> reminds me of the navigation of monkey island 3 ;-) nice <-- giusef_ has quit (Read error: 131 (Connection reset by peer)) zniavre has quit (Ping timeout: 600 seconds) --> crevette (~crevette@man06-2-88-167-44-76.fbx.proxad.net) has joined #gnome-art zniavre (~zniavre@dyn-91-171-226-247.ppp.tiscali.fr) has joined #gnome-art <Gyb> hbons, imho your mockup looks like a great interface for touchscreens! thos, new openmoko interface? *g* --> Rabbid (~hans@ti541210a080-7314.bb.online.no) has joined #gnome-art <thos> Gyb, ! --> giusef (~Zmax@151.81.10.53) has joined #gnome-art kasmol (~kasmol@host95-253-dynamic.18-79-r.retail.telecomitalia.it) has joined #Gnome-art <benzea> Gyb: holiday :-) --> monreal (~lithium@p57B666C6.dip.t-dialin.net) has joined #gnome-art jimmac (~jimmac@162-234-207-85.vychcechy.adsl-llu.static.bluetone.cz) has joined #gnome-art <Gyb> benzea, cool! --> akeem (~akeem@ip-91-187-45-68.static.hitech.cz) has joined #gnome-art <-- uV has quit (Remote closed the connection) <benzea> hm, 18 utc, not cet ... --> Cimi (~Cimi@host108-177-dynamic.0-79-r.retail.telecomitalia.it) has joined #gnome-art <Cimi> thos, http://www.gnome.org/~rodrigo/Screenshot-Appearance-Preferences.png <-- usability nazis :D <benzea> is that the metacity compositor? <Cimi> I guess so <benzea> it is kinda extreme <Cimi> yeah <benzea> one could move it to the interface tab ;-) <Cimi> or move Wm propreties <Gyb> thos really likes that shot.. cause it shows that there's someone in the worl who's using the new crux *g* *world <benzea> I think crux is used relatively often compared to mist or industrial though of course there are no stats whatsoever :-) <Gyb> have to admit that it looks quite good... perfectly for interface nazis^W^W freaks ;-) <Cimi> lol crux has problems with the toolbars too lines <benzea> it looks a lot better since the last couple of improvements thos did <Cimi> and maybe it has a strange bg color yeah <benzea> in my oppinion <Cimi> but still has problems with toolbars <benzea> dunno, doesn't seem bad to me <Cimi> #D9DBD9 try this bg color <-- SuavestBot has quit (thos) Rabbid has quit (Client terminated) <Cimi> thos, that bg_color and see this mockup for the toolbars http://img145.imageshack.us/img145/1193/schermatart9.png <thos> Cimi, is that just less gradient on toolbars? <Cimi> n o --> SuavestBot (thomas@muse.19inch.net) has joined #gnome-art <Cimi> just one 1px border between toolbars / menubar as in clearlooks --> Fre1 (~bellaich@LNeuilly-152-21-130-51.w193-253.abo.wanadoo.fr) has joined #gnome-art <Cimi> you just need to draw the dark border on the toolbar to every edge except the top so when you have two toolbars , 1 and 2 <-- SuavestBot has quit (thos) <Cimi> 1 is drawing the bottom border which is also the top border of the 2 <-- SuaveBot has quit (thos) <Cimi> just to understand if you actually have a cairo_rectangle (x, y, w, h) for the dark border on the toolbars it should become cairo_rectangle (x, y-1 , w, h+1) (but yeah this is ugly, just made to make you undestand what I mean) <Cimi> andreasn, 4 mins to the meeting? <andreasn> my clock says 7 err...6 <Cimi> 18 UTC isn't it? <benzea> Cimi: syncronise your clock ;-) <Cimi> oh ok :) 6 mins <benzea> five ;-) <Cimi> stfu benzea :P --> SuaveBot (thomas@muse.19inch.net) has joined #gnome-art <thos> ooh have a good meeting <thos> andreasn, decide what to do with art.gnome.org! <andreasn> hm? <thos> art.gnome.org should be for artists, not lusers ;-) <andreasn> I should do that? <Cimi> sudo rdate -s time.ien.it <-- sincronized :) <thos> andreasn, yes, yes you should <andreasn> aren't you staying? <benzea> rdate? <Cimi> I got permissions from kde team to reuse their submission guidelines for the contest <thos> andreasn, I have to go out for dinner :-( <benzea> Cimi: dunno, I just use ntpdate de.pool.ntp.org <Cimi> benzea, try it <andreasn> thos: ok <thos> andreasn, *someones birthday* or something ;-) <Cimi> same thing I guess <Gyb> Cimi, they're already doing a plasma theme contest ;-) <Cimi> Gyb, link? <thos> ah, bloody contests <Cimi> ^^ <thos> andreasn, you know there is no gdm themeing in gdm 2.24? --> dobey (~dobey@ip68-107-155-60.hr.hr.cox.net) has joined #gnome-art <dobey> bleh <andreasn> thos: yes <thos> cool <Gyb> Cimi, http://dot.kde.org/1206097090/ <dobey> this better be good <thos> uh oh I think we need a moderator! --> joxer (~joxer@195.110.151.126) has joined #gnome-art <joxer> hi people <Cimi> hi <-- zniavre has quit (Leaving.) <joxer> hi Cimi <dobey> thos: moderation is anti-freedom <Cimi> andreasn, so we can start? <joxer> i must follow the discussion while i'm studing biology sorry :) <andreasn> jimmac, lapo? mizmo? everyone here? <mizmo> yeppers <lapo> I'm here <dobey> joxer: that's ok, i'm working on car stereos <joxer> lol dobey <Cimi> here <joxer> dobey, my teacher hate me :| *hates --> kallepersson (~kallepers@81-236-233-148-no30.tbcn.telia.com) has joined #gnome-art <kallepersson> Hello hello. <hbons> hello <joxer> hi <lapo> so, eveybody here? <andreasn> just giving people a short while to catch up <lapo> uhm jakub missing <kallepersson> Great <lapo> jimmac: ping pong pang --> zniavre (~zniavre@dyn-91-171-226-247.ppp.tiscali.fr) has joined #gnome-art <lapo> andreasn: do you see tig on im? <Gyb> tigert is connected <andreasn> seems he's busy :/ <dobey> i'm busy, but i'm here <joxer> me too --> garrett (~garrett@charybdis-ext.suse.de) has joined #gnome-art <Cimi> andreasn, you should open a http://live.gnome.org/ArtMeeting <garrett> hi * <hbons> hey <lapo> yo garrett <dobey> what could one be busy doing in finland at this hour? drinking beer? <Cimi> hi all <lapo> andreasn: grab his ear and bring him here! :-) <andreasn> dobey: not impossible :) CIA-1 Cimi <hbons> this channel pretty much looks like #tango:P <lapo> dobey: lol <garrett> haha <dobey> hbons: that's right. <andreasn> Cimi: good idea, we can put meeting notes there anyway, jimmac seems absent <Cimi> wahoo <andreasn> but I think everyone else is here so we can start anyway <lapo> let's wait some seconds <hbons> vuntz is here, someone should kick him;) <jimmac> yo! <Cimi> hi jimmac ! <hbons> yo <joxer> but here what must we do? <lapo> heya czech one <benzea> we don't have no operators ;-) <lapo> wait lemme try to get my cousin here <Cimi> joxer, grab some popcorns and have fun with the meeting :) <joxer> Cimi, lol i must go to the tennis lesson! .-. * lapo summons ulisse <joxer> i can't follow the discussion weel :-\ <Cimi> where's ulisse? <joxer> lapo, giochi a FF ? <lapo> joxer: FF? <joxer> final fantasy <Cimi> omg <joxer> * lapo summons ulisse <- for this :P <lapo> joxer: noèe nope <joxer> lol <-- akeem has quit (Leaving.) <joxer> pinsava... --> ulisse (~ulisse@host82-129-dynamic.7-87-r.retail.telecomitalia.it) has joined #gnome-art <ulisse> yo <lapo> joxer: i giochilli jappo mi fanno incazzare come una lepre :-) <joxer> lol lapo, wii? <lapo> so, andreasn <hbons> yay <joxer> yo ulisse <andreasn> all right, ready to roll? <lapo> uhm, is better to roll after the meeting :-) <jimmac> kick it <kallepersson> haha, i read that as "ready to troll?" ready indeed <joxer> lolol <andreasn> so, basically I thought we should have a small meeting to coordinate our efforts for the next release <joxer> i'm ready <lapo> andreasn: wait a bit --> akeem (~akeem@ip-91-187-45-68.static.hitech.cz) has joined #gnome-art <andreasn> lapo: bringing in more italians? :) <lapo> keep in mind we have no moderation atm, so let's try to be nice without talking about 1000 arguments at a time <lapo> andreasn: nope, go on now :-) <dobey> hmm --> sgarrity (~steven@rind.silverorange.com) has joined #gnome-art <dobey> OH NO!! ITALIANS!!! <joxer> :O <benzea> hm, is there any list of topics that are goingt to be discussed? <joxer> megliu ._. * Cimi italian joxer is italian <andreasn> benzea: not really, but I hope we'll manage anyway <jimmac> i have mine :) <dobey> see what i mean :) <giusef> Italians == trash <joxer> .-. <Cimi> giusef, you're italian idiot <lapo> dobey: lot of them, almost a criminal sindicate, so watch out :-) <benzea> andreasn: ok, I guess things will just come up :-) <giusef> really? <joxer> giusef, are you zmax? ._. <andreasn> we had some kind of small roadmap last release, but I'm not sure what got done and if everyones stuff was on it really <giusef> yes I am <joxer> bba sparate giusef <dobey> hahahah <andreasn> so it would be cool to have a concrete roadmap as a result of this meeting <dobey> pokey today is perfect http://www.yellow5.com/pokey/ <andreasn> so, what are peoples plans for this release? anyone wants to start? <jimmac> I have three things I'd like to tackle they are mostly icon theme issues <vuntz> (guys, I'm sure minutes of this meeting would be of interest to lots of people, so send them to devel-announce-list!) --> Rabbid (~hans@ti541210a080-7314.bb.online.no) has joined #gnome-art <jimmac> first of all, it's rather bad KDE is following the naming spec and can use plain clean icon themes, while we have to depend on icon-naming-utils <hbons> yep * lapo look at vuntz <jimmac> so it's not possible for gnome users to take oxygen for example I don't really know what module would be responsible for this. maybe this is a general problem of each and every gnome app? <Cimi> jimmac, could kde users use tango for example? <jimmac> or is there a library that handles icon lookup? <dobey> jimmac: the main problem is the gtk+ stock icon bits <hbons> gtk.dgk i think <jimmac> Cimi: yes. the only issue is the lack of SVG support there <hbons> gdk <dobey> jimmac: everything else we can fix in gnome to just use proper names * kallepersson has a topic when jimmac is done <jimmac> dobey: what should I be filing bugs against? <dobey> jimmac: you should file bugs against the apps with the problems. the hackers can sort out whether it's a gtk+ or whatever issue that's what bug reassignment is for <benzea> does that mean that gtk+ would need a table to look up the new version of the icons? <jimmac> dobey: so it's every single gnome app? <dobey> it means that when someone requests gtk-foo it would need to know to look for whatever the spec name is instead jimmac: no. not all apps have problems <lapo> dobey: I think there was a plan in gtk to lookup for naming spec compliant icon before the stock icon <vuntz> what we can do here, is to have all apps use something like: http://svn.gnome.org/svn/gnome-panel/trunk/gnome-panel/panel-icon-names.h <dobey> jimmac: but i mean, the gtk+ stock stuff should mostly be obvious also --> iac_lizardking (~lizardkin@87.19.121.103) has joined #gnome-art <vuntz> then it's easy to know which icon names are used <jimmac> so the best way to do this is to apply oxygen, and file bugs against apps that don't show them? <iac_lizardking> Hello everybody! I'm Iacopo Masi <joxer> ciao iac_lizardking <lapo> hi iac_lizardking <Cimi> another italian guy :) <dobey> jimmac: that's one way, yes. we could fix g-i-t to not install symlinks in dev versions <lapo> dobey: can we disable the use of i-n-u during development period in git? <benzea> maybe one could write a script that lists the icons that are used by applications (dunno how hard it would be) <dobey> but it won't help if the symlinks are already tehre <jimmac> dobey: I am all for 'breaking' git to expose <lapo> +1 <hbons> me too <dobey> benzea: difficult, because not everything makes the same sinmgle API call to use an icon <andreasn> +1 <vuntz> jimmac: sounds like a good thing to do at the beginning of a development cycle :-) <benzea> ah, true <dobey> += 30 <jimmac> yea <andreasn> even better if distros do this too (during their betas), but just for the builds and gnome dev kit will work too <jimmac> so we could break git, create a tracking bug and people start filing icon bugs we make it dependent... <hbons> what about the non-gnome project apps? * jimmac tests thunar <dobey> andreasn: distros that ship the devlopment version in any way would get the same behavior <crevette> heya <andreasn> dobey: ah, good <dobey> hbons: this isn't the #non-gnome-app-art-meeting :) <lapo> dobey: if they don't patch it.... nor ship an old version, but let's don't care about distros now <dobey> i don't care about distros <hbons> dobey: no, but it's massive breakage <lapo> hbons: during dev phase, it should be not a big problem <dobey> hbons: broken apps are broken apps hbons: they can fix their broken apps if they break :) <hbons> :) <lapo> indeed, let's do it then <jimmac> nothing happens if kludgy worarounds are in place <benzea> I think that it should definitely be done in the unstable release cycle, one might want to put the symlinks in for the next stable release though <hbons> dobey: while don't we get rid of the bad gtk stock icon metaphors while we're at it first "while" -> why <jimmac> dobey: so are you willing to take the icon-naming-utils out og git trunk? <dobey> yes sure <jimmac> cool * jimmac will file the tracking bug <dobey> hbons: go for it <jimmac> so the other icon issue that hurts is inheritance <vuntz> make sure to announce this so people know they should file bugs about problems that appear --- sgarrity is now known as sgarrity_afk <jimmac> they way it works in gnome currently is that even if your current theme has generic type icons, specific mimetypes will be taken from inherited theme vuntz: announce in what way? <dobey> jimmac: alexl was wanting to fix that, and he did some work recently with allowing generic mime type icons <vuntz> jimmac: mail devel-announce-list and say "your icons will be broken, don't worry & file bugs :-)" <jimmac> dobey: cool, is that filed in the bugzilla? vuntz: gotcha <dobey> jimmac: it's in the mime spec in cvs <jimmac> fdo I suppose..? <dobey> jimmac: would have to ask him about specifics though, for getting it working in gnome yes <jimmac> well this is a gnome issue, so I'll just go ahead and file a bug against nautilus? <benzea> doesn't the file chooser need the same logic? <lapo> vuntz: can you interface with gtk guys (I was told mclansen may be the man) to have naming specs compliant icon lookup? <dobey> jimmac: well i don't know where to file the bug jimmac: glib/gio might be where it belongs these days <vuntz> lapo: I can try, if you guys tell me what's the problem, what should be fixed, etc. <lapo> vuntz: lookup for the corresponding naming spec icon before the stock one when an app wants a stock icon <jimmac> vuntz: there is a draft for a starndard icon naming spec - * jimmac looks up <lapo> vuntz: clear no? :-) <dobey> vuntz: resolving gtk-foo names to spec names, like gtk-open -> document-open, so that the theme icons get preference over stock names <jimmac> http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html so the gtk stock should only be used as a fallback <hbons> yeah <jimmac> it currently only works because of dobey's icon-naming-utils that create symlinks at icon theme build time. <vuntz> I mean, I know the spec. I just don't know what needs to be changed. Looks like it's the stock icons? <kallepersson> sounds like a great idea <crevette> dobey: you should change the @novell.com by something else :) <jimmac> yea, I understand it's 1) rename the stock icons, 2) make sure gtk uses the new names <andreasn> jimmac: isn't that breaking abi though? <dobey> crevette: change what where? <andreasn> jimmac: so it's more of a gtk+ 3.0 thing jimmac: (just #1 that is) <dobey> crevette: -latest.html != cvs trunk <lapo> jimmac: 1) may not be necessary with some programming magic <benzea> the icons names are compiled into every gtk+ app, so gtk needs to translate them <dobey> andreasn: it would break abi/api if you required the new names to work andreasn: if you create a table that says "this equals that" and then look up that, before this, it won't <dobey> which is the right way to do it at this point <andreasn> dobey: ah, ok <jimmac> too bad firefox3 will not use the stdandard names probably. <lapo> vuntz: is something clear for you now? :-) jimmac: indeed, it only uses stock stuff <vuntz> lapo: yep <kallepersson> brb supper <lapo> vuntz: do you think you can explain something clear to mclansen or some other gtk good soul? <vuntz> lapo: I'll try :-) <dobey> jimmac: doesn't matter if gtk+ does the right mapping thing <jimmac> vuntz: firefox3 is a nice example <dobey> jimmac: then it will Just Work (TM) anyway <lapo> ok, it sounds doable, let's move on <jimmac> vuntz: it is currently using gtk-* stock lookup so for themes that don't have the symlink hell, it's falling back to the gtk stock dobey: ah you're right. <lapo> jimmac: don't make your hacking side prevail, let's move on :-) <dobey> it's not "falling back" to the gtk stock. it's just not remapping to the new ones :) <jimmac> so for moving on... highres bitmaps versus svgs <lapo> good point <jimmac> it's a tough one. <lapo> yeah, svg is good, but it's limiting our magic to fight with different rendering libs and performance issues <jimmac> we have been traditionally creating a separate file per size but themes have gone through a lot of iterations. and it's very hard to make a change across a single icon in many sizes so much, that it's sometimes easier to create an icon from a different size rather than diving to the filesystem, and do some color copy/paste etc. I have experimented with having a single canvas that holds all the sizes. you can nicely see differences and reuse elements. it's very fast to take a larger size, scale, simplify... it is a really nifty workflow. <andreasn> jimmac: isn't it hard keeping track of the sizes? <hbons> jimmac: sounds like a good idea, specially for icon designers <jimmac> andreasn: what do you mean exactly? andreasn: for the export? <jimmac> that's another thing <lapo> andreasn: nope, with a nice template <andreasn> well, and the creation ah <jimmac> it's rather easy to do automatically <benzea> if you put all of them in a properly named group you can split it with a small program <jimmac> I have a layer that has just placeholder rectangled rectangles they are labeled by the output size and I abused the document metadata to use 'description' as the icon context name that way I can keep the source SVGs in one flat directory <lapo> andreasn: jimmac already has all the tricks to do the png magic <andreasn> great <dobey> except his "tricks" are in ruby <jimmac> and I have a ruby script that walks the SVG for the rectangles and calls inkscape to render PNGs <andreasn> it would be great if you could write down a small document/howto of the process <jimmac> the latest inkscape can actually chop the SVG into PDFs too <andreasn> but it sounds like a good workflow <jimmac> so theoretically getting SVGs out of the big canvas isn't totally impossible <lapo> jimmac: is it possible to extract svgs as well? <jimmac> I bet it's not too much work. I will talk to bulia <lapo> cool <jimmac> the question is, do we want to? <dobey> it would be nice if we could do the chopping with something a little less intense i guess <andreasn> I don't have any big objections <lapo> jimmac: +1 <jimmac> I have filed a bug against rsvg to do the id-based exporting <lapo> jimmac: exporting using rsvg would mean, fix all the redering issues it have <hbons> +1 too, but doesn't the chopping of icons all time take up resources too? <jimmac> it's actually decent <dobey> hbons: you only do it during "make" <lapo> hbons: it's only done at build time <jimmac> hbons: we don't need to do it at build time even <hbons> ah ok <jimmac> we can just be commiting the SVG+bitmaps and chop it up with the script manually <dobey> i owuld rather avoid bitmaps in svn <lapo> jimmac: having them exported with inkscape woiuld make our life easier tho <dobey> keeping svn as just the source is much nicer <jimmac> I am all ears in how we phase this in. I love the workflow I really do But it's a hell of work <lapo> jimmac: looks like you finally cured your pixel fetish eh :-) <hbons> but what if i want to make this "multi-icon" for a 3rd party app, it will require the script, no? <jimmac> it's not possible to assemble the one-canvas SVGs out of what we have :( <garrett> heh <hbons> wouldn't it be better to let gtk cut it? <jimmac> hbons: the result is a regular theme hbons: the only change is how you work as an artist. <lapo> hbons: it can be done manually naturally, it's only for "sources" <hbons> aha <lapo> jimmac: not possible, why? <jimmac> lapo: s/impossible/hard/ I don't know how I'd do that <lapo> jimmac: with some help I can manage most of the work here, I think jimmac: copy, paste, fix :-) <jimmac> that is a LOT of work.... AND there's this nasty inkscape gradient bug that is going to bite you <lapo> yeah, but it's not too hard, only death boring <jimmac> it's hours and hours of work <andreasn> anyway, clock ticks on :) <jimmac> I have no answers for this. <andreasn> moving along? <lapo> jimmac: like doing some 32x32? :-) <jimmac> also the problem with highres itself <lapo> that's another thing, we need to settle on a good template first <jimmac> it's neat. other platforms are doing it, but it's crazy time consuming. <lapo> we don't need everything in hires <jimmac> it isn't reasonable to do highres for all icons but if we don't shoudln't it be cool to keep our current scalables (48x48) scalable? <lapo> mimetypes + devices + trashbin will suffice for a start yeah it will be cool <jimmac> if we introduce a highres, say 256x256, being scalable and making the 48x48 fixed or threshold, it may annoy some people <lapo> we could let 48x48 scale to a certain extent then use the hires <jimmac> in that they used to have some icons scalable that aren't anymore <hbons> jimmac: one remark, where do you want the use them? <jimmac> so 48x48 should remian SVGs? * dobey doesn't care about annoying some people <kallepersson> jimmac: how does your highres ones look in for instance 64x64? <dobey> some people will just be annoyed no matter what <lapo> jimmac: I think it would be better <jimmac> hbons: talking about gnome icon theme <kallepersson> too much detail loss/blur? <lapo> kallepersson: atm kinda good <andreasn> hbons: do you mean if actual applications use it? gnome-do use pretty big icons <lapo> kallepersson: 256x256 made using a 4 px grid <jimmac> kallepersson: I am actually using them for 49x49+ <hbons> andreasn: yes <kallepersson> jimmac: nice. that's what is was thinking about <jimmac> it's only important to have 48x48 sharp as that is a common size <kallepersson> -is yes <lapo> jimmac: is it possible to have the 48x48 scale up to 63x63 then use the hires? <kallepersson> +1 <jimmac> highres is definitely a very long marathon lots of time per icon and iterations required <kallepersson> i can imagine, but imho we could add highres for some icons and then improve the set over time, no? <jimmac> lapo: if we have the 48x48 as an SVG still, perhaps <andreasn> if we get more artists aboard it could be done quicker <lapo> yeah * dobey wonders if he needs to be in here any longer <jimmac> lapo: let me tar up my Mango theme for you to try. <lapo> anyway remember we only need mimetypes + some other bits to start <kallepersson> dobey: i would like your opinion on my topic so please wait a bit more <lapo> jimmac: nice, let's see anybody played with hires apart me and jimmac? <lapo> andreasn for sure, right? <andreasn> lapo: some for some app icons like gossip and jamboree a couple of weeks ago <lapo> others? <kallepersson> a tiny bit, nothing done by far though <jimmac> lapo: http://jimmac.musichall.cz/stuff/mango-test.tar.bz2 lapo: untar to ~/.icons/ <lapo> ok, we need to define a template then we'll talk about the details later how should we start mangling g-i-t? what to do all the old cruft in it still? <jimmac> lapo: it inherits oxygen, so you'll get oxygen mimetype icons :/ <lapo> jimmac: shame on you! :-) <kallepersson> lapo: may I just get my topic out before you do? please? :) <andreasn> lapo: the stock stuff? <jimmac> andreasn: there's sticl gnome 2.0 styled stock icons <lapo> kallepersson: jimmac already said everything I would have said :-) <kallepersson> it's a quickie <jimmac> stick > still kasmol kallepersson <andreasn> kallepersson: shoot * kallepersson pastes <kallepersson> Me and Andreas have discussed the emblems. Something needs to be done. While we wait for it to be removed or improved by our hackers, it need to look good. I suggest that we try to fix them all asap and decide what to do with them in the future. Grapics can always be reused. <lapo> yay! emblems! <hbons> finally <lapo> kallepersson: I fear that fixing them graphically would make hacker not fix the code hackers <kallepersson> lapo: i disagree. just continue to bug 'em about it some were fixed some time ago, weren't they? at least there are some good looking ones to choose from, <andreasn> us refusing to draw stuff just creates a catch22, better to bring it up to discussion <lapo> kallepersson: naming spec stuff <kallepersson> lapo: okay <andreasn> so we don't end up with davidz media issue (that we discussed in #gnome-hackers yesterday) <lapo> frankly I prefer to just remove the old one and use a better system where emblems are actually usefull, but I'm a dreamer :-) <kallepersson> lapo: we could do that over time <andreasn> lapo: perhaps we need some ui people to take a look at the function <kallepersson> but atm there are oldschool emblems that won't look nice on the new fancy icons <andreasn> but it feels like a old eazel-leftover <dobey> i don't care about emblems. make them pretty with the current names and whatever <kallepersson> great (No buts!:) <dobey> not going to add them to the spec <lapo> kallepersson: can you do the fixing work? * hbons has something after this <dobey> but if you want to make them tangoish for now until things get fixed proper, then go for it <kallepersson> lapo: sure, but I might need some help dobey: that's exactly what I want. great * jimmac high fives kallepersson kallepersson high fives back <lapo> kallepersson: if you can just commit them to g-i-t then I'll touch them up if really needed kallepersson: if you can commit then, I can do it for you, you should have my email adress right? <kallepersson> yeah kasmol kallepersson I can commit 'em though. <lapo> cool, go on then <kallepersson> I need to practice on SVN :) kasmol kallepersson might take some while though, since work is super busy atm <andreasn> kallepersson: I have a dummy note for you :) <kallepersson> :) <andreasn> so, moving on? <kallepersson> It'd be cool to create a collection page on the wiki showing the progress I'll do that as soon as I get something done and I'll also be nagging you ppl about helping me out :) <dobey> eh go for it next. <kallepersson> But yeah, moving on ;) <hbons> color schemes <lapo> kallepersson: anyway promise to bug devs about fixing the emblem situation in a good way! :-) <hbons> the possibility to change gtk colors is great, but hard to pick by hand <kallepersson> lapo: okay, when I'm done ;) (brb) <hbons> it would be nice to have some schemes on the default theme (whatever it will be) in 2.22 24 <lapo> benzea, Gyb, thos, giusef: there is some work done already for colorschemes, right? <benzea> hm, nothing much happened on that side it seems I think we never were able to decide of where the color schemes should be stored <giusef> yep <benzea> ie. do they belong to the gtk theme, metatheme, some separate mechanism <lapo> can you mighty devs shake your brains together to get something sorted out on this front? :-) <-- Fre1 has quit (Leaving.) <hbons> benzea: they can just ship as .gtkrc files in the next release <benzea> some combination <hbons> not asking for UI or anything for it <benzea> no ui? <hbons> BlueCurve had a lot of variations in Fedora * dobey goes to do something else after having sat here for over an hour already :) <andreasn> dobey: later! thanks for bearing with us for the past hour :) <benzea> I am imagining a UI to choose from a small set of color schemes per GTK+/meta theme <andreasn> benzea: is it something that you think you will be working on for 2.24, or is it further down the road? <-- iac_lizardking (~lizardkin@87.19.121.103) has left #gnome-art <hbons> benzea: you select them now from the "Controls" tab <andreasn> hello? :) <benzea> sorry <giusef> for colorschemes, talking with Gyb and thos we decided to manage them like other themes <benzea> not sure, I guess it should be possible to pull it together for 2.24 <giusef> maybe inserting 1) a new tab for user defined ones 2) some options in the colors tab <hbons> giusef: that's ok too, but the current preview doesn't show the coors that great colors <lapo> let's try not to go into gory details now, can it be done for the next release? <giusef> I guess yes <hbons> i'm willing to create some nice schemes <kallepersson> hbons: are you reffering to Clearlooks colour schemes? <giusef> the user defined and theme releted schemes should be stored under the home directory <kallepersson> s/ff/f Can't you already create own colour themes while selecting theme? <hbons> kallepersson: any theme, if that's possible <giusef> by hand, yes <kallepersson> hbons: but can't you already do that (for clearlooks at least)? <giusef> kallepersson, What we are talking about is to create, store and if possible share, color scheme sets <benzea> sure, you can create color schemes with the UI or by setting the gconf key <hbons> kallepersson: you can, but you can't for example import a full scheme <lapo> ok, so we'll try hard to implement the colorscheme support for the next release, right? <benzea> you can safe the gconf key to store the color scheme <lapo> thos: no words from you? <hbons> kallepersson: and it would be nice to have some variations installed by default <andreasn> lapo: he's away <giusef> lapo, I'd like to work on it for a first contribute :-) <lapo> too bad! :-) <kallepersson> hbons: allright, I kinda get it more now :) <lapo> giusef: good! ;-) <benzea> it would be good to have at least one dark color scheme for clearlooks (and maybe others) <andreasn> hbons: would this mean we should drop some of our current themes (engines)? benzea: yes, totally agree d <jimmac> dark theme +1 <andreasn> a dark theme would be great <giusef> lapo I made a patch before.. rejected by Jens <lapo> benzea: yeah! +2 <hbons> andreasn: i don't think we need to drop anything <lapo> I'd like a nice flat engine as well, what about trying to use the olpc engine? * hbons is running a very nice dark clearlooks, that's the reason for scheme support:) <andreasn> lapo: I think gilouche works pretty well as a flat theme <lapo> andreasn: gilouche is cool, but it's noe exactly flat <lapo> not <andreasn> so you're talking about flat-flat? <hbons> ok, so, NEXT!:) <benzea> lapo: I had a quick try, the sugar gtkrc needs quite some fixing to make it work on a normal desktop next? <andreasn> ok, so the consensus is that we want to add a dark and a flat theme? ie. 1 dark, 1 flat but yeah, let's move on <Cimi> wallpaper!! <benzea> smaller themes should wa add a theme with smaller sizes (icons, and every thing else) in 2.24 <kallepersson> benzea: using 22 in menues instead of 32? <lapo> kallepersson: 32x32? <benzea> GNOME being to big on smaller resolutions is something that comes up every once in a while <lapo> I need to go now, be back in an hour, ciao <kallepersson> lapo: ciao <benzea> see the recent thread on the usability list <-- lapo has quit (Ex-Chat) <andreasn> benzea: yeah any volunteers to implement? <benzea> however as I see it it requires a separate theme for the small version, so I expect we should only have one <kallepersson> brb coffee time i do however think that a smaller theme would be neat. <benzea> it shouldn't be hard to add a couple of options to clearlooks to do it (based on the ClearlooksCompact theme that already exists) <kallepersson> for smaller screens and the new mini laptops that seems to be a new trend (!) <Cimi> benzea, we need to fix some thickness problems <benzea> I see the problem with icon sizes though, if we increase those the icons will will get blurry again, right? s/increase/decrease/ Cimi: true <Cimi> benzea, also moving focus drawing inside draw_button will work even in small and big layout/thicknesses <benzea> Cimi: I know that the current solution is broken :-) <Cimi> benzea, also the draw_topleft_highlight doesn't take care of the position and thicknesses it is broken with thickness = 0, 1 IIRC <benzea> I don't think it is even called if the thickness is not equals 3 <Cimi> for sure it is broken with = 0 benzea, it is and it breaks the themes <benzea> hm, maybe, so we see that clearlooks needs some fixes :-) <andreasn> so, to not get into details too much (we keep doing that :) ) will the two of you look into the small theme issue so we can have one for 2.24? <Cimi> andreasn, should be a work of few hours <andreasn> great! <Cimi> we just need to fix gtkentry and buttons <benzea> the theme itself, not getting the issues in the engine fixed :-) <andreasn> if you guys get too swamped in work, we can totally postpone some of it to 2.26 <benzea> I expect that it will take longer, but it should be doable <Cimi> benzea, the theme itself is a clearlooks with thickness = 2 <Cimi> andreasn, I will be busy with my transparent gtk engine :) <benzea> oh, icon sizes, should such a theme decrease them? <Cimi> benzea, no but it is simple just few lines of gtkrc <andreasn> benzea: I think so, yes, as long as it don't force them down below 16x16 <benzea> I am a bit afraid of blury icons ... but don't know if that may happen :-) <Cimi> I don't think so I guess it is the icon theme that will use the correct ones <andreasn> benzea: another thing that might help the small size is to turn some icons off for buttons and menus <benzea> Cimi: you need to set quite some style properties, then one may want a tweaked metacity theme, etc. <andreasn> or just one of them <benzea> andreasn: interesting idea <Cimi> no <andreasn> benzea: anyway, test what works and not <Cimi> metacity is ok <andreasn> and if you run into any icon isses, we can investigate those <benzea> sounds good <andreasn> so, moving on ARE YOU AWAKE PEOPLE?! :) <hbons> guess gnome is perfect <garrett> (: <Cimi> andreasn, wallz * garrett <- just lurking <andreasn> shoot <jimmac> andreasn: are you taking notes? <andreasn> jimmac: yes <jimmac> sweet <andreasn> jimmac: and I'll save the log <jimmac> * <Cimi> andreasn, we need abstract and transparent wallpapers <Cimi> I also thought, but it requires some changes that thos shouldn't love :) to add more capabilities to the control center CIA-1 Cimi <andreasn> Cimi: what did you have in mind? <Cimi> like automatically select a color taken from bg[selected] to use it with transparent bg benzea did something similar for his experience engine isn't it? so when I change my gtk theme to a green one my wallpaper (if it is transparent), will become green <benzea> in the eXperience engine the gtkrc defines what colors may be replaced <andreasn> would this replace the colors selector in the Background tab? <Cimi> no <benzea> I would think we would just add a way to pick a theme color by default there <Cimi> but we may provide a check like *use gtkrc colors* <andreasn> could this go in the same combo box? <benzea> though I guess that may be hard from a ui point of view (resetting it to use the themes color when the user has choosen a custom one) <Cimi> when the check is on -> the color picker are off <benzea> oh, that is a good point <Cimi> off = disabled <benzea> just add a "theme color" in the combobox <Cimi> but they preserv the last picked color <andreasn> benzea: I think that sounds sane don't make the ui that much more complicated it don't make... <benzea> (implementation detail could be to use a symbolic color or style property instead of some fixed GTK color) <kallepersson> andreasn and Cimi: transparent wallpapers is ++ <benzea> I think I'll be leaving soon <Cimi> benzea, ski trip tomorrow? :) <andreasn> anyway, moving on with wallpapers, thos wanted to replace the ones in gnome-backgrounds module, right? <Cimi> oh I don't know <kallepersson> andreasn: do you know wich ones? <kallepersson> whichÄ * <benzea> nah a bad headache now for whatever reason ... kasmol kallepersson <andreasn> kallepersson: most of them I think kasmol kallepersson <kallepersson> but why? aren't they nice? <andreasn> kallepersson: I helped draw a couple of them quite some time ago, and they are starting to age :) <Cimi> not so nicec -.- <andreasn> the are cute, but not good :) <Cimi> stars are fun :) mizmo monreal <kallepersson> ah you are referring to the pattern ones, not the photos <andreasn> jimmac, mizmo: does fedora or suse ship with gnome-backgrounds installed by default? * Cimi <- dinner <kallepersson> I would totally like to help with creating some patterns <-- giusef has quit (giusef) --- sgarrity_afk is now known as sgarrity_lurking <kallepersson> andreasn: suse doesn't <kallepersson> iirc --- sgarrity_lurking is now known as sgarrity <andreasn> sgarrity: perhaps you know <sgarrity> As someone who's been afk the whole time - would I be too much of a jerk to bring up a suggestion? <sgarrity> andreasn: checking. <andreasn> sgarrity: not at all <sgarrity> Has anyone brought up monocrome simple-shape icons for status/panel icons? <kallepersson> nope <sgarrity> (volume, network manager, etc.). <kallepersson> that'd be interesting to discuss <andreasn> sgarrity: I know the ubuntu art people are working on it, the results so far don't look that good, but I haven't tried them in action <sgarrity> Do people know what I mean? <kallepersson> yep <sgarrity> It would really have to be a decree: Gnome says icons on the panel must be X. (distributions are welcome to frack it up on their own if they choose) <andreasn> yes <mizmo> andreasn, fedora does yep <andreasn> sgarrity: I think it would cut down some noise <mizmo> (sorry i got pulled away from my desk) <andreasn> so I'm all for testing it out perhaps talk to the ubuntu art people if it's something they want to work with us on <kallepersson> sounds nice <andreasn> jimmac: any opinion? <kallepersson> I'm not really sure if it's a great idea to be honest... but heck, it's definetly worth trying out. A major concern would be all the apps that decide to place themselves in the systray (banshee etc) <-- zniavre has quit (Ping timeout: 600 seconds) <kallepersson> What about them? Their icon is their own brand, so they wouldn't want to make that monochrome <garrett> sgarrity: I agree on that mostly monochrome & simple shapes for the panel status icons <sgarrity> kallepersson: right - we don't have the totally control that Mac OS X has, but 3rd party apps still tend to follow it on the mac. <garrett> sgarrity: tigert, jimmac, and I talked about it years ago and then tigert implemented it in the N810 (; <sgarrity> I have Last.FM and QuickSilver on a testing mac here and they are both simple monochrome shapes. <garrett> (years later) <andreasn> :) <mizmo> are you sure the apps wouldnt be willing to go to monochrome <sgarrity> If it's actually consistent and looks good, app developers might feel inclined to match the style. <mizmo> totally, give them a nice slick example graphic.... hard to say no :) <sgarrity> right Tango has kind of worked that way (mostly). <andreasn> I'll try to find a url to the ubuntu stuff and see if we can build upon that I'll send it to themes-list later <mizmo> it's easier to argue against words than slick gfx <andreasn> and check with kwwii if he wants to cooperate on it <mizmo> especially if u volunteer to help with icons for said slick gfx ;-) <garrett> (: <andreasn> cool, moving on? <sgarrity> a simple spec might be a good place to start (with examples). <dobey> ugh <kallepersson> sgarrity: i see, well it would be nice if 3rd party apps did follow it <dobey> not the monochrome panel icons thing :( <sgarrity> not just monochrome, but yeah. <kallepersson> mizmo: I don't know. Just kinda assumed <hbons> monochrome == evil <kallepersson> andreasn: great <garrett> yeah, color for important things <dobey> s/monochrome/greyscale/ <garrett> like if the battery is low, red or part of it <kallepersson> garrett: good idea and perhaps package updater? <garrett> but simple icons w/ reduced color palettes, mainly greyscale yeah <kallepersson> and perhaps pidgin -new message- ? <garrett> anything attention getting, but that should not be its default state <kallepersson> yeah <dobey> i really just don't think it's feasible in gnome/kde <hbons> garret: yep reduced color palletes sound better <garrett> see N810 status icons for excellent examples <dobey> n810 is ok because the n810 is very well controlled it's not a bar that you can arbitrarily embed anything in --> alex-weej (~alex@cpc1-acto9-0-0-cust931.brnt.cable.ntl.com) has joined #gnome-art <dobey> for instance, not all things you would want monocorhome are tray icons and not all applets are things you want to be monochrome <garrett> yeah, and there are some apps that dock icons in both GNOME and KDE panels <hbons> dobey: i fully agree with you <dobey> plus the fact that you can place things in arbitray locations on the screen makes it even more fun garrett: well anything that uses the "system tray" can <-- dashua has quit (Remote closed the connection) <garrett> right <dobey> garrett: and there's work being done on "universal applets" <sgarrity> sure, but we could encourage/recommend a simpler visual style <dobey> which adds even more fun into the mix <sgarrity> developers are free to ignore us. <dobey> sgarrity: encourage/recommend for what? sgarrity: application icons? <sgarrity> for Notification Area icons and common system tray applets. dobey: I don't mean launchers. <dobey> those are the same thing <andreasn> people can do stupid stuff on the mac bar too, but most don't <dobey> not area == sys tray applets == something completely different <garrett> andreasn: true <garrett> dobey: but some applets are treated like the tray icons <sgarrity> dobey: right, sorry. I mean both common applets AND sys-tray/notification. <dobey> andreasn: most don't because most people don't do anything with the mac bar <garrett> like the volume and such <-- monreal has quit (Ex-Chat) <dobey> garrett: yes, but you end up with this case-by-case basis that becomes very problematic whenever anyone writes a new applet or anything <-- joxer has quit (All is one, one is all) <garrett> yes, but if we had this implemented, it would be nice <dobey> sgarrity: yes, my point being that "app launchers" are "common applets" <garrett> app launches are different <dobey> i don't think it would be nice exactly my point <sgarrity> garrett: agreed --> zniavre (~zniavre@dyn-91-171-237-122.ppp.tiscali.fr) has joined #gnome-art <dobey> and the pidgin status icon behaves like an app launcher <sgarrity> We're so flexible we can't do anything... <dobey> or like the taskbar <andreasn> sgarrity: yeah :( --> dashua (~dashua@pool-151-204-31-4.pskn.east.verizon.net) has joined #gnome-art <kallepersson> yep <dobey> sgarrity: that was exactly the point i was making, yes :) the panel is way too arbitrary <sgarrity> ok, I see I've started a tired old thread again. <andreasn> sgarrity: anyway, I think it's worth looking into and if we run into a wall, well, so be it <garrett> well I have an idea what if we have mockups to show for it... and blog about it <hbons> spam the planets with it! <garrett> we can start a discussion and see if people like it right if it looks cool, then that's one way to get traction <dobey> yes, because spamming people into supporting it, is clearly the way to get it done, and means it will actually work i mean, it works for viagra, right? <garrett> dobey: not really spam it, obviously <hbons> yeah:) --> kp2 (51ece994@webchat.mibbit.com) has joined #gnome-art <-- Company has quit (Read error: 131 (Connection reset by peer)) <sgarrity> dobey: If only you had been around to shit all over viagra... <dobey> garrett: mock-ups from artists will always look cool and people will like them. that's the whole point of mock-ups. :) --> Company (~company@e176122207.adsl.alicedsl.de) has joined #gnome-art <sgarrity> Forgive me - friday crankiness. <kp2> great meeting! <garrett> dobey: exactly <hbons> http://hbons.deviantart.com/art/Tray-example-77444161 <dobey> sgarrity: you. beer. now. garrett: the problem with mock-ups is that they likely won't actually be what the end result will look like for most people <vuntz> two different places)"./W 23 <garrett> hbons: oh that clock design looks a bit familiar (: <vuntz> oops :-) <hbons> jimmac's! <garrett> dobey: yeah, that can be a problem hbons: it is true that the panel can be made to look better even w/o monochrome icons the sizing is one thing <dobey> garrett: see the slab panel mock-ups you/jimmac did and how the panel doesn't look like that :) <garrett> and spacing dobey: yes, they had monochromatic icons (: <dobey> it would be great if we totally killed gnome-panel and replaced it with something where we had much more control garrett: yes i know <vuntz> I'd love to get feedback on how the panel could be improved for artists <hbons> garrett: yeah, everyone thinks it's better monochrome, because the current situation looks ugly. that doesn't mean getting rid of the colors will solve it. we need better sizes, spacing and palettes <garrett> so then, what about the visual styling of the gnome panel? the tasklist gets pretty ugly, especially when there are a lot of tasks open hbons: yep, that would help for sure <dobey> i know, why don't we kill the panel, and put a bar at the top of the screen with notification icons and stuff, and a "dock" at the bottom of the screen, that only has larger icons for applications, and doesn't have text on it and then we can have this other "view" where people can place "applets" that show the weather, or flight status, or let them look up things on google :) <hbons> heh * kallepersson lurks <andreasn> so, moving on? one thing that I would like to bring up is that we're lacking people our artists get too much to do to quickly and if there was more of us, that wouldn't be the case <dobey> well, one problem is also that developers always send us requests for things, though they don't necessarily truly need to have icons for them <andreasn> dobey: yes perhaps we could get hold of some ui people to give it thumbs up or down <dobey> and we don't have a formal request system <-- phiker has quit (blubb) <dobey> we get requests via bugzilla, mailing lists, private mails, and who knows how else <andreasn> perhaps we could gather stuff on a page on live.gnome.org <mizmo> i get personal email requests o_O hard to keep track of <andreasn> because I have a very hard time to keep track of stuff <mizmo> we have a design queue wiki page in fedora for the art team which works well <andreasn> mizmo: url? <mizmo> http://fedoraproject.org/wiki/Artwork/DesignService (wiki v. slow, thats the only problem :( ) we've bust moin out at the seams <dobey> wikis are slow anyway <andreasn> does it work well? <dobey> you have to actively go check to see if there's anything new <mizmo> andreasn, it does <mizmo> dobey, you can subscribe to the wiki page everytime someone adds something or changes something u get an email alert (part of the reason why moin is so slow :( ) <mizmo> andreasn, whenever we getr personal emails or requests to the list we've made it a policy to ask the requestor to list out the request in the wiki page <mizmo> actually we get most requests in irc <andreasn> ah, cool <mizmo> so, this makes sure it's written down and theres a record and ownership <dobey> mizmo: but what does it send you? the mediawiki rss sucks <mizmo> im not saying it's the best way of doing it but it's simple and not difficult to set up dobey, it sends you a diff <dobey> fun <mizmo> dobey, it's sufficient for me again :) not saying it's perfect <andreasn> I think it sounds better than what we have now <dobey> i think that's obvious :) i think i would rather use bugzilla though <andreasn> some kind of web service might be nice further down the road though --- kp2 is now known as kallepersson_ <dobey> it would be nice if there was a way to "file bugs" without having to have an account on bugzilla <mizmo> i was talking to thos about that before :) maybe ago could have a request system <andreasn> would it work to just have a artwork-request module? <kallepersson_> sounds neat <mizmo> maybe <andreasn> we can also list bugs in a wiki page hm it's starting to get late here and I didn't have any dinner yet <dobey> yeah <andreasn> anyone object to continue another day * dobey needs some food too <kallepersson_> mizmo: offtopic: nice ajax spinnnner <andreasn> like sometime next week? <mizmo> kallepersson, ? where oh in the design service page? hehe thnx <kallepersson_> yeah, new concept <andreasn> anyway, need to sign off <sgarrity> andreasn: you'll post the log? <sgarrity> A summary would be ideal if someone can do the work. <andreasn> I'll write down some notes in the wiki and save the log thanks everyone for your time! <-- sgarrity (~steven@rind.silverorange.com) has left #gnome-art <kallepersson_> great job arranging this andreasn <hbons> andreasn: where are you going to post the notes? <andreasn> hbons: live.gnome.org and I'll probably blog about it too <hbons> ok:) <andreasn> later all! --> Daniel_GC (~danielgpl@pc-224-36-83-200.cm.vtr.net) has joined #gnome-art
Attached Files
To refer to attachments on a page, use attachment:filename, as shown below in the list of files. Do NOT use the URL of the [get] link, since this is subject to change and can break easily.You are not allowed to attach a file to this page.