Re: Making a phone call with GNOME

[Zeeshan Ali (Khattak)]

Hi,

On 27 March 2018 at 16:56, Aleksander Morgado  wrote:
> Hey!
>
>> Firstly, there are only two existing free GSM middleware frameworks:
>> freesmartphone.org¹ (FSO) and oFono².  FSO is actually a whole
>> smartphone middleware, including not just telephony but contacts,
>> alarms, audio, battery and so on.  We are explicitly targetting the
>> GNOME platform which already provides a lot of (all of?) what FSO does.
>> We cannot use FSO or else we would conflict with our goal of building on
>> the GNOME platform.  Hence, we must use oFono.
>>
>
> A third option that fits well within GNOME is ModemManager. It
> supports voice call management as well since some time ago:
>   
> https://www.freedesktop.org/software/ModemManager/api/latest/gdbus-org.freedesktop.ModemManager1.Modem.Voice.html
>   
> https://www.freedesktop.org/software/ModemManager/api/latest/gdbus-org.freedesktop.ModemManager1.Call.html
>
> Not saying it's a direct replacement of oFono in this area though,
> oFono is likely more mature in all voice related operations. But
> ModemManager voice support has been used for some time in several
> professional setups, including trains and cars.

Yeah, while oFono might have more maturity in terms of voice related
operations, there are many reasons not to use it IMO:
http://zee-nix.blogspot.de/2014/06/ofono-its-dead-jim.html

It's up to you of course what you choose for your platform but if you
will be making use of Geoclue2 and decide to use oFono, you will need
to write the backend of oFono.

-- 
Regards,

Zeeshan Ali
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Librsvg 2.41.0 is released

[Zeeshan Ali (Khattak)]

Hi,

On 5 January 2017 at 19:34, Ross Burton  wrote:
>
> On 5 January 2017 at 18:25, Emmanuele Bassi  wrote:
>>
>> As for Continuous, we should be able to add Rust to the Yocto base.
>> Unfortunately, the build bot is still not running (and it hasn't been
>> building images since early December), and I don't have access to it
>> to check why.
>
>
> There's a meta-rust layer already, although I've not actually used it yet to
> vouch for how good/bad it is.

FWIW, We use it in Genivi Development Platform. We were using an old
git version and we faced a lot of issues with that but I'm told that
most of those issues have been resolved. We recently (3 weeks ago)
upgraded to latest git and so far haven't seen any issues.

-- 
Regards,

Zeeshan Ali
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME 3.23.3 unstable tarballs due (responsible: mcatanzaro)

[Zeeshan Ali (Khattak)]

Hi,

I'm sorry but I don't be able to make the release of Boxes.

On Fri, Dec 9, 2016 at 1:00 AM, Release Team  wrote:
> Hello all,
>
> Tarballs are due on 2016-12-12 before 23:59 UTC for the GNOME 3.23.3
> unstable release, which will be delivered on Wednesday. Modules which
> were proposed for inclusion should try to follow the unstable schedule
> so everyone can test them.  Please make sure that your tarballs will
> be uploaded before Monday 23:59 UTC: tarballs uploaded later than that
> will probably be too late to get in 3.23.3. If you are not able to
> make a tarball before this deadline or if you think you'll be late,
> please send a mail to the release team and we'll find someone to roll
> the tarball for you!
>
>
> For more information about 3.23, the full schedule, the official
> module lists and the proposed module lists, please see our colorful 3.23
> page:
>http://www.gnome.org/start/unstable
>
> For a quick overview of the GNOME schedule, please see:
>https://wiki.gnome.org/Schedule
>
> Thanks,
> --
> Automatically generated email. Source at:
> https://git.gnome.org/browse/releng/tree/tools/schedule/automail.py
> --
> devel-announce-list mailing list
> devel-announce-l...@gnome.org
> https://mail.gnome.org/mailman/listinfo/devel-announce-list



-- 
Regards,

Zeeshan Ali
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Deleted '-' milestone on bugzilla

[Zeeshan Ali (Khattak)]

Hi again,

Sorry, false alarm. :)

