Re: [Ayatana] Application Indicators improvement suggestion - optional text with icon

[Jonathan Meek]

Yes, but for the date and time indicator it is necessary to have text. You
can't hope to convey the time in an icon that small.

In that case, text becomes necessary to convey in the information
accurately. Introducing it in other places will add clutter to the setup and
start a possible branch of applications that decide they want text in their
indicator and possibly invite abuse.


On Thu, Jul 8, 2010 at 9:03 AM, Mark Curtis  wrote:

>  I too hope that the weather indicator applet would have the temp.
> It would seem a bit contradictory to say an indicator (like weather) can't
> have numbers when Maverick introduces the Time and Date applet
>
>
___
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] Application Indicators improvement suggestion - optional text with icon

[Jonathan Meek]

It accurately portrays the condition... Just like how the date/time
indicator accurately portrays the time, but the date is hidden away in the
menu. A single click and you can find out the more in-depth information as
needed.

On Thu, Jul 8, 2010 at 4:36 PM, Mark Curtis  wrote:

>  Do you think for the weather indicator, icon-only can "convey the
> information accurately"? I don't.
>
> It could show the sunny icon on both a day where it is 30F or 90F, so
> icon-only in that case isn't very accurate at all.
>
>
___
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] "fileless" paradigm (was: File menu)

[Jonathan Meek]

Isn't that essentially a folder though? A gathering of potentially related
files (provided it was organized correctly)

On Sat, Nov 13, 2010 at 4:05 PM, cmaglothin  wrote:

> To combat your argument that you need folders to keep organized, why not
> just supliment the idea of sorting by type with the adding of "projects."
> Not only could you search by filetype but you could link together files that
> are related in topic and have the "projects" searchable or tagged by their
> keyword.
>
> On Nov 13, 2010 2:55 PM, "David Stevenson"  wrote:
>
> On 13/11/10 19:00, frederik.nn...@gmail.com wrote:
> > On Fri, Nov 12, 2010 at 23:39, Appi 
> snip
>
> > this is just an example...
> > please name the issues you see, i don't see any! It's just only
> > imp...
>
> Well looking on my system I have a directory for a charity I am a
> director of, docs, photos & spreadsheets. A directory of a software
> project I worked on, docs, source & executables. One for the
> waterskiing, mostly videos, but some docs and saved web pages.
> I could go on but it would show how chaotic my filing is. So I am open
> to a better way to organise my life, but I do have my doubts that
> linking docs together because they are docs will help.
> David
>
>
>
> ___
> Mailing list: https://launchpad.net/~ayatana
> Post ...
>
>
> ___
> 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] "fileless" paradigm (was: File menu)

[Jonathan Meek]

Yes, what I meant is that C Maglothin's idea of a project idea effectively
is a folder. A collection of files that are generally associated in some
way. In other words, it seemed he was re-naming the same concept. (Wherein a
"project" would just be a folder in our conventional system used now.)

On Sun, Nov 14, 2010 at 5:56 PM, frederik.nn...@gmail.com <
frederik.nn...@gmail.com> wrote:

> Hello Jonathan,
>
> On Sun, Nov 14, 2010 at 03:15, Jonathan Meek wrote:
>
>> Isn't that essentially a folder though? A gathering of potentially related
>> files (provided it was organized correctly)
>>
>
> could you explain your idea a little maybe? The ToFu¹ had me a little
> confused this time..
>
> holla ;)
>
>
> ¹ http://en.wikipedia.org/wiki/Top-posting#Top-posting
>
___
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] "fileless" paradigm

[Jonathan Meek]

I'm not entirely sure this pertains to this particular conversation, but
here is my take on it:

I think that, instead of depending on users to sort their files by
themselves, there should instead be a Home directory where *everything* gets
put Then, when they open Nautilus (or Dash, etc.) they would still be
presented the conventional view of their Home directory, but, the folders
would instead be meta folders, sorting the content on the fly.

So, say a user download three videos and and song and half downloads a
fourth movie. When they went into Nautilus, they would see all the folders
we currently see, but those folders would not technically exist. When the
user clicks on the "Videos" meta-folder, the file browser automatically
sorts the pool of files in the Home folder and displays only video files.
When the user clicks "Music," the song file appears. When they click
"Downloads," all the files they download recently show as well as any
partial downloads.

This would save users having to worry about where they put that file when
they chose to save it or such as it would automatically be sorted to the
most logical place by the system. Then, for more granular control on a
per-file basis, I think dependence on applications would be better. (Using
Banshee to fix up the meta-data for your music, Shotwell for photos, etc.)

Well, that's my idea anyway.

On Tue, Dec 14, 2010 at 8:14 AM, Roberto Guido  wrote:

> On Tue, 2010-12-14 at 13:02 +0100, frederik.nn...@gmail.com wrote:
> > any more variations of this [CONTAINER] - [CONTENT] metaphor?
> >
> Lobotomy - http://lobotomy-project.org/
> The basic concept: container-less browsing, no folders, only "queries"
> against the store (of course managed and assisted by the user interface,
> not everyone can write SQL or SPARQL every time he needs a
> content ;-) ).
> That has been a "conceptual" project of mine for several years, and had
> many evolutions; not many code has been produced, just some document and
> elucubration now scattered all over the web.
>
> > Which concept can serve these needs?
> >
> I think enforcing "search" against "browsing" could be a good
> compromise: we need files just because we cannot imagine any other form
> of contents aggregation (we need to put the bytes somewhere...), but
> today we already have tools to go after folders.
> Desktop indexing is a reality, but barely used by user applications:
> both Tracker and Nepomuk are available and stable, I can count very
> little project running over them. If massively used and integrated in
> the DE, the user could forget folders and just search what needed from
> time to time instead of browsing his own folder hierarchy.
> For example, the "Save" option can just become "save those contents in a
> directory choosen by software, not by me, and index it so I can retrieve
> it". A Spotlight-like application can completely substitute the file
> manager, and we already have specific examples of folder-less contents
> navigation ( http://live.gnome.org/Soylent ).
>
>
>
> p.s.: I was one of the Itsme developers ;-)
> http://itsme.it/news/2009/02/09/we-doubled-our-tech-force/
>
> --
> Roberto -MadBob- Guido
> http://claimid.com/madbob
>
>
>
> ___
> 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] Aero-Expo Reconciliation

