[Elementary-dev-community] pantheon-terminal cleanup
Hi folks, I'm looking at pantheon-terminal's source code, and it seems like some of the communication paths are quite convoluted. I was wondering if it would be okay if I refactored it so that the various classes don't know so much about each other (they can communicate over signals and callbacks without having to know details about how they connect to each other--object graph assembly can be delegated to a different class). This tight integration between classes makes it difficult to reason about, which in turn makes changes difficult and drives up the risk of introducing bugs. In doing this refactoring, I would be able to add in automated tests (currently, the tight coupling of components makes testing nigh impossible). I want to run this by the maintainers first, because it will be a significant change and I want to know that there is a decent chance of my changes making it into trunk (I don't want to waste my time or yours!). Please advise. Thanks, Craig -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] Getting Started With Vala
Unfortunately, vala isn't a very easy language to get started with, and I haven't found any awesome, comprehensive resources. Personally, I couldn't figure it out until I learned C. I have quite a bit of programming experience and I really like helping people, so fire off an email if you have any specific problems or questions. Otherwise, I recommend the vala Google plus community. There's also a mailing list. On Jul 27, 2014 10:50 AM, Harris harrismru...@gmail.com wrote: Hi Elementary os Devs, I am trying to get started with programming Vala so I can give back to the Elementary community. In the past I have programmed with visual programming languages like scratch and MIT App Inventor. I started reading https://wiki.gnome.org/Projects/Vala/Tutorial but i could not finish it as it was too advanced. Do you know of any other books or tutorials that are meant for people like me with minimal coding background. Thanks, Harris -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] Getting Started With Vala
On the subject of good starter languages, python is really good and has some good starter material, but Go (golang.org) is nearly as easy and will teach you more about how things work in statically typed languages like vala, java, c#, c, c++, etc. On Jul 27, 2014 11:48 AM, David Gomes da...@elementaryos.org wrote: I beg to disagree, vala has great material - especially The Vala Tutorial and Valadoc. However, for people with little to no programming background, picking it up can be complicated as it wasn't really meant as a first-language. Having said that, what I recommend to Harris is to start off with something simpler like Python and when you're feeling more confident try The Vala Tutorial again. Have fun and good luck, David Munchor Gomes On Jul 27, 2014 5:37 PM, Craig webe...@gmail.com wrote: Unfortunately, vala isn't a very easy language to get started with, and I haven't found any awesome, comprehensive resources. Personally, I couldn't figure it out until I learned C. I have quite a bit of programming experience and I really like helping people, so fire off an email if you have any specific problems or questions. Otherwise, I recommend the vala Google plus community. There's also a mailing list. On Jul 27, 2014 10:50 AM, Harris harrismru...@gmail.com wrote: Hi Elementary os Devs, I am trying to get started with programming Vala so I can give back to the Elementary community. In the past I have programmed with visual programming languages like scratch and MIT App Inventor. I started reading https://wiki.gnome.org/Projects/Vala/Tutorial but i could not finish it as it was too advanced. Do you know of any other books or tutorials that are meant for people like me with minimal coding background. Thanks, Harris -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] Ideas for extending elementary os
That's too bad. This is one of the more interesting topics to hit the mailing list in a while. :/ On Thu, Dec 19, 2013 at 10:52 AM, Daniel Foré dan...@elementaryos.orgwrote: Hey Daniel, This list is used for developers to coordinate their efforts. If you're working on one of these projects and looking for assistance, please feel free to use this list as appropriate. However this is not the place to post a wishlist. As David pointed out, we use launchpad.net to track bug reports and plan new features. Some of the things you've listed are already being tracked on launchpad. Thanks for understanding. Cheers, Daniel Foré elementaryos.org On Thu, Dec 19, 2013 at 5:03 AM, Daniel Schöni dschoen...@gmail.comwrote: Hello together I want to share my ideas for extending elementary os. 1. Shortcut-Definitions Keyboard-Shortcuts should be defined in the HIG. All Applications should have the same shortcuts for the same actions (create, open, close element etc.). A non-conform shortcut should be handled as a bug. 2. New Applications There are some applications who are not part of elementary os and definitely should be a part of: * Task-Manager * Office-Suite (I know, a long-term-goal) There are some application who are not part of elementary os and would be good extensions: * Development IDE * Ebook Reader * Note-taking application like Tomboy 3. New Features Noise: * Internet-Radio Geary: * RSS-Feeds Every application who can share objects with other devices (smartphones etc.) should have a sync-feature. (Geary, Friends, Calendar, Noise, MoviePlayer, Shotwell). just adding my two cents ;-) greets Daniel -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] about TDD (Test Driven Development)
What do you mean real apps? As long as the code executes, I don't see the value in the distinction. On Sep 3, 2013 2:30 PM, David Gomes da...@elementaryos.org wrote: also we're not talking on mere theory or philosophy; we posted real code, examples and documentation; also real-life experience. This is a sane discussion. We don't need hypothetical examples on hypothetical apps, we want real examples on real apps. On Tue, Sep 3, 2013 at 4:08 PM, Daniele S. oppifjel...@gmail.com wrote: Sergey, Autopilot and Unit tests are not the same thing. In fact, from the same Autopilot documentation: Autopilot exists at the apex of the “testing pyramid”. It is designed to test high-level functionality, and complement a solid base of unit and integration tests. *Using autopilot is not a substitute for testing your application with unit and integration tests!*. Autopilot is a very capable tool for testing high-level feature functionality. It is not an appropriate tool for testing low-level implementation details. also we're not talking on mere theory or philosophy; we posted real code, examples and documentation; also real-life experience. This is a sane discussion. BR, Daniele 2013/9/3 Sergey Shnatsel Davidoff ser...@elementaryos.org Please make your energy useful in more useful ways Dear TTD proponents, while you keep spending lots of time on writing these mails and the time of all the other devs on reading them, ~alourie is looking into Autopilot and experimenting with writing tests using it. I encourage you to follow his example. Please stop wasting everyone's time and go read Autopilot tutorialhttp://unity.ubuntu.com/autopilot/tutorial/tutorial.htmland write some tests instead of emails. You can find existing tests for GTK apps herehttps://code.launchpad.net/~ubuntu-testcase/ubuntu-autopilot-tests/trunkshall you need them. You can meet ~alourie in #elementary-dev if you want to catch up with what he's found so far. He's online most of the time, just keep in mind he's in GMT+4 timezone. -- Sergey Shnatsel Davidoff OS architect @ elementary -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] Luna +1's Name and Some Other Stuff
So I'd probably start off by getting rid of all the technical debt we might have accumulated in the race to release and getting some tools to manage the increased complexity we're facing, e.g. unifying the way CMake works, providing better code documentation, adding some automated testing, etc. I'm so proud I could cry. *tear*. I support this message. On Aug 25, 2013 6:49 AM, Sergey Shnatsel Davidoff ser...@elementaryos.org wrote: Yay, bike shedding! Wait for me! AFAIR the original plan was to use gods from the same pantheon for any given series, Roman for the 0.x series specifically, hence the name of the DE - Pantheon. So I looked for suitable Roman deities and I think I've found a great one. Continuing the trend, she's a Roman deity and has a celestial body in the Solar system named after her. What's more, according to a myth that was very widespread in late antiquity, she eventually moved to Egypt and became Isis! Behold Io! The Roman Isis that comes with a celestial body and a domain name hack! http://en.wikipedia.org/wiki/Io_%28mythology%29 http://en.wikipedia.org/wiki/Io_%28moon%29 By the way, turns out http://elementary.io is already registered by Cassidy and currently redirects to elementaryos.org, so I feel like this was the plan all along. As for development, we have ~8 months till release, so this is going to be an iterative cycle. We're obviously not going for Wayland or Mir or anything equally new and fancy because that technology is not yet baked and will not be on par with the time-proven base by 14.04. It does look like we'll have another huge migration on our hands after that, though. So I'd probably start off by getting rid of all the technical debt we might have accumulated in the race to release and getting some tools to manage the increased complexity we're facing, e.g. unifying the way CMake works, providing better code documentation, adding some automated testing, etc. Next, since we're making an iterative cycle, I'd stop acting and start reacting. Like, make a list of things that people have trouble with in Luna and fix them. I have compiled an [incomplete] list of gripes people seem to have with Luna. Maybe we should run some user testing and see what causes issues? We can't afford organized user testing, but we could reach out to the community - say, provide people with testing methodology and ask people who spread elementary OS to carry out the testing and send in the results. Like run a user testing sprint to identify the issues the target audience has, and fix them. Sounds like a plan! Long live Io! -- Sergey Shnatsel Davidoff OS architect @ elementary -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] Luna +1's Name and Some Other Stuff
Calm down, I was kidding. But I really support keeping quality high while minimizing developer workload. Carry on. On Aug 25, 2013 9:01 AM, Sergey Shnatsel Davidoff ser...@elementaryos.org wrote: Oh God, this is turning into yet another TTD thread! Please, keep the TTD holywar out of here. You have your own cozy thread just for that. Three of them, in fact. -- Sergey Shnatsel Davidoff OS architect @ elementary -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] Congratulations Luna developers!
Alex, Perhaps you're right. My primary concern is that I think someone needs to have the authority to reject low-quality changes (for example, those without tests. This *could* be me, but I would like to hand this proposed pilot project off to someone else and (hopefully) move on to coach a different project. For the time being, I'll start looking for promising projects. Thanks, Craig On Aug 22, 2013 12:55 AM, Alex Lourie djay...@gmail.com wrote: Craig It seems we're running circles. No leader is needed now aside for someone who starts writing code. How about you choose some an app you consider to be a good start? We then find volunteers. And start coding. I'm sure that the moment it starts, everyone will be interested in results. On Aug 22, 2013 3:27 AM, Craig webe...@gmail.com wrote: I'm not opposed; however, every time I've delved into Elementary development, I've found myself fighting too many tertiary fires before I'm able to get any real work done (usually it's chasing down one obscure environment issue or another). So basically, I would like someone who is competent at Elementary development to champion the project (to serve as its leader) and I and a few other TDDevelopers can coach the development team as well as help develop ourselves. Furthermore, this exercise will be more productive if we have other devs who are interested in *learning* TDD to participate. So basically, if you can find a few elementary-proficient developers to help with the elementary-specific problems (including a project lead), the other TDDevelopers and I can coach and develop along side them. Thoughts? On Wed, Aug 21, 2013 at 4:50 PM, Kurt Smolderen kurt.smolde...@empuly.net wrote: What do you think of giving Footnote some love? I think it is currently unmaintained (need to verify that), it's conceptually a rather simple application but offers a good set of practices for TDD/ writing tests. We need to verify first of course what the intentions of the current owner are, but I would personally like to see a new version of Footnote... Craig webe...@gmail.com wrote: I have never heard a project die because they decided to move to TDD. And I heard about lots of hits on the matter. This. I've heard (and witnessed) a lot of projects drop their defect percentage from 20% to 3%. A lot of new-to-TDD developers don't like it at first because it feels slower, but I don't think those people remember how much time is spent bug hunting at the end of a release cycle. I think the next step is to find a pilot project and get the lead developer(s) to agree to work toward TDD. This will probably look like: 1) Modifying the project structure to include _test directories 2) Creating tests with GLib.Test or some such 3) Coaching/mentoring the developers at TDD 4) Performing code reviews in which insufficiently tested code is sent back for revision After testing it out for a few months, the community can see how they like it. Does this sound like a reasonable approach? If so, would any project leads like to volunteer their project? And who in the community would like to participate in such an experiment? On Wed, Aug 21, 2013 at 4:34 AM, Alex Lourie djay...@gmail.com wrote: Albert We don't need to exaggerate. Though TDD is, indeed, a development methodology, it is not supposed to completely change the way everyone works. Just consider that writing a good test takes about 10 minutes, and that each developer writes one or two tests for new stuff they add (or the old one they fix) from time to time. Then, in time, you'll have part of your code tested, which is exactly what we're aiming for. Beginning is hard, continue something is easier. I have never heard a project die because they decided to move to TDD. And I heard about lots of hits on the matter. On Tue, Aug 20, 2013 at 3:37 AM, Albert Palacios optimi...@gmail.com wrote: Hi Craig, Thanks for your explanation and the linked video. I am still agnostic, but I don't want to be the only one who complained about the proposal. At this point I have more questions than answers, and those will probably be solved with a working example. But remember, *TDD is a development methodology* not a testing methodology. It will change our development work flow, and will probably move potential volunteers away from the project. TDD like every other development methodology does not fit every project or team. It can be a hit, and it can even the death of the project. Albert On Tue, Aug 20, 2013 at 12:50 AM, Craig webe...@gmail.com wrote: Hi Albert, Thanks for your response, you asked a lot of great questions. In addition to Gufran's earlier response. Can you prove that there will be huge benefits in time/resources? Well, that depends on what you consider proof. In the spring, my company paid several thousand dollars to send me to a conference in San Jose in which many software
Re: [Elementary-dev-community] Congratulations Luna developers!
Hi Dane, Thanks for your reply. In a perfect world, I would have the time to do all of those things, unfortunately, the best I can offer is my experience and whatever coding time I have left over. Being an adult is a drag sometimes. I don't have time to learn a new application (and development environment) or drive its development. Moreover, I didn't champion (as you say) this email thread for my own benefit, but for the benefit of those who *have time * to develop elementary (because TDD is, after all, a tool to facilitate development). I am passionate about helping *developers*; however, I can only help those who want to learn. I don't have the resources to do more than coach; however, I don't think coaching is giving up or passing the baton. It just isn't being the primary developer. Even if I could do the work, I can have a little impact by using TDD to work efficiently, but I can have a much broader impact by showing others how to use TDD to improve *their own* efficiency. I don't doubt that there's value in leading by example, but I don't see that being a possibility for some time. Regarding your app, I'm happy to help you find better ways to test. I'm sure we can work out a time to do a hang out. Just let me know when works for you. To anyone else who is interested, I'm happy to answer any questions about TDD or other matters pertaining to software development. If you would like to implement testing on any projects you're involved in, please hang me a line! Thanks again, Craig On Thu, Aug 22, 2013 at 7:38 AM, Dane Henson (elementary) d...@elementaryos.org wrote: Craig, I don't think this is something you can just hand off. You championed this to a 60+ e-mail thread and you just expect someone else to pick up the banner? My old pastor had a saying: See the need, fill the need. If you feel this passionate about helping elementary, I know you can get over your GoLang tendencies and jump on the Vala bandwagon to at least act as a project manager. Here are some practical examples that we can start with: 1. The Vala language itself uses Unit testing without a framework, and they use a bash script to run them. Prolific Unit Test experts have said that it doesn't matter if you use a framework or not, just test! https://git.gnome.org/browse/vala/tree/tests 2. I pulled sources from all over the internet to create a half-baked project with testing built in using GLib.Test and Gee.TestCase. This has appeared on this mailing list before and could be a reasonable beginning. https://code.launchpad.net/~thegreatdane/+junk/agenda-tests 3. I'm working on a small project that I'll eventually put in a repository. It has the potential to be a good Unit Testing example. My problem is I need help knowing what is good to test, and what is redundant or unnecessary. We need practical knowledge, and you have it! I would be glad to do a hangout with you sometime (not today unfortunately) and get this stuff going. Don't give up or pass the baton. You brought it up, you need to follow through. On Thu, Aug 22, 2013 at 12:55 AM, Alex Lourie djay...@gmail.com wrote: Craig It seems we're running circles. No leader is needed now aside for someone who starts writing code. How about you choose some an app you consider to be a good start? We then find volunteers. And start coding. I'm sure that the moment it starts, everyone will be interested in results. On Aug 22, 2013 3:27 AM, Craig webe...@gmail.com wrote: I'm not opposed; however, every time I've delved into Elementary development, I've found myself fighting too many tertiary fires before I'm able to get any real work done (usually it's chasing down one obscure environment issue or another). So basically, I would like someone who is competent at Elementary development to champion the project (to serve as its leader) and I and a few other TDDevelopers can coach the development team as well as help develop ourselves. Furthermore, this exercise will be more productive if we have other devs who are interested in *learning* TDD to participate. So basically, if you can find a few elementary-proficient developers to help with the elementary-specific problems (including a project lead), the other TDDevelopers and I can coach and develop along side them. Thoughts? On Wed, Aug 21, 2013 at 4:50 PM, Kurt Smolderen kurt.smolde...@empuly.net wrote: What do you think of giving Footnote some love? I think it is currently unmaintained (need to verify that), it's conceptually a rather simple application but offers a good set of practices for TDD/ writing tests. We need to verify first of course what the intentions of the current owner are, but I would personally like to see a new version of Footnote... Craig webe...@gmail.com wrote: I have never heard a project die because they decided to move to TDD. And I heard about lots of hits on the matter. This. I've heard (and witnessed) a lot of projects drop
Re: [Elementary-dev-community] Congratulations Luna developers!
Hi Dane, I didn't take it hostilely :) And I didn't mean to say I was busier than anyone else; I'm just a lot busier than I used to be I suppose. Let's talk sometime. Email me off the list and we'll sort it out. With that, I think we can conclude this thread. Have a good night everyone, Craig On Thu, Aug 22, 2013 at 6:48 PM, Dane Henson d...@elementaryos.org wrote: I knew that would light a fire, but I didn't intend it to be hostile. I have a full-time job (not programming), a 3-year-old and a pregnant wife due in two weeks. I think I know a little about adult responsibilities and time balance. We do need to Skype/Hangout soon. I have a feeling you and I would get along famously and maybe we can get something started instead of just talking in circles. On Aug 22, 2013 4:33 PM, Craig webe...@gmail.com wrote: Hi Dane, Thanks for your reply. In a perfect world, I would have the time to do all of those things, unfortunately, the best I can offer is my experience and whatever coding time I have left over. Being an adult is a drag sometimes. I don't have time to learn a new application (and development environment) or drive its development. Moreover, I didn't champion (as you say) this email thread for my own benefit, but for the benefit of those who *have time* to develop elementary (because TDD is, after all, a tool to facilitate development). I am passionate about helping *developers*; however, I can only help those who want to learn. I don't have the resources to do more than coach; however, I don't think coaching is giving up or passing the baton. It just isn't being the primary developer. Even if I could do the work, I can have a little impact by using TDD to work efficiently, but I can have a much broader impact by showing others how to use TDD to improve *their own* efficiency. I don't doubt that there's value in leading by example, but I don't see that being a possibility for some time. Regarding your app, I'm happy to help you find better ways to test. I'm sure we can work out a time to do a hang out. Just let me know when works for you. To anyone else who is interested, I'm happy to answer any questions about TDD or other matters pertaining to software development. If you would like to implement testing on any projects you're involved in, please hang me a line! Thanks again, Craig On Thu, Aug 22, 2013 at 7:38 AM, Dane Henson (elementary) d...@elementaryos.org wrote: Craig, I don't think this is something you can just hand off. You championed this to a 60+ e-mail thread and you just expect someone else to pick up the banner? My old pastor had a saying: See the need, fill the need. If you feel this passionate about helping elementary, I know you can get over your GoLang tendencies and jump on the Vala bandwagon to at least act as a project manager. Here are some practical examples that we can start with: 1. The Vala language itself uses Unit testing without a framework, and they use a bash script to run them. Prolific Unit Test experts have said that it doesn't matter if you use a framework or not, just test! https://git.gnome.org/browse/vala/tree/tests 2. I pulled sources from all over the internet to create a half-baked project with testing built in using GLib.Test and Gee.TestCase. This has appeared on this mailing list before and could be a reasonable beginning. https://code.launchpad.net/~thegreatdane/+junk/agenda-tests 3. I'm working on a small project that I'll eventually put in a repository. It has the potential to be a good Unit Testing example. My problem is I need help knowing what is good to test, and what is redundant or unnecessary. We need practical knowledge, and you have it! I would be glad to do a hangout with you sometime (not today unfortunately) and get this stuff going. Don't give up or pass the baton. You brought it up, you need to follow through. On Thu, Aug 22, 2013 at 12:55 AM, Alex Lourie djay...@gmail.com wrote: Craig It seems we're running circles. No leader is needed now aside for someone who starts writing code. How about you choose some an app you consider to be a good start? We then find volunteers. And start coding. I'm sure that the moment it starts, everyone will be interested in results. On Aug 22, 2013 3:27 AM, Craig webe...@gmail.com wrote: I'm not opposed; however, every time I've delved into Elementary development, I've found myself fighting too many tertiary fires before I'm able to get any real work done (usually it's chasing down one obscure environment issue or another). So basically, I would like someone who is competent at Elementary development to champion the project (to serve as its leader) and I and a few other TDDevelopers can coach the development team as well as help develop ourselves. Furthermore, this exercise will be more productive if we have other devs who are interested in *learning* TDD to participate. So basically, if you can
Re: [Elementary-dev-community] Congratulations Luna developers!
I have never heard a project die because they decided to move to TDD. And I heard about lots of hits on the matter. This. I've heard (and witnessed) a lot of projects drop their defect percentage from 20% to 3%. A lot of new-to-TDD developers don't like it at first because it feels slower, but I don't think those people remember how much time is spent bug hunting at the end of a release cycle. I think the next step is to find a pilot project and get the lead developer(s) to agree to work toward TDD. This will probably look like: 1) Modifying the project structure to include _test directories 2) Creating tests with GLib.Test or some such 3) Coaching/mentoring the developers at TDD 4) Performing code reviews in which insufficiently tested code is sent back for revision After testing it out for a few months, the community can see how they like it. Does this sound like a reasonable approach? If so, would any project leads like to volunteer their project? And who in the community would like to participate in such an experiment? On Wed, Aug 21, 2013 at 4:34 AM, Alex Lourie djay...@gmail.com wrote: Albert We don't need to exaggerate. Though TDD is, indeed, a development methodology, it is not supposed to completely change the way everyone works. Just consider that writing a good test takes about 10 minutes, and that each developer writes one or two tests for new stuff they add (or the old one they fix) from time to time. Then, in time, you'll have part of your code tested, which is exactly what we're aiming for. Beginning is hard, continue something is easier. I have never heard a project die because they decided to move to TDD. And I heard about lots of hits on the matter. On Tue, Aug 20, 2013 at 3:37 AM, Albert Palacios optimi...@gmail.comwrote: Hi Craig, Thanks for your explanation and the linked video. I am still agnostic, but I don't want to be the only one who complained about the proposal. At this point I have more questions than answers, and those will probably be solved with a working example. But remember, *TDD is a development methodology* not a testing methodology. It will change our development work flow, and will probably move potential volunteers away from the project. TDD like every other development methodology does not fit every project or team. It can be a hit, and it can even the death of the project. Albert On Tue, Aug 20, 2013 at 12:50 AM, Craig webe...@gmail.com wrote: Hi Albert, Thanks for your response, you asked a lot of great questions. In addition to Gufran's earlier response. Can you prove that there will be huge benefits in time/resources? Well, that depends on what you consider proof. In the spring, my company paid several thousand dollars to send me to a conference in San Jose in which many software development authorities recited, test driven development pays itself off in iteration 0. That means the very first time you write the code it has already paid for itself (because even before you get the automatic-regression testing benefits, you've already got the benefits of a better architecture and documentation--because the tests _are_ the documentation!). I'm sure I can dig up lots of other resources, but I think it should suffice to say that I've never heard an expert comment on TDD except to say it's fastest way to develop quality software. For more information addressing your specific concerns, see the Wikipedia article's benefits section (and read on to the shortcomings as it is also relevant: http://en.wikipedia.org/wiki/Test-driven_development#Benefits. Even more importantly, this short video: http://www.youtube.com/watch?v=DodJQyHsmHI Can you prove that there will be less bugs? (looks like that if tests are not right, bugs will populate equally). It's pretty hard to write bad tests if you're practicing TDD, because you write the test first, watch it fail, insert the code you need to make it pass, and then hopefully watch it pass. If you wrote a bad test, it very probably will pass before you've written the code to make it pass (which serves to alert the programmer that his test is bad or his software is doing something unexpected) or the test will fail after he has correctly written the next line of code (which serves to alert the programmer to review both the code and his test and identify the source of the problem). For this reason alone, many, many bugs are eliminated. From what's been said, looks like there will be an extra effort on development, adding complexity and more tools to know (not to say maintain). Besides the initial learning curve, development actually goes _faster_ with TDD (see the aforementioned Wikipedia article--I can provide more resources on demand) because debugging time becomes exponentially more expensive as time passes after the bug has been introduced. This is because the bug can live anywhere in any code that has been added *since the last time
Re: [Elementary-dev-community] Congratulations Luna developers!
Hmm, that's a good point. While the barrier to entry is very high right now, we could move some of that difficulty from things like simple installation (I can't remember the last time following the installation instructions yielded a successful build/install) to things that help improve our quality. If it has to be hard it may as well be hard for a reason. Anyway, even if we do reject a bug fix for lack of testing, at least the hard work of finding the bug is done for us. From there, we can use the opportunity to teach the submitter how to test or, in the worst case, write the test ourselves and implement the fix (since the rejected fix points is to the cause of the bug). I'm sure there will be some complications in practice, but it will move us a step closer to quality and it will allow us to focus on implementing new features rather than bug hunting. That might be enough in its own right to attract developers (and likely talented ones at that!). Agree with Julian. TDD is best suited when the software is developed using agile development methodology. For something like elementary os, which is community driven, TDD might not be practical. But writing test cases is a must I believe. That way with regression testing it might make debugging new bugs, which occurs when new features are added will get a lot easier. On Wed, Aug 21, 2013 at 9:45 PM, Julien spautz.jul...@gmail.com wrote: So if I'm not mistaken, TDD requires you to write tests *before*implementing something. This might work well for teams with enough developers that don't have to rely on volunteers and drive-by contributors, but I don't see this working out for elementary, at least not at this point. Many contributors fix a few small bugs here and there and don't have much experience with development, which is why we try to keep the entry barrier really low for new devs. When I started here, I had no experience with Vala, Gtk and Launchpad at all, and I just fixed some easy bugs, implemented some small features in various apps and so on. If we used TDD, we would have to reject most code by new devs, because they didn't implement tests, and then we'll have to explain to them how to use tests, and then they'll have to write tests, but that's bad because you have to write them before you write the actual code ... It's going to be a mess. What might work are regular unit tests, implemented by people who kind of know what they're doing (we need some documentation for that, maybe add it to the dev guide). This will give us some of the TDD benefits w/o deterring potential new devs. On Wed, Aug 21, 2013 at 3:29 PM, Craig webe...@gmail.com wrote: I have never heard a project die because they decided to move to TDD. And I heard about lots of hits on the matter. This. I've heard (and witnessed) a lot of projects drop their defect percentage from 20% to 3%. A lot of new-to-TDD developers don't like it at first because it feels slower, but I don't think those people remember how much time is spent bug hunting at the end of a release cycle. I think the next step is to find a pilot project and get the lead developer(s) to agree to work toward TDD. This will probably look like: 1) Modifying the project structure to include _test directories 2) Creating tests with GLib.Test or some such 3) Coaching/mentoring the developers at TDD 4) Performing code reviews in which insufficiently tested code is sent back for revision After testing it out for a few months, the community can see how they like it. Does this sound like a reasonable approach? If so, would any project leads like to volunteer their project? And who in the community would like to participate in such an experiment? On Wed, Aug 21, 2013 at 4:34 AM, Alex Lourie djay...@gmail.com wrote: Albert We don't need to exaggerate. Though TDD is, indeed, a development methodology, it is not supposed to completely change the way everyone works. Just consider that writing a good test takes about 10 minutes, and that each developer writes one or two tests for new stuff they add (or the old one they fix) from time to time. Then, in time, you'll have part of your code tested, which is exactly what we're aiming for. Beginning is hard, continue something is easier. I have never heard a project die because they decided to move to TDD. And I heard about lots of hits on the matter. On Tue, Aug 20, 2013 at 3:37 AM, Albert Palacios optimi...@gmail.comwrote: Hi Craig, Thanks for your explanation and the linked video. I am still agnostic, but I don't want to be the only one who complained about the proposal. At this point I have more questions than answers, and those will probably be solved with a working example. But remember, *TDD is a development methodology* not a testing methodology. It will change our development work flow, and will probably move potential volunteers away from the project. TDD like every other development methodology
Re: [Elementary-dev-community] Other languages? (Was Re: Congratulations Luna developers!)
Vala can target Windows and OSX last I checked. Also, Elementary can run apps written in non-Vala languages. Of course, it's not supported because Elementary's development resources are spread so thin and many developers here don't have expansive experience in other languages. On Wed, Aug 21, 2013 at 4:14 PM, Jakob Eriksson ja...@aurorasystems.euwrote: On 2013-08-21 22:59, A. Xylon V. wrote: The thing about vala is that its simple enough to learn, but is still very powerful and is extremely fast. The best thing is that it was made for Gtk, which is perfect for elementary. More languages would mean that we wouldn't have unity across the applications - I do however, think that this would attract developers, especially since vala does not have very good tutorials, or books. That is an understatement. Not having support for other languages is sort of insane. Scenario: I am a developer. I develop an application for Windows and, against commercial reason, make a Linux version of it too. It's coded in a mix of C++ and Python. I think Elementary is just fantastic, so just out of love I want to make my Linux app an Elementary version. I read the HIG and love it. Then I go to http://elementaryos.org/docs/code on the FIRST page I read: If you're not familiar with Vala, we highly encourage you to brush up on it before coming here. Sorry say what? No, not going to happen. I can't redo my app in Vala, even if I wanted to, because that means I can't run it on Windows. (Or OSX, or iOS.) The dev page should read something like for Elementary core apps we use Vala as a programming language. If you want to create your own Elementary apps, we encourage you to try out Vala, which is a fantastic language. If you want to use another language, that's fine too. Here are example Hello World Elementary apps written in C++, Objective C, Python and Ruby. --jakob -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] Other languages? (Was Re: Congratulations Luna developers!)
To get this conversation back on topic, I'm experimenting with developing Gtk apps in Go (http://golang.org). Once I have that mastered, it shouldn't be too hard to make Granite apps given that Granite compiles to C. And Go is probably only a little slower than Vala but a lot more user friendly (the barrier to entry is a LOT lower, simpler design, better tooling, bigger community, etc). If you're interested in experimenting with me, let me know. On Wed, Aug 21, 2013 at 3:54 PM, Jakob Eriksson ja...@aurorasystems.euwrote: On 2013-08-21 22:35, Kurt Smolderen wrote: look at the code. As Vala is currently missing a decent IDE (such as Eclipse,...) and debugging isn't as easy due to the fact the code is translated into C, its often very difficult to analyse the flow of a program. Available tests might help this initial contributors with And when will it be blessed to create Elementary apps in another language than Vala? If Elementary would open up to other languages, we could REALLY see increased productivity and more contributors. IMHO Objective C, C++ and maybe even Java via GCJ would be the obvious candidates. --jakob -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] Congratulations Luna developers!
I'm not opposed; however, every time I've delved into Elementary development, I've found myself fighting too many tertiary fires before I'm able to get any real work done (usually it's chasing down one obscure environment issue or another). So basically, I would like someone who is competent at Elementary development to champion the project (to serve as its leader) and I and a few other TDDevelopers can coach the development team as well as help develop ourselves. Furthermore, this exercise will be more productive if we have other devs who are interested in *learning* TDD to participate. So basically, if you can find a few elementary-proficient developers to help with the elementary-specific problems (including a project lead), the other TDDevelopers and I can coach and develop along side them. Thoughts? On Wed, Aug 21, 2013 at 4:50 PM, Kurt Smolderen kurt.smolde...@empuly.netwrote: What do you think of giving Footnote some love? I think it is currently unmaintained (need to verify that), it's conceptually a rather simple application but offers a good set of practices for TDD/ writing tests. We need to verify first of course what the intentions of the current owner are, but I would personally like to see a new version of Footnote... Craig webe...@gmail.com wrote: I have never heard a project die because they decided to move to TDD. And I heard about lots of hits on the matter. This. I've heard (and witnessed) a lot of projects drop their defect percentage from 20% to 3%. A lot of new-to-TDD developers don't like it at first because it feels slower, but I don't think those people remember how much time is spent bug hunting at the end of a release cycle. I think the next step is to find a pilot project and get the lead developer(s) to agree to work toward TDD. This will probably look like: 1) Modifying the project structure to include _test directories 2) Creating tests with GLib.Test or some such 3) Coaching/mentoring the developers at TDD 4) Performing code reviews in which insufficiently tested code is sent back for revision After testing it out for a few months, the community can see how they like it. Does this sound like a reasonable approach? If so, would any project leads like to volunteer their project? And who in the community would like to participate in such an experiment? On Wed, Aug 21, 2013 at 4:34 AM, Alex Lourie djay...@gmail.com wrote: Albert We don't need to exaggerate. Though TDD is, indeed, a development methodology, it is not supposed to completely change the way everyone works. Just consider that writing a good test takes about 10 minutes, and that each developer writes one or two tests for new stuff they add (or the old one they fix) from time to time. Then, in time, you'll have part of your code tested, which is exactly what we're aiming for. Beginning is hard, continue something is easier. I have never heard a project die because they decided to move to TDD. And I heard about lots of hits on the matter. On Tue, Aug 20, 2013 at 3:37 AM, Albert Palacios optimi...@gmail.comwrote: Hi Craig, Thanks for your explanation and the linked video. I am still agnostic, but I don't want to be the only one who complained about the proposal. At this point I have more questions than answers, and those will probably be solved with a working example. But remember, *TDD is a development methodology* not a testing methodology. It will change our development work flow, and will probably move potential volunteers away from the project. TDD like every other development methodology does not fit every project or team. It can be a hit, and it can even the death of the project. Albert On Tue, Aug 20, 2013 at 12:50 AM, Craig webe...@gmail.com wrote: Hi Albert, Thanks for your response, you asked a lot of great questions. In addition to Gufran's earlier response. Can you prove that there will be huge benefits in time/resources? Well, that depends on what you consider proof. In the spring, my company paid several thousand dollars to send me to a conference in San Jose in which many software development authorities recited, test driven development pays itself off in iteration 0. That means the very first time you write the code it has already paid for itself (because even before you get the automatic-regression testing benefits, you've already got the benefits of a better architecture and documentation--because the tests _are_ the documentation!). I'm sure I can dig up lots of other resources, but I think it should suffice to say that I've never heard an expert comment on TDD except to say it's fastest way to develop quality software. For more information addressing your specific concerns, se e the Wikipedia article's benefits section (and read on to the shortcomings as it is also relevant: http://en.wikipedia.org/wiki/Test-driven_development#Benefits. Even more importantly, this short video: http
Re: [Elementary-dev-community] Congratulations Luna developers!
This is cool and important, but I don't think it should stop the discussion on test driven development. Perhaps this could be a separate thread? It doesn't sound as though anyone is opposed to TDD, so can we confirm that? And if no one is opposed, how can we proceed? Can we start some kind of a testing committee to help determine what testing steps are needed, what framework to use, and how to integrate testing into the existing project structure (i.e., using CMake)? Does this sound like a good plan? Thoughts? On Mon, Aug 19, 2013 at 12:05 PM, David Gomes da...@elementaryos.orgwrote: I'll work on it, so far we only have this I made: https://dl.dropboxusercontent.com/u/19899464/reviewstutorial.html On Mon, Aug 19, 2013 at 6:01 PM, Albert Palacios optimi...@gmail.comwrote: Hi Munchor, A contribution / bug fixing step by step guide is needed at the developers site. There was a .pdf before the new site change, but now it is impossible to find. The problem with the old guide is that it encouraged to create your own branch instead of using the ~elementary-dev-community one (this is totally new for me). Obviously, bazaar guides doesn't teach you on using the elementary-dev-community. On Mon, Aug 19, 2013 at 6:57 PM, David Gomes da...@elementaryos.orgwrote: I always tell people if they make their branches owned by ~elementary-dev-community I will volunteer to fix the code style myself. I have all the free time and the will to do it, just people always make their branches owned by themselves. ~David Munchor Gomes On Mon, Aug 19, 2013 at 4:29 PM, Albert Palacios Jimenez optimi...@gmail.com wrote: Hi, Before talking about testing, and advanced development techniques for teams with resources, there is one easy and simple thing we can do to accelerate development. Sometimes (very often), bugs are stopped due spaces not following the code style guidelines. Adding a code style validator script before compiling, we can prevent uploads with spaces at the end of the lines ... and save a lot of time. For example, just executing the next line before compiling: find . -type f -print0 | xargs -0 sed -i 's/[ \t]*$//' We will remove every white space at the end of any line, including new lines with tab spaces. This can sound stupid, but it is absurd to block bug fixes during several days due white spaces at the end of lines. -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] Congratulations Luna developers!
Hi Albert, Thanks for your response, you asked a lot of great questions. In addition to Gufran's earlier response. Can you prove that there will be huge benefits in time/resources? Well, that depends on what you consider proof. In the spring, my company paid several thousand dollars to send me to a conference in San Jose in which many software development authorities recited, test driven development pays itself off in iteration 0. That means the very first time you write the code it has already paid for itself (because even before you get the automatic-regression testing benefits, you've already got the benefits of a better architecture and documentation--because the tests _are_ the documentation!). I'm sure I can dig up lots of other resources, but I think it should suffice to say that I've never heard an expert comment on TDD except to say it's fastest way to develop quality software. For more information addressing your specific concerns, see the Wikipedia article's benefits section (and read on to the shortcomings as it is also relevant: http://en.wikipedia.org/wiki/Test-driven_development#Benefits. Even more importantly, this short video: http://www.youtube.com/watch?v=DodJQyHsmHI Can you prove that there will be less bugs? (looks like that if tests are not right, bugs will populate equally). It's pretty hard to write bad tests if you're practicing TDD, because you write the test first, watch it fail, insert the code you need to make it pass, and then hopefully watch it pass. If you wrote a bad test, it very probably will pass before you've written the code to make it pass (which serves to alert the programmer that his test is bad or his software is doing something unexpected) or the test will fail after he has correctly written the next line of code (which serves to alert the programmer to review both the code and his test and identify the source of the problem). For this reason alone, many, many bugs are eliminated. From what's been said, looks like there will be an extra effort on development, adding complexity and more tools to know (not to say maintain). Besides the initial learning curve, development actually goes _faster_ with TDD (see the aforementioned Wikipedia article--I can provide more resources on demand) because debugging time becomes exponentially more expensive as time passes after the bug has been introduced. This is because the bug can live anywhere in any code that has been added *since the last time the tests were run* and because the programmer will have an increasingly difficult time remembering the code he wrote at the time of the bug as time progresses. With TDD, you are running the tests after every change (generally you test every time you build), so as soon as you've broken something you find out about it. This means that the bug is guaranteed to live in the last change you made, which is a smaller sample and fresher-in-your-mind than changes you made weeks ago. Regarding your complexity concern, generally the process isn't complex (it's actually very simple) and it _simplifies_ development once you learn how to do it. The most complex part is figuring out how to integrate testing into the CMake project, and that's only complicated because CMake is complicated. Regarding tools, there are already testing tools available for Vala, including GLib (so we don't have to maintain anything). Anyway, testing tools don't take a terribly long time to learn. Can we focus on the half done things before adding new projects? Granite is not ready, documentation is missing, not to talk about the bugs that survived Luna release ... TDD is more valuable the sooner you start implementing it. Even if you didn't write tests for old code and only started TDD with new code (and existing defects), you would be doing yourself a huge favor. I'm not suggesting that everyone stop what they're doing and go back and test every line of code (although it would be a good thing to chip away at over time), but practicing TDD on _new_ code can't hurt that much, can it? With that in mind, are there any arguments against TDD that outweigh its merits? Thanks again for your questions! :) Craig On Mon, Aug 19, 2013 at 12:32 PM, Albert Palacios optimi...@gmail.comwrote: Hi Craig and Gufran, I don't agree with TDD, and making a committee. Can you prove that there will be huge benefits in time/resources? Can you prove that there will be less bugs? (looks like that if tests are not right, bugs will populate equally). Can you prove that creating, modifying and fixing code is going to be easier? From what's been said, looks like there will be an extra effort on development, adding complexity and more tools to know (not to say maintain). Can we focus on the half done things before adding new projects? Granite is not ready, documentation is missing, not to talk about the bugs that survived Luna release ... On Mon, Aug 19, 2013 at 7:27 PM, Gufran dogab...@gmail.com wrote: Count me
[Elementary-dev-community] Congratulations Luna developers!
Hello, I posted the following message on Google Plus yesterday, but it occurred to me that the weekend may not be prime time for checking that social network. I think this message is pretty important, so I want to post it again here: (I apologize in advance for its length) Congratulations to all the developers who made Luna such a success! You've done a great job and delivered an incredible Linux experience! I know I bring this up periodically, but I'm concerned that Luna + 1 and future releases will take more and more time to release, and/or that you will quickly reach a ceiling with respect to the amount of code we'll be able to maintain before quality degrades. The cause for my concern is the nature of complexity: as software grows (that is, as code is added), bugs grow exponentially (complexity increases exponentially with logic, and bugs grow linearly with complexity). If we don't start working toward solutions that will scale with this problem, we **will** hit a ceiling with respect to the amount of complexity we will be able to support (this means fewer features or less-powerful features). I promise. I know some in the community are working toward this goal, but I think it's going to take a concerted effort on the part of the developers to take this problem seriously. I urge you all to take this problem as seriously as you take the rest of the user experience (because bugs are, at the end of the day, a sharp degradation of the user experience). In my experience, the silver bullet for combating this problem is test driven development. If you look around the software development industry, code is improving, and it's largely because TDD is catching on. And Google is a good role model in this regard (not just for us, but for everyone--they are pioneers of code quality). If you're a developer and you're unfamiliar with TDD, take some time and research it. It will pay dividends immediately. If you have any questions about development, I'm happy to provide my advice as a professional developer. Also, read up on Google's testing strategies (I recommend http://www.amazon.com/Google-Tests-Software-James-Whittaker/dp/0321803027_How Google Tests Software_). You guys are a _great_ UX shop, now let's become a great code shop. I hope this analogy doesn't offend anyone who is passionate about their tech brands, but my advice is this: Design like Apple, develop like Google. I really push you developers to continue to strive to hone your craft the way Daniel and Cassidy (and any other UX designers) are learning to hone theirs. P.S., Sorry for the book, and I hope you all take this as respectful, constructive criticism. _Please_ ask me anything about development, especially with respect to how we can keep quality high using processes rather than sheer developer effort (so as to free you developers to work on interesting problems rather than bug hunting). Thanks for reading, Craig -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] Congratulations Luna developers!
David, I understand and appreciate the difficulty; however, I've had exactly zero questions about TDD. Like I said in the original post, I'm happy to answer any questions you may have. Please take me up on that offer any time. Thanks, Craig On Aug 18, 2013 6:57 PM, David Gomes da...@elementaryos.org wrote: This, this and this. And also many of the developers like me aren't really experienced with TDD and will have to take some time to study, learn and adapt to it. You can't just come here and tell developers, many of whom inexperienced young amateur programmers, to start using TDDs. Take me, for example, I never had proper programming education, I'm 17 years old. I know what TDD is but I've never used it before. You have to understand TDD is something very enterprise-ish and professional that big serious companies do. Look, I'm not saying we can't do it or we shouldn't do it or we won't do it - I'm just saying you need a better approach to what you're doing. I realize how useful and important TDD can be, but many of us might just be too busy having fun. Regards, David PS. I really hope I wasn't rude, I mean all I said in the nicest of ways. On Sun, Aug 18, 2013 at 11:58 PM, Daniel Foré dan...@elementaryos.orgwrote: This all sounds great and I think everybody is pro-testing, however I've yet to see a reproduce-able example or a guide regarding any kind of tests being implemented (especially by those extremely vocal about their importance). Not books or articles about why testing is good, but something that actually shows a person how to write tests for their apps. So, as Linus would say, Talk is cheap. Show me the code. — Sent from Mailbox https://www.dropbox.com/mailbox for iPhone On Sun, Aug 18, 2013 at 3:47 PM, Craig webe...@gmail.com wrote: Hi Alex, tl;dr: Unit tests are pretty much necessary to have an architecture on which you can run automatic system-level tests, and if you aren't automating then testing becomes too impractical. When you describe system tests you are actually describing what are called acceptance tests or behavioral tests ( http://www.extremeprogramming.org/rules/functionaltests.html). Unit tests test small units of code such as classes or functions. Traditional TDD relies primarily upon unit tests, and those are primarily what I'm referring to. One of the primary purposes of unit testing is to ensure good code architecture. If you don't unit test, you probably won't have good access points for your acceptance tests (how do you verify that that Gtk.Label has the correct text when you can only access the top level window?), so automation will be out of the question. And if you aren't automating then you can't continuously integrate (running all tests every time a change is made to the repository in order to find bugs as soon as they are made). Honestly, if you aren't automating then testing becomes too impractical. On Aug 18, 2013 5:10 PM, Alex Lourie djay...@gmail.com wrote: Hi Craig For the clarification purposes, I'd like to separate 'automatic tests (system testst)' and 'unittests'. I consider them different things. Unittests are pieces of code that test some other pieces of the code. System tests are scripts/code/steps that test that your program (or part of it) works. Unittests are usually run automatically (by, say, unittesting framework). System tests could be run automatically or manually. There are, sometimes, frameworks for that, but in most cases it's either manual or custom developed. Unittests are (usually) developed by the same developer who developed the original code, just as in your TDD example. System tests are best developed by external party (such as users). From here on, I can agree with you on point 1, and the naming. Basically, we all agree that having *testing *is a good practice and a feasible way to manage the complexity of software. But unittesting cannot test the logical connections between the blocks of code in the program. That's the job for system testing. I don't care how we call it. The more *systematic *testing we do for Elementary the better it's going to be, and the more chances we have to sustain growth. So I would just like to see testing implemented. Any kind of it. On Sun, Aug 18, 2013 at 10:56 PM, Craig webe...@gmail.com wrote: Hi Alex, To correct you on a couple of things: 1. TDD **does not** require you to have all or even several of the tests written before hand. It simply requires you to have the test written for the next change you are about to make. The idea is to write a test, run the test to watch it fail (this helps verify you wrote your test correctly), add the simplest code to make the test pass, run the test to watch it pass (and verify your code additions worked). Then you rinse and repeat. 2. TDD is actually a simplified form of what developers do already. That is, you usually write some code, run your code
Re: [Elementary-dev-community] Basing elementary on latest and greatest pieces of software
+1 On Jul 13, 2013 2:55 PM, Dane Henson d...@elementaryos.org wrote: One does not simply fork launchpad. On Jul 13, 2013 2:52 PM, Cassidy James cass...@elementaryos.org wrote: Chris, Launchpad is technically open source, but it's designed to be used only on Canonical's infrastructure and they aren't interested in making it run elsewhere. It's open source so that people can help Canonical out, not so people can set up their own instances. Regards, Cassidy James On Sat, Jul 13, 2013 at 5:13 AM, Chris Timberlake gam...@gmail.com wrote: Fabian, Correct me if I'm wrong but isn't launchpad open source? There's been much talk about Launchpad mock-ups and redesigns, etc. Maybe you could simply fork launchpad as opposed to creating a replacement? http://blog.launchpad.net/general/launchpad-is-now-open-source On Wed, Jul 10, 2013 at 2:55 PM, Fabian Thoma fab...@elementaryos.orgwrote: So I'm gonna enter that conversation here, if we want to have automated builds for debian based systems not on Launchpad we really need the following: 1. Hardware (we already got a virtual server capable of building the daily isos, so it should be able to handle this, if needed we can also go dedicated) 2. a build daemon, which is buildd that debian uses for it's build machines (we can use that 1 to 1 like launchpad) 3. a system managing builds and versions (which I'd prefer to build or use something highly flexible and adapt) 4. a repo server that hosts the packages and can support high traffic (that's a matter of renting it really) I don't see any issue in these things, especially the hardware and build based stuff. Building something to manage the builds and versions should not be a big deal either, but the real question has to be if we want to go and diy a Launchpad replacement or use something finished and integrate the build part into it. On Wed, Jul 10, 2013 at 11:42 PM, Sergey Shnatsel Davidoff ser...@elementaryos.org wrote: what do we need in order to get our own repo and automated build infrastructure? Is it a hardware issue? A lot of things I'm afraid. Off the top of my head, the list is as follows: 1. hardware 2. pbuilder configuration (mostly done) 3. some piece of software to accept dput uploads (should exist, but not found yet) 4. some piece of software to create and maintain the repository (should exist, but not found yet) 5. lots of integration scripts to write and secondary systems to set up (mailer to report failed builds, etc) 6. some UI to be able to make sense of all that and manage the setup (probably doesn't exist) -- Sergey Shnatsel Davidoff OS architect @ elementary -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- http://elementaryos.org/ *Fabian Thoma* | *Council Member* elementary OS fab...@elementaryos.org / elementaryos.org -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- *--**--** Chris Timberlake* Technical Architect Phone: 515-707-5109 gam...@gmail.com -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] Moving Away From Ubuntu
+1 On Jul 9, 2013 12:03 AM, Conscious User consciousu...@gmail.com wrote: Erm... I'm not sure how to answer this. None of your replies seem to be relevant or even directly related to what I said. Em Seg, 2013-07-08 às 23:27 -0500, Cody Garver escreveu: If anyone is an opponent of GNOME tech right now it's proprietary video driver developers. Those are concrete issues that affect any non-Intel GPU user. I haven't seen any hostility from Ubuntu. On Mon, Jul 8, 2013 at 11:22 PM, Cody Garver c...@elementaryos.org wrote: My sentence ran out of fuel there. PPAs are immensely valuable and eclipse any popular sentiment right now. On Mon, Jul 8, 2013 at 11:16 PM, Cody Garver c...@elementaryos.org wrote: PPAs. On Mon, Jul 8, 2013 at 11:12 PM, Conscious User consciousu...@gmail.com wrote: Hi all, Some time ago, I have noticed that an app I'm developing had some rendering issues only when the Ubuntu overlay scrollbars were being used. When I took this to Ubuntu developers, I was told that my best chance was to patch the scrollbars myself because no one was currently working on them. This is a symptom of something that, for anyone who's been following the Ubuntu developer community, should be quite evident at this point: due to the move to QML and touch, GTK and the rest of the stack Ubuntu had been using will now be second-class citizens, and it is only a matter of time before this change of status starts to gradually creep into overall stability and speed of fixing bugs. This wouldn't be much of a problem if Ubuntu simply packaged and shipped a vanilla GNOME stack, but the problem is that they ship a patched stack mixed with unpolished Ayatana projects which might now never get any more polish. And this might get worse with the move to Mir, as Canonical will probably need to add and maintain Mir support to GTK by itself. My intention here is not to question any direction Canonical is taking, but to question how much it still makes sense to build elementary on top of Ubuntu instead of a distro that uses a more vanilla GNOME stack or at least one that still treats it as a first-class citizen. It might be a good time to have a serious discussion on this. -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Cody Garver -- Cody Garver -- Cody Garver -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
[Elementary-dev-community] TDD Example
Hey guys (and any females who may be in attendance), *Here's a link (http://www.objectmentor.com/resources/articles/xpepisode.htm) to a test-driven development episode, written by Robert Uncle Bob Martin * (despite his silly monicker--and personality--Uncle Bob is a very respected voice in software development, and his advice is practiced by every major software company, including Google). *This simple example does a pretty good job at illustrating the test-driven development (TDD) process. * Uncle Bob uses Java primarily, but Java is sufficiently syntactically similar to Vala that we should be able to understand it. The confusing parts will probably pertain to the test frameworks--the Java community uses a test framework called JUnit. Unfortunately, while Vala has some testing frameworks, our dependency on the never-fun, always-complicated CMake system means that none of our elementary apps (to my knowledge) have managed to set up these frameworks so it will probably be fairly hard to try to practice these yourselves. *I know it's a little facetious to share with you a TDD example and then tell you that you probably won't even be able to try it; however, I'm working to figure out how we can set up a TDD environment for ourselves. In the meanwhile, I hope you'll read the episode and start to understand TDD principles and practices so you have less learning to do once we have tests set up.* Thanks for your time, Craig -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] Multi-Display Support
I don't think it's a bad idea (at least not if it were implemented well), but I do think it would take a substantial development effort... too much effort for such a tertiary feature. On Jun 28, 2013 1:31 PM, Allen Lowe lallenl...@gmail.com wrote: I think independent workspaces on each monitor is actually terrible. super confusing. On Wed, Jun 26, 2013 at 8:58 PM, Daniel Fore dan...@elementaryos.orgwrote: Dudes, they nailed it. We should of thought of it sooner. http://www.macworld.com/article/2042936/hands-on-with-os-x-mavericks-multiple-display-support.html -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] The book How Google Tests Software
I'm less interested in specific tools--I'm more interested in strategies--how we can work together to make sure we're shipping quality software. I don't know many companies that produce software with such quality and expedience as Google, so I figured this book would be a good place to start. Regarding TDD and test-writing overhead, you're probably going to be doing a lot of manual verification anyway. TDD cuts out a lot of manual verification (which takes a lot more time and isn't always reliable), it helps you structure your code in a modular fashion, and you get regression testing (making sure you didn't break something that used to work) for free. And there is a wealth of experience and research to back that up. It's not really a question anymore--in every case study I've heard of, TDD pays off in iteration zero (the first time). :) On Sun, Jun 23, 2013 at 2:27 PM, Sajith Edirisinghe sajithdils...@gmail.com wrote: In java there are tools like maven, ant for automated unit testing. But I'm not sure if there are any tools for vala or C. On the other hand test driven development would certainly increase stability of the system, though it adds an overhead of writing tests. On Mon, Jun 24, 2013 at 12:46 AM, Craig Weber webe...@gmail.com wrote: Also, on this note, I think it would be a very productive thing for some of us to collectively read software development books and discuss ideas that could help improve the way we do development so we can be better developers and more effectively help our users. Thoughts? On Sun, Jun 23, 2013 at 1:59 PM, Craig Weber webe...@gmail.com wrote: Has anyone read this book? If so, how applicable is this for elementary development? Would you recommend it for Elementary developers, and what about it could benefit Elementary developers? If few respond, I'll read through it anyway and provide a recommendation of some sort to share with the community, as I believe a formal testing process is important to developing quality software (and apparently le Goog does as well). Thanks, Craig -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
[Elementary-dev-community] Running Elementary in a VirtualBox VM [tutorial]
I made a brief write up on using VirtualBox to virtualize Luna. My primary purpose is to increase exposure to Luna, particularly to those less-technical users; however, it could also be useful for those looking to create a clean development environment without fear of breaking their production environment. I wrote this up because I experienced a lot of issues with installing/configuring a Luna VM, and I want others to benefit from my experiences. Please feel free to read this/share it with anyone who may find it useful: http://craigmatthewweber.com/2013/06/23/running-elementaryos-in-virtualbox-under-ubuntu-13-04/ -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] Built noise from source, can't find libgranite.so
So how do I know which version is needed? Shouldn't this be caught somewhere in the installation process? Here is the result of the apt-cache policy command you sent: libgranite-dev: Installed: 0.2.0~r590-0+pkg51~raring1 Candidate: 0.2.0~r590-0+pkg51~raring1 Version table: *** 0.2.0~r590-0+pkg51~raring1 0 500 http://ppa.launchpad.net/elementary-os/daily/ubuntu/raring/main amd64 Packages 100 /var/lib/dpkg/status 0.1.0-0ubuntu2 0 500 http://us.archive.ubuntu.com/ubuntu/ raring/universe amd64 Packages On Sun, Jun 23, 2013 at 9:58 AM, Sergey Shnatsel Davidoff ser...@elementaryos.org wrote: Sounds like you have an outdated development package; run apt-cache policy libgranite-dev to list all available versions. The easiest way to install an alternative version is via Synaptic. 2013/6/23 Craig webe...@gmail.com I built and installed noise from source, but it can't find libgranite.so (I get the following error when I run 'noise'): noise: error while loading shared libraries: libgranite.so.0: cannot open shared object file: No such file or directory I do have libgranite1 installed--can someone tell me what could be going wrong here? Please and thank you, Craig -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Sergey Shnatsel Davidoff OS architect @ elementary -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] Running Elementary in a VirtualBox VM [tutorial]
I'm not claiming running it in a VM is ideal; however, it's often necessary (a lot of people want to try an OS before installing it on hardware; others don't want to commit to beta software). In short, hardware installation is simply out of the question for a lot of people. If you'd like to write up an alternative virtualization solution, I'd be happy to link to it on my blog. As a side note, running the VM in fullscreen mode means you don't have to hover over said 1px stripe to show the dock. And I don't believe I've had such graphics problems with other OSes in VirtualBox--while I don't doubt VirtualBox's drivers are crappy, it looks like some of the problem is on Luna's implementation (of course, this is perfectly acceptable as Virtualbox isn't a supported target). On Sun, Jun 23, 2013 at 12:09 PM, Sergey Shnatsel Davidoff ser...@elementaryos.org wrote: Unfortunately VirtualBox is not a great choice because of its really, really poor GPU passthrough drivers that can cause all sorts of random issues, including crashes: http://www.phoronix.com/scan.php?page=news_itempx=OTk5Mw Running Luna in virtual machines is not a great idea in general because it's just not designed for such use. For example, using the dock in a VM is a PITA because you have to hover a 1px stripe, which is tricky. Also VirtualBox has very slow 2D acceleration, so the dock is slow to show up too even if you manage to reveal it. And any VM drivers are really slow at OpenGL, so Gala animations are laggy, window management in general is laggy even if you disable animations, and VirtualBox drivers show all kinds of nasty artifacts too. So, if you don't mind unusable window management (e.g. you always use one window), you can try running Luna in a VM, but please use something other than VirtualBox. In fact, Parallels GPU drivers are crap as well (proprietary and even worse than VirtualBox) and QEMU/KVM doesn't have guest GPU drivers, so the only VM in which Luna is usable (in single-window mode, because window management is b0rked either way) is VMware. If you want usable window management, you can try running Luna in fullscreen mode in QEMU/KVM or Xen with GPU passthrough to guest, but that's tricky to set up and I can't see any advantages of this setup over an actual installation. Oh, and there's also the option to hack out Gala and replace it with something that does compositing in software. But in that case you're not really running Luna. 2013/6/23 Craig Weber webe...@gmail.com I made a brief write up on using VirtualBox to virtualize Luna. My primary purpose is to increase exposure to Luna, particularly to those less-technical users; however, it could also be useful for those looking to create a clean development environment without fear of breaking their production environment. I wrote this up because I experienced a lot of issues with installing/configuring a Luna VM, and I want others to benefit from my experiences. Please feel free to read this/share it with anyone who may find it useful: http://craigmatthewweber.com/2013/06/23/running-elementaryos-in-virtualbox-under-ubuntu-13-04/ -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Sergey Shnatsel Davidoff OS architect @ elementary -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
[Elementary-dev-community] Building Gala, missing glib.h file
I'm trying to build Gala, and during the 'make' phase, I encounter this error: DBus.c:21:18: fatal error: glib.h: No such file or directory compilation terminated. make[2]: *** [CMakeFiles/gala.dir/src/DBus.c.o] Error 1 make[1]: *** [CMakeFiles/gala.dir/all] Error 2 make: *** [all] Error 2 Effectively, I am experiencing this bug: https://bugs.launchpad.net/gala/+bug/1072514 .. which I reopened because the solution the OP found hasn't helped me. Can someone please help with this? Thank you, Craig -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
[Elementary-dev-community] The book How Google Tests Software
Has anyone read this book? If so, how applicable is this for elementary development? Would you recommend it for Elementary developers, and what about it could benefit Elementary developers? If few respond, I'll read through it anyway and provide a recommendation of some sort to share with the community, as I believe a formal testing process is important to developing quality software (and apparently le Goog does as well). Thanks, Craig -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] The book How Google Tests Software
Also, on this note, I think it would be a very productive thing for some of us to collectively read software development books and discuss ideas that could help improve the way we do development so we can be better developers and more effectively help our users. Thoughts? On Sun, Jun 23, 2013 at 1:59 PM, Craig Weber webe...@gmail.com wrote: Has anyone read this book? If so, how applicable is this for elementary development? Would you recommend it for Elementary developers, and what about it could benefit Elementary developers? If few respond, I'll read through it anyway and provide a recommendation of some sort to share with the community, as I believe a formal testing process is important to developing quality software (and apparently le Goog does as well). Thanks, Craig -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
[Elementary-dev-community] Built noise from source, can't find libgranite.so
I built and installed noise from source, but it can't find libgranite.so (I get the following error when I run 'noise'): noise: error while loading shared libraries: libgranite.so.0: cannot open shared object file: No such file or directory I do have libgranite1 installed--can someone tell me what could be going wrong here? Please and thank you, Craig -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] Vala Game Development
Sounds good, I'll send you an email about it and we can get a conversation going. If anyone would like to be added to the conversation, just reply to this email. On Fri, Jun 14, 2013 at 5:42 PM, Sergio Tortosa Benedito serto...@gmail.com wrote: I would like to join, since I have been focusing somewhat to games (I have my own 3d ogre-based engine in the works :) ) it does make sense for me to help this project, and also I think the feedback I could get it would be very positive, what's more it could be a step forward in make the already mentioned engine available in vala, something I though would be pretty cool. El sáb, 15 de jun 2013 a las 12:30 ,Craig webe...@gmail.com escribió: I was wondering if anyone would be interested in experimenting around with making a simple 2D game with Vala, basically as a proof-of-concept. As it stands, C++ is the language of choice for game development, and as a professional C++ developer, I find this tragic. My primary goals for this project are to 1) help free the game development community from tedious languages 2) introduce Vala to a new genre of developer 3) learn a little more about both Vala and game development and share any applicable experiences with the broader community I don't have any serious expectation for this to become a real game (but it might)--mostly I'm interested in the experiment and having low-commitment fun. I know this isn't necessarily the right mailing list for this request, but I enjoy the feel of this community and would like to see if anyone here is interested before reaching out to broader audiences. At this point, my thoughts are extremely abstract and my mind is very open (I don't have any fixed plans for what this can look like, so you're welcome to help craft the vision). I don't expect this to be anyone's primary commitment (and I certainly don't want to detract from elementary development time), but if you're getting the programmer's equivalent of writer's block and you'd like to try something purely for fun (or if you'd like to learn to develop *so you can* start to contribute to Elementary), feel free to reply. Again, apologies if anyone finds this inappropriate for this list. Thanks for your time, Craig -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] Vala Game Development
Thanks David, As I mentioned, I selected this list for the community. Is there a preferred way to contact Elementary developers for matters not pertaining directly to the Elementary project? I would really like to see your projects. Please do post them! Thanks again, Craig On Fri, Jun 14, 2013 at 6:24 PM, David Gomes da...@elementaryos.org wrote: I've made two game prototypes using Vala - one 2D and one 3D, if you'd like the source code I can post it here. Regarding the convenience of this mailing list for that post, this is not really the place (vala-list would be more suitable), but I guess it's not a big deal either. On Fri, Jun 14, 2013 at 11:30 PM, Craig webe...@gmail.com wrote: I was wondering if anyone would be interested in experimenting around with making a simple 2D game with Vala, basically as a proof-of-concept. As it stands, C++ is the language of choice for game development, and as a professional C++ developer, I find this tragic. My primary goals for this project are to 1) help free the game development community from tedious languages 2) introduce Vala to a new genre of developer 3) learn a little more about both Vala and game development and share any applicable experiences with the broader community I don't have any serious expectation for this to become a real game (but it might)--mostly I'm interested in the experiment and having low-commitment fun. I know this isn't necessarily the right mailing list for this request, but I enjoy the feel of this community and would like to see if anyone here is interested before reaching out to broader audiences. At this point, my thoughts are extremely abstract and my mind is very open (I don't have any fixed plans for what this can look like, so you're welcome to help craft the vision). I don't expect this to be anyone's primary commitment (and I certainly don't want to detract from elementary development time), but if you're getting the programmer's equivalent of writer's block and you'd like to try something purely for fun (or if you'd like to learn to develop *so you can* start to contribute to Elementary), feel free to reply. Again, apologies if anyone finds this inappropriate for this list. Thanks for your time, Craig -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
[Elementary-dev-community] GTK-Ready Application Project Template
Hi everyone, After much struggling with CMake and various tutorials around the 'net, I decided to go ahead and build a bare-bones CMake vala application template. I tried to follow the Elementary tutorial as closely as I could (however, the tutorial version I found via Google omits critical components like setting up Vala CMake macros), so it should work for developing Elementary apps. Basically, this template exists for folks like me who can't make CMake yield to their will. Because I'm no CMake wizard, I'm sure it's far from perfect, and I'm open to suggestions on how to improve it, but I hope some people will find it useful. Here are some instructions: 1) Get it from https://bitbucket.org/craig_weber/cmake-vala-template/ (I'm not sure if I've made this public--if not, please let me know and I'll correct it)--it's available in zip, gz, and bz2 formats or you can clone it via mercurial if you so desire. 2) Open the root CMakeLists.txt file and change the 'multifileproj' in the line set(PROJECT_NAME multifileproj) to the name of your project 3) In src/CMakeLists.txt, add any project dependencies in the dependency lists (basically anywhere you see a reference to gtk+-3.0) 4) To build, navigate to the project's root directory and type: mkdir build cd build cmake .. make 5) Your executable will be in build/src/ (I have no idea why) If you have any problems, questions, concerns, suggestions, or accolades, please don't hesitate to email me. Thanks, Craig -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] New GtkSwitch image
Checkboxes always worked for me. I don't think the touchscreen revolution is responsible for the transition to switches (a checkbox is no less user friendly than a switch afaik). On May 24, 2013 1:31 PM, Jakob Eriksson ja...@aurorasystems.eu wrote: Which I find incredibly confusing, at least on iOS. More than once I have misread it for its opposite. (It doesn't help that it seems to be pretty hard to get a hold of on iPhone, but that is another matter. I am not very fond of Xylons idea or skeumorphic stuff in general. To me the whole idea of skeumorphic is a false dicomoty between the real world and the computer world. Increasingly, the real world is computer controlled or interacts with computer interfaces. To a child born now, a picture of a light bulb is almost as quaint and old as a picture of kerosene lamp. There is no skeumorphic. There is only familiarity (from any kind of experience) and clarity. We can draw on familiarity, but only so far. When familiarity, we need at least clarity. So whatever we do, we should make it very clear that there is a difference. Since we talk about the ON/OFF button, we could hint not only with the button itself, but we could strike out the text describing the option we are turning off, or making the text gray, or any number of things. I started this mini-rant because I got worked up when someone brought the iOS on/off widget as an example of good design. It's not horrible, but it's far from good. The iOS interface in general and as a whole, I think, is pretty good. But it's not because it's skeumorphic, but rather because it is coherently designed and has few ways to interact with it, easily learned. Two year olds master the GUI and it's not because the draw on their knowledge of spiral bound note books and other skeumorphic interface hints. Also the iOS interface absolutely *depends* on the input touch digitizer being very good. The iOS interface would be utterly *useless* on some of the low resolution, both in dpi and sample rate, many of the cheaper Android phones use. An aspect often overlooked in UI design, IMHO. On the desktop we thankfully have a very high speed, high resolution input device called the mouse. On the other, do we account for people with cheap laptops and really bad (too sensitive? dirty? small?) touchpad input devices? Is our interface great with those input devices too? On May 24, 2013 at 5:36 PM Alfredo Hernández aldomann.desi...@gmail.com wrote: The one implemented in elementary OS, iOS, GNOME, OS X, Android... The on/off switcher is becoming a new standard since touch devices started becoming a new frontier for UX design. It has become a standard in modern operating systems Ehem...this is me being stupid, but what is the standard switch in current modern operating systems anyway? On 24 May 2013 15:15, Alfredo Hernández aldomann.desi...@gmail.com wrote: The current one is clear enough and It has become a standard in modern operating systems. I don't see the need to change it. Regards. On 24 May 2013 13:09, A. Xylon V. avlabs...@gmail.com wrote: I have an idea for a new GtkSwitch image in the eGtk theme. See the attached file. This new GtkSwitch is skeuomorphic, and more intuitive from a user's POV (I think anyway). The user can immediately tell what to do, as they can relate to a light switch in real life, and therefore know the clicking on it will turn the option on/off. This is not as obvious in the current switch. However, I am not sure if this is possible to implement in Gtk3 css. -- My blog, yeaaah! http://skeptichacker.wordpress.com -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- My blog, yeaaah! http://skeptichacker.wordpress.com -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] Test Driven Development
Hello again,
Between attempting to fix a broken car and shopping for a new one, I
haven't had much time to devote to this; however, I did come across this
video as a quick primer. Take a look at it if you'd like to see a
quick-and-easy example of TDD.
http://www.youtube.com/watch?v=O-ZT_dtlrR0
Enjoy,
Craig
On Sun, May 5, 2013 at 1:00 AM, Pál Dorogi pal.dor...@gmail.com wrote:
I have uploaded my stuffs to launchpad, so you can have a look at it
at https://launchpad.net/dafproject
The dafcore, dafui and dafvalidation projects have unit tests under
test directory.
On 29 April 2013 16:26, Jaap Broekhuizen jaap...@gmail.com wrote:
Pal, that looks very interesting, please do upload it to launchpad so we
can
have a closer look :)
In te mean time, I have created a google document to have a central
point of
investigation for elementary automated testing. Feel free to add
information
to the doc whenever you can, but please keep it clean! :) You can find it
here:
https://docs.google.com/document/d/1cTsWpeT0h4FD81T-xs4bEWlALsO__j3rL1A7iB-SWz0/edit
I haven't found any BDD frameworks yet, but I have found some interesting
testing frameworks.
I think I'll set up a testing branch for granite some day later this
week,
maybe test out the different frameworks so we can see what suits us
best. If
anyone else wants to start setting up a branch like that, you are of
course
free to do so ;)
--
Jaap
On Mon, Apr 29, 2013 at 3:08 AM, Pál Dorogi pal.dor...@gmail.com
wrote:
Hi,
You can use cmake for unit test as it supports GLib's test. I use
MonoDevelop/Xamarin Studio for developing for huge projects coexists
/w cmake (as MD/XS does not support cmake). MD is for rapid
development but there is no internal Unit to support vala but C#
(Nunit) and some other languages. So, I run some cmake command before
and after MD build which runs cmake for cmake build and run test. For
example:
before build: cmake .. in /build/ dir
after build in MD: run build/test/unit_test
I added CMakeLists.txt into my MD project and I just need to sync
betwwen MD and that file when I add or remove a Vala source file
into/from the MD.
I do not know how would it works /w launchpad as I do not know how its
packaging works /w cmake's unit test, but I think it should work.
You just need add some stanza in the project's root CMakeList.txt like
this, but it's not simpe as it's using some other features like
external projects and so on.
set (PROJECT_TEST tests)
...
enable_testing (true)
add_subdirectory (${PROJECT_TEST})
and add create some CMakeList.txt in the ./test dir
###
# Sources
###
set (UNIT_TESTS unit_tests)
set (VALA_SOURCES
Model/Address.vala
Model/Person.vala
Model/Gender.vala
ValidatorTest.vala
TestMain.vala
)
set (PKG_DEPS gtk+-3.0 glib-2.0 gee-1.0)
# set (CMAKE_VERBOSE_MAKEFILE ON)
set (CMAKE_FIND_LIBRARY_SUFFIXES .so)
# External Packages definitions.
set (EXTERN_PROJ dafunit)
set (EXTERN_SOURCE_DIR src)
set (INTERN_PROJ dafvalidation)
set (INTERN_SOURCE_DIR ${PROJECT_SOURCE})
include (ExternalProject)
ExternalProject_Add (${EXTERN_PROJ}
#PREFIX ../../${EXTERN_PROJ}
SOURCE_DIR ../../../${EXTERN_PROJ}
BINARY_DIR ${CMAKE_BINARY_DIR}/${EXTERN_PROJ}/build
INSTALL_DIR
UPDATE_COMMAND
PATCH_COMMAND
INSTALL_COMMAND
)
ExternalProject_Get_Property(${EXTERN_PROJ} BINARY_DIR)
include_directories (${BINARY_DIR}/${EXTERN_SOURCE_DIR})
include_directories (${CMAKE_BINARY_DIR}/${INTERN_SOURCE_DIR})
# PkgConfig
find_package (PkgConfig)
find_package (GObjectIntrospection 0.9.12)
include (GObjectIntrospectionMacros)
pkg_check_modules(DEPS REQUIRED ${PKG_DEPS})
set (CFLAGS ${DEPS_CFLAGS} ${DEPS_CFLAGS_OTHER})
add_definitions (${CFLAGS})
set (LIBS ${DEPS_LIBRARIES})
set(LIB_PATHS ${DEPS_LIBRARY_DIRS})
link_directories(${LIB_PATHS})
# Does not work set (ENV{PKG_CONFIG_PATH} ${EXTERNAL_BINARY_DIR}/src)
vala_precompile (VALA_C
${VALA_SOURCES}
PACKAGES
${PKG_DEPS}
posix
CUSTOM_VAPIS
${CMAKE_BINARY_DIR}/${INTERN_SOURCE_DIR}/${INTERN_PROJ}.vapi
${BINARY_DIR}/${EXTERN_SOURCE_DIR}/${EXTERN_PROJ}.vapi
OPTIONS
)
add_executable (${UNIT_TESTS} ${VALA_C})
# Does not work add_dependencies (unit_tests dafvalidation)
target_link_libraries(${UNIT_TESTS} ${LIBS})
target_link_libraries(${UNIT_TESTS}
${BINARY_DIR}/${EXTERN_SOURCE_DIR}/${CMAKE_FIND_LIBRARY_PREFIXES}${EXTERN_PROJ}${CMAKE_FIND_LIBRARY_SUFFIXES})
target_link_libraries(${UNIT_TESTS}
${CMAKE_BINARY_DIR}/${INTERN_SOURCE_DIR}/${CMAKE_FIND_LIBRARY_PREFIXES}${INTERN_PROJ
Re: [Elementary-dev-community] Test Driven Development
{PKG_CONFIG_PATH} ${EXTERNAL_BINARY_DIR}/src)
vala_precompile (VALA_C
${VALA_SOURCES}
PACKAGES
${PKG_DEPS}
posix
CUSTOM_VAPIS
${CMAKE_BINARY_DIR}/${INTERN_SOURCE_DIR}/${INTERN_PROJ}.vapi
${BINARY_DIR}/${EXTERN_SOURCE_DIR}/${EXTERN_PROJ}.vapi
OPTIONS
)
add_executable (${UNIT_TESTS} ${VALA_C})
# Does not work add_dependencies (unit_tests dafvalidation)
target_link_libraries(${UNIT_TESTS} ${LIBS})
target_link_libraries(${UNIT_TESTS}
${BINARY_DIR}/${EXTERN_SOURCE_DIR}/${CMAKE_FIND_LIBRARY_PREFIXES}${EXTERN_PROJ}${CMAKE_FIND_LIBRARY_SUFFIXES})
target_link_libraries(${UNIT_TESTS}
${CMAKE_BINARY_DIR}/${INTERN_SOURCE_DIR}/${CMAKE_FIND_LIBRARY_PREFIXES}${INTERN_PROJ}${CMAKE_FIND_LIBRARY_SUFFIXES})
add_test(${UNIT_TESTS} ${CMAKE_CURRENT_BINARY_DIR}/${UNIT_TESTS})
###
I am going to upload it to lp so, if you would like to have a look at
it just let me know and that case I will uploadid it on some day in
this week
On 29 April 2013 07:19, Lochlan Bunn lokl...@gmail.com wrote:
I have read alot about TTD, both in school and in persistent
articles. I've
used it to develop a small gui based game, and I can say that I liked
the
flow once I was used to it. I used JUnit Eclipse, and that was all
that
was needed the whole time.
So when it comes to elementary dev, and vala/gtk/linux dev in
general, I'd
be interested in reading/learning how to write unit test (suites) for
vala
in respects to both CI, a la Launchpad, packaging, and moreso in an
IDE.
On 27 April 2013 07:48, Craig webe...@gmail.com wrote:
I agree wholeheartedly. And as Cassidy mentioned, we can use scratch
as
the incubation project. Would any devs be interested in
volunteering to
learn? Jaap, would you be interested in helping instruct?
On Apr 26, 2013 3:25 PM, Jaap Broekhuizen jaap...@gmail.com
wrote:
I also think implementing Behavorial testing (applying BDD) is very
relevant for us, as we are focussing a lot on user interface and
interaction.
So imo we should start on a project which we can use as a
playground for
both unit an behavorial testing.
Does anyone know of good vala bdd frameworks?
Jaap
Op 26 apr. 2013 22:21 schreef Cassidy James
cass...@elementaryos.org
het volgende:
I don't think we need any convincing; everything I've heard from
the
devs is that we need to do this. It's just a matter of figuring
out a common
way of doing it.
Craig, a relatively small/new project that could use testing is
the new
Scratch or even the new work going on with Contractor. Both are
(from what I
understand) fresh codebases and now might be the time to work on
tests. I
recommend you hop into #elementary-dev and work with the devs on
getting
some tests worked out.
Regards,
Cassidy
On Apr 26, 2013 11:04 AM, Pál Dorogi pal.dor...@gmail.com
wrote:
I dunno, I am a newbie here.
On 26 April 2013 22:24, Craig webe...@gmail.com wrote:
That's exactly what I'd like to know: how can I help. I can try
and
post
some tutorials, but I'd like to know who is interested and what
the
development community already knows.
On Apr 26, 2013 6:39 AM, Pál Dorogi pal.dor...@gmail.com
wrote:
Hi Craig,
I agree 100% /w you, but I think you should write some
tutorials and
post them in your blog, if you have any. But in my opinion
that the
human beings do not like re-learn things and the real OOP,
Design
Patterns, SOLID, TDD etc. etc. are very steep and time for a
non-real
OOP/DP experienced Programmer/Developer.
Also, the learning curve is very steep for these advanced
stuffs and
needs long time to get there. But, nobody would not know how
good
are
they until haven't learnt and used those stuffs, would they?.:)
I did sine similar things, getting some new fresh things (TDD,
MvvM/Presentation Model Design Pattern) to programming in Vala
((
http://ilapstech.blogspot.com/2013/04/advanced-programming-in-vala-dafs.html
)
but you should keep in mind that this kind of new things (TDD,
DP,
SOLDI, MVVM etc. etc.) are like evolution (evolution in
Programming)
which needs some time to get it succeeded (or failed).:)
On 26 April 2013 20:36, Craig webe...@gmail.com wrote:
Hello everyone,
I'm just leaving San Jose after having spent a week
listening to a
lot
of
smart people talk about, among other things, Test Driven
Development
(TDD).
I know I keep harping on this, but among the people who
write the
coolest,
best software (and other average software folks) TDD is seen
as
absolutely
critical. I can't point to anything other discipline in the
software
world
that is of comparable importance. And here's why:
When we start writing software, we can manage it with a
couple of
developers, perhaps all the way up through the first release
Re: [Elementary-dev-community] Test Driven Development
That's exactly what I'd like to know: how can I help. I can try and post some tutorials, but I'd like to know who is interested and what the development community already knows. On Apr 26, 2013 6:39 AM, Pál Dorogi pal.dor...@gmail.com wrote: Hi Craig, I agree 100% /w you, but I think you should write some tutorials and post them in your blog, if you have any. But in my opinion that the human beings do not like re-learn things and the real OOP, Design Patterns, SOLID, TDD etc. etc. are very steep and time for a non-real OOP/DP experienced Programmer/Developer. Also, the learning curve is very steep for these advanced stuffs and needs long time to get there. But, nobody would not know how good are they until haven't learnt and used those stuffs, would they?.:) I did sine similar things, getting some new fresh things (TDD, MvvM/Presentation Model Design Pattern) to programming in Vala (( http://ilapstech.blogspot.com/2013/04/advanced-programming-in-vala-dafs.html ) but you should keep in mind that this kind of new things (TDD, DP, SOLDI, MVVM etc. etc.) are like evolution (evolution in Programming) which needs some time to get it succeeded (or failed).:) On 26 April 2013 20:36, Craig webe...@gmail.com wrote: Hello everyone, I'm just leaving San Jose after having spent a week listening to a lot of smart people talk about, among other things, Test Driven Development (TDD). I know I keep harping on this, but among the people who write the coolest, best software (and other average software folks) TDD is seen as absolutely critical. I can't point to anything other discipline in the software world that is of comparable importance. And here's why: When we start writing software, we can manage it with a couple of developers, perhaps all the way up through the first release; however, as we add features, our software becomes more complex. It's hard for us to remember what parts of our programs worked well before and what parts are broken. We often make changes to the underlying architecture to facilitate a new feature, but we're not exactly sure if in doing so, we broke an existing feature. And we'll of course do a little ad hoc manual testing to verify that things still work, but we're only going to really check 5-10% of the code that we most suspect would break. And even if we do power through, we're only going to ever check 60-70% of the code, and it's all a very slow, unreliable process. Soon we spend all of our time fighting bugs and we can never get around to any interesting work. Does this pattern sound familiar? With TDD, you write a simple, small test for every piece of interesting code you write, and every time you rebuild the project, all of your old tests run. If you're writing good tests, you can be assured that all of your code works as you intend it to every single time you build, and if someone merges in a bug, it will be caught immediately (and the test that fails will give you some good information about what broke/where the bug is hiding). Of course, it takes time to write tests; however, it's still much less time than you would spend debugging your code. Furthermore, when you write tests before you write your production code, you are forced to design your code modularly just to make it testable. Among software professionals, TDD is seen as the fastest way to write software. I mean, Luna has been 90% complete for 90% of its development cycle, and this is a common pattern in the software world. With all of this in mind, I'd like to know how I can help you guys start practicing TDD? If this hasn't persuaded you, I'd appreciate it if you would respond and give your perspective so we can talk about it. I'm very interested in seeing you guys continue to put out great software, but I'm concerned that as you write more code, you're going to be creating more for yourselves to maintain and the amount of time you spend writing new software is going to drop off exponentially as the complexity (as complexity produces bugs) increases. Please let me know if/how I can help you. Craig -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] Test Driven Development
I agree wholeheartedly. And as Cassidy mentioned, we can use scratch as the incubation project. Would any devs be interested in volunteering to learn? Jaap, would you be interested in helping instruct? On Apr 26, 2013 3:25 PM, Jaap Broekhuizen jaap...@gmail.com wrote: I also think implementing Behavorial testing (applying BDD) is very relevant for us, as we are focussing a lot on user interface and interaction. So imo we should start on a project which we can use as a playground for both unit an behavorial testing. Does anyone know of good vala bdd frameworks? Jaap Op 26 apr. 2013 22:21 schreef Cassidy James cass...@elementaryos.org het volgende: I don't think we need any convincing; everything I've heard from the devs is that we need to do this. It's just a matter of figuring out a common way of doing it. Craig, a relatively small/new project that could use testing is the new Scratch or even the new work going on with Contractor. Both are (from what I understand) fresh codebases and now might be the time to work on tests. I recommend you hop into #elementary-dev and work with the devs on getting some tests worked out. Regards, Cassidy On Apr 26, 2013 11:04 AM, Pál Dorogi pal.dor...@gmail.com wrote: I dunno, I am a newbie here. On 26 April 2013 22:24, Craig webe...@gmail.com wrote: That's exactly what I'd like to know: how can I help. I can try and post some tutorials, but I'd like to know who is interested and what the development community already knows. On Apr 26, 2013 6:39 AM, Pál Dorogi pal.dor...@gmail.com wrote: Hi Craig, I agree 100% /w you, but I think you should write some tutorials and post them in your blog, if you have any. But in my opinion that the human beings do not like re-learn things and the real OOP, Design Patterns, SOLID, TDD etc. etc. are very steep and time for a non-real OOP/DP experienced Programmer/Developer. Also, the learning curve is very steep for these advanced stuffs and needs long time to get there. But, nobody would not know how good are they until haven't learnt and used those stuffs, would they?.:) I did sine similar things, getting some new fresh things (TDD, MvvM/Presentation Model Design Pattern) to programming in Vala (( http://ilapstech.blogspot.com/2013/04/advanced-programming-in-vala-dafs.html ) but you should keep in mind that this kind of new things (TDD, DP, SOLDI, MVVM etc. etc.) are like evolution (evolution in Programming) which needs some time to get it succeeded (or failed).:) On 26 April 2013 20:36, Craig webe...@gmail.com wrote: Hello everyone, I'm just leaving San Jose after having spent a week listening to a lot of smart people talk about, among other things, Test Driven Development (TDD). I know I keep harping on this, but among the people who write the coolest, best software (and other average software folks) TDD is seen as absolutely critical. I can't point to anything other discipline in the software world that is of comparable importance. And here's why: When we start writing software, we can manage it with a couple of developers, perhaps all the way up through the first release; however, as we add features, our software becomes more complex. It's hard for us to remember what parts of our programs worked well before and what parts are broken. We often make changes to the underlying architecture to facilitate a new feature, but we're not exactly sure if in doing so, we broke an existing feature. And we'll of course do a little ad hoc manual testing to verify that things still work, but we're only going to really check 5-10% of the code that we most suspect would break. And even if we do power through, we're only going to ever check 60-70% of the code, and it's all a very slow, unreliable process. Soon we spend all of our time fighting bugs and we can never get around to any interesting work. Does this pattern sound familiar? With TDD, you write a simple, small test for every piece of interesting code you write, and every time you rebuild the project, all of your old tests run. If you're writing good tests, you can be assured that all of your code works as you intend it to every single time you build, and if someone merges in a bug, it will be caught immediately (and the test that fails will give you some good information about what broke/where the bug is hiding). Of course, it takes time to write tests; however, it's still much less time than you would spend debugging your code. Furthermore, when you write tests before you write your production code, you are forced to design your code modularly just to make it testable. Among software professionals, TDD is seen as the fastest way to write software. I mean, Luna has been 90% complete for 90% of its development cycle
[Elementary-dev-community] Why does Cairo.set_source_rgb paint the whole canvas?
I posted this question on StackOverflow, but I'm hoping you guys can help answer it as well: I'm playing around with Clutter/cairo and I'm trying to draw a rectangle; however, it appears that theset_source_rgb is automatically painting the whole canvas with its source, regardless of whether or not I tell it to draw a rectangle (that is, even when I remove the ctx.rectangle() and ctx.fill()lines, the rectangle is still drawn). Why is this? And what do I need to do to have the rectangle do the painting rather than the set_source_rgb? The source can be found in the original SO question here: http://stackoverflow.com/questions/16007420/why-does-cairo-set-source-rgb-paint-the-whole-canvas Please advise, because I'm stumped! Thanks List! - Craig -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
[Elementary-dev-community] Vala/Go
Happy Monday everyone, I wrote a brief comparison of Vala and Go (golang) that might be of interest to some of you. Feel free to add your thoughts in the comments. http://craigmatthewweber.com/2013/04/06/vala-or-go/ Enjoy, Craig -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] Vala/Go
@Chris, Syntactically, I think Vala is a great language. I'm dying to use it, in fact! However, until I can get over the nasty project-management hump, I'm afraid I'm out of the loop. And don't think project management features are useful only to building and distribution. How can an IDE know which symbols are available outside of the current file (for purposes such as code verification, autocompletion, etc) without knowing something about what files are available to the project? Decent project management features are an important aspect of a language (for all kinds of purposes), and when they are missing, non-standard, or overly complex; it makes the language impractical. @Sergey, I'm not confusing the two. As I mentioned in my response to Chris, the two issues are linked--it's impractical to develop an application without a simple, automatic project metadata management tool and Vala doesn't seem to have one (I can't find _any_ information about bake online). To address your last paragraph, I don't know what the crux of the issue is (nor what the best solution is), but useful programs haven't been single files for decades; it's archaic to treat the project management concerns of development as an afterthought when developing languages. Like you said, why expose the developer to that unnecessary complexity? I have yet to find a better paradigm than Go's for mitigating that concern. On Mon, Apr 8, 2013 at 9:07 AM, Ryan Macnish nisshh.ubu...@gmail.comwrote: Go is brilliant, it has the best parts of c and the best parts of modern languages built in. On Apr 8, 2013 9:22 PM, Craig webe...@gmail.com wrote: Happy Monday everyone, I wrote a brief comparison of Vala and Go (golang) that might be of interest to some of you. Feel free to add your thoughts in the comments. http://craigmatthewweber.com/2013/04/06/vala-or-go/ Enjoy, Craig -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] Vala/Go
That brings me to a question I've had for a while--I'm not sure what goes into creating a C binding for any language, but is it possible to create a C binding to granite? If so, your proposal would be limited only by the availability of granite bindings. On the other hand, though I think Elementary development has a substantial barrier of entry, I don't know Elementary's goals of simplicity and consistency would be especially well-served by fragmenting the tools used. On the *other* other hand, it could also bring a lot of developer attention to the project, albeit Elementary's relatively small community, I think it would be difficult to find enough people to create and maintain bindings for all of those languages. Thoughts? On Mon, Apr 8, 2013 at 10:38 AM, Jakob Eriksson ja...@aurorasystems.euwrote: I think there should be a tutorial for writing an Elementary HID compliant app in all popular languages, Java, Python, C++, Go, Objective C and Ruby at least. Craig webe...@gmail.com skrev: @Chris, Syntactically, I think Vala is a great language. I'm dying to use it, in fact! However, until I can get over the nasty project-management hump, I'm afraid I'm out of the loop. And don't think project management features are useful only to building and distribution. How can an IDE know which symbols are available outside of the current file (for purposes such as code verification, autocompletion, etc) without knowing something about what files are available to the project? Decent project management features are an important aspect of a language (for all kinds of purposes), and when they are missing, non-standard, or overly complex; it makes the language impractical. @Sergey, I'm not confusing the two. As I mentioned in my response to Chris, the two issues are linked--it's impractical to develop an application without a simple, automatic project metadata management tool and Vala doesn't seem to have one (I can't find _any_ information about bake online). To address your last paragraph, I don't know what the crux of the issue is (nor what the best solution is), but useful programs haven't been single files for decades; it's archaic to treat the project management concerns of development as an afterthought when developing languages. Like you said, why expose the developer to that unnecessary complexity? I have yet to find a better paradigm than Go's for mitigating that concern. On Mon, Apr 8, 2013 at 9:07 AM, Ryan Macnish nisshh.ubu...@gmail.com wrote: Go is brilliant, it has the best parts of c and the best parts of modern languages built in. On Apr 8, 2013 9:22 PM, Craig webe...@gmail.com wrote: Happy Monday everyone, I wrote a brief comparison of Vala and Go (golang) that might be of interest to some of you. Feel free to add your thoughts in the comments. http://craigmatthewweber.com/2013/04/06/vala-or-go/ Enjoy, Craig -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] Vala/Go
Many languages support binding to C (probably more common than GObject introspection), so if it works with C, other high level OOP languages can bind to it without needing support for GObject introspection. :-) On Apr 8, 2013 10:58 AM, Nishant Agrwal nishantagrwal12...@gmail.com wrote: Granite is written in Vala, so I guess any gObject Introspection capable language should be very easy to use, especially those with dynamic binding, like Python. As far as C goes, Vala compiles to C anyway so that should be pretty easy as well, although I don't think most people would like to use C instead of a high level OOP language. On Mon, Apr 8, 2013 at 9:24 PM, Craig webe...@gmail.com wrote: That brings me to a question I've had for a while--I'm not sure what goes into creating a C binding for any language, but is it possible to create a C binding to granite? If so, your proposal would be limited only by the availability of granite bindings. On the other hand, though I think Elementary development has a substantial barrier of entry, I don't know Elementary's goals of simplicity and consistency would be especially well-served by fragmenting the tools used. On the *other* other hand, it could also bring a lot of developer attention to the project, albeit Elementary's relatively small community, I think it would be difficult to find enough people to create and maintain bindings for all of those languages. Thoughts? On Mon, Apr 8, 2013 at 10:38 AM, Jakob Eriksson ja...@aurorasystems.euwrote: I think there should be a tutorial for writing an Elementary HID compliant app in all popular languages, Java, Python, C++, Go, Objective C and Ruby at least. Craig webe...@gmail.com skrev: @Chris, Syntactically, I think Vala is a great language. I'm dying to use it, in fact! However, until I can get over the nasty project-management hump, I'm afraid I'm out of the loop. And don't think project management features are useful only to building and distribution. How can an IDE know which symbols are available outside of the current file (for purposes such as code verification, autocompletion, etc) without knowing something about what files are available to the project? Decent project management features are an important aspect of a language (for all kinds of purposes), and when they are missing, non-standard, or overly complex; it makes the language impractical. @Sergey, I'm not confusing the two. As I mentioned in my response to Chris, the two issues are linked--it's impractical to develop an application without a simple, automatic project metadata management tool and Vala doesn't seem to have one (I can't find _any_ information about bake online). To address your last paragraph, I don't know what the crux of the issue is (nor what the best solution is), but useful programs haven't been single files for decades; it's archaic to treat the project management concerns of development as an afterthought when developing languages. Like you said, why expose the developer to that unnecessary complexity? I have yet to find a better paradigm than Go's for mitigating that concern. On Mon, Apr 8, 2013 at 9:07 AM, Ryan Macnish nisshh.ubu...@gmail.com wrote: Go is brilliant, it has the best parts of c and the best parts of modern languages built in. On Apr 8, 2013 9:22 PM, Craig webe...@gmail.com wrote: Happy Monday everyone, I wrote a brief comparison of Vala and Go (golang) that might be of interest to some of you. Feel free to add your thoughts in the comments. http://craigmatthewweber.com/2013/04/06/vala-or-go/ Enjoy, Craig -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] Vala/Go
At this point the discussion is about Granite and the elementary HIG, which seems like an appropriate topic for the elementary dev list. On Apr 8, 2013 12:52 PM, xapantu xapa...@mailoo.org wrote: Just see /usr/include/granite/granite.h if you want to use granite with C. Just do the translations from vala code to C code, i.e. for new Granite.Widgets.ModeButton, it is granite_widgets_mode_button_new. However, as Jaap said it, I am not sure this is the place to discuss about go and Vala, especially when Luna is not released yet and that we will NOT change any language in our apps before Luna. Lucas On 08/04/2013 18:02, Craig wrote: Many languages support binding to C (probably more common than GObject introspection), so if it works with C, other high level OOP languages can bind to it without needing support for GObject introspection. :-) On Apr 8, 2013 10:58 AM, Nishant Agrwal nishantagrwal12...@gmail.com wrote: Granite is written in Vala, so I guess any gObject Introspection capable language should be very easy to use, especially those with dynamic binding, like Python. As far as C goes, Vala compiles to C anyway so that should be pretty easy as well, although I don't think most people would like to use C instead of a high level OOP language. On Mon, Apr 8, 2013 at 9:24 PM, Craig webe...@gmail.com wrote: That brings me to a question I've had for a while--I'm not sure what goes into creating a C binding for any language, but is it possible to create a C binding to granite? If so, your proposal would be limited only by the availability of granite bindings. On the other hand, though I think Elementary development has a substantial barrier of entry, I don't know Elementary's goals of simplicity and consistency would be especially well-served by fragmenting the tools used. On the *other* other hand, it could also bring a lot of developer attention to the project, albeit Elementary's relatively small community, I think it would be difficult to find enough people to create and maintain bindings for all of those languages. Thoughts? On Mon, Apr 8, 2013 at 10:38 AM, Jakob Eriksson ja...@aurorasystems.euwrote: I think there should be a tutorial for writing an Elementary HID compliant app in all popular languages, Java, Python, C++, Go, Objective C and Ruby at least. Craig webe...@gmail.com skrev: @Chris, Syntactically, I think Vala is a great language. I'm dying to use it, in fact! However, until I can get over the nasty project-management hump, I'm afraid I'm out of the loop. And don't think project management features are useful only to building and distribution. How can an IDE know which symbols are available outside of the current file (for purposes such as code verification, autocompletion, etc) without knowing something about what files are available to the project? Decent project management features are an important aspect of a language (for all kinds of purposes), and when they are missing, non-standard, or overly complex; it makes the language impractical. @Sergey, I'm not confusing the two. As I mentioned in my response to Chris, the two issues are linked--it's impractical to develop an application without a simple, automatic project metadata management tool and Vala doesn't seem to have one (I can't find _any_ information about bake online). To address your last paragraph, I don't know what the crux of the issue is (nor what the best solution is), but useful programs haven't been single files for decades; it's archaic to treat the project management concerns of development as an afterthought when developing languages. Like you said, why expose the developer to that unnecessary complexity? I have yet to find a better paradigm than Go's for mitigating that concern. On Mon, Apr 8, 2013 at 9:07 AM, Ryan Macnish nisshh.ubu...@gmail.com wrote: Go is brilliant, it has the best parts of c and the best parts of modern languages built in. On Apr 8, 2013 9:22 PM, Craig webe...@gmail.com wrote: Happy Monday everyone, I wrote a brief comparison of Vala and Go (golang) that might be of interest to some of you. Feel free to add your thoughts in the comments. http://craigmatthewweber.com/2013/04/06/vala-or-go/ Enjoy, Craig -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community
Re: [Elementary-dev-community] Vala/Go
I think he was suggesting supporting more languages, not changing the current one. My original post was discussing Go vs Vala for application development in general, which I thought might be of interest for some of the folks here. I don't think anyone was suggesting changing the official language. On Apr 8, 2013 1:15 PM, Mario Guerriero mefri...@gmail.com wrote: Switch to another language would be an incredible waste of time, also after Luna. We only have to make a script that automates the build process with elementary Vala apps. Anyway Go looks very promitting but it's too early to judge it, I think. — Sent from Mailbox https://bit.ly/SZvoJe for iPhone On Mon, Apr 8, 2013 at 8:12 PM, Craig webe...@gmail.com wrote: At this point the discussion is about Granite and the elementary HIG, which seems like an appropriate topic for the elementary dev list. On Apr 8, 2013 12:52 PM, xapantu xapa...@mailoo.org wrote: Just see /usr/include/granite/granite.h if you want to use granite with C. Just do the translations from vala code to C code, i.e. for new Granite.Widgets.ModeButton, it is granite_widgets_mode_button_new. However, as Jaap said it, I am not sure this is the place to discuss about go and Vala, especially when Luna is not released yet and that we will NOT change any language in our apps before Luna. Lucas On 08/04/2013 18:02, Craig wrote: Many languages support binding to C (probably more common than GObject introspection), so if it works with C, other high level OOP languages can bind to it without needing support for GObject introspection. :-) On Apr 8, 2013 10:58 AM, Nishant Agrwal nishantagrwal12...@gmail.com wrote: Granite is written in Vala, so I guess any gObject Introspection capable language should be very easy to use, especially those with dynamic binding, like Python. As far as C goes, Vala compiles to C anyway so that should be pretty easy as well, although I don't think most people would like to use C instead of a high level OOP language. On Mon, Apr 8, 2013 at 9:24 PM, Craig webe...@gmail.com wrote: That brings me to a question I've had for a while--I'm not sure what goes into creating a C binding for any language, but is it possible to create a C binding to granite? If so, your proposal would be limited only by the availability of granite bindings. On the other hand, though I think Elementary development has a substantial barrier of entry, I don't know Elementary's goals of simplicity and consistency would be especially well-served by fragmenting the tools used. On the *other* other hand, it could also bring a lot of developer attention to the project, albeit Elementary's relatively small community, I think it would be difficult to find enough people to create and maintain bindings for all of those languages. Thoughts? On Mon, Apr 8, 2013 at 10:38 AM, Jakob Eriksson ja...@aurorasystems.eu wrote: I think there should be a tutorial for writing an Elementary HID compliant app in all popular languages, Java, Python, C++, Go, Objective C and Ruby at least. Craig webe...@gmail.com skrev: @Chris, Syntactically, I think Vala is a great language. I'm dying to use it, in fact! However, until I can get over the nasty project-management hump, I'm afraid I'm out of the loop. And don't think project management features are useful only to building and distribution. How can an IDE know which symbols are available outside of the current file (for purposes such as code verification, autocompletion, etc) without knowing something about what files are available to the project? Decent project management features are an important aspect of a language (for all kinds of purposes), and when they are missing, non-standard, or overly complex; it makes the language impractical. @Sergey, I'm not confusing the two. As I mentioned in my response to Chris, the two issues are linked--it's impractical to develop an application without a simple, automatic project metadata management tool and Vala doesn't seem to have one (I can't find _any_ information about bake online). To address your last paragraph, I don't know what the crux of the issue is (nor what the best solution is), but useful programs haven't been single files for decades; it's archaic to treat the project management concerns of development as an afterthought when developing languages. Like you said, why expose the developer to that unnecessary complexity? I have yet to find a better paradigm than Go's for mitigating that concern. On Mon, Apr 8, 2013 at 9:07 AM, Ryan Macnish nisshh.ubu...@gmail.com wrote: Go is brilliant, it has the best parts of c and the best parts of modern languages built in. On Apr 8, 2013 9:22 PM, Craig webe...@gmail.com wrote: Happy Monday everyone, I wrote a brief comparison of Vala and Go (golang) that might be of interest to some of you. Feel free to add your thoughts in the comments. http
[Elementary-dev-community] Testing
Hello everyone, I'm curious what you devs do for testing? I'm not particularly familiar with Vala, but I'm learning a lot about testing at work and I'm trying to develop myself to that end in my free time. I'm sending this email because I'd like to get a pulse on what you Elementary devs think about testing and what you actually do to test your code. Also, please feel encouraged to talk about what you've done in the past, what has/hasn't worked for you, and generally what your philosophy is about testing (or whether you have no philosophy). Individual comments and comments on behalf of elementary as a whole are both welcome. Sound off! Thanks, Craig -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] Testing
*If anyone is interested in starting a Vala Unit Test project under the
umbrella of the elementary community, I'm sure we could get quite a bit of
traction from the Vala community at large and I would love to help out. -
Dane Henson*
*
*
Not only that, but I imagine it would garner quite a lot of professional
developer attention for elementary, since professional devs seem
dramatically more exposed to (and interested in) formal testing than
hobbyist developers.
*I apologize for spamming the mailing list. - Dane Henson*
Please don't apologize--from the sounds of it, there is quite a bit of
consensus that this is a subject that needs to be discussed. And I for one
have found each of your messages profitable.
*Unit testing is boring to write so if we just said Everybody. Write unit
tests. All Projects. Now. it would really take on. On companies and when
developers are paid to work, they can write and put tests everywhere, but
it's harder for us. - David Gomes*
*
*
David, I used to think that as well; however, once you learn to write tests
correctly (I'm starting that process myself) it becomes more exciting. As
Dane mentions later in the thread, when you build the bucket around the
water (write tests for existing code), it is certainly drudgery; however,
when you write tests *before* you implement the functionality, you
1. wind up with better code (because code must be written in neat
modules to provide your tests access to the inputs/outputs they need)
2. get the excitement of writing code and watching your tests pass/fail
(and as you learn to write better tests, you get detailed information about
exactly what caused the failure)
3. can change your code fearlessly, knowing that if anything breaks, you
will be notified immediately
The whole process becomes at least a little more exciting, especially if
you've experienced a huge untested code base and the fear that comes with
having to make a change or implement a feature lest the whole thing come
tumbling down on you.
*While if we (developers) use the first approach, which is called TDD is
much better. We write the test first so we define how our app should behave
and how our code is structured already (so all the thinking of the code
structure you do it in the tests) which is really great. - Goncalo*
*
*
TDD = Test Driven Development (for the uninitiated). I elaborated on this
process to some extent in my previous paragraph.
We can also do BDD , if there's no framework for this we can probably
create something, for more infos you can check cucumber for Ruby. *Bdd
let's you write the tests in PLAIN english, so who does the mockups could
write the tests as well. that would be great. - Goncalo*
*
*
BDD = Behavior Driven Development. It's either the same thing or very
closely related to ATDD (Acceptance Test Driven Development). In either
case, the general idea is that you specify what the entire system
*must do* (system
requirements/acceptance criteria) and then you write tests to verify each
requirement. This sort of test might look like:
WHEN the bold button is pressed
AND the string 'abcd' is typed,
EXPECT the text view to contain the string 'abcd' in bold
Then, for each line, you write a function that implements either the setup
(the WHEN/AND portion) or the evaluation (the EXPECT portion) and then the
framework puts the pieces together and executes the test. The code for the
test (in pseudocode) might look like this:
func pressBoldButton () {
theApp.boldButton.setPressed (true)
}
func type(string input) {
theApp.InsertAtCursor (input)
}
func verifyContents () {
start := 0
end := 3
contents := theApp.GetFormattedSubStr (start, end)
contentsAreBold := contents.isBold()
letters := contents.getPlainTextString()
Testing.Expect (contentsAreBold);
Testing.Expect (letters == abcd)
}
On Thu, Apr 4, 2013 at 9:11 AM, Dane Henson d...@elementaryos.org wrote:
Here is another practical post I found interesting regarding setting up
Unit Tests in Vala with Cmake:
http://blog.remysaissy.com/2012/11/setting-up-unit-tests-in-vala-project.html
I apologize for spamming the mailing list.
On Thu, Apr 4, 2013 at 8:56 AM, Sergey Shnatsel Davidoff
ser...@elementaryos.org wrote:
I strongly recommend anyone interested in automated testing to read
through Martin Pitt's Ubuntu Dev Week session on the topic. He's the one
responsible for most of unit testing in Ubuntu (he's also the author of
Apport which we already use). His IRC nick is pitti and the session logs
can be found at
http://irclogs.ubuntu.com/2013/01/31/%23ubuntu-classroom.html
--
Sergey Shnatsel Davidoff
OS architect @ elementary
--
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help : https://help.launchpad.net/ListHelp
--
Mailing list: https://launchpad.net/~elementary-dev-community
Re: [Elementary-dev-community] Testing
If we can get a number of experienced test practitioners and Vala developers to commit to it, I wouldn't mind contributing to a test framework development. Would anyone else be interested? On Thu, Apr 4, 2013 at 10:13 AM, Craig webe...@gmail.com wrote: *Would it be feasible to create a Unit Test team on launchpad with the sole purpose of specializing in adding testing to projects and writing the tests required to kill regression bugs before they kill us? - Dane* * * If we do this, I would expect it to be short term only. Developers should be responsible for testing their own code and Test Engineers should be primarily responsible for giving the devs the tools/training they need to test their own work. I propose instead that we only implement tests when we do bug fixes. If a bug crops up, we analyze what caused it and then we write a test to prevent any such bug from appearing (not just that specific bug, but any bug in that class of bugs). For example, I recently worked on a system that takes a config file, parses its key/value pairs into a map, and then exposes its values in the form of methods called string GetValueOfKey1(), string GetValueOfKey2(), etc. These functions simply contained return map.GetValue(key1);. This worked fine as long as the configuration file was setup correctly; however, as soon as someone made a mistake in the config file (accidentally renamed key1 to Key1 or some such) the application crashed because GetValueOfKey1() couldn't find key1 in the map structure. This error *ultimately resulted from* unhandled input, I created a test to test for *all kinds* of bad input and then implemented the input handling. Applying tests where they're useful prevents us from testing stable code. And then moving forward, we can write tests for all new functionality. On Thu, Apr 4, 2013 at 10:00 AM, Craig webe...@gmail.com wrote: *If anyone is interested in starting a Vala Unit Test project under the umbrella of the elementary community, I'm sure we could get quite a bit of traction from the Vala community at large and I would love to help out. - Dane Henson* * * Not only that, but I imagine it would garner quite a lot of professional developer attention for elementary, since professional devs seem dramatically more exposed to (and interested in) formal testing than hobbyist developers. *I apologize for spamming the mailing list. - Dane Henson* Please don't apologize--from the sounds of it, there is quite a bit of consensus that this is a subject that needs to be discussed. And I for one have found each of your messages profitable. *Unit testing is boring to write so if we just said Everybody. Write unit tests. All Projects. Now. it would really take on. On companies and when developers are paid to work, they can write and put tests everywhere, but it's harder for us. - David Gomes* * * David, I used to think that as well; however, once you learn to write tests correctly (I'm starting that process myself) it becomes more exciting. As Dane mentions later in the thread, when you build the bucket around the water (write tests for existing code), it is certainly drudgery; however, when you write tests *before* you implement the functionality, you 1. wind up with better code (because code must be written in neat modules to provide your tests access to the inputs/outputs they need) 2. get the excitement of writing code and watching your tests pass/fail (and as you learn to write better tests, you get detailed information about exactly what caused the failure) 3. can change your code fearlessly, knowing that if anything breaks, you will be notified immediately The whole process becomes at least a little more exciting, especially if you've experienced a huge untested code base and the fear that comes with having to make a change or implement a feature lest the whole thing come tumbling down on you. *While if we (developers) use the first approach, which is called TDD is much better. We write the test first so we define how our app should behave and how our code is structured already (so all the thinking of the code structure you do it in the tests) which is really great. - Goncalo* * * TDD = Test Driven Development (for the uninitiated). I elaborated on this process to some extent in my previous paragraph. We can also do BDD , if there's no framework for this we can probably create something, for more infos you can check cucumber for Ruby. *Bdd let's you write the tests in PLAIN english, so who does the mockups could write the tests as well. that would be great. - Goncalo* * * BDD = Behavior Driven Development. It's either the same thing or very closely related to ATDD (Acceptance Test Driven Development). In either case, the general idea is that you specify what the entire system *must do* (system requirements/acceptance criteria) and then you write tests to verify each requirement
Re: [Elementary-dev-community] Testing
+1 Sergey, that page is massive. Could you send us the interesting parts? On Thu, Apr 4, 2013 at 11:59 AM, Goncalo Margalho g...@margalho.info wrote: Sergey, how do you write code in Vala and write tests in C? it becomes too difficult for a developer, don't you think? On Thu, Apr 4, 2013 at 5:18 PM, Sergey Shnatsel Davidoff ser...@elementaryos.org wrote: I'm not so sure we need a solution bound to Vala specifically, because: 1. We have automated UI testing covered by Ubuntu's regression testing framework 2. We have D-bus testing coverted by Ubuntu's regression testing framework 3. Vala translates to C so we can use a C unit testing system for functions For details on what Ubuntu do see Martin Pitt's UDW session, http://irclogs.ubuntu.com/2013/01/31/%23ubuntu-classroom.html -- Sergey Shnatsel Davidoff OS architect @ elementary -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] Testing
Nor am I. But I think the first step would be to explore what can be done with the existing tools (assuming there are any that are still supported). I find that I rarely need much more than a simple facility with the ability to create test cases and do setup/teardown so if we can find anything that provides even that, I think we can go a long way. On Thu, Apr 4, 2013 at 10:45 AM, Goncalo Margalho g...@margalho.info wrote: I would be interested but I'm not the best vala developer for sure. On Thu, Apr 4, 2013 at 4:40 PM, Craig webe...@gmail.com wrote: If we can get a number of experienced test practitioners and Vala developers to commit to it, I wouldn't mind contributing to a test framework development. Would anyone else be interested? On Thu, Apr 4, 2013 at 10:13 AM, Craig webe...@gmail.com wrote: *Would it be feasible to create a Unit Test team on launchpad with the sole purpose of specializing in adding testing to projects and writing the tests required to kill regression bugs before they kill us? - Dane* * * If we do this, I would expect it to be short term only. Developers should be responsible for testing their own code and Test Engineers should be primarily responsible for giving the devs the tools/training they need to test their own work. I propose instead that we only implement tests when we do bug fixes. If a bug crops up, we analyze what caused it and then we write a test to prevent any such bug from appearing (not just that specific bug, but any bug in that class of bugs). For example, I recently worked on a system that takes a config file, parses its key/value pairs into a map, and then exposes its values in the form of methods called string GetValueOfKey1(), string GetValueOfKey2(), etc. These functions simply contained return map.GetValue(key1);. This worked fine as long as the configuration file was setup correctly; however, as soon as someone made a mistake in the config file (accidentally renamed key1 to Key1 or some such) the application crashed because GetValueOfKey1() couldn't find key1 in the map structure. This error *ultimately resulted from* unhandled input, I created a test to test for *all kinds* of bad input and then implemented the input handling. Applying tests where they're useful prevents us from testing stable code. And then moving forward, we can write tests for all new functionality. On Thu, Apr 4, 2013 at 10:00 AM, Craig webe...@gmail.com wrote: *If anyone is interested in starting a Vala Unit Test project under the umbrella of the elementary community, I'm sure we could get quite a bit of traction from the Vala community at large and I would love to help out. - Dane Henson* * * Not only that, but I imagine it would garner quite a lot of professional developer attention for elementary, since professional devs seem dramatically more exposed to (and interested in) formal testing than hobbyist developers. *I apologize for spamming the mailing list. - Dane Henson* Please don't apologize--from the sounds of it, there is quite a bit of consensus that this is a subject that needs to be discussed. And I for one have found each of your messages profitable. *Unit testing is boring to write so if we just said Everybody. Write unit tests. All Projects. Now. it would really take on. On companies and when developers are paid to work, they can write and put tests everywhere, but it's harder for us. - David Gomes* * * David, I used to think that as well; however, once you learn to write tests correctly (I'm starting that process myself) it becomes more exciting. As Dane mentions later in the thread, when you build the bucket around the water (write tests for existing code), it is certainly drudgery; however, when you write tests *before* you implement the functionality, you 1. wind up with better code (because code must be written in neat modules to provide your tests access to the inputs/outputs they need) 2. get the excitement of writing code and watching your tests pass/fail (and as you learn to write better tests, you get detailed information about exactly what caused the failure) 3. can change your code fearlessly, knowing that if anything breaks, you will be notified immediately The whole process becomes at least a little more exciting, especially if you've experienced a huge untested code base and the fear that comes with having to make a change or implement a feature lest the whole thing come tumbling down on you. *While if we (developers) use the first approach, which is called TDD is much better. We write the test first so we define how our app should behave and how our code is structured already (so all the thinking of the code structure you do it in the tests) which is really great. - Goncalo * * * TDD = Test Driven Development (for the uninitiated). I elaborated on this process to some extent in my previous paragraph. We can also do BDD , if there's
Re: [Elementary-dev-community] How to review and merge branches
That's great. It seemed as though you were against a prettifier when you've been using one all along! The next logical step is to migrate to a dedicated tool (one that is not bound to a certain editor) so users are free to use the editor of their liking. If such a tool is available (and is sufficiently simple to use), it makes no sense to avoid using it. On Apr 1, 2013 4:14 PM, David Gomes da...@elementaryos.org wrote: And that's why I use an editor that formats certain things about code for me. On Mon, Apr 1, 2013 at 10:13 PM, Craig webe...@gmail.com wrote: I think you misunderstand me. A prettifier doesn't force the user's style on the project, but it changes the format of the pushed code to match that of the project so, for instance, other elementary developers aren't plagued by my style and I don't have to mentally manage a conversion between my work style, my personal style, and the styles of the various projects in which I participate. Yes we should review and test or own code, but we should know enough to leverage the accuracy and speed of software for frequent and mundane tasks like reformatting code. On Apr 1, 2013 1:11 PM, Victor victoredua...@gmail.com wrote: You're right Craig, although there's something I still don't understand: Why would somebody want elementary to adapt his/her coding style. It's fine if developers focus on the logic first, using their own coding style, but as a final step those developers should also make sure that their code is consistent with the rest of the code in the project they're working on. Shouldn't we as developers review and test our own code before proposing a patch anyway? We can always adapt the style of new code during that self-review, before making our work available to be reviewed by others. On Mon, Apr 1, 2013 at 8:51 AM, Craig webe...@gmail.com wrote: Personally, I like that I can write code without thinking about the style and then have it styled automatically when I push. It lets me focus on the logic of my program rather than whether it obeys a style guideline. This is especially useful because I participate in projects involving several current languages and each with its own style guideline. I'm not saying we need something like gofmt, but it's foolish to imply that such a tool is useless (especially when we are manually investing time correcting code that could be done automatically). If an appropriate tool doesn't exist, I don't recommend developing one, but I don't see how you can mock gofmt when I can validate my style with no overhead whatsoever while you are doing it manually. Lol. ;-) On Apr 1, 2013 9:28 AM, David Gomes da...@elementaryos.org wrote: Fortunately, most of the developers can write good code. And when they fail to do so we have other developers who review their code. We don't need a fancy tool like gofmt that just changes our code. On Mon, Apr 1, 2013 at 3:25 PM, Craig webe...@gmail.com wrote: The more I read threads like this the more it seems elementary should migrate to Go. :-P On Apr 1, 2013 3:29 AM, Jaap Broekhuizen jaap...@gmail.com wrote: I agree with Victor. Consistency matters because it makes readability and therefore maintainability better. -- Jaap Op 1 apr. 2013 09:09 schreef Victor victoredua...@gmail.com het volgende: Coding style is a subjective topic, and that's why discussing which one works best is completely pointless, since it's a matter of preferences. It's like discussing what is the best color. What is important is consistency, and that's why all the new code proposed for merging should follow elementary's coding style guidelines (which are not published anywhere in the site as far as I know). Whenever you propose code that is styled inconsistently it only gives the impression that you were coding in a hurry, and we don't want to accept that kind of code, even though we have a ton of it already. Thanks for your attention, Victor. On Sun, Mar 31, 2013 at 12:48 PM, Craig webe...@gmail.com wrote: How do you figure? The go language community uses one and they rave about it. We use them at work (c++) as well and its uses an obnoxious style, but it's still more readable than a dozen different conventions. On Mar 31, 2013 5:39 AM, Sergey Shnatsel Davidoff ser...@elementaryos.org wrote: I'm afraid automatic prettifiers are a terrible idea because blindly restyling the code usually makes it lose any remains of readability it used to have. In other words, automatically restyled code is even less readable than code with a foreign coding style. 2013/3/31 David Gomes da...@elementaryos.org I wrote this in order to check for code style errors, but it's not perfect it's just a help-tool: https://github.com/elementary/vala-analyzer We have 'considered' using a prettifier too, but I just use Emacs to fix some stuff on my code - a prettifier script would be too much work and I don't know of any libraries
Re: [Elementary-dev-community] How to review and merge branches
I'm not arguing that gofmt is necessary; anything that facilitates a standard, clear format will suffice. However, I maintain that the vala community would be lucky to have so nice a tool as gofmt. (It really does fix everything) :-P On Apr 1, 2013 4:34 PM, David Gomes da...@elementaryos.org wrote: I'm not against prettifiers, I just don't see the need for something like gofmt that aligns comments, indents with tabs and supposedly fixes everything. I'm sure vala-analyzer is good for what we need now and we have other priorities now, but maybe one of these days somebody makes a prettifier, it's just that it's not an easy task. Also, let's please end the discussion on this thread please, we're really off-topic. On Mon, Apr 1, 2013 at 10:26 PM, Craig webe...@gmail.com wrote: That's great. It seemed as though you were against a prettifier when you've been using one all along! The next logical step is to migrate to a dedicated tool (one that is not bound to a certain editor) so users are free to use the editor of their liking. If such a tool is available (and is sufficiently simple to use), it makes no sense to avoid using it. On Apr 1, 2013 4:14 PM, David Gomes da...@elementaryos.org wrote: And that's why I use an editor that formats certain things about code for me. On Mon, Apr 1, 2013 at 10:13 PM, Craig webe...@gmail.com wrote: I think you misunderstand me. A prettifier doesn't force the user's style on the project, but it changes the format of the pushed code to match that of the project so, for instance, other elementary developers aren't plagued by my style and I don't have to mentally manage a conversion between my work style, my personal style, and the styles of the various projects in which I participate. Yes we should review and test or own code, but we should know enough to leverage the accuracy and speed of software for frequent and mundane tasks like reformatting code. On Apr 1, 2013 1:11 PM, Victor victoredua...@gmail.com wrote: You're right Craig, although there's something I still don't understand: Why would somebody want elementary to adapt his/her coding style. It's fine if developers focus on the logic first, using their own coding style, but as a final step those developers should also make sure that their code is consistent with the rest of the code in the project they're working on. Shouldn't we as developers review and test our own code before proposing a patch anyway? We can always adapt the style of new code during that self-review, before making our work available to be reviewed by others. On Mon, Apr 1, 2013 at 8:51 AM, Craig webe...@gmail.com wrote: Personally, I like that I can write code without thinking about the style and then have it styled automatically when I push. It lets me focus on the logic of my program rather than whether it obeys a style guideline. This is especially useful because I participate in projects involving several current languages and each with its own style guideline. I'm not saying we need something like gofmt, but it's foolish to imply that such a tool is useless (especially when we are manually investing time correcting code that could be done automatically). If an appropriate tool doesn't exist, I don't recommend developing one, but I don't see how you can mock gofmt when I can validate my style with no overhead whatsoever while you are doing it manually. Lol. ;-) On Apr 1, 2013 9:28 AM, David Gomes da...@elementaryos.org wrote: Fortunately, most of the developers can write good code. And when they fail to do so we have other developers who review their code. We don't need a fancy tool like gofmt that just changes our code. On Mon, Apr 1, 2013 at 3:25 PM, Craig webe...@gmail.com wrote: The more I read threads like this the more it seems elementary should migrate to Go. :-P On Apr 1, 2013 3:29 AM, Jaap Broekhuizen jaap...@gmail.com wrote: I agree with Victor. Consistency matters because it makes readability and therefore maintainability better. -- Jaap Op 1 apr. 2013 09:09 schreef Victor victoredua...@gmail.com het volgende: Coding style is a subjective topic, and that's why discussing which one works best is completely pointless, since it's a matter of preferences. It's like discussing what is the best color. What is important is consistency, and that's why all the new code proposed for merging should follow elementary's coding style guidelines (which are not published anywhere in the site as far as I know). Whenever you propose code that is styled inconsistently it only gives the impression that you were coding in a hurry, and we don't want to accept that kind of code, even though we have a ton of it already. Thanks for your attention, Victor. On Sun, Mar 31, 2013 at 12:48 PM, Craig webe...@gmail.com wrote: How do you figure? The go language community uses one and they rave about it. We use them at work (c++) as well and its uses
Re: [Elementary-dev-community] How to review and merge branches
How do you figure? The go language community uses one and they rave about it. We use them at work (c++) as well and its uses an obnoxious style, but it's still more readable than a dozen different conventions. On Mar 31, 2013 5:39 AM, Sergey Shnatsel Davidoff ser...@elementaryos.org wrote: I'm afraid automatic prettifiers are a terrible idea because blindly restyling the code usually makes it lose any remains of readability it used to have. In other words, automatically restyled code is even less readable than code with a foreign coding style. 2013/3/31 David Gomes da...@elementaryos.org I wrote this in order to check for code style errors, but it's not perfect it's just a help-tool: https://github.com/elementary/vala-analyzer We have 'considered' using a prettifier too, but I just use Emacs to fix some stuff on my code - a prettifier script would be too much work and I don't know of any libraries that would help me with the task. On Sun, Mar 31, 2013 at 3:34 AM, Craig webe...@gmail.com wrote: Good work David. Have you (elementary) considered using a prettifier to standardize a code style upon pushing to your trunk? On Mar 28, 2013 7:17 PM, Cody Garver c...@elementaryos.org wrote: Cool, it's pretty thorough. On Wed, Mar 27, 2013 at 7:58 AM, David Gomes da...@elementaryos.orgwrote: http://dl.dropbox.com/u/19899464/reviewstutorial.html Hello guys, From time to time somebody still has doubts on how to use Launchpad and Bazaar to review and merge branches to trunk so I wrote a tutorial. Note though that it may need expansion. Many times, even experienced developers who have been in the Apps Team for a long time make mistakes so even if you already know how to do it, reading the tutorial won't hurt. I also recommend that all developers that in the future are to join the Apps Team read this several times because even though we can always revert messed-up commits, it's better to do it right at the first time. Best regards, David Munchor Gomes -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Cody Garver -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Sergey Shnatsel Davidoff OS architect @ elementary -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] Autovala: new program for developers
If this works intuitively, you may have won me back to elementary development. On Mar 29, 2013 7:32 PM, Sergio Costas rasters...@gmail.com wrote: Hi all: Several days ago, another user commented that using CMake with Vala was quite hard and difficult. After thinking about it, I reached the conclusion that using CMake is quite boring and repetitive, so I said to myself: why not creating a tool that automatically generates the CMakeLists.txt files, based on several rules and heuristics? The result is Autovala. It not only deduces where to put each file and how to compile the binaries or libraries from the sources, but also automagically finds the packages used in each project, and passes them to the compiler. It also creates automatically the .gir and .vapi files for libraries. You have a longer and more precise description in the README file, in the github repository: https://github.com/rastersoft/autovala It is still an alpha version, but fully usable. It still lacks some minor things, like generating the .pc file for pkg-config, and other things. For those I will need some help. If someone volunteers... Enjoy it! -- Nos leemos RASTER(Linux user #228804) ras...@rastersoft.com http://www.rastersoft.com -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] Noise doesn't comply to HIG
As a data point, I never use the sound indicator for anything besides adjusting volume. I can't put my finger on why, and I've certainly tried; however, I always find myself going back to the application to control the application. Again, this is just my data point. :) On Wed, Mar 13, 2013 at 10:32 AM, Sergey Shnatsel Davidoff ser...@elementaryos.org wrote: 2013/3/13 Daniel Foré dan...@elementaryos.org Yea except that you can already access it quickly through the sound indicator. That requires more clicks and much higher precision of cursor navigation. Fitts' law in action. Besides, I doubt that opening music player through that indicator sufficiently discoverable. I bet many people won't discover option even if they open the indicator, and they probably won't do that in the first place. Also, what happened to the Indicators Never Launch Apps mantra? Nevermind, don't bother answering this one, I'm content with just seeing it gone. -- Sergey Shnatsel Davidoff OS architect @ elementary -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] Go-like build tools for Vala
Thanks David, I agree, compiling an existing CMake project is fairly straight forward; however, adding files or starting a project from scratch has been an exercise in frustration. Moreover, while I would love to have the time to learn CMake, I really shouldn't have to as it provides no benefit (as far as I can tell) compared against the go build solution. Generally speaking, the modern development environment is sufficiently complex between IDEs, version control systems, online code hosting, bug management, distribution systems, test servers, build servers, etc., (that's not to mention the complexities of the actual problems for which a developer is trying to write solutions)--it just seems like the unnecessary complexities of metadata-based build systems aren't worth learning when automatic systems should (and often do) exist. Personally, I can't spare the time to learn another tool that will be obsolete soon. And while CMake and the like _are_ broadly applicable, most languages have IDEs capable of managing the complexities internally (Vala is the only language that's required me to learn CMake or Autotools). Of all the Vala IDEs I've found that claim to be able to support CMake or Autotools, none are able to handle more than a small fraction of the conceivable project structures (if memory serves, Anjuta couldn't even handle most Elementary projects). Finally, rest assured, I haven't been actively working on Elementary for lack of time; however, when I had the time to contribute, the project management (or lackthereof) was a huge buzzkill. Thanks for your response, Craig :) On Tue, Feb 5, 2013 at 3:16 PM, David Gomes da...@elementaryos.org wrote: If by Elementary, you mean elementary OS, I'd like to say that I've been doing desktop development there for almost a year now and only rarely did I have to use CMake to its full extent. All I have to do is fetch a project, mkdir build; cd build; cmake ..;make;, and after I've fetched a project, I really only have to write some code cd build;make;. I really hope CMake isn't the reason you aren't helping us, because right now we could really use some help! However, I did learn how to write CMakeLists.txt files on side projects, which came in handy later on for elementary OS development, but to help us, there's no need to struggle with CMak. If you need to write anything, I encourage you to learn because it's really easy - https://github.com/davidgomes/2dplatformer/blob/master/CMakeLists.txt, that is the CMakeLists.txt I had to write for a side project, and it was quite simple (also, I do realize it's pretty badly-written, from what I've been told on #cmake). Those Go build tools you're talking about look cool and easy to use, but they are go-only. I think you should learn CMake or Autotools because you can use them with every language/library/framework that needs building (even Go!). Anyways, go build is probably not too hard to write for Vala projects that don't use any external libraries. Oh, and I just remembered, autotools, CMake and the likes help you A LOT with packaging your applications. They handle lots of stuff that would be a PITA to do yourself. David Munchor Gomes On Tue, Feb 5, 2013 at 9:05 PM, Craig webe...@gmail.com wrote: Firstly, let me just say that CMake and Make are a pain to learn. I'm a professional software developer and I still can't figure them out. In my job, we use tools that automate the nightmare that is project management (usually IDEs) and it's usually still unpleasant. The tedium of these tools is the one thing keeping me from using Vala as a primary programming language and otherwise contributing to Elementary. That said, lately I've been getting into Go (golang), and I'm finding it to be an AMAZING language; however, it's only 3 years old, thus it doesn't have an extensive collection of libraries. The only prominent GTK library is very immature and (I believe) it only supports some features from GTK+2.0 (none from 3.0). Among the more amazing features of Go are its build environment tools. `go build [app-name]` is all that is needed to build an entire application--no messing with CMakeLists or makefiles (no project metadata of any kind, in fact). Furthermore, `go install [app-name]` will build and install the application to a location in your PATH, making it instantly executable. Go also comes with an awesome test suite out of the box, and `go get [http://path.to.online/repository]`http://path.to.online/repository%5Dwill automatically fetch a package from a public code repository (it works with git and several other repo types) and store the files alongside your own source code. I think it would be a huge help to elementary developers if we at least created a Vala version of (at least) the `go build` tools to facilitate project management. This would dramatically lower the entry barrier to Elementary development, and it would encourage an organized
Re: [Elementary-dev-community] ARM enablement nearly complete; testing needed
I've just installed the Pantheon group from the daily ppa on a Samsung ARM Chromebook running an Ubuntu Build.. Everything installed fine and is running great. The only issue is the FBDEV xorg driver I'm using isn't rendering pantheon brilliantly. I'm going to switch over to the amsoc driver later today to try it out instead. On 15 December 2012 00:38, Cody Garver c...@elementaryos.org wrote: Great news! Posted it to reddithttps://lists.launchpad.net/elementary-dev-community/msg01889.html . On Fri, Dec 14, 2012 at 6:14 PM, Sergey Shnatsel Davidoff ser...@elementaryos.org wrote: Hey guys, The armhf enablement of Daily PPA is nearly complete now. The only remaining items are failed builds of some Switchboard plugs which should resolve themselves in an hour or two. In all other respects armhf situation is 1:1 equal to the i386 and amd64 ones. And guess what it means? Exactly - it's time to test this stuff! If you happen to be running Ubuntu's armhf port, please take a backup of your system (just in case), add ppa:elementary-os/daily to your software sources and install the pantheon package (or cherrypick whatever dependencies of it you prefer). Then check out how apps work (and if they work at all) and report your findings to this mailing list! I don't anticipate any major issues in applications because all Vala code is translated to C+GLib code and thus is portable by definition. Also, we're not yet in a position to consider any crashes appearing on ARM architecture-specific :) I don't code in Vala myself so developers may correct me on this point further in this thread. Still, SoCs may have different performance bottlenecks than desktops do, so please report anything that works unusually slowly. The situation with Pantheon Shell is more interesting. In theory, Gala should run on OpenGL ES 2.0 (and OpenGL 1.3 too, which took me by surprise). However, I'm not aware of anybody actually trying that. So if you happen to have hardware 3D acceleration on your ARM device, please test Gala and report your findings. Don't forget to include the output of es2_info command! Also, it would be nice to be able to retrace Apport crashes submitted from armhf, so that developers can investigate and fix them. This requires an armhf-capable machine to run the retracer on. If you have any resources to spare on an armhf-capable server you run, or know how to set up ARMv7 emulation on amd64, please contact me. Kudos to Rico for making the armhf enablement happen! -- Sergey Shnatsel Davidoff OS architect @ elementary -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Cody Garver -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] Fwd: INK and model based design
Yeah, I can work with them. Can you send me their contact info or link me to their models? On Nov 1, 2012 4:21 PM, Sergey Shnatsel Davidoff ser...@elementaryos.org wrote: Hey Craig, I've talked to Victor, the guy behind Noise, and according to him both music player codebases we have, Noise and BeatBox, could really use a well-thought-out more-object-oriented refactor. He and Lucas (xapantu) have kicked off an initial UML model and they have some extensive specs too, but I'm not sure if they're still relevant. Right now Victor is just patching up Noise for Luna, but they could use any help/input you can provide after the initial Luna release. If the music player experiment works out, I believe the approach can be expanded it to other projects. TIA, -- Sergey Shnatsel Davidoff OS architect @ elementary -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] Another suggestion for Luna+1: integrate workspaces and expose
+1 On Oct 25, 2012 3:36 PM, Sergio Costas rasters...@gmail.com wrote: Hi all: I want to propose a change for Luna+1 (of course; Luna is frozen and only accepts bugfixes): to integrate workspaces and expose all windows, like Gnome Shell. I think it's more natural, because you have only one action for managing all your windows, and simplifies the action of moving one window from one workspace to another. Something like this: http://www.rastersoft.com/expose_workspace_mockup.jpg -- Nos leemos RASTER(Linux user #228804) ras...@rastersoft.com http://www.rastersoft.com -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
[Elementary-dev-community] Elementary project editor
Hey folks, due to the complexities of Cmake projects, I was wondering if there has been any discussion regarding an elementary project editor? If not, I was thinking such a thing could 1) create/setup a new elementary project 2) provide for project configuration (adding/removing source files, libraries, dependencies, etc) 3) execute builds (CMake + make) 4) eventually become an elementary IDE I'm sure there are other advantages as well, but far as I can tell, starting and building CMake projects is the most significant barrier to the elementary development environment, and such a solution would allow otherwise proficient programmers to make sizable contributions without having to waste their time (and that of everyone they ask for help) getting around CMake. To be clear, I'm not proposing this for Luna, but as a consideration for the future. -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] Elementary project editor
I said I don't think this should be speed with Luna. :) I'll check it out! Thanks! On Oct 22, 2012 4:02 PM, David Gomes da...@elementaryos.org wrote: That is pretty much the description of Tom95's 'editor'. It's on his Launchpad, look it up. I very much disagree this should be shipped in Luna, though, people don't want an IDE to be included in an OS, just a normal text editor, like Scratch. On Mon, Oct 22, 2012 at 9:54 PM, Craig webe...@gmail.com wrote: Hey folks, due to the complexities of Cmake projects, I was wondering if there has been any discussion regarding an elementary project editor? If not, I was thinking such a thing could 1) create/setup a new elementary project 2) provide for project configuration (adding/removing source files, libraries, dependencies, etc) 3) execute builds (CMake + make) 4) eventually become an elementary IDE I'm sure there are other advantages as well, but far as I can tell, starting and building CMake projects is the most significant barrier to the elementary development environment, and such a solution would allow otherwise proficient programmers to make sizable contributions without having to waste their time (and that of everyone they ask for help) getting around CMake. To be clear, I'm not proposing this for Luna, but as a consideration for the future. -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] [Elementary-Dev-Community] Vala Version and Luna
I'm generally pretty ignorant with respect to the differences between versions and how important it is to maintain consistency between them. Care to give us a primer? On Oct 22, 2012 4:36 PM, David Gomes da...@elementaryos.org wrote: Hey there, Some time ago we switched to Vala 0.16, it was a very important change. Do you guys think it's time to move to 0.17? I understand it's too early for 0.18, but most of the devs are already using 0.17 because of certain things that we really need. -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
[Elementary-dev-community] Mouse-based Workspace Switching
Having just switched from Ubuntu 10.10 to Elementary on my desktop machine (which I haven't used in over a year), I've noticed a real irritation when trying to switch workspaces while one hand is on the mouse--the user has to take a hand off the mouse, put both hands on the keyboard (many keyboards don't have a super key near the arrow keys), activate the workspace switching motion, and then return their hand to their mouse to continue working. This isn't as big a problem on a laptop as most laptops have semi-decent trackpads right below the keyboard; however, on a typical desktop, this is a real irritation. Under older versions of Ubuntu (the ones that used the compiz cube by default) I liked being able to hold ctrl+alt and then click/drag to change workspaces; however, that still requires moving one hand to the keyboard which still feels tedious if your hand isn't there already. I propose coming up with a solution. It may not seem like a big deal, but if you're like me (having one application open per workspace) this can be a real annoyance. Thoughts? -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] Mouse-based Workspace Switching
Can we sub in a mouse activity in place of a key combo? On Oct 7, 2012 5:03 PM, Sergio Costas rasters...@gmail.com wrote: I found how to change the keys for moving from one workspace to another: open dconf-editor, and go to org-gnome-desktop-wm-keybindings and there, modify switch-to-workspace-left and switch-to-workspace-right. El 07/10/12 19:20, satch...@gmail.com escribió: While being able to switch workspaces with one hand, I think WASD is non-obvious, especially when all four are commonly used as window management shortcuts in other OSes (the first three in Ubuntu and the last one in Windows; I think Super+S is also used in Windows for system something or the other). I think a launcher makes sense, as do hot corners. On 7 October 2012 22:43, Sergey Shnatsel Davidoff ser...@elementaryos.org wrote: 2012/10/7 Sergio Costas rasters...@gmail.com Even would be nice to be able to use Super+z to go left, and Super+x to go right, or something like that. I hate to have to move the mouse down to a hot corner, or having to drop the mouse. There's a proposal to assign the actions of Super+Arrow keys to Super+WASD keys which is a great idea IMHO. -- Sergey Shnatsel Davidoff OS architect @ elementary -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Nos leemos RASTER(Linux user #228804) ras...@rastersoft.com http://www.rastersoft.com -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] Mouse-based Workspace Switching
I'm confused. Super+Z doesn't do anything for me... Am I using an old version? On Sun, Oct 7, 2012 at 5:33 PM, Sergio Costas rasters...@gmail.com wrote: I don't know... Anyway, it's not perfect, because there's a problem with key autorepeat :( If you press Super, then Z, it goes left; if you then release Z, but keep Super, it stops (as expected), but if you now press again Z, it doesn't do left again; you must keep both keys pressed, or release both and press them again. El 08/10/12 00:25, Craig escribió: Can we sub in a mouse activity in place of a key combo? On Oct 7, 2012 5:03 PM, Sergio Costas rasters...@gmail.com wrote: I found how to change the keys for moving from one workspace to another: open dconf-editor, and go to org-gnome-desktop-wm-keybindings and there, modify switch-to-workspace-left and switch-to-workspace-right. El 07/10/12 19:20, satch...@gmail.com escribió: While being able to switch workspaces with one hand, I think WASD is non-obvious, especially when all four are commonly used as window management shortcuts in other OSes (the first three in Ubuntu and the last one in Windows; I think Super+S is also used in Windows for system something or the other). I think a launcher makes sense, as do hot corners. On 7 October 2012 22:43, Sergey Shnatsel Davidoff ser...@elementaryos.org wrote: 2012/10/7 Sergio Costas rasters...@gmail.com Even would be nice to be able to use Super+z to go left, and Super+x to go right, or something like that. I hate to have to move the mouse down to a hot corner, or having to drop the mouse. There's a proposal to assign the actions of Super+Arrow keys to Super+WASD keys which is a great idea IMHO. -- Sergey Shnatsel Davidoff OS architect @ elementary -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Nos leemos RASTER(Linux user #228804) ras...@rastersoft.com http://www.rastersoft.com -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Nos leemos RASTER(Linux user #228804) ras...@rastersoft.com http://www.rastersoft.com -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] Time for a change in AppMenu icon?
I agree, Sam. I think this also highlights the importance of clearly defining the intentional function for various UI components. Perhaps it would be useful to separate out the various pieces of functionality into an overflow component and a settings component (or separate out the functionality differently). On Sun, Sep 30, 2012 at 3:19 PM, Sam Tate s...@mtate.me.uk wrote: Greetings, I think it's useful to get a discussion going every now and then about certain UX paradigms, no matter how small (we're all about attention to detail, right?) I really don't like the AppMenu icon. The concept is great - Android uses something very similar in the overflow menu, and other operating systems probably do too. It's a fantastic way to hide less commonly used buttons to stop the toolbar getting too cluttered. However, the cog icon doesn't make any sense to me. It sends the message of Settings/Preferences to the user, and this is *not *the only thing that the AppMenu is for. It houses About pages, functions (e.g. Rescan music folder) and more. It would make more sense to change the icon to something similar to Chrome's 3 line icon (http://i.imgur.com/ryKKG.png) which conveys the message much better. We should ideally try to do this before Luna, since the AppMenu is such a core part of the OS, and we don't want to alienate the flocks of new Luna users in L+1 by changing it then ;) Thoughts? Sam Tate -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] Time for a change in AppMenu icon?
Chrome just swapped out their wrench for the Android-esque 3-line symbol, as previously mentioned. The wrench was an iconic part of Chrome as they pioneered the minimalistic browser interface (now each of the major browsers has a similar feature in a similar location). And Chrome has been exposed to a much larger percentage of their potential userbase than Elementary. Anyway, Elementary has seen a single release (Jupiter), which has hardly defined Elementary in my opinion. Elementary's identity is only in the beginning of its formation, and I think now is exactly the time to be making large changes (before its identity settles concretely in the minds of its users). If we agree a change is positive, let's not let branding stand in the way of a good user experience (I would rather Elementary's identity be tied to a positive and ever-improving user experience than a particular symbol or other static configuration). Furthermore, *minimalism is* generic and lacking in personality in contrast to many design styles; however, elementary stands out because it is minimalist and its personality is heralded by its subtlety. In addition to the 3 lines being the broader standard for such a UX feature, it also has the advantage of being more subtle, which seems to mesh with Elementary's design DNA. Just my $0.02 On Sun, Sep 30, 2012 at 3:59 PM, Keith Adair kjz...@gmail.com wrote: I think we'd be taking a major risk in changing that icon. To me, that cog has grown to be an iconic symbol of the elementary project, along with the two iterations of the e logo. It signifies simplification; that this program is so simple that it only requires on simple sub menu for options. A lines logo to me seems generic, and lacking in personality. The cog IS elementary, and has been since the meager days of elementary-nautilus. It seems to me that I would rather miss the little cog in exchange for a generic icon. On Sep 30, 2012 1:34 PM, Craig webe...@gmail.com wrote: I agree, Sam. I think this also highlights the importance of clearly defining the intentional function for various UI components. Perhaps it would be useful to separate out the various pieces of functionality into an overflow component and a settings component (or separate out the functionality differently). On Sun, Sep 30, 2012 at 3:19 PM, Sam Tate s...@mtate.me.uk wrote: Greetings, I think it's useful to get a discussion going every now and then about certain UX paradigms, no matter how small (we're all about attention to detail, right?) I really don't like the AppMenu icon. The concept is great - Android uses something very similar in the overflow menu, and other operating systems probably do too. It's a fantastic way to hide less commonly used buttons to stop the toolbar getting too cluttered. However, the cog icon doesn't make any sense to me. It sends the message of Settings/Preferences to the user, and this is *not *the only thing that the AppMenu is for. It houses About pages, functions (e.g. Rescan music folder) and more. It would make more sense to change the icon to something similar to Chrome's 3 line icon (http://i.imgur.com/ryKKG.png) which conveys the message much better. We should ideally try to do this before Luna, since the AppMenu is such a core part of the OS, and we don't want to alienate the flocks of new Luna users in L+1 by changing it then ;) Thoughts? Sam Tate -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] Fwd: INK and model based design
On Thu, Sep 27, 2012 at 5:03 AM, Sergey Shnatsel Davidoff ser...@elementaryos.org wrote: Model centric programs boasts high reusability, efficiency, portability, and simplicity (which translates into reduced maintenance, testability, changeability and easier understandability) all for the minor cost of prolonging the code producing phase in favor of a longer design phase. In short, parties interested in pushing UML claim that it's a cure-all. To be clear, I'm not talking about UML specifically. I'm talking about model-centric development. UML is just the most noted means of representing model based design. It's just a higher level of abstraction. It's implemented all over, and most developers are probably trying to implement it subconsciously. Many companies use UML tools to make/edit a system model and those tools will generate code from the model abstraction in much the same way that a compiler efficiently converts a high level language into assembly language. Many companies do this is not an argument. Many (or rather, most) companies make UIs utterly inconsistent with the rest of the system to make them better; most companies write proprietary software, many companies use CVS for revision control, etc. We're not taking up any of this. It wasn't intended to be an argument. Daniel asked who is using it. I'm noting that it's not an entirely new idea. People have been making model based designs for years. Only now is its potential being realized. As the value of quality software has become increasingly quantifiable, employers have been demanding employees who are familiar with model based design, which is why schools are rapidly adopting UML into their CS curriculum. Furthermore, are you implying that model-based design somehow lends itself to a particular quality of UI design or version system? The analogy with compilers or other higher-level wrappers is not true. With high-level wrappers like Vala all you need to know is how to work with the wrapper, and the machine does the rest. With UML you have to know both UML and the programming language and work with both in one project. Is it worth to raise the entry barrier by requiring to learn/know not only GTK and Vala but UML too? It is true. UML can be compiled down into machine code without manual code manipulation. However, as I don't know of any OSS UML compilers and, except for the crazy expensive industry compilers, the technology really isn't there to compile it down efficiently anyway. However, the analogy works. It's widely considered good programming practice to program in high level terms. It's considered beneficial to abstract away the unnecessary details to enable the programmer to focus on the task at hand. If you espouse object-oriented programming or programming in a language other than Assembly or machine code, model-based development is logical. With object-oriented programming in particular, the subconscious objective is typically some sort of a model based abstraction anyway--I'm simply proposing using formal, conceptual tools to help you reach that objective quickly and accurately. I'll write what this looks like more specifically when I have the time. The other problem with UML is that it's a kind of documentation describing the code. And we all know how much developers hate updating documentation. The diagrams will quickly become outdated and misleading, unless developers spend time on updating them, all the time. It certainly can be a way of documenting the code. However, if you do your work in a sort of rough-draft UML (edit your objects, states, and algorithms via UML diagrams), you can quickly convert it to clean, accurate code, and have the documentation to boot. I get the impression you think I'm espousing a strict adherence to UML. I'm not. I'm talking about employing it to the extent that it makes sense to suit elementary's goals. Again, I'm working on a blog post that I hope will describe my vision more fully. Until then, try not to jump to any crazy conclusions. Consider it as a tool--try to understand what about it is useful and if any part of this tool could benefit you. But you're right--it will require some change and I don't expect everyone to welcome it with open arms. I'm just asking you to wait until you've actually heard my proposal before you get up in arms. And, most importantly, I doubt we would benefit from model-centric approach at all. Most elementary apps are simple and concise, and communicate over simple and obvious interfaces. We don't build any complicated systems or engage in system programming (yet). So for most of our apps using UML will be an unnecessary burden. If Elementary apps are so simple that they never have bugs and never take more than a week to program, then you're absolutely right--don't use a model-centric approach. Anyway, as I mentioned earlier, Elementary Apps already _are_ developed using a model-centric approach; however, you're
Re: [Elementary-dev-community] INK and model based design
First of all, I want to apologize as autocorrect insists on changing UML into INK. Secondly, I was purposefully vague so as to glean some understanding as to what elementary developers know about these design disciplines. Furthermore, I haven't had time to find and link-to a good article explaining these disciplines, and, while I'm working on a blog post of my own explaining the issues, I think it would be beneficial to start some conversation on the subject in the meanwhile. So I apologize for the inconvenience, but I promise it is out of necessity. On Sep 26, 2012 9:22 AM, Cassidy James cass...@elementaryos.org wrote: Hey Craig, Thanks for bringing this up on the mailing list. I know Cody has been looking into model-based design and UML a bit lately, but I don't know much about it. It might help me and the developers who aren't as familiar with it if you could give a quick description and/or some links for note info. Thanks! Cassidy James On Sep 26, 2012 6:35 AM, weberc2 webe...@gmail.com wrote: UML and model based design principles are the next big thing in the world of software. Why aren't these being employed at elementary? Discuss. Sent from my U.S. Cellular® Smartphone -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
[Elementary-dev-community] Fwd: INK and model based design
-- Forwarded message -- From: Craig webe...@gmail.com Date: Wed, Sep 26, 2012 at 4:54 PM Subject: Re: [Elementary-dev-community] INK and model based design To: Daniel Foré dan...@elementaryos.org Again, apologies for lack of information. It's a design process, I suppose. It pertains primarily to developers. It's implemented all over, and most developers are probably trying to implement it subconsciously. The foundational principal is that you create a conceptual model of the system you are designing (something most developers try to do mentally) using UML as a tool to record, visualize, and communicate said model, rather than using the implementation (the code) to try to understand the developer's thought process. It emphasizes planning and design over coding and accordingly separates the process of modeling/designing from that of programming. Many companies use UML tools to make/edit a system model and those tools will generate code from the model abstraction in much the same way that a compiler efficiently converts a high level language into assembly language. However, that is rather cutting edge and I don't think any good OSS tools exist to automate the code generation process yet, so I'm espousing the manual approach from which these code-generation tools are derived. Model centric programs boasts high reusability, efficiency, portability, and simplicity (which translates into reduced maintenance, testability, changeability and easier understandability) all for the minor cost of prolonging the code producing phase in favor of a longer design phase. On Sep 26, 2012 4:23 PM, Daniel Foré dan...@elementaryos.org wrote: Craig, Can you give even the vaguest hint to what this is? Is it a toolkit, a library, a language, a process? What part of the community is this relevant to? Translators, designers, devs, project leads? Where is this implemented with success? Etc etc Best Regards, Daniel Foré El sep 26, 2012, a las 11:06 a.m., Craig webe...@gmail.com escribió: Daniel, like I said, I'm trying to put something together, but the primary obstacle is time. Any familiarization you (read: everyone participating in the development process) can do on your own will be beneficial, in my opinion. On Wed, Sep 26, 2012 at 11:58 AM, Daniel Foré dan...@elementaryos.org wrote: I agree it'd be nice to get an overview of what exactly UML is. Don't forget many of us are not software professionals but merely hobbyists ;) On Wed, Sep 26, 2012 at 7:44 AM, Craig webe...@gmail.com wrote: First of all, I want to apologize as autocorrect insists on changing UML into INK. Secondly, I was purposefully vague so as to glean some understanding as to what elementary developers know about these design disciplines. Furthermore, I haven't had time to find and link-to a good article explaining these disciplines, and, while I'm working on a blog post of my own explaining the issues, I think it would be beneficial to start some conversation on the subject in the meanwhile. So I apologize for the inconvenience, but I promise it is out of necessity. On Sep 26, 2012 9:22 AM, Cassidy James cass...@elementaryos.org wrote: Hey Craig, Thanks for bringing this up on the mailing list. I know Cody has been looking into model-based design and UML a bit lately, but I don't know much about it. It might help me and the developers who aren't as familiar with it if you could give a quick description and/or some links for note info. Thanks! Cassidy James On Sep 26, 2012 6:35 AM, weberc2 webe...@gmail.com wrote: UML and model based design principles are the next big thing in the world of software. Why aren't these being employed at elementary? Discuss. Sent from my U.S. Cellular® Smartphone -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Best Regards, Daniel Foré elementaryos.org -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] [Elementary-translators] Add the 8 most popular language packs to the ISO image
I have never successfully made a live USB. I'm sure it's easy once you learn how to do it, but until it's foolproof, I think CD is the way to go. Moreover, a size limit does us to get rid of unnecessary bloat. On Sep 24, 2012 9:06 AM, Chris Triantafillis christriant1...@gmail.com wrote: My opinion is that we should increase the size limit and encourage people use USB rather than CD... CD is harmfull for the enviroment too... 2012/9/24 Daniel Foré dan...@elementaryos.org Alrighty, well if we think it'll fit, I'm down with adding more languages. Best Regards, Daniel Foré El sep 23, 2012, a las 10:50 p.m., Eduard Gotwig eduardgot...@gmail.com escribió: Daniel Fore: The stuff gets compressed with squashfs to like 1/3 of the original size.That means around 46/47 MB. 2012/9/23 Daniel Foré dan...@elementaryos.org Currently we want to fit on a CD, so 700MB Best Regards, Daniel Foré El sep 23, 2012, a las 12:32 p.m., Chris Triantafillis christriant1...@gmail.com escribió: What is the size limit? 2012/9/23 Daniel Foré dan...@elementaryos.org Sounds like we really don't have room for that. We have room for 50 more MB. So maybe we can choose like 3? Best Regards, Daniel Foré El sep 23, 2012, a las 12:25 p.m., Eduard Gotwig eduardgot...@gmail.com escribió: I included here Russian as well, couse its used quite often: 140 MB are going to be used after this operation by apt-get : sudo apt-get --no-install-recommends --download-only install language-pack-gnome-pl language-pack-gnome-es language-pack-gnome-it language-pack-gnome-ru language-pack-gnome-nl language-pack-gnome-fr language-pack-gnome-pt language-pack-gnome-de language-pack-gnome-en When someone wants to test that, go for it and include it in your custom build with congrego ;) 2012/9/23 Craig webe...@gmail.com I think American English is pretty standard in computing, even internationally. Not that it will be a serious impediment d either way. On Sep 23, 2012 1:28 PM, David Gomes da...@elementaryos.org wrote: First of all, English and Portuguese will be a problem. How can we decide which version of English and Portuguese to include? Sure, Portuguese is one of the most spoken languages in the world, but it's not because of the roughly 10 million inhabitants of Portugal, it's more due to the 200 million inhabitants of Brazil. So, we'd probably include Brazillian Portuguese. But English would be harder. There are more Americans than British, but a lot of people are anti-American English or so. The whole move of including 8 languages. I'm not sure, I'd like to know how much space that is. David Munchor Gomes On Sun, Sep 23, 2012 at 7:21 PM, Eduard Gotwig eduardgot...@gmail.com wrote: 2012/9/23 Eduard Gotwig got...@ubuntu.com Hey, I think about if we can add the 8 most popular languagee packs for GNOME to the ISO image? There is still space left. These 8 languages should be the ones, that are available on our new website: - [image: English]English - [image: Français]Français - [image: Deutsch]Deutsch - [image: Italiano]Italiano - [image: Español]Español - [image: Português]Português - [image: Polski]Polski - [image: Nederlands]Nederlands We cant include all, becouse they take too much space I guess. -- Mailing list: https://launchpad.net/~elementary-translators Post to : elementary-translat...@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-translators More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Best Regards, Chris Triantafillis -- Best Regards, Chris Triantafillis -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] [Elementary-translators] Add the 8 most popular language packs to the ISO image
If we keep the CD size limit, people can be free to choose their medium while still discouraging bloat. On Sep 24, 2012 9:11 AM, satch...@gmail.com satch...@gmail.com wrote: I think CDs are obsolete technology. Even here in India, CDs are slowly being phased out as the price of USB drives drops daily. USB drives are reusable, install and run OSes faster and, as Chris Triantafillis points out, are less harmful to the environment. If elementary is trying to be disciplined about the image size (as Ubuntu is), then I respect that. But there's no need to adhere to such an ancient and restrictive limit. On 24 September 2012 19:35, Chris Triantafillis christriant1...@gmail.com wrote: My opinion is that we should increase the size limit and encourage people use USB rather than CD... CD is harmfull for the enviroment too... 2012/9/24 Daniel Foré dan...@elementaryos.org Alrighty, well if we think it'll fit, I'm down with adding more languages. Best Regards, Daniel Foré El sep 23, 2012, a las 10:50 p.m., Eduard Gotwig eduardgot...@gmail.com escribió: Daniel Fore: The stuff gets compressed with squashfs to like 1/3 of the original size.That means around 46/47 MB. 2012/9/23 Daniel Foré dan...@elementaryos.org Currently we want to fit on a CD, so 700MB Best Regards, Daniel Foré El sep 23, 2012, a las 12:32 p.m., Chris Triantafillis christriant1...@gmail.com escribió: What is the size limit? 2012/9/23 Daniel Foré dan...@elementaryos.org Sounds like we really don't have room for that. We have room for 50 more MB. So maybe we can choose like 3? Best Regards, Daniel Foré El sep 23, 2012, a las 12:25 p.m., Eduard Gotwig eduardgot...@gmail.com escribió: I included here Russian as well, couse its used quite often: 140 MB are going to be used after this operation by apt-get : sudo apt-get --no-install-recommends --download-only install language-pack-gnome-pl language-pack-gnome-es language-pack-gnome-it language-pack-gnome-ru language-pack-gnome-nl language-pack-gnome-fr language-pack-gnome-pt language-pack-gnome-de language-pack-gnome-en When someone wants to test that, go for it and include it in your custom build with congrego ;) 2012/9/23 Craig webe...@gmail.com I think American English is pretty standard in computing, even internationally. Not that it will be a serious impediment d either way. On Sep 23, 2012 1:28 PM, David Gomes da...@elementaryos.org wrote: First of all, English and Portuguese will be a problem. How can we decide which version of English and Portuguese to include? Sure, Portuguese is one of the most spoken languages in the world, but it's not because of the roughly 10 million inhabitants of Portugal, it's more due to the 200 million inhabitants of Brazil. So, we'd probably include Brazillian Portuguese. But English would be harder. There are more Americans than British, but a lot of people are anti-American English or so. The whole move of including 8 languages. I'm not sure, I'd like to know how much space that is. David Munchor Gomes On Sun, Sep 23, 2012 at 7:21 PM, Eduard Gotwig eduardgot...@gmail.com wrote: 2012/9/23 Eduard Gotwig got...@ubuntu.com Hey, I think about if we can add the 8 most popular languagee packs for GNOME to the ISO image? There is still space left. These 8 languages should be the ones, that are available on our new website: - [image: English]English - [image: Français]Français - [image: Deutsch]Deutsch - [image: Italiano]Italiano - [image: Español]Español - [image: Português]Português - [image: Polski]Polski - [image: Nederlands]Nederlands We cant include all, becouse they take too much space I guess. -- Mailing list: https://launchpad.net/~elementary-translators Post to : elementary-translat...@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-translators More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Best Regards, Chris Triantafillis -- Best Regards, Chris Triantafillis -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary
Re: [Elementary-dev-community] Window Maximize Concept
In my mind, it seems to mark more sense to have a maximized window consume the whole screen, and use smaller windows only when you want to view other information. Since a non-maximized window already allows you to view other information, it doesn't seem to make a lot of sense to duplicate this behavior with maximize, particularly as it would come at the cost of losing traditional maximization. On Sep 23, 2012 2:33 PM, tahseen.ja...@gmail.com wrote: ** At least this can be made as an option. I really felt that it avoids unnecessary window maximising to cover complete desktop. And you can give the option through switchboard setting And guys, really good work. Once your stable release is out am done with Ubuntu. I would switch to Luna Tahseen Tahseen Sent on my BlackBerry® from Vodafone -- *From: * David Gomes da...@elementaryos.org *Date: *Sun, 23 Sep 2012 20:30:25 +0100 *To: *Tahseen Jamaltahseen.ja...@gmail.com *Cc: *elementary-dev-community@lists.launchpad.net *Subject: *Re: [Elementary-dev-community] Window Maximize Concept I completely disagree. First of all, this is one of the most hated design decisions of OS X. Secondly, we want users to have a welcoming experience from other distros and operating systems (namely Windows 95+) Now, another argument which has been presented by shnatsel is that not all windows have fixed width/height, some of them are dynamic and the width they need when you maximize a window might not be the same some time later. It could be an option, but I hope never the default behavior. Regards, David Munchor Gomes On Sun, Sep 23, 2012 at 8:12 PM, Tahseen Jamal tahseen.ja...@gmail.comwrote: Hi Team elementaryOS, I have a request. Differentiate your maximize from other distros. I think when I click on Maximize, I don't expect the window to cover the whole desktop. What I expect it to do is just have enough expansion to remove horizontal scroll bar and the height would also proportionately increase. Thus not unnecessarily covering the whole desktop You would observe the same thing in Mac OSX also. There is no point maximizing the window completely. Just should be enough to have no horizontal scroll bar -- Mailing list: https://launchpad.net/~**elementary-dev-communityhttps://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@**lists.launchpad.netelementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~**elementary-dev-communityhttps://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/**ListHelphttps://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] Running App Indicators
Isn't that kind of like pulling all street signs/traffic lights in excited anticipation for the day when cars have traffic data projected onto the windshield via HUD? On Wed, Sep 19, 2012 at 1:00 PM, Sam Tate s...@mtate.me.uk wrote: In the long run (L+1 or even L+2), I want there to be no difference between an open and closed app. Computers are fast enough now (esp. with Luna) that you don't really notice the extra delay when you open an app rather than restoring from Minimize. I also want apps to save their state for when you re-open them, and for the system (not the user) to handle memory management. However, these are things that need not be addressed now, and I will go into in more detail (probably with a blog post) closer to the time. For now, I much prefer the removal of indicators as it moves us towards this vision. SamTate On 19 September 2012 00:39, ttosttos Sa ttost...@gmail.com wrote: +1 on running app indicators unless a simple, _mouse only_ expose for app windows is available (e.g. long hover over dock icon exposing running screens). There are useful apps that don't support tabs and, even for those that do, you may still want to run multiple windows with different parameters (e.g. a browser with private and non-private settings). Switching focus to a particular instance of an app is a bit involved today. --ttosttos On Tue, Sep 18, 2012 at 9:02 AM, Daniel Foré dan...@elementaryos.orgwrote: Hey Guys, I've seen a few mails/reports about the current lack of running app indicators in Luna. I wanted to get a feel for how people who have been using Luna for a while feel about it. Namely, is this something people are complaining about because they expect it and aren't used to it yet, or is this a real problem? Personally, I don't miss them at all. I haven't used them for almost a year now (When Gala was just a dream haha). Luna is so good on resources that it hardly matters if an app is open or not and you can easily see if something is open from Gala's Workspace Overview since minimize isn't part of our regular workflow. But it also has the added benefit of saving a few pixels on the bottom of the dock (since our OOTB default is hide-on-maximize and not intelli or autohide I think keep the dock small is still important). If we do decide that running app indicators are important, would it be terribly difficult to make this a switch in the desktop plug? We may need to ask Rico to add a key for this since I think we wouldn't want to have this update for every user on the system (since the theming is currently stored globally). Because I do think that there are probably a significant amount of people for which the running indicators just aren't terribly useful in Luna and it could still remain as the default. But hey, that's why I am asking! Best Regards, Daniel Foré elementaryos.org -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] Running App Indicators
Ill have to think on that more, but on first thought I think it's a good idea to indicate them on the launcher as the presence of a running app changes the behavior of that particular launcher. (Launching a new window versus focusing on an existing one). Spatial concerns can be addressed by using a different indication method (background glow, for instance). Thoughts? On Sep 18, 2012 11:03 AM, Daniel Foré dan...@elementaryos.org wrote: Hey Guys, I've seen a few mails/reports about the current lack of running app indicators in Luna. I wanted to get a feel for how people who have been using Luna for a while feel about it. Namely, is this something people are complaining about because they expect it and aren't used to it yet, or is this a real problem? Personally, I don't miss them at all. I haven't used them for almost a year now (When Gala was just a dream haha). Luna is so good on resources that it hardly matters if an app is open or not and you can easily see if something is open from Gala's Workspace Overview since minimize isn't part of our regular workflow. But it also has the added benefit of saving a few pixels on the bottom of the dock (since our OOTB default is hide-on-maximize and not intelli or autohide I think keep the dock small is still important). If we do decide that running app indicators are important, would it be terribly difficult to make this a switch in the desktop plug? We may need to ask Rico to add a key for this since I think we wouldn't want to have this update for every user on the system (since the theming is currently stored globally). Because I do think that there are probably a significant amount of people for which the running indicators just aren't terribly useful in Luna and it could still remain as the default. But hey, that's why I am asking! Best Regards, Daniel Foré elementaryos.org -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] OEM Installation mode
How do we test clean installs? I've noticed virtualbox can't seem to read eOS isos. On Sep 17, 2012 4:43 PM, Sergey Shnatsel Davidoff ser...@elementaryos.org wrote: Hey Alex, All patches are properly propagated now. Please test OEM installation and report results. 2012/8/27 Sergey Shnatsel Davidoff ser...@elementaryos.org The updates have finally* landed to PPAs, so I've put together an updated ISO image. It does not include our patcheshttps://code.launchpad.net/%7Eelementary-os/elementaryos/os-patch-ubiquityof Ubiquity because imports of Ubuntu packages to Launchpadhttps://code.launchpad.net/%7Eubuntu-branches/ubuntu/precise/ubiquity/precise-updatesare lagging (as usually) and Ubiquity patch is not yet rebased onto our custom import infrastructurehttps://code.launchpad.net/%7Eelementary-os/ubuntu-package-imports/ubiquity-precise. But we didn't change anything critical, so I guess OEM installation should still work. As far as the prepare for shipping launcher goes, it should be present in the dock now. *usually it doesn't take that long. Canonical happened to be moving datacenters and that caused some quirks and delays. 2012/8/18 Alejandro Morales Lepe aml24...@gmail.com: Hi Sergey! I will test as soon as you notify me of the .iso! - Alex -- Sergey Shnatsel Davidoff OS architect @ elementary -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] OEM Installation mode
I'll admit the only one I tried was 9/14. Shame on me for assuming it was a persistent virtual box problem. :) On Sep 18, 2012 6:42 PM, ttosttos Sa ttost...@gmail.com wrote: I rarely run into issues loading elementary ISOs on VBox. Last one, I tried was 9/5 w/o any issues. ttosttos -- On Tue, Sep 18, 2012 at 2:15 PM, Craig webe...@gmail.com wrote: How do we test clean installs? I've noticed virtualbox can't seem to read eOS isos. On Sep 17, 2012 4:43 PM, Sergey Shnatsel Davidoff ser...@elementaryos.org wrote: Hey Alex, All patches are properly propagated now. Please test OEM installation and report results. 2012/8/27 Sergey Shnatsel Davidoff ser...@elementaryos.org The updates have finally* landed to PPAs, so I've put together an updated ISO image. It does not include our patcheshttps://code.launchpad.net/%7Eelementary-os/elementaryos/os-patch-ubiquityof Ubiquity because imports of Ubuntu packages to Launchpadhttps://code.launchpad.net/%7Eubuntu-branches/ubuntu/precise/ubiquity/precise-updatesare lagging (as usually) and Ubiquity patch is not yet rebased onto our custom import infrastructurehttps://code.launchpad.net/%7Eelementary-os/ubuntu-package-imports/ubiquity-precise. But we didn't change anything critical, so I guess OEM installation should still work. As far as the prepare for shipping launcher goes, it should be present in the dock now. *usually it doesn't take that long. Canonical happened to be moving datacenters and that caused some quirks and delays. 2012/8/18 Alejandro Morales Lepe aml24...@gmail.com: Hi Sergey! I will test as soon as you notify me of the .iso! - Alex -- Sergey Shnatsel Davidoff OS architect @ elementary -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] Protect builds
I run elementaryforums.org - which to be honest, is where some people are probably figuring out how to do the nightlies iso build. How does this sound to everyone: I could edit in warnings around all the build instructions, something along the lines of: The elementary team are still hard at work refining the next release of elementary os. This is an open source project, so anyone who has an interest can build the system in its current form. Please refrain from distributing your own built iso images to others, and please show restraint if considering writing reviews in its current form. The goal is for everyone to meet elementary *when it's ready*. This is alpha software, not ready for public consumption. Any thoughts? On 3 May 2012 18:45, Daniel Foré dan...@elementaryos.org wrote: The wallpaper thing is already being done. I think the trouble is that it's not exactly easy to make the builds available easily to developers, and yet keep them away from journalists and end users. Maybe we'll figure out a better system later, but for now I think it's okay to just let it be. Best Regards, Daniel Foré El may 3, 2012, a las 8:02 a.m., Andre Luis dos Santos dominiosan...@gmail.com escribió: Em 03-05-2012 03:14, Mensur Zahirovic escreveu: Hi guys, I was wondering is there any way builds could be protected so they are not being spread. I have seen people are posting directlinks in answers like here: http://elementaryos.org/support/answers/2734 So my question is can we build them somehow hidden and if so what do we need? Cheerz =) /Nookie I think we could use a Microsoft approach: at the default wallpaper, we could something like This is an Alpha Release, things should be unstable, so people will understand that they can't complain about unstability issues! -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] Protect builds
Hi Sergey, Thanks for taking the time to reply to this. Just to be clear, before I launched the forums (which are of course *unofficial*, community driven) I spoke to Cassidy James about the idea. I was pointed to previous discussion trails on the G+ page, and was pointed to the previous concerns from devs that a set of forums managed by the elementary team wasn't something they wanted - and an unoffical set of forums could be a way forward. I've also purchased (and so far, done nothing with) elementaryusers.org - which is where I was going to host (as you've suggested yourself) a community wiki. I take onboard all the quotes you've outlined before, but I'd like to point out, that the welcome message you're quoting was written before I had really soaked myself into the elementary community. I found the Jupiter iso online, installed it on my PC, realised it was the cleanest linux distro I had ever used and fell in love. When I realised that there weren't any community forums, I decided to fill a gap. Cassidy has been on the forums, and has made a point of trying to direct users to the correct official support methods, the answers section on elementaryos.org for example. Where you've quoted the section about got an idea to make elementary better? post it here - again, this is aimed at *users* of elementary, to discuss ideas amongst themselves. I understand the concerns of wanting all the info in one place (elementaryos.org), but I also see a need for a free flowing area for people to just talk about the project. Not a developer on launchpad, not joining mailing lists or hanging around on IRC. My main target is to have a community of eos users across a selection of community resources, centered around elementaryusers.org - specifically non-official, free flowing, open. The ubuntuforums.org is a glowing example of the type of thing I'm trying to achieve. UF.org ended up part of the official project, which isn't my aim. Especially as this is an open source project, expecting that control can be kept on what users do and discuss amongst each other is like trying to shovel water with a spade. I'm very much of the opinion that having something unofficial (like my site) managed by someone who keeps an active interest in the actual elementary project is a great thing. And somewhere where *fans* can *discuss* (not just ask a direct question) is also only a good thing. Just to reiterate, the forums were intended to be fully separate from the elementary project, and I discussed the idea with community leader before going ahead. I'll make a point of going through a re-design, make it incredibly clear that it's a non-connected website, and have permanant links back into the elementaryos.org sections in question. Thanks Craig On 4 May 2012 13:24, Sergey Shnatsel Davidoff ser...@elementaryos.org wrote: 2012/5/4 Craig Errington craigerring...@gmail.com I run elementaryforums.org - which to be honest, is where some people are probably figuring out how to do the nightlies iso build. Well, that's a wrong place to figure that out. The right place for technical questions is https://answers.launchpad.net/elementaryos - and it already holds an answer. Also, I'm a little surprised that this is the first time I hear about the forums. Of course nobody can keep track of everything elementary going on (except Cody Garver, but he's actually not human, but about a thousand gnomes working undercover. None of the individual gnomes keep track of everything either, they just work together really well), but at least I try to :) Quoting http://elementaryforums.org/discussion/2/elementaryforums-launched : Hello, and welcome to elementaryForums.org, a new set of forums for members of the elementary community; users, developers and interested outsiders are all welcome. It would be a good idea to at least post an announcement to this list if you want developers to get involved. Though developers already have two places to communicate - IRC and this list, and I don't think we need a third one. Moreover, forums work really poorly for developer communication (trust me, I've tried it - using a forum for communication killed a project of mine before I discovered mailing lists). Just thought of an something that would make elementary better? I've described the process of proposing ideas to the project at http://elementaryos.org/journal/how-see-what%E2%80%99s-our-sleeves and it didn't change much since then, I recommend sticking to it. I recall Dan saying that forums is the last place he'd visit looking for ideas, so I'm afraid this is not going to work. Found a guide elsewhere online? Well get going, start a new discussion. The best thing to do is to show it to developers, here or in IRC, instead of spreading it. Following some random guide found on the internet is not a brilliant idea. Often the author doesn't realize the consequences of what they advise to do; many hotfix howtos fix one
