Re: Platform
Il giorno gio, 21/05/2009 alle 21.30 +0300, Stefan Kost ha scritto: > Bastien Nocera schrieb: > > On Tue, 2009-05-19 at 17:15 +0300, Stefan Kost wrote: > > > > > >>> You might be confusing mDNS and service discovery with the protocols > >>> implemented on top of it. We want to use both UPNP and mDNS for > >>> interoperability purposes, but I don't see the point in re-coding mDNS > >>> applications to use UPNP instead > >> I just pointed to the legal situation. I know that those are two > >> different things and idealy we support them both as needed. > > > > A trademark problem? Why is that an issue to us what Apple calls their > > mDNS stack? > > > > I still don't understand what you're worried about... > > > this is from lennarts blog: > http://0pointer.de/blog/projects/bonjour-apache-license.html > would be good if avahi developers could comment here. > > Stefan As I read this: Apple's implementation is under the Apache license, which isn't particularly good, *SO* Avahi itself has been rewritten using the LGPL, and offers much better integration with the GNU/Linux stack (for example, DBus support...). This means there're no compatibility problems with Avahi and other free (as in speech) software around. This I got by reading http://avahi.org/. To sum it up: the mDNS specification is there to implement, Apple released Bonjour with the Apache license, Avahi implements it using the LGPL. Maybe I'm missing something? Matteo signature.asc Description: Questa è una parte del messaggio firmata digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mutter with proprietary OpenGL/ES library ??
On ven, 2009-07-10 at 05:45 +0100, Joone Hur wrote: > http://www.gnu.org/licenses/gpl-faq.html#WindowsRuntimeAndGPL > > I am wondering if it is the same case. > > The GPL v2 has the following exception. > > However, as a special exception, the source code distributed need not > include anything that is normally distributed (in either source or > binary form) with the major components (compiler, kernel, and so on) > of the operating system on which the executable runs, unless that > component itself accompanies the executable. > > Is proprietary OpenGL/ES libraries applied by this exception? I don't think so. You can work without a HW accelerated OpenGL library, by using the software renderer of things like MESA, and your system would run all the same (slow, but still run). The exception is thought just to mean: hey, if you do a Tic-Tac-Toe program for Windows in GPLv2, you don't need to provide also the source code or the executables of all the libraries you link to if they are critical system ones, like user32.dll, ntoskrnl.dll or, in Unixland, pthread.so or vmlinux. It would be unpractical, and sometimes outright impossible. That doesn't mean you can link to non-GPLv2 executables as you see fit. Regards, Matteo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mutter with proprietary OpenGL/ES library ??
On Mon, Jul 13, 2009 at 9:53 AM, Dave Neary wrote: > Hi, > > Matteo Settenvini wrote: > > Unless you are a lawyer, shouldn't you qualify that with "IANAL"? By who > is the exception "thought just to mean"? Sorry, didn't want to sound too harsh or imperative. > > The exception was initially added to allow GNU applications to run on > proprietary Unix systems, with proprietary libc and system libraries. > Since OpenGL-ES is typically included with the system in embedded > environments which support it as part of the standard system, it seems > to me like the exception applies. But IANAL. IANAL too, but I'm not sure it fits. It's questionable if it is a system component you can't live without, like glibc. However, that's just my opinion. I apologize, -- Matteo Settenvini FSF Associated Member Email : mat...@member.fsf.org ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME and non-linux platforms (release team please stand up)
Really, please don't turn this thread to an aggressive flamewar. Sun's entitled to what they want with their time and money; if they think OpenSolaris is the way to go, they're free to pursue it, and personally I wish them good luck. Even if I'm not an OpenSolaris user, I think that biodiversity in software is a good thing, and contamination across different platforms can bring us nice ideas as well as we can provide nice ideas to others. They've contributed much in the years, and telling them that what they pursue is a "dead end" is not... well... nice. Please don't let things slip. Matteo On mer, 2009-07-22 at 14:06 -0500, Jason D. Clinton wrote: > On Wed, Jul 22, 2009 at 1:45 PM, Lennart Poettering > wrote: > > > Please don't turn this in pointless and off-topic flamewar > about the > point or pointlessness of Solaris. > > Obviously the alleged pointlessness of something that we are arguing > about is relevant. Whether or not there are--you know--actual people > using said OS is what this is really about. And apparently even Sun > doesn't think so since they no longer invest the same level of > resources in it that they once did. I'm calling a duck a duck here. > It's a failure and even Sun knows that it is. There's no reason we > shouldn't be scrambling a few eggs on Solaris to advance the Linux > desktop experience. > > I know you're a veteran of the flame-war (goodness knows you've gotten > a lot of practice in the past two years) but don't immediately try to > shoot me down with accusations of triviality. Back off. signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ANNOUNCE: Nanny 2.29.1 released
Nice! That's surely something needed. Will this somehow make its way into GNOME as a Pessulus replacement, in due time? What are the plans for making the two applications talk one each other, if ever? Matteo Il giorno gio, 24/12/2009 alle 16.18 +0100, Contacto ha scritto: > what is it? > === > Nanny is an easy way to control what your kids are doing in > the computer. You can limit how much time a day each one of them is > browsing the web, chatting or doing email. You can also decide at which > times of the day the can do this things. > > Nanny filters what web pages are seen by each user, so you can > block all undesirable webs and have your kids enjoy the internet > with ease of mind, no more worries! ___ 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
Il giorno gio, 19/01/2012 alle 16.32 -0500, Colin Walters ha scritto: > However, modules will need to be patched to find the correct valac and > vapigen with the -0.14 suffix. For example, folks just does: > > AC_PATH_PROG([VAPIGEN], [vapigen], []) > if test "x$VAPIGEN" = "x"; then > AC_MSG_ERROR([Vala must be built with --enable-vapigen]) > fi > > We could manually pass VALAC=valac-0.14 VAPIGEN=vapigen-0.14 to > configure, but it's probably better to fix this inside the configure > scripts. > Wouldn't it be a good idea for Vala to install a valac.m4 file in /usr/share/aclocal, containing a pertaining macro? Something like AC_PROG_VALA([== 0.15]), so that everyone can use the same macro, avoiding this kind of duplication and differences among modulesets. This can set variables for both valac and vapigen in one go. Cheers, -- Matteo Settenvini FSF Associated Member Email : mat...@member.fsf.org -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS/E d--(-) s+: a- C+++ UL+++ P+ L>$ E++>+++ W+++ N+ o? w--- O M- V- PS++ PE- Y+>++ PGP+++ t++ 5 X- R+ !tv b+++ DI++ D++ G++ e++ h+ r++ y+ --END GEEK CODE BLOCK-- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Goal Proposal: Port to GMenu
Il giorno lun, 07/05/2012 alle 16.15 +1000, Andrew Cowie ha scritto: > I ask this because Epiphany¹ has no menu, but does and a funky button > over on the right that, upon investigation, turns out to be a menu has > useful things like "add bookmark" ... but not preferences! Which, > eventually and quite by accident, I discovered was in the global GMenu > thing up top. Oh. On this note, I have to say it was quite difficult for me at first to figure out there was a menu hidden under the activity title you see on the Shell bar. Back in 3.0 and 3.2 days, it contained only a "Exit" item for all apps I can remember of, and even then, I only discovered it by mistake - I did not think it was clickable, only a visual current-application title. Add to this that most applications present already with a menu bar inside their window, and it really is hard for a user to figure out there is a menu *outside* the window. Maybe it's only me (I always found the Mac OS X approach counter-intuitive too), but having to search menus in two places isn't ideal. Also, if I have two apps side-by-side, I need to change the current focus to click on the GMenu. So, some consistency is needed, I'd say. Or else instead than one place for menus, we end up with two places for menus. And with apps like Evolution, that have a lot of menu items, I am not entirely sure it is feasible to move them under the upper GMenu. By the way, and slightly unrelated: F10 allows me to pop up the first menu, and ALT+"letter" to open a specific one by accelerator. What is the corresponding shortcut for the upper menu? Finally, a design question: why GMenu (and some related classes, come to think of that) are in GIO and not in Gtk+? This is just to understand the rationale behind the choice. When I looked at the documentation, I expected at first to find it in Gtk+. Thanks! -- Matteo Settenvini FSF Associated Member Email : mat...@member.fsf.org -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS/E d--(-) s+: a- C+++ UL+++ P+ L>$ E++>+++ W+++ N+ o? w--- O M- V- PS++ PE- Y+>++ PGP+++ t++ 5 X- R+ !tv b+++ DI++ D++ G++ e++ h+ r++ y+ --END GEEK CODE BLOCK-- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Possible to fix glaring Gjs API issues before GNOME 4?
Il giorno gio, 28/02/2013 alle 01.51 -0800, Simon Feltman ha scritto:
> On Thu, Feb 28, 2013 at 12:04 AM, Martin Pitt
> wrote:
> Nikita Churaev [2013-02-27 23:26 +0400]:
> > 3. Gtk.TextBuffer.set_text(text, length) --- length argument
> is useless,
> > since JavaScript uses UTF-16 and length expects length of
> UTF-8 string.
>
>
> I'm afraid we have to live with little oddities like this. I
> think
> it's better to stay compatible with the C API and its
> documentation,
> and all currently existing JavaScript program which use the
> API than
> breaking API and continuously chasing after weird cases like
> that.
>
>
> I don't think skipping the length arg in this case could work even if
> API breakage was acceptable. I assume a skip implies a value of zero
> is used and in this case that would not work. A better alternative
> would be default value support. This way the oddity can be avoided in
> client code without breaking API and in general would be a very nice
> feature. However, new code using this would need to specify it only
> works with advanced versions of GLib or the libraries providing
> defaults.
>
>
> https://bugzilla.gnome.org/show_bug.cgi?id=558620
>
>
> -Simon
>
Uhm, I thought JavaScript ignored extra arguments to a function:
$ gjs
gjs> function f (a) { };
gjs> f (1, 2, 3);
(no error)
Then, why not changing the JS API to provide only
"Gtk.TextBuffer.set_text (text);"?
It would break no existing code.
In turn, *.set_text(text) calls the non-exported, "private",
two-argument version, by computing the right UTF-8 length.
Something like:
let (f = Gtk.TextBuffer.set_text)
{
Gtk.TextBuffer.set_text = function (text)
{
var l = ... // get the right "text" length for UTF-8
return f (text, l);
}
}
That way, you also solve a lot of programming errors in locales other
than C, providing an easier interface.
You just need a couple of overrides to do so. Similar functions would be
trivial to manage.
Cheers,
--
Matteo Settenvini
FSF Associated Member
Email : mat...@member.fsf.org
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCS/E d--(-) s+: a- C+++ UL+++
P+ L>$ E++>+++ W+++ N+ o?
w--- O M- V- PS++ PE- Y+>++
PGP+++ t++ 5 X- R+ !tv b+++
DI++ D++ G++ e++ h+ r++ y+
--END GEEK CODE BLOCK--
signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Tools for Sharing Tasks
Jasper already summed it up nicely, bringing some concrete examples. What I would do, is to use simply a webapp, such as RedMine, deployed somewhere all project members can access. Since it provides a REST API, you can then send and get JSON requests through normal HTTP operations. You can keep a queue for offline use, and provide an interface to solve conflicts, if you worry that people cannot be always connected to the Internet. Sometimes the easiest solution is just the best one: I would just say "use the web interface". Not an expert so I might be wrong, but: if you really would like an offline Gtk+ application to sync with a server, without having to care too much about how data is synced, I believe you could talk to evolution-data-server through libecal. EDS will then manage things under the hood, possibly using WebDAV/CalDAV, Exchange, etc. I think you could start by getting an ESource from libedataserver, and use it accordingly. Cheers, Matteo Il giorno mar, 02/04/2013 alle 19.25 +0300, אנטולי קרסנר ha scritto: > Hi, > > This is a somewhat technical question, I hope this is the right place > for it. > > I'm writing a GTK application which manages tasks and projects. At the > moment it's more or less like GTG (Getting Things Gnome). I want to add > task sharing, and I've been thinking what's the right way to do that. > > I checked what other people do. GTG uses the XMPP pubsub extension > (publish & subscribe), which seems to do the job, but it's not exactly > designed for sharing tasks. It does work, but it requires you to setup > the server. > > I've been thinking and I found another idea: use a git repository. > > This way people can easily watch how projects develop - this way we > easily achieve the publish&subscribe capability - and sharing tasks > between team members is as easy as working with git, which is already > very common. Task sync is simple sync of files in the repo. And it > doesn't require any extra work: starting a new local git repo is > extremely easy by typing "git init", and starting a repo on a server is > done by creating a user on gitorious and creating a repo there. > > Some sites don't offer private repos for free, but encryption will be > used anyway to allow maximal privacy anyway, so it shouldn't be a > problem. (GitLab offers 10 private repos for no charge if you really > need 100% privacy) > > I'd like to hear more ideas and make a wise decision, which tool is the > best one for task sharing. Git sounds very good to me, but I'm not an > expert (just a software engineering student, actually). > > > - Anatoly > signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Two 3.10 feature ideas
Dear all, unfortunately, I don't know if I will have the manpower in the next six months to contribute actively to GNOME, so I'm just dropping two ideas for features here. I believe they would benefit a good number of users. * Finally have evolution display notifications for new messages while the main UI is not open. There was a proposal in this direction several cycles ago, but I believe it was postponed indefinitely. Has evolution-data-server all the needed pieces? This is not conceptually much different than notifications for new chat messages. Sure, it can be achieved by some another different small program which needs to be configured separately, but it would be nice to have this well integrated with the rest of the GNOME experience. * Add social network notifications. Some of them could be read-only notifications (e.g. for Google+, which does not provide a write API), others could afford to offer an interface similar to the one used for chat (e.g. for Facebook and Twitter) where you can respond. Gwibber attempted to do some of these things, but a solution integrated with g-o-a (which already has the authentication pieces in place) + gnome-shell seem to make much sense. Anyway, thanks for your strenuous work! Cheers, -- Matteo Settenvini FSF Associated Member Email : mat...@member.fsf.org -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS/E d--(-) s+: a- C+++ UL+++ P+ L>$ E++>+++ W+++ N+ o? w--- O M- V- PS++ PE- Y+>++ PGP+++ t++ 5 X- R+ !tv b+++ DI++ D++ G++ e++ h+ r++ y+ --END GEEK CODE BLOCK-- signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
[Fwd: Re: Two 3.10 feature ideas]
With the new notifications panel, if you find notifications from a certain source annoying you can disable them. Also, in the online accounts panel you don't have to add what you don't want to. If these notifications distract you, just don't add them in the first place. We already have Facebook and Google as sources in GOA, as well as Flickr and Windows Live. While I am myself fighting for freedom on our platforms, and I fully agree Diaspora would be a nice addition, I don't see what keeps us to integrate our desktop to other websites for those users that would like to use them anyway. Choosing to fire up a browser and go visit that website (authenticating inside Epiphany/Firefox), or choosing to manually add an online account (authenticating with g-o-a) only changes the interaction medium, but it's up to the user to decide what to do. I am just proposing to have a generic framework to handle messages from social networks for those users who care to keep notifications enabled / manually configure them in GOA. StatusNet (and Identi.ca) is another free-software example of something that could benefit from this approach. As you see, there are free-software alternatives to proprietary ones, and they shouldn't be penalized. The framework would be source-agnostic. In fact, I believe that having Identi.ca supported by GOA would help boost its popularity, making it a more prominent alternative against, for instance, Twitter. That said, other desktop environments such as Mac OS X Mountain Lion, and Windows 8, both have integrated support for these things. I am not saying "let's do like they do", just pointing out that there might be a use case for users migrating from other platforms to GNOME. Cheers, Matteo --- Messaggio inoltrato --- Da: אנטולי קרסנר A: daniel.mustie...@gmail.com CC: mat...@member.fsf.org, GNOME Desktop Development List Oggetto: Re: Two 3.10 feature ideas Data: Fri, 12 Apr 2013 00:30:42 +0300 The first idea sounds good, but I don't think the second one is worth anyone's effort. Just a personal opinion, but as a Facebook user in the past, I've seen how loads of notifications keep you addicted and distracted and don't let you do the useful things you planned to do. There may be some use to such notifications, but basically - you would just be helping Facebook, Twitter and Google+ get more people addicted. And all three of them are proprietary and have known storied about how they use people's private data... So in my opinion, working on these notifications is one of the most not-important things we can possibly work on. I prefer to fix random bugs than help Facebook track people and control their lives. I know Google sponsors Gnome, but it doesn't change the fact I fight for software freedom, and I don't want to use Facebook or Twitter or Google mail/docs service. I do use this GMail mailbox, but I know it's bad and I'm looking for replacements. There's Diaspora, for example. I know many people here actually work for RedHat, but all those of you who care about software freedom purely: Do you really want Facebook/Google/Twitter to take over the desktop? If they do, Gnome will become just another desktop environment, not any better than Windows. Freedom and privacy are killer features, ladies and gentlemen. At least in my humble opinion. Let's not give up on them so easily. But do go ahead with the Evolution idea :) - Anatoly Krasner On ה', 2013-04-11 at 22:09 +0200, Daniel Mustieles García wrote: > For the first idea, maybe something like this could be useful: > > http://code.google.com/p/gnome-gmail-notifier/ > > I've been using it in both GNOME 2 and GNOME 3 ant id works properly > with notifications, so it would be a good starter point. > > Cheers! > > 2013/4/11 Matteo Settenvini > Dear all, > > unfortunately, I don't know if I will have the manpower in the > next six > months to contribute actively to GNOME, so I'm just dropping > two ideas > for features here. I believe they would benefit a good number > of users. > > * Finally have evolution display notifications for new > messages while > the main UI is not open. There was a proposal in this > direction several > cycles ago, but I believe it was postponed indefinitely. Has > evolution-data-server all the needed pieces? This is not > conceptually > much different than notifications for new chat messages. Sure, > it can be > achieved by some another different small program which needs > to be > configured separately, but it would be nice to have this well > integrated > with the rest of the GNOME experience. &g
Re: Pre-computing scrollbar size to accomodate all the items in music collection
On Mon, Jun 24, 2013 at 05:23:25PM +0530, Shivani Poddar wrote: > Hi! > I am working on the bug ->https://bugzilla.gnome.org/show_bug.cgi?id=699832 > I want to pre-compute the size of the scrollbar to indicate the total items > in the collection (which are more than the ones we load in the application > at one instance ) > Need some ideas as to how do I tackle it. Hello Shivani, I believe a way would be to ask for the size_request of a widget to be laid out in the underlying grid, and for the total containing grid's width. At least for the grid, this should be done while drawing, so that it is realised and you know the real size (which is needed also on resizing). You can then easily determine how many widgets per row you would end up in total, and thus how many total rows you have. Multiply by a child's height, and you have the total viewport height. I believe you can then force the height of the viewport view's window to your computed size, or just add invisible Gtk.Spinners of the same size of the other childrens (which is nice for async loads in the future, see below). This works under the (fair?) assumption that all children are of the same size. For Music, it should hold. You would have to be a bit careful to do the math by using the right padding, asking the grid about the internal spacing of children and the likes. In the long run, you might want to create a separate widget for this, as it would be useful also for other applications. libgd could be a good staging ground to commit it into. It should probably be written in Vala/JavaScript at this stage. That way, you could load results asynchronously by emitting widget signals. Providers of items can then just subscribe to some "do-load (range_start, range_end)" signal and be happy: when the scrollbar enters a range not yet loaded of items, observers are notified to provide them. Cheers, Matteo > > Thankyou, > Shivani Poddar ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Passive resistance [was: Re: Announcing GNOME's official GitHub mirror]
Il giorno gio, 15/08/2013 alle 12.07 +0200, Alexandre Franke ha scritto: > On Thu, Aug 15, 2013 at 11:49 AM, Alberto Ruiz wrote: > > I really don't care much about my code being mirrored anywhere. At > least gitorious would be ethically acceptable, so it wouldn't bother > me, but I won't invest time in this. I see the value of this as a > backup though, so if others want to work on this I say that's a good > thing. > > Anyway this is really not what was the most important point to me in > my previous email and you didn't answer the question I really cared > about, so I'm asking again: is there a way for maintainers to opt out > of the github mirroring? > Hello, I share the concerns already expressed that this move might be seen as an implicit support of a proprietary service (one for which the source code of the server-side website infrastructure is not available) by the GNOME project, part of the free software movement. One of the great things about GNOME has usually been being not only "open source" -- good on technical grounds --, but also great in fighting for users' freedoms. Mirroring on github instead of gitorious is a signal in the wrong direction, as it helps in attracting more users to github (therefore directly helping a proprietary platform in terms of popularity), annoys some maintainers and contributors as can be seen in this discussion, and allows github to advertise the mirror of such a big project as GNOME in their press releases (it *will* happen, I'm fairly sure, as PR is important). Else, why were they eager to help with the mirroring, spending time and resources on it, if there was little or no return in investment? And that's fine on their part: they're just doing their job. The problem is on this side. Since PR is the important point for them, and the mirroring afaik was done without the explicit consent of maintainers, or a democratic voting process taking place on a relevant mailing list such as d-d-l, I suggest a passive-resistance stance (note that I am not a maintainer myself). github uses a file called "README.md" to display the main project information. A section against github can be put at the top of them by a module maintainer, explaining why it should not be used as it is proprietary, and suggesting users to move away from it. The module maintainer herself could then create a mirror on e.g. gitorious, and put the link in the same README.md file, inviting users to use that and to close their github account if they want to respect users' freedoms. Since this gives bad publicity to github, and encourages users to leave their service in favor of a competing one, I believe the github team will sooner or later get fed up and remove the modules themselves. Or even if they don't, we still get the effect of discouraging users in using their infrastructure, which is the point. This requires only actions from each interested module maintainer, it doesn't need approval or work by the sysadmin team (as they didn't ask for the module maintainers' approval). If there's interest, we could draft a paragraph or two, so that a bit of uniformity in communicating our ideals takes the form of a wider protest. Regards, -- Matteo Settenvini FSF Associated Member Email : mat...@member.fsf.org -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS/E d--(-) s+: a- C+++ UL+++ P+ L>$ E++>+++ W+++ N+ o? w--- O M- V- PS++ PE- Y+>++ PGP+++ t++ 5 X- R+ !tv b+++ DI++ D++ G++ e++ h+ r++ y+ --END GEEK CODE BLOCK-- -- Matteo Settenvini FSF Associated Member Email : mat...@member.fsf.org -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS/E d--(-) s+: a- C+++ UL+++ P+ L>$ E++>+++ W+++ N+ o? w--- O M- V- PS++ PE- Y+>++ PGP+++ t++ 5 X- R+ !tv b+++ DI++ D++ G++ e++ h+ r++ y+ --END GEEK CODE BLOCK-- signature.asc Description: This is a digitally signed message part ___ 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]
Il giorno ven, 16/08/2013 alle 12.22 +0300, fr33domlover ha scritto: > This is a great idea, but only if enough maintainers cooperate with it. > Otherwise, the "Gnome officially using GitHub" message is stronger than > a few small modules having your README.md file, while all other modules > have READMEs of the common kind. > > Judging by replies here, I'm afraid there's no enough interest. All the > names I recognized here support the GitHub mirrors, while the voices > against them are people whose name I never saw, or are maintainers of > less popular modules. > > Without major modules participating, I'm not sure it will work. We can > wait longer and see comments from more people. Right now I think a > per-module switch to disable mirroring sounds like better protest (maybe > unless I see maintainers of major modules disagree with the GitHub > mirroring). I understand your position, but if you are really concerned about freedom and are a module maintainer, you are willing to take action even if it is only for your module. After all, each developer is free to do what they see fit with the code they maintain. Nobody can stop a mirror being taken (there's nothing in the license of the software preventing it), and forcing a developer to forfeit a github mirror is going against freedom 2 (http://www.gnu.org/philosophy/free-sw.html). However, taking action on the code you have the copyright of, and protesting about what is not in line with your ideals, sounds a fine compromise. It doesn't block other people doing what they want -- be it running Firefox with Adobe Flash, using DRM'd software, having a github account, or installing Mac OS X/Windows --, but makes them aware of what freedoms they give up in the process. Then, it's up to the final user to make their decision; which is definitively what free software is really about. Cheers, -- Matteo Settenvini FSF Associated Member Email : mat...@member.fsf.org -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS/E d--(-) s+: a- C+++ UL+++ P+ L>$ E++>+++ W+++ N+ o? w--- O M- V- PS++ PE- Y+>++ PGP+++ t++ 5 X- R+ !tv b+++ DI++ D++ G++ e++ h+ r++ y+ --END GEEK CODE BLOCK-- signature.asc Description: This is a digitally signed message part ___ 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]
Il giorno ven, 16/08/2013 alle 10.17 -0400, Jasper St. Pierre ha
scritto:
> As I've said before, GNOME uses proprietary services for collaboration
> and outreach.
>
> We have active presences on the proprietary communication services
> Google+, Facebook, and Twitter. We displayed a large Twitter wall at
> GUADEC showing tweets tagged with the hashtag #guadec.
>
> GitHub is just another one of these services we use for community
> outreach, and I fail to see how it's any different than any of the
> others.
>
You are of course right. The matter should be probably discussed, as
those services have the same problems of github, and free alternatives
do exist.
> There's possibly a discussion to have about whether GNOME should use
> proprietary services for outreach, but GitHub isn't really anything
> new here. In my opinion, if you feel strongly about the use of
> proprietary services for outreach, perhaps GNOME isn't the greatest
> fit for you.
Excuse me, but I happen to like GNOME, to like how it's designed, build,
and the developer community it has. I love GNOME devs, and I think they
are some of the best guys in FLOSS. I like the attention to details, the
project license, and the respect of the users freedom that comes with
it. Last time I checked, it is still part of the GNU Project! It was one
of the main reasons I got away from KDE years ago, in favor of GNOME.
Why shouldn't I try to change the (poor) direction things are taking to
preserve a piece of software, freedom and above all community I have an
emotional attachment to? Or is it already the situation so desperate
that GNOME is not "the greatest fit" for me, and I should look elsewhere
("don't bother, go away")?
In the end, I might just do so, if everyone turns out to be uninterested
in the fundamental values of free software. For once, I might start by
canceling my monthly donations. And with me, others — fewer than you
would gain by aggressive marketing, sure, but still. I always advocate
for GNOME. I'd hate starting to advocate against it.
You can indeed become fairly popular ignoring fundamental users'
freedoms (look at Ubuntu). But what are you willing to give up just to
be popular? Many a showgirl would give answers on that topic that would
make a seasoned sailor blush... I hope GNOME is not selling out.
In the end, you just find yourself more and more tied to those
proprietary services you tried to escape in the first place by creating
a system such as GNOME. If you have a Facebook account, for instance,
think how willing you are to close it down, even now after seeing the
Snowden datagate emerging.
Besides, while github is not free, gitorious and others are. Diaspora is
still experimental and not on-par with things such as Google+ or
Facebook, but gitorious is a good alternative. So even on a technical
level, this choice reeks. Also because by working with e.g. the
gitorious team, one could have also found more bugs / asked for some
features which would then be fixed in an open-source product, benefiting
the community at large. So there's an indirect contribution too to the
well-being of everyone.
I'm not implying a slippery-slope argument here: I don't think GNOME
will become closed source in the near future, or anything like that. But
there have been constant signs of going adrift in latest years, and not
always users have been heard out / notified. A community needs to be
built, or it will dissolve. While I appreciate the development effort
went into GNOME in the 3.x cycle, I also believe that it has not gotten
better at all in community-building, hemorrhaging users to other DEs.
And it won't be Facebook, Google+ or github to solve the fundamental
problem: poor communication and unilateral decisions (especially from
the designers, sorry guys) instead of building consensus or at least
discussing why their ideas are sounder than the others'.
Anyway, interoperability from GNOME's side with proprietary systems is
good. It allows users, if informed correctly, even to migrate and
transition to open systems. But relying on proprietary systems still
sends the wrong message, imho. It's like we cannot come up with
something working ourselves.
Else, give GMail accounts to all @gnome.org people, and just put an
alias into place. And move MLs to google groups. Maintaining a mail
server is quite frankly a pain in the ass, spam filters, CVEs and all,
so why losing sysadmining time onto it, when GMail works technically
better than anything else going around? (that was a rhetorical question,
of course).
Cheers,
--
Matteo Settenvini
FSF Associated Member
Email : mat...@member.fsf.org
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCS/E d--(-) s+: a- C+++ UL+++
P+ L>$ E++>+++ W+++ N+ o?
w--- O M- V- PS++ PE- Y+>++
PGP+++ t++ 5 X- R+ !tv b+++
DI++ D++ G++ e++ h+ r++ y+
-
Re: Announcing GNOME's official GitHub mirror
Il giorno ven, 16/08/2013 alle 12.55 -0400, Richard Stallman ha scritto: > [ 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. > > Until today, I was thinking of GitHub as a service, pure and simple, > and believed that the programs used to access it are git (which is > free) and a web browser (which can be free). Thus, no nonfree > software required. > To Richard: I would like a clarification in this respect. If I use a non-free web service (for instance, a web service for which the source code to install it and run it locally is not available), even through a web API, is it really different from linking to a proprietary library from my GPL program? I am talking on *ethical*, not technical grounds. Calling a function inside a proprietary library is just passing in some arguments and awaiting a return value, after the code inside the library does something. Calling a web service is just the same, except I have usually to serialize my values to be passed as parameters, and the code runs remotely instead than locally. But I still don't control what's happening in the middle. Do you think it is ethically acceptable for a free-software program to use a proprietary web service API? Thanks, -- Matteo Settenvini FSF Associated Member Email : mat...@member.fsf.org -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS/E d--(-) s+: a- C+++ UL+++ P+ L>$ E++>+++ W+++ N+ o? w--- O M- V- PS++ PE- Y+>++ PGP+++ t++ 5 X- R+ !tv b+++ DI++ D++ G++ e++ h+ r++ y+ --END GEEK CODE BLOCK-- signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
gitorious limitations [was: Re: Passive resistance [was: Re: Announcing GNOME's official GitHub mirror]]
Il giorno ven, 16/08/2013 alle 11.27 -0400, Jasper St. Pierre ha scritto: > On Fri, Aug 16, 2013 at 10:50 AM, Matteo Settenvini > wrote: > Besides, while github is not free, gitorious and others are. > Diaspora is > still experimental and not on-par with things such as Google+ > or > Facebook, but gitorious is a good alternative. So even on a > technical > level, this choice reeks. Also because by working with e.g. > the > gitorious team, one could have also found more bugs / asked > for some > features which would then be fixed in an open-source product, > benefiting > the community at large. So there's an indirect contribution > too to the > well-being of everyone. > > > gitorious is not an good alternative. > > > It's slow, buggy, and does not support the common operations that > GitHub does. I can't view images from the gitorious viewer. I can't > view raw files. > > I've never managed to get in contact with the gitorious team. As far > as I can tell, they've fallen off the face of the earth. > > > Ask Richard Hughsie why he moved colord from gitorious to GitHub. > There's good reasons we're trying to get away from it. I know I am going slightly (but only slightly) off-topic, but would you and Richard (whom I Cc'ed) care to give me a short list of items you find annoying in gitorious? I should have some free time starting November, and some good Rails experience, so maybe I can submit some patches a few months from now. I am involved in some other projects too, so I don't know about my priorities, but I'll keep this under my radar. Thanks, -- Matteo Settenvini FSF Associated Member Email : mat...@member.fsf.org -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS/E d--(-) s+: a- C+++ UL+++ P+ L++++>$ E++>+++ W+++ N+ o? w--- O M- V- PS++ PE- Y+>++ PGP+++ t++ 5 X- R+ !tv b+++ DI++ D++ G++ e++ h+ r++ y+ --END GEEK CODE BLOCK-- -- Matteo Settenvini FSF Associated Member Email : mat...@member.fsf.org -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS/E d--(-) s+: a- C+++ UL+++ P+ L>$ E++>+++ W+++ N+ o? w--- O M- V- PS++ PE- Y+>++ PGP+++ t++ 5 X- R+ !tv b+++ DI++ D++ G++ e++ h+ r++ y+ --END GEEK CODE BLOCK-- signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Announcing GNOME's official GitHub mirror
Il giorno ven, 16/08/2013 alle 19.10 -0400, Richard Stallman ha scritto: > [ 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. > > To Richard: I would like a clarification in this respect. If I use a > non-free web service (for instance, a web service for which the source > code to install it and run it locally is not available), > > I think it is a mistake to use the term "non-free web service" with > that definition, because that question is not what makes a web > service ethical or unethical. > > If the server does a job you could do in your own computer, even in > principle, then it's SaaSS and it's bad. Otherwise, the issues > that make the service ethical or unethical are other issues. > > is it really different from linking to a proprietary library > from my GPL program? > > Using a service run by someone else is like asking him to do a job for > you. If he uses nonfree software to do the job, that's his mistake > and his loss. We are sorry for him, but we don't need to boycott him > because of that. > > Thus, for instance, we don't need to refuse to take the subway because > the subway system has computers with Windows, or refuse to make a > phone call because the phone exchange uses runs proprietary software, > or refuse to make a connection across the Internet because it might > pass through some routers that run nonfree software, or refuse to > order t-shirts because the shirt company might use Windows to make > shirts. In these cases, we're not using that software -- the > companies are using it. If it's proprietary, the companies are the > ones whose freedom is taken away. > > When you use someone else's service, you never have control over any > software he uses to do your job. If it's free software, he has > control. If it's proprietary, he doesn't have control (which is an > injustice towards him). But either way, you don't have control over it. > That's the nature of a service -- but is it bad? > > In some cases, it is bad. There are certain jobs that you shouldn't > entrust to someone else's service, because you should have control > over them. Namely, these are the jobs you could do in your own > computer. Using a service for those jobs is SaaSS. > > If a given service is equivalent to calling a library in your > computer, then it is SaaSS, so it is bad. Even if the server runs > only released free software, SaaSS is still bad. In order to have > control of this computing, you need to do it by calling a free library > in your computer. That's the way it should be done. > > But I don't think that applies to most of what GitHub or Savannah does. > Those are communication activities. You couldn't do them by calling > a library in your own computer. So it is ok to use services for that > (but pay attention to the privacy issues). However, it would be nice > if we could do it in a peer-to-peer fashion. > Thank you for your kind and thorough answer. It was very helpful to me to understand the issue better. Wishing you a wonderful weekend, -- Matteo Settenvini FSF Associated Member Email : mat...@member.fsf.org -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS/E d--(-) s+: a- C+++ UL+++ P+ L>$ E++>+++ W+++ N+ o? w--- O M- V- PS++ PE- Y+>++ PGP+++ t++ 5 X- R+ !tv b+++ DI++ D++ G++ e++ h+ r++ y+ --END GEEK CODE BLOCK-- -- Matteo Settenvini FSF Associated Member Email : mat...@member.fsf.org -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS/E d--(-) s+: a- C+++ UL+++ P+ L>$ E++>+++ W+++ N+ o? w--- O M- V- PS++ PE- Y+>++ PGP+++ t++ 5 X- R+ !tv b+++ DI++ D++ G++ e++ h+ r++ y+ --END GEEK CODE BLOCK-- signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Announcing GNOME's official GitHub mirror
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 13/09/2013 16:48, Karen Sandler ha scritto: > On Thu, August 15, 2013 5:03 am, Alberto Ruiz wrote: > >> I've been working with the GitHub guys and Andrea Veri on setting >> up a > mirror for all GNOME repos in GitHub. > > As you can see in the minutes published today, the board discussed > the thread about GitHub and the various concerns on this issue. > > Firstly, the board would like to thank Alberto and Andrea for their > hard work to increase participation in GNOME by making this mirror > happen. We all think it's important to improve our outreach to > newcomers and welcome work like this to make contributions easier > to a greater group of people. Alberto, please also pass on our > thanks to the folks at GitHub who took the time and helped make > this happen! > > However, the majority of the board requested that the word > "official" be removed as we think it could be confusing as to > whether GNOME is recommending GitHub. Alberto has already complied > with this request. (You can read more detail about this in the > minutes.) > > The board would like to explore making this effort with other > services (like Gitorious). If there is someone who would like to > put in the work to create the appropriate hooks in the repository, > please contact us. > > karen > Great news! Thanks for being open about this, and taking care of discussing the issue. Cheers, - -- Matteo Settenvini FSF Associated Member Email : mat...@member.fsf.org - -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS/E d--(-) s+: a- C+++ UL+++ P+ L>$ E++>+++ W+++ N+ o? w--- O M- V- PS++ PE- Y+>++ PGP+++ t++ 5 X- R+ !tv b+++ DI++ D++ G++ e++ h+ r++ y+ - --END GEEK CODE BLOCK-- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBAgAGBQJSM488AAoJEIV2zBrZfULfgpkQAIoQDK5EN3T9PmNcx0NNl0ET 1gB7UqAe56mcKE0Fc46cUwEMBGVQ75jkk59yv1d00Se1nQHOJ0jd0yUX2aRutYm6 /Sdltb7Un0EQndq2evKAsMKXeJQOtS4GgyU3uIlr5h9myMBqXhBerhdzmv+ab+VU HfvjV+Z7VflFoW5huGZANtvYkN8AF/GHtKGtWC7J+OKfAelwPpxHZw7kWQP3S/ki tA9T3NSuzdytrp4XSrv09V7jyqMrqWMCFkezIXwmpaaihlXx1ceGJ1NXroNbsJ9A JGDVKMfB7UTDDm+gSi+UpIKeiJsOwDjzmZ73cmCAw+IMCUK1aQAMtY5GjN8uWr2b b7WloGFWAao8/Vxbswb5tLdIuZvNdrwF1EiLn48hY6cJ+8fLYtT4jd3InSnHND63 TLj7It957Z04nDUkaGntBOBoYEaKDwHzrqOP6G40Kz9bC0Z8Xpmo92E4YR6kGmqs h5TRd7yWWZTNl8gvGiiWFNBHFDZYgqK0xw128Fa46kx5Hq5hHkn9iMq31DDR0X2q oUZGZDAWhPg5dEvNiPm87KB6ge1zH+AEErMoHJLKifzKRdLNpIlKtAhiMsL/okNM MYVCdWTtlCs0wrlVFu/mZLkFdgYIXuYDRKT+z9OHKDJd8n3Rkg+2eBSSYxZKdstW NCrGT8YFFdk4JpH8Wi9G =jRCf -END PGP SIGNATURE- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Suggestions for an official GNOME hosted document collaboration suite?
Karen Sandler writes: > On 2014-02-14 16:39, Florian Müllner wrote: >> On Fri, Feb 14, 2014 at 10:27 PM, alex diavatis >> wrote: >> there is any legal issue that prevent gnome to introduce a per-user >> revenue >> model, or in other words commercial services over open source >> solutions? >> >> Being a non-profit organization[0], I would assume so (but then I am >> not a lawyer). > > We are a 501(c)(3) organization, but that doesn't mean we can't ever > charge for services. Basically it's more of a matter of whether the > income is taxed or not, and to make sure that this kind of activity > isn't a substantial part of what we do. I also IANAL, but I believe the real constraint is that any income from providing services to users (or other means) cannot be shared among people / shareholders, but must remain as reserve for the nonprofit board (paying for people doing real work on stuff is usually okay, but requires being a bit careful, lest creating a conflict of interests which might lead to an accusation of peculation). Also, the amount paid should be less than what a for-profit organization might charge for the same services, and the scope of such services related to your mission as an organization — then the income should be tax-exempt. These constraints can be of course be ameliorated by offering a service as part of a donation, pretty much like you might get a t-shirt as a Friend of GNOME, or 5 e-mail aliases as a FSF member. People then can donate any amount that covers the cost of the service, or more (of their own free will). However, I am more well versed in European law, so I might be off-the-spot with US law. Cheers, Matteo pgp8ZRw0ISuIh.pgp Description: PGP signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Displaying wallpapers in /usr/share/backgrounds/ in settings
On Fri, Mar 14, 2014 at 10:14:21PM +, Michael Ikey Doherty wrote: > Hi, > > As far as I know this isn't possible via dconf. There are a number of > sources available, via the Grilo backend. > > Main ones: > > ~/Pictures: > pictures_path = g_get_user_special_dir (G_USER_DIRECTORY_PICTURES); Hi, by the way, some applications do put images intended to be used as a background in a subdirectory of the Pictures/ XDG dir. I think at least Nautilus creates a "Wallpapers" subdirectory when you right-click on an image and select to set it as a background. Which I find a very good idea, since I like having backgrounds separated e.g. from my holiday photos, and I like keeping my Pictures/ folder a bit more organized than just a random kitchen sink for all images that can fit on my screen. Kudos to the Nautilus maintainers :-). However, this means that I don't get access to these images from "gnome-control-center background". Other programs are less well-behaved, and as soon as I press "set as wallpaper", they copy images in Pictures/, next to my photos. Very annoying, also because, if the image was already in Pictures/, it will *copy and rename* it. I think eog does this, but I did not check. But basically, even for GNOME apps, there is little to no standardization about how a wallpaper should be set. Some copy a file in Pictures/, some in Pictures/Wallpapers (my personal favorite), others do not copy a file at all, and just change a dconf key, ... and so on. Wouldn't be worth providing some kind of common API, or some sort of guideline in this respect? Cheers, Matteo PS. Personally, +1 for whoever proposes to standardise on Pictures/Wallpapers. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Pulseaudio
Hi, I'm new to this list, so sorry if I ask something already discussed. It has been a while since esound has received some attention - releases are almost stalled. Looking at the GNOME wiki, it seems that Pulseaudio is the stronger candidate between alternatives, and that it allows for quite a lot of nifty things. I'm running pulseaudio since four or five months now on two of my desktop systems, both x86 and PPC, and I must say that I'm really satisfied by it. It's quite stable and has very few compelling bugs for the normal user (e.g. when using it as an esound replacement on a machine with more than a logged in user it doesn't share the esd socket, or similar). It also seems to be actively developed, and is shipped by default with Fedora 8. Can it be eligible for inclusion in GNOME 2.22? Thanks for any answer, -- Matteo Settenvini FSF Associated Member Email : [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d--(-) s+:- a-- C++ UL+++ P?>++ L+++>$ E+>+++ W+++ N++ o? w--- O- M++ PS++ PE- Y+>++ PGP+++ t+ 5 X- R tv-- b+++ DI+ D++ G++ e h+ r-- y? --END GEEK CODE BLOCK-- -- Matteo Settenvini FSF Associated Member Email : [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d--(-) s+:- a-- C++ UL+++ P?>++ L+++>$ E+>+++ W+++ N++ o? w--- O- M++ PS++ PE- Y+>++ PGP+++ t+ 5 X- R tv-- b+++ DI+ D++ G++ e h+ r-- y? --END GEEK CODE BLOCK-- signature.asc Description: Questa è una parte del messaggio firmata digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
Il giorno lun, 08/10/2007 alle 17.49 -0400, Martin Meyer ha scritto: [...] > > Gstreamer seems like the right thing to do here, and I remember this > conversation coming up last year. I don't recall what the end decision > was, if any. I'm wondering this: what if someone were to re-implement > the esound API to simply pipe the sound into gstreamer? Is that > possible? Pulseaudio isn't a GStreamer contender. In fact, it exists a pulsesink component for gstreamer, very much like there exist a alsasink, an osssink, a esdsink... If I understand correctly, you'd like to have esound be a wrapper around some sort of GStreamer pipeline, that finishes into... into what? A sink, certain. Why not a Pulseaudio sink? And so, why not just eliminate the intermediary? Pulseaudio does want to do some things that pertain to a sound server, like have network transparency capabilities, controlling hardware, and doing low-level resampling and mixing. Since esound is almost dead, Pulseaudio is a viable alternative. Cheers, -- Matteo Settenvini FSF Associated Member Email : [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d--(-) s+:- a-- C++ UL+++ P?>++ L+++>$ E+>+++ W+++ N++ o? w--- O- M++ PS++ PE- Y+>++ PGP+++ t+ 5 X- R tv-- b+++ DI+ D++ G++ e h+ r-- y? ------END GEEK CODE BLOCK-- -- Matteo Settenvini FSF Associated Member Email : [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d--(-) s+:- a-- C++ UL+++ P?>++ L+++>$ E+>+++ W+++ N++ o? w--- O- M++ PS++ PE- Y+>++ PGP+++ t+ 5 X- R tv-- b+++ DI+ D++ G++ e h+ r-- y? --END GEEK CODE BLOCK-- signature.asc Description: Questa è una parte del messaggio firmata digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
Il giorno lun, 08/10/2007 alle 23.19 +0100, Gustavo J. A. M. Carneiro ha scritto: > Last time I tried PulseAudio (over a year ago) it hogged the sound > device and did not let any other ALSA client produce sound. > > Can someone confirm the bug is still there? Just (e.g.) play some music > with PulseAudio and then start an ALSA client, check that mixing is > being done. > > If the bug is still there then I would not recommend anyone using > PulseAudio. Unless you want to see for example your flash plugin sound > to stop working, like it didn't usually work in the old days when it > used OSS API. > > Pulseaudio can do much better than dmix in my opinion. The only thing you need is to tell alsa to use pulse as pcm.!default and ctl.!default, after having installed the relative ALSA plugin. The ALSA plugin is quite stable and works well for me. As for Macromedia Flash 9, it is well known it is a buggy proprietary software with quite a lot of problems. People jumped at it, anyway, and now Pulseaudio has an extra library you can install to have Flash working seamlessly. Much better than with ESD, imho. Regards, -- Matteo Settenvini FSF Associated Member Email : [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d--(-) s+:- a-- C++ UL+++ P?>++ L+++>$ E+>+++ W+++ N++ o? w--- O- M++ PS++ PE- Y+>++ PGP+++ t+ 5 X- R tv-- b+++ DI+ D++ G++ e h+ r-- y? --END GEEK CODE BLOCK-- -- Matteo Settenvini FSF Associated Member Email : [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d--(-) s+:- a-- C++ UL+++ P?>++ L+++>$ E+>+++ W+++ N++ o? w--- O- M++ PS++ PE- Y+>++ PGP+++ t+ 5 X- R tv-- b+++ DI+ D++ G++ e h+ r-- y? --END GEEK CODE BLOCK-- signature.asc Description: Questa è una parte del messaggio firmata digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
> Does it still beat the hell out of your sound card? With the version I > have installed it raises my CPU temp about 8C because it's causing > like 300 interrupts a second talking to the sound card. Not good for a > laptop. > Takes 0.7% CPU on average, raises to 2% when playing multiple sounds, on a IBM Thinkpad four-years-old 2.4Ghz P4 laptop. I don't know what version you use, or if it is an issue specific of your system, but I never noticed slowdowns due to pulseaudio. Moreover, a lot of videos lagging with esd now play fine. Cheers, -- Matteo Settenvini FSF Associated Member Email : [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d--(-) s+:- a-- C++ UL+++ P?>++ L+++>$ E+>+++ W+++ N++ o? w--- O- M++ PS++ PE- Y+>++ PGP+++ t+ 5 X- R tv-- b+++ DI+ D++ G++ e h+ r-- y? --END GEEK CODE BLOCK-- -- Matteo Settenvini FSF Associated Member Email : [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d--(-) s+:- a-- C++ UL+++ P?>++ L+++>$ E+>+++ W+++ N++ o? w--- O- M++ PS++ PE- Y+>++ PGP+++ t+ 5 X- R tv-- b+++ DI+ D++ G++ e h+ r-- y? --END GEEK CODE BLOCK-- signature.asc Description: Questa è una parte del messaggio firmata digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
On Tue, 2007-10-09 at 11:52, Gustavo J. A. M. Carneiro wrote: > I don't care only about proprietary applications. You think for example > that Second Life Linux client (which is open source) will use Pulse > Audio API directly? It will take years before that happens. I remember > perfectly well how much time it took for applications to switch from OSS > to ALSA, after Linux declared ALSA the official "blessed" Linux sound > API. > Pulseaudio does enable also to use applications still tied to OSS, btw. > > It's good that there's an ALSA plugin to redirect sounds to the Pulse > Audio daemon, although I must confess it doesn't sound entirely > satisfactory. Why be forced to use a userspace mixing program when > hardware mixing would work equally well (or better) in most situations? > Non-network audio should not need to be mixed by Pulse Audio on Linux, > IMHO. I'm not entirely sure, but I guess that software mixing is done only when needed, using hw mixing where available. I may be wrong though. Then PA could be fixed. > > Is there any good reason why Pulse Audio explicitly locks the audio > device, unlike any other normal ALSA client? And no, making every app > use Pulse Audio by force, just because you can, is not a good reason. It may be, but not just "because you can". Having a unified interface for GNOME would improve stability and uniformity. After all, why telling people to use DBus and porting old applications to a new system, when they could continue using ORBit? Why taking the pain to rework over old apps to use GVFS and not continuing linking to GnomeVFS? More, what if we want to port some GNOME app to a system that doesn't have ALSA? dmix also has not so good latency support, and no sample caching afaik. Also, it cannot control separately volume for different applications (try adjusting your volume for a Totem movie to the maximum and have Evolution ring the X11 bell or in a terminal and if you don't become deaf you'll understand why this makes sense, but it's not just that -- think about having foreground windows having higher volume and bg ones lower, enabling for spacial sound effects). Of course, switching to Pulseaudio is feasible just if it works 99% of times, which it quite does for me (until now, I had only problems with Wesnoth). Writing a plugin or adapting pulseaudio to chew away that last 1% of non-working apps isn't impossible, and we've time until 2.22 to fix it quite well. After all, I had *much more* trouble with esound than not with Pulseaudio, and esound is still shipped by default in a lot of distros. Then there is the point that Fedora and Ubuntu are pushing for PA. Pulseaudio allows quite a lot of things that dmix doesn't. See also http://0pointer.de/public/pulseaudio-presentation-lca2007.pdf. Anyway, if you think Pulseaudio is bad, then GNOME libraries shouldn't even try to link to libesd like they're doing as per now. Cheers, m. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
Il giorno mer, 10/10/2007 alle 14.00 +0100, Gustavo J. A. M. Carneiro ha scritto: > I tried and I'm still not convinced. Unless there are some special > kernel patches in fedora making a big difference, I still hate sound > routed through a userspace daemon. I would willingly tolerate it for > sound coming from network applications, but it's not a price I want to > pay for simple local applications when I don't care about PNP or network > sound. > > IMHO Pulse Audio developers are just being stubborn; I have not yet any > good reason why PA and direct ALSA access cannot get along. You tried and you found it doesn't work for you, and that's fine -- I'm happy to hear your opinion, _expecially_ because it is different than mine. I can say only that passing from ALSA to Pulseaudio *for me*: - decreased overall latency - meant I didn't have to configure it at all, except modifying my asound.conf a little, when I wanted full ALSA apps support. - now I can play two or more totem instances without gaps, and also have other desktop sounds playing in the meantime - has many other benefits, even from a developer point of view (it's easier to code with Pulseaudio APIs). - esd was perfectly replaced, which is the main point. Esound apps works for me out of the box. This is a big win, imho. As for the interrupts sent to the soundcard, a module has been already included in the upcoming 0.9.7 version that should fix that. AFAIK it's because Pulseaudio plays silence when nobody uses it, to avoid popping when a stream starts again, and due to something about the HAL module, too. The only thing I must criticize is you saying that PA devs are stubborn. It seems to me they're really trying to innovate a stagnating and non-homogeneous field, and they should at least be treated with some respect. "Stubborn" isn't the word I'd have chosen to describe them. Anyway, even if PA isn't *THE* answer, ALSA isn't, either, for the reasons already expressed in this thread. So, what do you purpose? I think that fixing PA is easier than starting it again all over. Else, do we need a Phonon-substitute for GNOME? > > I'm sorry for being the bad guy here, but someone has to say these > things... You're not the "bad guy". The point is: are you the *only* guy, even if very vocal? I'd like to hear some more opinions from other people that *don't* like Pulseaudio. C'mon, there ought to be some more on this list. Don't be shy. We need the opinion of everybody (I'm talking serious, no sarcasm meant). Thanks, -- Matteo Settenvini FSF Associated Member Email : [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d--(-) s+:- a-- C++ UL+++ P?>++ L+++>$ E+>+++ W+++ N++ o? w--- O- M++ PS++ PE- Y+>++ PGP+++ t+ 5 X- R tv-- b+++ DI+ D++ G++ e h+ r-- y? --END GEEK CODE BLOCK-- signature.asc Description: Questa è una parte del messaggio firmata digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: linuxMint's gnome-menu
Il giorno mer, 10/10/2007 alle 12.43 -0500, Benjamin Gramlich ha scritto: > > Do you mean the one pictured > > <http://linuxmint.com/pictures/screenshots/celena/mintmenu.png>? > > Yeah, that's the one. Sorry I wasn't more clear and didn't attach a link > to a picture. It's not a drop-in replacement for the current gnome-menu, > but it has some excellent features: > > 1) The search field > 2) You can mouse over Submenus to pull up the menuItems > 3) It's pretty > 4) The favourites menu > > It's written in python right now, and it's a little unresponsive at > times when other programs are running. I can't say I like the way this menu is structured a lot. I think that having to watch a wider area when looking for applications and other things introduces more complexity and confuses the user. Taking some more horizontal space in the panel as it is done now with the Application/Resource/System menu is very friendly and quick. > this is the coolest thing about the mintMenu: it takes up a static > amount of space, both horizontally and vertically. if the submenu that > you mouseover is taller than the window for the menu then the submenu > becomes a scrolling window. This way the users eyes can stay within a > confined area to search for what one needs. I think it's easier to > search for things horizontally than it is to search vertically, but > maybe that's me and not a fact. Also the idea of scrolling the menu area isn't very welcomed in my opinion. Windows 98 did that, and it was changed in XP (sorry in case I misunderstood what Benjamin said). It makes it harder to find applications for the user that has to scroll a window / to wait for a window to scroll. This menu reminds me a lot of WinXP start menu (okay, okay: I know it's a lot better, but is more crowded than necessary in my opinion). I always spent a lot of time looking for buttons in the start root menu in Windows -- for example locating the Resources item, or the Network connections one. I always wasted a couple of seconds to re-orient me. I remember it was one of the things I was *relieved* wasn't mimicked in GNOME/KDE when I finally switched to GNU/Linux. There is also a usability study that discuss the differences between Applications/KMenu/Start menu. See in particular the "GOMS analysis of a typical use case", "Flexibility and efficiency of use" and "Visual hierarchy is clear" paragraphs. http://obso1337.org/hci/papers/Study_of_Desktop_Start_Menu_System_Usability.pdf The study also says that a good menu would need a way to search for its content by keyboard. That could be something we could port (don't know the best way to fit it in the UI) from the Deskbar applet to the Applications menu. > > Also, since the gnome control center seems to be aiming to incorporate > all the Preferences and Administration capplets, we could eventually > remove these Submenus from the gnome-menu and have just the control > center available. [...] This could make sense since they're not so-frequently used as application menu items, and they tend to be quite a lot. I'd prefer seeing less items (e.g. Appearance groups three different old items) directly in the menu than a separate window for tons of applets, though. It enables for faster access to things, which is what we should care more about. > > Ciao, > benjamin > Just my 2c, -- Matteo Settenvini FSF Associated Member Email : [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d--(-) s+:- a-- C++ UL+++ P?>++ L+++>$ E+>+++ W+++ N++ o? w--- O- M++ PS++ PE- Y+>++ PGP+++ t+ 5 X- R tv-- b+++ DI+ D++ G++ e h+ r-- y? --END GEEK CODE BLOCK-- signature.asc Description: Questa è una parte del messaggio firmata digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: build systems
Il giorno ven, 09/11/2007 alle 15.51 +0100, Emmanuel Fleury ha scritto: > Richard Hughes wrote: > > On Fri, 2007-11-09 at 13:52 +0100, Daniel Svensson wrote: > >> waf runs in two steps, first configure, > >> then build. And I cannot stress enough how fast it is. Zooom! Also it > >> has a very nice looks ;) > > > > Yes, I evaluated waf a few months ago. It's a very nice internal design, > > and very pluggable. Unfortunatly it needs the same modules written as > > what we use with autotools, e.g. a module to install a schema file, do > > the translation stuff etc. > > > > It's written in python, and is really a nice project. If I was more l33t > > at python I would be pushing it much harder than I am for use inside > > GNOME. > > Did someone tried out Scons (http://www.scons.org/) ? I did try to use it for some projects of mine that I shared with about six-seven people each. Ugly as they are, autotools where easier to write and adapt than SCons, and everybody understood them after I spent half an hour explaining the principles. At the end, we reverted back to autotools, and it costed us less time in maintenance and configuration. Also, what didn't compile in exotic systems before, started working without doing anything else (MacOSX comes to mind). I may be biased, though, since I don't like Python much (I prefer Ruby). However, moving away from a well established and - above all - working infrastructure which is so widespread like the autoblah thing, requires compelling reasons. For me, the cruft of updating Makefiles and configures doesn't even remotely compares to maintaining SConstruct files or whatever else is the fashion of the week. Anyway, I also admit that I know autotools passably well. For example, I always use a unique Makefile.am for the whole module I'm building (recursive make is considered harmful!), which is something that not a lot of people do, and I must say I've seen a lot of "strange" practices in using autotools around, and that may explain why most people hate them so badly (simply disliking them is healthy, anyway). At least for me, SCons meant: * learning a new language (Python) to do simple things autotools did in a friendly - yet ugly - fashion; * having to write complex code to get simple things done in a portable way (at the time I tried it, I had to write by hand functions to check for packages using pkg-config and then start setting variables all around; more recently, compiling Mono binaries was a pain... see the now-dead Diva project SCons build scripts). Certainly not a win, if I can do the same thing in three lines within my configure.ac; * having to understand what an Evironment is and how is used, and reading through all that darn SCons man page (heck, can't we have GNU Info support? Never mind) searching for a function which is named in a way you'd never guess off-hand. I don't care having more granularity and control over what I do, if in 99% of cases autotools do what I want in a simplier way; * people say that SCons errors are more understandable. To me, quite a lot of times, scons failed silently and even more misteriously than autotools (without even printing it failed, I had to echo $?) However, I agree that autotools are just a huge kluge went widespread, and I'd like to see them replaced. But, I still didn't find a build system with low requirements, that's easy to learn, and with enough momentum to ensure me that I won't be forced to hop from one system to another several times across a few years of maintenance. I also don't like GNOME resisting to C++/Python/C#/Java in the platform, and opening to python for the build system. I don't want to have python installed just to compile glib, old fashioned as you may consider me. Yeah, I know that nowadays Python is installed for everyone, and all that things. I just don't like shooting to flies with a cannon. However, it's not that I hate python: I don't use deskbar applet because it's too slow and demanding, but I use exaile as my player and bazaar as my vcs, so go figure. If I was less lazy, I'd write a configuration system, and I'd make it in Ruby (if people want to use a damn cannon for killing mosquitos, at least let's make sure it's a _freakin'_ cannon) or auto-bootstrapping in C/C++ (yeah, I'm crazy). Software configuration should be something collateral to your work, not the most time-consuming thing in the process. My 2c. -- Matteo Settenvini FSF Associated Member Email : [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d--(-) s+:- a-- C++ UL+++ P?>++ L+++>$ E+>+++ W+++ N++ o? w--- O- M++ PS++ PE- Y+>++ PGP+++ t+ 5 X- R tv-- b+++ DI+ D++ G++ e h+ r-- y? --END GEEK CODE BLOCK-- signature.asc Description: Questa è una parte del messaggio firmata digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Lowering the barrier (was: Re: build systems)
Il giorno ven, 09/11/2007 alle 16.58 -0600, Jonathon Jongsma ha scritto: > On 11/9/07, Lucas Rocha <[EMAIL PROTECTED]> wrote: > > - Are the current drawbacks of using autotools in GNOME so so so > > annoying that it would be really worth the effort of migrating to > > something else? > > The only reason I could imagine migrating to something else at the > moment would be if it lowered the barrier to contribution so that we > got enough new contributors to offset the amount of work it required. > I'm doubtful that this would actually happen though, and we'd need to > be 100% sure that the system we were moving to was an improvement. > Changing subject since I think that the problem of lowering the barrier of contribution is crucial to the success of any free software project. I would like to discuss with you where we could act seriously in this direction. I've got some comments to make: * The GNOME love bugs weren't a bad idea, the only problem with some of them was they were boring and you didn't learn a lot from fixing them. For example, fixing include file order in headers isn't exactly what I'd consider exciting if I were to hack on some part of GNOME. I want action! Challenging ideas (but still, feasible ideas)! Furry little bugs squashed! Anyway, I'd like to see more bugs marked with the gnome-love keyword, and the most popular/new ones should deserve a window in the wiki, updated every week for major visibility. Make it a challenge, let the agonism arise between teenagers with too much testosterone! * The first time I tried to write something with the GNOME stack of libraries, I was baffled by ORBit. I simply wasn't able to get anything clear out from its documentation. I even didn't understand exactly what it was for. Three years, my first year as a CS student, and some beers later, I stumbled upon the DBUS specification. It was clear, concise, and explained very well to me what DBUS was for. After reading the *DBUS* document, I started understanding *ORBit* (which is different, obviously, but that gave me the insight). Following Murphy's law, now ORBit is being put in a corner :-). What I'm trying to say, is that we need some proper documentation explaining how the GNOME stack is built, and what components fulfill what need, bringing in concrete examples in the discussion. New hackers, especially if young and inexperienced like me, really need this sort of things to avoid going on a wrong path for months and then discovering that what you wrote was already there. That discourages anyone to continue. * Proper API documentation is still more important. I think that having 100% symbols documentation should be a priority. I know that no-one likes writing it, but it's necessary for all the people out there who don't have the willingness to read the code. By the way, the Mono library documentation is frankly quite incomplete. Also the Gtkmm one. I know of at least three separate CS programming courses in C++ at university that chose to use wxWidgets over Gtkmm just because of their better documentation (I prefer Gtkmm, but I don't have a problem to search also the Gtk+ docs as a fallback). * Code a lot of times isn't commented enough. Also static functions in a compilation unit should have at least a line explaining why they're there and what they're about. As you see, most of my problems go with the documentation, and not with the code, which usually I find well written - at least, the code *I* have read. A more strict policy about API documentation would be good news, and more abstract (vision, architectural) documentation 'd be wonderful news. Cheers, -- Matteo Settenvini FSF Associated Member Email : [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d--(-) s+:- a-- C++ UL+++ P?>++ L+++>$ E+>+++ W+++ N++ o? w--- O- M++ PS++ PE- Y+>++ PGP+++ t+ 5 X- R tv-- b+++ DI+ D++ G++ e h+ r-- y? --END GEEK CODE BLOCK-- signature.asc Description: Questa è una parte del messaggio firmata digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Unifying name for Plugins/Extensions/etc.
On mer, 2007-12-19 at 17:33 -0600, Shaun McCance wrote: > On Wed, 2007-12-19 at 17:37 -0500, Andrew Conkling wrote: > > [...] > Since plugin and extension are effectively synonomous, > what's to stop the Italian translators for using their > "extension" word for "plugin"? > > (I'm not trying to oppose the use of "extension", but > this particular argument just doesn't make much sense > to me.) Not much; we could do that (even if it wouldn't be a good translation, since plug-ins and extensions may indicate the same thing, but they're NOT synonymous in a grammatical sense, as Callum pointed out). However, the problem is having a consistent translation for plugins across the desktop. If you name that "extensions", translators will write it in italian as "estensioni". If you leave that plugins, Italian translators could write that as (at least): * plugin (untranslated) * estensioni * ampliamenti * moduli * aggiunte * spine (here I'm joking :-)) So it isn't guaranteed that everyone will use the same term as the other, since "plugins" does not have a clear correspondence in it_IT. Not counting the problem of going on the Internet for finding the solution to a problem, finding a tutorial in English wich refers to "plugins", and figuring out that is the same of "estensioni" in your Italian-translated UI. Whereas "extensions" is much more similar. Anyway, nothing does stop us. Here the problem is with consistency across the desktop. -- Matteo Settenvini FSF Associated Member Email : [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d--(-) s+:- a-- C++ UL+++ P?>++ L+++>$ E+>+++ W+++ N++ o? w--- O- M++ PS++ PE- Y+>++ PGP+++ t+ 5 X- R tv-- b+++ DI+ D++ G++ e h+ r-- y? --END GEEK CODE BLOCK-- signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Missing apps for GNOME
Hi, even if I don't have tons of time, I'd like to contribute more to the GNOME project. It's obviously always possible to fix bugs here and there, but I'd like to "specialize" on a particular project, at least for some time being. I know there are understaffed ones, and for sure I'd be interested in knowing which one needs people most -- keeping in mind that I'd require some mentorship if the project is well established and mature, in order to orient myself a little. I've got experience with C++ and Gtk+/Gtkmm, know C (but not the whole GNOME stack well), Ruby and can juggle with various languages a little. Willingness to learn is there, along with some algorithmic knowledge. However, I'd be also interested in hearing of priorities you think GNOME as a *desktop* should have. I mean, what app could be useful in the GNU/Linux free world, and we currently miss. As for my everyday use, I've come to think of some of them: 1. A good movie editor. A lot of people like to film their holidays and do a DVD of it, for example. In Windows, you've that crappy built-in software which is using WMV as a default format. Mac OS X, it comes with iMovie. The Diva Project showed to be promising, but it seems quite dead now. It was written in C#. 2. DVD authoring capabilities for an existing burner software. Someone is speaking of the upcoming K3b to have some features in, can someone confirm? I would like to pick some movies, create chapters and menus, and put the whole on a DVD. In Windows, see for example what Nero does. Btw, would it be better to work on GNOME Baker, Brasero, or do a stand-alone app for this? Are you aware of any free-software project already started on those points? Have you other suggestions? What project would you find more useful? Thanks, -- Matteo Settenvini FSF Associated Member Email : [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d--(-) s+:- a-- C++ UL+++ P?>++ L+++>$ E+>+++ W+++ N++ o? w--- O- M++ PS++ PE- Y+>++ PGP+++ t+ 5 X- R tv-- b+++ DI+ D++ G++ e h+ r-- y? --END GEEK CODE BLOCK-- -- Matteo Settenvini FSF Associated Member Email : [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d--(-) s+:- a-- C++ UL+++ P?>++ L+++>$ E+>+++ W+++ N++ o? w--- O- M++ PS++ PE- Y+>++ PGP+++ t+ 5 X- R tv-- b+++ DI+ D++ G++ e h+ r-- y? --END GEEK CODE BLOCK-- signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Just change release date (Was Re: State of gvfs in Gnome 2.21)
I use ftp:// on Nautilus daily to connect to six-to-seven different FTP servers on a GNOME 2.20 workstation at work. It's a little bit shaky, but usable. Now on GNOME 2.21.x at home, I use lftp on a terminal, 'cause I don't fear typing :-). However there are quite a lot of people out there (mainly web developers) who use FTP daily to upload content on the web. So, while not absolutely an issue (there's always some firefox addon available, or gftp or whatever), it would be *extremely* nice to have FTP support working for 2.22. Moreover, a regression is a regression, and should be prioritized. Btw, how much useful is having WebDAV and ObexFTP in before normal FTP support? Cheers, matteo Il giorno mar, 12/02/2008 alle 19.20 +0100, Kjartan Maraas ha scritto: > ti., 12.02.2008 kl. 16.32 +0100, skrev Andre Klapper: > > Am Dienstag, den 12.02.2008, 17:11 +0200 schrieb Peteris Krisjanis: > > > So I suggest - delay the release. Delay Ubuntu LTS. Delay also other > > > distro releases. Why? Because not release date matters. What matters > > > here is a _product_. It should be usable, it should be documented, > > > > it is *definitely* possible to fix the showstoppers in the next four > > weeks and release GNOME 2.22.0 in a sane state. so there's no need at > > all to discuss a delay currently. > > > How big an issue is ftp support in nautilus btw? I for one never have > never used it for much more than testing it. Does the bug count indicate > the size of our userbase for example? > > Cheers > Kjartan > signature.asc Description: Questa è una parte del messaggio firmata digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Any proposal for a small HCI-related university project?
Hi Luca, It's not strictly in GNOME, but improving song renaming in the PyGtk-based Exaile music player is badly needed and shouldn't be too hard to do (all the code is already there). Something with the potential of Amarok but the ease of use of other players. You should probably research how this is done in at least 7-8 different players, like Amarok, Quod Libet, BMPx, Rhythmbox, iTunes, etc... and invent something better, taking in account the needs of users that have to re-organize large libraries with ease. If you tackle it, remember subscribing the proper bug[1] and contacting Adam Olsen[2] to warn him you're working on it, so not to duplicate the effort. You may want also to join the dev team if you get results. Branching it and preparing a couple of patches should be fairly easy. If you make it, yours is the glory :-). Anyway, "official" GNOME projects have some priority, so please evaluate any other proposal before this ;-). Other ideas, anyone? Cheers, Matteo [1] https://bugs.edge.launchpad.net/exaile/+bug/136123 [2] https://edge.launchpad.net/~arolsen Il giorno sab, 01/03/2008 alle 17.10 +, Luca Vezzaro ha scritto: > > > Perhaps in two weeks, you could do a usability review of an application > > and create a number of patches to address your top 5 complaints? > > Yes, it might do since we've already been doing usability reviews as > an exercise. > Though it could be very hard to find an application which suits my needs... > > Luca Vezzaro signature.asc Description: Questa è una parte del messaggio firmata digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
PyGIO?
Hi everybody, does anyone have any news on some "PyGIO" bindings? They should complement the PyGtk and PyGObject stack, but googling for it didn't bring up any result. Regards, Matteo signature.asc Description: Questa è una parte del messaggio firmata digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moving from glib-gettext to gettext/autopoint?
Il giorno dom, 02/03/2008 alle 00.45 +0100, Sven Herzberg ha scritto: > Hi Loïc, > > PS: Can you tell me about the differences between gettextize and > autopoint (the manpages don't tell any) and why you want to move to > autopoint (this is also likely to increase feedback). autopoint seems to be the up-to-date version of gettextize, which makes things cleaner and is fully supported by new autotools (since last two-three years, I think). autoreconf -fis calls autopoint and not gettextize, also because gettextize may require user interaction while autopoint does not. Now it's time for bed... Matteo signature.asc Description: Questa è una parte del messaggio firmata digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.23 Schedule
Il giorno lun, 17/03/2008 alle 20.50 +0200, Felipe Contreras ha scritto: > Still the input from the user-base is not considered? > > How much a simple most-wanted-feature poll could hurt? > > Best regards. > Dunno what it counts, but an application for movie editing is high in my wish list, and one of the things most badly needed in the GNU/Linux world. Now that we've got Cheese, it's probably still more interesting. At work I'm forced to keep a virtual machine with Windows installed almost only for this, even that pitiful application which is "MovieMaker" is better than nothing. For basic tasks, the cmdline is enough for me (gst-launch or mencoder all the way), but not all the users can be expected to do that, right? It's a pity nobody seems to want to revive the Diva project, or to do something with the GStreamer framework. Anyway, that's just an idea if someone wants to catch it up. If I finally manage to get my degree and then get married, I'll probably find the force to do something about it. It may take a little, though. Mmmh, it's always like this. Just my 2c. matteo signature.asc Description: Questa è una parte del messaggio firmata digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Conduit for GNOME 2.24
These are wonderful news! I'd like to thank you for Conduit, I use it often and it's really useful. The only thing I miss is PocketPC integration (which unfortunately I've to use for work) with SyncCE. Thanks for your wonderful job! I'd like to have Conduit in GNOME. Matteo Il giorno lun, 31/03/2008 alle 23.35 +1300, John Stowers ha scritto: > Hey Guys, > > On behalf of the Conduit [1] development team, I would like to propose > Conduit for inclusion in GNOME 2.24 desktop suite. signature.asc Description: Questa è una parte del messaggio firmata digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Removing libgnomeprint* from the desktop set
Il giorno lun, 31/03/2008 alle 10.14 -0500, Mike Kestner ha scritto: > On Fri, 2008-03-28 at 19:58 -0600, Elijah Newren wrote: > > On Fri, Mar 28, 2008 at 10:12 AM, Vincent Untz <[EMAIL PROTECTED]> wrote: > > What exactly is the cost to GNOME of leaving a deprecated unmaintained > library in the release set? > > I believe the point is exactly that it's deprecated and unmaintained. Putting it outside of GNOME gives a strong signal to developers. However, this doesn't mean that library can't continue living its own life outside of GNOME: it can still be packaged for a distro, or shipped along with a third-party application. If the application in question is still actively developed, porting the old code to the new one shouldn't be too much a hassle; it's not as if you're removing any functionality to the platform, just saying "move on to the next version, it's better and more stable and people will work on it". Frankly, I read "shipped with GNOME" as "people still hack on it and bug fixing still occurs regularly". Cheers, Matteo signature.asc Description: Questa è una parte del messaggio firmata digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Why do GNOMEdevelopers almost exclusively use git mirrors and for example not bzr mirrors
Il giorno ven, 25/04/2008 alle 23.29 +0800, James Henstridge ha scritto: > On 22/04/2008, Jeff Waugh <[EMAIL PROTECTED]> wrote: > > > > Do bzr looms (recently released extension) satisfy the requirement explained > > in the earlier email? > > The Bazaar loom plugin lets you manage a stack of branches (similar to > quilt, stgit or mq), so isn't quite the same as the internal branches > in mercurial or git. You could probably remove code from the plugin > to get something similar though (the bits designed to support the > sequence-of-branches workflow). If I remember the original email, probably you're asking for this blueprint implemented: https://blueprints.edge.launchpad.net/bzr/+spec/nested-tree-support Although it is flagged as "Good progress", the URL pointed by the blueprint seems a little bit outdated to me. I'm putting Wouter in CC so maybe he can shed some light on the status of this blueprint, and give a tentative ETA information. Cheers, Matteo signature.asc Description: Questa è una parte del messaggio firmata digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Quotation marks: Using “” instead of ""
Well, that brings up the problem of quoting text in different languages. For example, as far as I know: * “English text” * „German text“ * «French text» * ...and so on If this change has to be made, someone should warn the translators to use consistently translated quote-marks all around. But I'd rather stick with the neutral symbol. Cheers, matteo Il giorno mar, 13/05/2008 alle 10.45 -0400, Pat Suwalski ha scritto: > My objection may seem silly, but since there is no way to type it on any > keyboard out there, that's a bit of a hindrance. Short of using the > character map and searching, one has to resolve to using "smart > substitution" editors like OpenOffice to get the characters. > > They also tend to fail horribly when pasting into a non-Unicode > terminal, which is still often the case over SSH. Probably not a huge > desktop consideration, though. Every distribution I know of uses Unicode > by default on the local terminal at this point. > > --Pat > > Christian Neumair wrote: > > Alex Jones proposed [1] to change the quotation marks in Nautilus > > strings from the ASCII representation "..." to the unicode variant > > “...”. > > > > I think the proposed quotation marks are aesthetically more pleasing, > > but I don't want to change this unless there is a GNOME-wide policy. > > > > I hereby propose to establish a GNOME policy of using “...” for > > quotations. Comments, objections? > > > > best regards, > > Christian Neumair > > > > [1] http://bugzilla.gnome.org/show_bug.cgi?id=532777 > > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list signature.asc Description: Questa è una parte del messaggio firmata digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libtool versioning (was Re: Getting a list of open files, the smart way?)
Il giorno gio, 15/05/2008 alle 21.35 +0200, Benoît Dejean ha scritto: > Bastien Nocera a écrit : > > On Thu, 2008-05-15 at 20:26 +0200, Benoît Dejean wrote: > > > >>> On 5/15/08, Benoît Dejean <[EMAIL PROTECTED]> wrote: > >>> I'm going to comment about your log message instead which says: > >>> > >> Updated libtool versioning: API addition does not change the ABI, so > >> only increased revision. gnome-2.22 is 8.1.1 so trunk is now 8.2.1. > >> > > > > That's not correct. You're supposed to increase both current, and age, > > so 8:1:1 would become 9:1:2. > > > even if they are no new symbols ? Shouldn't it be 8:1:1 -> 9:0:2, given it's the first revision of the new interface? From the libtool info page: Here are a set of rules to help you update your library version information: 1. Start with version information of `0:0:0' for each libtool library. 2. Update the version information only immediately before a public release of your software. More frequent updates are unnecessary, and only guarantee that the current interface number gets larger faster. 3. If the library source code has changed at all since the last update, then increment REVISION (`C:R:A' becomes `C:r+1:A'). 4. If any interfaces have been added, removed, or changed since the last update, increment CURRENT, and set REVISION to 0. 5. If any interfaces have been added since the last public release, then increment AGE. 6. If any interfaces have been removed since the last public release, then set AGE to 0. We should apply rule 4 and 5, I believe. Hi, Matteo signature.asc Description: Questa è una parte del messaggio firmata digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed module: project hamster
As far as functionality don't overlap, I don't see much of a problem in including more applications in GNOME. They just help it get promoted further. If I take a glance at my menu under a standard Ubuntu installation and I count the number of entries of a vanilla GNOME installation, they're not too much. Of course, too much cruft in your menu is undesiderable; but distros can choose what to take in and what to leave out. Also, the recent systray-is-wonderful-to-store-gazillions-of-icons trend is a little annoying to me, but hey, tastes are tastes. As long as I can disable it, I don't complain. The only thing which is really important to me is a strong commitment to mantain applications in GNOME in a long timeframe (read: years). There are some apps in gnome-media and gnome-utilities which aren't always up-to-date; gnome-dictionary, for example, has some serious stability issues (I need to file more bugs, I know...). Ah, and sometimes unification of apps could help; for example, I don't see why sound-juicer and rhythmbox can be merged (maybe because everyone is waiting for banshee's inclusion into GNOME? :-)). m. On lun, 2008-07-28 at 09:40 -0700, Luis Villa wrote: > On Mon, Jul 28, 2008 at 9:36 AM, Dave Neary <[EMAIL PROTECTED]> wrote: > >>> motivating reason for rejection, also... most of the apps we ship are > >>> mostly useless to most of our users. > >> > >> Do you think so ? It may be I almost perfectly matched GNOME apps > >> till today :) > > > > Looking in Utilities: I rarely use Calculator, Character map, or Disk > > Usage Analyser. You don't see me advocating they be dropped :) > > I'll go ahead and advocate dropping them, if it'll help ;) > > This is exactly the kind of app that makes me think we should have > certification for non-core applications- a way to say 'this is great > and useful and GNOME-y' (which it is) without saying 'this a part of > the core of GNOME which is tied to our release cycle and QA > standards.' > > Luis signature.asc Description: Questa è una parte del messaggio firmata digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSD should not housekeep the thumbnails
Afaik, other applications with similar problems do keep an ad-hoc cache in ~/.cache/. For example, banshee does keep a ~/.cache/album-art/ directory. Since f-spot has peculiar needs, maybe it'll make sense to move its thumbnail cache somewhere around there. Cheers, Matteo On mar, 2008-09-16 at 11:34 +0200, Stephane Delcroix wrote: > Hey guys, > > I'll try not to rant and stay constructive... > > Since 2.23.1, gnome-settings-daemon contains a housekeeping plugin that > clean the .thumbnails. Even if it looks fair, it really makes the F-spot > usage awful to the point it's basically unusable. > > The plugin does something like this: > - clean the thumbnails older than MAX_AGE (default to 60 days) > - clean the oldest thumbnails until the cache size is under MAX_SIZE > (default to 64MB) > > A large thumbnail takes ~70K, meaning that it'll keep less than 1000 > thumbs. By f-spot user standards, a collection with 1000 pictures is a > really small one, the (guessed) average sitting around 12k, and some > users are reporting some 50k images collection. > > F-Spot is built to not rely on the thumbnail presence and regenerate > them once needed, but regenerating thousands of thumbnails takes hours, > slow the main loop, generate a lot of disk I/O, ... > > As long as this plugin stays as is, we only have one choice available: > shout "fuck you standards" and move our thumbs out of .thumbnails. But > I think we can figure out an arrangement: > > 1) the MAX_SIZE should be set to 0 by default, so the cleaning is only > done one the thumbs age > 2) a) either change the comparison function to check for atime instead > of mtime >b) or, at every f-spot startup, touch all the thumbs we could need > > This means the housekeeping will housekeep way less (still eating user > disk space) and, for f-spot users a) images not accessed during the last > MAX_AGE will need to regenerate their thumbs or b) thumbs will only be > regenerated if you did not used f-spot in the last MAX_DAYS days. > > Please do not underestimate this issue, as it affects more than f-spot, > as f-spot will continuously regenerate its thumbs, the other thumbs (pdf > on your desktop) will need to be regenerated every time too. > > regards > > Stephane > > PS: looks like atime won't work for people caring about disk IO and > running with noatime > > f-spot bug: http://bugzilla.gnome.org/show_bug.cgi?id=547190 > g-s-d bug: http://bugzilla.gnome.org/show_bug.cgi?id=551944 > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Testing dark themes and marking deprecated widgets
On mar, 2008-09-30 at 20:48 +0200, Mathias Hasselmann wrote: > Am Dienstag, den 30.09.2008, 08:24 -0500 schrieb Shaun McCance: > > On Tue, 2008-09-30 at 14:02 +0300, Kalle Vahlman wrote: > > > 2008/9/30 Vincent Untz <[EMAIL PROTECTED]>: > > > More likely it will result in a bunch of "New Gnome theme > > is ugly" bug reports by people who, well, just don't know. > > Guess its a matter of communication. > > In worst case we have to find a way to prominently print "Beta Theme, > visit http://live.gnome.org/BetaTheme for information." over the > desktop? > There could always be space for a startup window in beta releases, with a checkbox like "Don't bug me again". It could contain release notes for betas. So people could know what to expect to be broken/changed, and a glimpse of the roadmap. Of course, these annoying startup windows should die before a stable release: we're not on Windows. They're just for users wanting to run on the bleeding edge, so to prevent a flood of "me-too" filed bugs. Just an idea, though. Feel free to drop it or make it better :-). Matteo > Ciao, > Mathias signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Add -D*_DISABLE_SINGLE_INCLUDES to GNOME_MAINTAINER_MODE_DEFINES
Hello, just want to know: does this policy also applies to Gtkmm includes? I mean, if I've got an application written in C++, should I only include "gtkmm.h"? Thanks, Matteo Il giorno gio, 30/10/2008 alle 11.25 -0400, A. Walton ha scritto: > On Thu, Oct 30, 2008 at 11:10 AM, Olav Vitters <[EMAIL PROTECTED]> wrote: > > On Thu, Oct 30, 2008 at 03:48:09PM +0200, Lucas Rocha wrote: > >> 10 days and no replies or objections. I think it makes sense to do it > >> for 2.26. Go! > > > > General FYI: We (r-t) also discussed this as a GNOME goal for 2.26 (fix > > single includes). There should be a wiki page for it. > > It's good to link it, I believe this is the one: > http://live.gnome.org/GnomeGoals/CleanupGTKIncludes > > -A. Walton signature.asc Description: Questa è una parte del messaggio firmata digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Add -D*_DISABLE_SINGLE_INCLUDES to GNOME_MAINTAINER_MODE_DEFINES
Can't you use:
namespace _gtk {
#include
}
?
It's always possible to add "using" declarations into gtkmm headers, if
source-level compat has to be retained. Just an idea, though. Don't know
if this is feasible.
Thanks!
Matteo
Il giorno mer, 19/11/2008 alle 14.48 +0100, Murray Cumming ha scritto:
> On Wed, 2008-11-19 at 14:07 +0100, Matteo Settenvini wrote:
> > Hello,
> >
> > just want to know: does this policy also applies to Gtkmm includes?
> > I mean, if I've got an application written in C++, should I only include
> > "gtkmm.h"?
>
> No, I have no plan to make that necessary with gtkmm. It would
> needlessly increase executable sizes with no benefit.
>
> I don't really believe it's necessary for C either, but that discussion
> is over. Unfortunately it means that we must include gtk.h instea of
> gtksomethingspecific.h in several gtkmm headers, poluting the global
> namespace.
>
>
signature.asc
Description: Questa è una parte del messaggio firmata digitalmente
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: FUD from PackageKit, Was: External dependencies, DeviceKit-power and GNOME Power Manager
Hi, Please, both, cool down. We don't need a flame war, and certainly not on DDL. Both seems to have their good POV; both seem to have a deteriorated vision of the other, probably due to past discussions. For example, saying that PackageKit can "serve only second-grade distributions", isn't nice to the developers. Josselin, probably you didn't realize that because you feel deeply frustrated and ignored, but to an external viewer you're looking quite aggressive. I think Richard felt attacked, jumped in the trench, and started shooting back. This won't bring anyone anywhere: we need the collaboration of a great distro like Debian as much as we need PackageKit. I see PackageKit as a very welcome idea and a needed layer in order to abstract what's most inhomogeneous across distros: package management. I'm quite excited by it. Maybe who wrote the apt backend could jump in the discussion and say what the difficulties of making it run seamlessly were/are. An idea, by the way: as of now, Ubuntu during an update pops-up sparingly a window asking what to do with a modified configuration file: if keeping the original version of the maintainer, the modified one, or what else. Can't we have an option at the beginning of the upgrade process like " When a system-wide configuration file has to be replaced: (o) Always choose the new version (recommended) ( ) Always leave the local version in place ( ) Ask from time to time " ...or maybe a preference option? Most users seeing that smb.conf or login.defs has to be adjusted really don't know what to do (I've seen quite a lot of them panicking at a distro upgrade): they never touched these files and don't know what they do. If this is Ubuntu specific only, just tell and I'll open a bug in launchpad. Thanks, matteo Il giorno mar, 25/11/2008 alle 19.58 +0100, Josselin Mouette ha scritto: > Le mardi 25 novembre 2008 à 18:26 +, Richard Hughes a écrit : > > Ubuntu are quite prepared to work _with_ the PackageKit developers > > rather than _tell_ us what legacy features we have to support. > > I don’t recall having asked anyone to implement anything for us. However > I do recall being explained that, if implemented, debconf support would > not make it into your code. > > These kinds of little sentences are precisely the hostility I was > talking about. You grew hate for the very idea of correctly supporting > Debian based on false ideas of what our requirements are, and ignored > any further attempts of explanations. signature.asc Description: Questa è una parte del messaggio firmata digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Sound effects
Il giorno ven, 12/12/2008 alle 02.00 +, Iain ha scritto: > Some thoughts on sounds. > > The sound naming spec defines 125 sounds. > That is 125 sounds for the user to learn the meaning of. > Because the sounds defined are incredibly arbitrary the sounds run the > risk of having their meaning overloaded. Having 105 keys on your keyboard doesn't mean you've to use all of them, and you can have more than one key to do the same thing. What I'm saying is that, having defined one sound which is a clicking sound like the iPod one, you can symlink other 20 sounds to it. The icon themes frequently do it. Why not sound? m. signature.asc Description: Questa è una parte del messaggio firmata digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Sound effects
Il giorno ven, 12/12/2008 alle 11.27 +, Iain * ha scritto: > > Arguably, these sounds are application specific. > The application should provide what sounds it needs. > > iain So, instead of ~120 sounds, we get thousands the user "has to learn the meaning of"? You want to use the sound spec? Fine, you're a well-behaving app. You're more on the skype side? Who's keeping you to do whatever it pleases you more, if not concerns about users' mental sanity? Of the two, please choose one. m. signature.asc Description: Questa è una parte del messaggio firmata digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Nautilus drop-down menu with view type
Hi, I'd like your opinion on a usability concern. Whereas I change the ordering of elements in nautilus quite a lot (for example, ordering files by creation date, or by name, or by type...), I almost never change the type of visualization (icons, list, etc...). I'd personally prefer to have the quick drop-down menu with the view type replaced by a drop-down menu with the sorting order in the main nautilus window, because I find it more useful and accessible there. However, my usage pattern may differ from that of the majority of users, so I'm asking you about what you think. Thanks, Matteo signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: quo vadis, docs
On lun, 2009-02-09 at 11:00 -0600, Shaun McCance wrote: > > We do get volunteers on a semi-regular basis, but we inevitably > lose them. It would be useful to identify why we lose them and > fix those problems. I'll readily admit that I'm partially at > fault for not taking enough time to train them. But there are > a lot of hoops you have to jump through to start working on our > documentation, and most people just don't care that much. My complaints: * DocBook is hard for beginners; I think there was a project called "FoisGras" or something near that that did try to make things better. People in 2009 expect to write docs into OpenOffice.org, not Emacs. And the XML markup, easy as it could be, confuses the hell out of my mother. @Luis and @Dan: she actually *DOES READ THE DOCS* because she learnt that F1 can help you. Moreover, I'm what you'd call a power user, and sometimes *I READ DOCUMENTATION TOO*, simply because some options are too cryptic to understand even in GNOME. The manual I read the most? NetworkManager. Technical terms are always hard; a glossary would help. And I don't want to learn how to use git in order to contribute to documentation, or whatever other automake/autoconf/xml2po/xgettext black magic some uber-geek thinks it's cool this week (I'm obviously exaggerating; after all, I'm a geek at the core too). Add to this that a lot of users which read the documentation aren't native language speakers (they don't even know English well), and so they read the docs translated in their language... The problem is, if you find a problem with the documentation, it doesn't even crosses in your mind to report a bug; you take that the application is working correctly, and someone will in due time fix that outdated documentation. It's not a bug with the app; it's a problem with the doc. It's a culture-related problem, I guess (hey, from tomorrow I promise to start reporting documentation bugs). However, I'm all beyond this culture. Bugs are for applications, not for documentation, in my mind. Documentation should be fixed just by a couple of clicks, not through an overly-complicated process. By the way, has *ANYONE* tried to click on the "Contribute" links into http://live.gnome.org/DocumentationProject ? No? Yup, broken links. I've not fixed these myself just so you can still try them; however, this is just a small example of something that make people who have searched across a dozen pages in live.gnome.org to contribute running off screaming. (By the way, has anyone ever counted the number of clicks to get to a certain goal inside the GNOME website? It's astounding the depth you can get. If someone has ever studied something of web-marketing, you know why I see this as horrific. We should "sell" our goals just like a traditional company would.) The actual process: * surf the web for half an hour in order to understand how to contribute * understand what package you want to contribute * learn to use a couple of VCSs. * use svn (now) or git (tomorrow) to download the sources * learn docbook * write the doc * check them just to be sure you don't have a parsing error * learn what is a patch, and how to make one * create a patch * submit a bug * attach a patch * hope it'll get in, freezes and all the rest scattered here and there. Should really be: * open documentation, see that it's wrong * click on the upper-right link "Fix it!" * the first time, insert your bugzilla username and password * edit the page in the english locale * you edit the page inside yelp * (automatic submittal to the bug system, or to a wiki) * message to the user "your bug id is ###. thanks for contributing! You've helped to make GNOME better: you've made a difference." Take a look at how Monodoc allows you to change documentation. Maybe the best thing we could do is to set up a wiki with some XSLT stylesheets. * you don't have a clear "start here" banner on your map in the GNOME frontpage. People like to do things which are advertised as cool, not as boring or complex. The "contributing" link is the *last* one in http://www.gnome.org/community/, whereas it should be a big colourful button on the top of the page. And http://live.gnome.org/DocumentationProject/Join talks about IRC, mailing lists, handbooks... my mother doesn't know what IRC is. Is it a small furry animal? > > > Plus, a prioritisation of documents for pre-release updates. > > The whole idea of Pulse was always to show what documentation > needs the most love, which I think is about the closest we can > come to a prioritization system. Or, we can try to build also a community. People like statistics; sometimes competition is a good way to have some work done. Look at wikipedia, for example. Individuals race on who has the most number of articles reviewed/written. And the overall quality is quite good. > > -- > Shaun Shaun is right, and I've always respected his work the most. It's hard; and it's also more hard than it should be due to how
Re: How to use gtk / C language to change the desktop background picture?
Hi, the easiest way, I believe, is to set the relative gconf key. You can see what is by launching "gconf-editor" and navigating to /desktop/background/picture_filename. To modify that from C code, have a look at the GConf manual. http://library.gnome.org/devel/gconf/stable/gconf-GConfClient.html This won't update ~/.gnome2/backgrounds.xml, though. Cheers, Matteo Il giorno dom, 15/03/2009 alle 18.55 -0700, lovelinux ha scritto: > Hi > I think known How to use gtk / C language to change the desktop background > picture(wallpaper)? > What are the required system function and library file? > thanks. signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
Il giorno mer, 01/04/2009 alle 19.34 +0200, Josselin Mouette ha scritto: > I understand the rationale for going “full 3D” for GNOME Shell, but the > overall result is that we will have to maintain the gnome-panel + > metacity solution separately, for ever. This will not be a big burden, > but the real issue behind this is there will be two entirely different > user experiences. I've got an old laptop (7-8 years), and it really cringes with compiz if I enable it. At work, we have a couple of machines with GNU/Linux + GNOME. They have integrated low-cost graphic cards, or are old machines. In fact, a common trend nowadays is to "recycle" old machines bought for 100-150€ moving them from Windows XP to GNOME. I see this happening quite frequently also in the developing countries, when I talk to people I know that live there. I wouldn't mind the default being 3D-oriented, if at least a "disable-most-effects" mode is available. Also for all those who have to use a software renderer. For now, my laptop lives very well with GNOME despite its age. I'd like it to stay so. Only trying KDE here is so slow it makes your eyes water... Cheers, Matteo signature.asc Description: Questa è una parte del messaggio firmata digitalmente ___ 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
Il giorno dom, 19/04/2009 alle 14.31 +0100, Emmanuele Bassi ha scritto: > 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". Mmmh, if I think about what applets I've been using in the last years, I'd say just three have something not provided by the standard context menu attached to systray icons. They are: the one of gnome-system-monitor, hamster-applet, and deskbar-applet. Also invest-chart presents the user with a sensible applet, afaik. I think these should be ported to the new infrastructure, and they make sense as applets. Matteo signature.asc Description: Questa è una parte del messaggio firmata digitalmente ___ 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
> 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? > * do applets have to be constantly visible Yes, that's the whole point of it, really: easily accessible shortcuts to more advanced functionality. I added the network, disk load and CPU load of gnome-system-monitor to my panel exactly because I want them *always* visible (especially if some app is hogging the CPU, so that I can know instantly). At the same time, the Tomboy and Hamster applets are much better shortcuts than a tray icon, also because I can move them wherever I want on my panel (not limited to the tray icon area). > * how can we make user aware the applets exist and make it convinient to > manage/raise them? If we're going towards an on-screen widgets approach, it may be sensible to have a "start here" simple widget that users see on first login. They can remove it, or replace it much like Tomboy has a "Start here" note. > > These are just a few. I have no answers for them. Maybe somebody has. There could be no answers without someone asking ;-). Just my 2c, Matteo signature.asc Description: Questa è una parte del messaggio firmata digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
R: git migration - svn:externals
Hi Owen, I'm not entirely sure (bazaar user here), however I think that git has the notion of submodules: http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html Matteo > Messaggio originale >Da: j...@jsschmid.de >Data: 23-apr-2009 8.06 AM >A: "Owen Taylor" >Cc: "desktop-devel-list" >Ogg: git migration - svn:externals > >Hi! > >svn:externals are not migrated at all. That breaks anjuta-extras module >(b.g.o #579867) and gtkmm (fixed by duplicating files now). > >Is there anything we can do to fix it? Duplicating files is a quite weak >and ugly solution. > >Regards, >Johannes ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Platform
Il giorno mar, 05/05/2009 alle 14.05 -0500, Shaun McCance ha scritto: > Hey folks, [...] > > The list is what came to mind as I was writing this email. > Please feel free to discuss libraries I forgot. > Thanks Shaun, you're wonderful as always. I also think it would be nice to mention gobject-introspection in a separate part, because using it we can easily provide bindings to other languages and many other nifty things. As for other things: is GNOME pushing tracker, beagle or just xesam (now that it's published)? Maybe I'm a bit confused about all this. Please help me understand. seed may be worth mentioning. Also libcanberra. Another question: what about inserting a section about gtk-doc and/or doxygen? Documenting source code is quite important. Thanks, Matteo signature.asc Description: Questa è una parte del messaggio firmata digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Platform
Il giorno mar, 05/05/2009 alle 14.41 -0500, Brian Cameron ha scritto: > Shaun: > > Shouldn't GStreamer be included for media support? It's in the list (second item of the "Recommended" section) :-) > > Also, what about gvfs, libdaemon, and libunique? gvfs could be introduced along with GIO; as for libunique, I gather that plans were there to put that functionality inside Gtk+. Any update on that? I don't know about libdaemon. > > Brian Matteo signature.asc Description: Questa è una parte del messaggio firmata digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