[Jonathan Meek]

I've seen many calling for an aero-peek-like function to be brought
into Unity. I would like to say that by and large this is completely
unnecessary given that Unity's already present expo feature.* However
I do see that there is room for improvement in the implementation with
the addition of tab/document recognition. What's the point of the expo
when I have two Firefox windows open with, hypothetically, six tabs in
each. In the current framework, I am required to remember that these
tabs are in window one and those tabs are in window two. The same
scenario can be ascribed to Gedit or even possibly LibreOffice. Expo
puts the focus more on the chrome and less on the content currently.
And isn't that contrary to the point of Unity? (to get more focus on
the content)

I suppose, looking at this, I cannot help seeing a blatant connection
to MPT's recent quitting article about the discrepancies about closing
documents vs. closing the application.


*Some would argue about the hover vs. double click implementation of
these two features. (Though I read today that expo is supposed to
happen on the first click? It's never worked that way for me...) My
personal opinion is that the double click is the better option as it
requires actual user action to bring up these content-covering
features instead of possible inadvertently covering content just
because your pointer happens to be in that area.

___
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] Dash should be in full screen by default in desktop

[Jonathan Meek]

Unity, as of my last checking, only uses fullscreen for above
1280x800. I know this because my lapop uses 1280x720 and switched Dash
to Desktop mode. I agree that it should be made available in CCSM,
though. Make the option readily usable instead of hidden away.

On 3/17/11, Bilal Akhtar  wrote:
> On 03/17/2011 12:54 PM, frederik.nn...@gmail.com wrote:
>> On Thu, Mar 17, 2011 at 05:44, Muhammad Nabil
>> wrote:
>>
>>> Dash in full screen looks better. Thanks.
>>>
>>
>> +1
>>
>> keeping the dash small would make sense, if another object could be
>> displayed beside it on the same level / layer, but that doesn't seem to be
>> the case, so it should rather utilize all the space.
>> transparancy keeps the stuff below visually accessible, that's good to
>> keep
>> a map of the desktop, even when you're in the dash.
>
> I don't think this would be good when the resolution is high (well above
> 1280x800). It would require unnecessary mouse movements.
>
> Unity should detect when the resolution is low, then make dash
> full-screen automatically (IIRC this happens when resolution is 1024x600
> or lower).
>
> Also Unity should add a user-friendly option, either in ccsm or at a
> more accessible location, which makes dash full-screen automatically.
> The current way to set this is to use dconf-editor, and we don't expect
> new users to know this.
>
> Bilal Akhtar.
>
>>
>>
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~ayatana
>> Post to : ayatana@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~ayatana
>> More help   : https://help.launchpad.net/ListHelp
>
>
> --
> Bilal Akhtar - Ubuntu Developer 
> IRC nick: cdbs
>
>

___
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] Dash should be in full screen by default in desktop

[Jonathan Meek]

Alright, that's awesome to hear! However, I should correct some major
typos I put in my other post:

>>Unity, as of my last checking, only uses fullscreen for above 1280x800.

Should be *below* 1280x800.

>>I know this because my lapop uses 1280x720 and switched Dash to Desktop mode.

Should be "my laptop uses 1366x768 and I wanted to switch Dash [...]"

Sorry about those! And keep up the good work on Unity

On 3/17/11, Neil Jagdish Patel  wrote:
> On Thu, 2011-03-17 at 10:42 -0400, Jonathan Meek wrote:
>> Unity, as of my last checking, only uses fullscreen for above
>> 1280x800. I know this because my lapop uses 1280x720 and switched Dash
>> to Desktop mode. I agree that it should be made available in CCSM,
>> though. Make the option readily usable instead of hidden away.
>
> Your absolutely correct, it was a mistake on my part to keep it in
> GSettings instead of ccsm (there was a reason for the decision, but I
> realised afterwards that having it in ccsm would be still possible and
> better).
>
> That'll be fixed for next week's release.
>
> --
> Neil Jagdish Patel | Technical Lead
> Desktop Experience Team
> Canonical
> 27 Floor, Millbank Tower
> London SW1P 4QP
> Ubuntu - Linux for Human Beings
> www.canonical.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
>

___
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] 11.04 Comboboxes

[Jonathan Meek]

So, among the many changes for 11.04, I've noticed one particular change
that irks me to no end: Comboboxes have been switched to now have arrows
pointing both up and down (much as presented on Mac OS X I've been told) but
are still inconsistent about click behavior.

An example: Go to Power Management preferences and click the combobox for
action to take on laptop lid closing, a menu will appear and you can choose
an item at your leisure. Now, go run CCSM and go to the Unity plugin's
settings, click on the combobox for hide behavior and it appears nothing
happens. The two boxes look the same, but for one, you have to seemingly
arbitrarily click and hold the combobox to select items and the other you
don't. An even better example, I see THREE different comboboxes used in the
Software Sources dialog: 1) In the Ubuntu Software tab, a click and hold
combobox. 2)In the Updates tab a combobox that you can type in for some
reason.(The Check for updates one) 3) Below that in the Updates tab as well,
a combobox with the "correct behavior. (The Release upgrade combobox)

I have to hope beyond hope that this isn't the first time this is being
brought up, and hope there is something in the works. But having three
different kinds of the same box in one dialog that is made by Canonical is
mildly disheartening.
___
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] 11.04 Comboboxes

[Jonathan Meek]

You're absolutely right it seems, I apologize. It seems that it's just a bit
too sensitive for my clicking behaviors and would close quickly making me
think that it acted differently. And will subscribe to that bug. Thanks.

