Re: [Ayatana] File transfer dialog behaviour

2010-05-15 Thread Akshat Jain
On Sat, May 15, 2010 at 3:02 AM, Frederik Nnaji frederik.nn...@gmail.comwrote:

 Hi David, your mockup looks pretty.. becoming more like a hybrid between
 our notification bubbles and and interactive progress indication dialog..
 i like the visual  this is taking!

 some ideas on this:

 REMOVE THE TITLE BAR
 why?
 a) imagine you hit the cancel button..
 the window would close immediately, since there is nothing left to learn or
 to interact with in this progress dialog.

Yeah!

b) minimizing this dialog should hide it, until you are notified about its
 completion.


 It still does.when I minimize,it goes to the notification area

PAUSE OPERATION
 add a pause button beside the cancel and you'll have an easily
 discoverable pause feature.

 Yeah!


 ADD CONTINUE IN BACKGROUND BUTTON
 all that's missing now is a way to let the computer know that you have
 acknowledged the informative part and you don't wish to interact..
 something like continue in background.
 winrar does this quite well ;)

 Yeah!


 OBJECT TITLE IN PROGRESS BAR
 while copying, display the title of the object being copied in the progress
 bar.
 putting this information anywhere else in the dialog window doesn't make
 too much sense.

No!


 REMOVE GEEKY INFORMATION
 don't display details like filesize vs transferred data.
 the progress bar should indicate that sufficiently.
 perhaps add a [ + ] button for details on the operation.

 This isn't geeky information anymore.It is also on Windows Vista/7



 ___
 Mailing list: https://launchpad.net/~ayatanahttps://launchpad.net/%7Eayatana
 Post to : ayatana@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~ayatanahttps://launchpad.net/%7Eayatana
 More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp


Re: [Ayatana] Default to single click to open files and folders

2010-05-15 Thread Akshat Jain
At first I was against this idea but after trying Kubuntu I am in favour of
this idea,It only took me a few minutes to be adjusted.I tried this 10
people(old people and 4-6 year old children)who had never used computers and
they were comfortable with single click but had problems with Double-Click
with many took as long as 1 hour to learn the double click(especially old
people).So overall single click is a win for Ubuntu.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp


Re: [Ayatana] Default to single click to open files and folders

2010-05-15 Thread SorinN
On the topic of double click or single click - the user should choose
not others. Open Source should not became a prison.

2010/5/12 Jan-Christoph Borchardt inqu...@googlemail.com:
 What about that? Are there any plans already to default to single
 click for opening files and folders in Ubuntu?

 It is way more intuitive to open with just a single click and have the
 modifier for the less frequent use-case of selecting (multiple)
 elements.

 Launcher icons are also activated by single click.

 A reverse example: My mother always double clicks links in the browser
 – regardless how often I tell her that it is not necessary. Muscle
 memory and habit is just too strong. Regarding that nowadays, people
 presumably spend more time in their web browser instead of their file
 manager, it would make sense to adopt the web standard for clicking.

 On a sidenote: I know two kids who changed the click behavior to
 single click on their own. They see double clicking as just annoying.

 ___
 Mailing list: https://launchpad.net/~ayatana
 Post to     : ayatana@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~ayatana
 More help   : https://help.launchpad.net/ListHelp




-- 
Nemes Ioan Sorin

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp


Re: [Ayatana] Default to single click to open files and folders

2010-05-15 Thread Mark Curtis

Regardless, one or the other has to be the default. I think that's more the 
discussion here, if changing the default behavior is beneficial.

 Date: Fri, 14 May 2010 23:47:41 -0700
 From: nemes.so...@gmail.com
 To: inqu...@gmail.com
 CC: ayatana@lists.launchpad.net
 Subject: Re: [Ayatana] Default to single click to open files and folders
 
 On the topic of double click or single click - the user should choose
 not others. Open Source should not became a prison.
 
 2010/5/12 Jan-Christoph Borchardt inqu...@googlemail.com:
  What about that? Are there any plans already to default to single
  click for opening files and folders in Ubuntu?
 
  It is way more intuitive to open with just a single click and have the
  modifier for the less frequent use-case of selecting (multiple)
  elements.
 
  Launcher icons are also activated by single click.
 
  A reverse example: My mother always double clicks links in the browser
  – regardless how often I tell her that it is not necessary. Muscle
  memory and habit is just too strong. Regarding that nowadays, people
  presumably spend more time in their web browser instead of their file
  manager, it would make sense to adopt the web standard for clicking.
 
  On a sidenote: I know two kids who changed the click behavior to
  single click on their own. They see double clicking as just annoying.
 
  ___
  Mailing list: https://launchpad.net/~ayatana
  Post to : ayatana@lists.launchpad.net
  Unsubscribe : https://launchpad.net/~ayatana
  More help   : https://help.launchpad.net/ListHelp
 
 
 
 
 -- 
 Nemes Ioan Sorin
 
 ___
 Mailing list: https://launchpad.net/~ayatana
 Post to : ayatana@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~ayatana
 More help   : https://help.launchpad.net/ListHelp
  
_
The New Busy is not the too busy. Combine all your e-mail accounts with Hotmail.
http://www.windowslive.com/campaign/thenewbusy?tile=multiaccountocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_4___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp


Re: [Ayatana] Doube-click

2010-05-15 Thread Thorsten Wilms
All but Luke Morton please skip past the following block:
---
Sorry to take this back on the list, but apparently I can't send 
mail to your given address and wouldn't know how else to reach you:

SMTP error from remote mail server after initial connection:
host ipmailmx.internode.on.net [192.231.203.138]:
554-ipmailmx06.adl6.internode.on.net
554-ESMTP; mout4.freenet.de [195.4.92.94] in MX's
BLACKLISTmail-abuse; crashed into the sunset
554 Blocked using Trend Micro RBL+. Please see
http://www.mail-abuse.com/cgi-bin/lookup?ip_address=195.4.92.94
---


On Sat, 2010-05-15 at 17:31 +1000, Luke Morton wrote:

 I've never edited an ubuntu wiki article. Is there a policy/etiquette
 regarding editing other people's content?

Just in case your are not familiar with MoinMoin, if your are logged in
and click Edit, you will find some markup examples and links to
documentation below the text entry.

Basically: treat other's contributions with respect and be thoughtful 
about your own.

You should not change the meaning of what other's wrote or delete stuff,
unless you are very sure what you are doing.

This can become a balance act between not forcing your point of view and
avoiding a mess.

Someone else's take on wiki etiquette:
http://senseis.xmp.net/?WikiEtiquette



 And do you think some user scenarios would be valuable?

What could we learn from users scenarios here and what might those
scenarios be?

We already have established problems users might have due to a lack of
training with the mouse, limited motor skill or RSI.

This is about very basic and quick operations, so there likely isn't
that much to explore. Maybe list cases where a user would want to select
multiple files? Continuous vs random selections. Can you think of cases
where differing needs would arise?


-- 
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/




___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp


Re: [Ayatana] Doube-click

