[04:17] <mhb> hi everyone, hi kwwii
[04:23] <troy_s> greets mhb
[04:40] <mhb> how's artwork?
[04:40] <mhb> or do you rather enjoy holidays?
[04:58] <msikma> Artists never rest. Or sleep, for that matter.
[05:00] <klepas> yes they do
[08:47] <n8k99> hi all
[08:50] <n8k99> mhb: here I is!
[08:55] <mhb> n8k99: hi
[08:55] <n8k99> mhb: art art art!
[08:55] <mhb> so, what do you say to the Edgy artwork?
[08:55] <mhb> Kubuntu Edgy?
[08:55] <n8k99> loved the kubuntu stuff
[08:55] <n8k99> don't really use the gnome version
[08:56] <n8k99> ...however I do prefer the baghira theme for kwin
[08:57] <n8k99> but I have been seeing some stuff that troy_s has been doing for U2
[08:57] <troy_s> ping
[08:57] <n8k99> the brown wood grain is nice - was thinking taht maybe there could be a kde version of that that uses a blue tone
[08:57] <troy_s> how goes it guys?
[08:57] <troy_s> actually, moving away from wood for the total panel.
[08:57] <troy_s> the newest just got upped
[08:58] <troy_s> its amber
[08:58] <troy_s> as bloody apple looks like it might be migrating into organics
[08:59] <mhb> troy_s: so you're moving away from organics?
[09:00] <troy_s> hell no
[09:00] <troy_s> the light pine though is out, as much as it is quite nice.
[09:00] <troy_s> might offer it as an alternative.
[09:01] <n8k99> no- I preferred the darker wood
[09:01] <troy_s> the lacquered amber is also appealing though.
[09:01] <troy_s> the 'darker' wood is actually amber.
[09:01] <n8k99> right that's the one - but if it had a blue tone it'd be gr8 over here in kdeville
[09:01] <troy_s> https://wiki.ubuntu.com/ubun2design/u2Specifications/u2WindowProposals
[09:01] <troy_s> well right now the code isn't clean yet...
[09:01] <troy_s> as it is all proof of principle
[09:01] <troy_s> once it is cleaned
[09:02] <troy_s> it will be colorizable and scalable to fonts
[09:02] <troy_s> just takes a little more work with the engine rc
[09:02] <mhb> troy_s: I don't think apple is moving to wood/metal though
[09:02] <troy_s> mhb -- i think you might be incorrect.
[09:02] <mhb> troy_s: I think somebody showed you garageband or something, right?
[09:02] <troy_s> mhb -- it is a very hot item in design circles right now, and if you look
[09:02] <troy_s> at the new bloody j. ives stuff on interface you will see a distinct movement away from plastic gloss
[09:03] <troy_s> as in the new itunes
[09:03] <troy_s> and the new garageband
[09:03] <troy_s> that said, i don't think they can push it as much as we can.
[09:03] <troy_s> as their 'boxes' are still very sterile ikea kitchen appliances.
[09:03] <troy_s> plastic is simply _done_.
[09:03] <mhb> true
[09:04] <troy_s> pop5 is pretty much the direction heading now.  with an adjustment for top left lighting to follow shortly.
[09:04] <mhb> pop5?
[09:05] <n8k99> yeah that's totally the one I am keen about
[09:05] <troy_s> proof of principle 5 on that proposal page.
[09:05] <troy_s> i adjusted the polish as the rc linework was hogging cycles
[09:05] <mhb> ah
[09:05] <troy_s> and it simply wasn't communicating the way it should.
[09:05] <troy_s> far superior now.
[09:06] <troy_s> going to bang out some icon work shortly, as xmas was a time hog.
[09:06] <troy_s> top panel needs work now too, and will be matching the window border.
[09:09] <mhb> troy_s: cool
[09:09] <troy_s> as per the interface design specs..
[09:09] <mhb> n8k99: do you have a screenshot of your preferred kwin theme?
[09:09] <troy_s> ideally, i think for usability, the primary desktop surface should inherently imitate the design and implementation of the window
[09:10] <n8k99> mhb: yeah hang on
[09:13] <mhb> troy_s: you still need to clearly define the background / foreground
[09:13] <troy_s> yes.
[09:13] <troy_s> are you speaking about the edges of windows?
[09:14] <mhb> troy_s: about the "primary desktop surface"
[09:14] <mhb> troy_s: I may have misunderstood the term
[09:14] <troy_s> the intention is to develop the focused window and the two panels to be reflective of each other.
[09:15] <troy_s> meaning that the close window button and the shutdown/logout button will look identical and be in the identical spots.
[09:15] <troy_s> minimize button also will be relfected in the 'show desktop' panel application.
[09:15] <troy_s> etc.
[09:15] <troy_s> so that the design is inherently intuitive.
[09:16] <troy_s> window menu will be in the same position and have the same look as the primary desktop main menu.
[09:16] <troy_s> the rest is uncluttered.
[09:16] <n8k99> http://eckenrodehouse.net/kubuntu/snapshot1.png
[09:16] <n8k99> that's an old favorite
[09:16] <mhb> troy_s: that's going to be hard
[09:16] <mhb> troy_s: because you have a lot less space on the window menu
[09:17] <n8k99> but I prefer it blue
[09:17] <troy_s> mhb?
[09:17] <troy_s> strictly speaking in terms of muscle memory and intuition -- the two menus will be in the same location and offer the same icon
[09:18] <n8k99> http://eckenrodehouse.net/kubuntu/konqueror-konsole.png is a better desktop that I normally rock
[09:18] <mhb> troy_s: you mean when the window menu is maximized?
[09:19] <mhb> troy_s: well, wouldn't that be confusing?
[09:20] <mhb> troy_s: I mean when you have a similar icon for "close window" and "shut down the system" people might get confused
[09:20] <n8k99> is that helpful mhb ?
[09:20] <mhb> n8k99: sure
[09:20] <troy_s> mhb no
[09:21] <mhb> n8k99: you're Nathan Eckenrode? Where do I know your name from?
[09:21] <troy_s> basically, that the far right button is close window, and the system panel upper will reflect the window properties
[09:21] <troy_s> meaning that the window close button
[09:21] <troy_s> and the shutdown system / logout button will be in the same location and offer the same icon
[09:21] <n8k99> mhb: no idea? I get around?
[09:22] <mhb> n8k99: I must have read it somewhere ... any important project you're a member of?
[09:22] <n8k99> mhb: og has mentioned me a couple times in his blog on the planet
[09:23] <n8k99> I presented *ubuntu with him @ the UN
[09:23] <troy_s> og?
[09:23] <troy_s> oliver?
[09:24] <n8k99> og marcel: brazil-port translator
[09:25] <n8k99> sometimes my name flashes by in the technical credits for hollywood
[09:25] <n8k99> ?
[09:25] <n8k99> no other clue
[09:27] <mhb> troy_s: aren't the users accustomed to the shutdown symbol and to the close button "x" symbol?
[09:27] <troy_s> indeed.
[09:27] <troy_s> which is why both will probably be an X
[09:28] <troy_s> as opposed to muddling the issue with learning new analogies with the power button.
[09:29] <mhb> troy_s: how can the user tell that the "X" sign top right does shutdown the system and not closes the current window?
[09:30] <mhb> troy_s: they might think that if those two are similar
[09:30] <mhb> n8k99: the baghira theme is nice, but you can't use that as a default for Kubuntu
[09:31] <mhb> n8k99: the buttons are too Mac-OS like
[09:31] <n8k99> yeah I know
[09:31] <n8k99> that's what I like about PoP 5 - it has the same basic feel
[09:32] <n8k99> just that the colors need to be corrected for kde
[09:32] <n8k99> and the buttons need to be, erm, made more easy to determine what they do
[09:32] <kwwii> btw. if anyone is interested in Oxygen, I am creating wiki pages (my favorite pastime) on http://developernew.kde.org/Projects/Oxygen
[09:37] <mhb> kwwii: great!
[09:37] <mhb> kwwii: thanks
[09:38] <mhb> kwwii: any screenshots of the windeco style yet?
[09:38] <mhb> n8k99: I guess the current windeco style is not that bad
[09:38] <mhb> n8k99: (Kubuntu)
[09:39] <kwwii> mhb: the code is in svn, but itis not very far yet
[09:40] <kwwii> and from day to day it either builds or it does not
[09:40] <mhb> kwwii: I've noticed, but I don't have KDE4 compiled yet
[09:40] <kwwii> ie. don't blame me
[09:40] <kwwii> :p
[09:40] <kwwii> yeah, it is only for kde4
[09:40] <mhb> n8k99: those same-looking buttons may be confusing for first-time users
[09:40] <mhb> n8k99: or former Windows users
[09:41] <n8k99> mhb: yes that's why I like having them colorcoded
[09:42] <mhb> n8k99: even then
[09:42] <mhb> n8k99: at least they are for me :o)
[09:43] <n8k99> mhb: I think that the current default buttons are a bit kludgey
[09:43] <n8k99> could just be me - I like watching the timetrial bike racers more than mountain bike racers
[09:44] <mhb> n8k99: kludgey?
[09:44] <mhb> n8k99: what do you mean by that?
[09:44] <n8k99> they are square with rounded corners and a symbol on the inside
[09:45] <n8k99> plus they are colored
[09:45] <n8k99> that's four elements per button
[09:45] <n8k99> no coded elements - visual elements
[09:45] <n8k99> s/not/no
[09:48] <mhb> n8k99: do you think that's too much?
[09:48] <n8k99> mhb: I actually do
[09:49] <mhb> n8k99: they aren't colored when not selected
[09:49] <n8k99> mhb: I'm just much more fond of a circle over a rounded corner square
[09:50] <n8k99> maybe even ovals
[09:51] <n8k99> it's really the button shape that drove me away from the default
[09:51] <n8k99> the rest of it is absolutely gorgeous
[09:51] <mhb> n8k99: you can do some proposals if you want
[09:51] <mhb> n8k99: but I think the symbols should stay
[09:52] <n8k99> ok
[09:52] <troy_s> mhb
[09:52] <troy_s> similar tasks should be similarly grouped
[09:52] <mhb> troy_s: yes?
[09:52] <troy_s> as in, closing a window is very much like closing a desktop session.
[09:53] <troy_s> the paradigm shift is only different based on the primary desktop window as compared to the standard windowing system.
[09:53] <mhb> troy_s: there are differences, for example the frequency of closing a window / closing a windowing system
[09:54] <mhb> troy_s: I close windows every day but I don't end the window session at all (I use the suspend to RAM shortcut)
[09:54] <troy_s> mhb, yes.  but in practical terms, if you teach a user to use the upper left corner to shut a window down, it isn't a large gap for an average user to figure out that the upper x will indicate similar functionality.
[09:54] <mhb> troy_s: I know users don't do that, but they end the session not so often
[09:55] <troy_s> again, the target audience is average computing skill based.
[09:56] <troy_s> to expand on that, the top panel would be reflective of the top window area on a standard window, and the lower panel is more 'status' based.
[09:57] <msikma> You're saying the top bar in Gnome should be like the top bar of a window?
[09:57] <troy_s> exactly
[09:57] <msikma> why
[09:58] <kwwii> we are working on the oxygen style and it will not include a seperation between the top "window decoration" and the toolbar...is that what you mean?
[09:58] <troy_s> functional panelling
[09:58] <troy_s> well the window that users use on a regular basis
[09:58] <troy_s> as in the top 'area' of a window
[09:58] <msikma> The top bar in gnome is not the top bar of a window. The top bar of a window is not the top bar in gnome.
[09:58] <troy_s> no, but the functionality is similar
[09:58] <msikma> So in that case you think we should just make them equal?
[09:59] <troy_s> paradigm speaking yes.
[09:59] <msikma> They will never have the same functionality.
[09:59] <msikma> They don't have it now and they won't have it in the future.
[09:59] <troy_s> there is 'affordance' with each
[09:59] <troy_s> well actually there are similar traits exhibited in each.
[09:59] <msikma> There's similarities between many different parts of an OS, but it's still important that they're different from each other.
[09:59] <troy_s> for example, the minimize / maximize buttons all deal with adjusting the current view of a window
[09:59] <troy_s> well sure, and a command line is probably the most extreme version of it.
[10:00] <troy_s> there is 'affordance' offered in all of the functionality
[10:00] <troy_s> meaning
[10:00] <troy_s> that a single click doesn't adversely affect anything in the top panel functionality.
[10:01] <troy_s> logical grouping would abide by the 'consistency' principle.
[10:02] <kwwii> sometimes I wonder who is kidding who
[10:02] <msikma> That doesn't mean we should equalize the top bar of gnome with the top bar of a window. Both have different functionality, and thus a different appearance. The fact that they have similarities won't make anyone believe that they are somehow related. Making it seem as though this is true will only confuse people needlessly.
[10:03] <troy_s> i don't believe so... if a menu is in the upper left of a window, one could easily expect a menu in the upper left of the top panel.
[10:04] <msikma> Certainly.
[10:04] <troy_s> likewise for closing.
[10:04] <troy_s> et.c
[10:04] <msikma> Even though I'm against the "close session" button at the top-right of the gnome toolbar, that too, I can understand.
[10:04] <msikma> It depends on how far you're willing to go.
[10:06] <troy_s> simply extending learned paradigms.
[10:06] <troy_s> its rather practical.
[10:07] <msikma> A widget's design should follow its functionality.
[10:07] <msikma> That, and no more or less.
[10:07] <msikma> Although it should be noted that a design may add additional functionality.