Design/Meetings/2012-11-17

Attendees

 * alexanderW
 * Astron
 * Medieval
 * Mirek2
 * riidom

Topics

 * XML Sources dialog
 * New icons
 * Color picker
 * Template dialog
 * Defaults
 * Global options
 * Conditional formatting
 * Gallery

Tasks
Alex Astron Mirek2
 * Work on the new Tango icons
 * Create icons for XML Sources
 * Look through .ui files
 * Contact Cédric about meeting with im
 * Update the Color Picker design
 * Contact ux-advise
 * Large icons by default
 * Icons in menus
 * Removing options entries
 * Update Global options analysis
 * Look through OpenClipArt

Log
[16:02]  mirek2, was Kohei asking for icons that would replace the ones visible here: https://wiki.documentfoundation.org/File:XMLSourceDialog.png? [16:03] yes [16:03]  ah, okay [16:04] would you like to make the icons? [16:05]  sure, but I guess I'd need to read up a bit on XML or ask Kohei [16:06] ok [16:06] great [16:07] now that we're on the topic of the dialog [16:08] what do you think about it? [16:09] for comparison, this is the MS implementation: http://www.sleepingdog.org.uk/semanticweb/rdf/excel/publishing/images/excel2007xmlmapping01.png [16:10]  Does one have to link specific XML elemets to cells again and again? [16:10]  If we have e.g. two entries, each having an ID [16:10] I think linking a category links all of the subcategories [16:11] (I know Kohei explained this to me, but I don't remember 100%) [16:11] I suggested to Kohei that the linked items should be visually set apart from unlinked ones [16:11] bolded, probably [16:12]  that'd make sense [16:13]  Well, I think the dialog looks good [16:14] what do you think about moving the "Linked cell" picker below the "Map to document" area [16:14] to make the dialog more space-saving [16:15] so that the user can see more of the spreadsheet while in the XML dialog [16:15]  It looks a bit lost, but since the size depends on the file-path I'm not sure what could be done [16:16]  I thought of that, too, but what would be the benefit? The size of the window would increase even more [16:16] the size doesn't have to depend on the file path -- the path could be shortened [16:17] or we could even just show the xml file name [16:17] like Excel does [16:17]  Okay, then I'd prefer to have that 'Linked cell' fiel below the XML map [16:18] okay [16:18]  I assume that's not yet an .ui file? [16:19] I'm not sure, but I think it is [16:19] are you thinking of editing it yourself? [16:21]  Well, the most work would be truncating the path, so Kohei would probably need to do that first [16:21]  Afterwards me or anybody else could do the rearrangement [16:22] alright [16:22] next topic? [16:22]  sure [16:22] 4.0 branding + icons? [16:23]  yes... [16:23]  flat icon theme? [16:23] <Medieval> flat icon theme?+ [16:23] <Medieval> is it coming some day or is it only proposal? [16:24] <alexanderW> not too shiny, but I'm not sure about completely flat [16:24] It's not coming anytime soon [16:24] it may come one day as the Android port progresses [16:24] the response to the new icons on Google+ has been less than stellar [16:25] <alexanderW> indeed [16:26] I think we just need to replace a few icons and polish a few icons up, though, so they feel like a set [16:26] <alexanderW> I'll redo some of them with flatter gradients [16:26] which ones? [16:26] <alexanderW> eg the diagram one [16:27] <alexanderW> the table [16:27] <alexanderW> data sources [16:28] <alexanderW> then maybe use a compass icon for the navigator [16:28] <alexanderW> do you think that would be better than that star we have now? [16:29] yes, I think a compass would be beter [16:29] better [16:29] the table definitely should be redone [16:29] could you color just the top row and leave the other rows blank? [16:29] and perhaps use blue for the top row, as the other icons already use a lot of orange [16:30] <alexanderW> sounds good [16:30] great :) [16:30] <alexanderW> you mena transparent rows or white/grey? [16:30] <alexanderW> *mean [16:31] white/grey [16:32] also, the drawing toolbar seems kind of incohesive [16:32] as the style of the shape icons is completely different from the style of the other icons [16:32] and the Gallery icon sticks out like a sore thumb [16:32] I mean the fontwork icon [16:32] <alexanderW> The gallery sticks out like one :) [16:33] <alexanderW> yes [16:33] I would just hide that icon by default [16:33] <alexanderW> an 'a' with a magic wand? [16:33] <alexanderW> I would, too [16:34] <alexanderW> btw, do you know how items from the default toolbar can be removed/ added to it? [16:34] <alexanderW> I mean the decision process in tdf [16:34] if it's a change people are likely to agree with, you can do it yourself [16:35] if it's likely to be controversial, bring it up on the ux-discuss mailing list [16:36] <alexanderW> Should I ask wrt several questionable toobar items? [16:37] such as? [16:37] <alexanderW> Data sources in Writer, Gallery, Fontwork [16:37] I don't think you need to ask in that regard [16:37] but you can if you'd like [16:37] btw, always just hide the icons, don't remove them [16:38] <alexanderW> ok [16:38] <alexanderW> What would you think about adding conditional formatting to the calc toolbar? [16:39] I liked your proposal [16:39] <alexanderW> IMHO it's a pretty major feature [16:40] yeah, I think so as well [16:40] btw, could you redo the "Line" icon as well? [16:40] <alexanderW> for the drawing toolbar? [16:41] yes [16:41] <alexanderW> I will [16:41] cool :) [16:42] anything else to add about icons? [16:42] <alexanderW> I don't think so [16:42] next time, could you upload the screenshot to a third-party site (e.g. deviantart)? [16:43] I think a lot of people criticized the icons without having a close look [16:43] <alexanderW> For comments? [16:43] <alexanderW> ah [16:43] <alexanderW> ok [16:43] because it's hard to view the image at 100% in G+ [16:44] <alexanderW> OT: I asked whether the elementary designers would have time for an IRC meeting today at 20:00 UTC, but didn't get a response yet [16:44] <alexanderW> I noticed that, too [16:44] I noticed [16:45] maybe they'll just show up [16:45] <alexanderW> Harvey is currently there [16:46] <alexanderW> Color picker? [16:46] alright [16:47] <alexanderW> Had a conversation with Markus [16:47] <alexanderW> one sec [16:48] regina brought up some good points [16:49] <alexanderW> yeah [16:49] about CMYK [16:49] <alexanderW> no CMYK support in the UI? [16:49] <alexanderW> as solution? [16:50] I was thinking that too [16:50] or, alternatively, we could show a note on the CMYK tab [16:50] <alexanderW> better not have a broken feature [16:50] but if we don't actually support CMYK, I don't think we should have a CMYK tab to begin with [16:50] yes [16:50] I agre [16:51] e [16:51] <alexanderW> "Additionaly we have no way to use ARGB right now in the UI while it is [16:51] <alexanderW> supported in the code. So we should find a solution that most likely [16:51] <alexanderW> limits the standard color palette but offers an easy way to define [16:51] <alexanderW> custom colors. " [16:51] <alexanderW> So one can define opaque colors theoretically? [16:51] you mean transparent colors [16:52] I assume just for certain objects [16:52] <alexanderW> oops, yes [16:53] I would just add an Alpha slider below the HSL color wheel and below the RGB sliders [16:53] <alexanderW> agree [16:54] and below the eye dropper label, if that feature is implemented [16:54] should we rename "LibreOffice Colors" to something? [16:54] "Default palette"? [16:54] LibreOffice Palette? [16:55] <alexanderW> Default palette maybe [16:55] Predefined Colors? [16:55] <alexanderW> No need for redundancy [16:55] ok [16:56] I don't think we can make the label for "Document colors" any more clear [16:57] any suggestions on how to make document colors clearer? [16:58] <alexanderW> 'Colors in use'? [16:58] that could work [16:58] <alexanderW> minus the set of colors that are a subset of the selected palette [16:58] <alexanderW> ^^ [16:59] actually, it includes all the colors in use [16:59] and it's a palette in itself, so there is no other selected palette [17:00] <alexanderW> Well, it's not stored as palette [17:00] it acts as a palette [17:01] and, theoretically, it could be stored as a palette within the document [17:01] <alexanderW> yes [17:01] <alexanderW> Markus mention that there might be performance problem [17:01] <alexanderW> *s [17:02] I think we'll definitely need a document colors entry [17:02] <alexanderW> Yeah [17:03] what would you suggest? [17:03] <alexanderW> in what regard? [17:03] to avoid performance problems [17:03] I don't really see a way around it [17:04] <alexanderW> Check every minute if there are new colors in the xml? [17:04] hopefully, the implementation will be good enough and there won't be performance problems [17:04] <alexanderW> or update the palette every time one applies a color or cemoves one from the text [17:04] <alexanderW> I hope so, too [17:04] alexanderW: don't we just need to check when the document is opened? [17:04] and then, yes, update it once a person applies a color [17:05] <alexanderW> What when you apply new colors? [17:05] or removes a color, true [17:06] I was just reiterating what you said [17:08] btw, recent colors apply to the document or to libreoffice as a whole? [17:08] <alexanderW> Anything else? [17:08] <alexanderW> I guess to the document [17:08] <alexanderW> would be empty if one opens a document [17:09] any way to make that clear? [17:09] <alexanderW> tooltip? [17:10] == astron247 [~frootzowr@dslb-088-072-038-203.pools.arcor-ip.net] has joined #libreoffice-design [17:10] over the "Recent" label? [17:10] hi astron [17:10] discussing the color picker [17:10] hi [17:11] <alexanderW> hi [17:11] <alexanderW> would that be enough? [17:11] I suppose so [17:11] <alexanderW> good [17:11] :) [17:11] <alexanderW> :) [17:12] one more thing Regina mentioned [17:12] "This color picker does only consider the "color models" version of color choosing. Corel Draw for example knows mixing with methods blending and harmony of color, and choosing from palettes (without "loading" them)." [17:12] not sure what she means [17:12] a color scheme designer, maybe? [17:12] i think so. [17:13] but i don't think we need that [17:13] <alexanderW> out of scope for 4.0, I guess [17:13] (at least not immediately) [17:13] I think so as well [17:13] though it would be a nice addition down the line [17:13] (dunno if you have discussed this yet) but i guess CMYK is the bigger problem [17:14] <alexanderW> we would skip that [17:14] we discussed it, and decided not to to have it at all [17:14] yes, sounds sensible [17:14] ok [17:14] <alexanderW> astron, did you try to compile that patch I mailed? [17:14] ah, i guess not... [17:14] what patch? [17:15] <alexanderW> Adding icons to the template manager [17:15] alex had to jump through some hoops to get the template mgr icons in [17:15] (second! [17:15] ) [17:15] <alexanderW> :) [17:15] <alexanderW> Jan helped me [17:15] sounds good. [17:16] one more thing about the picker: scroll bar [17:16] I had a few different thoughts: [17:16] <alexanderW> show it if a palette has more than n rows? [17:16] anyway, i dont know if i can try it today (i have no build right now), but will do it tomorrow [17:16] a) just add it to the right [17:16] <alexanderW> Thanks a lot [17:17] b) shrink the color "tablets" to make room for it [17:17] d) add up/down buttons to top and bottom? [17:17] c) have an ever-present white space at the right that could become a scrollbar, like GMail does [17:17] yes [17:18] :) funny how your d came before my c [17:18] i know. i couldnt wait. [17:18] <alexanderW> c) [17:18] alright [17:18] I think that's probably the best solution [17:19] astron, what do you think? [17:19] mirek, i dont know what you mean with your gmail example. [17:19] here, gmail has a (somewhat ugly) grey bar at the side... [17:20] sorry [17:20] now i know [17:20] alright [17:20] i think i would still prefer b [17:21] ok, I'll mock up both, see which one is better [17:21] are there any situations in which a non-palette screen would need a scroll bar? [17:21] i guess, youll have to mock up the transition between them ... [17:22] a non-palette screen? [17:22] what transition? [17:22] astron247: e.g. "custom color" [17:22] from a palette that needs a scrollbar to one that doesnt (and the other way around) [17:23] mirek2: the palette list might need one [17:23] (which is one reason i put it on the right, not on the left) [17:23] hm, not sure how to mock that up in Inkscape [17:23] astron247: I realize that [17:24] well, it should be somehat easy to take michels mockup – it just switches out background images named something-1, -2, -3 etc [17:24] ^somehat^somwaht [17:24] hm, I'll take a look [17:25] I didn't put the sidebar on the right because that wouldn't follow the standard order of information [17:25] right, but looking at it from the persepective of what's most important..? [17:26] with a scrollbar present, the triangle that appears next to the label could either be foregone or could just appear next to the scrollbar [17:26] (and also more expected coming from previous releases of libo [17:26] (e.g. in the style of the gnome applications overview sidebar) [17:27] astron247: I would say most UIs opt for a sidebar on the left [17:27] it's more logical [17:27] not sure what you mean by "more expected coming from previous releases of libo" [17:28] since libo never had a sidebar like this [17:28] right, and people will get the usual picker on the left, and gain a new sidebar on the right [17:28] if they're ready for it, theyll see it, otherwise they can just work with it like before [17:30] does that make more sense? [17:30] well, the whole picker is very different from the old one, size-wise [17:30] and given that we're implementing this with font color and background color first [17:30] which appear on the right of the font toolbar [17:31] users would now get the sidebar right below the icon if it was on the right [17:31] good point [17:31] and the picker/palette to the left of it [17:32] anyway, let's move on to another topic [17:33] <alexanderW> I converted some button columns into the stands [17:33] <alexanderW> *standard rows at the bottom: [17:34] <alexanderW> https://gerrit.libreoffice.org/#/c/1094/ [17:34] <alexanderW> Are you okay with these changes? [17:34] nice :) [17:34] I think so, though I'll have to try it out for myself to be sure [17:34] ah great, part of what was a topic at the esc call [17:34] (sorry for the so far missing log) [17:35] that's ok :) [17:35] <alexanderW> no problem, we always have the minutes [17:35] anything from the call that we should discuss now? [17:37] hm... not really, but theres an fyi: [17:38] * the android app of andrzej is on a rather aggressive schedule, to be released with 4.0 [17:39] alright [17:39] * oh, and next week is the munich hackfest [17:39] * Dec 9 is feature freeze [17:39] right [17:39] is the template dialog being readied for 4.0? [17:40] aumngh! [17:40] sorry, i didnt discuss that [17:40] ok [17:40] do we want to set up a meeting with cedric? [17:42] <alexanderW> Yeah [17:42] :) ok [17:42] what time suits you? [17:42] or should we just meet during the next irc chat? [17:43] or perhaps we could just voice our concerns on the esc? [17:43] <alexanderW> maybe the next irc chat? [17:44] i think we should try contacting cedric first – see if he is going to be available for anything like this..? [17:44] alright -- would you contact him? [17:45] okay.# [17:46] could you raise the topic of switching to large icons on all systems by default on the next ESC call? [17:47] or should I just send an e-mail to ux-advise? [17:47] I guess I'll send the e-mail, then you can discuss it on the esc [17:47] i could [17:47] fine [17:47] everyone here agrees with the idea, though, right? [17:48] i agree with it. [17:48] you could spin it as were moving to higher dpis etc. [17:48] (and of course, the gnome icons look better in 24*24 [17:48] ) [17:48] :) [17:49] (but thats not such a good reason) [17:50] <alexanderW> Global options [17:50] alex, do you agree? [17:50] <alexanderW> yes [17:50] just a sec: [17:50] if you read the thread by cor nouws, you know we discussed having icons in menus [17:51] alex, did someone answer your request for the shape default colour? [17:52] <alexanderW> not yet [17:53] hm... [17:53] ok [17:53] <alexanderW> can't find the thread [17:55] http://listarchives.libreoffice.org/global/design/msg05019.html ? [17:56] <alexanderW> Hm... [17:56] mirek? [17:56] <alexanderW> What was the decision? [17:56] <alexanderW> Having them in the menus all the time? [17:57] that would be what Cor and I would like, yes [17:57] <alexanderW> Same here [17:58] as that makes the menus a whole lot more usable [17:58] <alexanderW> Makes it easier to find specific items [17:58] <alexanderW> Good [17:58] I'll post that to ux-advise as well, then [17:58] astron, would you be ok with having it that way? [17:59] with having icons in menus by default [17:59] i dont like the decision for housekeeping reasons, as a users id probably be supportive :) (i think i said something similar last time) [17:59] yes, I think you did [18:00] so... is that a yes or a no? [18:00] i tend to be on the housekeeping side overall [18:01] as long as we have a small icon option, we'll need to support them anyway [18:02] and it's expected for some commands not to have an icon [18:02] right. and as long as we have icons in menus, we have excuses for people to make even more of them... [18:02] <alexanderW> making commands without icons [18:02] <alexanderW> ? [18:03] or making more icons? [18:04] making more icons... (my message was slightly late) [18:04] honestly, I think we have a deficiency of people wanting to make icons, so I don't think that's a danger just yet [18:05] and if it was, we could just tell those people to convert old non-Tango icons to Tango [18:05] okay, whatever [18:06] so ok if I pass this on to developers as something to implement? [18:06] we dont have to have consensus on everything, right? just post it on ux-advise [18:06] alright [18:07] on global options in general [18:07] https://wiki.documentfoundation.org/Design/Analyses/Global_Options [18:08] <alexanderW> Easy-hackify them? [18:08] well, we'd need a design first [18:08] <alexanderW> the removal [18:08] ok [18:08] <alexanderW> I think that alone takes quite some time [18:09] what do you mean by needing a design for adding the icons to meanus? [18:09] wouldn't it be easier to just implement a new design right away? [18:09] astron247: I was talking about global options in general [18:09] ah okay. [18:09] we've discussed most of the things [18:10] do we have consensus to make Writing Aids generic? [18:10] <alexanderW> what were writing aids again? [18:11] https://wiki.documentfoundation.org/Design/Analyses/Global_Options#Writing_Aids [18:12] <alexanderW> yeah, generic [18:13] astron? [18:14] hm, so "check spelling as you type" is a bit of an odd one. why is this in global options? [18:15] i would expect it in a menu (given how it has a toolbar icon) [18:16] then, check special regions: do we need that? [18:16] I suppose it could be useful in certain situations [18:16] I'm not sure, though [18:16] hah. [18:17] I was also surprised to see "Check spelling as you type" under options [18:17] additionally, the first three hyphenation options sound like we could get them right with language specific defaults. [18:18] astron247: I think hyphenation depends from person to person [18:19] I can't remember the last time I wanted something hyphenated, though [18:20] well, there are documents where youre required to hyphenate [18:20] == riidom [~khaosoahk@e176042037.adsl.alicedsl.de] has quit [Read error: Connection reset by peer] [18:20] astron247: yes, but I would leave the hyphenation up to the user [18:20] <alexanderW> yes [18:20] okay [18:22] about spell-check options: theoretically, we could integrate them into the spellcheck dialog [18:22] instead of having them in options [18:23] i dont think that would make much sense... how often are they used? [18:24] how often is the Spell-check dialog used? [18:25] i know its f7 and i dont really know many libo accels [18:25] so, pretty often. i think they would be in the way there [18:25] the options could be in a single drop-down menu [18:25] drop-down? [18:25] astron247: wouldn't they be more relevant there? [18:26] astron247: if the options are rarely used, it makes more sense to have them in a drop-down, no? [18:26] going by that argument, we probably wouldnt have any central options [18:26] (ie. the relevance argument) [18:27] that would be a good thing, imho [18:27] why would it make more sense to have them in a dropdown? so people could use them more often? [18:27] having options available where they're relevant [18:28] in a drop-down in the Spelling and Grammar dialog [18:28] similarly to what Google does with options [18:28] or elementary [18:28] (they have a gear with more options) [18:29] and, to be honest, the spellcheck options under writing aids make more sense when used on a document-by-document basis to me [18:29] rather than as options to set for the whole of libreoffice [18:30] (i.e. there are instances when you don't want to check for capitalization errors or special regions, but, in most cases, you do want to check for them.) [18:32] right, but dont these options also apply to the redlining effect? [18:33] yes, they do [18:34] then that is probably part of the reason... [18:34] hm, alright [18:36] in that case, Check spelling as you type should remain in the Options dialog as well [18:37] i think it might fit in the tools menu [18:37] and id really like to get rid of that tool bar icon [18:37] alright, sure [18:38] <alexanderW> the first spell-check icon? [18:40] yes [18:40] so, except for that, can I mark all the writing aids options as generic? [18:40] (the one that toggles the red underlines) [18:41] <alexanderW> having them enabled by default? [18:41] yes [18:41] <alexanderW> okay [18:42] uhm, mirek... i really think the whole language modlues thing belongs into advanced [18:42] alright [18:42] yes, I agree [18:43] except that, make all generic, and then add something about check as you type being more suited to the tools menu [18:43] alright, great [18:44] I'll look through the mailing list conversations with developers and fill in the blanks [18:45] afterwards, should we start a whiteboard for designing a Global options dialog, or should I just start the analysis of options for the different modules? [18:45] <alexanderW> analysis [18:46] <alexanderW> first weed out the superfluous stuff [18:46] you mean remove the options that we marked as unnecessary even before we start a redesign? [18:47] <alexanderW> yes [18:47] one of the ideas i had for a long time is this: if any developer adds an option, make him take two away... [18:47] <alexanderW> I guess we will re-use many panes, right? [18:48] astron247: :) I'd rather he just check with us [18:48] mirek2: of course he should take away one of those that we marked. [18:48] alexanderW: well, the idea was to redesign the whole thing [18:48] (also, i know it probably would never work) [18:48] astron247: that makes sense [18:49] <alexanderW> But keep the structure of tabs (or similar) and panes. Or not? [18:50] alexanderW: probably not [18:50] I think it would be good to reduce in such a way to only need a few category tabs at the top [18:50] <alexanderW> I see [18:51] but we'd do a standard whiteboard to pick out a design, of course [18:51] <alexanderW> ok [18:52] so I'll start the whiteboard after we've analyzed the options for the different modules [18:53] anything else left to discuss? [18:53] <Medieval> Is all icons represented in icon themes used in libreoffice? [18:54] most of them are in use [18:54] theres a bug aiming for removal of all the superfluous ones... ill try finding it [18:55] https://bugs.freedesktop.org/show_bug.cgi?id=42454 [18:55] <alexanderW> astron247: What do you think about adding captions to conditions applying to all cells, like here: http://www.java2s.com/Tutorial/Microsoft-Office-Excel-2007Images/Format_Using_Color_Scales___Specify_Description_Then_Click_Ok.PNG [18:56] (there might be another, more appropriate bug) [18:57] alexanderW: that's a good idea, however, it would take much more space than now, the whole dialogue would stop working like it does now... i am a bit wary of that idea [18:58] <alexanderW> why would it stop working like it does now? [18:58] <alexanderW> I'm only talking about the buttons etc. which are visible for 'All cells' [18:58] right now, every condition is still somewhat compact, ie. one condition takes ~3 rows [18:59] if we changed it to be closer to excels layout, it would probably be 6 rows [19:00] (or more) [19:00] <alexanderW> let me just scratch what I had in mind [19:00] in any case, you could make a mockup and put it on the design list [19:00] (btw, sorry, i didnt answer your mail about that idea) [19:01] <alexanderW> i'ts okay [19:01] <alexanderW> one min [19:04] <alexanderW> ... [19:05] okay, id like to ask one more thing... [19:07] <alexanderW> yes [19:07] <alexanderW> http://ubuntuone.com/61V3lOCdXP10f0iqeWdQLE [19:07] on the esc call, we were asked for one^Wtwo moreprojects: [19:07] * look through openclipart.org for suitable cliparts for the gallery [19:07] * look through all the new .ui files, to to see if something in them needs attention [19:07] is there anybody who'd be willing to do the former? (i know, alex already started on the latter) [19:08] I guess I could try the former [19:08] <alexanderW> How many clip-art items? [19:09] however, let's agree on a) how much clipart we want, b) what kind of clipart [19:09] alexanderW: will discuss this with markus (or maybe you could write a mail yourself) [19:09] b) photographic or vector, or a combination? what topics? [19:10] <alexanderW> vector only [19:10] I'd go for all vector myself, to be sure that the picture works everywhere [19:10] at every size [19:10] b) i think we should try to find categories that are useful. i would like to see animals, transportation devices, a few people and some figurative images [19:10] should they all have a similar style? [19:10] <alexanderW> now that we have AOO's svg implementation :) [19:11] alright [19:11] all SVG, then [19:11] and various topics [19:11] should they have similar styles? [19:11] all svg, i dont think openclipart offers anything else [19:11] i think every icon in the same category should be comparable in style [19:12] i dont think we need the same style for all categories [19:12] also, be sure to use CC-0 'd icons [19:12] alright [19:12] that will narrow the scope quite a bit [19:12] not quite, because oc.com is CC-0 by default [19:13] (but if you think about using eg. thenounproject too, then yes, that narrows the scope there) [19:13] ok [19:14] there is a bug... [19:14] it'd be good if we could integrate with openclipart.org [19:14] so that people could download more clipart if they'd like [19:14] astron247: yes? [19:14] sure, wont happen now [19:14] ill cc you on that [19:14] sorry for the cliffhanger [19:14] alright :) [19:15] are we thinking about using AOO's gallery? [19:15] or, mirek, can i assign you? [19:15] it's more usable than the current one, because it's a sidebar [19:15] mirek2: i think the consensus is no, becuase it is a bit ugly [19:15] astron247: assign me? [19:15] in the bug [19:16] could you show me the bug first? [19:16] just so I know what I'm signing up for [19:16] yes- https://bugs.freedesktop.org/show_bug.cgi?id=57062 [19:16] well, id edit the tile to not include templates [19:17] well, the bug is about refreshing our current selecting [19:17] title edited [19:18] which doesn't actually contain any clipart [19:18] but it should [19:18] just some bullets, some backgrounds, some sounds [19:18] and the gifs in there are really no use [19:18] <alexanderW> Gifs are awesome [19:18] so we'll remove all the current categories? [19:18] :) [19:18] <alexanderW> :) [19:18] well, you could keep the sounds, presumably [19:19] I know that AOO's gallery looks a bit ugly, but our current gallery is both ugly and barely usable [19:19] since it takes up a lot of screen space [19:20] are we sure that we don't want to use it instead? [19:20] sorry, i thought you were talking about aoo's gallery contents... [19:20] or perhaps we could just make it a simple dialog [19:21] which would at least be easier to look through [19:21] <alexanderW> for 4.0? [19:21] if it is about code... then (sorry, if i am not well informed) i dont know if thats opensource yet [19:21] alright [19:21] so we'll just stick to adding clipart and removing the other categories except sounds [19:22] ibm is apparently taking their sweet time open sourcing symphony – we have some code, but it still has proprietary headers [19:22] I've heard [19:22] (ie we cant use it and apache cant either [19:22] ) [19:22] but we have their SVG implementation now? [19:23] <alexanderW> yes [19:23] somehow. youd need to ask michael for the details. but the svg implementation was written specifically for aoo, so it is al2 already [19:23] oh, ok [19:23] <alexanderW> I saw it on cgit and the original developer wrote a post about the inclusion [19:24] yes [19:24] in any case, while we now have fully native svg, its probably quite a bit worse than rsvg. [19:25] (but i cant say where we use that implementation right now anyway...) [19:25] <alexanderW> I thought it was superior? [19:25] <alexanderW> there were some demo svgimported in LibO and AOO [19:26] <alexanderW> *demo-svgs [19:27] can you give me a link for that? [19:27] <alexanderW> I'll see [19:27] (my take was that its superior only in that it is native, ie, you can edit svgs in draw without importing them or so.) [19:28] <alexanderW> http://eric.bachard.org/news/index.php?post/2011/12/03/In-progress-:-native-support-of-the-SVG-graphic-format-in-Apache-OpenOffice.org [19:31] hm, that doesnt really compare it ot libo [19:32] ok. finish for today? [19:32] yes, I think so [19:32] should I put up the log? [19:33] sure [19:33] <alexanderW> please [19:33] youll assign yourself to the clipart bug? [19:33] <alexanderW> Have a nice weekend, everyone [19:33] thanks, you too [19:34] yes, sure [19:34] ok. bye then