2010-05-15 Thread Jan-Christoph Borchardt
On 14 May 2010 20:50, Thorsten Wilms t...@freenet.de wrote:
 I tried to collect the thoughts so far, regarding single-click mode for
 activation, but starting from the possible objective of getting rid of
 double-clicking:
 https://wiki.ubuntu.com/Ayatana/DoubleClick

Great, thanks! :)


 You might find that biased. Please add things that I might have missed.
 Edit the wiki directly, let's just try to not turn that page into a
 discussion board.

I added a few details and started a benchmarking category with
screenshots so comparison is easier (also for people who don‘t like to
or can‘t install Dolphin).

I could add Mac OS (if I find the functionality) and Windows (but only
XP I think) later.

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp


Re: [Ayatana] Improving single click for all GTK+ apps to make it suitable as a standard

2010-05-15 Thread Thorsten Wilms
On Sat, 2010-05-15 at 07:57 -0400, Freddie Unpenstein wrote:

 On the toolkit side, what I would like to see, is more cooking of the
  input events, similar to how terminals and X itself allow access to
  raw keystrokes, the processed/mapped input events, down to the final
  activation of a widget.
 
 In this regard, how about a consistant mechanism across all GTK widgets
  to intelligently process keyboard and mouse events, kind of like the
  three-stage cooking that goes on in commandline terminals:
 
 1-  the existing signals for the original raw mouse and keyboard
  events. (...)

 2- recognition of the shift/click/drag operation that the user may be
  performing, (...)

 3- looking up the emissions on stage two in a list of symbolic
  mappings, and re-emitting the resultant action as a final fully
  cooked input signal. (...)

 A widget, instead of implementing its own keyboard/mouse mapping code,
  could in most cases simply register a set of actions and their
  corresponding default mappings in the third stage processing, and let
  the default (or theme) mappings match those actions to their input
  sequences.


I would love to see a system-wide gesture-to-action mapping and you seem
to be talking about roughly the same.

Gestures would be sequences of stuff that the user does using input
devices (hardware controllers) and actions would be what the software
does in response.

Gestures could include simple clicks and keyboard input, but also
multi-touch gestures and even Emacs-style sequences.

For all GTK+ apps would be a nice start, but cross-toolkit would be even
better.

I wrote more about that back in 2007:
http://thorwil.wordpress.com/2007/04/10/event-to-action-mapping-1/


-- 
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/


___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp


Re: [Ayatana] Is it time we killed minimize to tray ?

2010-05-15 Thread Сергей
2010/5/14 David Hamm davidth...@gmail.com

 Chat windows used to be one click away. This was one of the best
 arguments against it until they made the tray.
 http://blogs.gnome.org/mccann/2009/07/05/getting-the-message/
 but you can still use the same argument, in that, gnome shell cannon't
 presume to know how all applications will work.

I love the tray concept. If Empathy would show its icon there, it will solve
the problem with chat windows. Calculator could be a screenlet or something
like that.


 Unfortunately I can see an audience for shell, maybe not as great as
 the ipad, but nonetheless it leaves me longing for android. Around
 early 2009 was the last chance anyone had to change the direction of
 the beast, unfortunately I found out to late, and now all we can do is
 watch. Its like one of those horror movies that you know the ending!
 nah gs brings more good then harm.

Try Maemo (http://maemo.nokia.com). You'll instantly forget Android.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp


Re: [Ayatana] Pretty mockups with darkly coloured progress dialogs (was: File transfer dialog behaviour)

2010-05-15 Thread Frederik Nnaji
yeah, thx.
actually, we're on the verge of redesigning windows as a whole.

* the title bar is losing importance (e.g.  we're treating the buttons like
trivial objects)
* windows are turning into intelligently shaped objects or fullscreen work
environments
* clutterful information in our focal point is reduced
* overlayed widgets and dialogs don't cover formerly focused objects [1]

all this in mind, i think it's about time to reconsider the applications of
RGBA in our DE design, especialla the A in RGBA ;)

that's my thoughts on the matter

On Sat, May 15, 2010 at 00:06, Dylan McCall dylanmcc...@gmail.com wrote:


 I guess MacOS has dark windows and light windows following some kind
 of pattern, too. Anyone know what theirs is?


i remember notification bubbles that, in spite of informing me well, don't
obscure the object they are informing about or any other object, since they
are semi-tranparent..

all dialogs that are usually (gather use cases) rather informative than
interactive should behave like this IMO
- app-specific alerts
- progress bars
- menus
- floating toolbars
- widget layers


[1] http://img651.imageshack.us/img651/1074/rgbagtk2.png (from
https://wiki.ubuntu.com/DesktopTeam/RgbaGtkWithPPA/)
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp


[Ayatana] Should Indicator-Session be put in the upper left corner

2010-05-15 Thread Mark Curtis

The reasoning behind the controversial button movement to the left was 
that starting/quitting would be on the left, and status would be on the 
right.

Given that reasoning, for consistency sake shouldn't 
indicator-session go on the far left since it is for starting/quitting 
an entire session?
_
The New Busy think 9 to 5 is a cute idea. Combine multiple calendars with 
Hotmail. 
http://www.windowslive.com/campaign/thenewbusy?tile=multicalendarocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_5___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp


Re: [Ayatana] Should Indicator-Session be put in the upper left corner

2010-05-15 Thread Frederik Nnaji
On Sat, May 15, 2010 at 16:48, Mark Curtis merkin...@hotmail.com wrote:

  The reasoning behind the controversial button movement to the left was
 that starting/quitting would be on the left, and status would be on the
 right.

 Given that reasoning, for consistency sake shouldn't indicator-session go
 on the far left since it is for starting/quitting an entire session?


aha!
looks interesting to me!
apple does this AFAIK

i'm not interested in copying windows or apple behaviour on the long run,
but there's nothing wrong with doing the right thing, once you started down
that path already..
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp


Re: [Ayatana] Default to single click to open files and folders

2010-05-15 Thread David Hamm
The more options and questions and choices we present to the
user, the less they will want to know about *any* of them.

btw, you have seen the power menu right?

.right, back to single click discussion. I'd say get everyone round
the office to set single click and have a vote after a week. reason
single click works so well for fingers is that your fingers move
slower and more decisively then a mouse. If we do go single click
make sure to give that back button emphasis. (like firefox, big back,
small forward)

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp


Re: [Ayatana] Default to single click to open files and folders

2010-05-15 Thread David Hamm
ps. select on hover-over (for devices w/ keyboards) is kinda necessary
if we switch to single click, which i'm all for btw.

the only thing that can enslave a person, is another person.

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp


Re: [Ayatana] Criticism of Client Side Window Decorations

2010-05-15 Thread Scott Kitterman


Akshat Jain ssj6akshat1...@gmail.com wrote:

Link Copy-Pasta
http://blog.martin-graesslin.com/blog/2010/05/why-you-should-not-use-client-side-window-decorations/
http://blog.martin-graesslin.com/blog/2010/05/follow-up-on-client-side-decorations/

This guy named Martin Gräßlin is a hardcore KWin fan I think,looks like if
he were a senior GNOME developer he would have replaced Metacity with
KWin.Lol

Design Team?

He's one of the leading kwin developers. It would be a bit surprising if he was 
not a fan.