On Thu, Mar 31, 2016 at 2:26 PM, Zeeshan Ali (Khattak)
<zeesha...@gnome.org> wrote:
> Hi everyone,
>
> I was editting milestones of gnome-boxes product on bugzilla and I
> decided to delete the '-' milestone (which AFAIK means unknown) and
> seems I ended up deleting it for all products. :(
>
> I'm terribly sorry for this but I think it's more the bugzilla
> interface that's to blame here since the it gives me the impression
> that I'm only editing one product.
>
> Anyway, I apologize for this inconvenience.
>
> --
> Regards,
>
> Zeeshan Ali (Khattak)



-- 
Regards,

Zeeshan Ali (Khattak)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Deleted '-' milestone on bugzilla

[Zeeshan Ali (Khattak)]

Hi everyone,

I was editting milestones of gnome-boxes product on bugzilla and I
decided to delete the '-' milestone (which AFAIK means unknown) and
seems I ended up deleting it for all products. :(

I'm terribly sorry for this but I think it's more the bugzilla
interface that's to blame here since the it gives me the impression
that I'm only editing one product.

Anyway, I apologize for this inconvenience.

-- 
Regards,

Zeeshan Ali (Khattak)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [Builder] Developer experience (DX) hackfest 2016

[Zeeshan Ali (Khattak)]

Hi,

On Thu, Dec 31, 2015 at 6:28 AM, Richard Stallman <r...@gnu.org> wrote:
> [[[ To any NSA and FBI agents reading my email: please consider]]]
> [[[ whether defending the US Constitution against all enemies, ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> Jitsi works fine for meetings.  All each participant needs is
> to visit a given URL; it could hardly be easier.

FWIW, I just tested this here with help from Lasse Schuirmann and and
Jakub Steiner. For me and Lasse, it worked like a charm, out of the
box (actually better first time experience than with Google hangout
since you are not asked to download/install some packages). However,
Jakub had some issues getting video to work and then some problem with
mic as well but IIUC, it was to do with his special hardware not being
properly supported by drivers.

> I thought we were looking for one-way streaming to a lot of people,
> not for a meeting.  But I could have misunderstood that.

It's a hackfest, so while the primary objective is one-way
communication, it would be very much desirable IMO for remote
participants to be able to talk with us.

-- 
Regards,

Zeeshan Ali (Khattak)

Befriend GNOME: http://www.gnome.org/friends/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME techonologies used by Mozilla

[Zeeshan Ali (Khattak)]

Hi Pranav,

I'm guessing I'm way too late for this round but if Mozilla will be
doing another round of this in future, I would like to point to a
task:

https://bugzilla.mozilla.org/show_bug.cgi?id=1063572

Since Geoclue2 relies heavily on Mozilla Location Services on most
computers out there (where they lack a 3G hardware), I think Firefox
relying on Geoclue on Linux machines, would turn this win situation
into a win-win one. :)

On Fri, Nov 27, 2015 at 10:00 AM, Pranav Kant <pranav...@gmail.com> wrote:
> Hi GNOME devs,
>
> We are already running short of time on this, so this needs some of your
> attention quick. If anyone has any GNOME project in mind that Mozilla
> directly or indirectly relies on[0], and which could be completed
> (hack/build some new feature or fix something really important) with the
> help of Mozilla funds out of its MOSS program (can be in form of hiring
> interns or working full time, or anything you could think of), please reply
> here. Also mention the funds that you require against your project. Please
> describe concrete, specific outputs and outcomes that grant would produce.
>
> Here[1] is the list that Sahil has compiled for GNOME projects on which
> Mozilla directly or indirectly relies on, just for your reference. But list
> could be incomplete, so don't mind if your project is being used by Mozilla
> in some way or other and is not on the list.
>
> You can reply on this thread with your project, or either of us (people in
> CC).
>
> At the end of the day, we would compile all the projects and submit the
> application for the grant under the GNOME umbrella.
>
> [0]
> https://blog.lizardwrangler.com/2015/10/23/mozilla-launches-open-source-support-program/
> [1]
> https://docs.google.com/document/d/12NyQXCnnyO61vqHB8VyYqtcN4xxfY0L8NELjfPrYRAA/edit
>
> On Wed, Nov 25, 2015 at 10:33 PM, Sriram Ramkrishna <s...@ramkrishna.me>
> wrote:
>>
>>
>>
>> On Wed, Nov 25, 2015 at 8:55 AM Andre Klapper <ak...@gmx.net> wrote:
>>>
>>> On Wed, 2015-11-04 at 18:32 +, Sriram Ramkrishna wrote:
>>> > I will be meeting with Jim today at 8pm.  I will report back on that
>>> > meeting and then see what next steps we need to do.
>>>
>>> Sri: Any news?
>>
>>
>> Sahil, Pranav and I met yesterday.  The deadline was yesterday for the
>> first round, but unfortunately we weren't quite able to get our act
>> together.  But our mentor told us with the upcoming holidays it is unlikely
>> they would look at the applications much this week anyways.
>>
>> We have the list of GNOME upstream source code around two products - Sea
>> Monkey and Firefox.  So by this Friday we will be putting two applications
>> for each of those products by Friday.  We have a mentor lined up and ready
>> to help us.  So we're in good shape other than the fact that we missed the
>> deadline.
>>
>> Pranav and Sahil, do you have anything to add?
>>
>> sri
>>
>>>
>>> andre
>>> --
>>> Andre Klapper  |  ak...@gmx.net
>>> http://blogs.gnome.org/aklapper/
>>>
>>>
>>> ___
>>> engagement-list mailing list
>>> engagement-l...@gnome.org
>>> https://mail.gnome.org/mailman/listinfo/engagement-list
>>
>>
>> _______________
>> engagement-list mailing list
>> engagement-l...@gnome.org
>> https://mail.gnome.org/mailman/listinfo/engagement-list
>>
>
>
>
> --
> Regards,
> Pranav Kant
> http://pranavk.me
>
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list



-- 
Regards,

Zeeshan Ali (Khattak)

Befriend GNOME: http://www.gnome.org/friends/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: FOSDEM Desktops DevRoom 2016 Call for Participation

[Zeeshan Ali (Khattak)]

On Tue, Dec 8, 2015 at 5:28 PM, Christophe Fergeau <t...@gnome.org> wrote:
> Hi,
>
> On Tue, Dec 08, 2015 at 01:45:59PM +0000, Zeeshan Ali (Khattak) wrote:
>> Hi Christophe,
>>
>> While I greatly appreciate your (and of everyone involved) voluntary
>> work on organising the devroom, I really wish we did not put all these
>> big projects into one devroom for just one day. Is there any way we
>> could get GNOME its own devroom (even for a day) in FOSDEM 2017?
>
> Given the amount of projects asking for devrooms, I suspect this is
> going to be hard. The FOSDEM organizers asked us to merge the devrooms
> for a reason. We already only have this shared devroom only for a day.

Yeah I understand that but I'm wondering if they could be persuaded
not to treat all applying projects equally and give more room and time
to projects that are more popular/bigger. I didn't want to say bad of
any projects in particular here but I feel I have to give an example,
to make my point so I'll mention one that I actually love: Guile.
Given that there is a handful of people who use Guile (or even Scheme
in general), I really don't see why it should be given the same amount
of room/time as GNOME and KDE.

-- 
Regards,

Zeeshan Ali (Khattak)

Befriend GNOME: http://www.gnome.org/friends/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: FOSDEM Desktops DevRoom 2016 Call for Participation

[Zeeshan Ali (Khattak)]

nization
>>
>> The Desktops DevRoom 2016 is managed by a team representing the most
>> notable open desktops:
>>
>>
>>- Pau Garcia i Quiles, KDE
>>
>>- Christophe Fergeau, Gnome
>>
>>- Michael Zanetti, Unity
>>
>>- Philippe Caseiro, Enlightenment
>>
>>- Jérome Leclanche, Razor
>>
>>
>> If you want to join the team, please contact pgquiles at elpauer dot org
>
>
>
>> ___
>> desktop-devel-list mailing list
>> desktop-devel-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
>
> ___
> foundation-list mailing list
> foundation-l...@gnome.org
> https://mail.gnome.org/mailman/listinfo/foundation-list
>



-- 
Regards,

Zeeshan Ali (Khattak)

Befriend GNOME: http://www.gnome.org/friends/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

System services jhbuild

[Zeeshan Ali (Khattak)]

Hi everyone,

As many of you who use jhbuild regularly already know, system services
(NetworkManager, ModemManager, geoclue etc) do not actually work when
installed in custom prefixes as normal user. These services require to
be installed on system to work.

The result is that typically people either end up wasting their system
resources and time building stuff that they won't have any use at all
for, or putting these components in their skip list permanently.

Unless someone has plans on fixing this (somehow) soon, I would
suggest we either kick out all system services from jhbuild all
together or at least remove them from dependency list of other
modules.

-- 
Regards,

Zeeshan Ali (Khattak)

Befriend GNOME: http://www.gnome.org/friends/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: System services jhbuild

[Zeeshan Ali (Khattak)]

On Mon, Sep 8, 2014 at 6:32 PM, Frederic Peters fpet...@gnome.org wrote:
 Sriram Ramkrishna wrote:
 On Mon, Sep 8, 2014 at 9:55 AM, Zeeshan Ali (Khattak)
 zeesha...@gnome.org wrote:
 
  Unless someone has plans on fixing this (somehow) soon, I would
  suggest we either kick out all system services from jhbuild all
  together or at least remove them from dependency list of other
  modules.
 
 +1 for me,  It should try to use what is already on the system.

 It does (basically it sets PKG_CONFIG_PATH to also look into the
 system directories, so if you have networkmanager development files
 installed, it will find them), and it even automatically skip modules
 that are installed with a proper version (but it has to know the
 required minimum version, and we used to maintain that appropriately
 with external deps, less so thosedays).

1. Many users won't have the development packages installed for these
system services and thus this won't be any solution for them. What sri
meant (correct me if I'm wrong) is to simply leave system services to
system.

2. Not all services provide a library (e.g geoclue currently doesn't)
so deps are setup for runtime-only. In that case, build of such
services is almost always redundant.

 Also, while it's not possible to run system services, it may still be
 useful to have them in jhbuild, as they provide libraries that will be
 used by other modules. For example it is required to have
 accountsservice libraries to build and run gnome-control-center, but
 most panels will be fine if the service itself is not running.

If control-center would need latest of accountsservice, its likely
going to be because of new D-Bus API rather than just some convenience
API provided by the library, wouldn't it? If control-center (built in
jhbuild) can use the service from system at runtime, it can also use
the library from system?

 Besides, what is the end goal of jhbuild?  Is it to write code against
 the latest GNOME or is it to build a complete desktop environment?  I
 would argue that we already have gnome-continuous for the latter.
 Reducing jhbuild's scope would help make it an easier tool to manage
 and actually work.

 It would certainly be easier but I don't foresee the double goal of
 jhbuild changing much, because it still has to fulfil both in some
 ways (as it's made to run in a VM, I don't feel like gnome-continuous
 provides an appropriate testing/working environment).

 Still, we may envision changes; for example it's now possible to have
 conditional modules, so perhaps we could work to have it both ways,
 with a default set without the system services, and a flag to enable
 them, a la jhbuild --conditions=+system-services build.

Although I can totally agree with going for this approach, I still
wonder what would user really achieve with this? Why build things that
in the end will be useless?

-- 
Regards,

Zeeshan Ali (Khattak)

Befriend GNOME: http://www.gnome.org/friends/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Translation commits pushed when rolling a tarball

[Zeeshan Ali (Khattak)]

On Sat, Aug 2, 2014 at 9:37 AM, Ekaterina Gerasimova
kittykat3...@gmail.com wrote:
 On 01/08/2014, Zeeshan Ali (Khattak) zeesha...@gnome.org wrote:
 On Thu, Jul 31, 2014 at 5:24 PM, Sébastien Wilmet swil...@gnome.org wrote:
 Hi,

 Hi,

 At some rare occasions, especially after the string freeze, translation
 commits are pushed when rolling a tarball for making a new release.
 Since the commit for the release should be pushed only when 'make
 distcheck' has succeeded, there can be a push conflict and the
 maintainer have to repeat the process (sometimes several times).

 I think it would be nice to send mails on gnome-i18n and gnome-doc-list
 to explain that commits should not be pushed during the release days. If
 a translation or documentation commit is important, the maintainers can
 anyway be contacted on IRC to know if the commit can be pushed.

 I think there is no equivalent of 'svn lock' for git, so sending a mail
 is a solution.

 Bonus point is to add a warning on l10n.gnome.org, but it is more work.

 What do you think?

 +1.

 Is it too rare to care about this problem?

 I don't think so but being a maintainer for years, you'll learn to do
 `git push origin master` first always. :)

 As someone who makes releases, I always prefer to have the latest
 translation in the release, but I understand that running a distcheck
 on some of the larger projects can take a long time.

 From a documentation point of view, it doesn't make sense to block
 pushes for a whole day, especially as some maintainers release very
 late. Have you considered dropping an email to
 gnome-doc-l...@gnome.org and gnome-i...@gnome.org lists before running
 the distcheck? I found communicating with translators to be very
 effective and the docs team would prefer communication over a ban.

You mean send them email to not push translations? Are they all on
those lists and read their inbox each time before pushing changes? If
so, sure but then again the main issue (at least for me) is forgetting
(to run `git push master` rather than `git push master RELEASE`) so I
don't know what adding an additional manual step to remember would
achieve.

-- 
Regards,

Zeeshan Ali (Khattak)

Befriend GNOME: http://www.gnome.org/friends/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Translation commits pushed when rolling a tarball

[Zeeshan Ali (Khattak)]

On Sat, Aug 2, 2014 at 4:09 PM, Sébastien Wilmet swil...@gnome.org wrote:
 On Sat, 2014-08-02 at 15:55 +0200, Sébastien Wilmet wrote:
 On Sat, 2014-08-02 at 15:21 +0200, drago01 wrote:
  Well you could just create a branch do your release there so that you
  don't have to care about what happens on master (branches are free in
  git) and merge it back to master afterwards.

 In GNOME we generally prefer to have a linear git history, but creating
 a branch is indeed another solution.

 (replying to myself after a bit more thoughts)

 I think it's the best compromise. I've never thought about this solution
 because I always do a rebase on top of master. Thanks for the tip!

Actually thats what I usually do but trouble with this approach is
that I often then forget that I'm on the branch and assume everything
went fine after doing a successfull `git push origin master  git
push origin TAG`. Later I realize that master has changed and my tag
is not in its history. :(

-- 
Regards,

Zeeshan Ali (Khattak)

Befriend GNOME: http://www.gnome.org/friends/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Translation commits pushed when rolling a tarball

[Zeeshan Ali (Khattak)]

On Thu, Jul 31, 2014 at 5:24 PM, Sébastien Wilmet swil...@gnome.org wrote:
 Hi,

Hi,

 At some rare occasions, especially after the string freeze, translation
 commits are pushed when rolling a tarball for making a new release.
 Since the commit for the release should be pushed only when 'make
 distcheck' has succeeded, there can be a push conflict and the
 maintainer have to repeat the process (sometimes several times).

 I think it would be nice to send mails on gnome-i18n and gnome-doc-list
 to explain that commits should not be pushed during the release days. If
 a translation or documentation commit is important, the maintainers can
 anyway be contacted on IRC to know if the commit can be pushed.

 I think there is no equivalent of 'svn lock' for git, so sending a mail
 is a solution.

 Bonus point is to add a warning on l10n.gnome.org, but it is more work.

 What do you think?

+1.

 Is it too rare to care about this problem?

I don't think so but being a maintainer for years, you'll learn to do
`git push origin master` first always. :)

-- 
Regards,

Zeeshan Ali (Khattak)

Befriend GNOME: http://www.gnome.org/friends/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Requesting a libchamplain release

[Zeeshan Ali (Khattak)]

On Tue, Jul 1, 2014 at 9:17 AM, Ankur Sinha sanjay.an...@gmail.com wrote:
 Hi,

 Are there plans of making a new libchamplian release soon? I've updated
 to gnome 3.13 using the repository set up for Fedora 20[1]. At the
 moment, gnome-maps is unusable - it crashes on start. Upstream says it's
 a bug in libchamplain that has been fixed. It'll be nice to have a new
 release that will get the fix to users and make maps usable again.

The appropriate person and list has been notified of this:

https://mail.gnome.org/archives/libchamplain-list/2014-June/msg7.html

I'll wait for Jiri a day more and if he doesn't roll out a release,
I'll do that.

-- 
Regards,

Zeeshan Ali (Khattak)

Befriend GNOME: http://www.gnome.org/friends/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Geoclue needs your help!

[Zeeshan Ali (Khattak)]

On Wed, May 21, 2014 at 8:28 PM, Tomasz Torcz to...@pipebreaker.pl wrote:
 On Fri, Jan 24, 2014 at 08:06:09PM +, Zeeshan Ali (Khattak) wrote:
 The source makes use of the new Mozilla Location Service[1] and that
 being very new, does not have a lot of coverage. The good news is that
 they provide a web API and an android application to allow people to
 help them extend their coverage: Mozstumblr. I talked to our designers
 briefly about having a similar service/app in GNOME to be able to
 contribute data from GNOME itself as well but lack of GPS hardware
 makes it rather not that useful in the end.

 So what I would really appreciate is for you nice folks to consider
 installing Mozstumblr on your android phones (if you have one, that
 is) and make our geolocation framework work as well as we all want it
 to.

   Mozilla works one way with this Location Service.  They do collect
 data, but don't allow downloading them back:
 http://pavelmachek.livejournal.com/120952.html

There is a very good reason they don't let you download it:

https://wiki.mozilla.org/CloudServices/Location/FAQ#Can_I_download_the_entire_raw_database.3F

In short, the data isn't exactly theirs to give away freely.

   I don't think GNOME should encourage contributions to such closed,
 proprietary service.

None of the software is closed or proprietary. Its all availlable and
developed in open like a real free software:

https://github.com/mozilla/ichnaea
https://github.com/mozilla/MozStumbler

Moreover, you can easily create a service based on their service that
gives out data to everyone if you wish so but I don't see GNOME
needing to do so.

-- 
Regards,

Zeeshan Ali (Khattak)

Befriend GNOME: http://www.gnome.org/friends/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: REMINDER: GUADEC 2014 Call for Presentations is open

[Zeeshan Ali (Khattak)]

On Wed, Apr 16, 2014 at 12:07 AM, Emmanuele Bassi eba...@gmail.com wrote:
 hi all;

Hi Emmanuele,

 a friendly reminder: the Call for Presentations for GUADEC 2014 is
 still open, but you have time until the 4th of May to submit a
 proposal for presenting a talk in Strasbourg, this July.

Thanks for reminding, I had totally missed the announcements.


-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: TARBALLS DUE: GNOME 3.11.5

[Zeeshan Ali (Khattak)]

On Sun, Feb 2, 2014 at 8:34 AM, Frederic Peters fpet...@gnome.org wrote:
 Hello all,

Hi,

 It's FOSDEM weekend, if you're there, come and say hi! to the GNOME
 booth. Tomorrow, after you safely got home, it will be time to roll
 some tarballs for 3.11.5.

Thanks for the reminder. I think many people are still travelling on
Monday so I would request that we extend the tarballs deadline by a
day.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: New developer

[Zeeshan Ali (Khattak)]

On Tue, Jan 21, 2014 at 1:43 PM, Suyash Singh m...@suyashsingh.in wrote:
 Hello. I am a new developer with some experience in python and linux. I want
 to be a contributor to GNOME. I wanted to know from where should I start or
 If I could get some bugs assigned. Anything would be helpful.

Maciej already mentioned how to get started. If you want someone to
help you find a particular project to work on, you'll have to tell us
a bit about your interests and/or background.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Geoclue needs your help!

[Zeeshan Ali (Khattak)]

On Fri, Jan 24, 2014 at 8:15 PM, Hashem Nasarat hnasa...@gmail.com wrote:
 Thanks for your work!

Thanks for appreciation!

 I think you should write a blog post about this to get wider coverage.

I totally intend to. :)


-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Middle click, dumbing down Slashdotted

[Zeeshan Ali (Khattak)]

On Thu, Sep 26, 2013 at 12:34 PM, Ionut Biru io...@archlinux.ro wrote:

 Hello Allan,

 I'm asking you from the position of being a linux user that had used
 middle click for years, 10 or more.

 How often do you use this functionality in your daily use of gnome?
 please answer honestly and I want a straight answer, don't give me a
 marketing  answer.

I'm hardly a marketing guy and I've used this feature for as long as
I've used Linux IIRC (~13 years). However, me being extremely habitual
of a feature and it being there for decades does not imply its a good
feature that must be retained as is. The way it currently works is
very confusing. Despite the fact that I take it for granted, I keep
pasting the wrong buffer.

 The proposed designed is broken from start.

That might be so but that is true for the feature its replacing as
well and if we try to address the problem, we are likely to arrive at
a good solution at the end (Remember that is not set in stone or
anything).

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Opening the 3.12 cycle

[Zeeshan Ali (Khattak)]

On Tue, Sep 24, 2013 at 10:03 AM, Andrew W. Nosenko
andrew.w.nose...@gmail.com wrote:
 On Mon, Sep 23, 2013 at 10:58 PM, Jasper St. Pierre
 jstpie...@mecheye.net wrote:
 On Mon, Sep 23, 2013 at 3:50 PM, Andy Tai a...@gnu.org wrote:

 what would this mean for systems not using systemd?


 Systems not using systemd already fall back to ConsoleKit, which does not
 have any maintainer. We don't support features like suspend or hibernate on
 ConsoleKit anymore and it's pretty much on life support only at this point.

 For 3.12, we will keep the old gnome-session and gdm code that uses
 ConsoleKit and fork/exec ourselves in the case where you compile without
 logind support, but I wouldn't expect it to be around much longer.

 Do you have any specific examples of systems not using systemd that you
 would like to run GNOME on?


 Did you heard about FreeBSD?

How many people use FreeBSD? I doubt its a significant enough number
for us to spend our time and resources on it.

 PS. Do you know any OS that _uses_ systemd at all beside Linux?

But apparently its the only free OS worth caring about. I think Jasper
was asking about distros as I'm pretty sure he is well aware that
systemd doesn't run on an archaic OSs, such as FreeBSD.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Opening the 3.12 cycle

[Zeeshan Ali (Khattak)]

On Tue, Sep 24, 2013 at 4:44 PM, Zeeshan Ali (Khattak)
zeesha...@gnome.org wrote:
 On Tue, Sep 24, 2013 at 10:03 AM, Andrew W. Nosenko
 andrew.w.nose...@gmail.com wrote:
 On Mon, Sep 23, 2013 at 10:58 PM, Jasper St. Pierre
 jstpie...@mecheye.net wrote:
 On Mon, Sep 23, 2013 at 3:50 PM, Andy Tai a...@gnu.org wrote:

 what would this mean for systems not using systemd?


 Systems not using systemd already fall back to ConsoleKit, which does not
 have any maintainer. We don't support features like suspend or hibernate on
 ConsoleKit anymore and it's pretty much on life support only at this point.

 For 3.12, we will keep the old gnome-session and gdm code that uses
 ConsoleKit and fork/exec ourselves in the case where you compile without
 logind support, but I wouldn't expect it to be around much longer.

 Do you have any specific examples of systems not using systemd that you
 would like to run GNOME on?


 Did you heard about FreeBSD?

 How many people use FreeBSD? I doubt its a significant enough number
 for us to spend our time and resources on it.

 PS. Do you know any OS that _uses_ systemd at all beside Linux?

 But apparently its the only free OS worth caring about. I think Jasper
 was asking about distros as I'm pretty sure he is well aware that
 systemd doesn't run on an archaic OSs, such as FreeBSD.

Sorry it came out so harsh. I only intended to make it clear that
Linux is the main (if not, the only) target most GNOME developers
focus on. Jasper said it much better. Anyway, apologies.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Opening the 3.12 cycle

[Zeeshan Ali (Khattak)]

On Tue, Sep 24, 2013 at 5:02 PM, Alberto Ruiz ar...@gnome.org wrote:
 Hey Andrew,  Zeeshan,

 2013/9/24 Zeeshan Ali (Khattak) zeesha...@gnome.org:
 On Tue, Sep 24, 2013 at 10:03 AM, Andrew W. Nosenko
 andrew.w.nose...@gmail.com wrote:
 On Mon, Sep 23, 2013 at 10:58 PM, Jasper St. Pierre
 jstpie...@mecheye.net wrote:
 On Mon, Sep 23, 2013 at 3:50 PM, Andy Tai a...@gnu.org wrote:

 what would this mean for systems not using systemd?


 Systems not using systemd already fall back to ConsoleKit, which does not
 have any maintainer. We don't support features like suspend or hibernate on
 ConsoleKit anymore and it's pretty much on life support only at this point.

 For 3.12, we will keep the old gnome-session and gdm code that uses
 ConsoleKit and fork/exec ourselves in the case where you compile without
 logind support, but I wouldn't expect it to be around much longer.

 Do you have any specific examples of systems not using systemd that you
 would like to run GNOME on?


 Did you heard about FreeBSD?

 How many people use FreeBSD? I doubt its a significant enough number
 for us to spend our time and resources on it.

 Really? How many people use GNU/Linux distros? From that POV we are
 better off targeting Android. I don't think GNOME is in the OS
 popularity contest.

Android is not free, I said 'free'. If FreeBSD had users comparable to
that of Linux, why is it that in almost every other free software
project, developers target Linux first, if they target any other free
OS at all. We can't buildup a complete system based on Android anyway
even if it was free since its already a complete system.

 There are much more compelling answers to Andrew's request, and I for
 one would like to see people working on getting GNOME working on BSD's
 as long as they understand that the majority of people run Linux and
 that we are trying to achieve a certain level of integration with the
 OS and that we expect certain features and services to achieve GNOME's
 goals.

 People can get GNOME working on the *BSDs, but is the developers
 running those OSes the ones that have to figure out a way to catch up
 with Linux and work with upstreams, it's just not realistic

Surely. As I already apologized, FreeBSD users should just go away
is not at all what I meant to say. However, my rather impolite comment
was in reply to his comment that sounded very much like Why are you
guys not caring about FreeBSD?.

 PS. Do you know any OS that _uses_ systemd at all beside Linux?

 But apparently its the only free OS worth caring about. I think Jasper
 was asking about distros as I'm pretty sure he is well aware that
 systemd doesn't run on an archaic OSs, such as FreeBSD.

 Worth caring about? I care about any OS that has an OSI approved
 license, I happen to run some incarnation of GNU/Linux and I try to
 make things work on that one because it's the one I use. But that
 doesn't mean that other OSes are not worthy of care by other people.
 It's just up to those people to try to get things running on it.

By not caring about, I mean us not thinking about it when we design
and implement various GNOME components. That is a fact and unless
there is some FreeBSD developers stepping-up and changing that, it
will remain to be the case. I only intended to make this clear. Once
again, I apologise that it came out so harshly and apparently also so
misleading.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Passive resistance [was: Re: Announcing GNOME's official GitHub mirror]

[Zeeshan Ali (Khattak)]

On Sun, Aug 25, 2013 at 11:54 AM, fr33domlover fr33domlo...@mailoo.org wrote:
 I'm not a module maintainer, just a community member trying to make sure
 you don't make your relation to GitHub tighter than it already is.

...

 I don't believe anyone has the right or the ability to decide what's
 more important in the name of all the contributors to GNOME or the whole
 community of users, which is why I suggest a switch: Let maintainers
 turn off the mirroring. Let them decide how they fight centralization.
 After all, they're the ones who do the actual work, not the few people
 who make decisions.

 Straight people can fight for gay people's rights. And I can fight for
 maintainers' rights.

Exactly how many maintainers have shown interest in this? I think most
of us are way too busy trying our best to make Free Software as
awesome as we possibly can that we can't be bothered by such
non-issues. As maintainer of some of the GNOME modules, I'm asking you
to stop this please.

I know you mean well and If you really want to help, I have like a
gazillion things on my TODO list that most people on this list will
agree are essential to world domination of GNOME (and therefore Free
Software). Contact me privately and I can provide you with a list.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Correct .doap file syntax for the name tag

[Zeeshan Ali (Khattak)]

On Thu, Aug 22, 2013 at 1:28 PM, Andrea Veri a...@gnome.org wrote:
 No, sorry for not pointing that out on my previous email, you can use a
 name tag of your choice but it would be simply awesome to have all the
 GitRepositories tags in place.

Would be nice if you revert your relevant commits to repositories now :)

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: New libgtop maintainer

[Zeeshan Ali (Khattak)]

On Sat, Aug 10, 2013 at 3:09 PM, Robert Roth robert.roth@gmail.com wrote:
 On Sat, Aug 10, 2013 at 2:42 PM, Matthias Clasen matthias.cla...@gmail.com
 wrote:

 On Fri, Aug 9, 2013 at 4:31 PM, Robert Roth robert.roth@gmail.com
 wrote:


  My goals for the 3.12 cycle (as we're getting close to the 3.9 freeze,
  only
  for the next cycle) are to review the buglist of the module, and extend
  it
  to provide library support for various gnome-system-monitor enhancement
  requests, but in the meantime keep it simple and fast enough to back the
  upcoming Usage application.

 Tbh, I think it would be good to start out by reevaluating the
 rationale for this library. Do we really need it anymore ? What data
 does g-s-m get from it ?

 For storage-related data, gio has probably
 encroached into the territory already.


 You might be right on that, I will check what GIO can do.

 For other data, libgtop is
 mostly a thin wrapper of /proc, iirc.

 Thas is true for linux systems, but libgtop also supports some BSDs, and
 other systems, which don't seem to have a procfs

Before we take this fact into consideration here, perhaps we should
first find out if a modern GNOME system actually work on BSD. We
wouldn't want to end up like some projects where they create several
abstraction layers to ensure portability and then have only one
working implementation underneath.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [Fwd: Geoclue2 merge into Geoclue master]

[Zeeshan Ali (Khattak)]

On Sun, Aug 4, 2013 at 4:18 PM, Zeeshan Ali (Khattak)
zeesha...@gnome.org wrote:
 On Sun, Aug 4, 2013 at 11:42 AM, Bastien Nocera had...@hadess.net wrote:
 Em Sat, 2013-08-03 às 19:18 -0400, Colin Walters escreveu:
 A bit of a scramble, but I've got the gnome-ostree builder now tracking
 geoclue master again.  I had to disable geolocation support in
 webkitgtk, but that's not a big deal because it doesn't really work in
 VMs anyways.

 But do you know if there's a patch for webkitgtk?

 Not yet, but WebKitGTK+ and Firefox support is something that we'll need
 to work on. We also have a number of bits that will need porting in the
 GNOME stack itself (Empathy and Evolution using old APIs for
 geocode-glib) and stuff that will need porting to Geoclue2.

 Oh and before we start porting apps, I must move geoclue to system bus.

Done! Shall i already move ipclient from geocode-glib to geoclue?

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [Fwd: Geoclue2 merge into Geoclue master]

[Zeeshan Ali (Khattak)]

On Sun, Aug 4, 2013 at 11:42 AM, Bastien Nocera had...@hadess.net wrote:
 Em Sat, 2013-08-03 às 19:18 -0400, Colin Walters escreveu:
 A bit of a scramble, but I've got the gnome-ostree builder now tracking
 geoclue master again.  I had to disable geolocation support in
 webkitgtk, but that's not a big deal because it doesn't really work in
 VMs anyways.

 But do you know if there's a patch for webkitgtk?

 Not yet, but WebKitGTK+ and Firefox support is something that we'll need
 to work on. We also have a number of bits that will need porting in the
 GNOME stack itself (Empathy and Evolution using old APIs for
 geocode-glib) and stuff that will need porting to Geoclue2.

Oh and before we start porting apps, I must move geoclue to system bus.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Smoketesting 3.9.5 release

[Zeeshan Ali (Khattak)]

On Tue, Jul 30, 2013 at 10:52 AM, Luca Ferretti lferr...@gnome.org wrote:
 Hi everyone,

 a preliminary version of 3.9.5 modules files is available at
 ftp://ftp.gnome.org/pub/GNOME/teams/releng/3.9.5

 There are several missing fresh modules, so I suppose I'll update in the
 next hours.

I made sure to get gnome-maps and its deps out in time but I don't see
it in the modules list. Was it included?

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GSoC 2013] Ability to save and load virtual machine boxes

[Zeeshan Ali (Khattak)]

On Sat, Apr 20, 2013 at 3:04 AM, Nikhil Siddhartha
nikhilsiddhar...@gmail.com wrote:
 Hi everyone,

Hi,

 I am a third year student of Computer Science at IIIT Hyderabad, Hyderabad,
 India. I am very interested in doing the project mentioned in the subject
 (Ability to save and load virtual machine boxes). I believe, I believe, I
 have sufficient experience and skills required for this project.

 I have some experience of working with technologies like libvirt and virtual
 machines. I have done a project titled 'A Virtualization Orchestration
 Layer', which is written in Python and included technologies like libvirt. I
 am also well versed in C/C++.

Cool.

Here is what you need to do:

* Get Boxes built from git repository (jhbuild[1] is your best bet!)
* Once you have done that, try it out and if you can find bugs, please
do file them.
* If any of the bugs you filed are trivial (we can help you out in
making that assertion), you want to dive into the code and submit
fixes for these bugs.
* If you don't find any trivial bugs yourself, see if you can find one
from open bugs[2].
* if there is still nothing, we can help you find some trivial ones.

At the same time you want to prepare a good proposal with a concrete
plan of action.

You'll probably get into problems with jhbuild and will have specific
questions. There is IRC channel and mailing-list where you can contact
us for help[3]. Please keep in mind that most of us are in Europe/US
so timezone might be an issue. Just saying that please be patient if
you don't get replies in time.

--
Regards,

Zeeshan Ali (Khattak)
FSF member#5124

[1] http://live.gnome.org/Jhbuild
[2]https://bugzilla.gnome.org/buglist.cgi?emailassigned_to1=1;query_format=advanced;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;email1=gnome-boxes-maint;product=gnome-boxes;classification=Applications;emailtype1=substring
[3]https://live.gnome.org/Boxes/#Mailing_List_and_IRC
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: About clutter-gtk and his lack of accessibility support

[Zeeshan Ali (Khattak)]

On Thu, Feb 14, 2013 at 9:08 PM, Matthias Clasen
matthias.cla...@gmail.com wrote:
 On Thu, Feb 14, 2013 at 12:11 PM, Piñeiro apinhe...@igalia.com wrote:

 Here is what I am seeing on my system right now:

 [mclasen@golem ~]$ rpm -q --whatrequires libclutter-gtk-1.0.so.0()(64bit)
 libchamplain-gtk-0.12.3-5.fc19.x86_64
 cheese-libs-3.7.4-2.fc19.x86_64
 totem-3.6.3-3.fc19.x86_64
 cheese-3.7.4-2.fc19.x86_64
 gnome-photos-3.7.3-4.fc19.x86_64
 gnome-initial-setup-0.6-2.fc19.x86_64
 eog-plugins-3.6.1-2.fc19.x86_64
 gnome-games-gnibbles-3.6.1-2.fc19.x86_64
 gnome-games-quadrapassel-3.6.1-2.fc19.x86_64
 gnome-games-swell-foop-3.6.1-2.fc19.x86_64
 gnome-games-lightsoff-3.6.1-2.fc19.x86_64
 empathy-3.7.5-2.fc19.x86_64
 gnome-color-manager-3.7.5-1.fc19.x86_64
 gnome-boxes-3.7.5-1.fc19.x86_64
 control-center-3.7.5.1-1.fc19.x86_64
 sushi-3.7.5-1.fc19.x86_64
 gnome-documents-3.7.5-1.fc19.x86_64

 A few of these will probably follow the gnome-documents example and
 shed the clutter-gtk dependency in time for 3.8, and for some others,
 having the (small) clutter parts inaccessible may not be a big deal
 (e.g. the photo dialog in the user panel). It might help your decision
 to evaluate a few of these apps to see how much their accessibility is
 affected by clutter-gtk use - it might turn out that everything except
 for documents, boxes and photos is fine... and if those 3 move to pure
 gtk in time for 3.8, all is good.

We're making extensive use of clutter-gtk in Boxes so moving away from
it in time for 3.8 does not sound realistic.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: TARBALLS DUE: GNOME 3.7.5

[Zeeshan Ali (Khattak)]

On Mon, Feb 4, 2013 at 12:22 PM, Frederic Peters fpet...@gnome.org wrote:
 Hello all,

Hi,

 Many of us were at FOSDEM and we failed to send the announcement
 before but you knew it was coming, here's the call for tarballs
 for GNOME 3.7.5!

I pushed the tag for Boxes 3.7.5 and uploaded the tarball but can't
seem to be able to install it: http://paste.stg.fedoraproject.org/3649

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Dropping gupnp-vala

[Zeeshan Ali (Khattak)]

On Fri, Nov 30, 2012 at 1:48 PM, Jens Georg m...@jensge.org wrote:
 Hi,

 Since the last gupnp-* unstable releases, gupnp-vala is more or less
 obsolete since all of them generate the vala bindings themselves now
 from gobject-introspection.

Awesome!

 Looking at the modulesets, Rygel is the only project that depends on
 gupnp-vala and I've already removed that dependency.

 Is everyone ok with dropping gupnp-vala completely from 3.8 (and later)
 -apps or did I overlook something?

Even if you have overlooked some app that uses the vala bindings,
they'll not notice anything changing under their feet. So I'll say go
ahead and remove it.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Introducing Boxes non-free

[Zeeshan Ali (Khattak)]

Hi,
  In the light of protests against Boxes package shipping non-free
logos[1], we have put them under a different repository and package
now. Since we don't anticipate changes to this package happening
between every GNOME release (there isn't even translations involved),
I decided to not tag it by GNOME releases.

Release tarball available at:
http://download.gnome.org/sources/gnome-boxes-nonfree/0.0/

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124

[1] https://bugzilla.gnome.org/show_bug.cgi?id=671251
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Introducing Photos

[Zeeshan Ali (Khattak)]

On Thu, May 10, 2012 at 7:50 PM, Alberto Ruiz ar...@gnome.org wrote:
 Shotwell is widely deployed and used, it has a team of people working on it,
 and a commercial backer. These are VERY important things, prolly the most
 important things to take into account, you worry too much about the data
 store technologies, Tracker is great, but it is by no means the only
 accepted data store in the desktop.

The point is that we already use Tracker in GNOME (Documents and Boxes
depend on it) and I don't see any reason for existing apps to stop
using it and while we could compromise on some code-duplication, its
certainly a big issue if there is two entities harvesting metadata
from tons of photos on every GNOME installation.

 If Yorba is open to follow the designs from the GNOME design team, I can't
 see any reason why we shouldn't go that way. IMHO is the quickest and more
 sustainable path to have a great photo browsing experience for GNOME 3.

+1 and its really nice to see that Yorba is very serious about GNOME
integration. Having said that I do feel that they need to do a bit
more on this front. For starters they really should use our infra
(bugzilla, git, mailing-list etc).

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: multiple vala versions in 3.4

[Zeeshan Ali (Khattak)]

On Mon, Jan 23, 2012 at 9:53 AM, Emmanuele Bassi eba...@gmail.com wrote:
 hi Zeeshan;

Hi Emmanuele,

 On 23 January 2012 02:14, Zeeshan Ali (Khattak) zeesha...@gnome.org wrote:
 On Sun, Jan 22, 2012 at 11:50 PM, Christophe Fergeau t...@gnome.org wrote:
 2012/1/21 Zeeshan Ali (Khattak) zeesha...@gnome.org:

 There are way
 too many of the libraries to take care of and on top of that they
 change all the time. Ideally each library should be providing vala
 bindings and take care of keeping it up2date. So its really not a
 fault of vala itself.

 I don't agree with this assessment.

 you're just deferring the issue to every library under the sun, and
 this is very much problematic in a variety of reasons:

 - as a maintainer, now I'd have to care not only about introspection,
 but also about a vapi file - which is another redundant format that
 expresses the library's API; so the first thing I'd look at would be
 generating the latter in terms of the former, which introduces a build
 dependency (albeit optional) on Vala. so it's my library that now has
 to deal with the compiler and generator bugs. yeah, right: not going
 to happen.

What I was proposing wasn't so different from what you are saying
here. Vala bindings should still be generated out of gir bindings but
since gir doesn't support some of the essential features that vala
apps have been depending on for some time now, we'll need to have
*some* vala-specific metadata, at least until gir supports those
features.

If having any vala-specific metadata in a few libraries isn't
acceptable to maintainers, yeah we should first separate out the
bindings into another package and then push the bindings that are
purely generated from gir to their respective libraries.

BTW just for the record, It should be noted that gir is the cause of
the problem here not vala.

 - I have used Vala, but I'm not an expert on figuring out its quirks,
 nor am I using it for my day to day work; this means that I'll have to
 rely on Vala developers to update the Vala bindings. this means that
 Vala developers and users will now need to go through various bugzilla
 products and git repositories to fix the Vala bindings in each and
 every project that ships one.

They'll have to go through the same procedures as python and
javascript users so I don't think this is an issue. Actually this will
give good motivation to vala developers to fix/improve your gir
annotations for you.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: multiple vala versions in 3.4

[Zeeshan Ali (Khattak)]

On Sun, Jan 22, 2012 at 11:50 PM, Christophe Fergeau t...@gnome.org wrote:
 2012/1/21 Zeeshan Ali (Khattak) zeesha...@gnome.org:

 Being a maintainer of 2 vala projects in GNOME, I can tell you that
 valac itself is pretty stable these days and it gets more and more
 stable all the time. The issue is the bindings usually.

 Yup, though it's still not unusual to hit vala compiler bugs unfortunately

 There are way
 too many of the libraries to take care of and on top of that they
 change all the time. Ideally each library should be providing vala
 bindings and take care of keeping it up2date. So its really not a
 fault of vala itself.

 Well, when people say vala, they mean what's in vala.git or the vala
 tarball. I agree there is a difference between vala-the-language and
 vala-the-bindings, but since they are shipped as a single entity, vala
 = vala-the-language + vala-the-bindings, it's not really useful to
 consider them separately. My feeling is that shipping the 2 separately
 might help (people may be able to keep using vala-the-language from
 their distro, but some module would require very new vala-the-bindings
 tarballs). Dunno how practical that would be.

I see your point and agree with your solution but as a plan-B. In case
we encounter heavy resistance against pushing individual bindings to
respective libraries, lets look into this option.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: multiple vala versions in 3.4

[Zeeshan Ali (Khattak)]

On Sun, Jan 22, 2012 at 2:36 AM, Antono Vasiljev s...@antono.info wrote:
 On 01/21/2012 11:44 AM, Steve Frécinaux wrote:

 Libraries already maintain gobject introspection files, and valac is
 supposed to use those these days isn't it?

 No. Unless gir format will be fixed to allow nested namespaces.

While it is true that ideal scenerio would be for Vala to simply use
gir/typelib but gir is missing features supported by vala and its
bindings for many years now. Nested namespace is one of them. Another
example is default values for parameters.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: multiple vala versions in 3.4

[Zeeshan Ali (Khattak)]

On Fri, Jan 20, 2012 at 2:30 PM, Matthias Clasen
matthias.cla...@gmail.com wrote:
 On 01/19/2012 10:32 PM, Colin Walters wrote:

 But others (folks at least) fail to compile with 0.15.


 This question might seem a little naive, but could someone highlight me why
 the vala compiler can't stay backward compatible from release to release?

 Indeed. Until vala grows up a little more, its increasing use in the
 desktop is a growing problem.

Being a maintainer of 2 vala projects in GNOME, I can tell you that
valac itself is pretty stable these days and it gets more and more
stable all the time. The issue is the bindings usually. There are way
too many of the libraries to take care of and on top of that they
change all the time. Ideally each library should be providing vala
bindings and take care of keeping it up2date. So its really not a
fault of vala itself.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Boxes and 3.4

[Zeeshan Ali (Khattak)]

On Thu, Dec 1, 2011 at 12:32 AM, Andrew Cowie
and...@operationaldynamics.com wrote:
 On Wed, 2011-11-30 at 14:15 +0100, Luca Ferretti wrote:

 And, in suborder, why can't Boxes be simply a non-core, featured
 application, just like GIMP or Simple Scan?

 Because there's a big difference between an integrated, designed,
 polished, documented and translated GNOME app and something that happens
 to use GTK, right?

 Just because it isn't targeted at core audience doesn't mean that it
 shouldn't be an awesome part of GNOME if you happen to be in an
 alternate space. You know, like IT professionals?

 We're getting *ransacked* out there in discussions in LUGs around the
 world (e.g. [1]) because power users are trying GNOME 3 have found it
 totally interferes with their accustomed workflows. Unhappy campers. If
 people in LUGs have the idea that GNOME 3 is no use for them, do you
 really think they're going to push for its adoption in the wider company
 that they have to support?

 So the whole discussion about whether Boxes is core or not is
 ridiculous. If it meets the standards of being a good GNOME app (HIG, oh
 HIG, where art thou HIG) then it should be endorsed and promoted.
 Period.

While I greatly appreciate your support for Boxes here, I must inform
you that Boxes is *not* targeted for IT professionals. For that we
have virt-manager and oVirt.

Regarding the rationale of Boxes as a core app, I think we definitely
need something to nicely handle insertion of an OS installer or live
media. The best thing to do in that scenerio is the creation and
launch of a VM (box) and Boxes already does that for you. Without
Boxes as part of every GNOME installation, we won't have this working
out of the box and bore the users by showing them files on the media.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Boxes and 3.4

[Zeeshan Ali (Khattak)]

On Thu, Dec 1, 2011 at 4:49 AM, Zeeshan Ali (Khattak)
zeesha...@gnome.org wrote:
 On Thu, Dec 1, 2011 at 12:32 AM, Andrew Cowie
 and...@operationaldynamics.com wrote:
 We're getting *ransacked* out there in discussions in LUGs around the
 world (e.g. [1]) because power users are trying GNOME 3 have found it
 totally interferes with their accustomed workflows. Unhappy campers. If
 people in LUGs have the idea that GNOME 3 is no use for them, do you
 really think they're going to push for its adoption in the wider company
 that they have to support?

 So the whole discussion about whether Boxes is core or not is
 ridiculous. If it meets the standards of being a good GNOME app (HIG, oh
 HIG, where art thou HIG) then it should be endorsed and promoted.
 Period.

 While I greatly appreciate your support for Boxes here, I must inform
 you that Boxes is *not* targeted for IT professionals. For that we
 have virt-manager and oVirt.

   Don't get me wrong please. I'm sure Boxes *will* satisfy many IT
professionals as well and we will try our best to support their
use-cases as long as those use-cases do not conflict with that of a
typical end-user.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Boxes and 3.4

[Zeeshan Ali (Khattak)]

Hi everyone,
   As most of you know, we proposed Boxes for 3.4 and from what I can
tell, there were no big objections in the end. There was then the
question of us actually delivering in time. As seen on planet GNOME
not long after that, we delivered the first release which was included
in 3.3.2. There is still a long way ahead to make Boxes the awesome
app that we all would like it to be but to ensure that Boxes is in
good enough shape for 3.4 inclusion in time, we would like to know a
few things:

* which features exactly are must?
* is the plan to keep vinagre in 3.4 alongside boxes?
* is Boxes going to be a 'preview' feature in 3.4 like Documents was in 3.2?

 Release team? everyone?

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Boxes (was Re: 3.4 Features, final round)

[Zeeshan Ali (Khattak)]

On Mon, Nov 7, 2011 at 9:00 AM, Vincent Untz vu...@gnome.org wrote:
 Le dimanche 06 novembre 2011, à 17:06 +0100, Frederic Peters a écrit :
 + Boxes
   https://live.gnome.org/ThreePointThree/Features/Boxes
   → many commits, mclasen will push the developers to blog a progress report
     once they have something to show

 While Boxes look interesting, to me, it feels like it's just an
 application, and not a feature per se. And I'm not saying that in a
 negative way :-)

  You are correct in the sense that it is 'an' application and not 'a'
feature. It is more like 2 essential features combined in one:

1. Remote display: It is very common to own/having to deal with
multiple machines these days so many users really need ability to
easily connect to remote machines (virtual and real).

2. Trying out OSs: Each time we release GNOME, I really want to try it
out and I know many people who do. Same goes for distros but people
usually try to avoid risks and therefore most people wait till the OS
in question is stable enough. I have even seen people avoid trying out
an OS just because they are too scared of it doing any harm to their
computers. Users will definitely appreciate an easy and completely
secure way to try out OSs.

   I think these features are very essential and therefore should be
available in every GNOME installation out of the box.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Features !

[Zeeshan Ali (Khattak)]

Hi Mathias,

On Wed, Oct 5, 2011 at 11:17 PM, Matthias Clasen
matthias.cla...@gmail.com wrote:
 Hey,

 so according to the draft schedule that Andre posted a while ago, we
 are in the middle of the 'feature proposal' period right now. I
 haven't seen much feature discussion here at all yet, and so far, the
 wiki only lists things that I have put there, which is a little scary
 - I can't be the only one itching to get cool things into GNOME 3.4.

 Where are your ideas ? It would be great to get them onto that wiki
 page, in particular since next weekend a bunch of us will get together
 in Montreal to, among other things, spend time to talk about 3.4
 features.

  Was wondering if we could take-up this forgotten feature planned for
3.1: https://live.gnome.org/ThreePointOne/Features/Sharing

  AFAIK, the issue was that designers were way too busy with more
important features in 3.1 so they didn't get any time for this one.
Lapo has started to investigate this it seems and last I asked
Bastien, he was also interested(?) in getting this done in 3.3 cycle.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: From here to apps

[Zeeshan Ali (Khattak)]

On Mon, Sep 26, 2011 at 1:09 PM, Frederic Peters fpet...@gnome.org wrote:

 Speaking of Vinagre, it even has Implement some of the ideas from
 GNOME desktop sharing/virtualisation design mockups on its roadmap
 for 3.4 (see https://live.gnome.org/Vinagre/RoadMap).

  I assume you are referring to Boxes here[1]. If you look at the
tentative designs, the UI is significantly different from that of
vinagre and virt-manager to justify writing of this UI from
scratch[2]. Apart from the UI, I don't see how much of vinagre code
could be useful to us since AFAIK most of the functionality is
provided by spice-gtk  (Marc-Andre?). Moreover, vinagre doesn't do any
VM management, which is a significant part of Boxes idea. There is a
conflict with virt-manager in that area (as you noticed) but we are
working closely with Daniel P. Berrange on the framework side so that
most (if not all) of this 'conflict' is limited to UI only.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124

[1] https://live.gnome.org/Design/Apps/Boxes
[2] Since many components of UI are common with Documents, I intend to
re-use/steal code from there.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Launching an application requires too many mouse clicks in Gnome 3

[Zeeshan Ali (Khattak)]

On Sun, Sep 4, 2011 at 9:25 AM, Xavier Cho fender_ru...@yahoo.co.kr wrote:
 In that case, we can just remove the application menu altogether and let
 them alt-f2 type commands to launch applications.

  Thats not the same thing at all. In case of alt-f2, user has to know
the exact and complete name of the application. Where as in overview
mode, she/he just
types a few letters of either the name of the command or the generic
name. For example, typing 'mus' in the overview-mode brings-up
rhythmbox as the only option.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

gudev from my grandpa

[Zeeshan Ali (Khattak)]

Hi everyone,
  David Zeuthen pointed out that gudev in jhbuild (3.2 modulesets) is
several years old (from 08-Dec-2004) and we really should use some
recent enough release of it. Is there a particular reason we are doing
this or shall I fix this?

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gudev from my grandpa

[Zeeshan Ali (Khattak)]

On Thu, Aug 25, 2011 at 1:30 PM, Andre Klapper ak...@gmx.net wrote:
 On Thu, 2011-08-25 at 13:23 +0300, Zeeshan Ali (Khattak) wrote:
 Hi everyone,
   David Zeuthen pointed out that gudev in jhbuild (3.2 modulesets) is
 several years old (from 08-Dec-2004)

 For the records,
 http://git.gnome.org/browse/jhbuild/tree/modulesets/gnome-suites-core-deps-3.2.modules
  says module=utils/kernel/hotplug/udev-147.tar.bz2 version=147.
 That's 10-Nov-2009 according to
 https://www.kernel.org/pub/linux/utils/kernel/hotplug/

 047 is from 08-Dec-2004.

  Ah, sorry! My dyslexia kicks-in sometimes. However, thats still
pretty old so my question remains.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gudev from my grandpa

[Zeeshan Ali (Khattak)]

On Thu, Aug 25, 2011 at 2:36 PM, Olav Vitters o...@vitters.nl wrote:
 On Thu, Aug 25, 2011 at 01:34:36PM +0300, Zeeshan Ali (Khattak) wrote:
   Ah, sorry! My dyslexia kicks-in sometimes. However, thats still
 pretty old so my question remains.

 We upgrade if needed. Keeping the requirements low makes it easier to
 use stuff from your distribution.

  Please note that I was talking of providing a newer gudev in
jhbuild, not bump the minimum requirement.

 Is a newer version needed?

   Not for me so far, just that davidz said lots of bugs have been
fixed since version 147.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME user survey 2011 (v4)

[Zeeshan Ali (Khattak)]

On Fri, Aug 19, 2011 at 2:17 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
  I didn't say this so far because it might sound like I am trying to
 make a joke but since you still insist on your assertions about the
 survey, I feel I must say this: How do you know people in general like
 to participate in surveys? It is my observation that most people do
 not like to do that, unless they have something to complain about. Now
 this observation of mine could very well be wrong but how do we know
 that? Do we do a survey to find out if people like to participate in
 surveys?

 Are you serious? That totally and completely speculative and
 unrealistic.

 What is speculative? I made it very clear that it is *my* observation
and *if* it is correct, the results of this survey may very well be
wrong. Do you have any evidence that suggests that my observations
above are incorrect?

 Have you ever participated in making a survey?

  No I have not but that does not necessarily mean what I said is
incorrect and could just be ignored by pointing to examples of other
surveys. If other people are ignoring an important issue, doesn't mean
we should do the same.

 I have, as
 I have explained, for the Git survey. In my experience, only the
 people that want to help in some way do spend the amount of time
 required to fill the survey.

  As I have explained to you many times before, git's user-base is
mostly (if not all) geeks and those geeks know where the mailing-list
is and be able to access the survey easily. Still, I am a geek and a
very happy user of git but I didn't even know about the existence of
this survey until you told me. Even then, I didn't care to
participate. I am pretty sure I would have cared to participate if I
had something to complain about its current or planned features.
GNOME's user-base consists of people who do not even know what GNOME
is so many of them will not be able to participate, especially if they
are happy users.

  In short, example of git surveys are quite irrelevant here.

 But again, as I said, if there's no survey on Earth you could trust,
 just ignore the results. Results by themselves cannot hurt you.

  In this case those results will really hurt since then you will have
some numbers to back-up your claim of GNOME 3 is completely
unusable. *If* your motivation for this survey has remained the same,
you'll spread a lot of negative propaganda (which you already did even
when you didn't have any numbers) and many people will just say Oh,
people don't like this gnome 3 thingie, must be shit and will stay
away from it. Even if you don't do that, there is many others who will
use this data in that way.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME user survey 2011 (v4)

[Zeeshan Ali (Khattak)]

On Fri, Aug 19, 2011 at 10:12 AM, Luc Pionchon pionchon@gmail.com wrote:
 On Fri, Aug 19, 2011 at 03:34, Zeeshan Ali (Khattak) zeesha...@gnome.org
 wrote:

 [snip]

  Maybe they all lied?

 Don't you think it is a bit early to speculate on results? (...)


 Overall I can see already one clear result, even before the poll has
 started:

 We do not know who is using GNOME.



 Maybe this needs reflexion

  No, in the current scenario that is actually a success story. Maybe
this will change when GNOME OS becomes a reality.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME user survey 2011 (v4)

[Zeeshan Ali (Khattak)]

On Thu, Aug 18, 2011 at 11:57 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
 On Wed, Aug 17, 2011 at 11:12 PM, Jason D. Clinton m...@jasonclinton.com 
 wrote:
 How about an application that pops notifications similar to this one?
 Would such a thing be accepted?

 You haven't yet addressed the problems that I pointed out.

 You haven't yet provided any suggestion.

  You are the one who proposed the idea of this survey and (more
importantly) insist that a useful survey is possible for GNOME so
*you* must address all criticism/concerns if you want us to take your
proposal seriously. Ignoring input from others just because they don't
have a solution for the problem(s) they point out isn't going to lead
anywhere.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME user survey 2011 (v4)

[Zeeshan Ali (Khattak)]

On Fri, Aug 19, 2011 at 12:45 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:

 Nothing is ever perfect, but having at least some results is better
 than nothing.

  Since you have repeated this assertion a few times, I must ask: What
if the results are all wrong and we don't have any way of knowing
that? Would those results still be better than nothing in your
opinion?

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME user survey 2011 (v4)

[Zeeshan Ali (Khattak)]

On Fri, Aug 19, 2011 at 2:09 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
 On Fri, Aug 19, 2011 at 1:20 AM, Zeeshan Ali (Khattak)
 zeesha...@gnome.org wrote:
 On Fri, Aug 19, 2011 at 12:45 AM, Felipe Contreras
 felipe.contre...@gmail.com wrote:

 Nothing is ever perfect, but having at least some results is better
 than nothing.

  Since you have repeated this assertion a few times, I must ask: What
 if the results are all wrong and we don't have any way of knowing
 that? Would those results still be better than nothing in your
 opinion?

 What do you mean by all wrong? Let's assume that the results show that
 1000 people are not happy with GNOME. How can that be wrong?

  Maybe they all lied? Maybe people who are satisfied do not want to
or have time to take part in surveys and you only get people who are
not happy into the survey? In which case, the results may show results
that are not correct. i-e a significantly large number of participant
say that they are very unhappy with GNOME but what if that number is
nothing compared to the number of people who are very much satisfied
with GNOME?

  I didn't say this so far because it might sound like I am trying to
make a joke but since you still insist on your assertions about the
survey, I feel I must say this: How do you know people in general like
to participate in surveys? It is my observation that most people do
not like to do that, unless they have something to complain about. Now
this observation of mine could very well be wrong but how do we know
that? Do we do a survey to find out if people like to participate in
surveys?

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME user survey 2011 (v4)

[Zeeshan Ali (Khattak)]

On Wed, Aug 17, 2011 at 5:23 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
 Hi,

 Here's the fourth version of the survey, only tiny minor changes, it
 seems it's stabilized as there isn't many more comments.

 Shall we start planning the deployment? Who can get it into the site?
 Can I have access?

 How about an application that pops notifications similar to this one?
 Would such a thing be accepted?

 Cheers.

 === 01. Which of the following images best resemble your desktop? ===
 (image selection)

  - GNOME 2
  - GNOME 3
  - Unity
  - KDE

 === 02. Overall, how happy are you with GNOME? ===
 (single choice)

  As Bastien pointed out already, in question#1 you are reaching out
to users who use GNOME without knowing so but in the rest of the
questions, you are not. I think this survey isn't going to be useful
to us if you don't include such users in it as GNOME 3 is very much
targeted for this type of users. Before you ask, no I don't know how
you can do that.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME user survey 2011

[Zeeshan Ali (Khattak)]

On Sun, Jul 31, 2011 at 7:11 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
 Hi,

 Last time I suggested something like this the response was not so
 great, but lately I've feeling that there's a lot of dissatisfaction
 with GNOME 3. Why not find for good what people are thinking with an
 user-survey?

  Was it really necessary to start your mail with negativity?

 It would be great if some sort of notification would popup directly on
 user's desktops, this way it can ensured that the maximum amount of
 people are notified.

  Assuming user is given the choice at first login if he/she wants to
participate, it is indeed a good idea. Would you be providing patches
for this?

 Otherwise, I think planet GNOME, reddit, twitter,
 Google+ and so on should give plenty of feedback. Maybe also contact
 Ars Technica, LWN, Phornix, and so on would help.

  Those sites will surely get us plenty of geeks but as I said to you
in person when I asked you to make this survey happen, there must be
at least 10% participation from people who can't be put in the 'geek'
category: ordinary people in non-technical professions. One way to
check that would be to ask a few simple questions like:

* How often do you use terminal/console?
* How do you rate your computer skills from 1-10.
* etc

  Also, most people are still on facebook so better advertise this on
facebook gnome3 page too.

  Other than that, the questionare you came-up looks good. :)

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME user survey 2011

[Zeeshan Ali (Khattak)]

On Sun, Jul 31, 2011 at 7:49 PM, Maciej Piechotka uzytkown...@gmail.com wrote:
 On Sun, 2011-07-31 at 19:40 +0300, Zeeshan Ali (Khattak) wrote:
 On Sun, Jul 31, 2011 at 7:11 PM, Felipe Contreras
 felipe.contre...@gmail.com wrote:
  It would be great if some sort of notification would popup directly on
  user's desktops, this way it can ensured that the maximum amount of
  people are notified.

   Assuming user is given the choice at first login if he/she wants to
 participate, it is indeed a good idea. Would you be providing patches
 for this?


 I don't think first login fits well in questions. If the questions are
 bout Gnome experience then user should have any before answering the
 questions.

  I meant the choice of whether or not he/she wants to be bugged by
pop-ups. Whether at login or not, we must not force user to take part
in any surveys or there will be no positive replies. :)

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: On the Interaction with the design team