On Tue, Apr 26, 2011 at 5:58 AM, Matthew Paul Thomas wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Jonathan Meek wrote on 07/04/11 03:22:
> >...
> > An example: Go to Power Management preferences and click the combobox
> > for action to take on laptop lid closing, a menu will appear and you
> > can choose an item at your leisure. Now, go run CCSM and go to the
> > Unity plugin's settings, click on the combobox for hide behavior and it
> > appears nothing happens. The two boxes look the same, but for one, you
> > have to seemingly arbitrarily click and hold the combobox to select
> > items and the other you don't. An even better example, I see THREE
> > different comboboxes used in the Software Sources dialog: 1) In the
> > Ubuntu Software tab, a click and hold combobox. 2)In the Updates tab a
> > combobox that you can type in for some reason.(The Check for updates
> > one) 3) Below that in the Updates tab as well, a combobox with the
> > "correct behavior. (The Release upgrade combobox)
> >...
>
> A radio menu, or option menu, lets you choose one of several choices,
> and displays the current choice in the closed menu. It's the menu
> equivalent of a set of radio buttons.
>
> A combo box is a combination of a text field and a radio menu, and
> displays the current choice in the text field.
>
> Windows calls a radio menu a "drop-down list", while Mac OS X calls it a
> "pop-up menu". GTK mistakenly calls it a "combo box", and then calls an
> actual combo box a "combo box entry".
>
> In both Ambiance and Radiance, I see no difference in appearance or
> behavior between the Power Management Preferences "When laptop lid is
> closed" menu, the CCSM Unity "Hide Launcher" menu, and the Software
> Sources "Download from" and "Show new distribution releases" menus. If
> you still see a difference, perhaps you could publish a screencast
> somewhere demonstrating it?
>
> The "Check for updates" menu is a combo box, and should not be. Someone
> has just reported this bug. <http://launchpad.net/bugs/750507>
>
> - --
> mpt
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk22l2AACgkQ6PUxNfU6ecqBugCfYdbesX467+JwOU/sXvBm2+aa
> 6HEAoJEmHz5KE9R/FzM5T7yDnVe/+uor
> =sVa5
> -END PGP SIGNATURE-
>
> ___
> 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] 11.04 Comboboxes

[Jonathan Meek]

Or not, it seems that is the wrong bug?

On Tue, Apr 26, 2011 at 5:58 AM, Matthew Paul Thomas wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Jonathan Meek wrote on 07/04/11 03:22:
> >...
> > An example: Go to Power Management preferences and click the combobox
> > for action to take on laptop lid closing, a menu will appear and you
> > can choose an item at your leisure. Now, go run CCSM and go to the
> > Unity plugin's settings, click on the combobox for hide behavior and it
> > appears nothing happens. The two boxes look the same, but for one, you
> > have to seemingly arbitrarily click and hold the combobox to select
> > items and the other you don't. An even better example, I see THREE
> > different comboboxes used in the Software Sources dialog: 1) In the
> > Ubuntu Software tab, a click and hold combobox. 2)In the Updates tab a
> > combobox that you can type in for some reason.(The Check for updates
> > one) 3) Below that in the Updates tab as well, a combobox with the
> > "correct behavior. (The Release upgrade combobox)
> >...
>
> A radio menu, or option menu, lets you choose one of several choices,
> and displays the current choice in the closed menu. It's the menu
> equivalent of a set of radio buttons.
>
> A combo box is a combination of a text field and a radio menu, and
> displays the current choice in the text field.
>
> Windows calls a radio menu a "drop-down list", while Mac OS X calls it a
> "pop-up menu". GTK mistakenly calls it a "combo box", and then calls an
> actual combo box a "combo box entry".
>
> In both Ambiance and Radiance, I see no difference in appearance or
> behavior between the Power Management Preferences "When laptop lid is
> closed" menu, the CCSM Unity "Hide Launcher" menu, and the Software
> Sources "Download from" and "Show new distribution releases" menus. If
> you still see a difference, perhaps you could publish a screencast
> somewhere demonstrating it?
>
> The "Check for updates" menu is a combo box, and should not be. Someone
> has just reported this bug. <http://launchpad.net/bugs/750507>
>
> - --
> mpt
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk22l2AACgkQ6PUxNfU6ecqBugCfYdbesX467+JwOU/sXvBm2+aa
> 6HEAoJEmHz5KE9R/FzM5T7yDnVe/+uor
> =sVa5
> -END PGP SIGNATURE-
>
> ___
> 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] Oneiric Dark Toolbars/Menubar Issues

[Jonathan Meek]

I recently say the post on OMG!Ubuntu! about the possibility of dark
toolbars being included for Oneiric and this sparked an interesting debate
among someone I know who I asked to draft his thoughts on the issue for post
to the Ayatana list for discussion. Here it is:


PROBLEM:
The management of maximised windows in Unity is principally flawed and could
potentially cause confusion.
This problem arises due to the location of the toolbars of maximised
windows, and the global menu in the Unity panel.
Consider the screenshot at
http://cdn.omgubuntu.co.uk/wp-content/uploads/2011/07/2011-07-19-150134_1366x768_scrot-1.png.
In the screenshot, you can see that because of the dark theming of the
toolbar of the image preview window, it appears to be a part of the panel
and the global menu.
The screenshot demonstrates a situation in which this is undesirable. It may
appear to the user that the toolbar for the image preview application is a
part of the global menu for the settings application. A similar problem may
arise in the event that a user has, for instance, two documents open in a
word processor, and one maximised behind another unmaximised window. In this
case, it may appear that the toolbar of the window behind operates on the
window in front. This could cause confusion and annoyance.
SOLUTIONS:
There are a number of potential solutions, including theming inactive
windows differently and displaying the title bar of full screen windows.
In my opinion, the best solution I have observed is the solution in use on
Mac OS X Lion. Lion creates a dynamic workspace for each maximised  window,
in effect treating maximised (or full-screen) applications as additional
workspaces. This means that it is impossible to end up with a situation
where an unmaximised window is in front of a maximised window.

>From Jonathan Rothwell 
___
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] "Ubuntu" Applications

[Jonathan Meek]

As things currently stand, if you want an application in Ubuntu you go to
the software center and browse the myriad applications available. Of these,
MANY are what I would dub 'legacy' applications (my word, don't focus too
much on it). As far as I know, there is nothing that quite defines an Ubuntu
application. This creates the situation, where, if we get the presumed
users, they install Ubuntu and go looking for applications and they can end
up installing the KDE4 stack for it, not knowing that it's not the way
things are supposed to look, furthering the inconsistencies of the Ubuntu
desktop "look." (This is NOT a thread to complain about such, there are
plenty others out there.)