Personally I find turning window decoration over to applications an odd way to 
go about increasing consistency on the desktop. 

I suspect it is unlikely that features requiring CSD will not have any easy 
time getting support across the Free desktop. (fwiw, windicators are not, 
afaiui, such a change).

Scott K___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp


Re: [Ayatana] Criticism of Client Side Window Decorations

2010-05-15 Thread Frederik Nnaji
On Sat, May 15, 2010 at 17:48, Scott Kitterman ubu...@kitterman.com wrote:

 Akshat Jain ssj6akshat1...@gmail.com wrote:

 Link Copy-Pasta
 
 http://blog.martin-graesslin.com/blog/2010/05/why-you-should-not-use-client-side-window-decorations/
 
 http://blog.martin-graesslin.com/blog/2010/05/follow-up-on-client-side-decorations/
 
 This guy named Martin Gräßlin is a hardcore KWin fan I think,looks like if
 he were a senior GNOME developer he would have replaced Metacity with
 KWin.Lol
 
 Design Team?

 He's one of the leading kwin developers. It would be a bit surprising if he
 was not a fan.

 Personally I find turning window decoration over to applications an odd way
 to go about increasing consistency on the desktop.


i see the point, though.
turning over the title bar design to the app will not increase consistency
altogether..

two things happen, if we do this:
* app designers will consider DE-wide consistency more
* sooner introduction of gnome-globalmenu
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp


Re: [Ayatana] Default to single click to open files and folders

2010-05-15 Thread Alex Lourie
On Sat, May 15, 2010 at 7:51 PM, Frederik Nnaji frederik.nn...@gmail.comwrote:


 User testing has revealed that single click comes more intuitively to users
 than double click.


Would you care to elaborate on that? What user testing?

90% of computers used today (Windows) using double click, another 5% of Mac
using double click, so ALL LINUX users are split between single click and
double click. So I'm not completely convinced about these user testing
having place.

Now, please don't get me wrong here - if there was such a testing I would
happily look at it. I just know that I personally always turned this feature
off.

And please people, stop comparing this to the iPhone/iPad - the interface on
those devices is different enough that no one ever would think to
double-tap them. In addition, at least by default, they are not intended
to work with files at all.

-- 
Alex Lourie
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp


Re: [Ayatana] Default to single click to open files and folders

2010-05-15 Thread David Hamm
As a matter of dignity and manly pride I challenge you, Alex Lourie,
to open nautiluseditpreferencesbehaviorsingle click, for a week.
And after that week, comeback and complain!

btw. the whole freaking internet is single click. psh.

On Sat, May 15, 2010 at 2:01 PM, Alex Lourie djay...@gmail.com wrote:

 On Sat, May 15, 2010 at 7:51 PM, Frederik Nnaji frederik.nn...@gmail.com
 wrote:

 User testing has revealed that single click comes more intuitively to
 users than double click.

 Would you care to elaborate on that? What user testing?
 90% of computers used today (Windows) using double click, another 5% of Mac
 using double click, so ALL LINUX users are split between single click and
 double click. So I'm not completely convinced about these user testing
 having place.
 Now, please don't get me wrong here - if there was such a testing I would
 happily look at it. I just know that I personally always turned this feature
 off.
 And please people, stop comparing this to the iPhone/iPad - the interface on
 those devices is different enough that no one ever would think to
 double-tap them. In addition, at least by default, they are not intended
 to work with files at all.
 --
 Alex Lourie

 ___
 Mailing list: https://launchpad.net/~ayatana
 Post to     : ayatana@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~ayatana
 More help   : https://help.launchpad.net/ListHelp



___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp


Re: [Ayatana] Default to single click to open files and folders

2010-05-15 Thread Tyler Brainerd
I'm changing my computer to single click to see what I think.

On Sat, May 15, 2010 at 2:07 PM, David Hamm davidth...@gmail.com wrote:

 As a matter of dignity and manly pride I challenge you, Alex Lourie,
 to open nautiluseditpreferencesbehaviorsingle click, for a week.
 And after that week, comeback and complain!

 btw. the whole freaking internet is single click. psh.

 On Sat, May 15, 2010 at 2:01 PM, Alex Lourie djay...@gmail.com wrote:
 
  On Sat, May 15, 2010 at 7:51 PM, Frederik Nnaji 
 frederik.nn...@gmail.com
  wrote:
 
  User testing has revealed that single click comes more intuitively to
  users than double click.
 
  Would you care to elaborate on that? What user testing?
  90% of computers used today (Windows) using double click, another 5% of
 Mac
  using double click, so ALL LINUX users are split between single click and
  double click. So I'm not completely convinced about these user testing
  having place.
  Now, please don't get me wrong here - if there was such a testing I would
  happily look at it. I just know that I personally always turned this
 feature
  off.
  And please people, stop comparing this to the iPhone/iPad - the interface
 on
  those devices is different enough that no one ever would think to
  double-tap them. In addition, at least by default, they are not
 intended
  to work with files at all.
  --
  Alex Lourie
 
  ___
  Mailing list: https://launchpad.net/~ayatana
  Post to : ayatana@lists.launchpad.net
  Unsubscribe : https://launchpad.net/~ayatana
  More help   : https://help.launchpad.net/ListHelp
 
 

 ___
 Mailing list: https://launchpad.net/~ayatana
 Post to : ayatana@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~ayatana
 More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp


Re: [Ayatana] Default to single click to open files and folders

2010-05-15 Thread Alex Lourie
On Sun, May 16, 2010 at 12:07 AM, David Hamm davidth...@gmail.com wrote:

 As a matter of dignity and manly pride I challenge you, Alex Lourie,
 to open nautiluseditpreferencesbehaviorsingle click, for a week.
 And after that week, comeback and complain!

 btw. the whole freaking internet is single click. psh.


David,

I believe I just did (and even said it) :-)

I always felt irritated by this one click to open folder thing, and my
productivity always get hurt when it's on.

I'm more with Conscious User on this: I'm not saying that double click is
good - I'm saying that I don't see the single click as the solution.

Subjectively, of course.

-- 
Alex Lourie
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp


Re: [Ayatana] Instant-messaging as an indicator menu

2010-05-15 Thread Frederik Nnaji
The Social Desktop, nicely wrapped in a consistent and comfortable UI, will
bring the Meercat into many a household! ;)

Humans share their knowledge and skills in the Ubuntu community, why don't
apps also behave like that? Something i can't stop reasoning about..
Yeah, we need to untangle Ubuntu's social desktop apps, give them an
intuitive and accessible structuring, make the social apps talk to each
other.
Some more userland IPC for a change would help enormously, and we have most
of the code for this out there already.