[Zeeshan Ali (Khattak)]

Hi,
On Fri, Jun 3, 2011 at 12:55 PM, Dave Neary dne...@gnome.org wrote:
 I really don't think IRC logs are a good way of communicating anything. It's
 better than unlogged, but really only marginally.

  This discussion reminds me of the one we had about switching to DVCS
some years back. At that time, most of the core developers wanted to
use git but most of the rest were opposed to that. While I don't claim
this situation is the same, this discussion is also about which tools
to use/not use and when it comes to that, IMO the people doing the
actual world should be the ones deciding. The rest should simply
'adapt'.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GUPnP inclusion

[Zeeshan Ali (Khattak)]

On Sun, May 15, 2011 at 11:16 PM, Shaun McCance sha...@gnome.org wrote:
 Hi Zeeshan,

  Hi Shaun,

 Could you or another GUPnP developer work with me to create
 a page for it in the Platform Overview?

  I was doing that some weeks ago (actually your mail about that is in
my inbox so i don't forget) but then this move of GUPnP process
started and I decided to wait on that so I don't end-up putting links
into out website that will break soon.


-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

GUPnP inclusion

[Zeeshan Ali (Khattak)]

Hi all,
   Rygel is planned to included back into GNOME in 3.1 as part of the
'Sharing' feature[1]. GUPnP dependencies of Rygel has so far been used
as blessed external dependencies. Since GUPnP is moving [2] to GNOME
infrastructure and Rygel development is very closely tied with GUPnP,
I propose that we now treat GUPnP as part of GNOME (developer
platform). If we decide to do this, I also recommend we not only take
the components that Rygel directly depend on[3] but gupnp-tools as
well since those tools are very useful for developing, testing and
tracing UPnP issues.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124

[1] https://live.gnome.org/ThreePointOne/Features/Sharing
[2] https://bugzilla.gnome.org/show_bug.cgi?id=648704
 https://bugzilla.gnome.org/show_bug.cgi?id=625933
 https://bugzilla.gnome.org/show_bug.cgi?id=648112
[3] gssdp, gupnp, gupnp-av, gupnp-dlna and gupnp-vala
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Bump vala requirement

[Zeeshan Ali (Khattak)]

On Wed, Feb 16, 2011 at 12:23 PM, Jens Georg m...@jensge.org wrote:
 Hi,

 rygel needs valac 0.11.6 since it fixes a codegen bug which leads to a
 crash in one of our plugins.

   IIRC, micro version could be bumped without notification/request(?).

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal: Moving d-d-l to moderated until after GNOME 3 release

[Zeeshan Ali (Khattak)]

On Fri, Jan 7, 2011 at 4:17 PM, Miguel de Icaza mig...@novell.com wrote:

 I'd like to propose that we move the list to strict moderation for the
 next couple of months - anything not to do with development (code, docs,
 i18n, continuous integration) related to GNOME 3 should be filtered out.
 Priority should be given to maintainers  developers and people doing
 release management.

 Perhaps you can create a moderated list for folks that need this kind of
 focused participation, call it desktop-devel-list-core-team.   Or make
 that invite only, or something like that.
 And you keep this list open, to discuss things publicly as we have had it
 for years.

+1


-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Consolidating Core Desktop libraries

[Zeeshan Ali (Khattak)]

On Mon, Nov 22, 2010 at 11:38 PM, Ivan Frade ivan.fr...@gmail.com wrote:
 Hi

 On Sun, Nov 14, 2010 at 4:21 PM, Zeeshan Ali zee...@gmail.com wrote:

   One could also think

   about reanimating the once proposed d-bus-based thumbnailer[1] if more
   users show up.

 Rygel also needs this. Currently we just serve the thumbails if they've
 been already created by another app but its very much desired to be able to
 create them ourselves or request another entity to do that.

   [1]: http://live.gnome.org/ThumbnailerSpec
 
  That spec is over-engineered, and far too complicated for what we want
  to use it for.

 True and one reason I'm not using it already in Rygel. Another reason to
 not use this spec is that IMHO we should have one service for both thumbnail
 and albumart extraction/download with simple APIs (get the
 thumbnail/albumart for this URI/album/artist and notify me when its done).

 Maybe the spec is too verbose, but the API itself is simple for application
 developers: a Queue method to request the thumbnail,

  Just as an example there is a 'mime_types' parameter to that method
which IMO doesn't make any sense. To complicate the matters more,
there is ways to 'register' specialized thumbnailers. We need
thumbnails for pictures and videos, both of which can be handled by
gstreamer in a dynamic way by a single thumbnailer.  On top of that,
there is more parameters of this simple Queue method (flavor and
scheduler) that really doesn't need to be exposed to application
developer.

 Album art is a different issue, and you depend there on external providers.

  That does't mean we can't have the same service (application) handling both.

 Not that is not possible, but requires a second thought.

  Sure, what doesn't? :)

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Bump gupnp-av and gupnp-vala dep

[Zeeshan Ali (Khattak)]

Hi everyone,
   I hope nobody minds if I bump minimum gupnp-av and gupnp-vala dep
to 0.7.0 (for rygel)? This is an unreleased version but I'll not
commit the sin of depending on unreleased external library so don't
worry about that. :)

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Bump min vala version to 0.11.1