I would propose that, to mitigate this issue, some sort of guideline be
established for the look and feel of *Ubuntu* applications. (Meaning Ubuntu,
not GNOME's HIG) Right now, there is no real set of rules that defines how
an app should look and behave on Ubuntu. We assume that it should be GTK
(but defaults have non-gtk apps); we assume it should have Native widgets
(but defaults use non-native/hacked widgets); we make all kinds of
assumptions and none of facts seem to fit to any real set of rules.*

This is also not something that the community do, because if I could, I
would. We need to work with the design team to be able to develop the
guidelines.

Now, say we have those hypothetical guidelines out. I would propose a new
feature in the USC, a sort of stamp for applications. It would work one of
two ways: if the app is added the old, package approver way, the approver
would be able to set the "100% Ubuntu integration"** badge and it would
appear beside the app name in the list view of Software Center.  The other
way would be for a checkbox in the developer submit function of Ubuntu.com
that says 'this app follows the Ubuntu guidelines' And would get some sort
of provisional badge that would be subject to the USC's 'report this app'
type of function. (Perhaps simply a check box saying "Application does not
meet Ubuntu guidelines" that would show for only applications with such a
badge.)

In this fashion, you create a psuedo-category of applications in Ubuntu that
are sort of first-party approved. You get a reason for apps to take the time
to look nice because they will be acknowledged as fitting in with what is
arguably the most popular Linux distro. You will, at least in my opinion,
create a system wherein creating an Ubuntu app is beneficial. Users will
know that those applications are more aligned with how things should be and
will naturally move toward them first when seeking new applications (though,
not all will, because features and such may not be the same). But the
average user will hopefully look for the stamp and won't be put off by the
quirks of Qt apps or the XUL xenograft ;) when encountering new apps on
their computer.

Thank you for taking the time to read this. I would be more than happy to
answer any questions or clarify any statements if need. I hope to be able to
hear back from design on this proposal. Adieu for now!

*This is also not to say that we should ditch, say, Firefox because it
doesn't fit in with proposed "defaults." There are exceptions to the rules.
**That is to say, it looks and behaves the way an Ubuntu app should in
Ubuntu. That isn't to say that it's a full-time Ubuntu app. For example,
Empathy would be eligible for this "stamp", even though it isn't developed
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] "Ubuntu" Applications

[Jonathan Meek]

It's very possible to write a Qt app that looks and feels fully native
> in GNOME/Unity. And I believe Qt apps will look better outside of
> GNOME than GTK ones will. Also there are a lot of good apps available
> in KDE that may not be available elsewhere in Ubuntu (kdeedu is but
> one example).
>
>
> You are very welcome to write a Ubuntu HIG and propose it. If you can
> attend an UDS, that would help a lot with promoting your proposal but
> UDS isn't necessary. Ubuntu community members can get involved in
> nearly all parts of the Ubuntu development process, limited only by
> their time, abilities, and desire. Please don't feel that you have to
> be a Canonical employee to contribute.
>
> The Linux and open source community is much more than just Ubuntu. You
> might also want to help GNOME with updating their HIG for GNOME 3. I
> imagine a Ubuntu HIG would be the GNOME HIG with a few differences of
> opinion anyway.
>
>
I'm not sure how the formatting of this will look, but I'll go ahead and say
I want to tackle paragraph one as one issue and 2-3 as the second.

So, re:Qt app. Yes, it will behave natively, there is no denying that. But
it has to be coded very specifically to do so. If just a standard Qt app, it
will pull in icons for it's app menu (something no GTK apps I can think of
do) and any buttons will have items underlined in them for keyboard
shortcuts by default (Someone please correct me on that if I'm wrong) which
makes it one of those VERY slight, but noticeable things that make them
stand out. Would the average user pick up on that? Likely not. But an
inconsistency is an inconsistency. (Note, I'm not discounting the inclusion
of Qt in Ubuntu, just that there should be a definitive toolkit for
"definitive" apps)

Re: HIG. I cannot make it to UDS (though I do wish i could). It is possible
to create a guideline, but I'm under the impression that it would require
some input from Ubuntu designers to define what should be and what shouldn't
because they are in charge of the (C/c)anonical defaults. Without their
input, it comes down to guesswork on how things should be handled in an
Ubuntu App. However, once their general "rules are established, it would
primarily be a community thing to run the ball to the goal line.
___
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] "Ubuntu" Applications

[Jonathan Meek]

I don't think being seen as "too Apple-like" is an issue at this point. I
feel that, while some may complain about it, it doesn't matter that they do
complain if there is solid reasoning behind what you're doing. It's not
about simply emulating Apple. It's about enhancing user's experiences with
Ubuntu.

Well, maybe it's a little bit about emulating Apple. One of the major things
that I've heard people harp on about regarding Mac is consistency of
everything. But that can apply to almost any design, not just Apple.

On Mon, Sep 5, 2011 at 9:27 PM, James Gifford wrote:

> I love that idea.
>
> However, It'd be seen by many as "too Apple-like". Not that that is a bad
> thing, but it's something to consider.
>
> Cheers,
> James Gifford
> http://jamesrgifford.com
>
> On Sep 5, 2011, at 20:36, Jonathan Meek  wrote:
>
> > As things currently stand, if you want an application in Ubuntu you go to
> the software center and browse the myriad applications available. Of these,
> MANY are what I would dub 'legacy' applications (my word, don't focus too
> much on it). As far as I know, there is nothing that quite defines an Ubuntu
> application. This creates the situation, where, if we get the presumed
> users, they install Ubuntu and go looking for applications and they can end
> up installing the KDE4 stack for it, not knowing that it's not the way
> things are supposed to look, furthering the inconsistencies of the Ubuntu
> desktop "look." (This is NOT a thread to complain about such, there are
> plenty others out there.)
> >
> > I would propose that, to mitigate this issue, some sort of guideline be
> established for the look and feel of *Ubuntu* applications. (Meaning Ubuntu,
> not GNOME's HIG) Right now, there is no real set of rules that defines how
> an app should look and behave on Ubuntu. We assume that it should be GTK
> (but defaults have non-gtk apps); we assume it should have Native widgets
> (but defaults use non-native/hacked widgets); we make all kinds of
> assumptions and none of facts seem to fit to any real set of rules.*
> >
> > This is also not something that the community do, because if I could, I
> would. We need to work with the design team to be able to develop the
> guidelines.
> >
> > Now, say we have those hypothetical guidelines out. I would propose a new
> feature in the USC, a sort of stamp for applications. It would work one of
> two ways: if the app is added the old, package approver way, the approver
> would be able to set the "100% Ubuntu integration"** badge and it would
> appear beside the app name in the list view of Software Center.  The other
> way would be for a checkbox in the developer submit function of Ubuntu.com
> that says 'this app follows the Ubuntu guidelines' And would get some sort
> of provisional badge that would be subject to the USC's 'report this app'
> type of function. (Perhaps simply a check box saying "Application does not
> meet Ubuntu guidelines" that would show for only applications with such a
> badge.)
> >
> > In this fashion, you create a psuedo-category of applications in Ubuntu
> that are sort of first-party approved. You get a reason for apps to take the
> time to look nice because they will be acknowledged as fitting in with what
> is arguably the most popular Linux distro. You will, at least in my opinion,
> create a system wherein creating an Ubuntu app is beneficial. Users will
> know that those applications are more aligned with how things should be and
> will naturally move toward them first when seeking new applications (though,
> not all will, because features and such may not be the same). But the
> average user will hopefully look for the stamp and won't be put off by the
> quirks of Qt apps or the XUL xenograft ;) when encountering new apps on
> their computer.
> >
> > Thank you for taking the time to read this. I would be more than happy to
> answer any questions or clarify any statements if need. I hope to be able to
> hear back from design on this proposal. Adieu for now!
> >
> > *This is also not to say that we should ditch, say, Firefox because it
> doesn't fit in with proposed "defaults." There are exceptions to the rules.
> > **That is to say, it looks and behaves the way an Ubuntu app should in
> Ubuntu. That isn't to say that it's a full-time Ubuntu app. For example,
> Empathy would be eligible for this "stamp", even though it isn't developed
> 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
>
___
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] "Ubuntu" Applications

[Jonathan Meek]

Seek and you shall find. I'm not aiming this at you in particular, but the
kind of mentality that your statement is indicative of.  We need not base
design decisions on how the community is going to react. That isn't a valid
argument for or against something. So what if some people think it is too
close to Apple? So what if some people think it's Ubuntu throwing it's
weight around.

Ubuntu has gone through the whole "oh you stole that from Apple" thing and
come out fine before. People are going to complain no matter what. Don't
worry about it. Just listen and if they say something constructive, use it
to improve. Don't stop before you've started just because someone is going
to complain.

As for a potential to widen a wedge in the community. I see no wedge. I see
some heated words and design decisions some people may not agree on, but we
carry on or step aside.

Ubuntu ALREADY stands out. There's no avoiding that.

Okay, thank you for reading that. Hopefully that will help mitigate the
defeatist posts.

Now, I was perusing the software-center design document earlier and saw that
the USC will, by design, put GTK versions of apps with multiple toolkits
above the other version. Essentially, I just want to take this idea a few
more steps up the ladder that it can be more useful for people.

On Tue, Sep 6, 2011 at 10:12 AM, Roland Taylor  wrote:

>  I'm with James on this one. It would be nice to have a definition of what
> an Ubuntu application is, but let's face it - that would drive a wedge in
> the wider community even wider than what currently exists. People would
> label Canonical as Apple and us users as fanboys, and essentially seek ways
> to alienate Ubuntu, just because it stands out.
>
> Essentially, while it would be great - we would have to word it very
> carefully, and be clear that all other applications are welcome.
>
>
> *When one seeks to stand out - they should first consider the cost of
> standing and the price of being out.
> *
>
> On 09/05/2011 09:27 PM, James Gifford wrote:
>
> I love that idea.
>
> However, It'd be seen by many as "too Apple-like". Not that that is a bad 
> thing, but it's something to consider.
>
> Cheers,
> James Giffordhttp://jamesrgifford.com
>
> On Sep 5, 2011, at 20:36, Jonathan Meek  
>  wrote:
>
>
>  As things currently stand, if you want an application in Ubuntu you go to 
> the software center and browse the myriad applications available. Of these, 
> MANY are what I would dub 'legacy' applications (my word, don't focus too 
> much on it). As far as I know, there is nothing that quite defines an Ubuntu 
> application. This creates the situation, where, if we get the presumed users, 
> they install Ubuntu and go looking for applications and they can end up 
> installing the KDE4 stack for it, not knowing that it's not the way things 
> are supposed to look, furthering the inconsistencies of the Ubuntu desktop 
> "look." (This is NOT a thread to complain about such, there are plenty others 
> out there.)
>
> I would propose that, to mitigate this issue, some sort of guideline be 
> established for the look and feel of *Ubuntu* applications. (Meaning Ubuntu, 
> not GNOME's HIG) Right now, there is no real set of rules that defines how an 
> app should look and behave on Ubuntu. We assume that it should be GTK (but 
> defaults have non-gtk apps); we assume it should have Native widgets (but 
> defaults use non-native/hacked widgets); we make all kinds of assumptions and 
> none of facts seem to fit to any real set of rules.*
>
> This is also not something that the community do, because if I could, I 
> would. We need to work with the design team to be able to develop the 
> guidelines.
>
> Now, say we have those hypothetical guidelines out. I would propose a new 
> feature in the USC, a sort of stamp for applications. It would work one of 
> two ways: if the app is added the old, package approver way, the approver 
> would be able to set the "100% Ubuntu integration"** badge and it would 
> appear beside the app name in the list view of Software Center.  The other 
> way would be for a checkbox in the developer submit function of Ubuntu.com 
> that says 'this app follows the Ubuntu guidelines' And would get some sort of 
> provisional badge that would be subject to the USC's 'report this app' type 
> of function. (Perhaps simply a check box saying "Application does not meet 
> Ubuntu guidelines" that would show for only applications with such a badge.)
>
> In this fashion, you create a psuedo-category of applications in Ubuntu that 
> are sort of first-party approved. You get a reason for apps to take the time 
&

Re: [Ayatana] "Ubuntu" Applications

[Jonathan Meek]

You misunderstand: I do not propose a "good looks" badge. I am proposing a
"standards compliance" badge.

As for your (1), I would not argue against a soft warning.

As for (2) Then let us not speak of it here ;)

On Tue, Sep 6, 2011 at 1:46 PM, topdownjimmy  wrote:

> I agree that there's a small problem with users installing gobs of KDE
> dependencies that they might not want (without even knowing that they
> don't want them). But "good looks" is so subjective as to make any
> attempt to define it in any formal way very problematic.
>
> 1) Maybe it would be wise to give some kind of soft warning against
> installing KDE apps if the KDE dependencies are not already met, e.g.:
> "This application requires a large number of additional packages, and
> may not integrate seamlessly with your desktop. There is no harm in
> installing it, but you may want to browse alternatives first.
> Continue?"
>
> 2) Maybe this would be overkill (and I suspect this subject has been
> discussed at length before), but I wonder if the software center could
> benefit from ratings for a handful of different aspects of an
> application, e.g.: "Stability," "Functionality," "Ease-of-use,"
> "Appearance."
>
> On Mon, Sep 5, 2011 at 8:36 PM, Jonathan Meek 
> wrote:
> > As things currently stand, if you want an application in Ubuntu you go to
> > the software center and browse the myriad applications available. Of
> these,
> > MANY are what I would dub 'legacy' applications (my word, don't focus too
> > much on it). As far as I know, there is nothing that quite defines an
> Ubuntu
> > application. This creates the situation, where, if we get the presumed
> > users, they install Ubuntu and go looking for applications and they can
> end
> > up installing the KDE4 stack for it, not knowing that it's not the way
> > things are supposed to look, furthering the inconsistencies of the Ubuntu
> > desktop "look." (This is NOT a thread to complain about such, there are
> > plenty others out there.)
> > I would propose that, to mitigate this issue, some sort of guideline be
> > established for the look and feel of *Ubuntu* applications. (Meaning
> Ubuntu,
> > not GNOME's HIG) Right now, there is no real set of rules that defines
> how
> > an app should look and behave on Ubuntu. We assume that it should be GTK
> > (but defaults have non-gtk apps); we assume it should have Native widgets
> > (but defaults use non-native/hacked widgets); we make all kinds of
> > assumptions and none of facts seem to fit to any real set of rules.*
> > This is also not something that the community do, because if I could, I
> > would. We need to work with the design team to be able to develop the
> > guidelines.
> > Now, say we have those hypothetical guidelines out. I would propose a new
> > feature in the USC, a sort of stamp for applications. It would work one
> of
> > two ways: if the app is added the old, package approver way, the approver
> > would be able to set the "100% Ubuntu integration"** badge and it would
> > appear beside the app name in the list view of Software Center.  The
> other
> > way would be for a checkbox in the developer submit function of
> Ubuntu.com
> > that says 'this app follows the Ubuntu guidelines' And would get some
> sort
> > of provisional badge that would be subject to the USC's 'report this app'
> > type of function. (Perhaps simply a check box saying "Application does
> not
> > meet Ubuntu guidelines" that would show for only applications with such a
> > badge.)
> > In this fashion, you create a psuedo-category of applications in Ubuntu
> that
> > are sort of first-party approved. You get a reason for apps to take the
> time
> > to look nice because they will be acknowledged as fitting in with what is
> > arguably the most popular Linux distro. You will, at least in my opinion,
> > create a system wherein creating an Ubuntu app is beneficial. Users will
> > know that those applications are more aligned with how things should be
> and
> > will naturally move toward them first when seeking new applications
> (though,
> > not all will, because features and such may not be the same). But the
> > average user will hopefully look for the stamp and won't be put off by
> the
> > quirks of Qt apps or the XUL xenograft ;) when encountering new apps on
> > their computer.
> > Thank you for taking the time to read this. I would be more than happy to
> >

Re: [Ayatana] "Ubuntu" Applications

[Jonathan Meek]

That is what the former half of the original post is about. Those guidelines
for what this hypothetical "standards-compliance" do not quite exist yet.
Before we worry about singling out ANY applications, we have to figure out
what exactly that application would entail, no?

With that in mind, we need to focus on ways that we can collaborate/get
approval for a sort of Ubuntu HIG that apps should abide by if they want to
get the hypothetical badge.

On Tue, Sep 6, 2011 at 2:10 PM, topdownjimmy  wrote:

> What in addition to being GTK-based would you propose as a requirement
> for being "standards-compliant"?
>
> On Tue, Sep 6, 2011 at 1:52 PM, Jonathan Meek 
> wrote:
> > You misunderstand: I do not propose a "good looks" badge. I am proposing
> a
> > "standards compliance" badge.
> > As for your (1), I would not argue against a soft warning.
> > As for (2) Then let us not speak of it here ;)
> >
> > On Tue, Sep 6, 2011 at 1:46 PM, topdownjimmy 
> wrote:
> >>
> >> I agree that there's a small problem with users installing gobs of KDE
> >> dependencies that they might not want (without even knowing that they
> >> don't want them). But "good looks" is so subjective as to make any
> >> attempt to define it in any formal way very problematic.
> >>
> >> 1) Maybe it would be wise to give some kind of soft warning against
> >> installing KDE apps if the KDE dependencies are not already met, e.g.:
> >> "This application requires a large number of additional packages, and
> >> may not integrate seamlessly with your desktop. There is no harm in
> >> installing it, but you may want to browse alternatives first.
> >> Continue?"
> >>
> >> 2) Maybe this would be overkill (and I suspect this subject has been
> >> discussed at length before), but I wonder if the software center could
> >> benefit from ratings for a handful of different aspects of an
> >> application, e.g.: "Stability," "Functionality," "Ease-of-use,"
> >> "Appearance."
> >>
> >> On Mon, Sep 5, 2011 at 8:36 PM, Jonathan Meek  >
> >> wrote:
> >> > As things currently stand, if you want an application in Ubuntu you go
> >> > to
> >> > the software center and browse the myriad applications available. Of
> >> > these,
> >> > MANY are what I would dub 'legacy' applications (my word, don't focus
> >> > too
> >> > much on it). As far as I know, there is nothing that quite defines an
> >> > Ubuntu
> >> > application. This creates the situation, where, if we get the presumed
> >> > users, they install Ubuntu and go looking for applications and they
> can
> >> > end
> >> > up installing the KDE4 stack for it, not knowing that it's not the way
> >> > things are supposed to look, furthering the inconsistencies of the
> >> > Ubuntu
> >> > desktop "look." (This is NOT a thread to complain about such, there
> are
> >> > plenty others out there.)
> >> > I would propose that, to mitigate this issue, some sort of guideline
> be
> >> > established for the look and feel of *Ubuntu* applications. (Meaning
> >> > Ubuntu,
> >> > not GNOME's HIG) Right now, there is no real set of rules that defines
> >> > how
> >> > an app should look and behave on Ubuntu. We assume that it should be
> GTK
> >> > (but defaults have non-gtk apps); we assume it should have Native
> >> > widgets
> >> > (but defaults use non-native/hacked widgets); we make all kinds of
> >> > assumptions and none of facts seem to fit to any real set of rules.*
> >> > This is also not something that the community do, because if I could,
> I
> >> > would. We need to work with the design team to be able to develop the
> >> > guidelines.
> >> > Now, say we have those hypothetical guidelines out. I would propose a
> >> > new
> >> > feature in the USC, a sort of stamp for applications. It would work
> one
> >> > of
> >> > two ways: if the app is added the old, package approver way, the
> >> > approver
> >> > would be able to set the "100% Ubuntu integration"** badge and it
> would
> >> > appear beside the app name in the list view of Software Center.  The
> >> > other
> >> > way would be for a checkbox in the developer submit function of
> >

Re: [Ayatana] "Ubuntu" Applications

[Jonathan Meek]

True and an excellent point. I'm not saying this is for all developers. But
for those who what to create that... *experience* for others, this will be
the thing for them to go by.

As for fragmentation. There's no real-- I don't see it as an issue
(personally). Because, the guidelines will primarily concern themselves with
the look and feel of an app, based on good design. And good design is good
design no matter what system it shows up on. (Well, not ENTIRELY accurate,
but I assume you get the gist of what I mean.) So the app developers gets
some good design guidelines to make his or her app better knowing they are
following what would potentially be professional designer approved specs.

On top of this, it would be recommended to add Unity integration and such.
But, we all know apps can exist just fine without all those bells and
whistles. It's there if you have it, not in the way if you don't. (IE,
Gwibber's Unity quicklist in no way interferes with running the application
in GNOME Shell, or have a message counter for Thunderbird doesn't make it a
worse application in other environments.

Make sense?

On Tue, Sep 6, 2011 at 2:24 PM, Thorsten Wilms  wrote:

> On 09/06/2011 06:59 PM, Jonathan Meek wrote:
>
>> Seek and you shall find. I'm not aiming this at you in particular, but
>> the kind of mentality that your statement is indicative of.  We need not
>> base design decisions on how the community is going to react. That isn't
>> a valid argument for or against something. So what if some people think
>> it is too close to Apple? So what if some people think it's Ubuntu
>> throwing it's weight around.
>>
>> Ubuntu has gone through the whole "oh you stole that from Apple" thing
>> and come out fine before. People are going to complain no matter what.
>> Don't worry about it. Just listen and if they say something
>> constructive, use it to improve. Don't stop before you've started just
>> because someone is going to complain.
>>
>> As for a potential to widen a wedge in the community. I see no wedge. I
>> see some heated words and design decisions some people may not agree on,
>> but we carry on or step aside.
>>
>
> Sounds like looking away on purpose ;)
>
> I agree, if that is what you are saying, that design decisions are often,
> but of course not exclusively, met with at best half-informed, poorly
> constructed criticism. Opinions thrown out by people who usually will not
> get involved beyond that point. A lot of noise best treated as such.
>
> But when it comes to defining what an "Ubuntu App" shall be, and to
> creating a custom HIG, the question is:
> What will developers make out of it?
>
> Will it seem like Ubuntu is asking for extra work? May it be asking for
> things that would be good in the context of any other distribution, anyway?
> Does it further needless fragmentation? Or is it about adjustments to make
> one single chosen platform really shine?
>
> Developers might prefer to think of themselves as Linux developers, not
> Ubuntu developers (to just skip over entirely OS-independent).
>
>
> --
> 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<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] "Ubuntu" Applications

[Jonathan Meek]

Actually, I intended something more in depth than that. I asked one of the
designers and am going to attempt to begin work on a comprehensive HIG.
Everything about the design needs to be thought out, not just 'integrate
with this.' The problem with this undertaking is that there are so few
applications that can be considered "Ubuntu" applications. Less and more
than you would think. (Though, I've only heard from one person, and his
design choices may not be the consensus of the entire design team)

Provisionally, Mr. Gifford is correct. The are going to be started on, and
presented for peer review. I'm debating how to go about this now less than I
am whether to go about it at all.

I would like some opinions to feedback into this. I know what the designer
said were good designed Ubuntu applications, but what do people here think
are some? And why do you think that? (This includes, looks, structure, and
behavior as well as integration.)

On Wed, Sep 7, 2011 at 3:59 AM, Stefanos A.  wrote:

> Every desktop environment has its own set HIG. Unity is sufficiently
> different than Gnome Shell or KDE4 that it merits some form of guidelines,
> even if they are as simple as "must work with the global menu, must offer a
> tailored launcher menu and must follow global font settings". Most of these
> will be inherited from Gnome Shell and the rest will be additions for
> Unity-specific functionality (i.e. they will be supplementary rather than
> divisive).
>
> Above all, canonical applications (as in Canonical *and* canonical) must
> follow these guidelines to the letter. Ubuntu One and the Software Center
> currently stick out like sore thumbs from the rest of the desktop. Not good
> at all.
>
> ___
> 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] Unity's Scope

[Jonathan Meek]

In a recent discussion on Google+ Cassidy James (of elementary fame) was
asking just what defines a scope or lense on Unity. There is no real set
guideline for what they are or should do.

To me, Unity is about hooking in and searching. You should be able to
search from Unity for anything (or alter it such that you can) so that it
removes the arbitrary imposition of "you can search for X in Dash, but Y &
Z HAVE to be done in a web browser."