Me Menu, Messaging Menu and Contact List, all accessible by 1 click from
Ubuntu's Gnome Panel, are not working together as one, and they are not
behaving consistently with the other giant baby newcomer Gwibber, nor is
anyone really saving up my facebook/google talk contacts in the cloud
(Ubuntu One).
why not?
a) Me Menu duplicates availability setting from Contact List: confusion.
b) Me Menu configures services that live in the Messaging Menu: confusion.
c) Click-Hold-Aim-Release is no improvement to Click (show
contacts/Messaging Menu): a step backwards
d) Contact List doesn't deserve its name, it's only an availability status
notifier with IM nicks at the moment.
e) gwibber's behaviour is inferior to all popular Website AJAX interactivity
(clicking like or adding comments reloads the whole stream-page and breaks
the user's interaction focus by jumping to the top of the stream...)

We should *at least* match the interactivity comfort of facebook.com and
mail.google.com..
Perhaps some dedicated usage of WebKit with a minimal local LAMP and some
accessible scripts and some CSS featuring RGBA in a WebKit based UI would
make a more powerful interface than the Erlang experiments currently
happening in Gwibber.. who knows anything about that?
* is it smart to implement AJAX-based social website UI behaviour using
Erlang?
* does your facebook.com stream jump to the top when you commit a comment?
* does your jabber webclient on mail.google.com reload the whole page for
every IM?
* does your bike release the clutch when you flip the light switch?
* does your mobile phone reboot its UI for each button pressed?

As long as Gwibber sucks, i will use the respective webpages instead.
I'm not alone in this observation, prove me wrong.
Same goes for Evolution, which is a landmark jack-of-all-trades suite of
Unusability [1].
We might as well go back into using POTS and paper mail, if Evolution is
meant to be the state of the art.
Being free of charge is no USP or catcher nowadays, when OSX costs about $50
and Windows 7 is delivered as factory default on most machines nowadays.
If we removed Gimp from Lucid, i suggest remove Gwibber from Lucid+1 also.
It was nice to see it in action, but i can't take the Ubuntu social desktop
seriously as long as Gwibber's obstructive scrollbars are bigger than the
information in between them. Not yet.

On Fri, May 14, 2010 at 18:52, David Hamm davidth...@gmail.com wrote:


 https://docs.google.com/drawings/edit?id=1jC_EV0X2GuZh15xN9QvmUzquK7EjqVkCbqgXbgEsYOYhl=en

 Maybe this would be better then wave, :p wave is still to young.


yeah, nice one. This would then be in the Me / Social Menu, right?

We've been tossing Empathy's Contact List all across the DE from A to B to
C with no successful integration of human contacts into our DE until even
today!
i can't even dock the Contact List to anything, even if i wanted to. Who can
help me with enabling docking and snapping for this window?

Now, whatever happened to Ubuntu, which means humanity after all, if i
may inquire?
For Maverick, we are supposed to integrate human beings better, as Jono
suggested in his blogpost here: [2]..
Upstream is doing this quite well by finally introducing Folks [3] to
Telepathy (hooray!!), after adopting the promising People project was
cancelled IIRC, and meta contact capable Soylent didn't quite happen
either...

SOCIAL FROM THE START
There's a blueprint for a global social API for Maverick [4] as
Jan-Christoph hinted a while ago ;)
Perhaps this blueprint will be ready for a review after this discussion
reveals some low hanging fruit..
This problem is much older than the meta contacts bug on empathy [5]..

Points in this topic that i think deserve more opinions:

* unified contacts for all social apps (Telepathy: Folks)
* menu or interactive list showing those online (Folks in Empathy)
* show offline contacts, if i pinned them favourites (pin like in Tomboy
menu)
* show offline contacts that match my FAYT search on top of list (perhaps
with a seperator before the actual list)
* show thumbs for real people
* offer single click menu with send email, chat, visit [URL/blog],
send SMS, call
* allow dragging of multiple contacts
* drag contacts onto the desktop to create vcards
* allow docking/snapping and autohiding Contact List to the right desktop
edge
* drop Gwibber from Ubuntu 10.10, as we dropped Gimp from 10.04
* ignore Mark's use case, he might need an extra AI to handle his 2000+

Re: [Ayatana] Instant-messaging as an indicator menu

2010-05-15 Thread Tyler Brainerd
I agree. Both gwibber and evolution suck hard, and the basic integration is
still weak across the desktop. I have to keep a browser open pointed at my
email pages anyway, because the messenging menu and evolution are
inconsistent at best. I have to manually check twitter because gwibber never
tells me about new posts properly. the whole thing is still messy and needs
to actually integrate, not just come with panel launchers.

On Sat, May 15, 2010 at 2:36 PM, Frederik Nnaji frederik.nn...@gmail.comwrote:

 The Social Desktop, nicely wrapped in a consistent and comfortable UI, will
 bring the Meercat into many a household! ;)

 Humans share their knowledge and skills in the Ubuntu community, why don't
 apps also behave like that? Something i can't stop reasoning about..
 Yeah, we need to untangle Ubuntu's social desktop apps, give them an
 intuitive and accessible structuring, make the social apps talk to each
 other.
 Some more userland IPC for a change would help enormously, and we have most
 of the code for this out there already.

 Me Menu, Messaging Menu and Contact List, all accessible by 1 click from
 Ubuntu's Gnome Panel, are not working together as one, and they are not
 behaving consistently with the other giant baby newcomer Gwibber, nor is
 anyone really saving up my facebook/google talk contacts in the cloud
 (Ubuntu One).
 why not?
 a) Me Menu duplicates availability setting from Contact List: confusion.
 b) Me Menu configures services that live in the Messaging Menu: confusion.
 c) Click-Hold-Aim-Release is no improvement to Click (show
 contacts/Messaging Menu): a step backwards
 d) Contact List doesn't deserve its name, it's only an availability status
 notifier with IM nicks at the moment.
 e) gwibber's behaviour is inferior to all popular Website AJAX
 interactivity (clicking like or adding comments reloads the whole
 stream-page and breaks the user's interaction focus by jumping to the top of
 the stream...)

 We should *at least* match the interactivity comfort of facebook.com and
 mail.google.com..
 Perhaps some dedicated usage of WebKit with a minimal local LAMP and some
 accessible scripts and some CSS featuring RGBA in a WebKit based UI would
 make a more powerful interface than the Erlang experiments currently
 happening in Gwibber.. who knows anything about that?
 * is it smart to implement AJAX-based social website UI behaviour using
 Erlang?
 * does your facebook.com stream jump to the top when you commit a comment?
 * does your jabber webclient on mail.google.com reload the whole page for
 every IM?
 * does your bike release the clutch when you flip the light switch?
 * does your mobile phone reboot its UI for each button pressed?

 As long as Gwibber sucks, i will use the respective webpages instead.
 I'm not alone in this observation, prove me wrong.
 Same goes for Evolution, which is a landmark jack-of-all-trades suite of
 Unusability [1].
 We might as well go back into using POTS and paper mail, if Evolution is
 meant to be the state of the art.
 Being free of charge is no USP or catcher nowadays, when OSX costs about
 $50 and Windows 7 is delivered as factory default on most machines nowadays.
 If we removed Gimp from Lucid, i suggest remove Gwibber from Lucid+1 also.
 It was nice to see it in action, but i can't take the Ubuntu social desktop
 seriously as long as Gwibber's obstructive scrollbars are bigger than the
 information in between them. Not yet.

 On Fri, May 14, 2010 at 18:52, David Hamm davidth...@gmail.com wrote:


 https://docs.google.com/drawings/edit?id=1jC_EV0X2GuZh15xN9QvmUzquK7EjqVkCbqgXbgEsYOYhl=en

 Maybe this would be better then wave, :p wave is still to young.


 yeah, nice one. This would then be in the Me / Social Menu, right?

 We've been tossing Empathy's Contact List all across the DE from A to B
 to C with no successful integration of human contacts into our DE until even
 today!
 i can't even dock the Contact List to anything, even if i wanted to. Who
 can help me with enabling docking and snapping for this window?

 Now, whatever happened to Ubuntu, which means humanity after all, if i
 may inquire?
 For Maverick, we are supposed to integrate human beings better, as Jono
 suggested in his blogpost here: [2]..
 Upstream is doing this quite well by finally introducing Folks [3] to
 Telepathy (hooray!!), after adopting the promising People project was
 cancelled IIRC, and meta contact capable Soylent didn't quite happen
 either...

 SOCIAL FROM THE START
 There's a blueprint for a global social API for Maverick [4] as
 Jan-Christoph hinted a while ago ;)
 Perhaps this blueprint will be ready for a review after this discussion
 reveals some low hanging fruit..
 This problem is much older than the meta contacts bug on empathy [5]..

 Points in this topic that i think deserve more opinions:

 * unified contacts for all social apps (Telepathy: Folks)
 * menu or interactive list showing those online (Folks in Empathy)
 * show offline contacts, if i 