[Zeeshan Ali (Khattak)]

Hi everyone,
   I would like to bump minimum vala version to 0.11.1 to be able to
remove some workarounds in Rygel. Another reason is that currently
rygel doesn't build against 0.11.1 and I'm not sure if it'll build
with 0.10.x anymore after I've ported it for 0.11.1. Jürg tells me
that Tracker will soon need to require it as well.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: It's Release Notes time!

[Zeeshan Ali (Khattak)]

Hi,

On Sat, Aug 21, 2010 at 9:23 PM, Paul Cutler pcut...@gnome.org wrote:
 Can you feel it in the air?  It's that time when we start writing
 release notes to tell our users and developers what's coming in the next
 GNOME release!

 Thank you to the Anjuta team for adding some bullet points about what's
 coming in GNOME 2.32.

 Now I need YOUR help!

  I tried my best to help you out in this regard while fixing all the
critical issues in rygel and the deps in time for GNOME 2.32. What do
I get in return? You completely ignored my project in the release
notes rather than helping me out by putting the features I put-up on
the wiki that rygel adds to GNOME, in nice words for users.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: It's Release Notes time!

[Zeeshan Ali (Khattak)]

On Thu, Sep 30, 2010 at 3:19 PM, Bastien Nocera had...@hadess.net wrote:
 On Thu, 2010-09-30 at 15:00 +0300, Zeeshan Ali (Khattak) wrote:
 Hi,

 On Sat, Aug 21, 2010 at 9:23 PM, Paul Cutler pcut...@gnome.org wrote:
  Can you feel it in the air?  It's that time when we start writing
  release notes to tell our users and developers what's coming in the next
  GNOME release!
 
  Thank you to the Anjuta team for adding some bullet points about what's
  coming in GNOME 2.32.
 
  Now I need YOUR help!

   I tried my best to help you out in this regard while fixing all the
 critical issues in rygel and the deps in time for GNOME 2.32. What do
 I get in return? You completely ignored my project in the release
 notes rather than helping me out by putting the features I put-up on
 the wiki that rygel adds to GNOME, in nice words for users.

 To be honest, Rygel in 2.32 isn't the experience we want to offer to
 users. We still have separate capplets for Rygel, gnome-user-share, and
 vino, and we'd want to merge all that under one panel for 3.0.

 Given the user experience, I don't feel so bad that it was ignored from
 the release notes this time, and we can offer a much better user
 experience when we get to 3.0, and publicise it.

  /me nods. Hopefully we managed to do all those things in time for GNOME 3.0.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: It's Release Notes time!

