Re: What about Embedded?
Mono has been successfully used in embedded systems of different sorts. Examples? Or are we just talking about some guy who got it working once? In the particular context of Gnome and Mono, I assumed you were talking about Maemo which is probably the high profile user of Gnome today on an small device, and on Maemo Mono is just a fine solution. Maemo are not using Python yet as far as I can tell. They would like to support it as a development environment, and maybe then use it for their own core stuff. But it needs some performance/memory/code-size work. 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
Save a kitten today (was Re: What about Embedded?)
On jeu, 2006-07-20 at 23:24 +0100, Jamie McCracken wrote: I totally agree but wouldn't it be better to use native languages that offer all this like the D language (http://www.digitalmars.com/d/). It's cool to read about various languages, but really, this is off-topic on this list. We're in the process of choosing which modules we'll include and deciding whether we'll accept apps written with Gtk#. It's not easy and there's been a lot of noise that make it even less easy. So please think twice before sending an email, especially when the list becomes high-traffic as it is right now. We don't want to see developers unsubscribing because of the noise. (this is not only for Jamie, but for everyone here) Thanks, Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
(Legal) advice needed
Hi, Here is the problem I've run into. I'm the author of bonfire, an app for burning CD/DVD (http://gnomefiles.org/app.php?soft_id=1158). Recently I've been given a CVS account to import it into GNOME CVS. Before I did it, a user reported that bonfire was a name used by a Canadian site selling music to be downloaded (http://bonfire.puretracks.com/). Apparently they had trademarked this name (see http://strategis.ic.gc.ca/app/cipo/trademarks/search/tmSearch.do?language=eng and search for bonfire). So, my question is: Is it still OK to import bonfire into GNOME CVS or should I change the name before? Of course I'm reluctant to change the name for many reasons, being: - the site is Canadian, I'm French and GNOME servers are in the USA, so maybe trademark doesn't apply in this case - bonfire just started to get included in some major distribution and changing the name will postpone everything - it's a new application and changing the name would confuse many people - above all, Bestbuy (the trademark holder) won't really care about my app having the same name What I thought was: import bonfire into GNOME CVS and wait and see. If Bestbuy reacts (which I doubt but who knows) I would change the name. But I really want to make sure that it's not an issue for GNOME. That being said, I would change the name if that was a problem regarding GNOME. I really need advice. Thanks in advance. Regards, Philippe Rouquier -- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Crush the political bullshit [Was: What about Embedded?]
quote who=Philip Van Hoof In an opensource setting, we should CRUSH political bullshit and overthrow it with technical superiority. We are by the way NOT doing that, and in stead failing TECHNICALLY at the exact same POLITICAL problems companies are also facing. Philip, Firstly, what we are doing (Free Software) is *inherently* political, and in many ways hasn't been technically superior for a long time. Do we give up? Absolutely not. Secondly, there are lots of interests involved in what we do, and sometimes they are competing interests (competing - and yet collaborating). You can't just make simplistic statements like CRUSH political bullshit and expect it to actually mean anything. It's just another way to dismiss people's entirely valid points of view. We can't do that. There are hard choices to be made here, some of which may exclude members of our community. These choices may not have such import to you, but please don't disregard or disrespect the other points of view in our community. Thanks, - Jeff -- linux.conf.au 2007: Sydney, Australia http://lca2007.linux.org.au/ People who paid for bug fixes in the 3c501 driver also bought MacIIfx support contracts... - Alan Cox ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Some Vala ideas (Was: What about Embedded?)
On Fri, 2006-07-21 at 11:23 +0200, Philip Van Hoof wrote: On Fri, 2006-07-21 at 07:07 +0200, Jürg Billeter wrote: You might be interested in looking at Vala http://www.paldo.org/vala/ . It's not ready for production use yet but it's available for testing now and with feedback [hint ;) ] from interested developers I believe that we can get a very nice development environment for GNOME ready in relatively short time. Yes Jürg, I have been looking at your Vala stuff very recently indeed. And I indeed have to say it looks very interesting. I even think language binding code generators are not the best solution. Imo it should be handled by the languages themselves and fully automatically. Other than political, I don't see the *real* technical difficulties for something like that. Probably because Vincent asked us to keep on topic, Jürg replied me in private about his idea to have compiler plugins and a standardized interface description (like GIDL). I hope some more people with ideas will contact Jürg and share them. -- 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: Migration Paths for New Modules
Shaun McCance wrote: On Thu, 2006-07-20 at 13:52 -0500, Shaun McCance wrote: Yikes, all right. We should definitely keep the exec_ats key for legacy. I suppose the Assistive Technology Preferences dialog should continue to set the old values, if possible, to keep older machines functioning the same. I'm not sure what keys are used by the Preferred Applications dialog. The keys under /desktop/gnome/applications seem to be obsolete. We could just make six keys: a boolean to enable each technology, and an exec string for each technology. Then there's the question of the interface. Would we want to shunt stuff off to the Preferred Applications dialog? I think it will be more obvious if it's right in the Assistive Technology Preferences dialog. So something like I meant to say something else here, but forgot about it. What happens if I set my preferred screen reader to Orca on a fancy new machine, and then try to log into an older Gnome using the same home directory. We don't have any sort of fallback mechanism in place. This problem isn't unique to us, by the way, and it goes as far back as networked Unix itself. Changing your shell, for example, can be a real headache on a heterogeneous network with centrally-managed login information. You won't even be able to log into a machine without your selected shell. I don't necessarily have a good solution to this problem. I can think of some strategies, but none that I think are much more than a hack. I know there's been blue-sky talk of a next-generation configuration system. A general-purpose solution to problems like these would be a definite selling point for such a system. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list This is one of my biggest headaches in supporting enterprise GNOME users. Consider these use cases: 1.An ISV creates creates a custom application and wisely chooses to base this application on GNOME components which won't change between releases. He creates a launcher for this application in the main menu. The launcher stops working when GNOME is upgraded. Not a huge problem for a developer on his laptop, a major headache for a sysadmin of 5,000 desktops. 2.Someone logs into a server running GNOME 2.1X, logs out and logs into a server running GNOME 2.1.X+2 using the same NFS home directory. 3.Someone logs into a server running GNOME 2.1.X, _doesn't_ log out and logs into a server running GNOME 2.1.X+2 using the same NFS home directory. (This can be common on Sun Ray and possibly other thin client GNOMEs) Should we say that cases 1-3 won't be supported by GNOME? or... A simple but incomplete and probably slow solution (hack?) might be to put the entire home directory under CVS control or on top of a versioning filesystem and give gdm and gnome session the smarts to checkout the right branch during login. Would something like this work instead?: Move everything off the filesystem into the filesystem independent configuration database. (this includes .gaim, .evolution, .gimp,.mozilla, font stuff, desktop files... which means the configuration database shouldn't be slower than the filesystem.) The configuration system manages configuration objects which expose read/write methods based on release, key and migration rules. E.G. Key :Range:Rule default_screenreader:2.10-2.14:RW default_screenreader:2.06-2.14:R default_screenreader:2.16-2.20:M The M rule means the migrate methods would be called for releases where Read or Write are not already defined in the rules. These methods would take key, version_key and version_now. In this case, the migrate read method would decide that if default_screenreader GNOME 2.12 key value is gnopernicus, and the client is version 2.16, it returns orca. Yeah, I know this idea is only 25% baked, but could it be refined into something which would improve the user experience? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: (Legal) advice needed
On 7/21/06, Rouquier Philippe [EMAIL PROTECTED] wrote: Hi, Here is the problem I've run into. I'm the author of bonfire, an app for burning CD/DVD (http://gnomefiles.org/app.php?soft_id=1158). Recently I've been given a CVS account to import it into GNOME CVS. Before I did it, a user reported that bonfire was a name used by a Canadian site selling music to be downloaded (http://bonfire.puretracks.com/). Apparently they had trademarked this name (see http://strategis.ic.gc.ca/app/cipo/trademarks/search/tmSearch.do?language=eng and search for bonfire). Application # 1218927 and 1218917 for those wondering. So, my question is: Is it still OK to import bonfire into GNOME CVS or should I change the name before? We don't have a formal policy on such things, but obviously we'd prefer to avoid known legal problems. Of course I'm reluctant to change the name for many reasons, being: - the site is Canadian, I'm French and GNOME servers are in the USA, so maybe trademark doesn't apply in this case IANAL(Y)* but some things to consider: (1) trademarks can be extended; i.e., it is likely that if Best Buy wanted to file to use this mark in the US or France, they would get it and could cause you legal problems in a completely traditional, valid way. (Though you have been using it in the US and France longer than they have, so you might win the case, but it would be expensive, a PITA, etc.) (2) GNOME does try to distribute in Canada; it would be irritating if a Canadian court told us we had to block ftp.g.o from being seen by Canadians :) This is a very messy area of the law, with very little settled precedent, but again, they could try to make life irritating/expensive/not fun. - bonfire just started to get included in some major distribution and changing the name will postpone everything - it's a new application and changing the name would confuse many people You should ask the Ekiga guys about that- it would seem that their name change went pretty smoothly. - above all, Bestbuy (the trademark holder) won't really care about my app having the same name This is a legal and strategy decision for them, but they are probably *required* by trademark law (if Canadian law is anything like American law) to care about your app having the same name, at least in Canada. If they don't defend it against you, they can lose the right to use the mark to describe software, which presumably is a big problem for them. What I thought was: import bonfire into GNOME CVS and wait and see. If Bestbuy reacts (which I doubt but who knows) I would change the name. But I really want to make sure that it's not an issue for GNOME. I'd certainly suggest being proactive, changing the name now, and getting it over with instead of letting it hang over your head- if bonfire is incredibly successful, someday this *will* be a problem. Whether or not it is a problem for GNOME should probably be left to a real lawyer- if the only legal penalty is 'you have to change the name', then it probably shouldn't be a problem for GNOME; if the potential legal penalty is 'change the name and fork over a lot of cash', then the board should probably think about it :) Luis * Hi Dave! Hi Jeff! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Putting the 'Mono debate' back on the rails
Ni hao, (Wow, this took a long time to write. Sorry!) I hope that everyone is unhappy about the running thread about Mono on d-d-l at the moment. Not because I want everyone to be unhappy - but I hope we can agree that it has devolved into argument, that everyone's sticking their oar in whether they should or not, and it's a real pity that we had to fall into this straight after GUADEC... Let's put the brakes on, step back, and aim towards finding a resolution. It might not please everyone, and we have to be prepared for that - but I don't think anyone here actually *wants* to have an argument. We want to find some answers. So let's see if we can turn this discussion around and work towards a resolution... then we can get back to changing the world! One of the problems I've seen in this discussion is that we're finding a lot of issues difficult to separate. We're conflating things, making it hard to see the wood from the trees. There are all kinds of questions here that have a lot of history, and there are some short term and long term goals or plans that *have* to be separated out to be discussed in any sane manner. This is not going to be simple, because there are no simple answers. We can't start dismissing each other's input and approaching this like it's a black'n'white debate - there are a *lot* of greys here, and we must approach it with that in mind. However, things *can* get simpler if we try to document and understand the problems. We can work together to define the parameters of the debate, which bits are complicated and which bits are not - I hope this list can go some way towards clarifying things. Here's a separated list of the short and long term things related to the 'Mono debate' that we have to resolve and a start on nutting out the parameters of each. I'm sure there's more and it's likely that we should turn this into a wiki page later. I'm going to follow up with some process suggestions to see this through, but first I want to get this out and documented. Here goes: * Should we include Gtk# in the Bindings suite? - short term - it hasn't been proposed for 2.16, but we could grandfather it in - the release management issues have largely been solved, aside from Gtk# not being split between Platform and Desktop (stable and unstable) APIs which is pretty important in terms of ISV/ISD communication and so on - bindings are a very important part of GNOME, and our value proposition - it seems that few people are concerned about Gtk# adopting the release process and other standards, then being included in our Bindings suite - a social/business/non-technical issue may persist regarding GNOME using or endorsing a Microsoft derived technology; some users/vendors may not appreciate that, to the point that they may choose to disassociate from the GNOME project (this shouldn't be dismissed out of hand) * Should we include Tomboy in the Desktop suite? (completely independently from the fact that it uses Gtk#/Mono) - short term - it has been proposed for 2.16 - does it *need* to go in the Desktop suite at all? (genuine question, it may not be necessary to include Tomboy in the Desktop suite to achieve Tomboy's goals) - if we say yes here, we depend on the next question (but short term, the next question only starts to matter if we say yes here!) * Should Gtk#/Mono applications be accepted into the Desktop suite? - short to medium term - pathological case of 'Desktop suite pressure' (everyone wants their stuff in the Desktop suite because that's how you become enfranchised) - performance (memory and cpu) is a red herring here; we all *know* that we want to start using higher level languages for writing amazing GNOME software, so whether it's Gtk#/Mono, Python, Java, Perl or Brainfuck, we fully acknowledge that we're taking a hit for developer productivity and our ability to deliver awesome software to users. very few pieces of the software on the radar for proposal are central, 'always-on' elements of the desktop experience (think f-spot vs. beagle). performance will be an important metric for inclusion of any software, but it needs to be done on a case by case basis, not from a dogmatic perspective about competing platforms or the idea of using higher level languages at all. that horse has well and truly bolted! - can we resolve the dissonance between delivering a coherent Desktop (a goal of the Desktop suite) and suggesting that vendors deliver multiple vm/language/binding/runtime platforms to satisfy it, and demand that users stomach it too? (this has also been raised as a performance issue) - a social/business/non-technical issue may persist regarding GNOME using or endorsing a Microsoft derived technology; some users/vendors may not appreciate that, to the point that they may choose to disassociate from the GNOME project * Should applications
Gtk# in the bindings suite
* Should we include Gtk# in the Bindings suite? - short term - it hasn't been proposed for 2.16, but we could grandfather it in - the release management issues have largely been solved, aside from Gtk# not being split between Platform and Desktop (stable and unstable) APIs which is pretty important in terms of ISV/ISD communication and so on - bindings are a very important part of GNOME, and our value proposition - it seems that few people are concerned about Gtk# adopting the release process and other standards, then being included in our Bindings suite - a social/business/non-technical issue may persist regarding GNOME using or endorsing a Microsoft derived technology; some users/vendors may not appreciate that, to the point that they may choose to disassociate from the GNOME project (this shouldn't be dismissed out of hand) Definitely. They're already widely used and they seem to be mature enough to be included in the suite. I cannot se a reason why they shouldn't if they follow the bindings/platform stability rules and are prepared to follow the release schedule. Johan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gtk# in the bindings suite
* Should we include Gtk# in the Bindings suite? - short term - it hasn't been proposed for 2.16, but we could grandfather it in It was proposed actually: http://mail.gnome.org/archives/desktop-devel-list/2006-April/msg00457.html -- Dan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
Hi Jeff, Le samedi 22 juillet 2006, à 00:03, Jeff Waugh a écrit : * Should we include Gtk# in the Bindings suite? - short term - it hasn't been proposed for 2.16, but we could grandfather it in It has been proposed, IIRC :-) - the release management issues have largely been solved, aside from Gtk# not being split between Platform and Desktop (stable and unstable) APIs which is pretty important in terms of ISV/ISD communication and so on - bindings are a very important part of GNOME, and our value proposition - it seems that few people are concerned about Gtk# adopting the release process and other standards, then being included in our Bindings suite - a social/business/non-technical issue may persist regarding GNOME using or endorsing a Microsoft derived technology; some users/vendors may not appreciate that, to the point that they may choose to disassociate from the GNOME project (this shouldn't be dismissed out of hand) Yes, we should: we want to let people use their preferred languages to develop applications that integrate in GNOME. * Should we include Tomboy in the Desktop suite? (completely independently from the fact that it uses Gtk#/Mono) - short term - it has been proposed for 2.16 - does it *need* to go in the Desktop suite at all? (genuine question, it may not be necessary to include Tomboy in the Desktop suite to achieve Tomboy's goals) I'm sorry, I'm not sure I understand this point. It might help to know what are Tomboy's (or Alex's) goals first :-) - if we say yes here, we depend on the next question (but short term, the next question only starts to matter if we say yes here!) I'm mixed about tomboy, but mainly because I can't seem to get used to it ;-) Tomboy has been praised for a long time by a lot of people. This is a good point for it. * Should Gtk#/Mono applications be accepted into the Desktop suite? - short to medium term - pathological case of 'Desktop suite pressure' (everyone wants their stuff in the Desktop suite because that's how you become enfranchised) - performance (memory and cpu) is a red herring here; we all *know* that we want to start using higher level languages for writing amazing GNOME software, so whether it's Gtk#/Mono, Python, Java, Perl or Brainfuck, we fully acknowledge that we're taking a hit for developer productivity and our ability to deliver awesome software to users. very few pieces of the software on the radar for proposal are central, 'always-on' elements of the desktop experience (think f-spot vs. beagle). performance will be an important metric for inclusion of any software, but it needs to be done on a case by case basis, not from a dogmatic perspective about competing platforms or the idea of using higher level languages at all. that horse has well and truly bolted! - can we resolve the dissonance between delivering a coherent Desktop (a goal of the Desktop suite) and suggesting that vendors deliver multiple vm/language/binding/runtime platforms to satisfy it, and demand that users stomach it too? (this has also been raised as a performance issue) - a social/business/non-technical issue may persist regarding GNOME using or endorsing a Microsoft derived technology; some users/vendors may not appreciate that, to the point that they may choose to disassociate from the GNOME project You forgot Alvaro's feeling that GNOME is a platform and adding dependency on another platform might not make sense from a consistency point of view. (Point four is similar, but it's not the same.) We don't have to talk about the other items now. If we do, it'll just make yet another huge thread without real conclusions... Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
On lør, 2006-07-22 at 00:03 +1000, Jeff Waugh wrote: - a social/business/non-technical issue may persist regarding GNOME using or endorsing a Microsoft derived technology; some users/vendors may not appreciate that, to the point that they may choose to disassociate from the GNOME project (this shouldn't be dismissed out of hand) There are also those amongst the users who are getting royally tired of this debate, we want to contribute and we want to do it using Mono. I'm personally getting to the point where if a decision is not made as to whither or not I will be allowed the freedom to develop for my desktop of choice in my language of choice I'll go on a puppy killing spree. The point being the issue goes both ways, if we keep Mono as the bastard child of the platform a lot of upcoming developers will get tired of waiting and seek other pastures. - David Nielsen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
quote who=Vincent Untz - does it *need* to go in the Desktop suite at all? (genuine question, it may not be necessary to include Tomboy in the Desktop suite to achieve Tomboy's goals) I'm sorry, I'm not sure I understand this point. It might help to know what are Tomboy's (or Alex's) goals first :-) It's the same thing as does Inkscape *need* to go in the Desktop suite at all? - there are all kinds of reasons for and against this from both sides (maintainer and suite). - can we resolve the dissonance between delivering a coherent Desktop (a goal of the Desktop suite) and suggesting that vendors deliver multiple vm/language/binding/runtime platforms to satisfy it, and demand that users stomach it too? (this has also been raised as a performance issue) You forgot Alvaro's feeling that GNOME is a platform and adding dependency on another platform might not make sense from a consistency point of view. (Point four is similar, but it's not the same.) Yeah, I was attempting to summarise that in point 4, though understanding that it was heavily conflated with the long term platform story. Shipping something in the Desktop suite doesn't imply supporting the platform (cf. Aisleriot), so there's some flexibility here. - Jeff -- linux.conf.au 2007: Sydney, Australia http://lca2007.linux.org.au/ Basically my philosophy on release management is that it should be like police brutality. - Maciej Stachowiak ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: What about Embedded?
Hello, Mono has been successfully used in embedded systems of different sorts. Examples? Or are we just talking about some guy who got it working once? Confidential, paying commercial customers. All we can say is that the PowerPC port was paid by them. Maemo are not using Python yet as far as I can tell. They would like to support it as a development environment, and maybe then use it for their own core stuff. But it needs some performance/memory/code-size work. Yeah, but users are. And they have been for a long time in the pre-Maemo GPE days. ___ 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!]
Alex Graveley alex at beatniksoftware.com writes: * Scripting framework Allows apps to easily expose external scripting and event notification. D-BUS was the big missing piece here. Can specify sets of interfaces for common tasks that apps can implement, and building up the frameworks to provide useful default implementations. That was the subject of my talk at Desktop Developer Conference (this minor conference that was earlier this week like evey year since 2004), were I proposed ideas toward a *cross desktop* implementation of such a framework. The people from KDE I did talk too were there are higly interested in such a feature. DBus for this framework would just be an IPC mechanism, and not the object model. I'll post the slide sometime next week when I actually have time to do so, but I certainly want to push an idea like that to be implemented. Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
Jeff Waugh wrote: Ni hao, (Wow, this took a long time to write. Sorry!) [...] Thanks, Please, could we (if possible) answer every point in a separate thread (like jdahlin began to do) to try and keep things clear ? Otherwise the new debate will be likely to turn into a nameless mess like the previous one. Thank you. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: What about Embedded?
On 7/20/06, David Nielsen [EMAIL PROTECTED] wrote: tor, 20 07 2006 kl. 23:24 +0100, skrev Jamie McCracken: The D language offers the best of all worlds IMO *without* compromising on speed, resource usage or bloat. It would be madness to use a VM instead! (of course its not as integrated into Gnome yet and lacks an IDE but if someone puts the work in you will have a killer platform than no VM based platform can match) ... in about 10 years, once D exits beta and someone sits down to write a proper IDE, the bindings, etc.. Mono is here now, it has basically all the tools we want, the Mono maintainers care about GNOME and as an added bonus we get to market GNOME to all the college students who are currently being trained with .NET in mind. I think this is a good point. I have just spent my gap year developing a C# app for Windows, not because I wanted to use that platform but because that was what my employer specified. It was ridiculously easy to learn (because of the number of help/tutorials/examples around), and the development speed was incredible. I'm sure this will be the situation for a huge number of young people. As far as I have experienced this year, Microsoft are very good at catching programmers when they are young, giving them very powerful tools that make life very easy, and that they _feel_ they can not do without (I think many people in the community are experienced working without any high level tools, and now find them useful but not essential, whereas increasingly young people are being taught to program with these advanced functions, practically unaware of what to do if they are not available). If you are only developing desktop applications for relatively high end systems (as these people generally are) I think it is fair to say that there are few compelling reasons to learn lower level languages. I reckon C# can act as a bridge that allows people to use what they know already (and the knowledge of a large pool of Windows and Linux programmers) to learn about (some aspects of) programming for Gnome, perhaps learning to write more efficient/low level code later on. The important thing is that they are programming _for gnome_ Embracing these people is a great way to get more developers, fresh ideas and new and diverse applications. Who ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
On Sat, 2006-07-22 at 00:03 +1000, Jeff Waugh wrote: * Should applications built with anything in the Bindings suite be accepted into the Desktop suite? - short to medium term - do we want the central components of our software to potentially be written in five to ten different languages and/or runtimes/platforms? - this leads very neatly into the next question * Is it time to redefine the suites and/or 'franchise' the release process? - medium term - this is not just about new suites, it's about redefining the current Desktop suite by its integration interfaces and central components; we need to make current suites serve us better before kicking off new stuff - http://perkypants.org/blog/2005/05/19/1116533413/ (last few paras) - start slow: don't even create new suites to begin with, just make sure the small number of apps that want to adopt our process and standards right now can do so - new/further governance of suites can come later Regarding just the above two issues: What if there is a bilateral subdivision of the desktop suite which helps *distributors* distinguish between applications that support being compiled AOT (C, C++, Mono AOT, Java GCJ, D?) and applications that run JIT'd/VM'd (Mono JIT, Java JRE, Python, Ruby, Perl). It seems to me that, at least conceptually if not technically, the division between the two camps above is one of AOT/native compilation versus JIT/VM'd/interpreted compilation. Notice that both Java and Mono could be in either camp depending on how the project's Makefiles are written ... in both the Mono AOT and Java GCJ cases, libraries in use are shared between processes. Execution performance is also (generally) higher. It would be interesting to get Miguel's take on whether or not Mono AOT usage should be encouraged. In the Java GCJ case, it is encouraged for use by its authors. 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: Gtk# in the bindings suite
On Fri, 2006-07-21 at 11:09 -0300, Johan Dahlin wrote: * Should we include Gtk# in the Bindings suite? - short term - it hasn't been proposed for 2.16, but we could grandfather it in - the release management issues have largely been solved, aside from Gtk# not being split between Platform and Desktop (stable and unstable) APIs which is pretty important in terms of ISV/ISD communication and so on - bindings are a very important part of GNOME, and our value proposition - it seems that few people are concerned about Gtk# adopting the release process and other standards, then being included in our Bindings suite - a social/business/non-technical issue may persist regarding GNOME using or endorsing a Microsoft derived technology; some users/vendors may not appreciate that, to the point that they may choose to disassociate from the GNOME project (this shouldn't be dismissed out of hand) Definitely. They're already widely used and they seem to be mature enough to be included in the suite. I cannot se a reason why they shouldn't if they follow the bindings/platform stability rules and are prepared to follow the release schedule. 100% agree. I don't know C# and prefer Python for RAD, but Gtk# is well tested, well maintained, well documented and well used. There is no reason why they should not be in Bindings. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF 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: Putting the 'Mono debate' back on the rails
On Sat, 2006-07-22 at 00:03 +1000, Jeff Waugh wrote: * Should we include Gtk# in the Bindings suite? - the release management issues have largely been solved, aside from Gtk# not being split between Platform and Desktop (stable and unstable) APIs which is pretty important in terms of ISV/ISD communication and so on I have resisted this split, and I think the above statement gets to the heart of my issue. There is this idea that it is not possible to guarantee API stability for bindings of Desktop libraries. We (Gtk#) have made no stability exceptions for these APIs to our users. That may seem insane to some. It may make us jump through some additional hoops down the road, if the desktop developers choose to exercise their prerogative to break things. However, it has not been an issue for us to this point. We bind six libraries that fall in the desktop set currently. I cannot split out three of them because the APIs are included in gnome-sharp.dll currently, and to split them out would break API compat for my users. Those are libgnomeprint, libgnomeprintui, and libpanelapplet. The first two are unlikely to have API breakage, since they are basically deprecated by Gtk 2.10. libpanelapplet is a very small exposed API for us. If splitting these APIs out is a requirement, we can remove Gtk# from consideration now. The remaining three, rsvg, vte, and gtkhtml have not proven problematic. The small portion of gtkhtml that we bind has not changed since 3.10. We have not updated the version of rsvg or vte since Gtk# 1.0, and have had no reports of breakage against newer installed versions. We currently have a policy that only Gnome Platform libraries will be considered for inclusion going forward. Since I am already committed to maintaining API stability in the existing bindings, and that seems to be the crux of the No non-platform bindings rule, I still think it should be reasonable to allow Gtk# into the bindings release as is. Hopefully that helps explain why I resist when people continue to tell me I must split up the binding to remove these unstable libraries. The resulting split would provide users no additional guarantees, would require more work on my part and for packagers and users, and would theoretically break deployed applications if upgrading Gtk# started removing installed binaries. -- Mike Kestner [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Tomboy in Desktop
quote who=Jeff Waugh * Should we include Tomboy in the Desktop suite? (completely independently from the fact that it uses Gtk#/Mono) Hi, Here's my point of view, completely independent from the fact that Tomboy is built with Gtk#/Mono. Here it is in point form, because I seem to be doing pretty well with it: * Without a doubt, Tomboy is pure awesome. * Alex says that Tomboy doesn't replace Sticky Notes, he doesn't really want to migrate Sticky Notes data into Tomboy, and that Tomboy and Sticky Notes suit different use cases. * In my experience, users perceive Tomboy and Sticky Notes to fulfill the same (or similar) function. * We need a thrilling ecosystem of software that Works With GNOME! * We don't have to integrate *everything* into the Desktop suite. That was never its purpose. The Desktop suite is all about the OOTB (out of the box) desktop user experience. * Innovation doesn't have to be jammed into the Desktop suite because we haven't found anywhere else to put it. We have to curtail this idea that the Desktop suite is the be-all and end-all of GNOME. * If Alex wants to adopt the GNOME release cycle and strategy for Tomboy, that's *fantastic*... but we can approach that differently. * Let's give our users the ability to discover and cherish awesome third party software for GNOME. If we suck the known universe into the Desktop suite, our users won't be able to have that experience. * This is *not* meant to disenfranchise Tomboy or Alex, or make it seem as if Tomboy is a 'second class citizen' - far from it. Tomboy can be one of the first targets for us to fix that perception. Be GNOME, not Be in GNOME. Thanks, - Jeff -- linux.conf.au 2007: Sydney, Australia http://lca2007.linux.org.au/ The ability to procrastinate is what separates us from the machines. - Chris Gregory, Desktop Magazine ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
bug-buddy support
I noticed that bug-buddy refuses to file bugs against a number of core desktop applications (I just found yelp and evince). I think we should make an effort to ensure that all core desktop apps have the necessary information in their .desktop files by 2.16. Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: bug-buddy support
On Fri, 2006-07-21 at 12:35 -0400, Matthias Clasen wrote: I noticed that bug-buddy refuses to file bugs against a number of core desktop applications (I just found yelp and evince). I think we should make an effort to ensure that all core desktop apps have the necessary information in their .desktop files by 2.16. I just noticed this as well. See bug #347679. Pardon my ignorance as I have just become the maintainer but, when did this change and what needs to be done? 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: Tomboy in Desktop
Jeff Waugh wrote: * Without a doubt, Tomboy is pure awesome. * We don't have to integrate *everything* into the Desktop suite. That was never its purpose. The Desktop suite is all about the OOTB (out of the box) desktop user experience. I don't get it. Don't we want the out of the box desktop user experience to be pure awesome? -- Dan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Tomboy in Desktop
quote who=Dan Winship Jeff Waugh wrote: * Without a doubt, Tomboy is pure awesome. * We don't have to integrate *everything* into the Desktop suite. That was never its purpose. The Desktop suite is all about the OOTB (out of the box) desktop user experience. I don't get it. Don't we want the out of the box desktop user experience to be pure awesome? You snipped out salient points between those two, and hinged the awesomeness of the Desktop suite on Tomboy's inclusion (it's already awesome - we don't need to jam everything in it to make it so). My answer to this is already in the list. :-) - Jeff -- linux.conf.au 2007: Sydney, Australia http://lca2007.linux.org.au/ I rather think of Pat as our linguistic ornithologist here - 'Oh look, the brown noddy also nests in the mangrove!' - John Fleck ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Bug buddy maintainer? (Was Re: bug-buddy support)
Matthias Clasen wrote: On 7/21/06, Jason D. Clinton [EMAIL PROTECTED] wrote: On Fri, 2006-07-21 at 12:35 -0400, Matthias Clasen wrote: I noticed that bug-buddy refuses to file bugs against a number of core desktop applications (I just found yelp and evince). I think we should make an effort to ensure that all core desktop apps have the necessary information in their .desktop files by 2.16. I just noticed this as well. See bug #347679. Pardon my ignorance as I have just become the maintainer but, when did this change and what needs to be done? See, this is something that I would have expected the bug-buddy maintainers to announce to desktop-announce-list when they made these changes... When I was hacking on bug-buddy a few months ago, I noticed that it uses the gmenu API to find and add applications for which it reports bugs. Unfortunately, this causes problems for programs which are not included in the menus (like evince and yelp). I don't know if this is how bug-buddy worked with 2.14.0 or what, but I agree this is a rather large problem. One solution is to include our own bug-buddy.menu file without any filters, but this doesn't solve the issue for applications with NoDisplay=true in the .desktop file as I don't believe the gmenu API returns these applications. Bug-buddy is pretty much maintainerless from what I can tell - Fer is not very active, and I have my hands full with Yelp. Is there someone out there that would be interested in taking bug-buddy by both reins? -- Brent Smith [EMAIL PROTECTED] IRC: smitten / #docs / irc.gnome.org ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
On Fri, 21 Jul 2006, Jason D. Clinton wrote: On Sat, 2006-07-22 at 00:03 +1000, Jeff Waugh wrote: * Should applications built with anything in the Bindings suite be accepted into the Desktop suite? - short to medium term - do we want the central components of our software to potentially be written in five to ten different languages and/or runtimes/platforms? - this leads very neatly into the next question * Is it time to redefine the suites and/or 'franchise' the release process? - medium term - this is not just about new suites, it's about redefining the current Desktop suite by its integration interfaces and central components; we need to make current suites serve us better before kicking off new stuff - http://perkypants.org/blog/2005/05/19/1116533413/ (last few paras) - start slow: don't even create new suites to begin with, just make sure the small number of apps that want to adopt our process and standards right now can do so - new/further governance of suites can come later Regarding just the above two issues: What if there is a bilateral subdivision of the desktop suite which helps *distributors* distinguish between applications that support being compiled AOT (C, C++, Mono AOT, Java GCJ, D?) and applications that run JIT'd/VM'd (Mono JIT, Java JRE, Python, Ruby, Perl). It seems to me that, at least conceptually if not technically, the division between the two camps above is one of AOT/native compilation versus JIT/VM'd/interpreted compilation. I don't think this is an item worth dividing on. For languages like Mono (and Java with GCJ), the compile or JIT (for Mono) or interp (for GCJ) is purely a case-by-case performance decision. Notice that both Java and Mono could be in either camp depending on how the project's Makefiles are written ... in both the Mono AOT and Java GCJ cases, libraries in use are shared between processes. Execution performance is also (generally) higher. The statement that performance is generally higher isn't quite correct. However, it's completely besides the point for this discussion. It would be interesting to get Miguel's take on whether or not Mono AOT usage should be encouraged. In the Java GCJ case, it is encouraged for use by its authors. Again, completely besides the point. The decision to AOT would be based on measurements. It doesn't address any of the issues in Jeff's email. -- Ben ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
consistency (or lack thereof)
Most of the control-center capplets are immediate-apply (except for ones which have very good reason not to be), and all of then have a Close button. All ? No, not all. The background capplet considers it better to have a Finish button instead... I have asked to fix this, but I have been told that user testing showed that Close is wrong there... So, what now ? Do we suddenly change all our close buttons to finish buttons ? Or do we embrace inconsistency in the name of user testing ? Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Bug buddy maintainer? (Was Re: bug-buddy support)
On ven, 2006-07-21 at 11:28 -0600, Brent Smith wrote: NoDisplay=true in the .desktop file as I don't believe the gmenu API returns these applications. Since gnome-menus 2.13.5 there is a GMENU_TREE_FLAGS_INCLUDE_NODISPLAY flag allowing to do that Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Bug buddy maintainer? (Was Re: bug-buddy support)
On ven, 2006-07-21 at 11:28 -0600, Brent Smith wrote: Unfortunately, this causes problems for programs which are not included in the menus (like evince and yelp) I've attached a patch to bug #347422 that fixes that issue Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: consistency (or lack thereof)
2006/7/21, Matthias Clasen [EMAIL PROTECTED]: Most of the control-center capplets are immediate-apply (except for ones which have very good reason not to be), and all of then have a Close button. All ? No, not all. The background capplet considers it better to have a Finish button instead... I have asked to fix this, but I have been told that user testing showed that Close is wrong there... Unless the user testing told that Finish is right there, I'd go for consistency until a know right text is found. Or just dump the button and rely on the window manager (yeah, IIRC user testing proved that one wrong too...). -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: consistency (or lack thereof)
On Sex, 2006-07-21 at 13:42 -0400, Matthias Clasen wrote: Most of the control-center capplets are immediate-apply (except for ones which have very good reason not to be), and all of then have a Close button. All ? No, not all. The background capplet considers it better to have a Finish button instead... I have asked to fix this, but I have been told that user testing showed that Close is wrong there... So, what now ? Do we suddenly change all our close buttons to finish buttons ? Or do we embrace inconsistency in the name of user testing ? No, please let's fix this. Besides the lack of consistency with other capplets, it makes absolutely no sense at all to have a Finish button, especially since it uses the stock icon for Apply. This is very confusing even for me because I think this is an apply button with a different wording: I have to click on it for settings to be saved; or, if I don't click on it, my changes are reverted. Of course none of those are true. The Finish button only makes sense in a task-oriented interface. It makes some sense when using the Change Desktop Background desktop popup menu, because it is worded like a task description. It makes no sense when accessing the same preference through Preferences-Desktop Background. This highlights another inconsistency: Change Desktop Background in the desktop popup menu should be Desktop Background Properties instead. Regards, -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
On Fri, 2006-07-21 at 13:39 -0400, Ben Maurer wrote: I don't think this is an item worth dividing on. For languages like Mono (and Java with GCJ), the compile or JIT (for Mono) or interp (for GCJ) is purely a case-by-case performance decision. ... The statement that performance is generally higher isn't quite correct. However, it's completely besides the point for this discussion. ... Again, completely besides the point. The decision to AOT would be based on measurements. It doesn't address any of the issues in Jeff's email. Well I respectfully disagree and I find your statements that my statements don't address any issues raised by Jeff very puzzling as they were specifically influenced by the framing Jeff did in the issue directly above the two I quoted. Quoth Jeff: * Should Gtk#/Mono applications be accepted into the Desktop suite? ... - performance (memory and cpu) is a red herring here; we all *know* that ... - can we resolve the dissonance between delivering a coherent Desktop (a goal of the Desktop suite) and suggesting that vendors deliver multiple vm/language/binding/runtime platforms to satisfy it, and demand that users stomach it too? (this has also been raised as a performance issue) You are, of course, welcome to disagree with my suggestion. I have no idea if it's a good one or not but I thought it was worth bringing up. I think that inventivizing projects to push toward an AOT approach could be one way to help allay the people pounding their fists over the perceived performance of the desktop OOTB. 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: Putting the 'Mono debate' back on the rails
On Fri, 21 Jul 2006, Jason D. Clinton wrote: On Fri, 2006-07-21 at 13:39 -0400, Ben Maurer wrote: I don't think this is an item worth dividing on. For languages like Mono (and Java with GCJ), the compile or JIT (for Mono) or interp (for GCJ) is purely a case-by-case performance decision. ... The statement that performance is generally higher isn't quite correct. However, it's completely besides the point for this discussion. ... Again, completely besides the point. The decision to AOT would be based on measurements. It doesn't address any of the issues in Jeff's email. Well I respectfully disagree and I find your statements that my statements don't address any issues raised by Jeff very puzzling as they were specifically influenced by the framing Jeff did in the issue directly above the two I quoted. Quoth Jeff: * Should Gtk#/Mono applications be accepted into the Desktop suite? ... - performance (memory and cpu) is a red herring here; we all *know* that ... - can we resolve the dissonance between delivering a coherent Desktop (a goal of the Desktop suite) and suggesting that vendors deliver multiple vm/language/binding/runtime platforms to satisfy it, and demand that users stomach it too? (this has also been raised as a performance issue) You are, of course, welcome to disagree with my suggestion. I have no idea if it's a good one or not but I thought it was worth bringing up. I think that inventivizing projects to push toward an AOT approach could be one way to help allay the people pounding their fists over the perceived performance of the desktop OOTB. AOT is *not* always faster. There are lots of variables. For example, at JIT time, the compiler can make some assumptions that AOT can not (for example, if you have a static readonly field [static final in java], JITs can inline the constant value because it will never change. AOT can't do this because the value is computed in the static constructor). In some cases, AOT can incresae startup time becasue the assembly used by CPUs is generally larger than the IL in a JIT. In these cases, it can be *faster* to compile than it is to read more from the disk see: http://blogs.msdn.com/ricom/archive/2004/10/18/244242.aspx for a bit about this. We should encourage performance. However, making divisions based on specific optimization techniques is the wrong direction. Also, getting off track and talking about specific optimization techniques while making high level decisions isn't going to help. If you want to talk more about AOT in Mono (or other runtimes), this is simply not the list to do it. -- Ben ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
On Fri, 2006-07-21 at 14:20 -0400, Ben Maurer wrote: AOT is *not* always faster. There are lots of variables. For example, at JIT time, the compiler can make some assumptions that AOT can not (for example, if you have a static readonly field [static final in java], JITs can inline the constant value because it will never change. AOT can't do this because the value is computed in the static constructor). We're goin' way off topic. Let me point you back to me first email: the project's Makefiles are written ... in both the Mono AOT and Java GCJ cases, libraries in use are shared between processes. Execution The benefit of AOT that I am emphasizing here is shared libraries and the amount of memory which would be saved - especially in the Java case. Any gains (or not) in execution speed would just be a nice side effect. 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: consistency (or lack thereof)
On Fr, 2006-07-21 at 13:42 -0400, Matthias Clasen wrote: Most of the control-center capplets are immediate-apply (except for ones which have very good reason not to be), and all of then have a Close button. All ? No, not all. The background capplet considers it better to have a Finish button instead... I have asked to fix this, but I have been told that user testing showed that Close is wrong there... So, what now ? Do we suddenly change all our close buttons to finish buttons ? Or do we embrace inconsistency in the name of user testing ? We have had an argument about this in #gnome-de some time in the past, I'll repeat my opinion here. Well, the HIG say Close IIRC, so, I think everything should be the way the HIG say. The question Finish vs. Close should not be a control-center specific question but a HIG-specific question on the usability list. Regards, Sven ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Bug buddy maintainer? (Was Re: bug-buddy support)
On 7/21/06, Brent Smith [EMAIL PROTECTED] wrote:
Bug-buddy is pretty much maintainerless from what I can tell - Fer is
not very active, and I have my hands full with Yelp. Is there someone
out there that would be interested in taking bug-buddy by both reins?
Well, here it's Fer :)
I am sorry about the non-regular releases of bug-buddy (as well as
gconf-editor and gnome-keyring-manager) during last months.
As some of you know I move to Helsinki a month and a half ago. My home
computer arrived last week, and my home DSL connection is coming in 10
days. Also I hope to get proper access to {cvs,svn}.gnome.org at work
soon.
Anyway, I did my best to get new bug-buddy interface and internal
ready for 2.16, after the great work from Olav in bugzilla.gnome.org
and lot of help from Brent. I am sorry about breaking the command line
interface that yelp and other applications were using (it's a
developer release!) and will try to fix it ASAP. Of course, any help
with bug-buddy (as with any other module in GNOME) is very welcome.
Fer, from a mobile phone connection.
Salu2
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Bug buddy maintainer? (Was Re: bug-buddy support)
On Fri, 2006-07-21 at 21:06 +0200, Fernando Herrera wrote: Anyway, I did my best to get new bug-buddy interface and internal ready for 2.16, after the great work from Olav in bugzilla.gnome.org and lot of help from Brent. I am sorry about breaking the command line interface that yelp and other applications were using (it's a developer release!) and will try to fix it ASAP. Of course, any help with bug-buddy (as with any other module in GNOME) is very welcome. Besides the command line changes, what else must be done? 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: Bug buddy maintainer? (Was Re: bug-buddy support)
On 7/21/06, Jason D. Clinton [EMAIL PROTECTED] wrote: On Fri, 2006-07-21 at 21:06 +0200, Fernando Herrera wrote: Anyway, I did my best to get new bug-buddy interface and internal ready for 2.16, after the great work from Olav in bugzilla.gnome.org and lot of help from Brent. I am sorry about breaking the command line interface that yelp and other applications were using (it's a developer release!) and will try to fix it ASAP. Of course, any help with bug-buddy (as with any other module in GNOME) is very welcome. Besides the command line changes, what else must be done? You need to add something to the .desktop file to convince bug-buddy to consider your app. Check out a desktop file of an app that bug-buddy does recognize for the details. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Bug buddy maintainer? (Was Re: bug-buddy support)
On Fri, 2006-07-21 at 15:20 -0400, Matthias Clasen wrote: You need to add something to the .desktop file to convince bug-buddy to consider your app. Check out a desktop file of an app that bug-buddy does recognize for the details. I do appreciate your help but I was hoping for something a little more definitive. What is it? Which parts are mandatory? Optional? How long has it been there? Is it going to change again? Does it need to be translated? 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: Bug buddy maintainer? (Was Re: bug-buddy support)
On 7/21/06, Matthias Clasen [EMAIL PROTECTED] wrote: On 7/21/06, Jason D. Clinton [EMAIL PROTECTED] wrote: On Fri, 2006-07-21 at 21:06 +0200, Fernando Herrera wrote: Anyway, I did my best to get new bug-buddy interface and internal ready for 2.16, after the great work from Olav in bugzilla.gnome.org and lot of help from Brent. I am sorry about breaking the command line interface that yelp and other applications were using (it's a developer release!) and will try to fix it ASAP. Of course, any help with bug-buddy (as with any other module in GNOME) is very welcome. Besides the command line changes, what else must be done? You need to add something to the .desktop file to convince bug-buddy to consider your app. Check out a desktop file of an app that bug-buddy does recognize for the details. Yeah, they are: [example for gnome-calculator .desktop file] X-GNOME-Bugzilla-Bugzilla=GNOME X-GNOME-Bugzilla-Product=gcalctool X-GNOME-Bugzilla-Component=general X-GNOME-Bugzilla-OtherBinaries=gnome-calculator and they were needed for bug-buddy for years. However when I merged the new xmlrpc branch I added a little utility on bug-buddy/src for verifying installed applications. Running it on my laptop (jhbuild gnome 2.16 moduleset) complains about these applications missing X-GNOME-Bugzilla info (only for those applicatrions having a Categories=GNOME in the .desktop file): gnome-nettool evolution-2.6 However this tool is not checking that the product/component stored in .desktop file actually matches anything in bugzilla server (for example gnome-panel one is broken right now). To solve this problem (outdated .desktop file product/component after bugzilla renaming, for example) we were planning (Olav, correct me if I am wrong here) to have some kind of fallback matching magic on our bugzilla server Salu2 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Bug buddy maintainer? (Was Re: bug-buddy support)
On 7/21/06, Jason D. Clinton [EMAIL PROTECTED] wrote: On Fri, 2006-07-21 at 15:20 -0400, Matthias Clasen wrote: You need to add something to the .desktop file to convince bug-buddy to consider your app. Check out a desktop file of an app that bug-buddy does recognize for the details. I do appreciate your help but I was hoping for something a little more definitive. What is it? Which parts are mandatory? Optional? How long has it been there? Is it going to change again? Does it need to be translated? I don't know any of this. And I guess we are not alone in this... ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
[Fwd: Re: Bug buddy maintainer? (Was Re: bug-buddy support)]
Here is the information everyone needs. Apparently mistakenly sent only to me. ---BeginMessage--- Hi, On 7/21/06, Jason D. Clinton [EMAIL PROTECTED] wrote: I do appreciate your help but I was hoping for something a little more definitive. What is it? Metainformation about the application used to report bugs on out BTS Which parts are mandatory? Optional? X-GNOME-Bugzilla-Bugzilla=GNOME -- Mandatory X-GNOME-Bugzilla-Product=XXX --Mandatory X-GNOME-Bugzilla-Component=YYY -- Mandatory X-GNOME-Bugzilla-OtherBinaries=ZZZ -- Optional, only if you application has several binaries X-GNOME-Bugzilla-Version=X.Y.Z -- Optional, and should need expansion from configure script, so if you want this you need a application.desktop.in.in to expand here @VERSION@ (application.desktop.in is used by intltool for translations). How long has it been there? circa 2002 Is it going to change again? No and yes. If you refer at the field names, they haven't changed since 2002 (X-GNOME-Bugzilla-Version was added on 2003). If you mean the values, bugzilla product/component could be changed if the maintainer ask the bugmaster to do it and should update the info in the desktop file after the change. As I mentioned on a previous email, afer this product/component renaming would break any old instalation of the application for submiting bugs, but we are working on a server side fallback to solve it. Does it need to be translated? Hope this helps. Salu2 ---End Message--- 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: consistency (or lack thereof)
Op Fri, 21 Jul 2006 20:51:12 +0200, schreef Sven Herzberg: We have had an argument about this in #gnome-de some time in the past, I'll repeat my opinion here. Maybe you had it in #gnome-de, but it was definitely discussed on this list or the usability list too (it's too hot now to go look it up). Ask dobey for the details, but IIRC Novell user testing showed convincingly that a majority of test subjects didn't know/expect that Close would save their changes. Therefore, first it was made explicit-apply but after a storm of protest, it became instant apply again but with different wording. So if we want to make things consistent, we should consider making every instant-apply Close button a Finish button instead. Well, the HIG say Close IIRC, so, I think everything should be the way the HIG say. The HIG is a set of guidelines that are evolving, they are not set in stone. regards, -- Reinout van Schouwen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: consistency (or lack thereof)
Matthias Clasen wrote: Most of the control-center capplets are immediate-apply (except for ones which have very good reason not to be), and all of then have a Close button. All ? No, not all. The background capplet considers it better to have a Finish button instead... I have asked to fix this, but I have been told that user testing showed that Close is wrong there... So, what now ? Do we suddenly change all our close buttons to finish buttons ? Or do we embrace inconsistency in the name of user testing ? I think there are a number of ways you could interpret the results of that user study. A user stating that 'Close' didn't make them think that their changes would be saved could mean that you change the button from 'close' to 'finish' or 'save' or 'done'. But you could also do lots of other things to ensure that a person feels their changes in the background capplet are saved. I think it would be advantageous and fair for people to discuss the root problem and prototype the changes, then decide the right change that other capplets could take advantage of. It seems hasty and incorrect to just change the one capplet and not the others, did user testing show that people felt the other capplets were saving even with only a close button? ~ Bryan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: consistency (or lack thereof)
On 7/21/06, Reinout van Schouwen [EMAIL PROTECTED] wrote: So if we want to make things consistent, we should consider making every instant-apply Close button a Finish button instead. Well, the HIG say Close IIRC, so, I think everything should be the way the HIG say. The HIG is a set of guidelines that are evolving, they are not set in stone. The correct way is then to bring it up to the HIG and say User testing shows XYZ. Once it is changed in the HIG then all relevent things can be changed and consistency is maintained. The incorrect way is this way, change one, and then leave it there. iain ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Tomboy in Desktop
lør, 22 07 2006 kl. 02:33 +1000, skrev Jeff Waugh: quote who=Jeff Waugh * Should we include Tomboy in the Desktop suite? (completely independently from the fact that it uses Gtk#/Mono) Hi, Here's my point of view, completely independent from the fact that Tomboy is built with Gtk#/Mono. Here it is in point form, because I seem to be doing pretty well with it: * Without a doubt, Tomboy is pure awesome. No argument from me, Tomboy is nothing short of life changing.. praise Alex! * Alex says that Tomboy doesn't replace Sticky Notes, he doesn't really want to migrate Sticky Notes data into Tomboy, and that Tomboy and Sticky Notes suit different use cases. We have a sticky notes application, wow, I haven't seen that exposed in any distro I've used lately. I think it's unlikely that users actually use this without having prior knowledge of it's existence. * In my experience, users perceive Tomboy and Sticky Notes to fulfill the same (or similar) function. To me Tomboy is mostly like Post-it notes-NG, I guess that makes it like sticky notes with the very useful twist that I can link them together. * We need a thrilling ecosystem of software that Works With GNOME! What does this have to do with Tomboy specifically, for now Works with GNOME seems to cover useful applications like Office suites, Music/Photo management, etc - all of which we probably need to do something about like the previously proposed tier system to give the user a certainty that a given application will in fact integrate with GNOME and use the data we expose where suitable - nothing is worse as a user than to install an application and having to configure it by hand because it somehow doesn't know about say e-d-s to get all your buddies or whatever. * We don't have to integrate *everything* into the Desktop suite. That was never its purpose. The Desktop suite is all about the OOTB (out of the box) desktop user experience. Yes and the out of box experience is currently not including several good and valid use cases like management of music and photos, office productivity, Instant messaging. It does however have VoIP and Low level system management this seems like a strange way of targeting a desktop to me, that might not be the case of other people. Having a certified GNOME application project might work as a entry level for GNOME. If we don't integrate everything or provide such a project, then how do we select what use cases cover the core of GNOME, in which case I guess GNOME would be the base libraries and a set of specified services for applications to hook up to. The issue seems to be that we risk turning GNOME into a distro since there's no such thing as a core desktop anymore (was there ever really?) and either we provide an ever increasing set of use cases or we provide a platform for vendors to hook into an have it all abide to the GNOME rules. * Innovation doesn't have to be jammed into the Desktop suite because we haven't found anywhere else to put it. We have to curtail this idea that the Desktop suite is the be-all and end-all of GNOME. Nobody really uses GNOME, everyone uses GNOME + whatever your vendor elects to fill the gaps with. Before we included Evolution everyone used it anyways since distros shipped it with their version of GNOME. The same goes for Rhythmbox and other services. * If Alex wants to adopt the GNOME release cycle and strategy for Tomboy, that's *fantastic*... but we can approach that differently. Tomboy being largely feature complete and stable would need mostly maintenance, this is up to Alex to sign on for though - Ekiga e.g. doesn't follow the GNOME cycle religiously either so long as it works with the desktop we ship and doesn't fall into an unmaintained state Tomboy should be fine. Following the cycle is mostly about: * deploying bugfixes * adopting platform changes * adding required features And being sure that users actually get this supportable version of your software in hand. * Let's give our users the ability to discover and cherish awesome third party software for GNOME. If we suck the known universe into the Desktop suite, our users won't be able to have that experience. And if vendors don't take the time to package these or convince talented users to do so, users won't have that experience either. Regardless my bet is that 99% of all people would just stick with whatever comes with their distro by default. That's the important target for applications that are outside of GNOME CORE, not the desktop release as such. Get in the vendor desktop or your chance of getting users decreases dramatically. * This is *not* meant to disenfranchise Tomboy or Alex, or make it seem as if Tomboy is a 'second class citizen' - far from it. Tomboy can be one of the first targets for us to fix that perception. Be GNOME, not Be in GNOME. Maybe we need to demote a whole lot of stuff instead, make GNOME just
Re: Tomboy in Desktop
Hi, To the first quoted point, I don't recall ever rejecting Sticky Note import. Quite the contrary, I've advocated that we use a first-run import wizard to aid migration. Serendipitously, in recent days, most of the major work for importing has been contributed by Sanford Armstrong in the form of a Tomboy plugin. Sanford's patch adds an item to the Tools menu labeled Import from Sticky Notes. But as this is perhaps not the nicest or most discoverable mechanism I'm trying to figure out how to best integrate this code for a nice experience. Comments welcome. To the second point, I have received very mixed response to the question of Tomboy's replacing of Sticky Notes. And we can see that mails to this list have expressed both points of view, with a slight bias towards the two coexisting (especially from those who actually use one tool or the other). I place myself in the coexist camp, mostly because the interaction models among the two tools are very different (again, Tomboy ain't sticky). A user who is used to Sticky Notes would be very confused if forced to use Tomboy, and vice versa. However, if the release committee believes that enforcing a single note-taking approach is what is best for the desktop, I think it makes sense to choose the solution which is novel, more scalable wrt the number of notes, less intrusive on user activity, supports richer note content, and which opens up possibilities for integration with other parts of the desktop. -Alex Jeff Waugh wrote: * Alex says that Tomboy doesn't replace Sticky Notes, he doesn't really want to migrate Sticky Notes data into Tomboy, and that Tomboy and Sticky Notes suit different use cases. * In my experience, users perceive Tomboy and Sticky Notes to fulfill the same (or similar) function. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Tomboy in Desktop
On Sat, 2006-07-22 at 00:10 +0200, David Nielsen wrote: lør, 22 07 2006 kl. 02:33 +1000, skrev Jeff Waugh: * If Alex wants to adopt the GNOME release cycle and strategy for Tomboy, that's *fantastic*... but we can approach that differently. Tomboy being largely feature complete and stable would need mostly maintenance, this is up to Alex to sign on for though - Ekiga e.g. doesn't follow the GNOME cycle religiously either so long as it works with the desktop we ship and doesn't fall into an unmaintained state Tomboy should be fine. Following the cycle is mostly about: * deploying bugfixes * adopting platform changes * adding required features And being sure that users actually get this supportable version of your software in hand. * letting translators translate, unless the developers want to translate their program into 45 languages. * letting documentation writers write documentation, unless the developers want to do it. There are *many* advantages to a stable release cycle, and a number of those reasons have to do with the fact that the programmers are not the only people producing what we ship. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Tomboy in Desktop
fre, 21 07 2006 kl. 17:57 -0500, skrev Shaun McCance: On Sat, 2006-07-22 at 00:10 +0200, David Nielsen wrote: lør, 22 07 2006 kl. 02:33 +1000, skrev Jeff Waugh: * If Alex wants to adopt the GNOME release cycle and strategy for Tomboy, that's *fantastic*... but we can approach that differently. Tomboy being largely feature complete and stable would need mostly maintenance, this is up to Alex to sign on for though - Ekiga e.g. doesn't follow the GNOME cycle religiously either so long as it works with the desktop we ship and doesn't fall into an unmaintained state Tomboy should be fine. Following the cycle is mostly about: * deploying bugfixes * adopting platform changes * adding required features And being sure that users actually get this supportable version of your software in hand. * letting translators translate, unless the developers want to translate their program into 45 languages. * letting documentation writers write documentation, unless the developers want to do it. There are *many* advantages to a stable release cycle, and a number of those reasons have to do with the fact that the programmers are not the only people producing what we ship. I feel ashamed now.. How could I forget translations when I'm on the Danish team - my bad. I'll go sit in a corner now - David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Tomboy in Desktop
Here's my point of view, completely independent from the fact that Tomboy is built with Gtk#/Mono. Here it is in point form, because I seem to be doing pretty well with it: * Without a doubt, Tomboy is pure awesome. Yes * Alex says that Tomboy doesn't replace Sticky Notes, he doesn't really want to migrate Sticky Notes data into Tomboy, and that Tomboy and Sticky Notes suit different use cases. * In my experience, users perceive Tomboy and Sticky Notes to fulfill the same (or similar) function. This means that Alex (the author of Tomboy) is wrong. Users do not use two different programs to fulfill the same function. Saying otherwise is like saying that konsole and gnome-terminal suit different use cases. They do not, on a GNOME desktop, gnome-terminal whips konsole's butt. * We need a thrilling ecosystem of software that Works With GNOME! Yes. The question is which application do we put in that ecosystem, Tomboy or Sticky Notes? * We don't have to integrate *everything* into the Desktop suite. That was never its purpose. The Desktop suite is all about the OOTB (out of the box) desktop user experience. * Innovation doesn't have to be jammed into the Desktop suite because we haven't found anywhere else to put it. We have to curtail this idea that the Desktop suite is the be-all and end-all of GNOME. Tomboy isn't very innovative. It is just Post IT-notes on the desktop done right. * If Alex wants to adopt the GNOME release cycle and strategy for Tomboy, that's *fantastic*... but we can approach that differently. * Let's give our users the ability to discover and cherish awesome third party software for GNOME. If we suck the known universe into the Desktop suite, our users won't be able to have that experience. The way to do it is to decide what kind of features GNOME should have. Then suck in enough apps to fulfill those features. If there is more than one app that fulfills the same features, choose the BEST one and let the LESS GOOD one stay in the universe. What I'm not so subtly hinting at is that Tomboy is a better application than Sticky Notes. Much better. Sticky Notes is also a good application, but since Tomboy is better the right thing to do is to replace Sticky Notes with Tomboy. We are all technologists, we all love technology and we all want to make GNOME the best desktop there is. So IMHO, from a technological standpoint, the decision is clear. But in reality the discussion isn't clear (which is evident by us discussing it). I think that that thing that is stopping this decision from being clear is very bad because it interferes with the goal of making the best desktop there is. I don't know what the thing is but I'm guessing that it is something like Sticky Notes developer(s) will be disappointed if we drop it. That is unfortunate, but I think that is how it has to be. Better software replace less good software. I hope that in the future many other GNOME components that has potential substitutes will also be judged based on their technical merits: Metacity vs. Compiz Epiphany vs. Firefox Epiphany vs. Galeon Novell's new panel menu vs. The old one Beagle vs. The memory efficient C-coded search thingy Bugzilla vs. 100's of much better bug tracking apps. :) CVS vs. Subversion (already done! Woho!!) Rythmbox vs. Banshee etc... -- mvh Björn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Tomboy in Desktop
Alex Graveley wrote: To the second point, I have received very mixed response to the question of Tomboy's replacing of Sticky Notes. And we can see that mails to this list have expressed both points of view, with a slight bias towards the two coexisting (especially from those who actually use one tool or the other). What about sharing the note storage between the two ? I feel like it's not possible for tomboy to use raw stickynotes data (since it has more information, like title and so on) but what about the other way round ? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Tomboy in Desktop
Notes in Sticky Notes are modal meaning they are all displayed on the screen or they are all hidden. I currently have 307 Tomboy notes :-) -Alex Steve Frécinaux wrote: What about sharing the note storage between the two ? I feel like it's not possible for tomboy to use raw stickynotes data (since it has more information, like title and so on) but what about the other way round ? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: consistency (or lack thereof)
On Jul 22, 2006, at 9:42 AM, Reinout van Schouwen wrote: ... Ask dobey for the details, but IIRC Novell user testing showed convincingly that a majority of test subjects didn't know/expect that Close would save their changes. ... But it *didn't* save their changes, and renaming it to Finish doesn't change that. I can close the window using the button in the title bar instead, or even using xkill, and my new choice of background doesn't revert itself. Anyway, there are several bigger unfixed problems with this window. http://mail.gnome.org/archives/usability/2006-March/msg00213.html -- 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: Bug buddy maintainer? (Was Re: bug-buddy support)
On 7/21/06, Fernando Herrera [EMAIL PROTECTED] wrote: Yeah, they are: [example for gnome-calculator .desktop file] X-GNOME-Bugzilla-Bugzilla=GNOME X-GNOME-Bugzilla-Product=gcalctool X-GNOME-Bugzilla-Component=general X-GNOME-Bugzilla-OtherBinaries=gnome-calculator Can you explain what other values bug-buddy supports for the Bugzilla entry ? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