Re: [Ayatana] Criticism of Client Side Window Decorations

2010-05-15 Thread Dylan McCall
On Fri, 2010-05-14 at 21:05 +0530, Akshat Jain wrote:
 Link Copy-Pasta
 http://blog.martin-graesslin.com/blog/2010/05/why-you-should-not-use-client-side-window-decorations/
 http://blog.martin-graesslin.com/blog/2010/05/follow-up-on-client-side-decorations/
 
 This guy named Martin Gräßlin is a hardcore KWin fan I think,looks
 like if he were a senior GNOME developer he would have replaced
 Metacity with KWin.Lol
 
 Design Team-?
 ___
 Mailing list: https://launchpad.net/~ayatana
 Post to : ayatana@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~ayatana
 More help   : https://help.launchpad.net/ListHelp


I was really looking forward to client-side decorations, but Martin has
pretty thoroughly changed my tune. I think there's a different problem
that needs to be solved: there is a doomed effort right now to make
window decorations feel like part of window clients even though the two
know nothing of each other. For example, window decorations are fixed to
the edges of the client area no matter what, as if they need to be. In
some themes (like Lucid's Light themes) they apply some quirky tricks to
blend with the client area.

Perhaps more problems can be solved if window borders Stop Intruding on
window clients.

A few loosely related thoughts spring to mind:

  * It would be really super if someone would implement unobtrusive
window manager controls that appear (with lots of alpha channel
goodness) when the mouse reaches particular hotspots at the edge
of the client area, maybe after being inside the client area.
That would lead to a valid solution to Bug #160311
(https://launchpad.net/bugs/160311), among other things, and
it's a requirement for client-side decorations to work at all
well.
  * Why does a title bar have to be at the top of its respective
window? This causes a serious usability problem when a window is
Alt+Dragged above the screen: only the bottom part is visible,
so it's impossible to drag it back unless you know how it got
there. I actually am quite surprised this isn't a common issue.
Why can't the title bar detach from the window and stay visible
regardless of where the client has gone?
  * A window “title bar”, with goodies like the Close and Minimize
buttons (and soon, I guess, Windicators!), serves a distinct
role: it helps the user organize a window client quickly and
easily. These are proxies; helpers; tools. I think “title bar”
is a misnomer.
  * A window client, in the Linux desktop, cannot trust the window
manager to do anything. As a result, we have a unique
arrangement where window decorations rarely introduce new
functionality that can't be achieved through the client. (Beyond
managing windows themselves, of course. The client can't be
reliably dragged to move it around. Now THERE is something that
could be patched in all the toolkits. If we want touch support,
it's a necessity).
  * Items in the window list mimic window title bars. (Title, icon -
that's how they typically look!). Windicators could fit in there
really neatly. We're moving to a world where the window manager
handles more of the surrounding desktop (eg: gnome-shell), so
these things could get cool.



Thanks,
Dylan


___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp


Re: [Ayatana] Should Indicator-Session be put in the upper left corner

2010-05-15 Thread Tyler Brainerd
ne ither windows or apple has such a dedicated app to the session. both have
it underneath the primary menu, and both have it on the left.

I agree. I was actually discussing this very thing a few days ago in the
comments of some blog.



On Sat, May 15, 2010 at 7:55 AM, Frederik Nnaji frederik.nn...@gmail.comwrote:

 On Sat, May 15, 2010 at 16:48, Mark Curtis merkin...@hotmail.com wrote:

  The reasoning behind the controversial button movement to the left was
 that starting/quitting would be on the left, and status would be on the
 right.

 Given that reasoning, for consistency sake shouldn't indicator-session go
 on the far left since it is for starting/quitting an entire session?


 aha!
 looks interesting to me!
 apple does this AFAIK

 i'm not interested in copying windows or apple behaviour on the long run,
 but there's nothing wrong with doing the right thing, once you started down
 that path already..

 ___
 Mailing list: https://launchpad.net/~ayatana
 Post to : ayatana@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~ayatana
 More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp


Re: [Ayatana] Criticism of Client Side Window Decorations

2010-05-15 Thread Frederik Nnaji
errrmm ... whow, Dylan!

On Sat, May 15, 2010 at 23:59, Dylan McCall dylanmcc...@gmail.com wrote:

 I was really looking forward to client-side decorations, but Martin has
 pretty thoroughly changed my tune. I think there's a different problem
 that needs to be solved: there is a doomed effort right now to make
 window decorations feel like part of window clients even though the two
 know nothing of each other. For example, window decorations are fixed to
 the edges of the client area no matter what, as if they need to be. In
 some themes (like Lucid's Light themes) they apply some quirky tricks to
 blend with the client area.

 Perhaps more problems can be solved if window borders Stop Intruding on
 window clients.

 A few loosely related thoughts spring to mind:

  * It would be really super if someone would implement unobtrusive
window manager controls that appear (with lots of alpha channel
goodness) when the mouse reaches particular hotspots at the edge
of the client area, maybe after being inside the client area.
That would lead to a valid solution to Bug #160311
(https://launchpad.net/bugs/160311), among other things, and
it's a requirement for client-side decorations to work at all
well.
  * Why does a title bar have to be at the top of its respective
window? This causes a serious usability problem when a window is
Alt+Dragged above the screen: only the bottom part is visible,
so it's impossible to drag it back unless you know how it got
there. I actually am quite surprised this isn't a common issue.
Why can't the title bar detach from the window and stay visible
regardless of where the client has gone?
  * A window “title bar”, with goodies like the Close and Minimize
buttons (and soon, I guess, Windicators!), serves a distinct
role: it helps the user organize a window client quickly and
easily. These are proxies; helpers; tools. I think “title bar”
is a misnomer.
  * A window client, in the Linux desktop, cannot trust the window
manager to do anything. As a result, we have a unique
arrangement where window decorations rarely introduce new
functionality that can't be achieved through the client. (Beyond
managing windows themselves, of course. The client can't be
reliably dragged to move it around. Now THERE is something that
could be patched in all the toolkits. If we want touch support,
it's a necessity).
  * Items in the window list mimic window title bars. (Title, icon -
that's how they typically look!). Windicators could fit in there
really neatly. We're moving to a world where the window manager
handles more of the surrounding desktop (eg: gnome-shell), so
these things could get cool.


you saved many people a lot of saliva here.
this is beautiful, much respect for your thoughts on an overlayed dynamic
titlebar !!!
in 2010 it's about time we think about these decorations thoroughly.

so much space just wasted, i think application designers will know
themselves where to place the name of their app, if they made it well and
are proud of it. we don't really need a title bar for that.

the window controls are also devoid of utility as you pointed out for the
ALT-drag case..
this is yet another exciting thread ;)

let's see what phantasies arise next..
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp


Re: [Ayatana] Criticism of Client Side Window Decorations

2010-05-15 Thread Tyler Brainerd
 Why does a title bar have to be at the top of its respective
   window? This causes a serious usability problem when a window is
   Alt+Dragged above the screen: only the bottom part is visible,
   so it's impossible to drag it back unless you know how it got
   there. I actually am quite surprised this isn't a common issue.
   Why can't the title bar detach from the window and stay visible
   regardless of where the client has gone?

Especially considering we already have 'rolling windows' available, is there
way a way to allow windows to partially roll when the title bar is forced to
the top of the screen and continued to move upwards?


On Sat, May 15, 2010 at 2:59 PM, Dylan McCall dylanmcc...@gmail.com wrote:

 On Fri, 2010-05-14 at 21:05 +0530, Akshat Jain wrote:
  Link Copy-Pasta
 
 http://blog.martin-graesslin.com/blog/2010/05/why-you-should-not-use-client-side-window-decorations/
 
 http://blog.martin-graesslin.com/blog/2010/05/follow-up-on-client-side-decorations/
 
  This guy named Martin Gräßlin is a hardcore KWin fan I think,looks
  like if he were a senior GNOME developer he would have replaced
  Metacity with KWin.Lol
 
  Design Team-?
  ___
  Mailing list: https://launchpad.net/~ayatana
  Post to : ayatana@lists.launchpad.net
  Unsubscribe : https://launchpad.net/~ayatana
  More help   : https://help.launchpad.net/ListHelp


 I was really looking forward to client-side decorations, but Martin has
 pretty thoroughly changed my tune. I think there's a different problem
 that needs to be solved: there is a doomed effort right now to make
 window decorations feel like part of window clients even though the two
 know nothing of each other. For example, window decorations are fixed to
 the edges of the client area no matter what, as if they need to be. In
 some themes (like Lucid's Light themes) they apply some quirky tricks to
 blend with the client area.

 Perhaps more problems can be solved if window borders Stop Intruding on
 window clients.

 A few loosely related thoughts spring to mind:

  * It would be really super if someone would implement unobtrusive
window manager controls that appear (with lots of alpha channel
goodness) when the mouse reaches particular hotspots at the edge
of the client area, maybe after being inside the client area.
That would lead to a valid solution to Bug #160311
(https://launchpad.net/bugs/160311), among other things, and
it's a requirement for client-side decorations to work at all
well.
  * Why does a title bar have to be at the top of its respective
window? This causes a serious usability problem when a window is
Alt+Dragged above the screen: only the bottom part is visible,
so it's impossible to drag it back unless you know how it got
there. I actually am quite surprised this isn't a common issue.
Why can't the title bar detach from the window and stay visible
regardless of where the client has gone?
  * A window “title bar”, with goodies like the Close and Minimize
buttons (and soon, I guess, Windicators!), serves a distinct
role: it helps the user organize a window client quickly and
easily. These are proxies; helpers; tools. I think “title bar”
is a misnomer.
  * A window client, in the Linux desktop, cannot trust the window
manager to do anything. As a result, we have a unique
arrangement where window decorations rarely introduce new
functionality that can't be achieved through the client. (Beyond
managing windows themselves, of course. The client can't be
reliably dragged to move it around. Now THERE is something that
could be patched in all the toolkits. If we want touch support,
it's a necessity).
  * Items in the window list mimic window title bars. (Title, icon -
that's how they typically look!). Windicators could fit in there
really neatly. We're moving to a world where the window manager
handles more of the surrounding desktop (eg: gnome-shell), so
these things could get cool.



 Thanks,
 Dylan


 ___
 Mailing list: https://launchpad.net/~ayatana
 Post to : ayatana@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~ayatana
 More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp


[Ayatana] Tabs

2010-05-15 Thread Tyler Brainerd
I'll try to be brief. Currently, alt tab moves between windows. Ctrl-Tab
moves between tabs in some programs, not all. Special (Win Key) and tab does
nothing.
It would kinda make more sense if we did this: Ctrl-Tab moves between tabs,
system wide. Special and tab moves between windows (the old standard
alt-tab) and alt tab moves between workspaces. General to specific, vice
versa.

I know it would suck to change up the alt-tab control, but we've got three
keys which are (generally) in a row, and we use only two, and could make all
three useful and make sense.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp


Re: [Ayatana] Tabs

2010-05-15 Thread Anzan Hoshin Roshi
On 15 May 2010 18:52, Tyler Brainerd tylerbrain...@gmail.com wrote:

 Er. Shoot. Thinkpads don't have them at all?



No. Perhaps the newest onesfrom Lenovo might though the travel boards I
bought last year still did not. After OS2, IBM wouldn't give them the
satisfaction of a Windows key.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp


Re: [Ayatana] Intuitive

2010-05-15 Thread Frederik Nnaji
Grüß Gott, Thorsten ;)


 2010/5/14 Thorsten Wilms t...@freenet.de:
   This is totally unrealistic. Humans can't even walk or talk without
  learning.
 
  Some say the nipple would be the only intuitive interface. I've been
  told that not even breast feeding just works on first try ...


you're a real entertainer ;)

In all your disregard for the term, let me suggest you start seeing it as a
romantic metaphor.
I think we all benefit from this little excourse into official nomenclature,
thanks ;)

In future i will try not to use this word carelessly but still intuitively.
Intuition is the fastest way someone can consciously make a correct
decision.
Since this is valid for humans, the AI guys will definitely pick up on this
for machines also, now that we have Memristors and Virtual Swarm
Intelligence out there..
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp


[Ayatana] Rethink the noninteractive Live CD default boot?

2010-05-15 Thread Lance
I originally posted this as a question at Ayatana:

https://answers.launchpad.net/ayatana-ubuntu/+question/110648

But thought I'd try this approach, please be kind.

As I found out iso-testing prior to Lucid Beta 1 
the Live CD now requires user interaction to display menu options:

https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/539172

At first this seemed fine but having used this more and more I find 
it to be only annoying. Consider the following:

1) It creates confusion for those who are new to Ubuntu. I've seen 
this a lot at the forums.

2) We've only moved the interactive part to a later point in the boot
 cycle because you still must choose whether to just run Ubuntu or 
install Ubuntu, so this really did not result in a faster boot.

3) With that move all we've done is remove the options to check 
CD for defects, adjust boot parameters, etc. without an otherwise 
unnecessary reboot which only results in frustration.

4) Even after learning of the new boot behavior the option to press
 any key passes so quickly that even an unplanned phone call or some 
other interruption can cause me to miss the opportunity, and increasing 
that time out would only increase the boot time.

I'm curious what others think about this. We could possibly plan 
changes for the first point release of Lucid and I'd think certainly for 
Maverick, 
and no time like the present ;^)

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp


Re: [Ayatana] Tabs

2010-05-15 Thread Frederik Nnaji
On Sun, May 16, 2010 at 01:02, Anzan Hoshin Roshi 
anzanhoshinro...@gmail.com wrote:



 On 15 May 2010 18:52, Tyler Brainerd tylerbrain...@gmail.com wrote:

 Er. Shoot. Thinkpads don't have them at all?



 No. Perhaps the newest onesfrom Lenovo might though the travel boards I
 bought last year still did not. After OS2, IBM wouldn't give them the
 satisfaction of a Windows key.


oh how i love that ;)
let's call it superkey.
now i am beginning to see where all usability issues are born:
hardware inconsistency.