[Zeeshan Ali (Khattak)]

On Thu, Sep 30, 2010 at 3:08 PM, Andre Klapper ak...@gmx.net wrote:
 Am Donnerstag, den 30.09.2010, 15:00 +0300 schrieb Zeeshan Ali
 (Khattak):
   I tried my best to help you out in this regard while fixing all the
 critical issues in rygel and the deps in time for GNOME 2.32. What do
 I get in return? You completely ignored my project in the release
 notes rather than helping me out by putting the features I put-up on
 the wiki that rygel adds to GNOME, in nice words for users.

 Can you please change your tone?
 I'm a bit tired of hurt egos.

  I already apologized Paul for being rude on IRC and here is another
apology. For the record, This was all a misunderstanding between me
and Paul and that he had very little time to write the release notes.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: It's Release Notes time!

[Zeeshan Ali (Khattak)]

Hi Paul,

On Thu, Aug 26, 2010 at 5:51 AM, Paul Cutler pcut...@gnome.org wrote:
 Hi,

 We're still pretty light on content for the upcoming 2.32 release.

   I just added some bullets off the top of my head about basic
features Rygel's inclusion will add to GNOME. I'm not very good at
this so please feel free to edit my text so to tailor it more for
end-users.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Bumping gupnp-dlna requirement

