GnomeClient replacement?
Hello, the GnomeClient API is for some apps the single Gnome dependency that has no GTK equivalent and that keeps said apps tied to the >25 or so platform libraries. Other libgnome(ui) uses are gnome_program_init() and gnome_help_display() which can be replaced by gtk_init variants and directly spawning gnome-open or yelp. Could there be a per application analysis of whether GnomeClient is really needed and whether it can be discarded or replaced by using the simple X API directly? I see it's on the Ridley TODO list but with no alternative proposed. thank you Jani ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Bring a conlusion please
> So, after 7 days of deliberations, what are the results? > Is Mono/GTK# going to be included as part of the desktop OR binding 2.16.x > platform, or not? A clear 'yes' or 'no' please. > > Is there a person or persons that can take this decision after having read > the public opinion on this matter? [snip] Yes. The release team does this. It has done this every 6 months or so since 2.0, I believe: http://live.gnome.org/ReleasePlanning/Tasks Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Time to heat up the new module discussion
Alvaro Lopez Ortega wrote: > Dan Winship wrote: > [snip] >> And if your argument is really "languages that come with their own >> frameworks are bad",and not just "I hate mono", then why didn't you >> argue against allowing python-based apps in the platform when that >> came up a year and a half ago? > > I missed it. :-/ Actually, what is puzzling me is that nobody else > did it. You cannot even imagine how many people think like this.. I > guess there are too many interests around these adoptions, I don't > know. In any case, IMHO using Python to develop basic desktops > applications is as wrong as using Mono or any other framework. > > And, don't take me wrong. I said *basic* desktop applications. > Projects like Alacarte are okay; those are applications that you may > use once a week/month. However, when we speak about an applet that > will be loaded each single time you boot for PC things change. We > ought to be extra careful with those. > I'm going to go ahead and pipe up here because I feel like I need to voice my opinion that Mono should _not_ be part of the core set of modules for the GNOME Desktop. This is for a number of concerns which have already been stated, but it boils down to 1) this is still too controversial of a topic to make a decision in a single six month release cycle (with only 3 or so months left) and 2) I think is a topic that should be left to ISVs to decide. That being said, I use tomboy/f-spot and I'm glad that a certain ISV packages Mono and applications based on it, but I don't see how adding it lends any coherence or consistency to the GNOME framework. -- Brent Smith <[EMAIL PROTECTED]> IRC: smitten / #docs ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Bring a conlusion please
> And regarding "what Gnome is and to whom it caters" discussion, after 14 > releases I think it's too late to start such a topic. It's never too late to reevaluate where you are, what you want to do, and how to do it. The computing environment that GNOME 1.0 fit into is different than the one 2.0 did, different from the one 2.14 did, and it will be different in 2.30 (maybe we'll hit 3.0 by then ;). Every so often, someone will propose *something* that won't fit into the current vision for "what is GNOME" and if it's compelling enough, that vision may have to be redefined. We've seen this debate come from mono-based applications for a while (vis-a-vis desktop environment vs. platform), and we're starting to see it with the software surrounding mobile platforms such as the N770 and OLPC. To say that we're going to keep GNOME focused on the same vision of a "desktop" that fueled 2.0 will only serve to limit possibilities and frustrate the developers who are working so hard on cool things. > Lastly, Gnome needs a new next-gen language. Please elect/find a product > manager that most Gnome devs and the Board agree that is good for the job > (could even be someone inside the Board too, or the Board itself), let him > read the lists, research and let him decide if the next-gen language of > Gnome is Python, C# or Java. Point of the matter is that fewer and fewer > graduates learn C++ and even fewer learn C. For Gnome to appeal to new > programmers, a new, fully supported by Gnome, environment must be found. > This is being stated over and over again for 3 years now, but no one does > anything about it because people can't agree. This is why a product manager > (or a Board that takes technical decisions) is much needed to give an end to > these disagreements after they have studied all opinions and pros and cons. One of the strengths of the GNOME platform is that you're not limited to any one language. Blessing a single language as "the next-gen language of GNOME" will cause nothing but flamewars and animosity between people who are really working towards the same thing. We have excellent environments for both python and CLI languages, and a lot of the other bindings (such as Java and ruby) are improving rapidly. Surely a platform with robust bindings into many languages is a better option than just catering to the university-taught-platform du jour. -David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Bring a conlusion please
Eugenia Loli-Queru wrote:
> So, after 7 days of deliberations, what are the results?
Technically we still have 6 more days to deliberate.
> Is Mono/GTK# going to be included as part of the desktop OR binding 2.16.x
> platform, or not? A clear 'yes' or 'no' please.
AFAIR, the only objections to including gtk# in the *binding* platform
have been fairly minor and technical ("it should be split into separate
packages" etc) and in theory easily addressed.
As for allowing gtk#-based apps into the desktop release, I think it's
safe to say that we have not reached a consensus, and so, barring a
sudden Shyamalanesque plot twist[1], the answer is "no" by default.
-- Dan
[1] GNOME is dead people!
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Bring a conlusion please
So, after 7 days of deliberations, what are the results? Is Mono/GTK# going to be included as part of the desktop OR binding 2.16.x platform, or not? A clear 'yes' or 'no' please. Is there a person or persons that can take this decision after having read the public opinion on this matter? If yes, what is their decision? If there isn't a product manager to take the ultimate deicision, why there isn't one? Gnome feels leaderless to me and to many others right now. This is something that must be fixed. Gnome would have been further ahead if there was a manager to take important decisions that the community would endlessly debate otherwise. And regarding "what Gnome is and to whom it caters" discussion, after 14 releases I think it's too late to start such a topic. If you truly need to find a new market (as some around here seem to think so), then use the GPL version of OpenCyc (version 1.0 was released just a few days ago), spend 2-3 years re-designing the gnomelibs to support Cyc's natural language capabilities, and conquer the world with your next-gen envrironment. No, creating a new kinda-like-social-networking-but-not-exactly project won't bring ultimate success neither it appeals to most people. You gotta innovate hard to acquire big markets, and if you don't feel like doing that, at least take more final decisions regarding Gnome instead of endlessly debating. Lastly, Gnome needs a new next-gen language. Please elect/find a product manager that most Gnome devs and the Board agree that is good for the job (could even be someone inside the Board too, or the Board itself), let him read the lists, research and let him decide if the next-gen language of Gnome is Python, C# or Java. Point of the matter is that fewer and fewer graduates learn C++ and even fewer learn C. For Gnome to appeal to new programmers, a new, fully supported by Gnome, environment must be found. This is being stated over and over again for 3 years now, but no one does anything about it because people can't agree. This is why a product manager (or a Board that takes technical decisions) is much needed to give an end to these disagreements after they have studied all opinions and pros and cons. Eugenia ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mummy, I made a platform in my pants! [Was: focus!]
Jeff Waugh wrote: > > That said, culturally we've taken a lot of emphasis and glory away from the > platform since pre-2.0, so it hasn't had the attention it really needs to > improve what we can deliver on top of it. I guess the point of my post is to > make sure we don't completely disempower/unglorify the platform in our drive > towards coherent user focus. > Much of the 2.0 push was all about platform - GTK+ 2.0 was based on analyzing Qt and Swing and Windows and ensuring widget-by-widget that the API was competitive, for a while Red Hat was sponsoring C++ bindings, I did freedesktop.org, huge debates about "component systems," etc. This is definitely what was going on in our minds at that time, within Red Hat at least. I think GTK+ continues pretty strongly and things like freedesktop, dbus, gstreamer, etc. are coming together. If we want to improve the platform though, why not do it using the same specific-benefits-for-specific-audience mindset. Only in this case the audience is programmers and designers. Then we can define "enough attention" on platform - when is the platform good enough? When is a change important/worthwhile/correct? I'd start by asking what qualitative/differences-in-kind would be made by new platform initiatives. For example, if the platform started including assumed, guaranteed linkage to online services, that really changes what apps I can write. Or if the platform, like Flash, has tools that nonprogrammers/visual-designers can use, then that really changes what apps can be written and who can write apps. Also we have to remember the platform isn't isolated from the end user experience. e.g. on this Mono thread I so rudely interrupted, it was all "small footprint" vs. "shiny new apps" - well, that's a tradeoff where you shaft either one audience who cares about one thing or another audience who cares about another. It can't be resolved well except by stepping up to the level of benefits to audience and setting that direction first, then making platform decisions compatible with it. Another example, an HTML/Flash type of platform really lets graphic design come into play, while a toolkit/GTK type of platform makes it actively painful to do original graphic design. People will have strong views on which is better, but either way you line up, the platform clearly sets the user experience on this. A final example, introducing extra platforms to the desktop in the form of Firefox and OO.org complicates things substantially - but also has big user experience wins (or losses, depending on audience) - how do you decide this? You need a clear set of priorities. > It's like the Apple comments about whether they've been successful or not. I > think anyone who's seriously looked at their platform will know that they > have massive silos of ammunition and opportunity in reserve - because they > can and will be able to deliver compelling results to users faster, as will > their developer ecosystem. Hmm. To me the key to success in most cases won't be developing in 6 months vs. 8, it will be whether a product is laser-focused on getting a benefit to its audience ASAP, and whether the product really introduces new benefits to an audience or not. In the end I definitely agree with you that we need to do both, but I'll eat my hat[1] if the open source world suddenly really converts to the design focus/thinking thing and starts ignoring platform-building. I mean seriously, this is the community that brings us hundreds of Linux distributions and enough programming languages to sink a small tanker. Havoc [1] note, I don't ever wear a hat, so this is kind of an empty offer ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: focus! (was Re: Focusing on innovation re: mono, python et al)
On Tue, 2006-07-18 at 10:46 -0400, Havoc Pennington wrote: > GNOME Maemo: > I don't know their "concept" or target audience, but I can > imagine something like - > Create a "newspaper replacement" device for coffee shops, > the kitchen table, riding the train to work. So the funny thing is that although that's who they are targeting their marketing towards at the moment, I rather suspect that they have their sights on a much different - and bigger - market: disconnected enterprise mobile computing. There is a burgeoning industry for mobile computing devices (gizmo for sales person to carry around, warehouse applications, medical devices, you name it) yet the usual problem with embedded devices is needing to develop such custom code for obscure processors, etc. What Nokia has done is different - it's a general purpose computing platform with a (more or less) commodity and powerful stack on top of it. I rather expect that what they're hoping is that people will flock to it as an easier place to write their apps [for] rather than having to muck about in the low level drudgery that usually accompanies having to do embedded work. AfC Toronto -- Andrew Frederick Cowie Managing Director Operational Dynamics Consulting http://www.operationaldynamics.com/ Management consultants specializing in strategy, organizational architecture, procedures to survive change, and performance hardening for the people and systems behind the mission critical enterprise. Available worldwide: Sydney+61 2 9977 6866 New York +1 646 472 5054 Toronto +1 416 848 6072 London+44 207 1019201 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mummy, I made a platform in my pants! [Was: focus!]
> That said, culturally we've taken a lot of emphasis and glory away from > the platform since pre-2.0, so it hasn't had the attention it really needs > to improve what we can deliver on top of it. I guess the point of my post > is to make sure we don't completely disempower/unglorify the platform in > our drive towards coherent user focus. Quick followup to this: Someone's going to say, "But you can't create a platform without understanding the user problems you're solving (where 'user' can mean end user or developer user)." This is true... However! ;-) Much like users don't ask for new technology to solve their problems because they don't understand the potential of the technology (which users would ask for a grid-based programmable calculating system before VisiCalc appeared?), application Developers often don't ask for new platform techology to solve their problems because they don't undertand the potential of the technology. - Jeff -- linux.conf.au 2007: Sydney, Australia http://lca2007.linux.org.au/ "'Cause remember, smug is beautiful." - Zachary Beane ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mummy, I made a platform in my pants! [Was: focus!]
> > We can, and should, do both. :-) > > I don't disagree, but I think the natural emphasis of a big horde of > programmers (including myself) is to think 95% of the time about how to > improve the platform to make their own lives nicer, and 5% of the time > about the actual point of the software for some audience, so when deciding > what to cheerlead I'd tend to avoid the "go platform!" point of view. ;-) > > Certainly GNOME tends to be badly skewed toward the platform side of > things. I prefer working on APIs to working on UIs myself, I have to > admit. That said, culturally we've taken a lot of emphasis and glory away from the platform since pre-2.0, so it hasn't had the attention it really needs to improve what we can deliver on top of it. I guess the point of my post is to make sure we don't completely disempower/unglorify the platform in our drive towards coherent user focus. It's like the Apple comments about whether they've been successful or not. I think anyone who's seriously looked at their platform will know that they have massive silos of ammunition and opportunity in reserve - because they can and will be able to deliver compelling results to users faster, as will their developer ecosystem. - Jeff -- linux.conf.au 2007: Sydney, Australia http://lca2007.linux.org.au/ Wars end, love lasts. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mummy, I made a platform in my pants! [Was: focus!]
Jeff Waugh wrote: > > A fucking amazing platform isn't an accident, and we need a fucking amazing > platform to bring more developers to GNOME - both internal developers and > external developers. One of our *crucial* audiences must be FLOSS hackers > and ISDs. If we don't satisfy them, we can't build our own momentum for > building this amazing software stack, and we can't build an ecosystem with > opportunities for everyone else. > I agree with you for volunteer developers; a simple, nice platform is pretty important. For commercial developers, in my experience they usually ignore whether the API is pretty or pleasant... developers will come because there are users. Platforms I've learned in the last 9 months: - HTML/JavaScript - Flash/ActionScript - Java/EJB3 - C++/COM/Win32 These are some of the most successful platforms around. They are mostly pretty bad in various ways; in many ways GNOME/Linux is better, in some ways it's worse. But the fact is that even though IE/HTML/JavaScript and Win32/C++/COM compete as two of the most irritating platforms I can imagine, commercial developers write for them anyway. That's because userbase trumps API aesthetics, and the fastest way to platform success is to have a lot of users. To me the GNOME platform is pretty good in terms of API offered. The largest "API" problems have to do with proprietary software; RPM and dpkg are not designed for third-party software, and the diversity of Linux distributions makes it even harder. The whole Linux ecosystem is set up assuming a single giant pool of built-from-source packages. Which has many advantages, but easiness for ISVs is not one of them. Still though I'd say number of users is a bigger issue than anything like this. > We can, and should, do both. :-) I don't disagree, but I think the natural emphasis of a big horde of programmers (including myself) is to think 95% of the time about how to improve the platform to make their own lives nicer, and 5% of the time about the actual point of the software for some audience, so when deciding what to cheerlead I'd tend to avoid the "go platform!" point of view. ;-) Certainly GNOME tends to be badly skewed toward the platform side of things. I prefer working on APIs to working on UIs myself, I have to admit. Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: focus! (was Re: Focusing on innovation re: mono, python et al)
Iain * wrote:
> Not sure if this is one of them rhetorical questions or if this was
> even what you meant but its late and I'm bored, split the way I
> understand best; generationally:
>
> - Younger teenagers who want to stay in touch with their circle of
> friends, share the latest funny video they've found and play some cool
> flash game.
>
> - Older teenagers who have to do coursework and school reports, look
> up information online, develop hobby abilities around the computer,
> express themselves.
>
> - Students who want to type essays, and keep in touch with friends
> back home and at other unis, letting them know what they've been up
> to.
>
> - People with a role in a club or society (say youth group, church
> activities, sports club, etc) who want to write newsletters, or send
> out flyers.
>
> - Small business/medium owners who need to do basic bookkeeping, stock
> checking and making silly signs that say "No, we have no bananas" and
> "I assure you we're open" when required.
>
> Now I'm getting silly, maybe other people have other ideas if this was
> indeed what you wanted people to do.
I did not mean it rhetorically, no - it's a serious exercise.
I did mean something more in addition to what you listed though - you
have here audiences and benefits, but the second part is how GNOME
provides those benefits vs. what they have now.
For example, if I'm a younger teenager, I likely already stay in touch
with my circle of friends on MySpace/Xanga/Facebook and AIM, share
videos on YouTube, and play Flash games in Internet Explorer.
So the question is what GNOME (the project and community, not the panel
and window manager) could offer that an audience _doesn't_ have. Also, I
was suggesting giving serious consideration to whether the desktop was
really an intrinsic part of the each individual benefit.
IOW, first think purely about the nail (or screw, or bracket). Then look
in our toolbox for the right tool. Thinking "how do we hit this thing
with a hammer?" or "what things can we hit with a hammer?" right off
just doesn't work. ("hammer" = "a desktop" if it isn't clear)
In the list of existing GNOME successes for example:
a) historical UNIX workstation users want something similar to UNIX
- this intrinsically involves an alternate desktop, though
Windows XP and OS X both do have some "UNIX friendly" features,
GNOME/Linux uniquely offer almost complete compatibility
- this is a benefit not available to people already, since
most of the historical proprietary workstations are discontinued
or not cost effective
b) tech fans want a set of apps (and desktop components) they can mess
with and customize, and they want just plain old _lots_ of apps
- this intrinsically involves the mostly open source OS and the
resulting zillions of free apps an "apt-get" or "yum" away,
and also the arcane config options and ability to tweak
than an open source platform offers
- this is a benefit that was uniquely introduced by the idea of an
open source OS, so Linux/GNOME are the original market leaders here
c) thin client / computer lab deployments who want something with good
manageability/security and low cost
- this intrinsically involves a complete OS + apps solution with all
of it working in a thin client or lab environment - it couldn't be
just add-ons to an existing OS very easily
- people _do_ have serious options with Citrix, Windows, Wyse, etc.
for this... so GNOME has been strongest when low cost is a factor,
but there are also some limitations to the competition that Linux
might be able to improve on
- the overlap of this audience with the "tech fans" audience probably
helps GNOME
d) server administrators packing in the terminals, using some web-based
admin tools, and goofing around online from time to time
- this most likely only weakly requires a complete OS + apps, and
indeed lots of sysadmins do run Windows. But Linux/UNIX admins might
be in categories a) or b) also in many cases, and the Windows
terminal emulators are pretty crappy. Still, the right app suite for
Windows might make a complete desktop pretty irrelevant here.
- the "what do they have already" answer is probably covered by
the a) and b) overlap above, i.e. "they were already historically
using Linux or UNIX" - but given that, it's in no way clear
why a Windows-using server admin would switch, since a) and b)
hinge on an admin that's already Linux-oriented
Anyhow... take a starting point like:
- People with a role in a club or society (say youth group, church
activities, sports club, etc) who want to write newsletters, or send
out flyers.
First you have to ask, how do they do newspapers and flyers now. And
then question 2 is, from their point of view, what's the offering
(staying open to making the offering an app, a web site, a desktop, or
anything else) that will rea
Who sets the agenda? [Was: focus!]
> Regarding the "focus" issue, perhaps the distribution needs to drive this, > not GNOME. I'm sorry, but despite the distributions being an absolutely critical part of the GNOME ecosystem (and we need to work with them very closely, etc), it is *NOT* in anyone's long term interests (GNOME, distributors, or users) to "sell out" our ability to set the GNOME agenda to the distributors. - Jeff -- linux.conf.au 2007: Sydney, Australia http://lca2007.linux.org.au/ What does an underage calf drink? Long Island Iced Teats. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Mummy, I made a platform in my pants! [Was: focus!]
> I tend to think explicit platform-building sucks (vs. accidentally making > a platform in the course of making something useful). Havoc, I love your desk-pounding focus, but sometimes I think you inspire people too far up their own arses. ;-) A fucking amazing platform isn't an accident, and we need a fucking amazing platform to bring more developers to GNOME - both internal developers and external developers. One of our *crucial* audiences must be FLOSS hackers and ISDs. If we don't satisfy them, we can't build our own momentum for building this amazing software stack, and we can't build an ecosystem with opportunities for everyone else. Examples: Vomit in whatever colour you want, but Microsoft have been able to satisfy Office power user audiences and create a pretty compelling platform for third party games developers (let alone everyone else, but this is a rad example). Apple have been able to satisfy the needs of photographers, while creating a really sweet development platform which has in turn created an ecosystem of smart, polished, cheap software that actually makes money for third party developers. Google satisfy the needs of grandmothers wanting directions to their grandchildren's colleges, but also created a compelling mapping API for third party mashup hackers / mapping companies. We can, and should, do both. :-) - Jeff -- linux.conf.au 2007: Sydney, Australia http://lca2007.linux.org.au/ GDK (acronym): GNU's Not Unix Image Manipulation Program Tool-Kit Drawing-Kit. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: focus! (was Re: Focusing on innovation re: mono, python et al)
On 7/17/06, Havoc Pennington <[EMAIL PROTECTED]> wrote: > Question for the list, what is the target audience and benefit to them > of the desktop release? > > Current: > - historical UNIX workstation users who want something similar but not > dead > - technology fans who want a set of apps they can mess with and > heavily customize > - thin client / computer lab deployments who want something with good > manageability / security and low cost (the low cost especially for > government/edu) > - server administrators who want to pack a lot of ssh sessions onto > the screen, use some web-based admin consoles, and occasionally waste > some time doing non-work stuff > - ... > > Future: Not sure if this is one of them rhetorical questions or if this was even what you meant but its late and I'm bored, split the way I understand best; generationally: - Younger teenagers who want to stay in touch with their circle of friends, share the latest funny video they've found and play some cool flash game. - Older teenagers who have to do coursework and school reports, look up information online, develop hobby abilities around the computer, express themselves. - Students who want to type essays, and keep in touch with friends back home and at other unis, letting them know what they've been up to. - People with a role in a club or society (say youth group, church activities, sports club, etc) who want to write newsletters, or send out flyers. - Small business/medium owners who need to do basic bookkeeping, stock checking and making silly signs that say "No, we have no bananas" and "I assure you we're open" when required. Now I'm getting silly, maybe other people have other ideas if this was indeed what you wanted people to do. iain ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Evolution-hackers] Memory consumption and virtual machines
On Tue, 2006-07-18 at 16:05 -0500, Federico Mena Quintero wrote: > On Tue, 2006-07-18 at 14:46 -0400, Jeffrey Stedfast wrote: > > I've been talking to Philip on IRC, and gave him these requirements for > his patch: > > 1. Don't change the external ABI of Camel, so that Evo needs no changes, > *OR* also submit a patch to update Evo for the changed API. Achieved > 2. Make sure the summary format on disk works with older Evos without > making *them* rewrite the summaries. This is for deployments which have > machines with old and new versions of GNOME, but NFS homedirs accessible > from any machine. Achieved my renaming all the summary filenames > 3. Keep the coding style, variable naming convention, indentation, etc. Done For you, attached and on a plate: o. The patch for evolution-data-server o. The patch for evolution-exchange Trying to get this upstream is, for me, saying thank you. Looking at the patch technically AND testing it (and if it doesn't perform, giving me numbers that compare it with the original implement- ation) is all I'm asking for. If Novell wants me to implement unit tests (or other tests) for this, I will ask for payment. -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be evolution_data_server__mmap_summary.diff.gz Description: GNU Zip compressed data evolution_exchange__mmap_summary.diff.gz Description: GNU Zip compressed data ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: focus! (was Re: Focusing on innovation re: mono, python et al)
On Tue, 2006-07-18 at 11:14 -0700, Rich Burridge wrote: > One of the things I like about the Mac OS X desktop (and Windows Xp desktop > for that matter), is that all applications provided by the vendor have a > consistent > look&feel. If I'm familiar with one application on that platform, then I > can apply > that knowledge as I'm learning a new one. This isn't true of all > applications > on the various GNOME desktops. Big tangent: the "GNOME Certification" plan will help in defining what is a "good GNOME application" and what isn't. That certification will include things like consistent look&feel [insert a lot of handwaving about how to quantify this...] Federico ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: focus! (was Re: Focusing on innovation re: mono, python et al)
> Regarding the "focus" issue, perhaps the distribution needs to drive > this, not GNOME. I'm thinking for example of ubuntu vs edubuntu > (education oriented variant of ubuntu). They're basically the same > distribution, with different default colors and different default set of > apps. So where does that leave GNOME and the GNOME project if really all we are is an API vendor for distributions to come along and do whatever they want with some apps that due to our coherent APIs all work lovely together. What is the need for "The GNOME Desktop"? (I'm still sorry I'm asking questions, I still don't have any [coherent] answers...) > _Maybe_ we could go one step further and have apps customize the > level of complexity of the UI (like very early nautilus had as > preference, like RB has a "compact" mode). As we saw with Nautilus, it sucked. And RB's compact mode wasn't to simplify the GUI, it was simply to take up less screenspace. iain ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Evolution-hackers] Memory consumption and virtual machines
On Tue, 2006-07-18 at 16:05 -0500, Federico Mena Quintero wrote: > On Tue, 2006-07-18 at 14:46 -0400, Jeffrey Stedfast wrote: > > I have to wonder if it's even worth ever merging the mmap hack into > > Evolution at all. If the plan is to finish Zucchi's disk-summary branch, > > which also solves the memory problems (afaik) as well as: > > > > 1. introducing an API for using cursors to get at message infos > > 2. better designed on-disk format that uses B-Trees > > Let's put that discussion on Pause until someone actually starts > resurrecting the disk-summary branch. > > If Philip's patch turns out to work well for daily use, it may be a good > stopgap measure. The disk-summary branch will need way more QA time > than the mmap() stuff, and a lot more performance tuning work as well :) > > > the problem with philip's mmap file format is that the strings that will > > be hit for sorting/viewing/etc are all spread out over a huge number of > > pages. I just see this being re-examined later to try and design the > > format to better optimise it by compacting all the strings into a strtab > > type thing. > > I've been talking to Philip on IRC, and gave him these requirements for > his patch: > > 1. Don't change the external ABI of Camel, so that Evo needs no changes, > *OR* also submit a patch to update Evo for the changed API. The external API nor ABI has changed by the patches. > 2. Make sure the summary format on disk works with older Evos without > making *them* rewrite the summaries. This is for deployments which have > machines with old and new versions of GNOME, but NFS homedirs accessible > from any machine. What about making an internal little tool that converts any summary file it detects to a summary.mmap file, and after that never touches the original summary file. This will allow the format of the mmaped summary file to change, and only an evolution with the mmap patches will only the first time have to perform things. We can also simply change the file-name and let the older evolutions continue using the "summary" file, and the mmaped evolutions the new file. The older evolutions will not accept any changes to the summary files (for example version changes). They will reload the summary file if it has defects it can't handle, however. > 3. Keep the coding style, variable naming convention, indentation, etc. Of course. > It may be possible to change the summary format by *just* adding a > nul-terminator to strings; that may work with older Evos if we are lucky > enough that they'll just ignore the nul byte at the end. This needs > testing. > > I'd say that (1) and (2) are hard requirements. (3) is the usual stuff. > > > I just don't get the feeling this is really all that well thought out > > and it scares me. > > > > I'd just hate to see a rush job come out of this > > Yeah, it needs good testing. Philip says he'll cook a patch so that I > can use it with my system's e-d-s RPM for daily use. Then I can test it > with my normal mailbox. It might take me a few days as in fact I was planning to give it a rest for a few days. I've been caring to much about it. I don't know, it might also be finished in a few hours. Oh, no .. it's to late now. -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Evolution-hackers] Memory consumption and virtual machines
On Tue, 2006-07-18 at 14:46 -0400, Jeffrey Stedfast wrote: > I have to wonder if it's even worth ever merging the mmap hack into > Evolution at all. If the plan is to finish Zucchi's disk-summary branch, > which also solves the memory problems (afaik) as well as: > > 1. introducing an API for using cursors to get at message infos > 2. better designed on-disk format that uses B-Trees Let's put that discussion on Pause until someone actually starts resurrecting the disk-summary branch. If Philip's patch turns out to work well for daily use, it may be a good stopgap measure. The disk-summary branch will need way more QA time than the mmap() stuff, and a lot more performance tuning work as well :) > the problem with philip's mmap file format is that the strings that will > be hit for sorting/viewing/etc are all spread out over a huge number of > pages. I just see this being re-examined later to try and design the > format to better optimise it by compacting all the strings into a strtab > type thing. I've been talking to Philip on IRC, and gave him these requirements for his patch: 1. Don't change the external ABI of Camel, so that Evo needs no changes, *OR* also submit a patch to update Evo for the changed API. 2. Make sure the summary format on disk works with older Evos without making *them* rewrite the summaries. This is for deployments which have machines with old and new versions of GNOME, but NFS homedirs accessible from any machine. 3. Keep the coding style, variable naming convention, indentation, etc. It may be possible to change the summary format by *just* adding a nul-terminator to strings; that may work with older Evos if we are lucky enough that they'll just ignore the nul byte at the end. This needs testing. I'd say that (1) and (2) are hard requirements. (3) is the usual stuff. > I just don't get the feeling this is really all that well thought out > and it scares me. > > I'd just hate to see a rush job come out of this Yeah, it needs good testing. Philip says he'll cook a patch so that I can use it with my system's e-d-s RPM for daily use. Then I can test it with my normal mailbox. Federico ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Evolution-hackers] Memory consumption and virtual machines
On Tue, 2006-07-18 at 14:46 -0400, Jeffrey Stedfast wrote: > I have to wonder if it's even worth ever merging the mmap hack into > Evolution at all. If the plan is to finish Zucchi's disk-summary branch, > which also solves the memory problems (afaik) as well as: > 1. introducing an API for using cursors to get at message infos > 2. better designed on-disk format that uses B-Trees When? I'm also very interested in this for tinymail. > the problem with philip's mmap file format is that the strings that will > be hit for sorting/viewing/etc are all spread out over a huge number of > pages. My own tests indicated that it's as-fast as the old implementation. Some test (like sorting) where even faster. I'm guessing mostly because qsort doesn't make large jumps afaik. I mostly fear NFS shared $HOME folders. > I just see this being re-examined later to try and design the > format to better optimise it by compacting all the strings into a strtab > type thing. That would be an excellent idea. > I also don't like how it has to reload the summary anytime new messages > arrive. This is exactly the same as the current implementation. The current implementation does exactly the same and isn't changed at all. Look at the patch. It doesn't change anything to reloading the summary. > I just don't get the feeling this is really all that well thought out > and it scares me. So lets test it then?! > I'd just hate to see a rush job come out of this > > Jeff > > > On Tue, 2006-07-18 at 13:26 -0500, Federico Mena Quintero wrote: > > On Tue, 2006-07-18 at 18:29 +0200, Philip Van Hoof wrote: > > > > > I'm waiting for the decision (yours) of making this optional using a > > > compilation flag or at run-time. > > > > Let's do this in the usual manner: > > > > 0. Polish the patch in the usual way: make sure it follows the > > indentation and naming conventions of the surrounding code, etc. > > > > 1. Branch evolution-data-server into HEAD (development, with Philip's > > patch), and the stable branch (without the patch). > > > > 2. Make the patch *mandatory* in HEAD, so that it gets a good amount of > > testing. > > > > 3. ??? > > > > 4. Profit!!! > > > > I'd suggest that (3) become "write a good stress-test suite for Camel, > > independent of Evolution". We need that anyway. > > > > Novell already has a bunch of LDTP stuff to test the Evo mailer from the > > user's viewpooint - run those tests on the patched version to see how > > well they work. [Varadhan, those tests are already part of our QA > > process, aren't they?] > > > > Federico > > > > ___ > > Evolution-hackers mailing list > > Evolution-hackers@gnome.org > > http://mail.gnome.org/mailman/listinfo/evolution-hackers -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Evolution-hackers] Memory consumption and virtual machines
On Tue, 2006-07-18 at 13:26 -0500, Federico Mena Quintero wrote: > On Tue, 2006-07-18 at 18:29 +0200, Philip Van Hoof wrote: I agree with 1,2,..3 and 4. I will make sure 1 will be finished soon. Probably this evening with a compile-time option (--enable-mmap) > > I'm waiting for the decision (yours) of making this optional using a > > compilation flag or at run-time. > > Let's do this in the usual manner: > > 0. Polish the patch in the usual way: make sure it follows the > indentation and naming conventions of the surrounding code, etc. > > 1. Branch evolution-data-server into HEAD (development, with Philip's > patch), and the stable branch (without the patch). > > 2. Make the patch *mandatory* in HEAD, so that it gets a good amount of > testing. > > 3. ??? > > 4. Profit!!! > > I'd suggest that (3) become "write a good stress-test suite for Camel, > independent of Evolution". We need that anyway. > > Novell already has a bunch of LDTP stuff to test the Evo mailer from the > user's viewpooint - run those tests on the patched version to see how > well they work. [Varadhan, those tests are already part of our QA > process, aren't they?] -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Memory consumption and virtual machines
On Tue, 2006-07-18 at 18:29 +0200, Philip Van Hoof wrote: > I'm waiting for the decision (yours) of making this optional using a > compilation flag or at run-time. Let's do this in the usual manner: 0. Polish the patch in the usual way: make sure it follows the indentation and naming conventions of the surrounding code, etc. 1. Branch evolution-data-server into HEAD (development, with Philip's patch), and the stable branch (without the patch). 2. Make the patch *mandatory* in HEAD, so that it gets a good amount of testing. 3. ??? 4. Profit!!! I'd suggest that (3) become "write a good stress-test suite for Camel, independent of Evolution". We need that anyway. Novell already has a bunch of LDTP stuff to test the Evo mailer from the user's viewpooint - run those tests on the patched version to see how well they work. [Varadhan, those tests are already part of our QA process, aren't they?] Federico ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: focus! (was Re: Focusing on innovation re: mono, python et al)
On Ter, 2006-07-18 at 13:08 -0400, Dan Winship wrote: [...] > But regardless, if we want to be cohesive, >we have to *integrate*, not keep a wall between the applications >and the rest of the system. IMHO, GNOME doesn't need to integrate apps onto itself. On the contrary, apps need to integrate with GNOME. For that to happen, GNOME needs: 1- Framework for desktop extensibility, in the line of some of the things we already have: ability to register new MIME types, install menu items, register new applets with the panel; some others are missing, like notifications (libnotify, hopefully some day part of gnome); also nautilus/epiphany/gedit extensions.. 2- A sound developer platform. glib/gtk+; hopefully gnome-vfs lower in the stack... GStreamer... 3- GNOME integration guidelines: the HIG is an excellent start, but not enough; I don't remember if there are others... And BTW, nautilus supports search folders, which can be optionally powered by beagle already. Nautilus _optionally_ depends on beagle. That means beagle integration without GNOME depending on beagle. If beagle were part of GNOME, would things really be any different? I think not. IMHO, GNOME should be _open to integration_, not assimilate all good gtk+ based applications. Regarding the "focus" issue, perhaps the distribution needs to drive this, not GNOME. I'm thinking for example of ubuntu vs edubuntu (education oriented variant of ubuntu). They're basically the same distribution, with different default colors and different default set of apps. _Maybe_ we could go one step further and have apps customize the level of complexity of the UI (like very early nautilus had as preference, like RB has a "compact" mode). Regards, -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic. smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: focus! (was Re: Focusing on innovation re: mono, python et al)
Dan Winship wrote: > Rich Burridge wrote: > >> I've seen GNOME steadily improve over the last few years, but it still >> doesn't have a cohesive wholeness to it. One of the problems in this >> respect is that different distros customize GNOME as they see fit. >> > > That's totally backwards. GNOME doesn't have a cohesive wholeness > because *it's not a cohesive whole*. It's a part. The distros *need* to > make changes to integrate GNOME with the rest of the distro and *make* a > cohesive whole. > Fair enough. This is the Novell desktop (based on GNOME). I'm sure I could dig up some comments on the Sun JDS (based on GNOME) desktop too. My concern here is that each of these desktops will have a different look&feel that goes beyond what the "GNOME desktop" provides. A user that is used to one, won't necessarily be automatically "at home" on the other. Other distro's provide their own look&feel which will be different again. One of the things I like about the Mac OS X desktop (and Windows Xp desktop for that matter), is that all applications provided by the vendor have a consistent look&feel. If I'm familiar with one application on that platform, then I can apply that knowledge as I'm learning a new one. This isn't true of all applications on the various GNOME desktops. What I'd like to see is more "cohesive wholeness" bought done to the common denominator. The underlying "GNOME desktop" that all these distros start from. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: focus! (was Re: Focusing on innovation re: mono, python et al)
Rich Burridge wrote: > I've seen GNOME steadily improve over the last few years, but it still > doesn't have a cohesive wholeness to it. One of the problems in this > respect is that different distros customize GNOME as they see fit. That's totally backwards. GNOME doesn't have a cohesive wholeness because *it's not a cohesive whole*. It's a part. The distros *need* to make changes to integrate GNOME with the rest of the distro and *make* a cohesive whole. Look, here are some quotes from the first 4 (non-duplicate) hits for "Novell SLED review"[1] on google: "The desktop environment itself is clean, attractive, and free of clutter. Novell claims to have done extensive user testing to refine SLED’s UI, and it shows. This is not your average, stock Gnome system." (InfoWorld) "this desktop is probably the cleanest and most logical desktop of ANY operating system I've come across. All in all it's hard to imagine a better organized workspace and set of capabilities." (dcperspective) "The most impressive feature is its complete lack of, what I call, 'ducktape' feeling. Virtually all distributions I have tried gave me the direct feeling I was using a product stitched together by ducktape; group A did something, group B as well, and group C stitched those two together with ducktape. SLED, however, feels as if the parts are surgically sewn together, after which a plastic surgeon hid the stitches. A huge step forward for desktop Linux." (OSNews) "For one thing, they’ve completely redesigned the GNOME interface (more on that in a moment), and integrated Beagle desktop search into the distro so completely that you wonder how you lived without it before." "I fought [the new main menu] at first, but trust me when I tell you that once you get used to it, you won’t know how you got this far without it." (madpenguin) (Ahem. Sorry for the advertising.) The reviewers have spoken, and they think that SLED is a cohesive whole, and that upstream GNOME and the distros that ship vanilla upstream GNOME aren't. So what can we (GNOME) do? There seem to be two broad directions: 1. Agree that (for now at least) GNOME is a part, not a whole, and that we can best help users by helping distros to build good wholes. 2. Figure out what sort of whole GNOME wants to be, and become it. Eg, if we want to be the sort of whole that SLED is, we'd become it by integrating Beagle and Tomboy. If we want to become the sort of whole that OS X is, we'd integrate Rhythmbox or Banshee and F-Spot. But regardless, if we want to be cohesive, we have to *integrate*, not keep a wall between the applications and the rest of the system. -- Dan [1] at first I tried just "SLED review", but that actually turned up reviews of sleds. :-) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: focus! (was Re: Focusing on innovation re: mono, python et al)
Havoc Pennington wrote: > > This of course is a personal question that everyone has to answer for > themselves; if GNOME made a beautiful just works super-integrated > desktop, that did not in the end have that many users (that failed to > bring an open source alternative to the general public); vs. if GNOME > made a lot of not-desktop-in-the-traditional-sense things and some of > them had a chance to reach the general public on a large scale; which > would we rather have. I know for sure that if people are honest with > themselves, we have a lot of developers on both sides of this question. > > I'm not sure we're doing either of those things right now though - our > current audience-benefit focuses that I've listed a few times don't care > _that_ much about "just works" or beautiful or integration. Not as much > as Apple's creative professionals audience does, for sure. > > So we tend to prioritize things like hackability/configurability, > diversity of apps, interoperability, i18n, reliable releases, > management/security, and so forth over more Apple-like priorities. The > de facto audience here winning over the audiences some people might more > idealistically have in mind. > btw, I bet GNOME can do all three of the strawman things I brought up here. But it's a matter of not trying to do them all in one big soupy way, but getting laser focus on each. Not thinking of any of them as "make a desktop," but something more specific in each case that may or may not involve a desktop, and if it does may also involve additional stuff on top of it. Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: focus! (was Re: Focusing on innovation re: mono, python et al)
Rich Burridge wrote: > > I was talking about things like: > > * look and feel. It's a beautiful desktop. > * ease of use. Most things "just work". > * integration of different desktop components. > > I'm not talking about market share. > This of course is a personal question that everyone has to answer for themselves; if GNOME made a beautiful just works super-integrated desktop, that did not in the end have that many users (that failed to bring an open source alternative to the general public); vs. if GNOME made a lot of not-desktop-in-the-traditional-sense things and some of them had a chance to reach the general public on a large scale; which would we rather have. I know for sure that if people are honest with themselves, we have a lot of developers on both sides of this question. I'm not sure we're doing either of those things right now though - our current audience-benefit focuses that I've listed a few times don't care _that_ much about "just works" or beautiful or integration. Not as much as Apple's creative professionals audience does, for sure. So we tend to prioritize things like hackability/configurability, diversity of apps, interoperability, i18n, reliable releases, management/security, and so forth over more Apple-like priorities. The de facto audience here winning over the audiences some people might more idealistically have in mind. The "enterprise Linux" distributions have some strong incentives different from the Apple-style priorities as well. Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Memory consumption and virtual machines
On Tue, 2006-07-18 at 09:30 -0600, Veerapuram Varadhan wrote: > > Take for example Evolution. Using ONE WEEK of hacking, I managed to > > reduce its memory footprint with at least 40 MB of ram. > > I don't know how many times I need to repeat, because, this keeps coming > in lot different threads and I see no progress to make the patch > complete. I'm waiting for the decision (yours) of making this optional using a compilation flag or at run-time. > Yes, I agree, the patch does reduce *STARTUP-MEMORY-FOOT > PRINT* of Evolution as mentioned by Federico in his blog, however, it is > *as of now* just-a-hack that the Evolution team cannot take it *as is*. > Phillip, as you keep saying the patch needs rework before considering > upstream, when are we going to get it? Will the final-patch addresses > all the concerns raised by me and Fejj? Guess, you are aware of the > GNOME release cycle and API freeze dates. It wouldn't be a good idea to glue this patch to an API freeze or GNOME release cycle as it needs extensive testing that shouldn't be bound by such milestones, but should be bound by test results. The test results have to be done on installations that I don't own. I cannot perform these tests with just my own equipment. I don't have customers that run Evolution on a NFS shared $HOME or run Evolution 4300 times on an application server. I guess this is why you wanted it to be optional. I'm still waiting for your decision of that "optionality" being at compile time or at run time. Note that at run time means that more errors and bugs are possible (especially when switching the implementation happens). Also note that after a full week of night-hacking on this patch, you have to remember that I'm not getting paid to do this. That I have a daytime job and a girlfriend. -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: focus! (was Re: Focusing on innovation re: mono, python et al)
Havoc Pennington wrote: > Rich Burridge wrote: >> Christian Fredrik Kalager Schaller wrote: >>> I am not saying we shouldn't take good ideas etc., from Apple, but lets >>> try to remember that Apple is basically a failure in the desktop >>> market. >> >> What were you smoking when you wrote this? >> > > Well, it depends on your "success metric" when talking about "failure" Thanks for the good summary. I was talking about things like: * look and feel. It's a beautiful desktop. * ease of use. Most things "just work". * integration of different desktop components. I'm not talking about market share. I've seen GNOME steadily improve over the last few years, but it still doesn't have a cohesive wholeness to it. One of the problems in this respect is that different distros customize GNOME as they see fit. You can't always assume what's going to be there (or if it will be the same place in the menu hierarchy). It's like the different flavours of UNIX and Linux all over again. Perhaps there needs to be a concise definition of what you can always expect in a GNOME desktop and where it will be. Maybe that's exactly what Core GNOME desktop is all about. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: focus! (was Re: Focusing on innovation re: mono, python et al)
Rich Burridge wrote: > Christian Fredrik Kalager Schaller wrote: >> I am not saying we shouldn't take good ideas etc., from Apple, but lets >> try to remember that Apple is basically a failure in the desktop market. > > What were you smoking when you wrote this? > Well, it depends on your "success metric" when talking about "failure" Christian is right in many ways if you are talking about marketshare... their marketshare is in the 3-10% range (depending on who you ask) and has not really shown signs of exceeding that... and most of it is based on a historical market that Windows never really had (creative professionals) so Apple's track record of getting people to 'switch' is even worse than 3-10% might indicate. There's recent health caused by getting out of the "switch people's desktop" rut and creating something new with the iPod/iTunes/etc. line of stuff. That brand equity has rubbed off on the desktop a bit. But basically Apple's desktop remains a premium product for certain audiences, with no real chance of having 20-50% marketshare anytime soon. GNOME could learn a lot here. Both OS X and Firefox illustrate to me that even with near-perfect branding, marketing, and usability, the "switch from A to B in the same category - same benefit to same audience" premise for a product will not be a blockbuster success vs. the market leader. While with something that's really a new category with no clear market leader yet, you get breakout successes - in many cases _despite_ bad usability, low quality, lack of marketing, and other issues. That's why qualitative/disruptive difference in kind is so much more interesting than quantitative "betterness" along some continuous dimension, if your goal is to have a huge impact on lots of people. I do think OS X has some qualitative/disruptive differences in the apps Apple offers, but in those cases the apps are sort of boat-anchored by the OS; that is, offering the apps' benefits minus having to switch to OS X would make the apps take off far faster. For example, if iTunes/iPod were Mac-only it would be much less successful. Anyhow... you could definitely say that OS X is a design success or serves its audience well or has made Apple a lot of money, i.e. in many ways it's not a failure, not really interested in arguing that. But in marketshare terms it isn't the best kind of product for rapid/mass adoption. Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: focus! (was Re: Focusing on innovation re: mono, python et al)
On Tue, 2006-07-18 at 08:33 -0700, Rich Burridge wrote: > Christian Fredrik Kalager Schaller wrote: > > I am not saying we shouldn't take good ideas etc., from Apple, but lets > > try to remember that Apple is basically a failure in the desktop market. > > What were you smoking when you wrote this? I don't think that your comment is very constructive or insightful. 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: focus! (was Re: Focusing on innovation re: mono, python et al)
Christian Fredrik Kalager Schaller wrote: > I am not saying we shouldn't take good ideas etc., from Apple, but lets > try to remember that Apple is basically a failure in the desktop market. What were you smoking when you wrote this? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Memory consumption and virtual machines
On Mon, 2006-07-17 at 08:57 +, Philip Van Hoof wrote: > The lovely smell of programming environment flame wars! > > Part one > > As the developer of an application that has an extremely high focus on > reduced memory consumption and as the author of a patch for Camel that > reduced Evolutions memory footprint with ~40 MB (maybe more, but that > number I'm certain of) . . . > > Take for example Evolution. Using ONE WEEK of hacking, I managed to > reduce its memory footprint with at least 40 MB of ram. I don't know how many times I need to repeat, because, this keeps coming in lot different threads and I see no progress to make the patch complete. Yes, I agree, the patch does reduce *STARTUP-MEMORY-FOOT PRINT* of Evolution as mentioned by Federico in his blog, however, it is *as of now* just-a-hack that the Evolution team cannot take it *as is*. Phillip, as you keep saying the patch needs rework before considering upstream, when are we going to get it? Will the final-patch addresses all the concerns raised by me and Fejj? Guess, you are aware of the GNOME release cycle and API freeze dates. V. Varadhan Novell, Inc. Software for the Open Enterprise™ http://www.novell.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Focusing on innovation re: mono, python et al
On Mon, 2006-07-17 at 09:33 -0400, JP Rosevear wrote: > On Mon, 2006-07-17 at 11:30 +0200, Murray Cumming wrote: > > > On 7/17/06, Murray Cumming <[EMAIL PROTECTED]> wrote: > > >> > > >> > Which makes me wonder why we are able to bless some applications and > > >> > not others. The point of blessing the application is saying that this > > >> > application meets the gnome standards for X,Y and Z and has a release > > >> > shedule that coincides with the gnome platform release. > > >> > > >> And that people will work on it to bug-triage it, bug fix it, translate > > >> it, document it, UI review it, integrate it, and present it, which is > > >> what > > >> that release schedule makes possible. > > > > > > And so why does what language it is written in matter to this blessing > > > at all then? > > > > - Multiple languages make the work harder by requiring people to know more > > languages > > Only for bug fixing part, the language for development has no bearings > on triage, translation, ui review, documentation, etc. To be perfectly fair, both .Net and Python have different format strings than those used by printf. So there is some extra burden on translators. So including Mono apps would give translators four different format string conventions to learn (counting the crap I made them learn for XSLT.) It can also have an impact on bug triaging. A lot of bug folks do basically understand stack traces, and they're able to triage accordingly. On more than one occasion, I've had bug squad members identify duplicates that the simple dup finder didn't catch. Neither of these are deal-breakers. But they are do make work a bit harder, and they shouldn't be ignored. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: focus! (was Re: Focusing on innovation re: mono, python et al)
Sankarshan Mukhopadhyay wrote: > Havoc Pennington wrote: > >> My first-order answer is that GNOME thinks of itself as "making a >> desktop" - even though the _reality_ is that the larger GNOME >> community/ecosystem is doing way more than that, and that the larger >> tech industry is doing still more. > > Would you consider junking the concept of "GNOME as a desktop" in favor > of "GNOME as an application development programming context" or would > think that the slicing should go deeper ? Namely, percolating the idea > right down to the level where applications are developed around GNOME > core (assuming the segregation of GNOME core and GNOME extras). From the > earlier mail that you posted it would appear that you favor a shift of > GNOME from a software development paradigm to a more personal/social (if > I may) context. Wherein the *who* assumes greater importance while > releasing GNOME rather than *what*. > > As it stands I don't see an aggressive movement towards (re)doing the > GNOME messaging - its happening but its taking its time probably because > of the distribution centric messaging that goes for GNOME. Perhaps the > time is really there to start talking more about the context in which > GNOME figures in every day computing rather then the concept where GNOME > provides applications (cool as they may be) but in no ways do emphasize > the stuff GNOME is supposed to do. I tend to think explicit platform-building sucks (vs. accidentally making a platform in the course of making something useful). What I'm advocating is something like this goal set: GNOME big picture: Bring a 100% open source computing environment to the general public. Subprojects we have already - GNOME Thin Desktop: Create a manageable, secure, simple, gratis desktop for computer labs worldwide. GNOME Technical Desktop: Create a fun, hackable, rapidly-changing work environment for programmers, administrators, and tech enthusiasts. GNOME Server Console: Create a command center for enterprise server operating system administrators. Stuff we have already, but not labeled GNOME, much of it never will be, but by way of example: GNOME "One Laptop Per Child": Create a simple social environment for experiential learning. (or whatever, would not presume to know how to state this one) GNOME Maemo: I don't know their "concept" or target audience, but I can imagine something like - Create a "newspaper replacement" device for coffee shops, the kitchen table, riding the train to work. GNOME [anything - look at the full breadth of the tech industry!] In other words, associate the names/brands/teams with specific-benefit-to-specific-audience statements. Many of these things would share code, or even almost all code. That's what I'm saying about not splitting by codebase. There's a natural "platform" which is just "stuff many of these subprojects happens to use" There's are also other "platform" meanings, like "stuff the desktop-ish subprojects recommend to desktop-ish ISVs" Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: focus! (was Re: Focusing on innovation re: mono, python et al)
BJörn Lindqvist wrote: >> Current: >> - historical UNIX workstation users who want something similar but not >> dead >> - technology fans who want a set of apps they can mess with and >> heavily customize >> - thin client / computer lab deployments who want something with good >> manageability / security and low cost (the low cost especially for >> government/edu) >> - server administrators who want to pack a lot of ssh sessions onto >> the screen, use some web-based admin consoles, and occasionally waste >> some time doing non-work stuff >> - ... >> >> Future: >> - ... ? (try to be as specific as the above) > > Look at Windows. All this talk about the "target audience" scares the > hell out of me. Because if is decided that the target audience is the > white collar office worker (or some other stereotype I don't belong > to) it means that GNOME wont benefit me anymore. > 1) The point is to explicitly list you, and whoever else, and then (instead of talking vaguely about "the user" and doing crap neither one of you likes) make sure the GNOME project offers something for both. Now, I don't _personally_ believe that something truly suitable for many mainstream audiences could be _exactly_ the same codebase as something that works well for GNOME's current audiences. GNOME 2 (in a vague, ill-informed, we-were-all-much-younger kind of way) tried to dump the current audiences for future audiences, but was both too radical for current and not nearly radical enough for future. So, let's not do that again. It's been corrected now; GNOME desktop subproject has been soundly moved back to the current audiences I described, more or less, and is (IMHO) not moving very quickly or effectively toward mainstream audiences - except for the potential in the rich ecosystem of stuff _outside_ the desktop release proper. My personal belief is that the "desktop release" should stay focused about where it is (but retitled so people more clearly understand that) and new directions found for other audiences. 2) Sounds like you're taking "the desktop" as the only goal. I agree there's an existing category of software "the desktop" and people who know they want it know about what they want from it, and there's no need to get fancy. There's much benefit to understanding the current audiences for the GNOME desktop subproject, in order to serve them better. I also think it would be valuable to think honestly about which other audiences _need_ or _want_ an alternative desktop. But for audiences who aren't looking for an alternative desktop and have no reason to, I see no reason to go looking for nails for an existing hammer. Build a wrench instead of a hammer. 3) In other words, actually try to do my "Future" exercise in a way that's parallel to the list I offered for "Current" - IOW, in a way that lists the _benefits_ of a _desktop_ (not _part_ of a desktop such as an app - what's the benefit to making people _switch their whole OS_). It's very hard to do if you keep this constraint that the Future items all have to offer a nail suitable for the desktop hammer. But give that up and be willing to build a wrench instead, and your Future list will quickly be a mile long. That's how open source has to be thinking to succeed. 4) In other words, GNOME is not offering benefits to a vacuum. It's offering benefits _vs what people already have, including Windows_. If Microsoft is really designing "for everyone" as you say, then that's their weakness and where many of their competitors (Apple, Google, Blackberry) have made the strongest inroads. 5) As a minor side point, Windows may end up being useful for everyone, but I feel their (conscious or not) design center is something like "enterprise IT staff supporting users of MS Office" - they often shaft their other audiences to serve that one, and it's some huge majority of their revenues. In fact, the current audiences of GNOME (I would say) are people who have been shafted by this Microsoft focus, and more tightly focused on by the GNOME project. Which should be a lesson to us. Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Focusing on innovation re: mono, python et al
On Mon, 2006-07-17 at 09:32 -0400, JP Rosevear wrote: > > Since applications > > that are included in the core GNOME desktop are known to be well- > > maintained, widely-translated, and released on a regular schedule, it > > can certainly be more desirable for a distro to include a core GNOME > > app than an alternative, especially if it's one for which their users > > are paying for support. > > They are known to be somewhat well maintained but the quality varies > widely in practice. True, and I'd certainly expect that to be a factor in any distro's decision too. If a poor-quality, well-maintained product doesn't measurably improve over time, though, it should probably be dropped from the GNOME desktop release anyway, if there's a better alternative. Cheeri, Calum. -- CALUM BENSON, Usability Engineer Sun Microsystems Ireland mailto:[EMAIL PROTECTED]Java Desktop System Group http://ie.sun.com +353 1 819 9771 Any opinions are personal and not necessarily those of Sun Microsystems ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On breaking the woohoo barrier...thoughts on how GNOME can get great
On Mon, 2006-07-17 at 16:17 +0530, Sankarshan Mukhopadhyay wrote: > One of the things that seems to be drifting with GNOME both in its > current form and in the upcoming (and proposed Topaz) is that a whole > bunch of features are getting tossed at the end user without actively > bundling them together in a coherent whole of benefits accrued. > > Why would end users use GNOME and thus Linux Or Solaris, or FreeBSD... :) Cheeri, Calum. -- CALUM BENSON, Usability Engineer Sun Microsystems Ireland mailto:[EMAIL PROTECTED]Java Desktop System Group http://ie.sun.com +353 1 819 9771 Any opinions are personal and not necessarily those of Sun Microsystems ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: focus! (was Re: Focusing on innovation re: mono, python et al)
> Actually I have to say we should stop idealizing Apple that much, they are > a company which basically has gone from being the desktop leader to today > being a fringe player. They have survived partly by clinging onto a couple > of niches like graphical design and to some degree education. That was true five years ago. - Jeff -- linux.conf.au 2007: Sydney, Australia http://lca2007.linux.org.au/ "Microsoft treats security vulnerabilities as public relations problems." - Bruce Schneier ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: focus! (was Re: Focusing on innovation re: mono, python et al)
On Jul 18, 2006, at 11:54 PM, Sankarshan Mukhopadhyay wrote:
>
> Matthew Paul Thomas wrote:
>>
>> If that happened, the platform developers would likely have less
>> interaction with application developers on mailing lists like this
>> one. So you'd be more likely to end up like the W3C's HTML Working
>> Group has with XHTML 2.0 -- spending huge amounts of time producing
>> an extremely elegant platform that's useless for real-world
>> applications.
>
> Why would that happen in the event GNOME decides to remould itself
> from being a kick-ass *desktop* to being a coherent platform ?
> ...
Because I was using "platform" as shorthand for your "application
development programming context", which apparently excluded
applications ("applications are developed around GNOME core").
I've used only one kick-ass desktop, and that's the one my computers
sit on.
--
Matthew Paul Thomas
http://mpt.net.nz/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: focus! (was Re: Focusing on innovation re: mono, python et al)
Matthew Paul Thomas wrote: > If that happened, the platform developers would likely have less > interaction with application developers on mailing lists like this one. > So you'd be more likely to end up like the W3C's HTML Working Group has > with XHTML 2.0 -- spending huge amounts of time producing an extremely > elegant platform that's useless for real-world applications. Why would that happen in the event GNOME decides to remould itself from being a kick-ass *desktop* to being a coherent platform ? :Sankarshan -- http://www.gutenberg.net - Fine literature digitally re-published http://www.plos.org - Public Library of Science http://www.creativecommons.org - Flexible copyright for creative work ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: focus! (was Re: Focusing on innovation re: mono, python et al)
Christian Fredrik Kalager Schaller wrote: [a snip here] > They have over the last few years managed to grow a little into the > tech geek segment and the multimedia market, but even using things like > iPod and iTunes to push their desktops they seem to have managed little > apart from not slipping further down in market share and instead staying > around their allotted 4% to 5%. [and another here] Perhaps one of the aspects of this thread would be to look beyond the metaphor for the desktop and more into the metaphor as one that extends the workspace area (without calling it a desktop) into the space and context of personal computing and social collaboration. Apple might have got it wrong to use iTunes and iPod to push their desktops (I don't know since I don't have the stats) but using non-desktop metaphors to a GNOME platform might not be utopian as on date. :Sankarshan -- http://www.gutenberg.net - Fine literature digitally re-published http://www.plos.org - Public Library of Science http://www.creativecommons.org - Flexible copyright for creative work ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: focus! (was Re: Focusing on innovation re: mono, python et al)
Actually I have to say we should stop idealizing Apple that much, they are a company which basically has gone from being the desktop leader to today being a fringe player. They have survived partly by clinging onto a couple of niches like graphical design and to some degree education. They have over the last few years managed to grow a little into the tech geek segment and the multimedia market, but even using things like iPod and iTunes to push their desktops they seem to have managed little apart from not slipping further down in market share and instead staying around their allotted 4% to 5%. I am not saying we shouldn't take good ideas etc., from Apple, but lets try to remember that Apple is basically a failure in the desktop market. Nothing objectively wrong with many of the approaches Apple takes, but obviously the market doesn't care enough about them to reward Apple with any significant market share gains. Over the last decade there has been many 'must have' technologies hyped which turned out to marginal and worthless. For instance many of probably remember that one of the last battles fought in the browser wars where in the area of 'push technology'. All analysts seemed to agree that who of Microsoft and Netscape that managed to come up with the best push solution would be the winner of that generation of browsers. Well both active Desktop and Netscape Netcaster was released with much fanfare only to relatively quickly fade into obscurity and be discontinued. Apple's 'cool' is a bit like 'push technology' it is this thing people talk about, but if you look at the marketplace it isn't obvious it matters. Christian On Tue, 2006-07-18 at 18:57 +1000, Jeff Waugh wrote: > > > > All this talk about the "target audience" scares the hell out of me. > > Because if is decided that the target audience is the white collar office > > worker (or some other stereotype I don't belong to) it means that GNOME > > wont benefit me anymore. > > That doesn't have to be true. Consider OS X - if anything, their target has > been 'creative professionals' (which reaches into all kinds of places) for a > long time. But they've been able to amass a *huge* number of hacker and geek > users with their development platform, UNIX heritage, 'just works' approach, > and lustful upmarket / cool kids attractiveness. > > "Picking an audience" doesn't necessarily mean picking *only one* audience. > > :-) > > - Jeff > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: focus! (was Re: Focusing on innovation re: mono, python et al)
On Jul 18, 2006, at 9:50 PM, Sankarshan Mukhopadhyay wrote: > > Havoc Pennington wrote: >> >> My first-order answer is that GNOME thinks of itself as "making a >> desktop" - even though the _reality_ is that the larger GNOME >> community/ecosystem is doing way more than that, and that the larger >> tech industry is doing still more. > > Would you consider junking the concept of "GNOME as a desktop" in > favor of "GNOME as an application development programming context" or > would think that the slicing should go deeper ? Namely, percolating > the idea right down to the level where applications are developed > around GNOME core (assuming the segregation of GNOME core and GNOME > extras). > ... If that happened, the platform developers would likely have less interaction with application developers on mailing lists like this one. So you'd be more likely to end up like the W3C's HTML Working Group has with XHTML 2.0 -- spending huge amounts of time producing an extremely elegant platform that's useless for real-world applications. To ensure usefulness of the platform for as many distributors as possible, perhaps it would be better for Gnome to contain *a representative sample* of software for various genres (office, artist, scientist, gamer), skill levels (cf. iLife vs. Apple's "Pro apps", or Microsoft Works vs. Office), and hardware types (desktop, PDA, OLPC) -- so you can demonstrate that Gnome is a suitable development platform for all those audiences, rather than trying yourself to solve all the problems of any single audience. Gnome-wide efforts on things like usability, localization, library deprecation, etc would also be less effective if it was reduced to an "application development programming context". Cheers -- Matthew Paul Thomas http://mpt.net.nz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: focus! (was Re: Focusing on innovation re: mono, python et al)
Jeff Waugh wrote: > "Picking an audience" doesn't necessarily mean picking *only one* audience. Would it be that while searching for the *this is our audience* block, we have managed to begin to stop to think about what GNOME really is ? :Sankarshan -- http://www.gutenberg.net - Fine literature digitally re-published http://www.plos.org - Public Library of Science http://www.creativecommons.org - Flexible copyright for creative work ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: focus! (was Re: Focusing on innovation re: mono, python et al)
Havoc Pennington wrote: > My first-order answer is that GNOME thinks of itself as "making a > desktop" - even though the _reality_ is that the larger GNOME > community/ecosystem is doing way more than that, and that the larger > tech industry is doing still more. Would you consider junking the concept of "GNOME as a desktop" in favor of "GNOME as an application development programming context" or would think that the slicing should go deeper ? Namely, percolating the idea right down to the level where applications are developed around GNOME core (assuming the segregation of GNOME core and GNOME extras). From the earlier mail that you posted it would appear that you favor a shift of GNOME from a software development paradigm to a more personal/social (if I may) context. Wherein the *who* assumes greater importance while releasing GNOME rather than *what*. As it stands I don't see an aggressive movement towards (re)doing the GNOME messaging - its happening but its taking its time probably because of the distribution centric messaging that goes for GNOME. Perhaps the time is really there to start talking more about the context in which GNOME figures in every day computing rather then the concept where GNOME provides applications (cool as they may be) but in no ways do emphasize the stuff GNOME is supposed to do. :Sankarshan -- http://www.gutenberg.net - Fine literature digitally re-published http://www.plos.org - Public Library of Science http://www.creativecommons.org - Flexible copyright for creative work ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: focus! (was Re: Focusing on innovation re: mono, python et al)
> All this talk about the "target audience" scares the hell out of me. > Because if is decided that the target audience is the white collar office > worker (or some other stereotype I don't belong to) it means that GNOME > wont benefit me anymore. That doesn't have to be true. Consider OS X - if anything, their target has been 'creative professionals' (which reaches into all kinds of places) for a long time. But they've been able to amass a *huge* number of hacker and geek users with their development platform, UNIX heritage, 'just works' approach, and lustful upmarket / cool kids attractiveness. "Picking an audience" doesn't necessarily mean picking *only one* audience. :-) - Jeff -- linux.conf.au 2007: Sydney, Australia http://lca2007.linux.org.au/ "Socks for the foot menu!" - Liam Quin ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: focus! (was Re: Focusing on innovation re: mono, python et al)
On 7/17/06, Havoc Pennington <[EMAIL PROTECTED]> wrote: > Jeff Waugh wrote: > > > > > >> Or even why is GNOME sidelining things like: > >> - Maemo > >> - Elisa > >> - One Laptop Per Child > >> - ... > > > > You make it sound active - it's not, it's passive. But that's changing. > > I don't mean to imply active or not, and I'm glad to hear it's changing. > > I think having some of those non-desktop projects on equal footing > within GNOME alongside the desktop release would make a big difference. > _Especially_ if each subproject is defined by its target audience and > benefit, rather than by its codebase. > > I thought of a more concrete approach to understanding what this means. > > Question for the list, what is the target audience and benefit to them > of the desktop release? The target audience is ME!! :) Seriously look at Windows and ask the same question. What is the target audience and benefit to them of Windows? The answer is it makes the computer work and present a graphical interface that allows more advanced applications to be built ontop of it. A simple computing environment usable for anyone. That is the goal Microsoft is striving for, GNOME should have a just as ambitious goal. There are lots of functionality that is generally useful to everyone. Or atleast a large minority of all users. Like a file manager, window manager, display manager, configuration center, text editor, package manager, games, web browser, music and video player, system monitor, terminal emulator, word processor, spreadsheet calculator, email manager, calendar, cd burner, irc client, im client, mobile phone synchronization, plus lots more. And that IS GNOME, isn't it? The challenge is to integrate it into one coherent mass so that it becomes maximally useful for the largest number of people possible. > Current: > - historical UNIX workstation users who want something similar but not > dead > - technology fans who want a set of apps they can mess with and > heavily customize > - thin client / computer lab deployments who want something with good > manageability / security and low cost (the low cost especially for > government/edu) > - server administrators who want to pack a lot of ssh sessions onto > the screen, use some web-based admin consoles, and occasionally waste > some time doing non-work stuff > - ... > > Future: > - ... ? (try to be as specific as the above) Look at Windows. All this talk about the "target audience" scares the hell out of me. Because if is decided that the target audience is the white collar office worker (or some other stereotype I don't belong to) it means that GNOME wont benefit me anymore. -- mvh Björn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