okay, so let's just give the special workspaces the special case of
Superkey-Tab to switch, no?
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp


Re: [Ayatana] Tabs

2010-05-15 Thread Frederik Nnaji
hi Anzan

On Sun, May 16, 2010 at 02:33, Anzan Hoshin Roshi 
anzanhoshinro...@gmail.com wrote:

 okay, so let's just give the special workspaces the special case of
 Superkey-Tab to switch, no?



 No, there's no super key. Just Fn Ctrl Alt then spacebar. I have this on
 an R40, T40, two X41s abd on and on the travel Thinkpad keyboards (just the
 keyboard, not a laptop, very cool) used on five desktop boxes.


oh well i know that, my friend has a Thinkpad, i loved it for not having the
branded key on it ;)
i'm saying, most computer keyboards, apple or non-apple, have a superkey.

instead of screwing with user habits and altering the mapping of ALT-TAB,
why not simply map workspaces to SUPER-TAB..
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp


Re: [Ayatana] Tabs

2010-05-15 Thread Luke Morton
On Sat, 2010-05-15 at 15:37 -0700, Tyler Brainerd wrote:
 I'll try to be brief. Currently, alt tab moves between windows.
 Ctrl-Tab moves between tabs in some programs, not all. Special (Win
 Key) and tab does nothing.
 It would kinda make more sense if we did this: Ctrl-Tab moves between
 tabs, system wide. Special and tab moves between windows (the old
 standard alt-tab) and alt tab moves between workspaces. General to
 specific, vice versa.
 
 I know it would suck to change up the alt-tab control, but we've got
 three keys which are (generally) in a row, and we use only two, and
 could make all three useful and make sense.
 