[Zeeshan Ali (Khattak)]

Hi everyone,
   To whom it may concern (anyone? :)), next release of rygel will
require the upcoming release of gupnp-dlna (due for release tomorrow)
. We're trying to put all API/ABI changes in already so after this
we'll only need to change the recommended version, though we can't
guarantee that. That said, API/ABI of gupnp* (including gupnp-dlna) is
guaranteed to be frozen in 2 weeks.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Bump min vala version to 0.9.3

[Zeeshan Ali (Khattak)]

Hi,
   I realized later that this is a micro version bump and I can change
it myself so went and did that (jhbuild and wiki).

On Thu, Jul 15, 2010 at 3:30 PM, Maciej Piechotka uzytkown...@gmail.com wrote:
 On 15/07/10 01:18, Zeeshan Ali (Khattak) wrote:
 Hi,
    The new vala release contains some improvements to glib API that
 breaks rygel's build so I would like to use vala 0.9.3 in the next
 release.


 libgee 0.5.2 will and current master do require that version.

   Yes but the minimum version of libgee is at 0.5.0 and recommended
at 0.5.1. Feel free to change that. :)

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

New external dependencies for Rygel: GUPnP DLNA

[Zeeshan Ali (Khattak)]

Hi everyone,
   I would like to start using (and therefore depending on) a new
library called GUPnP DLNA[1].  GUPnP DLNA is a small utility library
that aims to ease the DLNA-related tasks such as media profile
guessing, transcoding to a given profile, etc. This library was
originally aimed to be part of gupnp-av but a hard dependency on
gstreamer was not acceptable for all existing gupnp-av users and hence
it was put in a separate package/library.

   For more information, please read the relevant thread (especially
the first email) on gupnp mailing-list and first release announcement:

http://lists.o-hand.com/gupnp/0915.html
http://lists.o-hand.com/gupnp/0975.html

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124

[1] http://gupnp.org/sources/gupnp-dlna/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Bump min vala version to 0.9.3

[Zeeshan Ali (Khattak)]

Hi,
   The new vala release contains some improvements to glib API that
breaks rygel's build so I would like to use vala 0.9.3 in the next
release.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: New external dependencies for Rygel: GUPnP Libgee

[Zeeshan Ali (Khattak)]

Hi,

On Fri, Jun 18, 2010 at 10:40 AM, Frederic Peters fpet...@gnome.org wrote:
 Zeeshan Ali (Khattak) wrote:

   When I said that, I thought it takes a few days but seems that is
 not the case. Its been like 10 days that I made this proposal, nobody
 objected on the deps but nobody seems to update the external deps
 wikipage even though I sent a mail to release-team this morning so I'm
 not sure about the status of the proposal.

 Well, rygel and the external deps were shipped in 2.31.3, look at:
 http://ftp.gnome.org/pub/GNOME/teams/releng/2.31.3/gnome-suites-2.31.3.modules

  Thats very interesting cause rygel wasn't mentioned in the release
announcement: http://ftp.gnome.org/pub/GNOME/desktop/2.31/2.31.3/NEWS
. Moreover, I asked Lucas about it and he told me that the reason
rygel didn't make it there was that it didn't get into the jhbuild
moduleset before he rolled out the release.

  Anyway, good to know that it did make it there. :)

                                             Same goes for the Vala bump
 proposal I made separately.

 I thought I answered you on IRC, that it was okay. So here goes it:
 it's ok.

   I was under the false impression that final decisions are
communicated through update of relevant wikipage by release team.
Thanks Claudio for clearing that up.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: New external dependencies for Rygel: GUPnP Libgee

[Zeeshan Ali (Khattak)]

Hi,

   If you want to add a new dependency or want one of the minimum
   versions updated, make a good case for it on desktop-devel-list (this
   may only require a few sentences). In particular, provide reasons why
   it is important to bump the version number, explain any impact
   (compile and run time) on other modules, and list any additional
   external dependencies it would pull in as well as any requirements on
   newer versions of existing external dependencies. Be prepared for
   others to take a few days to test it (in particular, to ensure it
   builds) before giving a thumbs up or down.
 
  Are you ok with it?

    If you mean this decision taking some time, sure but rygel depended
 on these libs when it was proposed for inclusion so I was hoping that
 people have already tested it along with its dependencies.

 Nope, the important part is that *every time* you will want to bump
 the version number you will have to ask and wait.

  Understood.

  When I said that, I thought it takes a few days but seems that is
not the case. Its been like 10 days that I made this proposal, nobody
objected on the deps but nobody seems to update the external deps
wikipage even though I sent a mail to release-team this morning so I'm
not sure about the status of the proposal. Same goes for the Vala bump
proposal I made separately.

   If these things usually take such a long time, I don't think I'll
have any choice but to start doing most of the development on
gitorious clone and only sync to gnome git master twice a month. :( I
hope thats OK with everyone?

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Vala version bump?

[Zeeshan Ali (Khattak)]

Hi,

On Wed, Jun 9, 2010 at 6:24 PM, Zeeshan Ali (Khattak) zee...@gmail.com wrote:
 Hi everyone,
  While Rygel currently depends on (and is tested with) Vala 0.8.0,
 the minimum version of Vala on external deps wikipage[1] is 0.7.8 and
 recommended is 0.8.1. Moreover, Jürg tells me that its the 0.9.x
 branch that is intended for GNOME 3.0. I was wondering maybe we should
 just bump the minimum version to 0.9.0 and recommended version to
 0.9.1?

   The latest email from Andre about use of gtk+-3.0 changes this plan
a bit. Jürg just added the gtk+-3.0 vapi to vala git master and it'll
only be available in the next release (= 0.9.2). So I'll request both
minimum and recommended versions to be 0.9.2.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Vala version bump?

[Zeeshan Ali (Khattak)]

Hi everyone,
  While Rygel currently depends on (and is tested with) Vala 0.8.0,
the minimum version of Vala on external deps wikipage[1] is 0.7.8 and
recommended is 0.8.1. Moreover, Jürg tells me that its the 0.9.x
branch that is intended for GNOME 3.0. I was wondering maybe we should
just bump the minimum version to 0.9.0 and recommended version to
0.9.1?

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124

[1] http://live.gnome.org/TwoPointThirtyone/ExternalDependencies
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: New external dependencies for Rygel: GUPnP Libgee

[Zeeshan Ali (Khattak)]

Hi,

On Tue, Jun 8, 2010 at 2:00 PM, Frederic Peters fpet...@gnome.org wrote:
 Zeeshan Ali (Khattak) wrote:

  Did you read http://live.gnome.org/TwoPointThirtyone/ExternalDependencies?

   I did but then again I've been reading a lot lately so things have
 been slipping of my mind.

  Especially this part:
 
   If you want to add a new dependency or want one of the minimum
   versions updated, make a good case for it on desktop-devel-list (this
   may only require a few sentences). In particular, provide reasons why
   it is important to bump the version number, explain any impact
   (compile and run time) on other modules, and list any additional
   external dependencies it would pull in as well as any requirements on
   newer versions of existing external dependencies. Be prepared for
   others to take a few days to test it (in particular, to ensure it
   builds) before giving a thumbs up or down.
 
  Are you ok with it?

    If you mean this decision taking some time, sure but rygel depended
 on these libs when it was proposed for inclusion so I was hoping that
 people have already tested it along with its dependencies.

 Nope, the important part is that *every time* you will want to bump
 the version number you will have to ask and wait.

  Understood. One question: Next time I do this, should I do it before
committing the changes to master or before a release?

 Honestly I have no hardware talking UPnP so I didn't get much of a
 look, and discovering it comes with the addition of five new modules
 to our stack was not the pleasant welcome I expected when I got home
 yesterday :)

  Building rygel and testing it doesn't require any hardware. :)

 Anyway, could you file a patch against jhbuild to switch all those
 modules to tarballs?

  Sure, I'll try to do that today.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

New external dependencies for Rygel: GUPnP Libgee

[Zeeshan Ali (Khattak)]

Hi,
   I would like to propose the following as blessed dependencies for Rygel:

* gupnp = 0.13.3
* gupnp-av = 0.5.5
* gupnp-vala = 0.6.5
* libgee = 0.5.0

  The first three are part of GUPnP project and the last one is a
collection library providing GObject-based interfaces and classes for
commonly used data structures. Please visit the projects' home
pages[1][2] for more information on them.

  Yes, I should have done it at the same time I proposed Rygel but hey
this is my first module in GNOME so please go easy on me. :) On the
bright side some gnome modules already depend on the first two of the
libraries above indirectly (empathy) or optionally (gnome-user-share).

--
Regards,

Zeeshan Ali (Khattak)
FSF member#5124

[1] http://www.gupnp.org
[2] http://live.gnome.org/Libgee
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: New external dependencies for Rygel: GUPnP Libgee

[Zeeshan Ali (Khattak)]

Hi Frederic,
   Thanks for the very quick reply. My reply below:

On Tue, Jun 8, 2010 at 1:52 AM, Frederic Peters fpet...@gnome.org wrote:
 General questions first:

  - Are there frequent releases of those?

  The GUPnP libraries, yes! libgee used to be very frequently released
until recently when the new maintainer just disappeared after he moved
to a new house. That said,  I haven't seen any issues with Libgee
after 0.5.0 release and if I (or anyone) do, I'm sure Jürg will take
over and make the releases happen in time. Right Jürg?

  - Do you often need newer versions?

  Requirements of libgee haven't changed at all for quite some months
now. The GUPnP libraries are another story and Rygel's requirement for
them get bumped quite often.

  - What are your relations with the upstream authors? (for example, can
   you bother them with the GNOME schedule?)

  I'm one of the main authors of GUPnP libraries and (co-)maintainer.
Ross Burton is the main maintainer and he does a good job making
releases happen whenever needed.

  I'm sure Jürg can always be harassed to make the libgee release
happen in time. :)

 About gupnp, it depends on gssdp, right?

  Yes it does but gssdp is much more stable than the other GUPnP
libraries so it rarely needs changes/releases.

 About libgee, shouldn't this be in glib, or in the language itself,
 instead of an extra library?

  Don't know. I guess that would be a question for Jürg.

 Did you read http://live.gnome.org/TwoPointThirtyone/ExternalDependencies?

  I did but then again I've been reading a lot lately so things have
been slipping of my mind.

 Especially this part:

  If you want to add a new dependency or want one of the minimum
  versions updated, make a good case for it on desktop-devel-list (this
  may only require a few sentences). In particular, provide reasons why
  it is important to bump the version number, explain any impact
  (compile and run time) on other modules, and list any additional
  external dependencies it would pull in as well as any requirements on
  newer versions of existing external dependencies. Be prepared for
  others to take a few days to test it (in particular, to ensure it
  builds) before giving a thumbs up or down.

 Are you ok with it?

   If you mean this decision taking some time, sure but rygel depended
on these libs when it was proposed for inclusion so I was hoping that
people have already tested it along with its dependencies.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Documentation for Proposed Modules

[Zeeshan Ali (Khattak)]

Hi,

On Thu, May 6, 2010 at 5:02 PM, Shaun McCance sha...@gnome.org wrote:
 These I'm not entirely clear on what they'll affect:

  * rygel

  Me neiher. :) If I understood correctly, you are talking about the
docs user sees when she hits the 'Help' button. Since Rygel is
supposed to be mostly invisible to an end-user, I doubt rygel needs
any such docs. Please feel free to contradict me. :)

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Documentation for Proposed Modules

[Zeeshan Ali (Khattak)]

On Thu, May 6, 2010 at 5:32 PM, Shaun McCance sha...@gnome.org wrote:

 Right, but if it allows users to do cool things, we'd like to
 talk about those in the Desktop Help or elsewhere.

  As soon as I proposed Rygel, someone pointed out that he doesn't
know what Rygel is so I added a user-story at the top of the homepage:
http://live.gnome.org/Rygel. Hope thats good enough if we advertise
this link everywhere. If you think its important to have this into
gnome help as well, do let me know.

 With Avahi,
 as an example, there's no application to write help for, but
 it lets me see the computers on my network. That's something
 we can write about. I think we need to see first-hand what we
 can do with a system with Rygel.

 Avahi is more comparable to (lowest-level stack) of UPnP, Rygel is
more like a service that you'll typically use from another machine
(PS3, Xbox, DLNA TV etc).

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Documentation for Proposed Modules

[Zeeshan Ali (Khattak)]

On Thu, May 6, 2010 at 5:50 PM, Bastien Nocera had...@hadess.net wrote:
 I'm afraid I still haven't worked on the integration of Rygel into
 gnome-user-share because I still don't know how we want to handle
 libraries of videos in the GNOME desktop itself (and I don't mean in a
 technical sense, but in a UI sense).

  Glad to know that I am not the only one finding it hard to figure
out UIs. :) This is a mystery for me as well as we have two backends
to satisfy (standalone media db/extractor and Tracker) and its hard to
come-up with a simple and intuitive UI without having to expose the
existence of these plugins to user. Unless Tracker guys (promise to)
provide DLNA related options in their preferences UI?

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: new module proposal: gobject-introspection

[Zeeshan Ali (Khattak)]

On Sat, Apr 24, 2010 at 4:13 PM, Colin Walters walt...@verbum.org wrote:
 On Fri, Apr 23, 2010 at 7:22 PM, Zeeshan Ali (Khattak) zee...@gmail.com 
 wrote:
  Talking of namespaces, is it correct that gir does not allow
 multiple libs to share a namespace? If so, that could be bigger issue
 than not supporting nested namespaces AFAICT.

 You want two shared objects which just get blended into the same GI namespace?

  Namespace, yes; gi/typelib file, preferably not. I was pointing-out
the one-to-one mapping of namespace to gi/typelibe files which could
be a problem in certain cases (see below).

 That's actually trivial, the shared-library attribute takes a comma separated
 list.

 We were actually using this for a while to implement C overrides,
 where importing Gtk would pull in libgtk-x11-2.0.so and libgtk-addons.so.
 We've long since moved to just using gtk directly however now that C
 accessors exist for all of the widget flags, etc.

 But nothing stops one from using this facility now if you want it.  Just
 pass --library multiple times to the scanner.

   If I understood you correctly, that would work if the libraries are
in the same (source) package? Is there a way to accomplish the same
for libraries in separate packages?

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: new module proposal: gobject-introspection

[Zeeshan Ali (Khattak)]

Hi,

On Sat, Apr 24, 2010 at 12:05 AM, Colin Walters walt...@verbum.org wrote:
 We've made a good
 amount of progress in allowing Vala to be rebased on introspection as
 well (though there is one major blocker still left for that).

   The nested namespace issue you mentioned below?

 1) gir-repository should be dead - people please stop depending on it.
 It's pretty high priority for me to get gnome-shell switched over to
 the GTK+ introspection built stack.

  Isn't death of gir-repository awaiting for moving all gir/typelib to
respective libraries rather than for applications to stop depending on
gir-repository?

 2) API/ABI stability.  I'm going to try really hard on this.  If we end
 up doing nested namespaces for Vala some things will get harder,
 but we'll see.

  Talking of namespaces, is it correct that gir does not allow
multiple libs to share a namespace? If so, that could be bigger issue
than not supporting nested namespaces AFAICT.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Module Proposal: Rygel

[Zeeshan Ali (Khattak)]

Hi,

On Fri, Mar 19, 2010 at 5:53 PM, Vincent Untz vu...@gnome.org wrote:
 Le vendredi 19 mars 2010, à 16:39 +0200, Zeeshan Ali (Khattak) a écrit :
    I didn't miss that. :) If you read carefully he said just to be
 safe and hence it's not so important. Still, I tried to setup the

 I said on the safe side because I've no good example of when those
 strings would appear. But I would expect them to be translatable :-)

 translation framework, got into some weird autofoo issues, asked some
 gnome developers (including you) to help me out on IRC and when nobody
 replied, I gave-up and started working on something more useful: unit
 tests.

 Do you have a bug report somewhere with the issues that you had? I
 didn't see your request for help on irc, and I'm sure many people
 didn't.

  Just to inform the interested people that Rygel in git master now
has the translation framework fixed and I've marked all strings (that
could ever be seen by user) for translation. Thanks to Andre Klapper
and Pierre-Luc for helping out on this.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Finding and Reminding, tech issues, 3.0 and beyond

[Zeeshan Ali (Khattak)]

Hi,

On Sun, Apr 11, 2010 at 12:10 AM, Owen Taylor otay...@redhat.com wrote:

 Well, certainly tracking and indexing file metadata doesn't *require*
 anything as complex, or general purpose as RDF. I have some concerns
 about the complexity, but as long as we don't get to the point where
 understanding RDF and ontologies is a prerequisite for developing a
 GNOME app, we're probably fine.

  In order to achieve this goal, Tracker will have to provide APIs
specifcally tailored for specific purposes. The only hurdle there is
that Tracker developers seem to be very insistent on Sparql to be
*the* API every application should be using to communicate with
Tracker. I would really love to be wrong about that but thats the
impression I got when trying to convince Tracker guys to implement the
MediaServer[1] API.

 But if we go beyond that and start encouraging people to start putting
 all sorts of application data into Tracker and relying on Tracker to do
 efficient queries on it, then it definitely is a concern. Based on how
 Tracker is mapping RDF into SQL tables, some SPARQL queries are going to
 be fast, some are going to be dead slow and people need to be able to
 come to an understanding of which are which.

  I think the 'custom APIs for specific purposes' approach will
minimize such performance issues since in that case both
application(s) and Tracker will know exactly what is expected from the
very start. For example, I am using optionals in my queries in Rygel
and I observed that they make the queries very slow. I was told (by
Tracker developers) that the solution is to use property functions
instead. I haven't gotten around to change this but I am affraid it'll
require not only miner changes but some redesign of the code.

  Now if Tracker implemented the MediaServer spec I mentioned, I would
