Gnome Developer - Broken Link

2011-04-07 Thread Nick Glynn
The new look is fantastic but the link on
http://developer.gnome.org/gnome-devel-demos/unstable/getting-ready links
to
http://developer.gnome.org/gnome-devel-demos/unstable/media/gnome-devtools.catalog
which
currently 404's.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Gnome Feature Request

2011-05-08 Thread Nick Glynn
I think leveraging dbus would be the way to do it but presented in a way
similar to Android's intents/receiver system.
On May 8, 2011 5:30 PM, "Jasper St. Pierre"  wrote:
> So... you're suggesting D-Bus?
>
> 2011/5/8 Erick Pérez 
>
>> Hi:
>>
>> I hope the term for proposing stuff to Gnome 3.2 isn't over yet, It
>> took me a while to made my mind about this.
>> So here it goes:
>>
>> What I think Gnome needs now:
>> A centralized, gnome controlled place for applications to
>> share/offers actions: I think this might me more easy to understand by
>> using examples.
>>
>> Example 1:
>> I'm reading a pdf file in Evince, and I want to look for a
>> word
>> definition on Dictionary. Evince could look at this central place of
>> apps services, and send Dictionary a signal to look for the word
>> selected and show a window with the results.
>> Example 2:
>> I want jump list in Gnome, Gnome-Shell would look at this
>> place and
>> for every application in my favorite list would retrieve the suitable
>> actions for place in the jump list
>> Example 3: QuickLook apple-like, I'm looking for a file in nautilus,
>> and nautilus would look at this place for an app that can show me a
>> preview of this file-type and fire it.
>>
>> I think I made my point.
>> There still some definitions left.
>> 0. More than anything, It would be necessary to define some verbs for
>> applications to use it to understand each others
>> 1. App could offers services based on file, clipboard content, etc.
>> 2. App could offers services based file type
>> 3. We should define a way for apps to get the results of and operation
>> back, no matters is a true or false, or a file packed, or something
>> else
>> 3. Gnome will need some way to manage the apps actions offered, and
>> some way to prevent ones and allows others
>>
>> Finally, what I'm thinking of is something very alike to Contractor
>> elementary module
>> <
>>
http://www.omgubuntu.co.uk/2011/03/contractor-brings-seamless-file-sharing-between-apps-to-the-linux-desktop/
>> >
>> but I want something more general, not just file, but others stuff
>> too, not even sharing, but doing something for me, sending tweets,
>> cropping pictures, converting ebooks, etc. Giving the ability of
>> application to communicate each other is one step to make the Gnome
>> Desktop a more consistent and integrated ecosystem.
>> There's one thing to note, the underlying structure, the code bits,
>> are a lot ahead since dbus exist already and I can't think of a better
>> way to handle communication
>>
>> Now: Which is the course from here.
>> I'm ready to collaborate programming or doing something else
>>
>> Erick
>>
>> --
>> El derecho de expresar nuestros pensamientos tiene algún significado
>> tan sólo si somos capaces de tener pensamientos propios.
>> El miedo a la libertad, Erich Fromm
>> ___
>> desktop-devel-list mailing list
>> desktop-devel-list@gnome.org
>> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Find my machine

2011-08-04 Thread Nick Glynn
Hey,

Are there any plans to integrate PreyProject/iCloud type functionality into
the new gnome-control-centre/account settings that ties into the gnome
infrastrucure?
Although this is something that would be more useful for the Gnome-as-an-OS
scenario - it may be worth thinking about now as Gnome moves forward.

I've go some code running on my local machine that uses Leaflet (
http://leaflet.cloudmade.com/ ) and some python on my laptop at the moment
but would rather contribute with some direction on whether it's useful -
without a common server it's not that useful for end users and feels that a
"Just works" solution could be a great value-add for Gnome.

Cheers,
Nick
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Features !

2011-10-06 Thread Nick Glynn
Hi,

On 6 October 2011 09:48, Martyn Russell  wrote:

> On 06/10/11 09:34, Joaquim Rocha wrote:
>
>> On Thu, 2011-10-06 at 08:37 +0100, Martyn Russell wrote:
>>
>>> [...]
>>>
>>> I love the shell generally though, this is really just where I think we
>>> could improve things.
>>>
>>>
>> Hi,
>>
>
> Hi,
>
>  I second Martyn's proposals and I'd like to name a few things that at
>> least in my case, could be improved.
>>
>> The worst part of the shell for me is the bottom tray area (sorry if
>> this is not the official name for it).
>> Besides being visually ugly (with the gradient background) IMHO, the
>> windows' names expanding when the mouse is over the icons is
>> disconcerting for me. I have to be extra accurate with the trackball in
>> order not to miss the exact icon or it will expand the another one,
>> etc... This is especially terrible when I have 10 telepathy buddy icons
>> and have to go expanding them all when I try to find a specific buddy
>> this way. (Of course I can just open the contacts list but anyway, the
>> use case I'm talking about is also valid IMHO)
>>
>> I think that a good way to fix this is to remove the expanding thing and
>> to show the name on top of the icons on mouse-over (as tooltips).
>> Something like when rests the mouse on top of an opened app's icon in
>> the opened apps list on the left.
>>
>
> Or, similarly to how mac did it? does it? using a jumping icon or changing
> the colour or some notification which is subtle. With an icon appearing in
> the top (like the battery icon) which allows you to use your contacts
> (favourite or recently communicated with and have access to the contacts
> app/dialog), that would be a nice way to avoid needing the roster entirely
> generally. You could see notifications grouped there. I was struggling with
> concepts for this when I worked on Gossip back in the days before Empathy.
> It's not an easy UX to come up with.
>
> You could apply this to the network manager applet/icon too to avoid this
> constant bombardment of connection state changes on devices like laptops.
>
> Of course, this completely conflicts with the current approach and being
> able to reply to messages without opening any window.
>
> For me the issue is more about *not seeing* messages waiting for me and
> internally people in Lanedo who have been using gnome-shell < 3.2 only
> respond to messages if spoken to directly (i.e. chatrooms messages were
> missed). This is likely fixed now I suspect. Either way, I never use the
> bottom notification bar and don't think to check it for new events at all.
>
>
>  Another thing I think could be given some thought is the notifications.
>> I understand how convenient it is to show them on the bottom of the
>> screen (it's a "clean" side and helps integrating the chat). The problem
>> is that I am often writing on the bottom of the screen (on a terminal or
>> chatting with a friend) and a notification comes up, blocking my text.
>> This is especially annoying when that notification is a chat window and
>> it gets focused, receiving the text I was writing before...
>> I don't know a good way to fix it but perhaps it could be given some
>> thought by the designers.
>>
>
> I agree.
>
>
>  Still on the bottom area, I wish that when my status is available,
>> notifications would stick in a visible area. It often happens that I'm
>> far from the keyboard for 5 minutes, meanwhile a notification came (say
>> someone is trying to chat with me) but timed out and is now hidden in
>> the tray area. I end up answering those notifications much later when I
>> happen to notice them. Maybe this could be configured so when the status
>> is "available" and a notification comes, the tray area would be visible
>> constantly until one focus another area.
>>
>
> Yea, precisely the case I see too.
>
>
>  I think it'd be also useful if the opened windows' previews (when
>> accessing activities) showed their icons, for example on a corner of the
>> previews or the the left of their name.
>>
>>
>> Finally, I think that the inclusion of a "close all" option in the apps
>> menu (when right-clicking on the left area's icons) would be useful.
>>
>
> I suspect you might want to do this per workspace than all at the same
> time. I only close all when rebooting.
>
> But I also use the extension to place certain apps on particular workspaces
> because I am used to my work flow being related to the workspace I am on.
>
>
> --
> Regards,
> Martyn
>
> Founder and CEO of Lanedo GmbH.
> __
>

Maybe something like the Ubuntu/Dell brain/ideastorm would be a nice
addition to the Gnome website for these sorts of proposals?

It may help prioritise those must have features/requests and then
developers/UX guys could assign, develop or shootdown the ideas as
appropriate?

Regards,
Nick
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-

Re: GNOME user survey 2011 (v6)

2011-10-18 Thread Nick Glynn
>
> > Phoronix is a tabloid seeking sensation.
> Agree. But I guess it is not a surprise that some users are crying for good
> old gnome2. If gnome could properly estimate the share of those deprived...
> would it change anything?


What's stopping these deprived users from using Gnome 2.X? I don't think
there's enough developers interested in keeping the 2.X series alive - it
would be a different matter if people were smashing out the features/patches
for the 2.X range but as that's not happening I don't see why they don't
stay with what works for them?

Regards,
Nick
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Prevent screen from going to sleep

2012-03-01 Thread Nick Glynn
> Thanks for  the tip, but I  don't use the gnome shell.
>
> Marco
>

So you don't use the Gnome desktop but you're moaning to the development
list thereof?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Learn Gnome The Hard Way

2012-06-02 Thread Nick Glynn
Hey list,

Are there any efforts to develop a new Gtk/Gnome Development book as I
think the most recent was Foundations of Gtk Development which was 2007 and
a fair bit has changed since then.

I appreciate there's a lot better documentation/tutorials on *.gnome.org
these days but wondered if something akin to Zed Shaws Learn X The Hard Way
is in the works such that it can be contributed to by the community as well
as those in the know and kept up to date much easier than a traditional
book.

For those unfamiliar with the concept you can see the outline repo here
https://gitorious.org/learn-x-the-hard-way/learn-x-the-hard-way and more
examples of the type of documentation can be seen at
http://www.learncodethehardway.com/

I've had a look and couldn't find anything in progress but Google doesn't
seem to index github/gitorious projects all that well.

Regards,
Nick
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: 3.12 feature: polari

2013-10-11 Thread Nick Glynn
So there's going to be Empathy, Chat and Polari?

Each with a different use-case?

Maybe taking the lead from Google on their Hangouts for Everything
(including MMS and SMS) might be a better route?

Happy to help tho
- Nick
On 11 Oct 2013 10:35, "David Woodhouse"  wrote:

> On Fri, 2013-10-11 at 10:25 +0100, Ross Burton wrote:
> > Or be a better alternative to Empathy for rooms, leaving Empathy (or
> > eventually, Contacts + Shell, I guess) for IM.
>
> That seems like confusing balkanisation to me. So if I'm having a
> conversation in an IRC channel with someone, and we decide to take it
> *off* the channel to private messages, it suddenly ends up in a
> different app altogether?
>
> Or would the differentiation be on the *protocol* it uses? Which doesn't
> sound like a very user-friendly idea either. And many "IM" protocols
> actually support group chats or meetings too...
>
> And if there's an IRC channel with only two people in, what then? :)
>
> --
> dwmw2
>
>
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: 3.12 feature: polari

2013-10-11 Thread Nick Glynn
What's the new shiny feature for this over the more established players?

I saw on the notes it mentioned about missed messages and multiple channels
- will there be a gnome hosted service that proxies the messages so they're
available on reconnect as that would be fncy :D
On 11 Oct 2013 11:19, "Allan Day"  wrote:

> David Woodhouse  wrote:
> >> Or be a better alternative to Empathy for rooms, leaving Empathy (or
> >> eventually, Contacts + Shell, I guess) for IM.
> >
> > That seems like confusing balkanisation to me.
>
> The usage patterns for IRC are different from regular IM (passive
> presence in many "always on" channels vs. active participation in a
> smaller number of temporally specific conversations). You can't
> support both with the same UI (I know, I've tried to design such a
> thing).
>
> > So if I'm having a
> > conversation in an IRC channel with someone, and we decide to take it
> > *off* the channel to private messages, it suddenly ends up in a
> > different app altogether?
> ...
>
> No. Please check the mockups [1] - private messages are handled in
> Polari (in a similar fashion to other IRC clients, like XChat).
>
> There's nothing radically new here - IRC and IM clients frequently
> coexist without any problems. This feature is simply intended to
> provide a better IRC client for GNOME.
>
> Allan
>
> [1] https://wiki.gnome.org/Design/Apps/Potential/Polari#Tentative_Design
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list