We can't really rely on the super key (as others have mentioned).
However, since switching between desktops is already available through
to Ctrl + Alt + [Arrow], we could add Super + Tab as a  way to cycle
through desktops in the same way Alt + Tab cycles through windows.

As for Ctrl + Tab, the only app I know of that supports that is Firefox.
Also, Ctrl + Tab has other uses (see link below).

This does raise an interesting point though: we should probably aim for
consistency for handling tabs (and shortcut keys in general). My quick
test yields a few different approaches:

Terminal: 
Focus: Ctrl + PgUp and Ctrl + PgDown
Move: Ctrl + Shift + PgUp and Ctrl + Shift + PgDown
Create: Ctrl + Shift + T
Close: Ctrl + Shift + W
New window: Ctrl + Shift + N

Gedit: 
Focus: Ctrl + Alt + PgUp and Ctrl + Alt + PgDown
Move: (can't find a way to do this)
Create: Ctrl + N
Close: Ctrl + W
Close all: Ctrl + Shift + W
New window: (can't find a way to do this)
Close window: Ctrl + Q

Firefox: 
Focus: Ctrl + PgUp and Ctrl + PgDown or Ctrl + Tab and Ctrl + Shift +
Tab
Move: (can't find a way to do this)
Create: Ctrl + T
Close: Ctrl + W
New window: Ctrl + N
Close window: Ctrl + Shift + W
Close application: Ctrl + Q

It would be nice to standardise these (and other apps). There's already
a relevant section in the GNOME HIG:
http://library.gnome.org/devel/hig-book/stable/input-keyboard.html.en
but it doesn't say anything about tabs (although it does mention
documents).


___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp


Re: [Ayatana] Criticism of Client Side Window Decorations

2010-05-15 Thread Sam Spilsbury
On Sat, May 15, 2010 at 9:59 PM, Dylan McCall dylanmcc...@gmail.com wrote:
 On Fri, 2010-05-14 at 21:05 +0530, Akshat Jain wrote:
 Link Copy-Pasta
 http://blog.martin-graesslin.com/blog/2010/05/why-you-should-not-use-client-side-window-decorations/
 http://blog.martin-graesslin.com/blog/2010/05/follow-up-on-client-side-decorations/

 This guy named Martin Gräßlin is a hardcore KWin fan I think,looks
 like if he were a senior GNOME developer he would have replaced
 Metacity with KWin.Lol

 Design Team-?
 ___
 Mailing list: https://launchpad.net/~ayatana
 Post to     : ayatana@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~ayatana
 More help   : https://help.launchpad.net/ListHelp


 I was really looking forward to client-side decorations, but Martin has
 pretty thoroughly changed my tune. I think there's a different problem
 that needs to be solved: there is a doomed effort right now to make
 window decorations feel like part of window clients even though the two
 know nothing of each other. For example, window decorations are fixed to
 the edges of the client area no matter what, as if they need to be. In
 some themes (like Lucid's Light themes) they apply some quirky tricks to
 blend with the client area.

 Perhaps more problems can be solved if window borders Stop Intruding on
 window clients.

 A few loosely related thoughts spring to mind:

      * It would be really super if someone would implement unobtrusive
        window manager controls that appear (with lots of alpha channel
        goodness) when the mouse reaches particular hotspots at the edge
        of the client area, maybe after being inside the client area.
        That would lead to a valid solution to Bug #160311
        (https://launchpad.net/bugs/160311), among other things, and
        it's a requirement for client-side decorations to work at all
        well.

So the window controls are essentially invisible unless you play a
hide an seek game with your mouse? I don't understand why you'd want
this - and it requires some form of meaningful acceleration within
apps, something that I don't think everyone has.

      * Why does a title bar have to be at the top of its respective
        window? This causes a serious usability problem when a window is
        Alt+Dragged above the screen: only the bottom part is visible,
        so it's impossible to drag it back unless you know how it got
        there. I actually am quite surprised this isn't a common issue.
        Why can't the title bar detach from the window and stay visible
        regardless of where the client has gone?

You can do this with reparenting decorations, or even decorations
which draw separately as a texture on screen (like what you already
have with compiz!). You cannot do this with client side decorations.
Some window managers may reparent the window and not draw decorations
for it. This means that the window can never reliably tell it's
position.

      * A window “title bar”, with goodies like the Close and Minimize
        buttons (and soon, I guess, Windicators!), serves a distinct
        role: it helps the user organize a window client quickly and
        easily. These are proxies; helpers; tools. I think “title bar”
        is a misnomer.
      * A window client, in the Linux desktop, cannot trust the window
        manager to do anything. As a result, we have a unique
        arrangement where window decorations rarely introduce new
        functionality that can't be achieved through the client. (Beyond
        managing windows themselves, of course. The client can't be
        reliably dragged to move it around. Now THERE is something that
        could be patched in all the toolkits. If we want touch support,
        it's a necessity).

The window manager absolutely depends on the client to not be stupid
and to obey rules (unless you want to make every client
_NET_WM_OVERRIDE_REDIRECT). If a client can't be dragged to move it
around, it is because the window manager strictly forbids this, and if
a window manager strictly forbids this, it is because the user told it
to. You should never override window management rules in the window
manager.

As for window decorations adding new functionality, as Martin and I
have already said, you can use DBus to specify what indicators there
should be, and the window manager will implement it meaningfully. If
you're talking about new functionality to /manage/ the window, then
again, putting that in the client is a big no-no, see point #2.

      * Items in the window list mimic window title bars. (Title, icon -
        that's how they typically look!). Windicators could fit in there
        really neatly. We're moving to a world where the window manager
        handles more of the surrounding desktop (eg: gnome-shell), so
        these things could get cool.

If you're moving to a world where global contexts are the norm, then
why not just put windicators there? 

Re: [Ayatana] Tabs

2010-05-15 Thread Frederik Nnaji
On Sun, May 16, 2010 at 03:15, Luke Morton luke.mor...@internode.on.netwrote:

 We can't really rely on the super key (as others have mentioned).


nobody said rely on
some internet kiosk keyboards have no ALT or CTRL even..
most keyboards profide super key, even apple.
let's work with that it for now..

It would be nice to standardise these (and other apps). There's already
 a relevant section in the GNOME HIG:
 http://library.gnome.org/devel/hig-book/stable/input-keyboard.html.en
 but it doesn't say anything about tabs (although it does mention
 documents).


as USL folks with NASA already discovered, consistency is key in designing
an easily learnable interface.

let the guys at GNOME Usability know about your thought, they will surely
include a section in the new HIG Book 3.0
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp


Re: [Ayatana] Tabs

2010-05-15 Thread Luke Morton
On Sun, 2010-05-16 at 04:06 +0200, Frederik Nnaji wrote:
 On Sun, May 16, 2010 at 03:15, Luke Morton
 luke.mor...@internode.on.net wrote:
 
 We can't really rely on the super key (as others have
 mentioned).

 nobody said rely on

I did :) And I just meant we can't count on it being there so attaching
core functionality like task switching to it isn't a great idea.

 some internet kiosk keyboards have no ALT or CTRL even..
 most keyboards profide super key, even apple.
 let's work with that it for now..

Interesting. I hadn't considered those cases.

 It would be nice to standardise these (and other apps).
 There's already
 a relevant section in the GNOME HIG:
 http://library.gnome.org/devel/hig-book/stable/input-keyboard.html.en
 but it doesn't say anything about tabs (although it does
 mention
 documents).
 
 
 as USL folks with NASA already discovered, consistency is key in
 designing an easily learnable interface.
 
 let the guys at GNOME Usability know about your thought, they will
 surely include a section in the new HIG Book 3.0

Will do. Thanks.


___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp


Re: [Ayatana] Criticism of Client Side Window Decorations

2010-05-15 Thread Scott Kitterman


I've not been keeping a close eye on this discussion (so it may have
already been mentioned) but Mark Shuttleworth mentioned that CSD aren't
a requirement for windicators:

