Hi,
Am 14.06.2010 16:21, schrieb Shane Fagan:
I see you guys are planning the design of the networking menu. My
question is do you really need vpn in there? Is it something that we
need to expose to every user? Barely any desktop (or netbook) user uses
vpn at all they mainly use normal lan,
On Mon, 2010-06-14 at 14:08 +0100, Luke Benstead wrote:
Is there a reason why DockbarX is not suitable for this? I've attached
a screenshot incase people dunno what I'm talking about :)
That is what you would get if you removed the ... from the bar when they
get resized.
I never understood
On 06/14/2010 12:31 AM, Matthew Paul Thomas wrote:
Scott Ritchie wrote on 23/04/10 06:48:
I like where you're going, but what do we do about interoperability?
There's a hint in your post that we'll simply leave apps broken, stick
up our middle fingers, and tempt developers with our
On 14 June 2010 08:31, Matthew Paul Thomas m...@canonical.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Scott Ritchie wrote on 23/04/10 06:48:
I like where you're going, but what do we do about interoperability?
There's a hint in your post that we'll simply leave apps
A massive portion of Ubuntu users use Wine or Java apps to some
degree. If we are trying to improve usability, how would relegating
non-application-indicator-conforming apps to floating windows improve
a user's experience compared to the current situation of having the
(empty most of the
On 15 June 2010 10:32, Conscious User consciousu...@aol.com wrote:
A massive portion of Ubuntu users use Wine or Java apps to some
degree. If we are trying to improve usability, how would relegating
non-application-indicator-conforming apps to floating windows improve
a user's
How about a middle-ground compromise? Not using a full blown
window,
but putting the Wine tray icons inside an indicator menu.
Horrible mockup attached for illustration.
I thought about that, but AFAIK you can't have right clicking
On 15 June 2010 10:39, Conscious User consciousu...@aol.com wrote:
How about a middle-ground compromise? Not using a full blown
window,
but putting the Wine tray icons inside an indicator menu.
Horrible mockup attached for illustration.
I thought
Plus, with this mockup, you need an inidicator icon/menu for each
class of application that might put things in the notification area?
That's gross, on top of the just-not-working problem.
Here's an idea: Just leave the notification icons in the panel. They
should show up right next to the
On 15/06/10 10:35, Luke Benstead wrote:
I thought about that, but AFAIK you can't have right clicking (perhaps
also double clicking) inside an indicator menu.
We could do a special-case for this.
signature.asc
Description: OpenPGP digital signature
2010/6/15 Jeremy Nickurak jer...@nickurak.ca
Here's an idea: Just leave the notification icons in the panel. They
should show up right next to the existing indicator icons. This could
be done in the same indicator-applet or in a seperate
notification-area applet, it doesn't really matter.
On Tue, 2010-06-15 at 10:42 +0100, Luke Benstead wrote:
We are talking about an
impossible-to-overcome-by-application-indicator-design-limitation.
I presume system indicators went from objects to states so right
clicking was thrown out. So Networking to State of Network and Messages
to You Have
On Tue, Jun 15, 2010 at 2:10 AM, Martin Owens docto...@gmail.com wrote:
On Mon, 2010-06-14 at 14:08 +0100, Luke Benstead wrote:
Is there a reason why DockbarX is not suitable for this? I've attached
a screenshot incase people dunno what I'm talking about :)
That is what you would get if
Plus, with this mockup, you need an inidicator icon/menu for each
class of application that might put things in the notification area?
No. Just for the corner cases that cannot use libappindicator and
never will, like Wine and Java. Are there any other besides those
two?
All other classes of
On Tue, Jun 15, 2010 at 9:52 PM, Conscious User consciousu...@aol.com wrote:
In application menus, the behavior is the same for left-clicking and
right-clicking: both open the same menu. For indicator applets, the
right click invokes the menu with the applet options, like locking,
moving and
rev. 24 fixes some embarrassing... typos say.
--
https://code.launchpad.net/~dbarth/indicator-appmenu/conform-to-specs-defaults/+merge/27608
Your team ayatana-commits is subscribed to branch lp:indicator-appmenu.
___
Mailing list:
The proposal to merge lp:~dbarth/indicator-appmenu/conform-to-specs-defaults
into lp:indicator-appmenu has been updated.
Status: Needs review = Merged
--
https://code.launchpad.net/~dbarth/indicator-appmenu/conform-to-specs-defaults/+merge/27608
Your team ayatana-commits is subscribed to
Review: Approve
Looks better to me. In the 2 widgets, the _dispose function leaks memory. While
I appreciate that it's tedious to maintain that during the UI prototyping
phase, at least it'd deserve a big /* TODO */ in those functions to make it
obvious there is a huge leak. Otherwise, cool!
Review: Approve
Looks good. Could use a couple comments explaining what happens in fail
conditions here and there (like if your proxy is null) but nothing blocking a
merge.
+1
--
https://code.launchpad.net/~bratsche/appmenu-gtk/almost-rewrite/+merge/27638
Your team ayatana-commits is
Forgive me if I don't know exactly how libappmenu is going to be used - it's
not mentioned anywhere in any of the distributed files ;-) From the looks I'd
say it was the gtk module that we load into all apps to export the menu on the
bus? My comments are based on that at least :-)
I am a bit
Mikkel,
I thought that there was an easy way to get the specific name change in GDBus.
I figured we'd pick up that optimization when we ported from dbus-glib to GDBus.
Ted
--
https://code.launchpad.net/~bratsche/appmenu-gtk/almost-rewrite/+merge/27638
Your team ayatana-commits is subscribed
21 matches
Mail list logo
