Re: Learn Gnome The Hard Way

[Sebastian Pölsterl]

Am 04.06.2012 03:05, schrieb Tiffany Antopolski:
> Hi Nick,
> 
> As Alberto mentioned, there is a current, very active effort going on at:
> http://git.gnome.org/browse/gnome-devel-docs/tree/platform-demos/C.
> 
> 
> The most active section is the creation of "Beginner Tutorials" in C,
> Vala, Python and JavaScript.  The Gnome Outreach programme has 3 interns
> plus myself  currently dedicated to the effort.
> 
> I am familiar with Foundations of Gtk+, and have also wished it be
> updated :-)
> 
> The "Beginner Tutorials" are also including GtkApplicationWindow and the
> app menu technologies.
> 
> We did the second release of this effort just this week:
> 
> Vala:
> http://developer.gnome.org/gnome-devel-demos/unstable/beginner.vala.html.en
> 
> Python:
> http://developer.gnome.org/gnome-devel-demos/unstable/beginner.py.html.en
> 
In the case of Python I created a tutorial a while back [1]. It's
focusing on GTK+, nevertheless it would be great if we could combine our
efforts into a single document.

[1]: http://readthedocs.org/docs/python-gtk-3-tutorial/en/latest/

Best regards,
Sebastian



signature.asc
Description: OpenPGP digital signature
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GObject Introspection instead of PyGTK

[Sebastian Pölsterl]

Hi Richard,

keep in mind that gnome 3 does not support applets anymore. Therefore,
you have to port to PyGI and gnome3-compatible libraries at the same time.

Regards,
Sebastian Pölsterl

Am 02.11.2011 20:55, schrieb Richard Henwood:
> hi All,
> 
> My python app [1] won't run on Ubuntu 11.10 apparently because:
> 
> 
> "python-gnomeapplet is no longer being developed as Python developers need to 
> use GObject Introspection instead of PyGTK to work with GTK3."
> 
> Please can someone point me in the direction of an example of using GObject 
> Introspection instead of PyGTK.
> 
> and advise if it will be possible for me to write an app that is both Gnome 
> 2.x and 3 compatible.
> 
> Many thanks,
> Richard
> 
> 1. http://sites.google.com/site/richardhenwood/gnome-workspacetime
> 
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
> 




signature.asc
Description: OpenPGP digital signature
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME Feature Proposal: Backup

[Sebastian Pölsterl]

Am 18.05.2011 19:21, schrieb Michael Terry:
> 
> And also, does being in git imply that the translation team would
> automatically consider the module?
> 
Not automatically, you have to be added[1] to l10n.gnome.org

[1]:
http://bugzilla.gnome.org/enter_bug.cgi?product=damned-lies&component=l10n.gnome.org

-- 
Greetings,
Sebastian Pölsterl



signature.asc
Description: OpenPGP digital signature
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME Moduleset Reorganization vs. L10N

[Sebastian Pölsterl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 16.10.2010 14:32, schrieb Gil Forcada:
> El dv 15 de 10 de 2010 a les 13:29 -0500, en/na Diego Escalante Urrelo
> va escriure:
>> El vie, 15-10-2010 a las 08:29 -0700, Sandy Armstrong escribió:
>>>
>>> I'm not a fan myself, but I can see how once a project was already
>>> hooked on a Launchpad-oriented process, it would be work to migrate to
>>> GNOME infrastructure.
>>>
>>
>> Agree, how could we shorten that difference? I think this is the real
>> issue, at least for this part of the proposal.
> 
> 
> 
> All in all we don't score that bad on features, but we are missing a big
> point not shown on the previous listings: integration and self-creation.
> 
> 
> = Integration =
> 
> All components described above are shown in a seamless integrated
> interface, so jumping from code to bugs and back and link blueprints to
> branches is easy.
> 
You are absolutely right. Most of the pieces are already available but
work as separate, independent parts where each component is not aware of
the existence of others. This makes navigating through a projects
resources difficult.

What I like about launchpad/sourceforge is that it doesn't matter which
project it is, the project's website always looks the same. Therefore,
the link to the bug tracker etc. is always at the same position. Whereas
on projects.gnome.org everything looks different. If we could unify the
websites' layout and put all relevant links like Gil mentioned on the
front page, this would be a big improvement.

In addition, as a maintainer when comes release time you have to
- - upload the tarball
- - tag release in git
- - send announcement to gnome-announce-list and project's mailing list
- - update your website and/or live.gnome.org

If one could do all these things in a single step by just uploading the
tarball (after all, everything relevant should be mentioned in NEWS)
that would be perfect.

I understand that those are difficult and time consuming tasks, but I
just wanted to mention that what I think GNOME infrastructure needs
desperately is integration.

- -- 
Greetings,
Sebastian Pölsterl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkzAWmQACgkQ1ygZeJ3lLIfq0QCfSiIsY2zRs5+SauI8rqySYiUk
aZwAoI4PU+Cb4txbDg96PYyFy31OMqPa
=Wpqw
-END PGP SIGNATURE-
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: 2.91.0 status

[Sebastian Pölsterl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 05.10.2010 19:49, schrieb Matthias Clasen:
> 
> Stuff that hasn't been ported to GTK3:
> 
> deskbar-applet
> 
> Stuff thats not updated from 2.32:
> 
> deskbar-applet:2.32.0

You can remove deskbar-applet from the GNOME 3.0 moduleset, because
gnome-shell basically makes it obsolete.

- -- 
Greetings,
Sebastian Pölsterl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyrZn8ACgkQ1ygZeJ3lLIfRDACfRVhHHnk4tdaBudsCNzl5biRg
4gIAnix3UXAqLZWS5j9poFeOmxX2QXRj
=hEvq
-END PGP SIGNATURE-
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: New module proposal: tracker

[Sebastian Pölsterl]

Martyn Russell schrieb:

On 27/10/09 14:50, Sebastian Pölsterl wrote:

Martyn Russell schrieb:

Carlos Garnacho and I did spend 2 or 3 days writing an application
similar to spotlight - although it is just a quick mock up to
demonstrate the speed and ability of Tracker and could do with some
more love. The blog/video about it is here:

http://blogs.gnome.org/mr/2009/09/30/tracker-0-7-released/


Looks very much like Deskbar-Appplet in the very early days to me. You
might just want to write a module for Deskbar.


We have code for Deskbar but it needs updating. Anyway, did I read 
something about the maintainer not sure if he is going to continue with 
the new GNOME shell project underway? Just speculation? Or random crap 
in my brain :)


Well, the applet you developed won't work under gnome-shell, too. 
Therefore, your solution isn't future-prove, either.


--
Greetings,
Sebastian Pölsterl
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: New module proposal: tracker

[Sebastian Pölsterl]

Martyn Russell schrieb:

On 27/10/09 03:34, Sriram Ramkrishna wrote:



On Mon, Oct 26, 2009 at 4:08 PM, Andre Klapper mailto:ak...@gmx.net>> wrote:

Am Dienstag, den 18.08.2009, 13:05 +0100 schrieb Martyn Russell:
 > I would like to propose Tracker as a new GNOME module.

The GNOME release-team will soon decide about module inclusions for
GNOME 2.30.

To the GNOME developers:
If you have not commented yet, if there is anything to add, if you 
have

questions to the maintainer: Please comment now.


I have one comment and I think from a marketing perspective, I would
like to see that we are on par with the other desktops. OSX has
spotlight, and I believe windows has winfs or at least it has something
built in.  We are doing ourselves no favors when we are not feature
complete against other desktops.


Carlos Garnacho and I did spend 2 or 3 days writing an application 
similar to spotlight - although it is just a quick mock up to 
demonstrate the speed and ability of Tracker and could do with some more 
love. The blog/video about it is here:


  http://blogs.gnome.org/mr/2009/09/30/tracker-0-7-released/

Looks very much like Deskbar-Appplet in the very early days to me. You 
might just want to write a module for Deskbar.


--
Greetings,
Sebastian Pölsterl
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: New module proposal: tracker

[Sebastian Pölsterl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Philip Van Hoof schrieb:
> On Tue, 2009-08-18 at 21:43 +0200, Maciej Piechotka wrote:
>> On Tue, 2009-08-18 at 15:12 -0400, Jamie McCracken wrote:
>>> On Tue, 2009-08-18 at 20:57 +0200, Lennart Poettering wrote:
>>>
>>> Epiphany does not share its metadata with anyone else nor can you cross
>>> query it
>>>
>> I believe that gnome do and/or deskbar do it quite well w/out tracker. 
> 
> Let's ask the GNOME Do and Deskbar people about this? Would a system
> like Tracker help the projects?
> 
Sure, parsing the epiphany bookmarks file over and over again is not a
good solution, but it does the job. Users usually don't care *how*
something appears on their screen as long as it actually does.

Depending on tracker only to retrieve epiphany bookmarks in a more sane
way is not going to happen.

The tracker store may be more useful to deskbar if more applications
would actually use it (e.g. evolution, f-spot, rhythmbox, banshee). But
as I see it, the ideas of tracker may be great, but far to less
applications use it so it could be worthwhile implementing tracker-store
support.

Another problem non of the desktop search engines could solve for me is,
to provide a way to find out how one result/item can be opened. For
deskbar that's a crucial point. It doesn't help at all if I can ask
tracker to search for xyz, but don't know how to handle the results. To
solve this dilemma we currently hard coded the commands to open specific
types of results in the beagle module (don't know about the tracker
module, it isn't officially part of deskbar anyway). I'd love to get rid
of such hacks.

So unless you provide patches/plugins for more applications to fill
tracker-store and even more importantly patches for applications that
consume this data, it's -1 from me.

- --
Greetings,
Sebastian Pölsterl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkqLHiwACgkQ1ygZeJ3lLId8mACfY1T1I5+CrPZGPRUlNfwB0Z61
ClgAn2kGgOFxVNYC0NgGsvYFEXcEgE9t
=Q5un
-END PGP SIGNATURE-
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

deskbar-applet branched for 2.26

[Sebastian Pölsterl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Deskbar-Applet has been branched for 2.26. The name of the branch is
gnome-2-26. Development for 2.27/28 will continue in master.

- --
Greetings,
Sebastian Pölsterl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkn7NUQACgkQ1ygZeJ3lLIfddwCeJWzJfvSuiet5e2FJ+o1pLv3/
Ca0An2sYIjnIiLWYNUJoCurMt71Q49H8
=wzZi
-END PGP SIGNATURE-
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Applets? [was Re: Planning for GNOME 3.0]

[Sebastian Pölsterl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Owen Taylor schrieb:
> [...]
> 
> The last thing I'll mention here is that I don't think we should be
> overly concerned with porting and applet parity. If there was no system
> monitor applet in GNOME 3.0, life would go on. What we should be
> concerned about is creating the ecosystem where it's easy and fun to do
> interesting things. And when we do there will inevitably be 23 competing
> system monitor applets whether we like it or not.
> 
I totally agree. As long as there's an easy way to write applets, there
will be lots of applets. Unfortunately, I currently can't see what this
ecosystem might look like.

- --
Greetings,
Sebastian Pölsterl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknsaggACgkQ1ygZeJ3lLIdHYwCeJKpIyyE1Jdx+WXAkhmtQSshA
0I4AoIDSd/3ZErkPibYO/00oC3W91d5V
=jU8B
-END PGP SIGNATURE-
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Planning for GNOME 3.0

[Sebastian Pölsterl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Matteo Settenvini schrieb:
>> Just to give some ideas
>> * do applets need to be in the panel
> 
> No, and that's why Superkaramba - KDE, Google and Microsoft have come up
> with on-screen widgets, which may be the solution ebassi is searching
> for?
> 
I agree, it doesn't matter where the applets actually sit. But there
must be an easy way to extend your desktop with applets that let you
access informations or actions quickly.

- --
Greetings,
Sebastian Pölsterl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknsaQgACgkQ1ygZeJ3lLIcv8QCfRdwpVn254cemNxQojhSV9fy3
e7kAn3O8iQnP4VmqPQUIMXgRuYoRVcnh
=LUln
-END PGP SIGNATURE-
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Planning for GNOME 3.0

[Sebastian Pölsterl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Emmanuele Bassi schrieb:
> no need to Cc me in: I'm subscribe to d-d-l.
> 
> On Sun, 2009-04-19 at 16:02 +0200, Sebastian Pölsterl wrote:
>  
>>> what do applets provide, nowadays, and are they even remotely useful?
>>> what can deskbar-applet provide that cannot be implemented with
>>> something that does not sit inside a 24x24 icon on the most valued piece
>>> of screen real estate? isn't a gnome-do approach equivalent to the
>>> deskbar-applet? why tomboy-applet is so special? it's basically a
>>> launcher with a custom context menu. also, starting up deskbar-applet
>>> *and* tomboy as applets on my panel causes my desktop more to start up
>>> on login; not great turn ons, especially when there are developers out
>>> there trying to get the boot-to-UI process down in the seconds range.
>>>
> 
>> I agree that the current applet paradigm is outdated and it doesn't do
>> well when you have a lot of applets or an applet that takes some time to
>> load. But those are the problems we want to solve, right? I'm not saying
>> that we should keep the whole applets system, but I want something
>> similar to it.
> 
> why? why should something continuously live on my panel and occupy
> space?
> 
Because you want to know which applets are currently running. In
addition, applets like system monitor need to show up somewhere,
otherwise they are useless.

>>  I don't care if it's called applet or widget or whatever,
>> if it's in the panel or somewhere else. For me the idea of applets is
>> that you can access information/functionality with minimum effort. Let's
>> say deskbar-applet would be an application started from the menu. That
>> would make deskbar-applet useless, because it should help you starting
>> applications and doing tasks with less effort. Now if I have to start
>> deskbar-applet first, I can just open the application I want to in the
>> first place.
> 
> then we don't need an icon, but we need something completely different;
> something that pops up (say) when you press F12; or something that comes
> up when I start typing on an empty workspace.
> 
> I just don't see the need to have something constantly visible on a
> panel or on my screen, when it's all about user-initiated actions. the
> tomboy-applet doesn't need to stay in my notification area (why on earth
> does it stay in my notification area is another matter entirely, but
> let's overlook that for a second) when I don't need to write a note? why
> does it have to start when my desktop starts, when it can start when I
> do need to write a note and be unloaded afterwards?
> 
Keep in mind that not all applets require user interaction, some just
show information and you don't have to interact with them at all (e.g.
system monitor or weather applet).

- --
Greetings,
Sebastian Pölsterl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknsaDwACgkQ1ygZeJ3lLIfjPwCggi01Qx1YebODH5H44/K3VlDd
wFoAoKccunKqZAcvp5Uuzkz8XUTJF0qc
=nZbr
-END PGP SIGNATURE-
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Planning for GNOME 3.0

[Sebastian Pölsterl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jamie McCracken schrieb:
> If a new infrastructure is needed then it would be best to merge it with
> notification icons and make it xdg compliant and not gnome specific
> 
I would love to see desktop a independent applet/widget/whatever spec.
I'm just not very confident that we can come up with a spec that
everybody is happy about. This would cause to delay things further.
Feel free to prove me wrong.

- --
Greetings,
Sebastian Pölsterl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknrSDgACgkQ1ygZeJ3lLIfqDgCeJDRhkiE73tzwIx/YiBHiZoxF
E/sAnjA5SxwZjWP+gjk+rWSJTHV9U8/D
=jJWz
-END PGP SIGNATURE-
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Planning for GNOME 3.0

[Sebastian Pölsterl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Emmanuele Bassi schrieb:
> On Sun, 2009-04-19 at 14:34 +0200, Sebastian Pölsterl wrote:
> 
>> I think it would be a big mistake to omit applets in the new gnome desktop
>> evolution.
> 
> why?
> 
> we've been changing the platform gradually over the years, mostly by
> deprecating stuff and including new functionality. nevertheless, I
> haven't heard a single justification for the continued existence of
> "applets".
> 
> what do applets provide, nowadays, and are they even remotely useful?
> what can deskbar-applet provide that cannot be implemented with
> something that does not sit inside a 24x24 icon on the most valued piece
> of screen real estate? isn't a gnome-do approach equivalent to the
> deskbar-applet? why tomboy-applet is so special? it's basically a
> launcher with a custom context menu. also, starting up deskbar-applet
> *and* tomboy as applets on my panel causes my desktop more to start up
> on login; not great turn ons, especially when there are developers out
> there trying to get the boot-to-UI process down in the seconds range.
> 
I agree that the current applet paradigm is outdated and it doesn't do
well when you have a lot of applets or an applet that takes some time to
load. But those are the problems we want to solve, right? I'm not saying
that we should keep the whole applets system, but I want something
similar to it. I don't care if it's called applet or widget or whatever,
if it's in the panel or somewhere else. For me the idea of applets is
that you can access information/functionality with minimum effort. Let's
say deskbar-applet would be an application started from the menu. That
would make deskbar-applet useless, because it should help you starting
applications and doing tasks with less effort. Now if I have to start
deskbar-applet first, I can just open the application I want to in the
first place.

> [...]
> 
> yes, it was all good with GNOME 1.x, but even for 2.x the amount of
> applets has been steadily decreasing - also because writing an applet is
> not trivial (as it involves dealing with some of the most obscure and
> less documented parts of our development platform). people have been
> abusing the system notification area with all sorts of crap (beagle,
> tomboy, etc.) because writing an applet is *boring* (server files
> anyone?) and *hard* (weird build changes, hard to debug uses, completely
> different APIs for handling the menus), and it really doesn't provide
> you with much functionality (wow, an icon and a context menu!).
> 
> so, please: saying "it would be a mistake" without providing reasons why
> it would be good to have applets support in the first place it's not
> going to convince me that we should keep them.
> 
You're right that writing an applet with the current framework is
extremely painful and difficult to understand, but again that's what we
want to change, right? If we can make creating an applet easier maybe
people decide to write applets again.

If one can easily write an applet one can easily adjust his desktop
without being an expert in programming. Because applets tend to be those
little programs that make your live a little bit easier they *do* make a
difference.

- --
Greetings,
Sebastian Pölsterl




-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknrLwoACgkQ1ygZeJ3lLIehbgCeMuEFUi9CllbTWtBZdT4iz1Km
StsAnjOS1WVgpAXX7oj2cAgr+fvMl0HE
=QaMC
-END PGP SIGNATURE-
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Planning for GNOME 3.0

[Sebastian Pölsterl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Colin Walters schrieb:
> On Mon, Apr 13, 2009 at 11:53 AM, Sandy Armstrong
>>  * What is the applet story for gnome-shell?  As the maintainer of a GNOME
>> applet (Tomboy), I accept that there may be significant work to port our
>> applet to a new infrastructure, but now I'm concerned that I will also need
>> to *create* that infrastructure (because gnome-shell is basically being
>> imposed upon us, and not going through the regular process, I can only
>> assume that if there's no applet infrastructure, it's my fault for not
>> caring enough to contribute one).
> 
> No, not at all.  I think it should be gnome-shell's responsibility
> mostly.  This is a complex discussion though.  I think we ultimately
> will end up with a multifaceted approach.  The "core desktop" applets
> like clock, user switcher etc. are being ported directly.  We should
> add the Tomboy applet that list.

What exactly do you mean by "ported directly"?

As the deskbar-applet maintainer I'm very concerned that are no clear
plans for an applet/desktop widget framework, yet. I guess porting an
applet to the new yet-to-be-invented framework would take considerable
time. Because there's currently no plan for a new framework it will take
some time until there is a time and the framework is actually usable.
Hopefully it's not already too late to start porting applets then. I
think it would be a big mistake to omit applets in the new gnome desktop
evolution.

- --
Greetings,
Sebastian Pölsterl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknrGmcACgkQ1ygZeJ3lLIdYBgCfWOhWa1uaFOa2EyhgeOUSVvjy
rxgAn3lOeZH1/po22MXK7Oo3baiZIK/G
=bPGV
-END PGP SIGNATURE-
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME DVCS Survey Results

[Sebastian Pölsterl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Matthias Clasen schrieb:
> On Sun, Jan 4, 2009 at 3:59 PM, David Zeuthen  wrote:
>> On Sun, 2009-01-04 at 17:48 +, John Carr wrote:
>>> As bkor has stated, there are lots of Git users so any implementation
>>> will support you, and support you well. That is a requirement. So any
>>> talk of my idea is not Git vs Bazaar, its talk of one way we can move
>>> forward. So i dont consider it to be derailing. When mentioning my
>>> idea, lets stick to technical problems with it rather than trying to
>>> undermine anyone who has looked at it and thinks it is sound and
>>> doable.
>> Can you explain what would happen in the event that a future version of
>> git switches to an repository format that isn't compatible with how you
>> want to store data?
> 
> It seems pretty clear to me that any 'homegrown' system like this is
> not suitable as a longterm, stable solution for a project the size of
> gnome.

I totally agree. Sooner or later it will become a nightmare to maintain.

- --
Greetings,
Sebastian Pölsterl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAklhNewACgkQ1ygZeJ3lLIeGIACglzAktDqy1eQ6VBsOsak41zSk
d6cAnAh9IK1acbtnyufeezRL+TQ9Dgvp
=N+VG
-END PGP SIGNATURE-
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Update Python version to >= 2.5

[Sebastian Pölsterl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Luca Ferretti schrieb:>
> I think this is the right time to update from 2.4 to 2.5 (or 2.6
> directly), or at least do it in `jhbuild bootstrap`.
> 
> 
> [1] http://live.gnome.org/TwoPointTwentyfive/ExternalDependencies
> 
I just wanted to mention that this was last discussed in July[1].

I'm all for it. Let's set the minimum version to 2.5.

[1]:
http://mail.gnome.org/archives/desktop-devel-list/2008-July/msg00103.html

- --
Greetings,
Sebastian Pölsterl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkUVgwACgkQ1ygZeJ3lLIdWCQCfTBsSUFUzExeeuXjynumy/0MK
l8IAnjuX3IJ2aCYT9ovLGnMCRTZOPhJO
=PXqJ
-END PGP SIGNATURE-
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Cleanup tasks

[Sebastian Pölsterl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Matthias Clasen schrieb:
> 2008/11/4 Joe Smith <[EMAIL PROTECTED]>:
>> So I'm doing pretty good with updating gedit, but I've noticed that there
>> are some header files not included in the main ones (, ,
>>  and ). For instance, how should we
>> include glib/gi18n.h when it isn't specifically included in glib.h? Will
>> this require adding it as an include in glib.h?
>>
> 
> No, gi18n.h is a header that has to be included separately. That is
> because you need to either include gi18n.h or gi18n-lib.h depending on
> wether you are an app or a lib. There
> is a few more of those, e.g. gstdio.h.

Same for gdkkeysyms.h

- --
Greetings,
Sebastian Pölsterl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkRtgEACgkQ1ygZeJ3lLIdR/ACcCbGC46avNqC6qqbxkCF5TQZZ
EokAn0tOM5vV3l0CPNPPJak6Y3pjAI1h
=y1u1
-END PGP SIGNATURE-
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Teaching GNOME to students...

[Sebastian Pölsterl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Emmanuel Fleury schrieb:
> Sebastian Pölsterl wrote:
>> What I don't understand is why you differentiate between bugs and
>> feature requests. From my point of view there's no big difference,
>> especially for a programmer. In both cases you get to familiar with the
>> code and write a patch.
> 
> In a matter of fact, the approach is quite different (in my humble opinion).
> 
> In the case of a bug, you are (most of the time) provided with a
> _proper_ behavior of the software and you should twist the code until
> you match it.
> 
> In the case of the feature-request, you are actually requested to
> provide by your own what the proper behavior should be... and this small
> difference might be quite thin to skilled developer but it makes it a
> lot harder to students.
> 
Well, a feature request usually comes with a guide how it should work or
look like, too. Of course, often there are multiple ways to implement
that feature, whereas for a bug the most difficult part is to find the
cause of it. I guess it depends which one is more difficult.

- --
Greetings,
Sebastian Pölsterl

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkN/bkACgkQ1ygZeJ3lLIf1qwCfS6ZCPolc7TnngnJe4WxND1Q8
vZYAn3p42ADs1N/3H4pfFmCnwMHDUzmc
=TG4X
-END PGP SIGNATURE-
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Teaching GNOME to students...

[Sebastian Pölsterl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Emmanuel Fleury schrieb:
> Hi again,
> 
> Sorry, I should have say that:
> 
> - The code language must be C.
> 
> - To submit a bug, just send me an e-mail at [EMAIL PROTECTED]
> 
> Regards
Ah, that rules out Deskbar-Applet :(

- --
Greetings,
Sebastian Pölsterl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEUEARECAAYFAkkN5ccACgkQ1ygZeJ3lLIdHjgCcCAn8Z/MVv72Cvx4rXHeLvG3g
fKcAmKBqmjR/HjT9sEBM40hNuOWt5jE=
=6a30
-END PGP SIGNATURE-
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Teaching GNOME to students...

[Sebastian Pölsterl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Emmanuel Fleury schrieb:
> Hi all,
> 
> I'm associate professor at Bordeaux University and since few years I'm
> running a course with few other teachers about 'reading, understanding
> and managing _real_ code'. Since 2007, we chose to focus on the GNOME
> project because it matches everything we ever wanted to have for such a
> course:
> 
> - A large amount of code,
> - Enough complexity to get the students over-helmed with it,
> - Highly documented,
> - A skilled and reactive community,
> - A bug and feature-request database (see later on),
> 
That's a wonderful idea. I always hated the programming stuff in
university were you program something that's already available and once
your done just through it away, because the same thing but much better
already exists. I could imagine that it makes more fun when you see that
a part of your code is actually included in a piece of software that is
used by many people.

> Our course is composed of a few theoretical courses and (mainly) three
> small projects:
> 
> 1- Dig a part of GNOME and extract some technical understanding of it.
> Make some slides out of it and present it in front of all other students.
> 
> 2- Take a bug from the issue list and dig it (bug resolution is not
> mandatory but at least have a deep explanation of the bug).
> 
> 3- Take a feature-request from the issue list and implement it.
> 
> Last year we chose the bugs almost on our own (thank a  lot Vincent Untz
> who did provide his precious help to us when we had to sort a bit the
> bugs and the feature-requests). Here is the result (in French, I'm
> afraid): http://www.labri.fr/perso/fleury/courses/EMC07/projects.html
> 
> For this year course it is now time for us to select bugs (not yet
> feature-request) and we would like to strengthen our link with the GNOME
> community by letting GNOME's developers suggest some bugs for our list.
> 
> Benefit will be for all of us (you, students and my teachers team).
> 
> First, it will let you choose bugs that you are interested to get solved
> (or a least... explored). Second, we noticed that our way of choosing
> last year made a lot of students very disappointed because nobody did
> get immediate interest in looking at the solution they proposed on the
> bugzilla (not all of them did post a patch but at least a few did).
> 
I can understand that it's frustrating if it appears that nobody is
interested in your patch. I think it's the right choice to ask for bugs
developers are interested in first.

> Having somebody interested in the resolution of the bug means that this
> shouldn't happen again. Third, browsing all these bugs, trying to
> evaluate their complexity, if they might be just too stupid or too
> difficult cost us a lot of time... where GNOME's developers could
> already have this knowledge.
> 
> Now, let me describe the kind of bug we are looking at:
> 
> - It MUST involve programming skills (fixing the spelling of a
> documentation is not our focus).
> 
> - It MUST be confirmed, 100% reproducible and architecture independent.
> 
> - It SHOULD have a medium complexity (meaning that it requires at least
> to browse and understand at least several hundred lines of code in the
> application to get a deep understanding of it... remember that our
> course is about reading and understanding a code which is not theirs. On
> the other hand, don't expect the student to be good at it, so if the
> difficulty is too high this might be risky).
> 
> - It SHOULD not be in a high priority to fix it (if so, the students
> would be in concurrence with others and won't learn anything).
> 
> 
In general I think looking at gnome-love bugs will already give you
plenty of bugs with different levels of difficulties.

What I don't understand is why you differentiate between bugs and
feature requests. From my point of view there's no big difference,
especially for a programmer. In both cases you get to familiar with the
code and write a patch.

For Deskbar-Applet currently three bugs come to my mind:
- - Adjust files modules that the query string can appear everywhere in a
file's name (case in-sensitive) (see bug 491404)
- - Add possibility to add/change/remove directories that the files module
searches in (see bug 443975). Add home dir and XDG special dirs by default.
- - Programs Handler should notice newly installed programs. Someone
wanted to work on this, but I got no update from him/her. In addition,
the gio port must be completed first. (see bug 343894)

- --
Greetings,
Sebastian Pölsterl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAA

Re: new module proposal: brasero

[Sebastian Pölsterl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Philippe Rouquier schrieb:
> Hi,
> 
Hi Philippe,

> We'd be interested in having brasero integrated into the GNOME desktop.
> 
> [...]

+1 from me.
Brasero is a wonderful application I've been using for quite some time
now. As mentioned some distributions already include brasero by default.
This shows that brasero is ready for the masses and GNOME.

- --
Greetings,
Sebastian Pölsterl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkMrkQACgkQ1ygZeJ3lLIfTLACfeYLtz17zp9lN+Y3niJcU+SOC
qhUAn2YhKn65bXgkFLRMesX6LEyux7Th
=29os
-END PGP SIGNATURE-
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

deskbar-applet branched for 2.24

[Sebastian Pölsterl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Deskbar-Applet has been branched for 2.24. The name of the branch is
gnome-2-24. Development for 2.25/26 will continue in trunk.

- --
Greetings,
Sebastian Pölsterl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkLESIACgkQ1ygZeJ3lLIeXdwCbBosAV+/8JvOOTWYDLbA2rg3e
Io0An2KgwMcj1sajXUQkL+KdM/opwQl4
=jKD5
-END PGP SIGNATURE-
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME 2.24 Showstopper Review

[Sebastian Pölsterl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Andre Klapper schrieb:
> GNOME 2.24.0 release is on September 22 (see [1]), and we still have
> enough 2.24 blocker bugs (and other bugs of course) to fix for
> everybody! Take a look, test & help out, clean up our platform, make
> 2.24 better!
> 

In my opinion an additional blocker is that hamster applet requires
Python 2.5 [1]. It might be just a change in configure.ac if they don't
make use of any Python 2.5 specific features.

[1]: http://bugzilla.gnome.org/show_bug.cgi?id=548914

- --
Greetings,
Sebastian Pölsterl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAki72jcACgkQ1ygZeJ3lLIeN7gCgr7LiJ3pM6ndIkeDXVAjvxrRV
D90AniC6fvirytg4vb8uVYKCMzuWQ960
=nZjO
-END PGP SIGNATURE-
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: External Deps: Minimal Python dependency

[Sebastian Pölsterl]

Johan Dahlin schrieb:

Sebastian Pölsterl wrote:

Vincent Untz schrieb:

Le mardi 22 juillet 2008, à 17:56 +0200, Sebastian Pölsterl a écrit :

Hi!

As mentioned in [1] sqlite is a blessed external dependency now. I 
want  to use sqlite for Deskbar-Applet, too. Because, Python 2.5 has 
a  built-in sqlite module I suggest increasing the minimal version 
to 2.5  from currently 2.4.3 . Of course, Python 2.5 has more 
benefits [2].


[1]:  
http://mail.gnome.org/archives/desktop-devel-list/2008-July/msg00090.html 


[2]: http://docs.python.org/whatsnew/whatsnew25.html


(heh, I should read ddl before replying to mails)

So, I took a quick look at the second link. That's all cool, but can we
get an overview of what is really useful in there for us?

Vincent

* Various speed improvements regarding re module, sets, unicode 
operations (substring, split, en-/decode) and handling exceptions [1].


I don't understand why optimizations is an argument in bumping the 
minimum required version. Sure, those who want to make their python program
can upgrade, but is the intention really to tell users of 2.4 that they 
can't use it because we think it's too slow?


* New ElementTree package for processing XML. It's easy to understand 
and fast.


Available as an external module.

 > * New hashlib package which supports previously unsupported SHA-224,
 > SHA-256, SHA-384, and SHA-512.

I bet this is not useful for any GNOME applications.

* New ctypes package which lets you load libraries and calling 
functions in them.


Available as an external module.

Which leaves us with the 'with statement' as a new feature worthwhile to 
upgrade for.


Is it worth telling users of RHEL5, Debian Etch etc that they can't use 
the GNOME release because you want to use the with statement in your 
code? Is it really that difficult to write code without using it?


Sure, depending on python 2.5 only for the with statement makes no 
sense. It's fine with me to use either the built-in sqlite module if 
available or the external module. I wasn't ware that requiring python 
2.5 would cause so much trouble for users of above distros, because 
python 2.5 is already around for over one and a half years.


--
Greetings,
Sebastian Pölsterl
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: External Deps: Minimal Python dependency

[Sebastian Pölsterl]

Vincent Untz schrieb:

Le mardi 22 juillet 2008, à 17:56 +0200, Sebastian Pölsterl a écrit :

Hi!

As mentioned in [1] sqlite is a blessed external dependency now. I want  
to use sqlite for Deskbar-Applet, too. Because, Python 2.5 has a  
built-in sqlite module I suggest increasing the minimal version to 2.5  
from currently 2.4.3 . Of course, Python 2.5 has more benefits [2].


[1]:  
http://mail.gnome.org/archives/desktop-devel-list/2008-July/msg00090.html

[2]: http://docs.python.org/whatsnew/whatsnew25.html


(heh, I should read ddl before replying to mails)

So, I took a quick look at the second link. That's all cool, but can we
get an overview of what is really useful in there for us?

Vincent

* Various speed improvements regarding re module, sets, unicode 
operations (substring, split, en-/decode) and handling exceptions [1].
* New ElementTree package for processing XML. It's easy to understand 
and fast.
* New hashlib package which supports previously unsupported SHA-224, 
SHA-256, SHA-384, and SHA-512.
* New ctypes package which lets you load libraries and calling functions 
in them.
* The 'with' statement. Which makes it very easy to use locks or 
read/write a file, because it makes sure everything is cleaned up 
correctly (e.g. when an error appeared).


[1]: 
http://docs.python.org/whatsnew/other-lang.html#SECTION0001310000


--
Greetings,
Sebastian Pölsterl
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: External Deps: Minimal Python dependency

[Sebastian Pölsterl]

Alberto Ruiz schrieb:

2008/7/22 Sebastian Pölsterl <[EMAIL PROTECTED]>:

Hi!

As mentioned in [1] sqlite is a blessed external dependency now. I want to
use sqlite for Deskbar-Applet, too. Because, Python 2.5 has a built-in
sqlite module I suggest increasing the minimal version to 2.5 from currently
2.4.3 . Of course, Python 2.5 has more benefits [2].


Why don't you use the sqlite bindings for python2.4?

Jdahlin suggested that, too. If you really don't want to depend on 
Python 2.5, I'm going to do it that way.


--
Greetings,
Sebastian Pölsterl
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: External Deps: Minimal Python dependency

[Sebastian Pölsterl]

Olav Vitters schrieb:

On Tue, Jul 22, 2008 at 05:56:27PM +0200, Sebastian Pölsterl wrote:
As mentioned in [1] sqlite is a blessed external dependency now. I want  
to use sqlite for Deskbar-Applet, too. Because, Python 2.5 has a  
built-in sqlite module I suggest increasing the minimal version to 2.5  
from currently 2.4.3 . Of course, Python 2.5 has more benefits [2].


What distributions have Python 2.5 and what has changed since the last
time this came up? I know RHEL5 (buildbot) has 2.4 and it is not just a
matter of building Python within jhbuild (breaks badly with x86_64).

I wasn't around when this came up last time. Could you point me to the 
thread?


--
Greetings,
Sebastian Pölsterl
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

External Deps: Minimal Python dependency

[Sebastian Pölsterl]

Hi!

As mentioned in [1] sqlite is a blessed external dependency now. I want 
to use sqlite for Deskbar-Applet, too. Because, Python 2.5 has a 
built-in sqlite module I suggest increasing the minimal version to 2.5 
from currently 2.4.3 . Of course, Python 2.5 has more benefits [2].


[1]: 
http://mail.gnome.org/archives/desktop-devel-list/2008-July/msg00090.html

[2]: http://docs.python.org/whatsnew/whatsnew25.html

--
Greetings,
Sebastian Pölsterl
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: evolution-data-server now depends on sqlite 3.5

[Sebastian Pölsterl]

Am Donnerstag, den 17.07.2008, 13:27 +0200 schrieb Patryk Zawadzki:
> 2008/7/17 Sebastian Pölsterl <[EMAIL PROTECTED]>:
> > Am Mittwoch, den 16.07.2008, 18:41 +0200 schrieb Luca Ferretti:
> >> According to this[1] commit, evolution-data-server now depends on
> >> sqlite.
> >>
> >> Due to the increasing[2] number of project that require this library,
> >> could we consider to officially add sqlite to external deps?
> > I'm all for it. That way I can use sqlite to store Deskbar-Applet's
> > history.
> 
> Isn't deskbar (at least in part) a python app? Doesn't stock python
> ship with sqlite3 bindings?
> 
Only Python 2.5 does, but only Python 2.4 is a blessed external
dependency. Increasing the minimum version to 2.5 would make more sense
in this case.

-- 
Greetings,
Sebastian Pölsterl


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: evolution-data-server now depends on sqlite 3.5

[Sebastian Pölsterl]

Am Mittwoch, den 16.07.2008, 18:41 +0200 schrieb Luca Ferretti:
> According to this[1] commit, evolution-data-server now depends on
> sqlite.
> 
> Due to the increasing[2] number of project that require this library,
> could we consider to officially add sqlite to external deps?
> 
I'm all for it. That way I can use sqlite to store Deskbar-Applet's
history.

-- 
Greetings,
Sebastian Pölsterl


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Using vala

[Sebastian Pölsterl]

kamel derouiche schrieb:

Hi,,


I want to use vala for information system (uname,
kernel,..., memory status)
 
how I should do to use the files: sys / utsname, io.h,

poll.h

You should probably ask on vala-list: 
http://mail.gnome.org/mailman/listinfo/vala-list


--
Greetings,
Sebastian Pölsterl
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Need Leadership

[Sebastian Pölsterl]

natan yellin schrieb:

On Sun, Jun 29, 2008 at 2:19 PM, Sebastian Pölsterl <[EMAIL PROTECTED]>
wrote:


Diego Escalante Urrelo schrieb:


Hey,

On 6/28/08, Thomas H.P. Andersen <[EMAIL PROTECTED]> wrote:


On Fri, Jun 27, 2008 at 6:13 PM, Dave Neary <[EMAIL PROTECTED]> wrote:
 >

 But this all getting a bit off topic I guess :) I just wanted to point
 out two things that might motivate developers (ego boosts and personal
 profit) and see if there are ways we can help those along. The ego
 boosting is already there. There can be enough hacker energy for weeks
 in a single "Awesome!" One way we could do more of this could be a
 periodical vote for the CoolestHacker or whatever.


What if we hack a twitter like thing for GNOME where we can drop a
line about what are we doing now or we did this week in GNOME, or
maybe just a random thought. At the end of the week or biweekly
someone grabs the best lines and sends a GNOME Almost Weekly News.
It would work as an informal way of keeping track of what we are doing
(in human readable format) and a way to comment on what other cool
guys are doing. Pretty much like twitter:


 I like the idea. That would be an easy way to keep track of what's
happening in GNOME at a central place. The main problem I see is to convince
developers that they actually post their status updates.


Wouldn't that defeat the purpose. If developers don't want to post, forcing
them to do so isn't going to attract more contributors.

I don't want to force developers to post at all. But there should be a 
number of developers that post regularly. Maybe I'm wrong and most 
developers love to post their status updates their. I don't know.



Besides, isn't this the point of project/people trackers like CIA and Ohloh?

Those sites just track stats. The doesn't tell you what the developer's 
plans are. Sure you could read the commit messages, but it's cumbersome 
to read all new commit messages of the projects you're interested in.


--
Greetings,
Sebastian Pölsterl
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Need Leadership

[Sebastian Pölsterl]

Diego Escalante Urrelo schrieb:

Hey,

On 6/28/08, Thomas H.P. Andersen <[EMAIL PROTECTED]> wrote:

On Fri, Jun 27, 2008 at 6:13 PM, Dave Neary <[EMAIL PROTECTED]> wrote:
 >

 But this all getting a bit off topic I guess :) I just wanted to point
 out two things that might motivate developers (ego boosts and personal
 profit) and see if there are ways we can help those along. The ego
 boosting is already there. There can be enough hacker energy for weeks
 in a single "Awesome!" One way we could do more of this could be a
 periodical vote for the CoolestHacker or whatever.


What if we hack a twitter like thing for GNOME where we can drop a
line about what are we doing now or we did this week in GNOME, or
maybe just a random thought. At the end of the week or biweekly
someone grabs the best lines and sends a GNOME Almost Weekly News.
It would work as an informal way of keeping track of what we are doing
(in human readable format) and a way to comment on what other cool
guys are doing. Pretty much like twitter:

I like the idea. That would be an easy way to keep track of what's 
happening in GNOME at a central place. The main problem I see is to 
convince developers that they actually post their status updates.


--
Greetings,
Sebastian Pölsterl
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Module proposal: Project Hamster for GNOME 2.24

[Sebastian Pölsterl]

Toms schrieb:
> I would like to go with LGPLv3, but since there is certain evidence of
> deskbar code, i'll check what they are using and use that
> Any suggestions on this are welcome
> 
Deskbar is using GPLv2 or later.

-- 
Greetings,
Sebastian Pölsterl
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

deskbar-applet branched for 2.22

[Sebastian Pölsterl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Deskbar-Applet has been branched for 2.22. The name of the branch is
gnome-2-22. Development for 2.23/24 will continue in trunk.

- --
Greetings,
Sebastian Pölsterl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH3lgN1ygZeJ3lLIcRAi56AJ9jusX8HIjURrJtoDM+PVeRHnZQlwCfaJxL
GBex8RJiehIk+AqXKCB7Pbs=
=LD9y
-END PGP SIGNATURE-
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: State of gvfs in Gnome 2.21

[Sebastian Pölsterl]

Are there any plans for providing python bindings?

-- 
Greeings,
Sebastian Pölsterl
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Requiring DOAP instead of MAINTAINERS file

[Sebastian Pölsterl]

Wouter Bolsterlee schrieb:
> 2008-01-22 klockan 01:51 skrev Shaun McCance:
>> On Tue, 2008-01-22 at 00:02 +0100, Marko Anastasov wrote:
>> >
>> > What does everybody think about, in the long run, expanding this idea
>> > of mimicing apache projects pages and having one page for each
>> > module where all the "metadata" about the project will be nicely
>> > presented (be it from DOAP files or the files we keep today),
>> > with addition to summaries from recent activity on the mailing list
>> > (eg latest posts, recent most active discussion), bugzilla (similar),
>> > commits and with developers' blogs aggregated (perhaps showing
>> > only those posts tagged with the name of the project to reduce noise).
>> > That would then be a one stop overview of all development activity.
>> >
>> > Just an idea I got recently...
>>
>> That is exactly the sort of stuff that Pulse does.
>>
>> http://www.gnome.org/~shaunm/pulse/web/set/gnome-2-22-desktop
>
> IMHO, this stuff should become something like "projects.gnome.org". That
> would be seriously cool.
>
I agree. Pulse looks really great. Why shouldn't we us it when it already
exists?

-- 
Greetings,
Sebastian Pölsterl
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Lowering the barrier

[Sebastian Pölsterl]

Emmanuel Fleury schrieb:
> Who wrote:
>> http://live.gnome.org/GtkLove doesn't even mention that anyone marking
>> a bug as being a GnomeLove bug should be prepared to help a beginner
>> to solve it (this is also likely to lead to 'misuse', I guess):
>>
>> "Love Bug List
>>
>> This list is intended as collection of bugs suitable for novice GTK+
>> hackers. Add items to it (adding the 'gnome-love' keyword to the bug)
>> only if you think they could be fixed in a reasonable time frame by a
>> free software developer without much experience in GTK+. If you are
>> unsure, add it. Please do not use this list as a personal whishlist of
>> issues you'd like to see fixed. "
>>
>> Specifically, I think that the "If you are unsure, add it" comment
>> could lead to frustration?
>>
>> Also
>> http://live.gnome.org/GnomeLove does not make it specifically clear
>> anywhere that there are people to support anyone fixing a 'GnomeLove'
>> bug, in contrast The 'Mentored Projects' sections is specifically
>> mentioned, http://live.gnome.org/MentoredProjects, with mentoring
>> being a clear component - could that page also mention that a
>> GnomeLove bug, in it's own way, is like a mentored project? I guess
>> just a few tweaks of both pages could be very useful here?
> 
> What about a third category (after love-bug and mentored-project) such
> as 'gnome-academic-bug' intended to be a student project for few weeks,
> few months or a semester ?
> 
> Computer science education is more and more in need of original projects
> for their students and if you could just mark some bugs and/or some
> wishes to be feasible by some students it would be nice.
> 
> In a matter of fact I'm already using the bug-list of Gnome for getting
> some projects for my master students. :)
> 
What about a GNOME Love week where we help new contributors getting
started, something like a mini-SoC? The complexity of the tasks must be
lower, of course.

-- 
Greetings,
Sebastian Pölsterl
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Lowering the barrier

[Sebastian Pölsterl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Who schrieb:>
> *** In the case of 'Gnome Love' bugs - perhaps people people could
> offer to 'mentor' on them, so anyone needing to ask questions in
> attempts to fix them can have a ready contact. I understand, of
> course, that time is important and it may well be quicker for that
> mentor to fix the bug themselves - even so, perhaps it is worth it?
> 
I totally agree on this. Each GNOME love bugs should have a mentor and a
short explanation how to contact that mentor. If you know that you can
ask someone who's familiar with the particular application it's much
much easier to start contributing, instead of programming without
"supervision" where you'll feel lost pretty soon.

- --
Greetings,
Sebastian Pölsterl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHNtZx1ygZeJ3lLIcRAr9UAKCcvkyx9efcas/xAHN4HGK4u27KTgCgqE+H
0xMNJwYdPlxW0rrPiUfsyls=
=Dmrs
-END PGP SIGNATURE-
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Lowering the barrier

[Sebastian Pölsterl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Mikkel Kamstrup Erlandsen schrieb:
> 
> POINTS OF ACTION:
> 
> Here is a list of proposed actions to address some of the outlined issues.
> They are intended not impose excessive work load on module maintainers.
> 
>  * Write a "GObjects for Java/C# Developers" document (or maybe two separate
> docs) meticulously explaining the concepts of classes and object instances
> compared to Java/C# objects for the lay hacker
> 
I would love to see something like that!

> 
> * Lobby for distributions to create a gnome-developer-studio package
> installing all build deps, documentation, latest anjuta, everything you need
> to hack on Gnome. Pimp those packages on the official Gnome pages.
> 
On Ubuntu you can already do that when installing the gnome-devel package.

- --
Greetings,
Sebastian Pölsterl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHNcVh1ygZeJ3lLIcRAj9uAJ4iX7VNrTDVjv2d+ML1gmSn7pZhJgCgh9qP
xLqRQtr9Hr5ZCUa1EEA5oLw=
=eCX+
-END PGP SIGNATURE-
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

deskbar-applet branched for 2.20

[Sebastian Pölsterl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi!

Deskbar-Applet has been branched for 2.20.
Development for 2.21/2.22 is taking place in trunk. Plans are available
at http://live.gnome.org/DeskbarApplet/RoadMap222

- --
Greetings,
Sebastian Pölsterl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHE5Ar1ygZeJ3lLIcRAqB9AJsF2VoX2KpLx9I0y/Q+ypz5/2gntgCglixW
AS4a9yYBcxJg7Qfa8jaNRvQ=
=sWLV
-END PGP SIGNATURE-
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Requesting UI Freeze break for gnome-panel and gnome-utils

[Sebastian Pölsterl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jaap Haitsma schrieb:
> Hi,
> 
> The gnome-searchtool icon got removed from gnome-icon-theme because it
> got replaced by the system-search icon.
> 
Good to know. Deskbar-Applet uses the icon as well. So the icon should
get replaced there, too.

- --
Greetings,
Sebastian Pölsterl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG01Le1ygZeJ3lLIcRAi+aAJ44o5VH5GptyvLOCgz6WFBLASKp3QCfRune
Z+BMr5w6vKTrcSTEaKF0BaQ=
=hfcS
-END PGP SIGNATURE-
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Requesting UI freeze break for Deskbar-Applet

[Sebastian Pölsterl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi!

The attached patch adds a "Back to matches" button under the list of
actions (see attachment) and makes the '>' beneath matches that have
more than one action clickable to go the list of actions. This replaces
that you have to press ctrl while clicking on a match to display its
actions.

Raphaël knows about this patch, too, and is all for it.

This patch tackles bug #468455 and bug #468456.

The patch is important, because it helps a lot to navigate. Without it,
navigating between the list of actions and the list of matches would
only be possible using the keyboard. Navigating using the keyboard is
somewhat a hidden feature and everything you could achieve with the
keyboard should be possible with the mouse, too.
If the patch won't be part of the final 2.20 release many users
obviously won't recognize the new feature of actions, because they won't
intuitionally find the way to the list actions. Actions are a core
feature of the new Deskbar-Applet. Therefore, I think this patch should
be applied.

[1]: http://bugzilla.gnome.org/show_bug.cgi?id=468455
[2]: http://bugzilla.gnome.org/show_bug.cgi?id=468456

- --
Greetings,
Sebastian Pölsterl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGzv4p1ygZeJ3lLIcRAo0GAKCFkOSjz2ksRdVtYZ7DHZnmY9ADGACcClIm
d4alahwCUn8j0auFKXXhctw=
=01Vk
-END PGP SIGNATURE-
Index: /home/sebp/workspace/deskbar-applet/deskbar/ui/cuemiac/CuemiacTreeView.py
===
--- /home/sebp/workspace/deskbar-applet/deskbar/ui/cuemiac/CuemiacTreeView.py	(revision 1582)
+++ /home/sebp/workspace/deskbar-applet/deskbar/ui/cuemiac/CuemiacTreeView.py	(working copy)
@@ -29,10 +29,13 @@
  'has-more-actions' : (gobject.TYPE_BOOLEAN, 'whether the match has more than one action',
 'If set to True a symbol will be displayed on the right',
 False, gobject.PARAM_READWRITE),
- 'match-markup' : (gobject.TYPE_STRING, 'markup for match description',
-  'markup for match description',
-  "", gobject.PARAM_READWRITE),
 }
+__gsignals__ = {
+# This signal will be emited when '>' on the right is clicked
+"show-actions-activated": (gobject.SIGNAL_RUN_LAST, gobject.TYPE_NONE, [gobject.TYPE_PYOBJECT]),
+# This signal will be emited then an area that's not the '>' from above is clicked
+"do-action-activated": (gobject.SIGNAL_RUN_LAST, gobject.TYPE_NONE, [gobject.TYPE_PYOBJECT]),
+}
 
 def __init__ (self):
 gtk.CellRendererText.__init__ (self)
@@ -40,6 +43,12 @@
 self.__match_count = 0
 self.__has_more_actions = False
 self.__match_markup = ""
+self.__button_x = 0
+self.__button_y = 0
+self.__button_width = 0
+self.__button_height = 0
+
+self.set_property("mode", gtk.CELL_RENDERER_MODE_ACTIVATABLE)
 
 # Grab some default theme settings
 # they are probably incorrect, but we reset
@@ -64,8 +73,8 @@
 self.render_match (window, widget, background_area, cell_area, expose_area, flags)
 else:
 self.render_category (window, widget, background_area, cell_area, expose_area, flags)
-
-def render_match (self, window, widget, background_area, cell_area, expose_area, flag):
+   
+def render_match (self, window, widget, background_area, cell_area, expose_area, flags):
 ctx = window.cairo_create ()
 
 # Set up a pango.Layout
@@ -72,8 +81,7 @@
 more_actions_layout = ctx.create_layout ()
 if self.get_property("has-more-actions"):
 more_actions_layout.set_markup (">")
-else:
-more_actions_layout.set_text("")
+
 more_actions_layout.set_font_description (self.header_font_desc)
 
 more_actions_layout_width, more_actions_layout_height = more_actions_layout.get_pixel_size()
@@ -78,19 +86,41 @@
 
 more_actions_layout_width, more_actions_layout_height = more_actions_layout.get_pixel_size()
 
-state = self.renderer_state_to_widget_state(flag)
+state = self.renderer_state_to_widget_state(flags)
+
+self.__button_width = more_actions_layout_width + 2
+self.__button_height = cell_area.height 
 
 # Draw the actual text in the remaining area
 cell_area_width = cell_area.width
-cell_area.width -= more_actions_layout_width + 2
-gtk.CellRendererText.do_render (self, window, 

Re: Introducing NewStuffManager

[Sebastian Pölsterl]

James \"Doc\" Livingston wrote:
> On Sat, 2006-10-07 at 13:09 -0600, Tom Tromey wrote:
>[...]
>> How does this relate to python eggs[2]?  And if it doesn't, why not?
>> It seems to me that if there's an upstream project that handles a lot
>> of this, then it would be beneficial to simply re-use it.
>
> For Python plugins that could work, but do we want to support things
> other than Python? I'll ignore natively compiled (i.e. C) plugins since
> they get icky.
>
> The applications that the OP mentioned, Deskbar, Gedit and Epiphany (and
> Rhythmbox, which is a potential non-Desktop client) use Python, but what
> about other things? Evolution, Banshee et al use Mono-based plugins,
> some other app might use Java plugins, should they be able to use
> NewStuffManager too?
>
Java and Mono plugins should be no problem, because they don't have to be
compiled on the user's platform.
I'm currently working on NewStuffManager integration with Banshee. It
shouldn't be a big deal to get this working.

-- 
Greetings,
Sebastian Pölsterl
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Introducing NewStuffManager

[Sebastian Pölsterl]

Hi!

I released a new version that already contains some of the suggestions
made here:

* Support for GnuPG signatures (the XML file must contain an element
http://www.example.com/path/to/myfile.tar.gz.sig).
The public key will be automatically imported from a key server,
* XML element version now looks like 1.2.3.4/
* The Spec file is stored in an INI-like format now
* Some bug fixes

The introduction at http://www.k-d-w.org/clipboard/NewStuffManager has
been updated as well.

You can download the new version from the git repository
http://www.k-d-w.org/git/new-stuff-manager.git

It would be very nice, if some people out there could test it, especially
the GnuPG signature part.

-- 
Greetings,
Sebastian Pölsterl
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Introducing NewStuffManager

[Sebastian Pölsterl]

James Henstridge wrote:
> On 08/10/06, Sebastian Pölsterl <[EMAIL PROTECTED]> wrote:
>> Tom Tromey wrote:
>> > How does this relate to python eggs[2]?  And if it doesn't, why not?
>> > It seems to me that if there's an upstream project that handles a lot
>> > of this, then it would be beneficial to simply re-use it.
>> >
>> eggs are something like a setup wizard. You pack your files into an egg
>> so
>> that the user can install the application easily. I don't know what you
>> mean. Do you want to support eggs as an download source, or what?
>
> Python eggs provide a way to distribute the code, provide metadata
> about the egg plus its dependencies, etc.  If the egg contains just
> Python code, then it doesn't need to even be unpacked: the zip
> importer can access the code directly.
>
> So I guess a different way of phrasing Tom's question is:
> 1. why not distribute deskbar applet plugins as Python eggs?
> 2. if deskbar applet plugins could come in the form of eggs, why not
> make NewStuffManager into a system for installing, updating and
> managing these plugin eggs?
>
> The repository file might just extract the metadata from the eggs so
> that NewStuffManager could work out what needs to be downloaded.
>
You're idea sounds good. I tried to get into python eggs a while ago, but
not with much success. I should give it another try.
If deskbar-applet can work with eggs that would be great.

-- 
Greetings,
Sebastian Pölsterl
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Introducing NewStuffManager

[Sebastian Pölsterl]

Diego Escalante wrote:
>> > What happens if a distro wants to ship a plugin?  I'm specifically
>> > thinking about upgrades and versioning, and making sure the manager
>> > does the right thing.  E.g., consider this scenario: the distro ships
>> > a plugin (version 1), then the user updates from the update site
>> > (version 2) into his home directory, and then the OS itself is
>> > upgraded, pulling in version 3.  (If this sounds far-fetched... I've
>> > done this multiple times with Eclipse plugins on Fedora.)
>> >
>> Okay, let's say you have version 1 of the plugin installed. Then you
>> have
>> to call NewStuff.GetAvailableUpdates([("id_of_myplugin", "1.0.0.0")]) to
>> findout if an update is available. This call returns [("id_of_myplugin",
>> "2.0.0.0")]. So NewStuffManager downloads and installs version 2 of the
>> plugin. After that your distro updates to version 3. If you call
>> NewStuff.GetAvailableUpdates([("id_of_myplugin", "3.0.0.0")]) the return
>> value won't contain an entry for "id_of_myplugin" anymore. Therefore, no
>> update is available. Of course, the version of the installed plugin must
>> be stored in the plugin itsself or the application that uses it,
>>
> I understand then that applications that relay on NSM in the future
> will have to do some logic like "plugin in /usr is 2.0 but plugin in
> /home is 1.0, I will prefer the one in /usr". I don't see a lot of
> scenarios where users would kill for an older version of a plugin and
> in any case they can rename the plugin in /home so it's a different
> plugin with it's own version (and it's never updated).
>
With your solution _all_ plugins in /home have version 1 and all in /usr
version 2. I think it's better that each plugin has it's own version.
Again refering to Deskbar-Applet: Each plugin contains dictionary that
contains the plugin's information like version, requirements.

>> > Is there any way for a plugin to express its requirements?  Maybe it
>> > needs other plugins, or specific versions of things, or ... your idea
>> > here.  This sort of thing is a staple of other plugin management
>> > environments.  (Eclipse for sure, which goes the overkill route.  JNLP
>> > has a lighter touch, basically allowing re-use via URLs, though having
>> > a tag to indicate the required JRE version.)
>> >
>> Currently, there's no way to do this via NewStuffManager. Deskbar-Applet
>> plugins can contain a function that check the requirements, though. If
>> some of the requirements are missing the plugin isn't loaded by
>> deskbar-applet.
>>
> Python plugins would be easy to check (I think) since probing via
> Python if the module foo is available would be enough, if it's not
> found NSM can make a guess like "looks like you are missing module
> foo, that's required for this plugin. Look for python-foo in your
> distribution.". More than that would be a little too optimistic for a
> human maintained list.
> C plugins might be another history (but actually, I don't know if
> writing C plugins should be promoted at all)...
>
>> Mabye, it's a good idea to implement a way to allow a plugin to express
>> its requirements. I'm grateful for any suggestion.
>>
> I'm a Python fan, so I must insist that mentioning in the XML that the
> plugin needs module foo, bar, cuac would be enough for any Python
> plugin. C ones would be harder.
>
That idea sounds great to me. It would be enough to supply a list of
modules that should be available. An easy try: import module_xyz except:
print "plugin not available" would do the trick.

C plugins are another story. NewStuffManager supports no compiling of the
C code, either.

-- 
Greetings,
Sebastian Pölsterl
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Introducing NewStuffManager

[Sebastian Pölsterl]

Tom Tromey wrote:
>
> I've got a few questions about it.  I've tried to read through all the
> available info -- forgive me if I missed something.
>
> First, you may want to read through the JNLP spec[1] for ideas.  JNLP
> is more or less the equivalent java technology, though a bit more
> application-centric.
>
Afaik Java Web Start is used to run applications over the web instead of
downloading and installing them first. NewStuffManager tries not to
achieve such goal.

> What happens if a distro wants to ship a plugin?  I'm specifically
> thinking about upgrades and versioning, and making sure the manager
> does the right thing.  E.g., consider this scenario: the distro ships
> a plugin (version 1), then the user updates from the update site
> (version 2) into his home directory, and then the OS itself is
> upgraded, pulling in version 3.  (If this sounds far-fetched... I've
> done this multiple times with Eclipse plugins on Fedora.)
>
Okay, let's say you have version 1 of the plugin installed. Then you have
to call NewStuff.GetAvailableUpdates([("id_of_myplugin", "1.0.0.0")]) to
findout if an update is available. This call returns [("id_of_myplugin",
"2.0.0.0")]. So NewStuffManager downloads and installs version 2 of the
plugin. After that your distro updates to version 3. If you call
NewStuff.GetAvailableUpdates([("id_of_myplugin", "3.0.0.0")]) the return
value won't contain an entry for "id_of_myplugin" anymore. Therefore, no
update is available. Of course, the version of the installed plugin must
be stored in the plugin itsself or the application that uses it,

> Is there any way for a plugin to express its requirements?  Maybe it
> needs other plugins, or specific versions of things, or ... your idea
> here.  This sort of thing is a staple of other plugin management
> environments.  (Eclipse for sure, which goes the overkill route.  JNLP
> has a lighter touch, basically allowing re-use via URLs, though having
> a tag to indicate the required JRE version.)
>
Currently, there's no way to do this via NewStuffManager. Deskbar-Applet
plugins can contain a function that check the requirements, though. If
some of the requirements are missing the plugin isn't loaded by
deskbar-applet.

Mabye, it's a good idea to implement a way to allow a plugin to express
its requirements. I'm grateful for any suggestion.

> How does this relate to python eggs[2]?  And if it doesn't, why not?
> It seems to me that if there's an upstream project that handles a lot
> of this, then it would be beneficial to simply re-use it.
>
eggs are something like a setup wizard. You pack your files into an egg so
that the user can install the application easily. I don't know what you
mean. Do you want to support eggs as an download source, or what?


-- 
Greetings,
Sebastian Pölsterl
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Introducing NewStuffManager

[Sebastian Pölsterl]

Chipzz wrote:
>> Indeed, applications should be updated by the distribution. But
>> NewStuffManager is intended to update plugins only not hole
>> applications.
>
> And those still should be updated by the distribution (in case they came
> with the distribution in the first place).
>
In the case of deskbar-applet some handlers are shipped with the
distribution, but the user has still the freedom to install new handlers.
NewStuffManager helps installing new handlers and keeping them up-to-date.

-- 
Greetings,
Sebastian Pölsterl
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Introducing NewStuffManager

[Sebastian Pölsterl]

Shaun McCance wrote:
>
> You absolutely can translate the name of a plugin, just as we
> translate the names of applications.  You certainly want stable
> IDs, but names are human-readable content.  The first example
> we encounter on the web page is "Leo.org dictionary".  The word
> "dictionary" is an English word.  Germans, presumably, would
> rather see "Leo.org Wörterbuch".
>
> When names are simple functional descriptions, there is no doubt
> they should be translated.  When they are catchy words (Epiphany,
> Evolution, Ekiga), then perhaps not.  But even in those cases,
> some languages would like to be able to transliterate those
> words to their alphabet.
>
> As for the effort required to keep all those translations inside
> the repository, it's a lot of effort to do all the translations
> as it is, but we manage.  Why?  Because Gnome has the best damn
> translation teams on the planet.  All we have to do is get stuff
> hooked up to PO files in Gnome CVS, and translations will happen.
> Surely we can write a clever script to add plugins to the server
> which will extract translated data from the tarball and merge it
> all into the repository XML file.  We're smart like that.
>
You have a point here. I'm convinced that it's a very good idea to
translate the repository file. I take this into account for the future
development. Thanks a lot for pointing that out to me.

>> > The repository XML file doesn't seem to contain any way
>> > of specifying versions of the application for which the
>> > plugin can be used.  Imagine, for instance, the plugin
>> > bar for the application foo.  Version 2 of foo adds some
>> > new hooks for plugins, which version 2 of bar uses.  But
>> > we keep version 1 of bar in the repository for people
>> > still using version 1 of foo.
>> >
>> That's true that can cause some issues. But you could also provide two
>> repository files one for version 1 and one for version 2.
>
> That seems like a feasible way of doing things.
But in the end when you have maybe 5 different versions and a lot of
plugins the repository will likely become very big. I think it's best to
seperate plugins for different versions of the application. This makes it
clear that the plugins in the repository are all for one version of the
application. That's what all the distributions do, too.

>
> And just not to come off too negative, what NewStuffManager
> is doing is absolutely awesome, and I'm excited to get it
> into Gnome.
>
I'm glade you like it ;)

-- 
Greetings,
Sebastian Pölsterl
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Introducing NewStuffManager

[Sebastian Pölsterl]

Martin Waitz wrote:
>
> Isn't updating applications something which should be solved by the
> distribution?  What do you do in multi-user installations?
>
Indeed, applications should be updated by the distribution. But
NewStuffManager is intended to update plugins only not hole applications.

-- 
Greetings,
Sebastian Pölsterl
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Introducing NewStuffManager

[Sebastian Pölsterl]

Shaun McCance wrote:
>
> I have some comments and questions after reading that
> page.  Mind you, I haven't downloaded NewStuffManager
> or dug into it.  I'm going off of what you've described
> on the web page.
>
> The repository XML files contain human-readable strings,
> like the name element.  From the RNG scheme, it doesn't
> appear these can be localized using the standard xml:lang
> attribute.
>
I must admit didn't think of i18n or l10n at all.

But I don't think it's a good idea to internationalize the repository's
XML file.
Especially the name element. Can you really translate the name of a plugin?
Furthermore, it would be lot of work to translate all the stuff for a big
repository and contents can change often. So you would need to translate
the file over and over again.
Lastly. RPM or deb files aren't internationalized either.

> The repository XML file doesn't seem to contain any way
> of specifying versions of the application for which the
> plugin can be used.  Imagine, for instance, the plugin
> bar for the application foo.  Version 2 of foo adds some
> new hooks for plugins, which version 2 of bar uses.  But
> we keep version 1 of bar in the repository for people
> still using version 1 of foo.
>
That's true that can cause some issues. But you could also provide two
repository files one for version 1 and one for version 2.

> I see no reason to XMLify existing syntaxes, particularly
> those that are easy to parse.  I'm referring to the version
> element.  Why not just allow
>   3.1.1.0/version>
> instead of the more bulky
>   
> People sometimes do this with dates, and I think it's just
> too overbearing.  The syntax for version numbers is already
> well understood.
>
I'm open to that.

> The spec file is data.  You should use a data language like
> XML or key (INI-style) files.  Unless there's some really
> good reason why people need the full expressive power of
> an actual programming language, using one for data files
> is inviting trouble.
>
I thought that myself. I'm most likely going to use an INI style spec file
in the future.

> Is NewStuffManager the best name we can come up with?
>
It's just the working title. I'm looking forward to any suggestions.

> And one of my layout pet peeves: In the screenshots, you
> have headers (e.g. "Available Extensions").  Below the
> header is a big list box with buttons and maybe a note.
> The contents underneath are indented.  I know the HIG
> recommends indenting groups, but I think it looks silly
> when there's only a single group containing primarily
> a large control like a list box.  I suppose I should
> bring this up more generally on the usability list.
>
That's something that's not NewStuffManager specific. Besides, I didn't
make the GUI.

-- 
Greetings,
Sebastian Pölsterl
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Introducing NewStuffManager

[Sebastian Pölsterl]

Andrew Sobala wrote:
>
> Hi Sebastian,
>
> I missed Nigel's original e-mail, and on reading it now, I think an
> extension downloading and applying mechanism is needed in GNOME. Thanks
> loads for working on this, you rock :-)
>
Thanks a lot!

> I haven't looked at the presentation in too much depth, but in Nigel's
> original e-mail, he mentions there's no security. What's the status on
> this - have you implemented GPG signing now, or are you still planning
> on doing so in the future? I do think any extension mechanism nowadays
> is absolutely worthless until we can verify that the code came from a
> trusted source.
>
GPG support is on my todo list. Currently, you can only provide a checksum
(md5 or sha1) and NewStuffManager verifies the downloaded file.

-- 
Greetings,
Sebastian Pölsterl
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Introducing NewStuffManager

[Sebastian Pölsterl]

Hi!

My name is Sebastian I'm 20 years old and co-author of Deskbar-Applet for
about 3 months.
You may have heard
(http://mail.gnome.org/archives/desktop-devel-list/2006-July/msg00807.html)
of NewStuffManager from Nigel Tao some time ago.

So, I'm the guy who's responsible for that project.

But things have changed:
We decided on removing NewStuffManager from Deskbar-Applet and create a
new project. There's still a patch available for Deskbar-Applet to
integrate NewStuffManager support, though.

I'm posting this here to encourage you to read my presentation at
http://www.k-d-w.org/clipboard/NewStuffManager/ and to find out what you
are expecting from such an application.

-- 
Greetings,
Sebastian Pölsterl
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list