Yes, it's been brought up already. He said the same thing this week at the 
Ubuntu Developer Summit (UDS) in Brussels. This thread is about CSD generally 
and concerns about its impact on desktop consistency and not at all tied to 
windicators.

Scott K
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp


Re: [Ayatana] Criticism of Client Side Window Decorations

2010-05-15 Thread Frederik Nnaji
hi sam

On Sun, May 16, 2010 at 03:41, Sam Spilsbury smspil...@gmail.com wrote:

 So the window controls are essentially invisible unless you play a
 hide an seek game with your mouse? I don't understand why you'd want
 this - and it requires some form of meaningful acceleration within
 apps, something that I don't think everyone has.


AIUI it has something to do with mouse pointer position relative to the
window border..
I don't understand where acceleration would fit into this context..
You have a point with your cat and mouse game though..


 You cannot do this with client side decorations.


why not? because of the imprecision of the absolute position information?
that's a WM bug, has nothing to do with CSD.


 The window manager absolutely depends on the client to not be stupid
 and to obey rules


Doesn't this mean that we can entrust the client with more then?
You are arguing against your own position here.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp


Re: [Ayatana] Criticism of Client Side Window Decorations

2010-05-15 Thread Sam Spilsbury
On Sun, May 16, 2010 at 10:46 AM, Frederik Nnaji
frederik.nn...@gmail.com wrote:
 hi sam

 On Sun, May 16, 2010 at 03:41, Sam Spilsbury smspil...@gmail.com wrote:

 So the window controls are essentially invisible unless you play a
 hide an seek game with your mouse? I don't understand why you'd want
 this - and it requires some form of meaningful acceleration within
 apps, something that I don't think everyone has.

 AIUI it has something to do with mouse pointer position relative to the
 window border..
 I don't understand where acceleration would fit into this context..

If you want to make the fading smooth, then you will most likely need
some form of graphical accelleration, whether that be EXA, Glitz or
G3D. There is no way to guaruntee that everyone has this.

 You have a point with your cat and mouse game though..


 You cannot do this with client side decorations.

 why not? because of the imprecision of the absolute position information?
 that's a WM bug, has nothing to do with CSD.


Some window managers have to fake out position information to make
this kind of thing work. Usually this is because they are reparenting
the window (metacity, kwin) or they are a compositing window manager
with input redirection and have to place the window offscreen to
redirect input to it on-screen (Metisse, future versions of compiz).

In any case, there are methods of a client determining it's position
on the root window, however this is inaccurate at best and something
the client shouldn't need to be concerned with.

If you wanted to do separated titlebar handles, there is a lot of work
that needs to go into that, namely the client drawing titlebars in a
separate window and either reparenting that window into itself or
drawing it separately. Which kind of begs the question - why not just
let the window manager do that because it already does. If you let the
window manager do this, then you can guaruntee that the titlebar will
be consistent with the rules the window manager has defined and client
won't all just do their own thing when their titlebar is off-screen.


 The window manager absolutely depends on the client to not be stupid
 and to obey rules

 Doesn't this mean that we can entrust the client with more then?
 You are arguing against your own position here.

When you have client side decorations, you give more chances for the
client to be stupid and introduce it's own window management
paradigms, drawing the buttons the window manager does not expect to
be drawn, or in extreme cases resizing or moving windows in special
ways when they are grabbed by the titlebar.

Regards,

Sam


-- 
Sam Spilsbury

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp