Design/Meetings/2013-06-29

    From The Document Foundation Wiki

    Attendees

    • astron
    • aurelien_n
    • elixir
    • issa
    • mipmap
    • mirek2

    Topics

    • Style management
      • Style pop-over
    • Fonts
    • Default template
    • Color picker
    • Symbolic icons: Wrench shape

    Tasks

    aurelien

    • Try to hack on style menus
    • Tweak the scope of the style pop-over whiteboard

    mirek2

    • Make a style pop-over whiteboard

    Log

    [16:01] <mirek2> hi everyone
    [16:02] <@mipmap_> hello
    [16:02] <aurelien_n> hi
    [16:03] <mirek2> aurelien_n: I'm wondering -- how much work are you willing to do on styles?
    [16:03] <mirek2> (some of the wiki proposals are quite ambitious)
    [16:04] <aurelien_n> tough question, especially as I'm really new in this huge codebase :)
    [16:04] <aurelien_n> but if I can get some progress and people like it, I'd probably be motivated!
    [16:04] <@mipmap_> :)
    [16:05] <mirek2> sounds good :)
    [16:05] <aurelien_n> yes, I mostly wanted to make a list of things as I dream them to be, then the plan is to start with easy stuff and work on it step by steps
    [16:06] <@mipmap_> Styles is a very large area, it can be broken down into smaller parts
    [16:06] <mirek2> it'd be good if you could pick something in particular to work on (e.g. the Style sidebar), so that designing could focus on that
    [16:06] <aurelien_n> for now, I also want to feedback from real designers, to know if the direction seems good, to tweak some parts and get an idea of what can be done easilly and what will require more work
    [16:07] <aurelien_n> I think a simple toolbar would be a good start (at least adding a "character styles selection button"). I guess it is easy and does not require that mush design work for a first step
    [16:07] <@mipmap_> I would like to separate the style tools from the formatting tools in the toolbar
    [16:08] <mirek2> so, my opinion:
    [16:08] <aurelien_n> but the sidebar has a high priority, starting with quick buttons on bottom
    [16:08] <mirek2> I wouldn't have a separate Style toolbar
    [16:09] <aurelien_n> why not?
    [16:09] <@mipmap_> Combining hard formatting with styles invites into mixing them
    [16:09] <mirek2> rather, it'd be better to make styles more usable and approachable in the current formatting toolbar
    [16:10] <@mipmap_> https://wiki.documentfoundation.org/images/8/85/New_formatting_toolbar_panel.png
    [16:10] <mirek2> mipmap_: in some cases, creating a special style is needless
    [16:10] <@mipmap_> true, but its also inviting into breaking the styles you have created
    [16:10] <aurelien_n> I imagine that once the buttons exist, putting them in the same toolbar or in a new one is the easy part. When working on long documents, I would want to hide all manual formatting stuff
    [16:12] <@mipmap_> yes
    [16:12] <mirek2> mipmap_: on the other hand, many people create/tweak styles by first hard formatting, then choosing "tweak style based on selection"
    [16:12] <@mipmap_> hm, yes that is true
    [16:13] <aurelien_n> but you are right: going for styles only would be a very "bold" move... And only make sense if we make it really easy to create a new style.
    [16:13] <aurelien_n> that's also why I proposed a separate toolbar: to make it easy to be in "manual formatting" or in "style formatting" modes by changing the toolbar
    [16:13] <@mipmap_> I usually create styles based on hard formatting, it's more efficient then using the window
    [16:14] <mirek2> I think the easiest way to create/edit styles is by hard-formatting first
    [16:14] <mirek2> I see several downsides to a separate toolbar:
    [16:14] <mirek2> * it's not easily discoverable
    [16:14] <@mipmap_> Having only the paragraph style in the dropdown is not enough tough.
    [16:15] <mirek2> I agree fully
    [16:15] <mirek2> IMO, it'd be best to have tabs in the style picker
    [16:15] <mirek2> for characer, paragraph, and list styles
    [16:16] <@mipmap_> IMO, i would like to have styles in toolbar dropdowns, which can be added to it from the side panel
    [16:16] <aurelien_n> by style picker you mean the existing sidebar?
    [16:16] <mirek2> no, the style dropdown
    [16:17] <aurelien_n> why not having several dropdowns for styles?
    [16:17] <aurelien_n> at least paragraph and character styles need to be available directly, without switching tabs
    [16:17] <mirek2> for one thing, they could be really hard to tell apart
    [16:17] <aurelien_n> true, this annoys me as well /:
    [16:18] <@mipmap_> is it possible to create dropdown icons like for color (text color, background color, text background)
    [16:18] <@mipmap_> Instead of having textbox dropdowns
    [16:18] <mirek2> I did originally suggest to have two: http://clickortap.files.wordpress.com/2011/09/overflow.png
    [16:19] <mirek2> and I differentiated them by color and location
    [16:19] <aurelien_n> icons will be hard for this: not very informative
    [16:19] <@mipmap_> hm
    [16:19] == astron247 [~frootzowr@dslb-088-072-048-170.pools.arcor-ip.net] has joined #libreoffice-design
    [16:19] <mirek2> but people kept asking why there were 2
    [16:20] <@mipmap_> Can a Icon be included into the listbox element? as a static guide of what the listbox contains?
    [16:20] <aurelien_n> it could mix an icon and the dropdown
    [16:20] <mirek2> astron247: log: http://piratepad.net/qJMlPC3ZlC
    [16:20] <astron247> hi & thanks!
    [16:21] <mirek2> aurelien_n: I also think it's better to have styles in the same place so that you would have one place to target
    [16:22] <mirek2> if styles are always on the very left, your muscle memory learns to target it
    [16:22] <aurelien_n> you mean that tabs allow to keep it all together?
    [16:22] <@mipmap_> I would like to keep the flanks clean
    [16:23] <@mipmap_> leave them for comments and such
    [16:23] <mirek2> aurelien_n: tabs would allow you to have a single picker, yes
    [16:23] <mirek2> perhaps there might even be a way to reuse code from the sidebar
    [16:24] <mirek2> as that uses tabs as well
    [16:24] <aurelien_n> I have two problems with the tabs: as I said I would not be so happy to have to change tabs for paragraph and character tabs, I want them to be visible at all time. Then you still need some space for the tabs themself, where would you put them?
    [16:24] <mirek2> at the top of the pop-over
    [16:25] <aurelien_n> the buttons to select the type of styles in the sidebar are really small, it is useless without the tooltips IMHO
    [16:25] <mirek2> I agree
    [16:25] <aurelien_n> using larger buttons makes it impossible to put them on top
    [16:25] <mirek2> that needs work, imho
    [16:26] <mirek2> aurelien_n: why?
    [16:27] <mirek2> anyway, it'd be best to stop the conversation and create a separate whiteboard for the pop-over
    [16:27] <aurelien_n> if we are speaking of a toolbar widget, I don't see how you can have buttons of decent side on top of the widget itself, they would have to be on the side
    [16:28] <@mipmap_> I guess its out of scope, but what about having a separate window for style management? https://wiki.documentfoundation.org/images/4/42/Format_window.png
    [16:28] <mirek2> I'm speaking of a button widget inside a popover
    [16:28] <aurelien_n> OK, that would be possible indeed
    [16:29] <mirek2> before we get carried away with ideas, let's see what we should design first
    [16:29] <@mipmap_> ok :)
    [16:29] <aurelien_n> but then, why not list both in two separate columns to avoid selecting the tab each time?
    [16:29] <mirek2> interesting idea...
    [16:30] <aurelien_n> it would be a bit heavy I guess but it could work
    [16:30] <mirek2> what about allowing scrolling between tabs
    [16:31] <mirek2> i.e. horizontally scrolling switches the tab
    [16:31] <mirek2> (similar to Android tab behavior)
    [16:31] <aurelien_n> still a bit heavy for things you use often
    [16:32] <mirek2> should I start a style pop-over whiteboard?
    [16:32] <aurelien_n> anyway, on my mockup I have a more complex widget for the character style: commin styles have direct buttons (like bold, italic currently) and a dropdown allows to select others
    [16:32] <aurelien_n> single click for many cases and visually different from the paragraph style selector
    [16:33] <aurelien_n> it sounds like there is a need for more discussion for a good solution, thus yes
    [16:34] <mirek2> or perhaps you could start it and add the scope based on what you feel like you could do?
    [16:35] <mirek2> there's a template at https://wiki.documentfoundation.org/WikiAction/edit/Design/Whiteboards/Whiteboard_Template
    [16:35] <aurelien_n> a separate wiki page?
    [16:36] <mirek2> https://wiki.documentfoundation.org/WikiAction/edit/Design/Whiteboards/Style%20Pop-over
    [16:37] <aurelien_n> I would really like a second dropdown as a short term goal, to see how it feels and discover the code
    [16:37] <mirek2> (if you don't feel comfortable creating it, I could create it and you could then add the scope)
    [16:37] <aurelien_n> then, I'm fine with saying that this would not be accepted and that we work on a better design
    [16:37] <aurelien_n> good for me if you create it first
    [16:37] <mirek2> aurelien_n: that could be within the scope
    [16:37] <mirek2> ok
    [16:39] <aurelien_n> you want to fill this page now, or to discuss now, then we fill it for the next meeting and refine?
    [16:39] <mirek2> let's just discuss
    [16:39] <mirek2> about your proposal:
    [16:40] <aurelien_n> ok, so the options are:
    [16:40] <@mipmap_> what other topics do we have? color picker?
    [16:40] <aurelien_n> * separate dropdowns
    [16:40] <aurelien_n> * tabs in the dropdown
    [16:40] <aurelien_n> * big dropdown with columns
    [16:40] <@mipmap_> * small icons with dropdowns like color pickers
    [16:41] <mirek2> we'll see what ideas the proposals offer...
    [16:41] <aurelien_n> we can list several options there for now and decide what seems better/more realistic afterwards
    [16:42] <@mipmap_> yep
    [16:42] <mirek2> sounds good
    [16:42] <mirek2> can I comment on your proposal a bit?
    [16:42] <aurelien_n> sure
    [16:42] <mirek2> I don't quite see the advatage of strong/emphasis/underline buttons as opposed to hard formatting buttons
    [16:43] <mirek2> those basically offer the same functionality, only through find and replace
    [16:44] <aurelien_n> they would be "common" styles, using this makes it much easier to change the look of all emphasized text at once, which is important for long documents
    [16:44] <@mipmap_> But is that not a character style?
    [16:44] <mirek2> you can do that with find and replace, though
    [16:44] <mirek2> if all emphasized text is bold
    [16:45] <aurelien_n> yes, but reusable character styles, instead of "local" character styles which are created when you use the bold/italic buttons
    [16:45] <aurelien_n> but not all bold text is emphasized
    [16:45] <mirek2> and if emphasized text isn't bold, the icons could be misleading
    [16:45] <@mipmap_> I think these formatting rules should be applied the same way as paragraphs, for consistency
    [16:45] <aurelien_n> and I did not know that you could find bold text/change its style for a full document quickly and easily
    [16:46] <aurelien_n> yeah, ideally, the icons would reflect the look of the style
    [16:46] <mirek2> you can, in the find and replace dialog
    [16:47] <mirek2> aurelien_n: sounds good
    [16:47] <mirek2> though there might be a size issue
    [16:47] <aurelien_n> indeed find and replace seems to do a lot more than I ever used... but it is much less clean/easy than using styles!
    [16:47] <mirek2> definiely
    [16:48] <@mipmap_> i agree
    [16:48] <mirek2> a while ago, I had this idea of pinning styles
    [16:48] <aurelien_n> what do you mean by pinning?
    [16:48] <mirek2> where you could pin any style to the toolbar
    [16:48] <@mipmap_> when you list styles and colors there should only be a small selection of the possible ones (the most used ones), otherwise it becomes clumpsy
    [16:48] <mirek2> and it would show up as a toolbar icon
    [16:49] <@mipmap_> like a generic style palette
    [16:49] <aurelien_n> that would be great indead!
    [16:49] <@mipmap_> I guess you could create a unified style dropdown where every row has an icon - indicating what kind of style it will represent
    [16:50] <mirek2> I think it'd be better to narrow down the style list
    [16:50] <mirek2> and be more contextual
    [16:50] <aurelien_n> That's a bit what I wanted when combining a set of buttons and a dropdown for the character styles: have a few styles available directly. allowing to customize it would be fantastic for a later stage
    [16:50] <@mipmap_> drag and drop would be fantastic :)
    [16:51] <aurelien_n> mipmap_: you mean mixing different types of styles in the same list? I'm affraid it would be confusing
    [16:51] <@mipmap_> yes, and yes you are probably right
    [16:52] <aurelien_n> yeah, it would be cool, even if a bit far from what I feel confident planning now!
    [16:52] <mirek2> in terms of contextuality, LibO could:
    [16:53] <aurelien_n> putting the n most often select styles (with n configurable somehow) sounds like a good idea
    [16:53] <@mipmap_> yep
    [16:53] <mirek2> * e.g. only show the Caption style if there is any caption
    [16:54] <mirek2> * show Heading X only if Heading X-1 is already used
    [16:54] <mirek2> etc.
    [16:54] <aurelien_n> sounds sane
    [16:55] <@mipmap_> having too fluid dynamic contents in the dropdowns could make it harder to use since its always a little different
    [16:55] <mirek2> Google Docs does that thing with the headings
    [16:55] <@mipmap_> you might also end up in a chicken or egg problem - how do I apply a style when I don't have it yet
    [16:55] <@mipmap_> ok
    [16:55] <mirek2> it's not hard at all
    [16:56] <aurelien_n> it could have a submenu for "all other styles"
    [16:56] <mirek2> mipmap_: the answer being that you shouldn't apply Heading 3 if you don't have Heading 2 applied
    [16:57] <aurelien_n> I think the list should be kept small, but that all styles in use must be there, as well as some default one to get started
    [16:57] <@mipmap_> ok
    [16:57] <@mipmap_> now I understand :) that seems more reasonable
    [16:57] <mirek2> aurelien_n: definitely
    [16:57] <aurelien_n> the heading filter trick is a nice one though
    [16:57] <aurelien_n> maybe always put heading 1 and 2 anyway
    [16:57] <mirek2> yup
    [16:58] <mirek2> that's exactly what Docs does, btw
    [16:58] <aurelien_n> I was considering "heading 1, heading 2, heading 3, other headings in submenu"
    [16:58] <mirek2> as for the default ones, if you look at the current selection, most of them are contextual
    [16:59] <mirek2> aurelien_n: I wouldn't like them in a submenu
    [16:59] <aurelien_n> ??
    [16:59] <@mipmap_> my suggestion about this is: add as few as possible (2) and then if people complain add more until you get no complaints
    [16:59] <aurelien_n> the filter done by gdocs sounds better
    [17:00] == elixir_ [~elixir@14.139.122.114] has quit [Ping timeout: 252 seconds]
    [17:00] <@mipmap_> what do you mean by contextual?
    [17:00] <mirek2> based on context
    [17:00] <aurelien_n> for example?
    [17:00] <mirek2> e.g. if there's no footer, the Footer style is hidden
    [17:00] <@mipmap_> well I know what contextual means, but in this case
    [17:01] <@mipmap_> ok i get it :)
    [17:01] <mirek2> and the style should show up only when you edit the footer
    [17:01] <@mipmap_> The rules for deciding this might get quite complicatied though
    [17:01] <aurelien_n> but even if we have a table of content and an index, we don't want to use their styles in the list for the main text
    [17:02] <aurelien_n> yes, exactly
    [17:02] <@mipmap_> What if I would like to fine tune a style?
    [17:02] <@mipmap_> I would then open it in the sidepanel?
    [17:02] <aurelien_n> you go to the sidebar for this I would say
    [17:02] <@mipmap_> ok
    [17:02] <mirek2> you can do that when you have something that has the style selected or through the sidebar
    [17:03] <mirek2> another thing that Docs has and is awesome is that each style has an associated menu
    [17:03] <@mipmap_> Perhaps there should be a "Store in style" button somewhere which overwrites the old style
    [17:03] <mirek2> http://clickortap.wordpress.com/2012/02/19/notice-google-docs-new-style-management/#jp-carousel-973
    [17:04] <@mipmap_> I think that would be too complex for a LO dropdown
    [17:04] <mirek2> mipmap_: you mean "Update style to match selection"?
    [17:04] <@mipmap_> but perhaps in the sidebar
    [17:04] <@mipmap_> yes
    [17:05] <aurelien_n> I clearly want something similar in the sidebar, not sure abot the dropdown
    [17:05] <mirek2> mipmap_: why do you think it'd be too complex?
    [17:05] <mirek2> aurelien_n: it makes quick style editing much easier
    [17:05] <mirek2> try it in Docs
    [17:05] <@mipmap_> I have not seen such complex dropdowns anywhere else in the suit, so I just thought it would be inconsistent. It would fit in the Menu bar on top with File, Edit etc
    [17:06] <aurelien_n> it is convenient but a bit weird, and I never used it
    [17:07] <aurelien_n> but it is good to keep it in mind
    [17:07] <mirek2> it's already been nominated for an EasyHack
    [17:08] <aurelien_n> yes, I've seen your link to the bug report
    [17:08] <@mipmap_> oh well :) then we will see if someone takes the bait
    [17:08] <mirek2> it would make style editing much easier
    [17:09] <@mipmap_> I have another comment about a tiny icon issue ive had
    [17:09] <aurelien_n> only if you still use the text formatting toolbar, which I want to avoid :D
    [17:09] == elixir_ [~elixir@14.139.122.114] has joined #libreoffice-design
    [17:09] <mirek2> having the sidebar always open isn't an option for everyone
    [17:10] <mirek2> it's not pleasant on small screens and doesn't work well with 2 windows side by side
    [17:10] <aurelien_n> for now it is the only way to work with styles at all... hence the new buttons in the toolbar
    [17:10] <@mipmap_> you have these icons (#) next to each other like this: #  #  #  #  #. Sometimes you have dropdown arrows like this: #  # v #  # v #. My issue is that these dropdown arrows are aligned centered. It can be very hard to see what icon they belong to. I would much rather have a setup like this: #v #  #  #v #.
    [17:11] <aurelien_n> the aim is to go to it only to edit styles, instead of going to it everytime yu want to apply one
    [17:11] <@mipmap_> mirek2 and its horrible with impress :) there you already have 2 sidebars by default...
    [17:11] <aurelien_n> this looks like a toolkit issue
    [17:11] <@mipmap_> ok
    [17:12] <aurelien_n> impress and styles is another can of worm, that I'd like to open later on, if it gets better wth writer
    [17:12] <@mipmap_> hehe
    [17:12] <mirek2> aurelien_n: quick editing is important too, imho
    [17:12] <aurelien_n> my main problem is that impress has NO character styles at all
    [17:13] <@mipmap_> Im just thinking about creating a generic solution which would work on all parts of the suits, which is why I made the style-window and a longer toolbar with all the styles in dropdowns.
    [17:13] <aurelien_n> by quickedit you mean the buttons in the sidebar?
    [17:13] <mirek2> it doesn't even have paragraph styles
    [17:13] <@mipmap_> bold, italic etc
    [17:13] <aurelien_n> it has some, but very restricted
    [17:14] <aurelien_n> so, what do you think about including some editing features to the style sidebar?
    [17:14] <mirek2> aurelien_n: I meant that editing should be accessible through the pop-over as well
    [17:14] <aurelien_n> I'm affraid it would be hard on small screens
    [17:14] <aurelien_n> mirek2: how would you do that?
    [17:14] <mirek2> aurelien_n: through the menu I mentioned
    [17:15] <mirek2> with an "Update style to match selection" entry
    [17:15] <mirek2> and ideally an accompanying shortcut
    [17:15] <aurelien_n> I'm still not sold to putting that as sidebuttons in a menu
    [17:16] <mirek2> try it in Docs -- it's a really quick and simple way to edit a style
    [17:16] <aurelien_n> do we want to update any random style like this or only the current one?
    [17:16] <mirek2> any style
    [17:17] <mirek2> or even allow the user to create a new style based on the selection
    [17:17] <aurelien_n> then to edit the current style, you have to find it back in the list, go to the sidebutton and select "update" in the submenu
    [17:17] <mirek2> yup
    [17:18] <aurelien_n> what about having this feature directly available for the current style instead?
    [17:18] <aurelien_n> i.e. avoid the need to search the style first.
    [17:19] <aurelien_n> and force it to apply to the current style, so that we know that we can destroy the hand formatting at the same time, otherwise it introduce a lot of trash
    [17:19] <mirek2> sometimes I first hard-code the style, then apply it
    [17:20] <mirek2> so updating the current style (Default, in my case), wouldn't work for me
    [17:20] <aurelien_n> when you do this in one place, then do it in another place with different settings don't you keep the first place with the old formatting?
    [17:21] <aurelien_n> I really want a way to completely eliminate hard formatting to avoid crap falling on me days later...
    [17:21] <mirek2> so, my workflow:
    [17:21] <mirek2> * apply hard formatting
    [17:22] == elixir_ [~elixir@14.139.122.114] has quit [Read error: Connection reset by peer]
    [17:22] <mirek2> * choose "Update style to match selection"
    [17:22] == elixir_ [~elixir@14.139.122.114] has joined #libreoffice-design
    [17:22] <mirek2> on a style I want to use that formatting
    [17:23] <aurelien_n> yes, I understand this, but I wonder if you leave some hard formatting behind you when doing this
    [17:23] <mirek2> and I guess that, ideally, the selection's style should then switch to that style as well
    [17:23] <mirek2> hm, let me see what Docs does...
    [17:24] <aurelien_n> I can't get it to do what I was affraid of
    [17:25] <mirek2> it looks like it works like I just described it should
    [17:25] <aurelien_n> it does seem to remove hard formatting when doing this yes
    [17:25] <@mipmap_> This way of working with styles does not cover inheritance which is really importantimho
    [17:25] <mirek2> it applies the style when you click "Update style to match selection" and gets rid of the hard formatting
    [17:26] <mirek2> aurelien_n: yes, it should remove the hard formatting
    [17:26] <mirek2> mipmap_: you can specify inheritance in the sidebar
    [17:26] <mirek2> it's more of an advanced feature, though
    [17:27] <@mipmap_> maybe
    [17:27] <mirek2> I've only used it with headings
    [17:27] <aurelien_n> I had in mind another workflow: formatting buttons always update the current style, and an easy way to create a new style. It is a bit extreme and I guess it would only work for me and some crazy people...
    [17:27] <mirek2> that wouldn't work well
    [17:27] <@mipmap_> I've tried to use it in captions and notes too, but my version of LO takes about 1 min to open the style formatting windows :(
    [17:28] <aurelien_n> why not?
    [17:28] <mirek2> as bolding some text would make the default style bold
    [17:28] <@mipmap_> hehe yeah it makes it very easy to break a style
    [17:28] <aurelien_n> yeah, but you see the result right away, and create a new style instead
    [17:29] <@mipmap_> from a programming point of view, how would you determine which style the "bold" would affect?
    [17:29] <aurelien_n> in this scenario, the formatting options could remain hidden most of the time and be clearly associated to the current style
    [17:29] <@mipmap_> the header? the first page? the character style
    [17:29] <mirek2> mipmap_: yup, that's another reason to have more functionality in the pop-over
    [17:29] <aurelien_n> always to the current style
    [17:29] <mirek2> aurelien_n: it wouldn't suit my workflow
    [17:30] <aurelien_n> but as I said: it is an extreme workflow, which would be fantastic for me, and that most users would hate!
    [17:30] <@mipmap_> how about a style highlighter? Press a style and then press this button and all areas which are covered by this style would be highlighted somehow
    [17:30] <mirek2> aurelien_n: yup
    [17:30] <aurelien_n> mipmap_: I'd love that, but I'm affraid it requires a lot of changes, not going there now
    [17:31] <@mipmap_> aurelien_n a shortcut key could be good for that
    [17:31] == issa [5b9399be@gateway/web/freenode/ip.91.147.153.190] has joined #libreoffice-design
    [17:31] <@mipmap_> ok
    [17:31] <mirek2> mipmap_: find and replace?
    [17:31] <@mipmap_> yeah something like that, but in a button-click
    [17:32] <aurelien_n> anyway, if well implemented and done for character styles as well as paragraph ones, the gdoc idea would work
    [17:33] <aurelien_n> and it is probably more realistic in the short term, so, let's go for it now (but I'll keep dreaming of a world without any hard formatting)
    [17:33] <mirek2> another idea I had was using a button for font selection
    [17:33] <mirek2> and showing the font name in the status bar
    [17:33] <mirek2> thus leaving more room in the toolbar and giving more emphasis to styles
    [17:34] <mirek2> aurelien_n: hurray! :)
    [17:34] <aurelien_n> I guess it depends a lot on the kind of document you use, but I would kill for a text editor where I don't get bothered by such details except during the tiny amount of time where I want to edit the styles, so please no font name in the statusbar
    [17:35] <aurelien_n> reducing the font selector makes sense anyway
    [17:35] <issa> hello
    [17:35] <@mipmap_> yes
    [17:36] <@mipmap_> there are too many fonts in there!
    [17:36] <mirek2> issa: hi
    [17:36] <@mipmap_> hi
    [17:36] <mirek2> discussing styles
    [17:36] <aurelien_n> hello issa
    [17:36] <mirek2> mipmap_: yup
    [17:36] <issa> can I see the log so far?
    [17:36] <mirek2> another problem to tackle
    [17:36] <mirek2> http://piratepad.net/qJMlPC3ZlC
    [17:37] <mirek2> btw, Google Docs also solves the too-many-fonts problem
    [17:37] <@mipmap_> I think a sans-serif, a serif, a monospace and a fantasy would be enough
    [17:37] <@mipmap_> (5 fonts all in all)
    [17:37] <aurelien_n> yes, but it is a bit extreme!
    [17:38] <@mipmap_> oups make it four
    [17:38] <aurelien_n> some people are CRAZY about font choice
    [17:38] <mirek2> Fantasy???
    [17:38] <mirek2> hand-writing, maybe
    [17:38] <@mipmap_> its a class of fonts I think... at least in swedish
    [17:38] <@mipmap_> yeah, scripts, logo text and other cool things
    [17:39] <mirek2> you mean dingbat fonts?
    [17:39] <@mipmap_> should only be used in headers, but people somehow insist in using them in bread text
    [17:39] <aurelien_n> I fully agree that a much smaller selection of fonts which are always there and appear on top would be great
    [17:39] <mirek2> mipmap_: display fonts?
    [17:40] <mirek2> I think themes will go a long way
    [17:40] <@mipmap_> How about having a two part dropdown, you have one part with the 4 default ones and then "MOAR fonts" in the bottom which expands the list
    [17:40] <@mipmap_> (directly no window opening)
    [17:40] <aurelien_n> showing the selected few, allowing to add new ones and then listing them as well would be great indeed
    [17:40] <mirek2> I'd prefer to let the user add/remove fonts
    [17:40] <@mipmap_> yeah, that would be better
    [17:40] <mirek2> that way, you only see the fonts you use
    [17:41] <aurelien_n> but you can not do that without starting some kind of flamewar about which fonts MUST absolutely be there by default I guess
    [17:41] <@mipmap_> yes, perhaps that would be a good overall concept - you only see the styles you use in the document
    [17:41] <mirek2> mipmap_: not only
    [17:42] <aurelien_n> as much as I would love it, I won't work on it though
    [17:42] <mirek2> that would be a paradox
    [17:42] <mirek2> aurelien_n: I get that -- it's a lot of work
    [17:42] <mirek2> hopefully someone will show up come next GSoC
    [17:42] <issa> please keep in mind people who use multiple languages with different fonts for each
    [17:43] <@mipmap_> true true
    [17:43] <mirek2> right
    [17:43] <mirek2> anyway...
    [17:44] <mirek2> aurelien_n: you'll try working on the style menu?
    [17:44] <aurelien_n> I can try this, I'l probably ping people for more code pointers though
    [17:44] <mirek2> ok
    [17:45] <aurelien_n> and a new button to select character styles, this is really my main motivation!
    [17:45] <@mipmap_> sounds good
    [17:45] <@mipmap_> yes, that alone would be a great feat
    [17:45] <mirek2> aurelien_n: what kind of button?
    [17:45] <mirek2> a pop-over?
    [17:46] <aurelien_n> for starter, as it could share code with the paragraph selector. But I agree that we need something better, or at leasta  clear visual difference
    [17:46] <mirek2> I'll put up a style pop-over whiteboard, you'll tweak the scope, and we'll talk about it next week
    [17:47] <@mipmap_> yep
    [17:47] <aurelien_n> perfect for me
    [17:47] <mirek2> great
    [17:47] <@mipmap_> I will think long and hard about those dropdowns since I really like that approach :)
    [17:47] <mirek2> :)
    [17:47] <mirek2> ok to move to another topic?
    [17:47] <aurelien_n> yes
    [17:48] <@mipmap_> yes
    [17:48] <@mipmap_> color pickers!
    [17:48] <mirek2> astron247: could you update us on the esc call?
    [17:49] <astron247> uh...
    [17:49] <astron247> actually, i didnt talk about very much
    [17:50] <mirek2> ok
    [17:50] <astron247> hum... the new ux-advise component is now in bugzilla (actually spelled as ux-advice)
    [17:50] <@mipmap_> what is an esc call?
    [17:51] <mirek2> it's a weekly call among the members of the Engineering steering committee
    [17:51] <astron247> and soem who arent members :)
    [17:51] <astron247> ^soem^some
    [17:51] <mirek2> right
    [17:51] <mirek2> astron is the design team representative there
    [17:51] <@mipmap_> ok
    [17:52] <mirek2> astron247: ok
    [17:52] <mirek2> is that all the news for the week?
    [17:52] <astron247> i thin kso
    [17:52] <astron247> if i should discuss anything from here – tell me
    [17:52] <mirek2> ok
    [17:52] <@mipmap_> what about default document?
    [17:53] <@mipmap_> default style
    [17:53] <astron247> uhm... ahmed wanted to do that right?
    [17:53] <mirek2> https://wiki.documentfoundation.org/Design/Whiteboards/Default_Template
    [17:53] <mirek2> right
    [17:53] <@mipmap_> ok, I'll take it with him then
    [17:54] <mirek2> I suggested to list the typography rules the template should follow first
    [17:54] <mirek2> and it got stuck on that
    [17:54] <@mipmap_> I made some contributions in that area today
    [17:55] <@mipmap_> however - is the deafault template targeting screens or printers? this is important since a default for printers would probably use serifs in bread text while a default for screens would use sans-serifs
    [17:55] <mirek2> could you put your suggestions under a proposal category?
    [17:56] <@mipmap_> it's a bit of a philosophical question
    [17:56] <@mipmap_> sure
    [17:56] <mirek2> (for discussion, we use mailing lists)
    [17:56] <@mipmap_> ok
    [17:57] <mirek2> mipmap_: would be great if you could provide a source for the rules you list
    [17:57] <mirek2> I've never heard of a fantasy font category
    [17:57] <@mipmap_> hehe graphical arts teacher in senior high :)
    [17:58] <mirek2> perhaps display fonts are what you mean?
    [17:58] <@mipmap_> yeah probably
    [17:58] <mirek2> also, serifs and sans-serifs can be used in both print and on-screen
    [17:59] <mirek2> I don't see any reason why one should be preffered for screens
    [17:59] <mirek2> the text will be just as readable on a screen as on paper
    [17:59] <aurelien_n> many people hate serifs on screens, while they like them on paper
    [17:59] <astron247> fantasy fonts used to mean "obscure cursive font that looks terrible" to me
    [17:59] <mirek2> :)
    [18:00] <@mipmap_> from what I learned serifs have feet to make them blend into each other more, while sans serifs are better for screens since they have less distractions
    [18:00] <astron247> right
    [18:00] <astron247> but: the liberation fonts are quite screen optimised
    [18:00] <@mipmap_> these feets does not render well on older screens, they look very blurred
    [18:00] <mirek2> some argue that serifs make text more readable
    [18:00] <astron247> (more so than times new roman, anyway)
    [18:00] <@mipmap_> yes but not on the screen
    [18:00] <aurelien_n> sans serif may be a better choice for a neutral default, but no matter which you choose, some people will not be happy with it!
    [18:01] <astron247> and the other thing is that many new screens are actually quite high-resolution
    [18:01] <mirek2> mipmap_: that depends on the font
    [18:01] <@mipmap_> yeah that thats the only thing I think we can conclude :)
    [18:01] <aurelien_n> classical computer screens (especialy on most laptops) are really not high DPI
    [18:01] <astron247> yes
    [18:01] <@mipmap_> yeah, this was some ten years ago when screens were poor
    [18:01] <astron247> but there is a trend towards that even in that segment
    [18:02] <mirek2> I would stay with Liberation Serif for now
    [18:02] <@mipmap_> I'll look into the matter and write a small summary on the template page
    [18:02] <issa> I think serifs look great on the screen in larger sizes
    [18:02] <@mipmap_> yes
    [18:02] <mirek2> especially as I think Liberation Sans is quite ugly
    [18:02] <aurelien_n> I think it would make more sense to propose a small collection of default styles than a single one
    [18:02] <mirek2> and we can't use any other fonts
    [18:03] <aurelien_n> is liberation bundled with LibO?
    [18:03] <astron247> yes
    [18:03] <mirek2> aurelien_n: a collection of templates, you mean?
    [18:03] <aurelien_n> yes
    [18:03] <@mipmap_> I was also thinking about a reference document where all default styles are deifined
    [18:03] <@mipmap_> so you can see them in action
    [18:03] <issa> ;ldfghjkl;'.lkjhgfdsdfghbjnkml,;.'/
    [18:04] <issa> sorry!
    [18:04] <astron247> aurelien_n: we were told that we can only use liberation, so the number of differnt styles you can make with these fotns is quite low
    [18:04] <mirek2> mipmap_: that's what the default template is
    [18:04] <mirek2> though I'm not sure where it is located
    [18:05] <mirek2> astron247: do you know?
    [18:05] <aurelien_n> you can have with and without serif (it sounds a bit too much to have a template just for that but it could help)
    [18:05] <@mipmap_> um no, the default template is a document which has the styles defined, by reference document I mean a sample report with text in it so that you can see what it looks like
    [18:05] <aurelien_n> and with and without numbered headings
    [18:05] <mirek2> mipmap_: someone should create that :)
    [18:05] <mirek2> would you like to?
    [18:05] <@mipmap_> yeah, I'll dig into it
    [18:06] <issa> mirek2: ahmed did
    [18:06] <@mipmap_> seems like a small enough task
    [18:06] <@mipmap_> he is more into defining the template, not the test document
    [18:06] <mirek2> aurelien_n: that's really something the user should adjust for himself
    [18:06] <mirek2> with styles
    [18:06] <@mipmap_> i guess style-test-document is what I'm looking for
    [18:07] <mirek2> +1
    [18:07] <issa> mipmap_: yes, but he made a test document while working on that
    [18:07] <@mipmap_> aha
    [18:07] <@mipmap_> I'll send him an email then
    [18:08] <mirek2> it should be on the mailing list
    [18:08] <astron247> mirek2: sorry
    [18:08] <mirek2> http://nabble.documentfoundation.org/Default-LO-Style-td4061081.html
    [18:08] <@mipmap_> it is confirmed: fantasy is the swedish word for display font
    [18:08] <mirek2> astron247: for what?
    [18:09] <astron247> mirek2: not answering. what exactly is the question?
    [18:09] <mirek2> oh, that's not important
    [18:10] <mirek2> I was asking where the default template was
    [18:10] <mirek2> but that's not what mipmap_ wanted
    [18:10] <@mipmap_> no, I want a document with some foo text in it, decorated with foo images
    [18:11] <mirek2> right
    [18:11] <@mipmap_> my fear is that someone designs a super good looking header system, which looks like crap with the other features
    [18:11] <@mipmap_> using different fonts etc.
    [18:11] <mirek2> take https://wiki.documentfoundation.org/images/d/da/Serif_template.ott and improve upon it as you see fit
    [18:12] <astron247> anyway, the default template, afaik is hardcoded in a .cpp file somewhere , i think
    [18:12] <mirek2> oh, that's a pity
    [18:12] <@mipmap_> oh my
    [18:12] <astron247> but theres some mechanism to load other templates as default
    [18:13] <@mipmap_> ok
    [18:14] <@mipmap_> I'll work on this during the week
    [18:14] <@mipmap_> any other topics?
    [18:14] <mirek2> not from me
    [18:14] <@mipmap_> I have some comments about color pickers, but perhaps I can take that in the mailist
    [18:15] <mirek2> sure
    [18:15] <mirek2> or here
    [18:15] <@mipmap_> ok
    [18:15] <mirek2> whatever you prefer
    [18:15] <aurelien_n> I had another (quick) question which I forgot about styles
    [18:15] <mirek2> aurelien_n: go ahead
    [18:15] <@mipmap_> https://wiki.documentfoundation.org/User:Mipmap#Color_palette
    [18:16] <aurelien_n> the "clear formatting" command is annoying for me as it removes character styles
    [18:16] == astron247_ [~frootzowr@dslb-088-072-048-170.pools.arcor-ip.net] has joined #libreoffice-design
    [18:16] <@mipmap_> a couple of weeks ago I got suckered into color pickers. I was using GIMP and it was horrible. I decided to make a review of all the color pickers I could think of and wrote a 8 part blog post about that
    [18:17] <@mipmap_> my conclusions are, about the palette system;
    [18:17] <aurelien_n> Does it seem realistic to change its behaviour? or to have two commands, this one and a new one which only removes hard formatting ?
    [18:17] <@mipmap_> 1. the colors has to be organized into columns
    [18:17] <mirek2> hold on
    [18:17] == astron247 [~frootzowr@dslb-088-072-048-170.pools.arcor-ip.net] has quit [Ping timeout: 240 seconds]
    [18:17] == astron247 [~frootzowr@dslb-088-072-048-170.pools.arcor-ip.net] has joined #libreoffice-design
    [18:17] <mirek2> let's cover aurelien_n's question first
    [18:17] <@mipmap_> hupp, I'll shut up for a while :)
    [18:18] <aurelien_n> this has been reported as issue in OOo for years...
    [18:18] == astron247_ [~frootzowr@dslb-088-072-048-170.pools.arcor-ip.net] has left #libreoffice-design []
    [18:18] <mirek2> hm, that's a good one
    [18:19] <mirek2> my gut would say that it might be best to have one command
    [18:20] <@mipmap_> Perhaps remove that option from drop down and move it into the Format Menu, where it would rest under Clear Formatting> 1) Clear Page formatting, 2) Clear Paragraph formatting ...
    [18:20] <issa> we shouldn't change the current one's behavior, but maybe add a "reset style" button
    [18:20] <mirek2> on the other hand, if I copy some text over from another document and want all of it to use the default style, two buttons would probably be best
    [18:20] <aurelien_n> there is a "clear formatting" command in the format menu already
    [18:20] <@mipmap_> ok
    [18:21] <mirek2> issa: what would that solve?
    [18:21] <@mipmap_> either you offer the user to remove all formatting at once, or you have 4-5 buttons/options for each one separately
    [18:21] <aurelien_n> I want clean documents where everything is controlled by styles
    [18:22] <@mipmap_> you can't really have a button which says clear formatting and only affect some forms of formatting
    [18:22] <mirek2> so... I guess 2 buttons might be best
    [18:22] <aurelien_n> this command is the only way to get such a document without getting crazy, but if it destroys character styles it is useless for me!
    [18:22] <mirek2> I get it
    [18:22] <aurelien_n> yep, it is a bit tricky, so I understand the need for two separate commands
    [18:23] <mirek2> haw is styling handled in ODF?
    [18:23] <aurelien_n> So I'd like to add a method to clear only hard formatting, then we can decide wether we are happy with putting both in the format menu or if we want to reuse them in the toolbar as well...
    [18:23] <aurelien_n> everything is a style in ODF
    [18:23] <mirek2> is it similar to CSS?
    [18:24] <aurelien_n> excepot that some styles are "reusable" and some are purely local
    [18:24] <mirek2> ok
    [18:25] <aurelien_n> now "clear formatting" removes all character styles, wether they are local or reused
    [18:25] <@mipmap_> hm
    [18:25] <@mipmap_> that is a bit of a problem
    [18:25] <mirek2> right
    [18:25] <aurelien_n> I would like to add an option to clear local styles only
    [18:25] <@mipmap_> yes, that would be good
    [18:25] <@mipmap_> as a cleanup tool
    [18:25] <mirek2> perhaps you could have an advanced "clear formatting" dialog
    [18:26] <@mipmap_> is it possible from a programmin point of view?
    [18:26] <aurelien_n> ok, I'll ask for a pointer to the current code then and see if I can make the other one.
    [18:26] <mirek2> sounds good
    [18:26] <aurelien_n> it should be possible yes, not sure it is easy...
    [18:26] <@mipmap_> :)
    [18:26] <issa> why not make it like paste and paste special?
    [18:26] <@mipmap_> yeah, that would add consistency with calc
    [18:27] <aurelien_n> what do you mean?
    [18:27] <@mipmap_> in calc you can copy and paste, and paste special. pasting special can transform(flip) ignore formats, ignore equations etc.
    [18:28] <@mipmap_> So you would have a import-light in writer
    [18:28] <aurelien_n> writer also has a "paste special" menu (for unformatted text)
    [18:28] <@mipmap_> however, it will not make it less hard from a programming point of view
    [18:28] <@mipmap_> ok
    [18:28] <aurelien_n> but it is not only about pasted text
    [18:28] <aurelien_n> but also about cleaning up an existing document
    [18:29] <aurelien_n> anyway, I'll see if I can get it to work and come back to you to discuss where to put it
    [18:29] <mirek2> sounds good
    [18:30] <@mipmap_> ok
    [18:30] <@mipmap_> color pickers?
    [18:31] <mirek2> ok
    [18:31] <@mipmap_> ...so all in all, ive spent too much time thinking about this...
    [18:31] <@mipmap_> For palettes, you should organize the colors in columns, where the tiles are square and give them a small border. This is to prevent visual artifacts from occuring
    [18:32] <@mipmap_> "vibrations" and gray shadows
    [18:32] <@mipmap_> if you look at something like yahoo you can see gray dots everywhere
    [18:32] <@mipmap_> I made an example here https://wiki.documentfoundation.org/User:Mipmap#Color_palette
    [18:34] <@mipmap_> To indicate which color the user has picked, you should make it appear "more", not cover it with an icon. This is to keep the UI from interfering with the color. If you put two colors next to each other they will interfere, does not matter if it is another swatch or if it is a UI border
    [18:34] <mirek2> have you taken a look at our whiteboard, btw?
    [18:34] <mirek2> https://wiki.documentfoundation.org/Design/Whiteboards/Color_Picker
    [18:34] <@mipmap_> of course :)
    [18:34] <aurelien_n> this looks great. I really like the well ordered colors, but is it something that you want to maintain or just propose as example/default palette?
    [18:34] <@mipmap_> I tried but it wont accept my additions
    [18:34] <@mipmap_> :(
    [18:35] <@mipmap_> Then the color wheel/window/definer
    [18:35] <@mipmap_> the picked color should be displayed in a square, since squares are more harmonious then rectangles
    [18:35] <@mipmap_> you should have easy copy/paste areas for input of hex/rgb codes.
    [18:36] <@mipmap_> There are ... parameters in a rgb system: hue, whiteness and blackness. You cant have everything in the same window, it will look crazy
    [18:36] <@mipmap_> usually you put white/black/color in one window and then have hue in a slider
    [18:37] <mirek2> (we already have the picker, btw)
    [18:37] <mirek2> oh, you mean widget, not window
    [18:37] <@mipmap_> this is problematic since there are 8 hues, which works like "poles". black-white has only two poles which is much better in a slider
    [18:38] <@mipmap_> good luck moving your finger between red and yellow when these hues when the pixel area is perhaps 40, but there are 100s of colors in between...
    [18:38] <issa> I assumed the picked color's square was the before and after colors
    [18:38] <@mipmap_> so... color wheel or color window (square) I like wheels more since they are prettier :)
    [18:39] <issa> mipmap_: we could have three of them
    [18:39] <@mipmap_> The windows look very dark since black gets two corners while the colors and whiteness only gets one each :(
    [18:39] <@mipmap_> ok thats my thoughts
    [18:40] <@mipmap_> I have exluded the before color since it might interfere with the new one. This is a problematic part of this...
    [18:40] <@mipmap_> Sometimes you want to compare and sometimes you dont
    [18:40] <mirek2> well, we've discussed the picker a lot
    [18:41] <mirek2> (seriously, take a look at the IRC chat archives)
    [18:41] <@mipmap_> The best thing would be if the entire window would dissapear while editing, and displaying the edits applied directly
    [18:41] <@mipmap_> yeah i know
    [18:41] <@mipmap_> i read some of it
    [18:41] <@mipmap_> :)
    [18:41] <mirek2> and we can't reach consensus on a lot of things
    [18:41] <@mipmap_> oh well, these were my thoughts, now you know
    [18:42] <mirek2> so I would leave further designing to when we find a dev
    [18:42] <@mipmap_> yep
    [18:42] <mirek2> as (s)he'll settle the arguments for us
    [18:42] <@mipmap_> hehe
    [18:42] <aurelien_n> a naive question about this: are there any fuull time devs in LibO who can work on such things?
    [18:43] <mirek2> not really
    [18:43] <issa> no
    [18:43] <@mipmap_> I could make one using html5 technologies
    [18:43] <@mipmap_> but not c++
    [18:43] <aurelien_n> you mean no full time dev at all or none who work on pure UI stuff with designers?
    [18:44] <mirek2> there are tons of full-time devs
    [18:44] <mirek2> but they're busy with other stuff
    [18:44] <mirek2> and not interested in UI stuff
    [18:44] <@mipmap_> there are some ui related things going on tough: like porting all 500 windows into gtk3
    [18:45] <mirek2> not gtk+ 3
    [18:45] <aurelien_n> yeah, I saw this
    [18:45] <@mipmap_> ok
    [18:45] <mirek2> just Glade files
    [18:45] <aurelien_n> yep
    [18:45] <mirek2> the toolkit stays VCL
    [18:45] <aurelien_n> must be quite a work already...
    [18:46] <aurelien_n> but also a great opportunity to tweak the GUI!
    [18:46] <@mipmap_> mhm
    [18:46] <mirek2> yup
    [18:47] <mirek2> if you'd like to convert some dialogs, you're welcome to
    [18:47] <@mipmap_> I've taken some programming classes and done some app programming for android (game stuff) but I really don't know where to start in something like this...
    [18:47] <mirek2> though major changes should go through the mailing list
    [18:47] <mirek2> mipmap_: start with an EasyHack
    [18:48] <@mipmap_> but they are too hard for me :)
    [18:48] <@mipmap_> I would need help just setting up a dev. environment
    [18:48] <mirek2> https://wiki.documentfoundation.org/Development/Easy_Hacks
    [18:48] <aurelien_n> unfortunately I don't have much free time to spend on it...
    [18:49] <mirek2> you can always use the libreoffice-dev irc channel if you need help
    [18:49] <mirek2> it'd be great if you could attend the LibreOffice conference
    [18:49] <aurelien_n> yes, I'll most likely annoy them a bit soon!
    [18:49] <astron247> the problem with the conversion to ui is that even our terrible ui gets converted, unquestioned
    [18:49] <mirek2> you could meet some of the developers
    [18:50] <aurelien_n> let's start by checking if I can get some work done first!
    [18:50] <astron247> btw, mirek2: are you going?
    [18:50] <mirek2> probably
    [18:50] <aurelien_n> but I guess that a few devs dedicated to GUI tweaks over a year or two would make a big difference
    [18:50] <mirek2> aren't you?
    [18:50] <aurelien_n> when/where is it?
    [18:50] <astron247> its soon :)
    [18:51] <mirek2> http://conference.libreoffice.org/2013/en
    [18:51] <@mipmap_> spain or something
    [18:51] <astron247> no
    [18:51] <mirek2> Milono
    [18:51] <@mipmap_> yep
    [18:51] <mirek2> Sep. 25-27
    [18:51] <mirek2> Milano
    [18:51] <@mipmap_> would be awsome to attent
    [18:51] <@mipmap_> attend
    [18:51] <@mipmap_> <- unemployed and poor :)
    [18:52] <astron247> oh :(
    [18:52] <aurelien_n> milono = milano, italy?
    [18:52] <aurelien_n> oh, right
    [18:52] <mirek2> yup
    [18:53] <aurelien_n> at least it is in europe
    [18:53] <@mipmap_> hm, I think I will close the shop for today
    [18:53] <aurelien_n> ok
    [18:53] <@mipmap_> see you next week or in mail-list
    [18:53] <mirek2> alright
    [18:53] == mipmap_ [5a84242b@gateway/web/freenode/ip.90.132.36.43] has quit [Quit: Page closed]
    [18:53] <aurelien_n> thanks for the comment, hoping to continue this soon!
    [18:54] == aurelien_n [~aurelien@31-36.3-85.cust.bluewin.ch] has left #libreoffice-design ["Ex-Chat"]
    [18:54] <mirek2> should we end the chat?
    [18:54] <issa> just one thing
    [18:54] <mirek2> go ahead
    [18:55] <issa> I've used Gnome's wrench http://i.imgur.com/B1HWTWZ.png
    [18:55] <issa> it looks better, but still not that good
    [18:56] <mirek2> make the cut part based on the wrench shape rather than an oval
    [18:57] <mirek2> also, try bringing the main shapes closer to the center
    [18:57] <mirek2> of the icon
    [18:57] <issa> alright
    [18:57] <mirek2> they are too high imho
    [18:57] <astron247> issa, what size are the icons in your image optimized for?
    [18:58] <issa> the small ones are 16x16 and the large ones are 24x24
    [18:58] <astron247> ok, because they look bigger in the image..?
    [18:59] <mirek2> I would suggest to do the cut by duplicating the wrench, making an outline (2-4px), converting the outline to a path, then subtracting it from the main shape
    [18:59] <issa> oh, I guess I exported them wrong
    [18:59] <astron247> ok
    [19:00] <issa> mirek2: that's what I usually do, but in this case the wrench tips would form an x shape
    [19:01] <mirek2> could you post a screen?
    [19:03] <issa> just a second
    [19:03] <issa> http://i.imgur.com/lprKfrA.png
    [19:04] <issa> I guess it wouldn't matter because it's small
    [19:04] <mirek2> I don't see the X
    [19:04] <mirek2> I think it's good
    [19:05] <issa> never mind, I remember it was bigger than that http://i.imgur.com/q8TpjsV.png
    [19:06] <issa> also here's the actual size of the icons http://i.imgur.com/Uy6ZCdM.png
    [19:06] <mirek2> you could try a smaller outline size
    [19:07] <astron247> issa, how about adding the outline, and then making a path from the outline?
    [19:07] <issa> but that's the one I've been using for all icons with sub icons
    [19:08] <issa> astron247: I don't see how that's any different?
    [19:08] <issa> astron247: do you mean I should manually remove the extra edges?
    [19:09] <astron247> ye
    [19:09] <astron247> s
    [19:10] <astron247> i mean, once youve done that, you can copy the now two shapes everywhere else
    [19:10] <issa> ok
    [19:11] <mirek2> anything else?
    [19:12] <issa> no
    [19:12] <mirek2> ok
    [19:12] <mirek2> I'll put up the log
    [19:12] <mirek2> one more thing
    [19:12] <mirek2> I won't be here next week
    [19:13] <mirek2> can either of you be here?
    [19:13] <astron247> yes
    [19:13] <issa> I should be
    [19:13] <mirek2> ok
    [19:13] <mirek2> the chat is in your hands then