have just informed Tracker guys which API is slow and it would have
been upto them to optimize it. i-e I wouldn't have needed to even know
about optionals and property functions, let alone to change/redesign
my code to make the queries faster.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124

[1] http://live.gnome.org/Rygel/MediaServer2Spec
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GSoC Proposal: Scripting Framework for Applications

[Zeeshan Ali (Khattak)]

On Thu, Apr 8, 2010 at 10:06 PM, Colin Walters walt...@verbum.org wrote:
 On Thu, Apr 8, 2010 at 2:56 PM, Shaneeb Kamran shaneebs...@gmail.com wrote:
 My take is that GNOME apps should pick C + one of JS,Python and move
 on with actually writing your app and fixing bugs, making it
 compelling, etc.

   That would be my plan for world domination as well except that I
think its time all gnome developers stop wasting their time writing
code in C while they can achieve the exact same results using Vala in
far less time and efforts without introducing performance overhead or
dependencies. Moreover, we'll get gobejct-introspection support for
free.

--
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Module Proposal: Rygel

[Zeeshan Ali (Khattak)]

Hi,

On Mon, Feb 22, 2010 at 4:17 PM, Vincent Untz vu...@gnome.org wrote:
  We have pride in our incredible translation teams; it would be really
  nice if Rygel had the infrastructure in place to be translated.
 
  Is this planned?

   It most certainly is and if it starts to become very likely that my
 proposal will be approved, I'll put this in my high-priority todo
 list.

 Heh, the logic should be reversed :-) It can't be approved (or likely to
 be approved) until the app is translatable.

  Since me and Bastien (based on Lennart's arguments on this thread)
agreed to kill the preferences UI in favor of some simple options to
be added to gnome-user-share dialog, do I still need to do this for my
proposal to be considered?

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Module Proposal: Rygel

[Zeeshan Ali (Khattak)]

Hi,

On Fri, Mar 19, 2010 at 2:56 PM, Frederic Peters fpet...@gnome.org wrote:
 Zeeshan Ali (Khattak) wrote:

  Heh, the logic should be reversed :-) It can't be approved (or likely to
  be approved) until the app is translatable.

   Since me and Bastien (based on Lennart's arguments on this thread)
 agreed to kill the preferences UI in favor of some simple options to
 be added to gnome-user-share dialog, do I still need to do this for my
 proposal to be considered?

 In another branch of this thread, Vincent Untz gave you an answer:

 |     Yeah something like that. However most of the errors/warnings are
 |  sent over to the (remote) client as well and it all depends on the
 |  client whether it shows them to user or not.
 |
 | In this case, it probably makes sense to have them translated, to be
 | on the safe side.

 And that makes me think the preferences UI was not all there was to
 Rygel, other parts should be translatable as well.

   I didn't miss that. :) If you read carefully he said just to be
safe and hence it's not so important. Still, I tried to setup the
translation framework, got into some weird autofoo issues, asked some
gnome developers (including you) to help me out on IRC and when nobody
replied, I gave-up and started working on something more useful: unit
tests.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124

P.S. In case you are interested, here is my attempt:
http://gitorious.org/rygel/rygel/commits/l10n
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Module Proposal: Rygel

[Zeeshan Ali (Khattak)]

Hi Bastien,

On Fri, Mar 19, 2010 at 2:59 PM, Bastien Nocera had...@hadess.net wrote:

 2 things come to mind:
 - Tracker shouldn't need to use D-Bus to access its database read-only:
 https://bugzilla.gnome.org/show_bug.cgi?id=613255

   I couldn't agree more. So here is my plan: I will go with all
plugin[1]  external approach using the new D-Bus spec[2] . This will
mean SLOW (its already very slow with my queries that has lots of
optionals) tracker backend but I leave that for tracker guys to solve.
They can either do what you asked for above or they can implement this
D-Bus interface directly.

 - The way you currently use Tracker means that there's no way to
 differentiate between videos that I want indexed and searchable, and the
 ones that I want to export. This is a privacy problem and could be
 solved by making applications provide their catalogues instead (which
 could be powered by Tracker).

  Actually this issue is partly solved. I made sure that tracker guys
have the right ontology caugh..metadata keys for this. However,
there is  currently no UI for user to be able to mark media to be
exported.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124

[1] Except the ones that serve gstreamer source elements  hence must
be in-process but these are developer/test oriented.
[2]  http://live.gnome.org/Rygel/MediaServer2Spec
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Module Proposal: Rygel

[Zeeshan Ali (Khattak)]

On Fri, Mar 19, 2010 at 4:53 PM, Vincent Untz vu...@gnome.org wrote:
 Le vendredi 19 mars 2010, à 16:39 +0200, Zeeshan Ali (Khattak) a écrit :
    I didn't miss that. :) If you read carefully he said just to be
 safe and hence it's not so important. Still, I tried to setup the

 I said on the safe side because I've no good example of when those
 strings would appear. But I would expect them to be translatable :-)

  These are error messages mostly what gnome apps/libs spew out on
console using g_critical/warning/error functions.

 translation framework, got into some weird autofoo issues, asked some
 gnome developers (including you) to help me out on IRC and when nobody
 replied, I gave-up and started working on something more useful: unit
 tests.

 Do you have a bug report somewhere with the issues that you had?

   No but I can file a bug report and assign it to you if you like. :)
Try building that rygel branch i linked to and you'll see what the
problem is. If you feel lazy, just ping me in private on irc and I'll
provide the details of the issue.

 I didn't see your request for help on irc, and I'm sure many people
 didn't.

  Thats ok, people have better things to do. :) Just to be clear, I
didn't mean to insult anyone, was just telling my excuse. :)

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Module Proposal: Rygel

[Zeeshan Ali (Khattak)]

Hi,

On Sat, Feb 20, 2010 at 11:57 PM, Zeeshan Ali (Khattak)
zee...@gmail.com wrote:

  * Rygel is already readily available in two major distributions:
 Debian and Fedora.

   Now it's also available in Ubuntu (lucid). Its also available in an
unofficial Gentoo repo: http://gpo.zugaina.org/net-misc/rygel

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Module Proposal: Rygel

[Zeeshan Ali (Khattak)]

Hi,

On Mon, Feb 22, 2010 at 2:08 PM, Sergey Udaltsov
sergey.udalt...@gmail.com wrote:
  From reading description, it seems to me that Rygel would be better
 suited as system service. Just like for example mt-daapd (which seem
 to have the same purpose as Rygel but for DAAP). How does it fit GNOME?
 Absolutely correct point! Folks, when did you decided that GNOME is
 for PCs only (personal computers, in the worst of all possible
 interpretations - computer for one single user)? That is ok for
 tablets, smartphones etc - but not for general purpose desktop.

  We didn't make any such decision, actually it's just the other way
around. See below.

 If some computer provides media collection through UPnP/DAAP, it
 should do it as a system-level service, just like mt-daapd (even
 though it can be flexible enough to accomodate per-user dirs, just
 like apache or smb).

   Just because others do it in a particular way, doesn't make it
right. Although Rygel can be run as a system-wide service, the main
target use-case is that of providing services per-user[1] so for
example each user can choose to share his media on the network rather
than every user's media. We want *each* user to have full control of
whether she wants UPnP services to be enabled or not and then which
services exactly she wants and what exactly she wants from it using a
simple preferences UI.

   Lets assume for a second that we want rygel to run as a
system-service, how does rygel then communicate to processes running
on session-bus (e.g tracker, rhythmbox, totem)?

   Lastly, rygel can be run as both system-wide service and
per-session at the same time on the same machine.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124

[1] Currently it's actually per-session because of D-Bus limitation
but plan is to make it  per-user when it's possible.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Module Proposal: Rygel

[Zeeshan Ali (Khattak)]

Hi Frederic!

On Mon, Feb 22, 2010 at 9:59 AM, Frederic Peters fpet...@gnome.org wrote:
 Zeeshan Ali (Khattak) wrote:

 Adoption  GNOME-ness, community:

 We have pride in our incredible translation teams; it would be really
 nice if Rygel had the infrastructure in place to be translated.

 Is this planned?

  It most certainly is and if it starts to become very likely that my
proposal will be approved, I'll put this in my high-priority todo
list. The preferences UI case is easy but I was wondering what to do
about the actual rygel process. Do I need translations there? I ask
since that will be mostly invisible to a typical user.

--
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Module Proposal: Rygel

[Zeeshan Ali (Khattak)]

Hi,

On Mon, Feb 22, 2010 at 4:17 PM, Vincent Untz vu...@gnome.org wrote:

   It most certainly is and if it starts to become very likely that my
 proposal will be approved, I'll put this in my high-priority todo
 list.

 Heh, the logic should be reversed :-) It can't be approved (or likely to
 be approved) until the app is translatable.

  Gotcha! I'll see what I can do this week about it.

 The preferences UI case is easy but I was wondering what to do
 about the actual rygel process. Do I need translations there? I ask
 since that will be mostly invisible to a typical user.

 Where will the strings appear? If it's just error strings in a log file,
 then they don't have to be translated, for example.

   Yeah something like that. However most of the errors/warnings are
sent over to the (remote) client as well and it all depends on the
client whether it shows them to user or not.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Module Proposal: Rygel

[Zeeshan Ali (Khattak)]

Hi,

On Mon, Feb 22, 2010 at 4:29 PM, Sergey Udaltsov
sergey.udalt...@gmail.com wrote:
   Just because others do it in a particular way, doesn't make it
 right. Although Rygel can be run as a system-wide service, the main
 target use-case is that of providing services per-user[1] so for
 example each user can choose to share his media on the network rather
 than every user's media.
 That use case is perfectly served by samba - having ONE system-level
 daemon and multiple per-user shared directories (controlled by users)

  Not really. Can the user share his directories if the system-wide
deamon is not running? Sure, if the user has admin privileges she is
asked for the authentication and is able to start samba daemon but we
can't assume each user has the admin rights.

 We want *each* user to have full control of
 whether she wants UPnP services to be enabled or not and then which
 services exactly she wants and what exactly she wants from it using a
 simple preferences UI.
 I do not see any trouble with that. That is absolutely valid
 requirement - except I'd replace each user with each user belonging
 to some group ;)

  That is because you seem to be keen on admin intervention while I am
keen on each user to be as free (from admin) as possible. :)

   Lets assume for a second that we want rygel to run as a
 system-service, how does rygel then communicate to processes running
 on session-bus (e.g tracker, rhythmbox, totem)?
 AFAIK the typical model is working the other way around. If these
 process have anything to say to system-level daemons, they initiate
 communications. CMIIW. Why is that model bad for Rygel?

  Because it's Rygel that starts the communication being the client.
Also if we go the route you are recommending, each such application
will present user configuration in it's own UI and there will be no
centralized place for user to control his DLNA (media sharing 
playback) preferences.

   Lastly, rygel can be run as both system-wide service and
 per-session at the same time on the same machine.
 That is a very important thing to know. In that case, I still have a
 couple of questions:
 - Should gnome promote per-session usage of Rygel (in case of
 adoption), as more desktop-oriented mode of operation - or should
 gnome be neutral in that aspect?

 - What's the general approach for system-wide services in gnome? Does
 GNOME need that kind of policy?Some system-wide services are really
 useful for desktop, would GNOME adopt them?

  I don't think I alone can answer these questions and in this case I
shouldn't say anything being biased. :)

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Module Proposal: Rygel

[Zeeshan Ali (Khattak)]

Hi,

On Mon, Feb 22, 2010 at 6:29 PM, Lennart Poettering mzta...@0pointer.de wrote:
 On Sun, 21.02.10 14:50, Bastien Nocera (had...@hadess.net) wrote:

 - The preferences UI is pretty horrible

 Should we really keep the UI at all? The options offered therein appear
 very esoteric to me, and a trivial addition to
 gnome-file-share-properties that would just introduce one simple
 checkbox Share my Music (and Share my Videos, yadda yadda) seems a
 lot more appropriate to me.

  Hmm.. sounds right now that I looked at that UI.

 I don't see why anybody would want to disable transcoding or choose the
 interface to listen on (Rygel should listen on all of them
 anyway...).

  Agree on transcoding but not interfaces. We don't want media to be
shared on public networks. The plan is to be able to select network by
ESSID so user can decide where the media is shared (home) and where
its not (office, cafe). Unless there is a better way to achieve this?

And the plugins pane of rygel preferences is redundant
 too. Rygel should use tracker if it is installed and otherwise and
 automatically fall back to the gvfs backend. No need to configure
 anything there.

  Agreed! So I guess we both agree on getting rid of this UI mostly
and move the remaining parts to gnome-user-share UI. Now lets see if
Bastien agrees. :)

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Module Proposal: Rygel

[Zeeshan Ali (Khattak)]

Hi,

2010/2/22 Javier Jardón jjar...@gnome.org:
 2010/2/22 Lennart Poettering mzta...@0pointer.de:

 Well, we already run apache as part of the user session from
 gnome-user-share.

 GNOME is certainly focussed on the desktop, or similar user
 interfaces. As such it should provide services for building user
 interfaces, not server machines.

 A bit OT but I'd like to mention the meiga project [1] here.
 It uses libsoup instead apache to share your directories.

  While that is definitely a big + point (amongst others) in favor of
meiga, gnome-user-share is part of GNOME so I would like to depend on
that.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list