Re: Announcing GNOME's official GitHub mirror
The results GitHub brings are not relevant in this case. TONS of useful software have been created - and are still being created - using Microsoft tools, and many other proprietary tools. So what? I think it's somewhat unfair to make the GitHub mirroring automatic and let people send their patches. What if I don't know how to do it or have no time? I think it should be every maintainer's right to decide they don't want to cooperate with a proprietary service. You don't see complaints about GSoC because money blinds people. But here you go: I hereby complain about the policy of Gnome projects to supply support for Google, Facebook and Live.com before they even consider adding similar support for free open alternatives (such as Diaspora, Friendica and MediaGoblin). To be honest, none of my code belongs to Gnome, and I use only Gitorious for hosting. But this upcoming GitHub support would just discourage me from wanting to contribute upstream, and discourage freedom-enthusiasts from joining in. On ה', 2013-08-15 at 12:11 +0200, Alberto Ruiz wrote: > 2013/8/15 Alexandre Franke : > > On Thu, Aug 15, 2013 at 11:49 AM, Alberto Ruiz wrote: > >> We should pick our fights, on the other hand, GitHub has released more > >> open source code and tools than the gitorious community. We accept > >> money from Google for the GSoC's every year and I see no complaints. > >> Everything is a matter on how you look at things really. > > > > I agree that everyone should be free to pick their fights. I agree > > that you you are free to pick yours and have them different from mine. > > Do you agree that mine can be different from yours? > > Absolutely. > > > I really don't care much about my code being mirrored anywhere. At > > least gitorious would be ethically acceptable, so it wouldn't bother > > me, but I won't invest time in this. I see the value of this as a > > backup though, so if others want to work on this I say that's a good > > thing. > > > > Anyway this is really not what was the most important point to me in > > my previous email and you didn't answer the question I really cared > > about, so I'm asking again: is there a way for maintainers to opt out > > of the github mirroring? > > At the moment, no there isn't. Patches to the hook and help to make > this happen are welcome. > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Announcing GNOME's official GitHub mirror
Hello, GitHub indeed offers many features that Gnome's git web interface doesn't. But may I ask why you chose GitHub and not some other service? I'll tell you why it's important in my humble opinion, to ask this question. As you many have heard already, most Git hosting websites use proprietary software and are impossible to clone, which means these services are *partially proprietary* and it means they are *centralized*. Examples: GitHub Google Code SourceForge Launchpad (may technically be opensource but running a clone is forbidden => not really free software...) Actually, the only service I know which is truly free software IIRC, is Gitorious. Also, there's GitLab. They run servers but you can easily setup your own server, being idenpendent and running on fully free software. I just wanted to know whether you took these things into account. (Certainly the popularity of GitHub is not the reason you chose it I guess, just like the popularity of Windows doesn't make us focus on Windows support, and the popularity of Skype doesn't make us focus on Skype connectivity of our apps). Regards, fr33domlover On ה', 2013-08-15 at 11:03 +0200, Alberto Ruiz wrote: > Hello everyone, > > I've been working with the GitHub guys and Andrea Veri on setting up a > mirror for all GNOME repos in GitHub. > > I have more detailes about this in a blog post[0] I just published. > > The aim of this mirror is just to serve as a starting point for people > wanting to have a public branch where they can publicize their work > even if they don't have a GNOME account. It should also help > maintainers keep track of the work people is doing out there with > their code. > > There's no intention to support pull requests or to depend in any way > in this service, this is just a nice-to-have to serve the GitHub's > community and user base. > > The hooks are supposed to be non invasive and this should be > completely transparent to the rest of our infrastructure, if you have > any issues feel free to get in touch with me or Andrea! > > Let me know if you have any questions or requests, happy hacking! > > [0] > http://aruiz.synaptia.net/siliconisland/2013/08/gnomes-official-github-mirror.html ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Idea For Semantic Text-Based GTD Application
Hello Maciej, On ג', 2013-07-02 at 12:09 +0200, Maciej Piechotka wrote: > On Sat, 2013-06-29 at 17:52 +0300, אנטולי קרסנר wrote: > > Hello everyone, > > > > > > This is a draft of the Quick Start part of a tutorial I'm writing for a > > data definition language I made. > > > > https://gitorious.org/peer-review/peer-review/trees/master > > > > > > The language is currently called Idan. It can be used by anyone, > > including non-programmers, to define data models (classes, properties, > > objects) and then define data accordingly, all in simple syntax and > > plain text. > > > > Once the language is ready I'll write the software for it, which can > > read files and manipulate them. > > > > *** Motivation: *** > > > > Data models are usually written by the programmer, and a user can't > > change them. If you want to have a customized system for outlining and > > todo-list or task dependency hierarchies, either you use plain text or > > Emacs org-mode. > > > > Org-mode is great, but it means you need to use Emacs key combinations. > > > > TaskJuggler language exists too, but it's aimed at somewhat technical > > people who need the tool for serious usage. > > > > Idan is simple enough for anyone to use, with Python-like syntax and > > minimal clutter, and the software will allow connection to RDF, and all > > kinds of reports and queries, thus allowing to have all the GUI you > > want, combined with the ability to alter the model by hand and see > > immediate results. > > > > Text formats for task lists already exist, but Idan aims to be a > > general-purpose model definition language, and has features for > > out-of-the-box export to databases and external languages such as RDF. > > > > > > > Sorry for sounding negative - I've never used org-mode or TaskJuggler > and I don't know how to use them. My 'complains' are probably simply > unfamiliarity with this class of tools. That's okay, me neither to be honest. I'll give some examples now. > > Unfortunately I fail to see what problems you are trying to solve. Could > you provide a scenario where it would solve some problem (what user > would be doing from POV of user)? Possibly 2 to show the generality of > approach? Of course. One notable example is the increasing popularity (at least it seems to increase) of text-based task handling and GTD techniques. Many blogs and websites mention the issue, like this one: http://wiki.43folders.com/index.php/Plain_text Also, some smartphone apps (especially proprietary ones) use a simple text-based approach: http://www.hogbaysoftware.com/products/taskpaper I don't have other concrete examples, only tasks and project management. But I can explain the concept in general. Imagine you have many tasks, and you can't remember them. You decide to find a desktop app which can store your tasks. You start with a plain text file, but you realize it cannot sort your tasks by date or by tag, and automatically filter tasks based on location or completion status. You go to Gnumeric or LibreOffice Base. But now your long text descriptions of tasks look ugly there, and you can't make the spreadsheet display a clear hierarchy of task dependencies. Okay, you decide to try a to-do list desktop application. The problem is that each person has a unique mental model, and no app fits everyone's usage patters. But most people are not aware of that. You try one simple app, and discover it doesn't support task dependencies, and remove it. Now you install several new apps and try them. One supports dependencies, but doesn't support tasks with more than one "parent" task. You try another one, but it doesn't support tag hierarchies. Then you try another one, but it doesn't support sync with your mobile device. At this point we reach an ironic situation: On one hand, tasks are a very simple data structure, and the minimal technology required for managing them is pen and paper. In the computer, simple Bash scripts can be enough, or even a tiny C or Python library. No special technology is necessary. On the other hand, finding the perfect app for you may be difficult, and even impossible if you have serious usage patterns and need topics hierarchies and task hierarchies and task sharing. The solution offered by Idan to this kind of problem is to move the modeling process from the program to the user! Or at least to a person who is not necessarily the one who writes the code. Programming languages model two kinds of data: 1. Helper utilities which don't correspond to any real object, and exist only for the program. For example, I/O stream
Re: Idea For Semantic Text-Based GTD Application
Hello everyone, This is a draft of the Quick Start part of a tutorial I'm writing for a data definition language I made. https://gitorious.org/peer-review/peer-review/trees/master The language is currently called Idan. It can be used by anyone, including non-programmers, to define data models (classes, properties, objects) and then define data accordingly, all in simple syntax and plain text. Once the language is ready I'll write the software for it, which can read files and manipulate them. *** Motivation: *** Data models are usually written by the programmer, and a user can't change them. If you want to have a customized system for outlining and todo-list or task dependency hierarchies, either you use plain text or Emacs org-mode. Org-mode is great, but it means you need to use Emacs key combinations. TaskJuggler language exists too, but it's aimed at somewhat technical people who need the tool for serious usage. Idan is simple enough for anyone to use, with Python-like syntax and minimal clutter, and the software will allow connection to RDF, and all kinds of reports and queries, thus allowing to have all the GUI you want, combined with the ability to alter the model by hand and see immediate results. Text formats for task lists already exist, but Idan aims to be a general-purpose model definition language, and has features for out-of-the-box export to databases and external languages such as RDF. If you have a few minutes to go over this file and tell me what you think, I'll be thankful. It's s short quick-start tutorial. A primer. https://gitorious.org/peer-review/peer-review/trees/master Thanks in advance, Anatoly On ג', 2013-06-18 at 05:32 +0300, Luc Pionchon wrote: > On 17 June 2013 09:43, אנטולי קרסנר wrote: > > Hey Luc and list, > > > > I've been planning and designing a language for data modeling and > > description, somewhat based on concepts borrowed from Python (which I > > learned in the process). > > > > I'm now writing a tutorial, and it looks quite simple and > > straight-forward, and the language is very simple. Very soon I'll finish > > the tutorial and I'd like to have it reviewed and hear comments and > > advice. Is anyone interested? > > if you publish it somewhere, I'll have a look > > > > > > With a polished language I'll be able to proceed and write a parser and > > command-line tools, which can serve (with their underlying library) as a > > base for larger systems and GUI app integration (Gnote, GTG, etc.) > > > > regards, > > Anatoly > > > > > > On ד', 2013-05-29 at 21:10 +0300, Luc Pionchon wrote: > >> Hi Anatoly, > >> > >> if you really get such simple enough language, you certainly will get > >> some users. > >> > >> I see you are planning for more usages, though about TODO apps, did > >> you see todotxt [1] which is basically a text based todo/GTD. They > >> have a relatively simple language [2]. Is it similar to what you are > >> thinking about? > >> > >> [1] http://todotxt.com/ > >> [2] https://github.com/ginatrapani/todo.txt-cli/wiki/The-Todo.txt-Format > >> > >> I think you should go ahead and start to write examples, so people > >> could grasp it, and you will also get a better view of the > >> feasibility. > >> > >> Don't care much about "user testing", it's up-side down business > >> thinking. Do something useful, and you'll get some users. > >> > >> go ahead! > >> In any case that is certainly a good learning experience > >> > >> On 29 May 2013 18:02, אנטולי קרסנר wrote: > >> > Hello everyone, > >> > > >> > > >> > I'm an individual not working on any Gnome module. I'll try not to get > >> > into much detail (likely to fail on this one), but here's the idea I > >> > have: > >> > > >> > After reading about existing GTD software tools I made the following > >> > conclusions: > >> > > >> > * There are GUI tools > >> > * There are plain-text solutions > >> > * There are pen-and-paper solutions > >> > * There are text-based applications > >> > > >> > GUI tools have lots of features and visual widgets, but they somehow > >> > fail to satisfy most people. At the same time, plain text seems to > >> > become more and more popular. After reading I made these conclusions: > >> > > >> > * Each person has her own way of thinking, her own way of how the brain >
Re: Switching Between Applications in Gnome 3
I agree we shouldn't scroll through tabs with Alt-Tab, but I can understand where the problem comes from. Very frequently I click on a link in Evolution or "open containing folder" or a file downloaded with Epiphany, and instead of having a new Nautilus/Epiphany tab open, the result is a whole new window. This is very annoying and creates multiple windows. Another problem is exactly that multi-multi-multi-tab problem: You have tons of tabs. Me too. Sometimes I have two Epiphany windows, just so that I can split the tabs into "categories". If we could categorize tabs or have them in a hierarchical structure in the app itself, we'd have less mess on the desktop. I think the points mentioned are worth a thought and some clever design. I believe Gnome is going in the right direction, but focusing on a single source of content is good only for the simple home user / content consumer. When working, one needs to be able to work with many windows and tabs effectively. To be honest, I've been using Gnome 3.4.2 for a while, and no later version, so I don't know how later versions changed the UI. On ב', 2013-06-17 at 17:38 +0100, Emmanuele Bassi wrote: > hi Luis; > > On 17 June 2013 17:09, Luis Menina wrote: > > > I also whish one could cycle through the tabs of a tabbed application > > using just Alt+Tab too, gnome shell handling the tabs, to find the tab > > of the same application I was using 5s ago. > > you really, *really* don't want this. > > I currently have two Firefox windows open, the first with 41 tabs > (after I did a couple rounds of garbage collection, last night I was > at around 70), the other with ~50 tabs. then I have four or five > terminal instances, and within each I have between 3 and 7 tabs. tabs > are cheaper than windows, so people *do* use a ton of those. the > selector would become incredibly tiny, and hard to navigate — > *especially* on low-resolution displays like a netbook. > > ciao, > Emmanuele. > > -- > W: http://www.emmanuelebassi.name > B: http://blogs.gnome.org/ebassi/ > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Idea For Semantic Text-Based GTD Application
Hey Luc and list, I've been planning and designing a language for data modeling and description, somewhat based on concepts borrowed from Python (which I learned in the process). I'm now writing a tutorial, and it looks quite simple and straight-forward, and the language is very simple. Very soon I'll finish the tutorial and I'd like to have it reviewed and hear comments and advice. Is anyone interested? With a polished language I'll be able to proceed and write a parser and command-line tools, which can serve (with their underlying library) as a base for larger systems and GUI app integration (Gnote, GTG, etc.) regards, Anatoly On ד', 2013-05-29 at 21:10 +0300, Luc Pionchon wrote: > Hi Anatoly, > > if you really get such simple enough language, you certainly will get > some users. > > I see you are planning for more usages, though about TODO apps, did > you see todotxt [1] which is basically a text based todo/GTD. They > have a relatively simple language [2]. Is it similar to what you are > thinking about? > > [1] http://todotxt.com/ > [2] https://github.com/ginatrapani/todo.txt-cli/wiki/The-Todo.txt-Format > > I think you should go ahead and start to write examples, so people > could grasp it, and you will also get a better view of the > feasibility. > > Don't care much about "user testing", it's up-side down business > thinking. Do something useful, and you'll get some users. > > go ahead! > In any case that is certainly a good learning experience > > On 29 May 2013 18:02, אנטולי קרסנר wrote: > > Hello everyone, > > > > > > I'm an individual not working on any Gnome module. I'll try not to get > > into much detail (likely to fail on this one), but here's the idea I > > have: > > > > After reading about existing GTD software tools I made the following > > conclusions: > > > > * There are GUI tools > > * There are plain-text solutions > > * There are pen-and-paper solutions > > * There are text-based applications > > > > GUI tools have lots of features and visual widgets, but they somehow > > fail to satisfy most people. At the same time, plain text seems to > > become more and more popular. After reading I made these conclusions: > > > > * Each person has her own way of thinking, her own way of how the brain > > works. Therefore, each person should have a personally tailored solution > > > > * GUI tools, and GTD tools in general, tend to make the false assumption > > of "everyone is like me" and "one size fits all", which is why most > > tools fail to become widely popular. > > > > * Emacs Org-Mode is quite successful as a GTD tool, thanks to its > > flexibility and extensibility, but lacks an intuitive interface, which > > limits its adoption despite the success of Org-Mode > > > > * A next-generation tool should have the extensibility of a plain-text > > system, and the convenience, ease-of-use and efficiency of a visual tool > > > > > > > > Therefore, I decided to create a language for definition of properties > > and classes, intended for be used for describing tasks, timelines, > > projects, etc. This language is easy enough for non-programmers to use, > > and yet is expressive enough for practical use. It borrows concepts from > > RDF, OWL and scripting languages. > > > > On top of this language there will be a set of text-based tools allowing > > easy manipulation of the text. It means users can edit the files in > > plain text, but also have convenient tools and utilities for easier > > processing and visualization, similar to Org-Mode. > > > > On top of that there may be task/project-related definitions, a > > specialized text editor and/or Gedit plugins, and a flexible GUI app > > which replaces the "one for all" concept with a "personally tailored to > > a user's mental model" concept, which seems to work very successfully > > with plain text and Emacs Org-Mode. > > > > > > Existing free software I found: > > > > - Gedit (Gnome's plain text editor, extensible with plugins) > > - Emacs Org-Mode > > > > That's all. All other tools, including all GTD and To-do apps for > > Gnome/GNU, are either scripts intended for power users, or have a > > limited scope which is not flexible enough to customize. > > > > > > An existing GUI app for GTD called Getting Things Gnome (GTG) has great > > potential, but I'd like to back it up using a flexible text-based > > approach which is then used to describe
PERT and CPM algorithms and utilities
Hello, I've been writing a task management app, and I want it to be able to handle PERT, CPM, WBS data, etc. Take some user-defined data, run algorithms and return results, which can then be displayed bu GUI, e.g. Gnome Planner. While sitting in boring lectures I already started writing and planning algorithms, and then I realized: what if there's a standard library for these utilities, and then writing software for project management is much easier and avoid all the math and algorithms? Before I proceed and implement the algorithms in C/C++, I'd like to know: is there a standard tool for that? As far as I know, all programs implement their own code for that, including Planner. Does Planner have a document explaining the algorithms it uses, or some freely available resource on which it bases the code? And is there's a free software library for these things? If not, I'll write one. It's a waste of time for GTG, Planner and many others to write their own widgets and algorithms, since many things are common (dependency graphs, gantt, etc.) to many tools and by making the low-level part available out of the box, writing this kind of software will require much less wheel reinvention. regards, Anatoly ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Switching Between Applications in Gnome 3
Hello, I've been using Gnome 3.4.2 for long time. I started using Gnome 3 because I believe in innovation and evolution through trial and error. But I noticed a problematic recurring pattern in my usage of my laptop (I don't carry it anywhere, and it's has a large screen, so it can be considered like a desktop computer). When I work, especially when I program, I have many windows open: Gedit for source code (I know, I know, I should start using an IDE) Devhelp Epiphany window for programming-related pages Epiphany window for other pages (webmail, social network, etc.) Nautilus, with 2-4 several tabs open, maybe also 2 windows Gnome Terminal window, with the working directory being my git repo Gnome Terminal window for compiling short experiment programs I write Evolution Empathy Transmission This is a lot of open windows, so I group them into workspaces. But it doesn't help, I still feel too inefficient sometimes, and I'd like to know how I can improve my desktop worflow and usage. A typical workspace arrangement I use is listed in the bottom of this message. The problems I encounter: 1. When I need to switch between windows in the same workspace, I take the mouse cursor to the corner of the screen, then click on the window I want to see. 2. When I need to switch between windows in different workspaces, I move the mouse cursor to the corner of the window, then move it to the workspace sidebar, click on the one I want, then click on the window I want. 3. Sometimes using the mouse is faster than thinking, so I have the following problem with Nautilus and Epiphany: since more than one window is open, very often I click on an Epiphany or Nautilus window in the overview, and when it fully appears on the screen I realize it's the wrong window and go to the other one. It happens because I click before I start thinking which workspace is the active one... maybe just because I have many tabs and may pages open. The question is, how can I improve that? Switching between windows, especially on different workspaces, becomes very slow. I tried using alt +tab, but when I hold alt+tab for too long, the marker starts running through the list of windows and I can't efficiently click on the one I want. Oops, wait a second! I just tried the alt+tab keys again, and now it seems I was rejecting them too easily... I think it can work for me :) But anyway, is there some workflow you recommend for programming? I have one 15.6' screen and I need many windows open. Maybe there's some keyboard-driven approach which I and other people should be more aware of. I really think Gnome 3 can be great and more people can find it useful. It's just a matter of knowing how to use it efficiently. So if you have any advice for me, it's very welcome :) Anatoly Here's a typical workspace setup I use: * Personal workspace: Epiphany window for non-programming pages Nautilus with non-programming folders open as tabs * Programming workspace 1 Gedit Devhelp Epiphany window for programming-related pages Gnome Terminal window, with the working directory being my git repo Nautilus with programming related folders open as tabs * Programming workspace 2 Gnome Terminal window for compiling short experiment programs I write Sometimes Evince (for PDF files), filer-roller for tarballs * Network/communication workspace Evolution Empathy Transmission ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Idea For Semantic Text-Based GTD Application
Hello Luc, Yes, I've seen "todotxt" while I was examining existing examples and tools. It indeed has a simple language, and if it's as successful as it's presented on the website (considering the community, I assume it's really successful), it's a proof that a simple language can be flexible enough and still be easy enough for end users. My goals and design guidelines are indeed different, and I also don't like how todotxt works with Dropbox, Google, Android, Amazon, Apple, iOS... But it's a nice example to learn from. I'm still working on the language syntax and concepts, polishing them. But once I have a draft, I'll send examples, have people try them and give me feedback. By relying on both concepts from academic research (used in existing technology e.g. RDF, Adenine) and input from users, I hope to produce a high-quality basis to build upon :) Anatoly On ד', 2013-05-29 at 21:10 +0300, Luc Pionchon wrote: > Hi Anatoly, > > if you really get such simple enough language, you certainly will get > some users. > > I see you are planning for more usages, though about TODO apps, did > you see todotxt [1] which is basically a text based todo/GTD. They > have a relatively simple language [2]. Is it similar to what you are > thinking about? > > [1] http://todotxt.com/ > [2] https://github.com/ginatrapani/todo.txt-cli/wiki/The-Todo.txt-Format > > I think you should go ahead and start to write examples, so people > could grasp it, and you will also get a better view of the > feasibility. > > Don't care much about "user testing", it's up-side down business > thinking. Do something useful, and you'll get some users. > > go ahead! > In any case that is certainly a good learning experience > > On 29 May 2013 18:02, אנטולי קרסנר wrote: > > Hello everyone, > > > > > > I'm an individual not working on any Gnome module. I'll try not to get > > into much detail (likely to fail on this one), but here's the idea I > > have: > > > > After reading about existing GTD software tools I made the following > > conclusions: > > > > * There are GUI tools > > * There are plain-text solutions > > * There are pen-and-paper solutions > > * There are text-based applications > > > > GUI tools have lots of features and visual widgets, but they somehow > > fail to satisfy most people. At the same time, plain text seems to > > become more and more popular. After reading I made these conclusions: > > > > * Each person has her own way of thinking, her own way of how the brain > > works. Therefore, each person should have a personally tailored solution > > > > * GUI tools, and GTD tools in general, tend to make the false assumption > > of "everyone is like me" and "one size fits all", which is why most > > tools fail to become widely popular. > > > > * Emacs Org-Mode is quite successful as a GTD tool, thanks to its > > flexibility and extensibility, but lacks an intuitive interface, which > > limits its adoption despite the success of Org-Mode > > > > * A next-generation tool should have the extensibility of a plain-text > > system, and the convenience, ease-of-use and efficiency of a visual tool > > > > > > > > Therefore, I decided to create a language for definition of properties > > and classes, intended for be used for describing tasks, timelines, > > projects, etc. This language is easy enough for non-programmers to use, > > and yet is expressive enough for practical use. It borrows concepts from > > RDF, OWL and scripting languages. > > > > On top of this language there will be a set of text-based tools allowing > > easy manipulation of the text. It means users can edit the files in > > plain text, but also have convenient tools and utilities for easier > > processing and visualization, similar to Org-Mode. > > > > On top of that there may be task/project-related definitions, a > > specialized text editor and/or Gedit plugins, and a flexible GUI app > > which replaces the "one for all" concept with a "personally tailored to > > a user's mental model" concept, which seems to work very successfully > > with plain text and Emacs Org-Mode. > > > > > > Existing free software I found: > > > > - Gedit (Gnome's plain text editor, extensible with plugins) > > - Emacs Org-Mode > > > > That's all. All other tools, including all GTD and To-do apps for > > Gnome/GNU, are either scripts intended for power users, or have a > > limited scope which is
Re: Idea For Semantic Text-Based GTD Application
Thank you for sharing your opinion. I agree a general-purpose structured language is not suitable for end-users. I looked at some existing languages and examined their nature, and I couldn't find any easy one. The most simple general-purpose is probably the Turtle notation for RDF, but it's still too complicated for end users. Thus, I decided that my language will not have full expressive power. It will define general entities, but once concepts like tasks and calendars are defined, the usage is as simple as defining which properties you want your tasks to have. And it only becomes easier and easier: Once a standard set of properties is written (due date, name, title, description, topic, location, etc.), most people won't even need to write code. If they want, they may choose the properties required for a task, and this way simplify the view by hiding what they don't use. Or just choose the properties they want from the list. For example, some people don't arrange tasks as a graph, just as a list. So they can ignore the dependency features and just see a simple list. Once standard simple query tools are defined, and use the standard properties and classes, even most queries will become easy to write. And the best part: Everything too advanced from the user can be downloaded from a repository. Once people start writing definitions, the end users who are not programmers can simply download the tools, instead of trying to write them. With time, people with all kinds of workflows and technical skills and fields will create a database of free definitions, tools and settings, making the experience of end users convenient, both in the workstation building process and during daily usage of it. So, while I try to provide wide and expressive range of concepts, the actual usage of the language for time management and related life hacking will quickly become very simple, even for non-programmers. Like I said, they basically just need to choose properties, and choose the visualizations they want to see. And with a wide range of properties and views, I hope every user will be able to create a personal setup. Anatoly On ד', 2013-05-29 at 11:26 -0400, Jasper St. Pierre wrote: > I'm not sure. Obviously, we'll see how it works out in practice, but > research has shown that even "basic" structured text languages are > hard for end-users and consumers to grasp. To most people, the > flexibility in text is its lack of structure, which allow people to be > creative and express themselves. > > > org-mode doesn't enforce any structure beyond some basic syntactic > elements to mark free-flowing text as items (bullet points), and while > it comes with a stock set of keywords (TODO, DONE), these aren't > hardcoded at all and most complex org-mode flows add their own > keywords or things like that. > > > The actual words, and the order of them, doesn't matter. So I feel > that a structured text-based approach would simply fail because it > doesn't allow for such flexibility. > > > New research is always welcome, and if you manage to get random > end-users to fluently understand your language system through > concentrated user testing, I'll gladly welcome it. > > > > On Wed, May 29, 2013 at 11:02 AM, אנטולי קרסנר > wrote: > Hello everyone, > > > I'm an individual not working on any Gnome module. I'll try > not to get > into much detail (likely to fail on this one), but here's the > idea I > have: > > After reading about existing GTD software tools I made the > following > conclusions: > > * There are GUI tools > * There are plain-text solutions > * There are pen-and-paper solutions > * There are text-based applications > > GUI tools have lots of features and visual widgets, but they > somehow > fail to satisfy most people. At the same time, plain text > seems to > become more and more popular. After reading I made these > conclusions: > > * Each person has her own way of thinking, her own way of how > the brain > works. Therefore, each person should have a personally > tailored solution > > * GUI tools, and GTD tools in general, tend to make the false > assumption > of "everyone is like me" and "one size fits all", which is why > most > tools fail to become widely popular. > > * Emacs Org-Mode is quite successful as a GTD tool, thanks to > its > flexibility and extensibility
Idea For Semantic Text-Based GTD Application
Hello everyone, I'm an individual not working on any Gnome module. I'll try not to get into much detail (likely to fail on this one), but here's the idea I have: After reading about existing GTD software tools I made the following conclusions: * There are GUI tools * There are plain-text solutions * There are pen-and-paper solutions * There are text-based applications GUI tools have lots of features and visual widgets, but they somehow fail to satisfy most people. At the same time, plain text seems to become more and more popular. After reading I made these conclusions: * Each person has her own way of thinking, her own way of how the brain works. Therefore, each person should have a personally tailored solution * GUI tools, and GTD tools in general, tend to make the false assumption of "everyone is like me" and "one size fits all", which is why most tools fail to become widely popular. * Emacs Org-Mode is quite successful as a GTD tool, thanks to its flexibility and extensibility, but lacks an intuitive interface, which limits its adoption despite the success of Org-Mode * A next-generation tool should have the extensibility of a plain-text system, and the convenience, ease-of-use and efficiency of a visual tool Therefore, I decided to create a language for definition of properties and classes, intended for be used for describing tasks, timelines, projects, etc. This language is easy enough for non-programmers to use, and yet is expressive enough for practical use. It borrows concepts from RDF, OWL and scripting languages. On top of this language there will be a set of text-based tools allowing easy manipulation of the text. It means users can edit the files in plain text, but also have convenient tools and utilities for easier processing and visualization, similar to Org-Mode. On top of that there may be task/project-related definitions, a specialized text editor and/or Gedit plugins, and a flexible GUI app which replaces the "one for all" concept with a "personally tailored to a user's mental model" concept, which seems to work very successfully with plain text and Emacs Org-Mode. Existing free software I found: - Gedit (Gnome's plain text editor, extensible with plugins) - Emacs Org-Mode That's all. All other tools, including all GTD and To-do apps for Gnome/GNU, are either scripts intended for power users, or have a limited scope which is not flexible enough to customize. An existing GUI app for GTD called Getting Things Gnome (GTG) has great potential, but I'd like to back it up using a flexible text-based approach which is then used to describe semantic entities and attach them to program objects. This would supply both the flexibility of text, the convenience of GUI and automatic translation to RDF, which means instant Semantic Desktop integration (using Tracker and Zeitgeist). *** The Question *** My question is, what do you think? Does this idea sound useful? To me personally, it seems to fill the gap between plain text (which has no visualization and productivity utilities) and convenient GUI (which current is mostly not flexible enough). NOTE: Non-free software already exists, which uses plain text as a backend, such as Taskpaper: http://www.hogbaysoftware.com/products/taskpaper regards, Anatoly ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: loomio
I never said the development teams should use it. I realized technical decisions can't be made by community voting. But - 1. Sometimes a team is interested in seeing what the community/other teams think 2. Some decisions are not technical, like you said the marketing team can find loomio useful So if the marketing team tries loomio, it's just fine, I don't restrict to any specific team, and don't expect any specific team to use or not use it. Do know relevant teams which have mailing lists I can post to? (or forward this message to them) On ד', 2013-04-24 at 11:01 -0700, Sriram Ramkrishna wrote: > Well the non-coding parts might accept it. The problem with voting is > that it is an emotional choice when it comes to people who are voting > and are not part of development. Which can lead to all kinds of > conflicts in trying to decide how things develop. > > If we had voting, we would have had to revert everything and go back > to GNOME 1. While at the same time people will be voting to update > everything. It's just wrong. > > > But decision making for teams like marketing might work okay if we > restrict to a particular set of people. Kind of like having commit > access, you get to vote when you put in the time. > > > > On Wed, Apr 24, 2013 at 10:13 AM, Marco Scannadinari > wrote: > Hi, is there any progress with this? > > I there a Gnome team willing to be the "pioneer" and > try loomio, > and report about the experience? I don't belong to any > team so I > can't take responsibility personally (but I'll help > you, if you > decide to give loomio a try). > > > Unfortunately, it seems both the design-team and desktop-devel > teams are > quite against the whole idea of loomio or any other community > voting > system. Andre Klapper also posted a link [0] to a study which > suggest > that commitee-oriented design processes aren't a good idea. > I'm (and > probably not a lot of other people) are not in a position to > argue or > disprove such a study, so, as much as I would like to see it > be > implemented, I guess that's that... > > [0] > http://nat.org/blog/2006/02/dan-winship-on-design-by-committee/ > -- > Marco Scannadinari > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list > > > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: loomio
Hi, is there any progress with this? I there a Gnome team willing to be the "pioneer" and try loomio, and report about the experience? I don't belong to any team so I can't take responsibility personally (but I'll help you, if you decide to give loomio a try). Anatoly On א', 2013-04-14 at 11:36 +0300, אנטולי קרסנר wrote: > Hello, > > I found a tool for collaborative decision making and brainstorming > called loomio: > > https://www.loomio.org/ > > It's open for private beta, and I think Gnome, as a community project, > can really benefit from using it. > > Currently the communication between people in the project is done in > several channels not connected to each other: mailing list, GnomeLive > wiki and IRC channels. All three of them treat all text as just plain > text, meaning the computer doesn't provide us tools for specific content > such as brainstorming, ideas, plans, schedules, etc. > > Loomio doesn't provide all of these things, but it's a great tool for a > community to use for managing ideas and decisions. > > What do you think? > > > > Anatoly > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: loomio
I agree, random people can't have the same influence on votes like the people actually seriously involved, but like Sri and Marco said, there are already existing cases in which such a system can be very useful. Seif offered to try it with the Gnome Music team, but anyone else who wants to give it a try is very welcome too. I couldn't set up an account because I don't personally belong to any team so I can't speak for a whole team, but signing up is quite easy: we just need to fill a form for beta-testing it (currently all organizations using loomio are considered "private beta testers", although it is already used successfully by organizations of all sizes): https://www.loomio.org/group_requests/new Anatoly On ג', 2013-04-16 at 23:30 +0200, Andre Klapper wrote: > On Tue, 2013-04-16 at 22:08 +0100, Marco Scannadinari wrote: > > So you want to have random people suddenly join, be of the decision and > > have equal say? I find that a little bit weird. > > > > As opposed to the method that we have now which is..? > > (I cannot speak for all teams, as I'm not in all teams. > Anybody feel free to correct me please.) > > Most teams have meetings sometimes, mostly IRC based (though some also > have phone or Google Hangouts as far as I know). > Except for board and release-team, team membership is not exclusive / > defined, and (except for board) meetings are public. Newcomers and > lurkers are welcome to meetings and to provide input to influence > decisions, but when it comes to "hard" voting (if decision making > process is not consense-based) I'd expect only "established" people to > feel like taking part anyway, or at least expect their votes to have way > more weight. In the end that's how I understand meritocracy. > > Also see section "5.5.2 Community" of > http://www.dgsiegel.net/foss-development-processes > > andre ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: loomio
With pleasure :) But it depends on the necessary resources. If they supply their own server on which they create the group account, all I need to do is fill a form. But I don't have all the details: https://www.loomio.org/group_requests/new On ב', 2013-04-15 at 16:31 +0200, seiflo...@googlemail.com wrote: > Hmm I am very uncertain about loomio, however since I am working on > gnome-music with a small team, we could try using loomio for a bit to > see if it in any way improves our workflow. > We could report and blog about the experiecen. However that would > require Anatoly to set up the whole infrastructure for it. I would say > the sooner the better. > Cheers > Seif > > > On Mon, Apr 15, 2013 at 4:11 PM, Olav Vitters wrote: > On Mon, Apr 15, 2013 at 03:33:06PM +0300, אנטולי קרסנר wrote: > > So I'm not attacking the relevance of existing tools. I'm > suggesting a > > tool which may be better for some use cases. Maybe it can, > maybe it > > can't, but don't judge so quickly. > > > It just seems some basics are missing. What is missing from > what we > currently have, what are the benefits or what we currently > have. Then go > on to check what can solve it in a better way. > > At the moment I'm guessing: > 1. wish for all decisions to be documented > 2. decisions to be easily findable by people who are not > involved > 3. all components of a decision to be logged > > If above is a good summary, then: > #1 is nice to have, #3 is IMO unrealistic, #2 is not the right > focus, > should be better if people taking decisions can log their > reasoning more > easily. > > -- > Regards, > Olav > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list > > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: loomio
If we all always thought and decided on things the way you suggest, then nothing would ever change. It's not a big secret that tools like wikis and mailing lists are very general-purpose and the reason they're used so widely is that creating tools for specific tasks is a very difficult task. Even professional and proprietary getting-things-done tools are not that widely used, because making them serve the purpose is difficult. I agree the ease of use, years of proven success and general-purpose-ness of IRC, mailing lists and wikis make them very useful, but clearly it's possible to have even better tools. And one day I discover loomio. It's not project management, but collaborative decision making can definitely benefit from it, and provide by far more than any mailing list can. So I'm not attacking the relevance of existing tools. I'm suggesting a tool which may be better for some use cases. Maybe it can, maybe it can't, but don't judge so quickly. On ב', 2013-04-15 at 22:19 +1000, Andrew Cowie wrote: > On Mon, 2013-04-15 at 14:49 +0300, אנטולי קרסנר wrote: > > > Keeping track of the process would become much easier than the current > > mix of IRC, mailing lists and wiki pages. > > So then it would be a mix of IRC, mailing lists, wiki pages, and this > thing. > > As ever, > http://imgs.xkcd.com/comics/standards.png > > AfC > Sydney > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: loomio
I agree, I didn't mean to change the way module maintainers make specific technical decisions for their modules. But many decisions are relevant for the whole community, and using such software would allow people to participate more easily and give them a feeling their voice counts. Keeping track of the process would become much easier than the current mix of IRC, mailing lists and wiki pages. I sent a message to the gnome-love list too, hoping relevant teams will see it there. Since I don't even have any area of responsibility in the Gnome project, all I'm doing is to suggest the use of loomio. The decision is up to the people responsible for things here in the actual teams. I wanted to make sure you are aware of loomio. Olav mentioned something about involvement or marketing which I didn't understand, but just to make things clear: I have nothing to do with loomio or Gnome (except for being a user on Gnome 3 on my laptop), I'm just a random person who heard about loomio and suggests you to use it, if it fits the project's decision making model. Everything else is up to you, I can't speak to anyone in the name of the whole community. Enjoy :) On א', 2013-04-14 at 21:31 -0700, Sriram Ramkrishna wrote: > > > > On Sun, Apr 14, 2013 at 7:53 PM, Germán Póo-Caamaño > wrote: > On Sun, 2013-04-14 at 20:53 -0400, Hashem Nasarat wrote: > > > [...] > > Sriram, while I agree many problems would be alleviated with > more > > volunteer time, I've witnessed multiple instances in the > past 6 months > > where decisions were not made democratically, despite a > clear lack of > > consensus. Most recently, there were a great deal of changes > to the > > gnome-shell "All Applications" view very late in the 3.8 > schedule, well > > after code freeze, and despite visible disagreement. Loomio > seems to > > offer an intuitive way of seeing how controversial a change > is. > > > "If I’d asked people what they wanted, they would have asked > for a > better horse" -- Henry Ford [1] > > Software development is not a democracy. Decisions are taken > by people > who actually develop the software. Comments might or might > not be > welcomed depending of several factors (politeness, pertinence, > reputation, data, etc.). > > > Germán is right. In free software land, the module maintainer is the > ultimate dictator of what goes into the code base. So the decision > falls upon the maintainer and a trusted cohort or two. In which > case, decisions are fairly easy to come to and you don't really need > decision software. > > > Marketing and others non-coding teams tends to require more consensus > mostly because sometimes money and tangible resources are involved so > decisions are done jointly. That's where such things would be > interesting. > > > So for instance, your suggestion of decision software might quite well > for the Board when trying to document consensus, but it doesn't map > well to the technical culture of free software. > > > sri > > > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
loomio
Hello, I found a tool for collaborative decision making and brainstorming called loomio: https://www.loomio.org/ It's open for private beta, and I think Gnome, as a community project, can really benefit from using it. Currently the communication between people in the project is done in several channels not connected to each other: mailing list, GnomeLive wiki and IRC channels. All three of them treat all text as just plain text, meaning the computer doesn't provide us tools for specific content such as brainstorming, ideas, plans, schedules, etc. Loomio doesn't provide all of these things, but it's a great tool for a community to use for managing ideas and decisions. What do you think? Anatoly ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Management Tools used by Gnome project
On ו', 2013-04-12 at 18:05 -0700, Germán Póo-Caamaño wrote: > On Sat, 2013-04-13 at 03:59 +0300, אנטולי קרסנר wrote: > > Hello everybody, > > > > I'm gathering information about how free software projects are managed > > and I'll be thankful if someone can explain briefly which technologies > > are used by Gnome. > > I think that "Producing Open Source Software: How to run a successful > Free Software project" by Karl Fogel is a good starting point. > > http://producingoss.com/ > Thanks, it is very useful indeed. But I'd like to hear some more: How and where is the release cycle managed? How does cross-module communication and management happen? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Management Tools used by Gnome project
Hello everybody, I'm gathering information about how free software projects are managed and I'll be thankful if someone can explain briefly which technologies are used by Gnome. As far as I know, there's no special project management software in use. I do know some tools: The GnomeLive wiki, mailing lists, IRC channels, developer manuals, git repositories, but I don't see things from the prject manager point of view. How is this huge project really managed and maintained? Which tools are used, and for what purposes? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [OT] Re: [Fwd: Re: Two 3.10 feature ideas]
Hello Karen, I must say I really like your writing skill and excellent verbal expression ability :) Thanks for making things clear. I agree with you, providing access to popular services is a pre-requisite for many people, while providing free-software alternatives is still a primary goal, and always should be. On ו', 2013-04-12 at 15:27 -0400, Karen Sandler wrote: > On Fri, April 12, 2013 1:51 pm, ×× ×˜×•×œ×™ ×§×¨×¡× ×¨ wrote: > > I wasn't implying closed-source software succeeds, it was sarcasm. > > > > Anyway, arguing on different believes and priorities is pointless, I'll > > stop here. I got the point, you want a bigger market share. But I don't > > understand why. I mean, why is that the primary goal? It sounds like a > > goal for a commercial company. > > I've got to chime in here too - I want to bring free software to more > people as part of our nonprofit charitable mission. I believe that it is > really important to our society that we build free alternatives to the > proprietary systems that are increasingly being relied on for critical > functionality. Free software is the right answer for all software, but we > do have a basic challenge in providing the alternatives that people will > want to use. I want to encourage a move to good online services, but I > also know that providing a way for users to continue to use the services > that they already count on is a pre-requisite for many. It's a complicated > issue, and I think we need to work as hard as possible to build > alternatives and to encourage users towards fully free and ethically built > software and services. But we also must be an immediately viable > alternative. > > karen > > > > > Anyway, you do what you believe in and I'll do what I believe in. I > > understand now, why Gnome supplies all those "bad" plugins before it > > tries to offer replacements. > > > > There are enough modules for me to work on, which aren't related to > > Facebook or Google. > > > > See you around > > > > On ו', 2013-04-12 at 19:29 +0200, Andre Klapper wrote: > >> On Fri, 2013-04-12 at 19:40 +0300, ×× ×˜×•×œ×™ ×§×¨×¡× ×¨ wrote: > >> > What does "competing on the market" mean? Do you get a salary for > >> > working on Gnome projects, which depends on how many people use your > >> > software? > >> > >> Primarily, markets are based on interest & attention, not money. > >> > >> > Since when is "increasing the user base" a primary goal? If that's > >> we're > >> > after, let's start writing closed-source software. Microsoft, Google, > >> > Facebook and many others succeed more than Gnome, maybe we should just > >> > follow them and abandon the Free Software idea. > >> > >> You imply that because of being closed-source, other projects are more > >> successful, but it's more likely that they are successful for a number > >> of other reasons while being closed-source. So that's a false cause. > >> > >> But we might differ on defining "success" here, I'm thinking in terms of > >> userbase and marketshare, you might not. > >> > >> > Now seriously, which goal is more important: spreading software > >> freedom > >> > and free-as-in-freedom computing, or just getting more people to use > >> > Gnome (which doesn't increase anyone's salary anyway)? > >> > >> To me both is important. Plus not sure why you mention salaries. > >> > >> > In my opinion, the point is that the developers themselves should care > >> > about software freedom, and make that a high-priority goal, rather > >> than > >> > feeding their ego by having users migrate to Gnome. > >> > >> So "caring about software freedom" does not feed your ego by making you > >> feel more morale compared to closed-source? Good, then. > >> > >> > You can't spread > >> > freedom if you're not consistent with your own ideas. People will say, > >> > "all that open source/free software thing is bullshit, look at them. > >> > They supply a direct connection to Facebook and GMail and Twitter from > >> > the desktop, before them even bother to give us a free alternative. > >> It's > >> > all bullshit, let's go back to Windows." > >> > >> "People will say" misses a citation, but I can come up with that too: > >> "People will say that the open source/free software thing is bullshit, > >> they don't even offer basic integration with the most common services on > >> the interwebs. Freedom is nice, but I need to get my work done." > >> > >> Anyway, I prefer to make GNOME good, easy, beautiful for everybody, not > >> just for people who already know and care about software freedom. > >> > >> andre > > > > > > ___ > > desktop-devel-list mailing list > > desktop-devel-list@gnome.org > > https://mail.gnome.org/mailman/listinfo/desktop-devel-list > > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [OT] Re: [Fwd: Re: Two 3.10 feature ideas]
I wasn't implying closed-source software succeeds, it was sarcasm. Anyway, arguing on different believes and priorities is pointless, I'll stop here. I got the point, you want a bigger market share. But I don't understand why. I mean, why is that the primary goal? It sounds like a goal for a commercial company. Anyway, you do what you believe in and I'll do what I believe in. I understand now, why Gnome supplies all those "bad" plugins before it tries to offer replacements. There are enough modules for me to work on, which aren't related to Facebook or Google. See you around On ו', 2013-04-12 at 19:29 +0200, Andre Klapper wrote: > On Fri, 2013-04-12 at 19:40 +0300, אנטולי קרסנר wrote: > > What does "competing on the market" mean? Do you get a salary for > > working on Gnome projects, which depends on how many people use your > > software? > > Primarily, markets are based on interest & attention, not money. > > > Since when is "increasing the user base" a primary goal? If that's we're > > after, let's start writing closed-source software. Microsoft, Google, > > Facebook and many others succeed more than Gnome, maybe we should just > > follow them and abandon the Free Software idea. > > You imply that because of being closed-source, other projects are more > successful, but it's more likely that they are successful for a number > of other reasons while being closed-source. So that's a false cause. > > But we might differ on defining "success" here, I'm thinking in terms of > userbase and marketshare, you might not. > > > Now seriously, which goal is more important: spreading software freedom > > and free-as-in-freedom computing, or just getting more people to use > > Gnome (which doesn't increase anyone's salary anyway)? > > To me both is important. Plus not sure why you mention salaries. > > > In my opinion, the point is that the developers themselves should care > > about software freedom, and make that a high-priority goal, rather than > > feeding their ego by having users migrate to Gnome. > > So "caring about software freedom" does not feed your ego by making you > feel more morale compared to closed-source? Good, then. > > > You can't spread > > freedom if you're not consistent with your own ideas. People will say, > > "all that open source/free software thing is bullshit, look at them. > > They supply a direct connection to Facebook and GMail and Twitter from > > the desktop, before them even bother to give us a free alternative. It's > > all bullshit, let's go back to Windows." > > "People will say" misses a citation, but I can come up with that too: > "People will say that the open source/free software thing is bullshit, > they don't even offer basic integration with the most common services on > the interwebs. Freedom is nice, but I need to get my work done." > > Anyway, I prefer to make GNOME good, easy, beautiful for everybody, not > just for people who already know and care about software freedom. > > andre ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [OT] Re: [Fwd: Re: Two 3.10 feature ideas]
I wasn't implying closed-source software succeeds, it was sarcasm. Anyway, arguing on different believes and priorities is pointless, I'll stop here. I got the point, you want a bigger market share. But I don't understand why. I mean, why is that the primary goal? It sounds like a goal for a commercial company. Anyway, you do what you believe in and I'll do what I believe in. I understand now, why Gnome supplies all those "bad" plugins before it tries to offer replacements. There are enough modules for me to work not, which aren't related to Facebook or Google. See you around On ו', 2013-04-12 at 19:29 +0200, Andre Klapper wrote: > On Fri, 2013-04-12 at 19:40 +0300, אנטולי קרסנר wrote: > > What does "competing on the market" mean? Do you get a salary for > > working on Gnome projects, which depends on how many people use your > > software? > > Primarily, markets are based on interest & attention, not money. > > > Since when is "increasing the user base" a primary goal? If that's we're > > after, let's start writing closed-source software. Microsoft, Google, > > Facebook and many others succeed more than Gnome, maybe we should just > > follow them and abandon the Free Software idea. > > You imply that because of being closed-source, other projects are more > successful, but it's more likely that they are successful for a number > of other reasons while being closed-source. So that's a false cause. > > But we might differ on defining "success" here, I'm thinking in terms of > userbase and marketshare, you might not. > > > Now seriously, which goal is more important: spreading software freedom > > and free-as-in-freedom computing, or just getting more people to use > > Gnome (which doesn't increase anyone's salary anyway)? > > To me both is important. Plus not sure why you mention salaries. > > > In my opinion, the point is that the developers themselves should care > > about software freedom, and make that a high-priority goal, rather than > > feeding their ego by having users migrate to Gnome. > > So "caring about software freedom" does not feed your ego by making you > feel more morale compared to closed-source? Good, then. > > > You can't spread > > freedom if you're not consistent with your own ideas. People will say, > > "all that open source/free software thing is bullshit, look at them. > > They supply a direct connection to Facebook and GMail and Twitter from > > the desktop, before them even bother to give us a free alternative. It's > > all bullshit, let's go back to Windows." > > "People will say" misses a citation, but I can come up with that too: > "People will say that the open source/free software thing is bullshit, > they don't even offer basic integration with the most common services on > the interwebs. Freedom is nice, but I need to get my work done." > > Anyway, I prefer to make GNOME good, easy, beautiful for everybody, not > just for people who already know and care about software freedom. > > andre ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [OT] Re: [Fwd: Re: Two 3.10 feature ideas]
What does "competing on the market" mean? Do you get a salary for working on Gnome projects, which depends on how many people use your software? Like I said, I don't offer to block them. I offer to have them as a low priority. What is the GOAL of the Gnome project? Dominating the desktop market? Becoming a monopoly? Since when is "increasing the user base" a primary goal? If that's we're after, let's start writing closed-source software. Microsoft, Google, Facebook and many others succeed more than Gnome, maybe we should just follow them and abandon the Free Software idea. Now seriously, which goal is more important: spreading software freedom and free-as-in-freedom computing, or just getting more people to use Gnome (which doesn't increase anyone's salary anyway)? I guess we do agree on the goals. The question is, what's the order of priorities. The internet is already free enough for free software to use. But clearly Facebook and Google aren't, so you can't compare. Eventually we can add Diaspora plugins and so on, and let the users choose freedom if they wish, but that's not the point. In my opinion, the point is that the developers themselves should care about software freedom, and make that a high-priority goal, rather than feeding their ego by having users migrate to Gnome. You can't spread freedom if you're not consistent with your own ideas. People will say, "all that open source/free software thing is bullshit, look at them. They supply a direct connection to Facebook and GMail and Twitter from the desktop, before them even bother to give us a free alternative. It's all bullshit, let's go back to Windows." First choose goals, priorities and values, then make a plan according to them. Writing free software doesn't make us angels and doesn't give us any excuse to give free software a bad name by showing more support to Facebook, Youtube and Google than we show to Diaspora, MediaGoblin and MyKolab (or whatever can replace GMail and google calendar using free software). So do as you wish, just keep a clear list of priorities. The winners are the ones who remain last in the field. The ones who persist. The ones who swim against the current when they need to. The sheep which don't blindly follow the herd. The ones who aren't afraid of cold water. Assuming you consider software freedom as victory... I do. - Anatoly Krasner On ו', 2013-04-12 at 18:04 +0200, Andre Klapper wrote: > On Fri, 2013-04-12 at 01:46 +0300, אנטולי קרסנר wrote: > > Fact: many of them know it's bad. Fact: it > > doesn't make them stop using it. Fact: if Gnome is good enough without > > Facebook, it can help them stop using it. Fact: it supplies integration > > and GOA accounts, thus the users remain addicted. > > Fact: many people are addicted to the internet. If GNOME did not provide > a browser or even internet connectivity, GNOME could help them stop > using the internet. > > So I've seen the "This Free and Open Source Project should educate its > users about non-free services!" opinion across several FOSS projects I > am/was involved in. "Make it harder for users to use non-free but > convenient services" is a great way to decrease your userbase, but > providing *better* services than the non-free ones and competing on the > market might be more sustainable. I won't stop you from doing that. > > andre ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Fwd: Re: Two 3.10 feature ideas]
I know free software alternatives exist, but some apps don't even support them. If we want people to migrate, let's just support proprietary media formats. Let's support anything the users actually use. Even closed-source tools. Why not, if it's what they use??? [sarcasm] I agree I don't have to add a Facebook account to GOA, but you make a mistake assuming what users want is the right thing. Fact: many people are addicted to Facebook. Fact: many of them know it's bad. Fact: it doesn't make them stop using it. Fact: if Gnome is good enough without Facebook, it can help them stop using it. Fact: it supplies integration and GOA accounts, thus the users remain addicted. Fine, keep the Facebook account, just give users the option to never see and use it. Also, why waste time on it? Go ahead, write plugins, but why FOCUS on Facebook and Twitter? I'd rather fix random bugs. If integrating Windows Live, Facebook and Google is the way to make people migrate to Gnome, I'm ashamed of that. Ashamed of being a part of that. We can keep those features, but give them the lowest prioprity. If Gnome is good enough, people will come anyway. Otherwise, I prefer they don't come, than the case they come because of Facebook and MSN integration. What I'm saying is: Sometimes users don't know what's best for them. It's okay, nobody's perfect. But why help the devil? Let's guide them to using free-software alternatives! GNU and Gnome are supposed to me committed to freedom, not to users' wishes. Users wish to use facebook, but that's just an issue of addiction and not understanding software freedom and privacy. We can't let that change our goals. Anyway, you get the point. You're welcome to have all those features, just make sure I can have all of them using free software. And make that the first priority. THEN you can add facebook and google. They're in wide use, but I can't let them be in the highest priority. It just wouldn't make any sense. Good luck! And never forget, freedom and privacy are above all :) On ו', 2013-04-12 at 00:24 +0200, Matteo Settenvini wrote: > With the new notifications panel, if you find notifications from a > certain source annoying you can disable them. Also, in the online > accounts panel you don't have to add what you don't want to. If these > notifications distract you, just don't add them in the first place. > > We already have Facebook and Google as sources in GOA, as well as Flickr > and Windows Live. While I am myself fighting for freedom on our > platforms, and I fully agree Diaspora would be a nice addition, I don't > see what keeps us to integrate our desktop to other websites for those > users that would like to use them anyway. > > Choosing to fire up a browser and go visit that website (authenticating > inside Epiphany/Firefox), or choosing to manually add an online account > (authenticating with g-o-a) only changes the interaction medium, but > it's up to the user to decide what to do. > > I am just proposing to have a generic framework to handle messages from > social networks for those users who care to keep notifications enabled / > manually configure them in GOA. StatusNet (and Identi.ca) is another > free-software example of something that could benefit from this > approach. As you see, there are free-software alternatives to > proprietary ones, and they shouldn't be penalized. The framework would > be source-agnostic. > > In fact, I believe that having Identi.ca supported by GOA would help > boost its popularity, making it a more prominent alternative against, > for instance, Twitter. > > That said, other desktop environments such as Mac OS X Mountain Lion, > and Windows 8, both have integrated support for these things. I am not > saying "let's do like they do", just pointing out that there might be a > use case for users migrating from other platforms to GNOME. > > Cheers, > Matteo > > --- Messaggio inoltrato --- > Da: אנטולי קרסנר > A: daniel.mustie...@gmail.com > CC: mat...@member.fsf.org, GNOME Desktop Development List > > Oggetto: Re: Two 3.10 feature ideas > Data: Fri, 12 Apr 2013 00:30:42 +0300 > > The first idea sounds good, but I don't think the second one is worth > anyone's effort. > > Just a personal opinion, but as a Facebook user in the past, I've seen > how loads of notifications keep you addicted and distracted and don't > let you do the useful things you planned to do. > > There may be some use to such notifications, but basically - you would > just be helping Facebook, Twitter and Google+ get more people addicted. > And all three of them are proprietary and have known storied about how > t
Re: Two 3.10 feature ideas
The first idea sounds good, but I don't think the second one is worth anyone's effort. Just a personal opinion, but as a Facebook user in the past, I've seen how loads of notifications keep you addicted and distracted and don't let you do the useful things you planned to do. There may be some use to such notifications, but basically - you would just be helping Facebook, Twitter and Google+ get more people addicted. And all three of them are proprietary and have known storied about how they use people's private data... So in my opinion, working on these notifications is one of the most not-important things we can possibly work on. I prefer to fix random bugs than help Facebook track people and control their lives. I know Google sponsors Gnome, but it doesn't change the fact I fight for software freedom, and I don't want to use Facebook or Twitter or Google mail/docs service. I do use this GMail mailbox, but I know it's bad and I'm looking for replacements. There's Diaspora, for example. I know many people here actually work for RedHat, but all those of you who care about software freedom purely: Do you really want Facebook/Google/Twitter to take over the desktop? If they do, Gnome will become just another desktop environment, not any better than Windows. Freedom and privacy are killer features, ladies and gentlemen. At least in my humble opinion. Let's not give up on them so easily. But do go ahead with the Evolution idea :) - Anatoly Krasner On ה', 2013-04-11 at 22:09 +0200, Daniel Mustieles García wrote: > For the first idea, maybe something like this could be useful: > > http://code.google.com/p/gnome-gmail-notifier/ > > I've been using it in both GNOME 2 and GNOME 3 ant id works properly > with notifications, so it would be a good starter point. > > Cheers! > > 2013/4/11 Matteo Settenvini > Dear all, > > unfortunately, I don't know if I will have the manpower in the > next six > months to contribute actively to GNOME, so I'm just dropping > two ideas > for features here. I believe they would benefit a good number > of users. > > * Finally have evolution display notifications for new > messages while > the main UI is not open. There was a proposal in this > direction several > cycles ago, but I believe it was postponed indefinitely. Has > evolution-data-server all the needed pieces? This is not > conceptually > much different than notifications for new chat messages. Sure, > it can be > achieved by some another different small program which needs > to be > configured separately, but it would be nice to have this well > integrated > with the rest of the GNOME experience. > > * Add social network notifications. Some of them could be > read-only > notifications (e.g. for Google+, which does not provide a > write API), > others could afford to offer an interface similar to the one > used for > chat (e.g. for Facebook and Twitter) where you can respond. > Gwibber > attempted to do some of these things, but a solution > integrated with > g-o-a (which already has the authentication pieces in place) + > gnome-shell seem to make much sense. > > Anyway, thanks for your strenuous work! > > Cheers, > -- > Matteo Settenvini > FSF Associated Member > Email : mat...@member.fsf.org > > > -BEGIN GEEK CODE BLOCK- > Version: 3.12 > GCS/E d--(-) s+: a- C+++ UL+++ > P+ L>$ E++>+++ W+++ N+ o? > w--- O M- V- PS++ PE- Y+>++ > PGP+++ t++ 5 X- R+ !tv b+++ > DI++ D++ G++ e++ h+ r++ y+ > --END GEEK CODE BLOCK-- > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
"File usage design" - store aplication data in home folder
Hi, I couldn't find advice on the web for a question related to designing file usage of desktop applications (and gnome software in general): Assume I have an app which allows the user create notes or tasks or messages or similar pieces of text, usually not more than a few paragraphs long. I can store them all in one file or store each one as a separate file. Clearly there are many advantages to storing them as separate files: Faster save-time (but probably slower loading...) when just a small update is made, separately signing and encrypting files, separate backup and restoration, easy copy-and-paste manually from Nautilus or manual text editing from Gedit, etc. But let's ignore the technical issues. Assume I can encrypt and sync the text even as a single big file. What are the pros/cons for having a big file VS using separate files? Example: Gnote uses a separate file for each note. GTG stores all tasks in a single XML file. - Anatoly Krasner ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Tools for Sharing Tasks
I see... Redmine can do the job, but it's meant to be used for a project. For a team working together using one server. My application tries to make task sharing easy even if you don't have a whole project. For example, delegate a task to your nice neighbor. What git gives me is the ability to share tasks without a centralized system. Each user can choose any git hosting service he/she wants, and if you want to share a task with someone, it can be done using your repo as the "remote" one, or using the other user's repo. It doesn't matter because there's project. I can use any file sharing service of course, but git provides version tracking. You can store tasks and source code in the same repo easily. There will be no mess and no conflicts, because tasks cannot be edited by all the people sharing them. In the general case, only the creator, the one who assigns tasks to people under him, can edit them. It makes sense: you can't "edit" the orders you're given from your boss. Maybe there's something better than git or XMPP, but I need something specific which gives me all those features of decentralized file sharing. I'll read more about XMPP, I'm not sure yet if it can store the files on the server or at least keep an "offine message" to send to a given user when the users connects to the server... if I can use existing Jabber/XMPP servers it's great, otherwise it's to much work for a home user to do just to share a task or two On ג', 2013-04-02 at 18:58 +0200, Matteo Settenvini wrote: > Jasper already summed it up nicely, bringing some concrete examples. > > What I would do, is to use simply a webapp, such as RedMine, deployed > somewhere all project members can access. Since it provides a REST API, > you can then send and get JSON requests through normal HTTP operations. > You can keep a queue for offline use, and provide an interface to solve > conflicts, if you worry that people cannot be always connected to the > Internet. Sometimes the easiest solution is just the best one: I would > just say "use the web interface". > > Not an expert so I might be wrong, but: if you really would like an > offline Gtk+ application to sync with a server, without having to care > too much about how data is synced, I believe you could talk to > evolution-data-server through libecal. EDS will then manage things under > the hood, possibly using WebDAV/CalDAV, Exchange, etc. I think you could > start by getting an ESource from libedataserver, and use it accordingly. > > Cheers, > Matteo > > Il giorno mar, 02/04/2013 alle 19.25 +0300, אנטולי קרסנר ha scritto: > > Hi, > > > > This is a somewhat technical question, I hope this is the right place > > for it. > > > > I'm writing a GTK application which manages tasks and projects. At the > > moment it's more or less like GTG (Getting Things Gnome). I want to add > > task sharing, and I've been thinking what's the right way to do that. > > > > I checked what other people do. GTG uses the XMPP pubsub extension > > (publish & subscribe), which seems to do the job, but it's not exactly > > designed for sharing tasks. It does work, but it requires you to setup > > the server. > > > > I've been thinking and I found another idea: use a git repository. > > > > This way people can easily watch how projects develop - this way we > > easily achieve the publish&subscribe capability - and sharing tasks > > between team members is as easy as working with git, which is already > > very common. Task sync is simple sync of files in the repo. And it > > doesn't require any extra work: starting a new local git repo is > > extremely easy by typing "git init", and starting a repo on a server is > > done by creating a user on gitorious and creating a repo there. > > > > Some sites don't offer private repos for free, but encryption will be > > used anyway to allow maximal privacy anyway, so it shouldn't be a > > problem. (GitLab offers 10 private repos for no charge if you really > > need 100% privacy) > > > > I'd like to hear more ideas and make a wise decision, which tool is the > > best one for task sharing. Git sounds very good to me, but I'm not an > > expert (just a software engineering student, actually). > > > > > > - Anatoly > > > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Tools for Sharing Tasks
I just checked what Snowy is... sounds useful, but the Gnome Live page hasn't been touched for long time and the FAQ says it's not stable yet and not safe to trust. I agree git is not meant for sharing, but here's the idea I have in mind: Task sharing is not simple file sharing, so I can't let users share the task files manually. The task management application uses git behind the scenes, just like SparkleShare uses git for file sharing. There shouldn't be any conflicts because program logic takes care of sharing, sync, giving tasks to employees, getting "task done" signals from them, receiving tasks from supervisor, etc. No need to use git directly. If there's a conflict, it means a bug. A problem in program logic. The advantage is that sharing tasks becomes extremely easy. Getting your own local repo and a remote repo for task sharing is extremely easy and accessible. Once you set the application to use a given repo, you don't need to touch git. XMPP has the advantage you can see people's avatars and use Jabber to instant-message the people you work with, but this can be made to work as an addition, in parallel to git. Backup and version management and very important in projects, so using git also allows very easy backup and control of versions and project status. And finally, using git makes changes to the application backend very easy. git allows me to play with file sharing and sync features and change the implementation, without affecting the user or resetting the user's task database or making the user create new repos/accounts/folders. - Anatoly On ג', 2013-04-02 at 12:29 -0400, Jasper St. Pierre wrote: > git isn't designed as a sharing protocol. It's a source control tool. > People have tried to take some of the versioning technology behind git > and adapt it to other things (SparkleShare, there are some git-backed > issue trackers, etc.) > > > As a simple example, what happens when you have a merge conflict? > There's a miscommunication, and one guy sets the task from OPEN to > DONE, and another guy sets it from OPEN to INPROGRESS. > > > When they try to share tasks, git is going to fail and ask them to > edit a file with: > > <<<<<<<<<<<<<<<< > > DONE > > > INPROGRESS > > >>>>>>>>>>>>>>>> > > > unless you're smart about how you present merge conflicts. > > > This is just an example, and I could come up with a large number of > other reasons why git's power is a deficiency when trying to build a > usable simple sharing system. I don't believe in the technology behind > git as a simple way to share stuff. It's too tied to source code and > programmers. I think a simple pub/sub model, either using XMPP, or an > open-source service (Snowy), or something else, is simpler and the > easier way to go. > > > > On Tue, Apr 2, 2013 at 12:25 PM, אנטולי קרסנר > wrote: > Hi, > > This is a somewhat technical question, I hope this is the > right place > for it. > > I'm writing a GTK application which manages tasks and > projects. At the > moment it's more or less like GTG (Getting Things Gnome). I > want to add > task sharing, and I've been thinking what's the right way to > do that. > > I checked what other people do. GTG uses the XMPP pubsub > extension > (publish & subscribe), which seems to do the job, but it's not > exactly > designed for sharing tasks. It does work, but it requires you > to setup > the server. > > I've been thinking and I found another idea: use a git > repository. > > This way people can easily watch how projects develop - this > way we > easily achieve the publish&subscribe capability - and sharing > tasks > between team members is as easy as working with git, which is > already > very common. Task sync is simple sync of files in the repo. > And it > doesn't require any extra work: starting a new local git repo > is > extremely easy by typing "git init", and starting a repo on a > server is > done by creating a user on gitorious and creating a repo > there. > > Some sites don't offer private repos for free, but encryption > will be > used anyway to allow maximal privacy anyway, so it shouldn't > be a >
Tools for Sharing Tasks
Hi, This is a somewhat technical question, I hope this is the right place for it. I'm writing a GTK application which manages tasks and projects. At the moment it's more or less like GTG (Getting Things Gnome). I want to add task sharing, and I've been thinking what's the right way to do that. I checked what other people do. GTG uses the XMPP pubsub extension (publish & subscribe), which seems to do the job, but it's not exactly designed for sharing tasks. It does work, but it requires you to setup the server. I've been thinking and I found another idea: use a git repository. This way people can easily watch how projects develop - this way we easily achieve the publish&subscribe capability - and sharing tasks between team members is as easy as working with git, which is already very common. Task sync is simple sync of files in the repo. And it doesn't require any extra work: starting a new local git repo is extremely easy by typing "git init", and starting a repo on a server is done by creating a user on gitorious and creating a repo there. Some sites don't offer private repos for free, but encryption will be used anyway to allow maximal privacy anyway, so it shouldn't be a problem. (GitLab offers 10 private repos for no charge if you really need 100% privacy) I'd like to hear more ideas and make a wise decision, which tool is the best one for task sharing. Git sounds very good to me, but I'm not an expert (just a software engineering student, actually). - Anatoly ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Undo system for Gnome applications
Hello, I noticed each Gnome application (Gedit, Gnote, Planner and many many more) has its own way to implement undo-redo capabilities. Is there a reason we don't use a common undo-redo interface? Even if the interface itself is very simple (and it is), using a common one minimizes code duplication, saves time and helps programs integrate. I think having an undo-redo interface in Gtk (or Glib) can be very useful, what do you think? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Question: Standard formatting of date/time strings
Hi, In Glib there's a structure GDateTime, and there's a function which converts it into a string using a given format string, passed as a parameter. (Personally I work with glibmm, i.e. I use Glib::DateTime) I'd like to convert my datetime object to a string, but how do I choose the format? I'd like to use a format knowing it's a standard common format which will suit any locale. But the documentation says nothing about standard formats. So I checked how Gedit implements the inert-time plugin, and I found an array of format strings, hard-coded. I tried to find the format Nautilus uses but I couldn't find it in the source files... Are there some standard formats I (and everybody else) could use? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