If that is the case, then how do we explain the binary clock that's been
implemented? Do we stop developers from creating different "fun" scopes
because it should be about search? Or should it be whatever someone can
imagine?

If it is, when do we say when? How do we make recommendations?

I imagine this will be something that will be covered in whatever eventual
HIG springs up, but the "damage" (not meant in a literal sense, I like the
work being done) is being done now. The precedent is being set.
___
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] Unity's Scope

[Jonathan Meek]

Thank you for the prompt response. I was not aware of the site prior to now
and this will be nice to have on hand.

On Thu, Jan 5, 2012 at 5:17 AM, John Lea  wrote:

>  *Hi Jonathan,
>
> Thanks for bringing the up. There is a brief definition at the top of the
> Lens documentation ( * https://wiki.ubuntu.com/Unity/Lenses ).  Another
> summery of the Dash is:
> *
> "The Dash aims to provide a lightweight, instant and easy means to browse
> and retrieve content.  The Dash is the beginning of most user journeys; a
> user first finds the content they are looking for in the Dash before moving
> to the relevant application. The Dash is content centric; content sources
> are grouped together around content types.  When a user wishes to search,
> they are given the option of using a interface tailored to the needs
> associated with searching a specific type of content (music, applications,
> etc...).  The Dash is storage location agnostic, content is aggregated from
> the user’s computer, their private cloud and the public web.  Using the
> Dash requires no management; content does not need to be organised in order
> to be readily accessible and there is zero configuration.   All content
> items can also have multiple parents; for example the song “You Give Love a
> Bad Name” can be categorised as both “80s” and “Soft Rock” (as opposed to
> the traditional files and folders pattern where a file can only be placed
> in a single folder).  The Dash works with all form factors and input
> devices, a user should be equally comfortable using the Dash with touch,
> keyboard or pointer navigation."
>
> **So yes the binary clock does not fit with the purpose and objectives of
> the Dash. However it is fun and playful, and while we would never ship it
> by default, I don't believe there should be restrictions on what users can
> choose to install. That would take us down a very un-free Apple like path.
>
> cheers,
> John
> *
>
> On 05/01/12 04:29, Jonathan Meek wrote:
>
> In a recent discussion on Google+ Cassidy James (of elementary fame) was
> asking just what defines a scope or lense on Unity. There is no real set
> guideline for what they are or should do.
>
>  To me, Unity is about hooking in and searching. You should be able to
> search from Unity for anything (or alter it such that you can) so that it
> removes the arbitrary imposition of "you can search for X in Dash, but Y &
> Z HAVE to be done in a web browser."
>
>  If that is the case, then how do we explain the binary clock that's been
> implemented? Do we stop developers from creating different "fun" scopes
> because it should be about search? Or should it be whatever someone can
> imagine?
>
>  If it is, when do we say when? How do we make recommendations?
>
>  I imagine this will be something that will be covered in whatever
> eventual HIG springs up, but the "damage" (not meant in a literal sense, I
> like the work being done) is being done now. The precedent is being set.
>
>
> ___
> Mailing list: https://launchpad.net/~ayatana
> Post to : ayatana@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp
>
>
>
> --
> John Lea | Ubuntu Desktop User Experience Lead
> Canonical  www.canonical.com | Ubuntu  www.ubuntu.com
> 27th Floor, 21-24 Millbank Tower, London, SW1P 4QP
> Tel: +44 (0) 20 7630 2415 | Email: john@canonical.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
>
>
___
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] What to call the unity panel?

[Jonathan Meek]

Last that I've heard, the correct term is "Menubar."

On Mon, Jan 9, 2012 at 11:56 AM, Michael Terry
wrote:

> Hello!
>
> I was about to implement a part of the new System Settings spec [1] when I
> saw that it referred to the unity panel as "the top bar".
>
> But in a past cycle, I implemented the Time & Date spec [2] which has UI
> that refers to the unity panel as "the menu bar".
>
> So which one is the official user-facing phrase?  I can fix either UI to
> be consistent, I just need to know which.
>
> -mt
>
> [1] https://docs.google.com/**document/d/**1ILTJDiDCd25Npt2AmgzF8aOnZZECx*
> *TfM0hvsbWT2BxA/edit?hl=en_GB&**pli=1#heading=h.i5lg1g344bsb
>
> [2] 
> https://wiki.ubuntu.com/**TimeAndDate#Time_.26_Date_**settings
>
> __**_
> 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] Unity and Menus

[Jonathan Meek]

In my spare time, I'm working on creating a traditional windowed
application that will have a menubar. I find it important to integrate with
Unity, leading me to an important question: What behavior is the best to
adopt?

As I see it, there are three options:

   1. I can have windows each have their own specific menubar as needed and
   let Unity take it out and put it in the top as is usual now.
   2. I can push the application to use only one window so that the menubar
   becomes a non-issue.
   3. I can work on an application-wide menu.

And for the issues I see with these approaches:

   1. This creates inconsistencies with the launcher being per-application
   in its design. The launcher is based on the application, not on its
   constituent windows.
   2. Not all applications can force their system into a single window
   interface with the limitations of current GTK technology. (At least to my
   own satisfaction given the different models needed for different aspects of
   the application.)
   3. The way that Unity currently grabs the menubar from applications is
   on a per-window basis. More or less literally ripping the menubar from the
   application. This makes any application-wide menu feel like a hack
   personally.

I feel like it's obvious which approach I'd prefer, but I'm interested in
feedback in which scenario is the one most in line with Ubuntu's future. I
know that one of the ultimate goals stated my MPT was to be able to provide
a default set of menus for every application. Then again, we have one of
the default applications forgoing menus altogether (Ubuntu One Control
Panel).

So which approach is condoned?

Additional question: What should the nomenclature of menus be? Are we to
adopt the inherited behavior for classic GNOME applications where the first
menu name should be relevant to the application? (I.E. Rhythmbox's first
menu being named "Music", or Empathy's "Chat")

Or the adopt the newer GNOME behavior that will appear when using an
application on OS X? (I.E. The name of the application being the first menu
[in my opinion alleviating some of the global menu design issues] found in
this link  from
another recent Ayatana posting.)

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