Re: Module Proposal: PDF Mod
2010/2/19 Bastien Nocera had...@hadess.net On Thu, 2010-02-18 at 19:39 -0800, Gabriel Burt wrote: I'm not exactly excited to enter a possible flame fest when I'm happy doing my hacking and having users find me and tell me they like the results. But, in case others agree GNOME could benefit from this, I'm proposing PDF Mod for inclusion in GNOME 2.30. Too late for GNOME 2.30, the proposal ended on October 26 last year, see: http://live.gnome.org/TwoPointTwentynine Purpose: a simple tool for doing basic manipulations of PDF documents. It can rotate, move, remove, and extract pages, merge documents, edit their basic metadata (title, author, etc), and extract images. Future feature scope includes being able to change page sizes, and possibly do imposition (prep for printing). I'd say that although useful[1], it doesn't really fit with what people expect from the default applications on a Desktop. I love PDFMod, I find it very useful ad hope to one day see it grow to be a powerful PDF editing tool that retaining it's intuitive simplicity and elegance. I am though not convinced either that this is desktop material, it would help if we had some better idea of what kind of user PDFMod aims to please and what use cases we are aiming at addressing. E.g. I have often found myself reading slides or books in evince and pages of ads are inserted, blank pages or itemized lists being added over several slides which is useful during presentation but when reading the slides often can be annoying. In these cases it would be very useful to be able to call up PDFMod from evince and simply remove them. This doesn't though sound like a sufficiently normal scenerio to warrant presence in the default desktop. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call for a Gnome Media Center
ons, 14 02 2007 kl. 11:02 +, skrev Ross Burton: On Wed, 2007-02-14 at 10:44 +, Emmanuele Bassi wrote: there was a proposal for the desktop places on the wiki: http://live.gnome.org/DesktopPlaces which is entirely doable now that we have an API to access local bookmarks (GBookmarkFile in GLib). applications can install a bookmark for their folder, which has a title that can be translated like we localise schemas for GConf and desktop entries for the menu, and point it to the unlocalised directory on disk: Music - file:///home/ebassi/Music Photos - file:///home/ebassi/Photos So Sound Juicer would install a Music bookmark, right? Rhythmbox and Muine would want to do the same, so what happens here? Would these be physical files so would conflict when packaged? Should the desktop ship a standard set of bookmarks, or should there be some way of merging multiple identical bookmarks. I already consider it a bug that f-spot forces ~/Photos on me, if it becomes the norm to assume that people speak English or even like their interface in English I'd have to dig my eyeballs out or something to bear the pain. There has to be a way to ensure we get proper i18n names on those folders. - David -- Ridicule is the only weapon that can be used against unintelligible propositions. Ideas must be distinct before reason can act upon them.” -Thomas Jefferson 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: New Control Centre
man, 05 02 2007 kl. 19:19 +, skrev Alex Jones: It's slow. Now when I want to quickly get to my sound settings I have to click System, Control Centre... *wait 3 seconds*, figure out where Sound should be and then click that. And then I have an extra window to close when I'm done, which really does annoy me. IMO this was just a proper bad idea. If we had a proper control centre app like Mac OS's then it would be a different story, but this thing is just a glorified application launcher that introduces an unnecessary layer of separation. Down with control centre. I want my menus back. Changing settings just isn't the quick in-and-out-in-5-seconds-flat job it used to be. I agree 100%, I like the idea but the current implementation is extremely slow and it seems pointless since it just launches yet another app. - David Nielsen -- Ridicule is the only weapon that can be used against unintelligible propositions. Ideas must be distinct before reason can act upon them.” -Thomas Jefferson 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: Proposed module: tracker
ons, 10 01 2007 kl. 10:36 +0530, skrev Ritesh Khadgaray: On Mon, 2007-01-08 at 20:26 +, Richard Hughes wrote: Grab some high-up redhat, suse, ubuntu distro people and ask them why they ship beagle by default and not tracker. If you can come up with a convincing argument, and one of the big three [1] start shipping the code then it becomes much easier convincing us difficult-to-please GNOME guys. :-) Out of curiosity, Was tracker around and known when beagle was included ? Generally no. -- Ridicule is the only weapon that can be used against unintelligible propositions. Ideas must be distinct before reason can act upon them.” -Thomas Jefferson signature.asc Description: Dette er en digitalt underskrevet brevdel ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moving spellcheckers into the Gtk+ stack
tor, 07 12 2006 kl. 13:31 +0100, skrev Marco Barisione: Il giorno gio, 07/12/2006 alle 12.28 +0100, Paolo Maggi ha scritto: 2. Include a standard language picker widget. Lots of applications are going to want this, and it's going to become messy if people can't just drop in something. This has applications beyond spell-checking too. I personally feel that it's nicest to check words in the union of selected languages, so that users don't have to micro-manage settings for each UI element that they may potentially be typing in. I agree. For long texts it would be good to have an algorithm to recognize the language of a single paragraph, Microsoft Word does it, but I don't know how it works. So far as we spell check as each word is entered, if we hit above say 90% known in one dictionary then it's probably that language. A good guess is easy to make and will often be correct. Naturally this solution is far from perfect but it should give us a good indication within the first sentence or so. Or am I just spouting bull? - David Nielsen -- Ridicule s the only weapon that can be used against unintelligible propositions. Ideas must be distinct before reason can act upon them.” -Thomas Jefferson signature.asc Description: Dette er en digitalt underskrevet brevdel ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: getting on a longer release cycled
tor, 07 09 2006 kl. 11:24 -0700, skrev David Trowbridge: What in particular isn't possible with the 6-month cycle? I honestly don't think it's about the cycle length as much as the slight fear we seem to have of setting major goals for the project. I doubt we can do Topaz within the comfort of our tried and true 6 month cycle and we do need to decide what Topaz is going to be at some point. As the honorable Jono Bacon put it, he would hate to go to GUADEC 2007 and have Topaz still be something we talked about rather than actually worked on. This is likely to require someone to take the probably unappricated position of Topaz direction manager (or Topaz dictator, asbestosuit included). Basically I think Hub has the right idea but the wrong approach. We need to start thinking about what we want and if that requires us to extend the cycle, do things in parallel or whichever solution we need then we absolutely need to do it. - David Nielsen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New panel layout for GNOME 2.18?
tir, 22 08 2006 kl. 17:53 -0300, skrev theblues gnr: I don't think an usability test has ever been done with the current layout. At least I never heard of one. BetterDesktop seems to have done this, slab is part of the result of those tests. - David Nielsen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module decisions for 2.16
ons, 09 08 2006 kl. 22:55 +0800, skrev Davyd Madeley: On Wed, Aug 09, 2006 at 03:08:40PM +0200, Vincent Untz wrote: On mar, 2006-08-01 at 14:31 -0600, Elijah Newren wrote: + Sticky notes = mostly duplicates functionality of Tomboy = general agreement to deprecate sticky notes for now and remove it in a later release = 'deprecation' means hidden from the user and some kind of warning for those trying to use it Davyd, is there anything we can do to help here, or is this something you can handle? Ok. Here is a suggested migration path. Since some users will not be able to use Tomboy (on systems that are not Mono enabled), we should keep stickynotes around. I propose we do the same as we currently do with mini-commander, that is by default it will transparently upgrade people's stickynotes to tomboy. We then have a --enable-stickynotes flag, that will cause stickynotes to be compiled and installed (installing with this flag will also cause people's whose stickynotes to get upgraded to Tomboy will then cause it to go back again). We then leave it up to package distributors to decide if they want to break this out as a separate package or not. Sound reasonable? To avoid this debate in the future it would be nice if we could come up with a standard protocol for handling application replacements. Aside preserving the users data, deciding how we rid ourselves of the old program is an acceptable fasion would be nice. If we do seperate out the program out with the option to reenable it, then how long do we keep it that way, one cycle, two cycles or more? I mean we definately don't want a situation where such programs sit around forever. We also shouldn't encourage a situation where the norm is as long as it's desired because that means defacto shipping both applications and maintaining them both to a degree forever (there will after all always be a group of users however small that would like to keep a given program). I would favor something general like, --enable-deprecated=application and have the standard be keeping it during the cycle we mark them and the next one, after which they get removed from the shipped product. If someone wants to pick it up and maintain it seperately after scheduled removal then that would be a fine solution for the code rather than death. We might also want to keep a centralised list of items scheduled for removal along with rationale like the kernel does, it seems to work nicely for them so odds are it will be a decent solution for us as well. What kinds of warnings do we want to display to the user or should we leave that to the vendors? If they want to keep an application around telling their users that it will go away would not be the best possible approach. I think it should continue to work as always, a vendor has to take active steps to reenable a given application with the knowledge that it will go away after a given date and as such can take the steps they see fit to either move over to the new application or arrange for maintainership of the old one at their leisure. - David Nielsen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: name change for gnome-volume-manager?
søn, 06 08 2006 kl. 15:43 -0400, skrev Robert Love: On Sun, 2006-08-06 at 19:32 +0100, Alan Horkan wrote: When it was introduced I pointed out that volume is very often associated with audio volume[1] and likely to confuse users - I freely admit it confused me intially - but since it made sense to developers my concerns were dismissed. The reason I was for g-v-m back then, but support the g-d-m (uh-oh, bad acronym!) change now is because the scope of g-v-m has changed from just volumes to all devices. G-v-m is now, in fact, our general policy manager on top of HAL for all hardware. Toward that end, gnome-hardware-manager makes sense, too. Of the proposed names I would personally favor using the term hardware, it's much nicer for users as device has certain techie feel to it. Would there be any sense in merging g-v-m and the preferred application thingy, as a user they seem to serve pretty much the same kind of customization. Then again from there it's not a far cry from saying that the gstreamer setup application and g-p-m could also fit in there and voila we have a control panel - I'm not sure that's entirely desirable. Maybe rethinking where information is displayed would make sense, if we call g-v-m the hardware manager then for all intents and purposes things like the keyboard handler would go in there as well, it is hardware after all. As would the monitor settings and many other things. The whole preferences submenu has always seemed like a mess to me honestly, I would love to see it structured better. It has a feel of having had an item added everytime we got a new feature from somewhere rather than having followed the GNOME way and undergone some UI-fu for sanity and ease of use. - David Nielsen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Baobab
ons, 26 07 2006 kl. 17:47 -0700, skrev Jeff Waugh: quote who=Emmanuele Bassi The GNOME Utilities package is a small package that GNOME has kept since the 1.x era (and before); it provides some application other than baobab, like the screenshoter, the file search dialog, the dictionary and the system log viewer, that are not sufficiently big to warrant their own package but at the same time are considered part of the basic offering of GNOME itself. I think Davyd's question was more about whether Baobab (or its function) is suitable to be considered part of the basic offering of GNOME itself. I am not convinced it should be there myself. It's a nice little tool, however as the user only has access to a subset of the data stored on the system representing data in the manner Baobab does might not be the best option we have. For me the only reason to use such a tool would be if I'm running out of space and I need to find the best place to start the deleting. Now it strikes me that the correct way to handle that use case is: 1) Available diskspace goes below a set limit*, libnotify me that I'm running out of diskspace. 2) The system offers to clean out the trash for me 3) If I'm still not above the limit then we could present the user with some suggestions for files in his homedir that he has never accessed to be moved to tagged for removal. This sounds dangerous but at least we know nobody ever touched them so it might be safer than having him find big files with baobab without a helpful suggestion and just deleting away. I've seen people remove everything except the .exe file from applications on Windows to save space, since that was all they used - much to their surprise it stopped working. Baobab on as a regular user makes little sense, as a sysadmin on a system with a lot of users it would be very handy to spot which users are storing a lot of irrelevant data in their homedir etc. I don't really think it has a place on a regular desktop, it would be most welcome in a administration application set for GNOME along side Sabayon, pessulus and most of gnome-system-tools though. * calculating this limit can be tricky, no one setting will ever hit the mark for all cases. The reserved block feature in ext3 is a perfect example of how not to do this. ___ 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
man, 24 07 2006 kl. 16:47 +0100, skrev [EMAIL PROTECTED]: Iain * wrote: The other example is gstreamer, I am sure they can share with us whether their decision to go with parallel-installable version of 0.8 and 0.10 was a pleasant exercise. Of course they were facing similar situations as is now. Speaking as aGStreamer application author and user, it was very pleasent. It allowed me to use applications that had been ported to 0.10 and applications that had not...all at the same time! Good :). But for how long? 6 months, 1 year or 3 years? I guess you don't to want to do that for very long :) or many versions. For as long as it takes for the applications to be ported or replaced with ones that use the new superior technology. Users will encourage a port if the functionality of the programs based on the newer instance is better, they will want what that adds in the applications that don't take advantage of it. We saw this with the GTK1 to GTK2 transition, sure it took a while but in the end most applications have either died out for lack of use (and been replaced with other ones if needed) or been ported because that turned out the best possible solution. You don't see many people saying, I'm going to develop a kickass application and I'm going to use GTK1 for the interface anymore - we've all realized that GTK2 is better for all involved. The upcoming release of Fedora finally managed to push GTK1 entirely out of the Core distribution, it took a while but it's inevitable progress. Smaller changes that the toolkit transition will of course take less time, gstreamer 0.10 adaption has taken surprisingly short time, I believe out of all the application I use only Thoggen has yet to be ported. The same should happen with the bindings. So long as we don't break things for the user it should matter much while the change happens. Parallel installability makes this possible. - David Nielsen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Tomboy in Desktop
man, 24 07 2006 kl. 19:49 +0100, skrev Jamie McCracken: I dont doubt that but FWIW when it comes to adding Tracker to gnome 2.18, I would like notes to be added as a first class object and stored in Tracker's DB. Tracker already makes it easy to add tagging, extensible metadata and linking to other objects so adding such support to sticky notes (and Tomboy too if maintainer allows) is one way of improving things in that regard. Im not commiting myself to fixing all your gripes in sticky notes just giving it a bit of tracker power that will hopefully make them more manageable and powerful. I have no gripe with sticky notes, hell up till a few days ago I had blissfully forgotten it's existence. This is also not about Tracker, this is about Tomboy - the argument was starting to center around the notion that we could just fix sticky notes and my point was that Tomboy is a much better application today and users generally love it. Sticky Notes comes no where near it and bringing it to the same state would take a lot of hard and pointless work. Merely adding spell checking (and I agree we should have a common spell checking API and HIG spec but that aside) and stuffing it in Tracker (which isn't an option TODAY as tracker is nowhere near ready either, by your own admission the plan for proposal is 2.18) won't magically make it Tomboy. Tomboy is the product of innovation, it works well and is stable. I see no reason to not include it what so ever. I don't really see a reason to keep Sticky Notes either, it's not discoverable and I doubt many people actually use it - furthermore all the things you'd do in Sticky Notes can be done in Tomboy with ease. It's minimally different interfaces and modes of operation but it would be better to do a UI review of Tomboy and have one application, one good default. If you want the same exact behavior as Sticky Notes, simply don't use the linking feature, voila - you have the same thing (but with spell checking, reference ability, etc). That is where Alex and I differ in opinion, I think we can replace Sticky Notes based on that observation. But please don't retrofit Tomboy on Sticky Notes just because of the politics around Mono and don't bring up Tracker as a solution. We can't make decisions based on software we haven't even examined and debated for inclusion. I imagine the Beagle people might have arguments for and against their system for that debate when it comes around in 6 months or so. That's my opinion. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Tomboy in Desktop
man, 24 07 2006 kl. 22:58 +0100, skrev Alan Horkan: I have no gripe with sticky notes, Doesn't sound like it. You are advocating it be removed and the Tomboy author is not. I honestly don't, my gripe is with duplication of functionality, if we include Tomboy, which I believe was the discussion at hand. We would be providing the basically same functionality twice, this seems to go against what I've come to know and love about GNOME over the many years I've been a part of the community. In fact the very feature that converted me from KDE long ago got replaced, acme or whatever the name was of the first no frills, no configuration, just work multimedia keyboard thing. The functionality got even better by being replaced in my opinion. It is all too easy to disregard all the work put into more peripheral tasks or documentation and ongoing maintainance. I'm a translator, trust me I'm not disregarding tasks aside programming, in fact I translated Tomboy just the other day and I'm about to put my work through peer review within my designated team. APIs get deprecated, but applications get removed entirely. Sometimes the option to keep using what you were happy with really is better than having to learn a new different application. I have yet to actually meet a user who used Sticky Notes, but lets say they exist and are plentiful, I would have expected at least one to chime in and make an practical argument against removing it. However if none do and no concensus can be made on replacing Sticky Notes what do you propose then.. I would be perfectly fine with keeping Sticky Notes on for a few releases although I'm afraid it will end up never getting removed just like I'm afraid that will happen to gnome-cd-player. If we can make a cut off date sufficiently far in the future would that work for you, they both die say in 2 years. That should after all be plenty of time to write documentation of all kinds and you have my word I will help out all I can. For these kinds of things it would be really nice to have the same kind of system the kernel uses, we mark something off as deprecated with a given date in this case we could say come branch time for 2.21 the following gets removed, please stop relying on it today. If we can't outright remove a given program at least we should agree on a policy to do so gracefully in all cases henceforth. I'm not suggesting Sticky Notes be made tomboy but the whole process of removing older applications bothers me. I'd like to see them frozen/deprecated in some way and remain available and then maybe removed at some major milestone or at least after a few releases. This really has nothing to do with Tomboy, I felt similarly strongly about keeping gnome-cd-player when sound juicer was proposed. Yes and when exactly did you imagine we'd get to remove it? This is why we need a policy and a strong leader. No even I'm not that arrogant as to suggest that would be me - in the past Jeff has served this position as our pantsless leader, though his current commercial ties might cause for accusations of bias. If the foundation could afford it that would be one position I'd love to see filled. Someone like Quim Gil has shown a tremendous ability to coordinate and energize people so I'd probably off hand propose him or someone with the same qualities. Actually I've thought about that for some time now, ever since GUADEC where I happened to catch some of the board meeting via the stream. It's also apparent by listening to the community that they think we flutter around to much and need direction. A strong leader and some road maps for desired goals would do us some good and help bring back the community's faith in us. Stability for those who do use it. Why force users to change? Dont try to assume you know best. Why force people to do anything, why force them to use GNOME - I believe the majority will elect to migrate for reasons of functionality and stability of these new products. But we have forced change on them before, gpdf - evince, gtk1 - gtk2, sometimes forcing users a bit is needed for progress to be ensured. Imagine if we never removed code. There are also other ways of ensuring stability than keeping code extensive use of build testing would be just one (maybe we could look at GStreamer here, they have a fine set of tools in use but we can improve on them over time, I know Fredrico would probably like some automated performance measurements as well e.g.). Stability is also for those that seek it, GNOME is pretty damn stable but we can do better.. Did we ever turn the critical to fatal thing back on again for development, it seemed to hit bugs left and right, great testing feature for those of us who have the strange hobby of filing bugs. I apologize for any stop energy I might have released accidentally. - David Nielsen http://osnews.com/story.php?news_id=15266 ___ desktop-devel-list mailing list
Re: Tomboy in Desktop
man, 24 07 2006 kl. 19:45 -0500, skrev Shaun McCance: On Tue, 2006-07-25 at 02:02 +0200, David Nielsen wrote: man, 24 07 2006 kl. 22:58 +0100, skrev Alan Horkan: APIs get deprecated, but applications get removed entirely. Sometimes the option to keep using what you were happy with really is better than having to learn a new different application. I have yet to actually meet a user who used Sticky Notes, but lets say they exist and are plentiful, I would have expected at least one to chime in and make an practical argument against removing it. Sorry, I voiced my concerns in a more general fashion. I try not to posit myself as the user in discussions, because somebody always comes back with the you're not our target user crap. I use Sticky Notes. I have maybe half a dozen notes at any given time. They're mostly transient notes, and most of them get deleted within a couple weeks or so. I mostly use them as TODO lists, although I occasionally use them to jot down other random crap. If I did an upgrade[1] and Sticky Notes wasn't there anymore, I'd be pretty pissed. That's my data. It was probably important. And it's gone. Sure, I'll bet it's buried in a dot directory somewhere. I'll bet I could find it. I'll bet my mom couldn't. And, for what it's worth, I'm fond of the non-window behavior of Sticky Notes, though the ability to show only selected notes would be appreciated. When I'm coordinating what to do with a note, it's nice to have a visually distinct note sort of floating on top of things. None of this is to say that Tomboy isn't an incredible and innovative application (it is). What I'm saying is that I find Sticky Notes meets my needs for what Sticky Notes does, and that losing data sucks hard. [1] Yes, what's still there after an upgrade depends entirely on how one upgrades, which is outside the scope of Gnome. I usually upgrade my distro with a clean install. I keep my home directory on its own partition and wipe the rest. OK, I'm weird. I stand corrected, and yes losing your data does suck rather badly, we should avoid that naturally. I tend to follow the same upgrade method and it normally works for me, I can't think of a reason why it wouldn't or shouldn't do as you expected. This regrettably is a bug, I hope nobody else encountered it, losing data is the one thing that really piss users off in my experience - I fondly remember once being called out at 4am to recover the prepared exam questions for the next day for a teacher who's son had upgraded the system at an unfortunate time.. This kind of experience makes users cry. I'd be rather upset if I upgraded my system and my carefully arranged Tomboy notes went boom. However we have already debated this and there's even a thread now on migration from one system to another (Gnoperinus migration to Orca), a similar conversion would be needed if we replace Sticky Notes with Tomboy, now or at the future date. We can replace applications but the users data should remain. They trust us with it, we should be flattered. - David Nielsen ___ 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. 12:08 +0100, skrev Gustavo J. A. M. Carneiro: Sáb, 2006-07-22 às 00:10 +0200, David Nielsen escreveu: 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! I disagree. Tomboy is nice, but it tries to do too much. It does what it has to do to provide useful functionality. Tomboy looks like a hybrid (or should I say mutant) wiki page system and mind mapping software. Well, for a Wiki system I'd rather use a real web based one (I hate writing wikis in these tiny windows). For mind mapping, I'd rather use a real mind mapping software; alas, we don't have a good gtk2 mind mapper, but freemind is pretty good. For simply taking notes, sticky notes is more than enough. Tomboy is a little like a useful wiki (don't ever ask me to type in real wikis, I hate them) with a sane interface on your desktop, we could even do a plugin to export wiki code and publish it with say a xml-rpc interface. But for bringing some of the useful nature of a wiki with an interface that's more like what I'm used to, Tomboy is brilliant. Tomboy isn't a mindmapping tools, I guess you could use it like one but I would frankly rather have a real seperate mindmap application, maybe something where I could branch out freely and make mapped items links to a Tomboy note. This would allow for a quick visual overview and revealing more details by opening up the specific subset of thoughts. The idea needs more fleshing out, maybe it could be done as a plugin to Tomboy, although it feels like tying a few cats together to make a horse. Sticky notes applet is awesome in its simplicity; let's not remove it, please. Sticky Notes tends to get cluttered up for note taking while project managing, it's an all or nothing interface whereas Tomboy allows me to show only related notes. I normally prefer having only the set of post-it notes I care about displayed rather than having my screen covered in yellow goodness. - 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
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: Tomboy in Desktop
a platform that exposes ways of exchanging information and a set of guidelines for it's design (basically the HIG) - we could then provide a reference platform that uses these services if needed. I guess that kinda makes GNOME into freedesktop.org really but what is the middle ground here, either we pick a set of core use cases to solve and let the distros fill in the gaps or we fill them in. The less we set in stone in terms of solutions, provided we spec out and provide functionality to solve them, the more likely it is that the distros will converge on a set of applications that will win out on excellence for the use cases the distro selects, but everyone is equally able to hook in and replace a given application. -David Nielsen ___ 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: What about Embedded?
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. Aside such things as the existence of tons of books, documentation, classes and existing programmers for .NET, I agree D is a shoe in.. I have confidence in Miguels team, I'm sure they'll optimize the crap out that sucker if we hit serious problems providing GNOME using Mono. - David Nielsen ___ 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
than in C but let's not make any assumptions on performance or ressource use till we've had time to gather data. Splitting our user community will also lead to less influence. Third-party projects already ignore very basic HIG recommendations. And in fact: Why should they bother? It's not that GNOME appears to be the leading Linux desktop, isn't it? If we split due to the desktop release depending on Mono, it will be even harder to convince third-party projects to follow our example. We offer ISVs and core developers yet another piece of technology to use when they want to integrate into GNOME - how is this bad - C# is after all one of the languages that's being pushed hard in college classes currently and looking at job ads the demand for .NET development is there. Providing this for GNOME is good, it will bring more applications and more programmers to our platform. Mono seems like a good platform so it should be able to sell itself. On the other hand, the risks of forcing users to opt-out instead of letting them opt-in are immense. What risks? we add more technology, get better apps - the only users we risk loosing are those do listen to the anti-MS crowd and frankly if you use GNOME because you hate Windows and not because you love GNOME maybe you should reconsider your reasoning. GNOME is a fantastic desktop, I love it dearly, I wouldn't feel at home in another desktop but I want it to move forward and I want it to live after the current generation of developers move on. We simply won't do that on C. - David Nielsen ___ 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!]
ons, 19 07 2006 kl. 12:41 -0500, skrev Federico Mena Quintero: In terms of code and APIs, we are *done*. If you remember the Advisory Board meeting at GUADEC, what ISDs asked for was not more APIs, but the polish things: A common spell checking system would be extremely nice, currently GNOME ships with several applications which use different systems to present a spell checking interface to the user. Spell checking in GNOME makes puppies cry... please think of the puppies. - David Nielsen ___ 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
søn, 16 07 2006 kl. 23:33 -0500, skrev Jason D. Clinton: While you provided a fine run down of arguments, I believe you forgot a vital one, Mono can be optimized, we can cut down ressource consumption, we can indeed do better - we cannot however make C development as fast development in C#, nor as fun. Twice the memory consumption is as I understand it not the lowest common denominator but rather the worst case under the new garbage collector - but nobody has provided hard numbers for the highly contested ressource use yet. Mono comes with a complete set of tools and the only reason we even have to have this debate is the excellence of the applications it enables us to ship... this is a luxury problem. The question isn't if we want to rewrite all of GNOME in C# but do we want the applications it enables us to ship or don't we. Yes, beagle sometimes eats small furry children for breakfast but we aren't debating beagle for inclusion.. yet, by the time we will being having that debate, naturally it would prudent to examine if it still displays grotesk ressource abuse and if we can fix it. We are specifically talking about Tomboy this time around. - David Nielsen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
