Re: [Elementary-dev-community] Farewell, Sort Of

[Harvey Cabaguio]

I meant to say I wish good health to your family.



On Mon, Apr 1, 2013 at 8:59 PM, Daniel Foré  wrote:

> You're hilarious Cassidy :p
>
> Best Regards,
> Daniel Foré
>
> El abr 1, 2013, a las 5:16 p.m., Cassidy James 
> escribió:
>
> Hey Awesome Devs,
>
> As many of you may or may not know, I joined the elementary team a little
> over two years ago. I had been following the project from its humble
> origins as an icon set and watched it grow into much more: a philosophy, a
> way of thinking, and a truly powerful software movement.
>
> In the time since, I've been on board as a community manager, a sort of
> public relations guy, a Council member, and a user experience designer.
> I've floated to where I was needed, helping as much as I could.
>
> It's time to continue that flux, albeit with another software project.
> I've been approached by Canonical to work as a user experience designer for
> Ubuntu. I'll be working alongside the awesome designers at Canonical on
> Ubuntu and their mobile efforts. I'm excited to bring the promise of truly
> free software to a much wider audience, and I couldn't ask for a better
> team to be working with.
>
> I will attempt to still be present in the elementary community and
> contribute when my new career allows, though I expect it to be at a much
> smaller capacity compared to now. I wish you all the best of luck with Luna
> and future releases.
>
> Regards,
> Cassidy James
>
> --
> 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] Farewell, Sort Of

[Daniel Foré]

You're hilarious Cassidy :p

Best Regards,
Daniel Foré

El abr 1, 2013, a las 5:16 p.m., Cassidy James  
escribió:

> Hey Awesome Devs,
> 
> As many of you may or may not know, I joined the elementary team a little 
> over two years ago. I had been following the project from its humble origins 
> as an icon set and watched it grow into much more: a philosophy, a way of 
> thinking, and a truly powerful software movement.
> 
> In the time since, I've been on board as a community manager, a sort of 
> public relations guy, a Council member, and a user experience designer. I've 
> floated to where I was needed, helping as much as I could.
> 
> It's time to continue that flux, albeit with another software project. I've 
> been approached by Canonical to work as a user experience designer for 
> Ubuntu. I'll be working alongside the awesome designers at Canonical on 
> Ubuntu and their mobile efforts. I'm excited to bring the promise of truly 
> free software to a much wider audience, and I couldn't ask for a better team 
> to be working with.
> 
> I will attempt to still be present in the elementary community and contribute 
> when my new career allows, though I expect it to be at a much smaller 
> capacity compared to now. I wish you all the best of luck with Luna and 
> future releases.
> 
> Regards,
> Cassidy James
> 
> -- 
> 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] Farewell, Sort Of

[Harvey Cabaguio]

Screw you and I hope your family has good health!


On Mon, Apr 1, 2013 at 7:22 PM, Dane Henson  wrote:

> Feels like a punch in the gut. I'm excited for you and proud to have
> canonical poaching our awesome community members. I wish you the best of
> luck and hope you continue to haunt these parts. Your prominent presence on
> the council will be sorely missed.
> On Apr 1, 2013 7:16 PM, "Cassidy James"  wrote:
>
>> Hey Awesome Devs,
>>
>> As many of you may or may not know, I joined the elementary team a little
>> over two years ago. I had been following the project from its humble
>> origins as an icon set and watched it grow into much more: a philosophy, a
>> way of thinking, and a truly powerful software movement.
>>
>> In the time since, I've been on board as a community manager, a sort of
>> public relations guy, a Council member, and a user experience designer.
>> I've floated to where I was needed, helping as much as I could.
>>
>> It's time to continue that flux, albeit with another software project.
>> I've been approached by Canonical to work as a user experience designer for
>> Ubuntu. I'll be working alongside the awesome designers at Canonical on
>> Ubuntu and their mobile efforts. I'm excited to bring the promise of truly
>> free software to a much wider audience, and I couldn't ask for a better
>> team to be working with.
>>
>> I will attempt to still be present in the elementary community and
>> contribute when my new career allows, though I expect it to be at a much
>> smaller capacity compared to now. I wish you all the best of luck with Luna
>> and future releases.
>>
>> Regards,
>> Cassidy James
>>
>> --
>> 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] Farewell, Sort Of

[Dane Henson]

Feels like a punch in the gut. I'm excited for you and proud to have
canonical poaching our awesome community members. I wish you the best of
luck and hope you continue to haunt these parts. Your prominent presence on
the council will be sorely missed.
On Apr 1, 2013 7:16 PM, "Cassidy James"  wrote:

> Hey Awesome Devs,
>
> As many of you may or may not know, I joined the elementary team a little
> over two years ago. I had been following the project from its humble
> origins as an icon set and watched it grow into much more: a philosophy, a
> way of thinking, and a truly powerful software movement.
>
> In the time since, I've been on board as a community manager, a sort of
> public relations guy, a Council member, and a user experience designer.
> I've floated to where I was needed, helping as much as I could.
>
> It's time to continue that flux, albeit with another software project.
> I've been approached by Canonical to work as a user experience designer for
> Ubuntu. I'll be working alongside the awesome designers at Canonical on
> Ubuntu and their mobile efforts. I'm excited to bring the promise of truly
> free software to a much wider audience, and I couldn't ask for a better
> team to be working with.
>
> I will attempt to still be present in the elementary community and
> contribute when my new career allows, though I expect it to be at a much
> smaller capacity compared to now. I wish you all the best of luck with Luna
> and future releases.
>
> Regards,
> Cassidy James
>
> --
> 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] Farewell, Sort Of

[Goncalo Margalho]

If you were saying that the 2nd of april I could believe you. In USA is
still the 1st.


On Tue, Apr 2, 2013 at 1:16 AM, Cassidy James wrote:

> Hey Awesome Devs,
>
> As many of you may or may not know, I joined the elementary team a little
> over two years ago. I had been following the project from its humble
> origins as an icon set and watched it grow into much more: a philosophy, a
> way of thinking, and a truly powerful software movement.
>
> In the time since, I've been on board as a community manager, a sort of
> public relations guy, a Council member, and a user experience designer.
> I've floated to where I was needed, helping as much as I could.
>
> It's time to continue that flux, albeit with another software project.
> I've been approached by Canonical to work as a user experience designer for
> Ubuntu. I'll be working alongside the awesome designers at Canonical on
> Ubuntu and their mobile efforts. I'm excited to bring the promise of truly
> free software to a much wider audience, and I couldn't ask for a better
> team to be working with.
>
> I will attempt to still be present in the elementary community and
> contribute when my new career allows, though I expect it to be at a much
> smaller capacity compared to now. I wish you all the best of luck with Luna
> and future releases.
>
> Regards,
> Cassidy James
>
> --
> 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] Farewell, Sort Of

[Cassidy James]

Hey Awesome Devs,

As many of you may or may not know, I joined the elementary team a little
over two years ago. I had been following the project from its humble
origins as an icon set and watched it grow into much more: a philosophy, a
way of thinking, and a truly powerful software movement.

In the time since, I've been on board as a community manager, a sort of
public relations guy, a Council member, and a user experience designer.
I've floated to where I was needed, helping as much as I could.

It's time to continue that flux, albeit with another software project. I've
been approached by Canonical to work as a user experience designer for
Ubuntu. I'll be working alongside the awesome designers at Canonical on
Ubuntu and their mobile efforts. I'm excited to bring the promise of truly
free software to a much wider audience, and I couldn't ask for a better
team to be working with.

I will attempt to still be present in the elementary community and
contribute when my new career allows, though I expect it to be at a much
smaller capacity compared to now. I wish you all the best of luck with Luna
and future releases.

Regards,
Cassidy James
-- 
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] How to review and merge branches

[Craig]

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"  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  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"  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  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"  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  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"  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  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" 
>>> wrote:
>>>
 I agree with Victor. Consistency matters because it makes
 readability and therefore maintainability better.

 --
 Jaap
 Op 1 apr. 2013 09:09 schreef "Victor" 
 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 h

Re: [Elementary-dev-community] How to review and merge branches

[David Gomes]

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  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"  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  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"  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  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"  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  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"  wrote:
>>
>>> I agree with Victor. Consistency matters because it makes
>>> readability and therefore maintainability better.
>>>
>>> --
>>> Jaap
>>> Op 1 apr. 2013 09:09 schreef "Victor"  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  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,

Re: [Elementary-dev-community] How to review and merge branches

[Craig]

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"  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  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"  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  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"  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  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"  wrote:
>
>> I agree with Victor. Consistency matters because it makes readability
>> and therefore maintainability better.
>>
>> --
>> Jaap
>> Op 1 apr. 2013 09:09 schreef "Victor"  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  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 

> I wrote this in order t

Re: [Elementary-dev-community] How to review and merge branches

[Craig]

Dane, it will only breed lazy practices in the arena of style, which is a
non issue because said beautifier will correct all such issues. Style isn't
something any one needs to be disciplined in for the same reasons we no
longer have to be disciplined about writing in assembly: we have automated
tools to do the translation for us! :-)
On Apr 1, 2013 1:36 PM, "Dane Henson"  wrote:

> I understand the hesitance to push lovingly crafted code through a
> cookie-cutter code beautifier, but we are hardly talking about chopping
> everything apart and putting it together backwards.  The only document I
> know of (
> https://docs.google.com/document/d/1AcuFhcuEkoEM5_JEhGrdeshRQP5oBudh7IPQJeeuxHQ)
> talks about simple rules like whitespace, naming conventions, and the
> pre-amble "using" statements.
>
> This stuff can get controversial, but having clean, consistent code
> between projects can make it much easier for newer developers like me take
> a bite out of the code without curling up into a ball and crying in the
> corner at the EOF.
>
> My opinion is that we should strive to add a code formatting phase at the
> end of our workflow _before_ requesting a merge to make it easier for the
> reviewer.  If it becomes too cumbersome, I don't have any major qualms with
> an automated formatting script _as a last resort_.  An automated system
> could breed lazy programming practices, or even introduce bugs if not
> implemented properly.  However, unification is better than fragmentation.
>  It's why we chose a common programming language to begin with, right?
>
> A disciplined programmer is an invaluable programmer, especially when it
> comes to mundane details like this.
>
> (please don't look at my personal projects as an example of good code...
> nobody is perfect :P)
>
>
> On Mon, Apr 1, 2013 at 1:10 PM, Victor  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  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"  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  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"  wrote:

> I agree with Victor. Consistency matters because it makes readability
> and therefore maintainability better.
>
> --
> Jaap
> Op 1 apr. 2013 09:09 schreef "Victor"  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  wrote:
>>
>> How do you figure? The go language community uses one and they rave
>> about it

Re: [Elementary-dev-community] How to review and merge branches

[David Gomes]

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  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"  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  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"  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  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"  wrote:

> I agree with Victor. Consistency matters because it makes readability
> and therefore maintainability better.
>
> --
> Jaap
> Op 1 apr. 2013 09:09 schreef "Victor"  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  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 
>>>
 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  wrote:

> Good work David. Have you (elemen

Re: [Elementary-dev-community] How to review and merge branches

[Craig]

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"  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  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"  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  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"  wrote:
>>>
 I agree with Victor. Consistency matters because it makes readability
 and therefore maintainability better.

 --
 Jaap
 Op 1 apr. 2013 09:09 schreef "Victor"  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  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 
>>
>>> 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  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" 
 wrote:

> Cool, it's pretty thorough.
>
>
> On Wed, M

Re: [Elementary-dev-community] How to review and merge branches

[David Gomes]

http://dl.dropbox.com/u/19899464/elementaryos_coding_style.html

It's this one, not sure if somebody put it up on a Google Docs.


On Mon, Apr 1, 2013 at 7:36 PM, Dane Henson  wrote:

> I understand the hesitance to push lovingly crafted code through a
> cookie-cutter code beautifier, but we are hardly talking about chopping
> everything apart and putting it together backwards.  The only document I
> know of (
> https://docs.google.com/document/d/1AcuFhcuEkoEM5_JEhGrdeshRQP5oBudh7IPQJeeuxHQ)
> talks about simple rules like whitespace, naming conventions, and the
> pre-amble "using" statements.
>
> This stuff can get controversial, but having clean, consistent code
> between projects can make it much easier for newer developers like me take
> a bite out of the code without curling up into a ball and crying in the
> corner at the EOF.
>
> My opinion is that we should strive to add a code formatting phase at the
> end of our workflow _before_ requesting a merge to make it easier for the
> reviewer.  If it becomes too cumbersome, I don't have any major qualms with
> an automated formatting script _as a last resort_.  An automated system
> could breed lazy programming practices, or even introduce bugs if not
> implemented properly.  However, unification is better than fragmentation.
>  It's why we chose a common programming language to begin with, right?
>
> A disciplined programmer is an invaluable programmer, especially when it
> comes to mundane details like this.
>
> (please don't look at my personal projects as an example of good code...
> nobody is perfect :P)
>
>
> On Mon, Apr 1, 2013 at 1:10 PM, Victor  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  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"  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  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"  wrote:

> I agree with Victor. Consistency matters because it makes readability
> and therefore maintainability better.
>
> --
> Jaap
> Op 1 apr. 2013 09:09 schreef "Victor"  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  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

Re: [Elementary-dev-community] Granite's IconFactory

[Mario Guerriero]

Files is using it.
—
Sent from Mailbox for iPhone

On Mon, Apr 1, 2013 at 8:25 PM, Chris Timberlake  wrote:

> Is there a way to add compile time warnings to it?
> In the event developers are using it and are unknowing? I'm not
> knowledgeable about adding compile time warnings in Vala but it might be
> worth it.
> On Apr 1, 2013 11:23 AM, "Sergey "Shnatsel" Davidoff" <
> ser...@elementaryos.org> wrote:
>> I suggest deprecating it instead of removing it right away.
>>
>>
>> 2013/4/1 David Gomes 
>>
>>> I can only remove it when Noise stops using it.
>>>
>>>
>>> On Mon, Apr 1, 2013 at 7:21 PM, Victor  wrote:
>>>
 I'm sure Mario has used it in many of his projects.

 In my humble opinion, that class it not a big deal. It's only a
 wrapper/facade around one method from GTK+.

 Would you mind removing the StatusBar class too? It is hacky, ugly and
 incomplete and only Noise is using it.

 On Mon, Apr 1, 2013 at 12:06 PM, David Gomes 
 wrote:

 Hello there,

 There's a class/object/file in Granite called "IconFactory.vala", you
 can check it out here -
 http://bazaar.launchpad.net/~elementary-pantheon/granite/granite/view/head:/lib/Services/IconFactory.vala
 .

 Is anybody using it and definitely dependent on it?

 We're considering removing it and I need to know if it's necessary.

 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
>>>
>>>
>>
>>
>> --
>> 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] How to review and merge branches

[Dane Henson]

I understand the hesitance to push lovingly crafted code through a
cookie-cutter code beautifier, but we are hardly talking about chopping
everything apart and putting it together backwards.  The only document I
know of (
https://docs.google.com/document/d/1AcuFhcuEkoEM5_JEhGrdeshRQP5oBudh7IPQJeeuxHQ)
talks about simple rules like whitespace, naming conventions, and the
pre-amble "using" statements.

This stuff can get controversial, but having clean, consistent code between
projects can make it much easier for newer developers like me take a bite
out of the code without curling up into a ball and crying in the corner at
the EOF.

My opinion is that we should strive to add a code formatting phase at the
end of our workflow _before_ requesting a merge to make it easier for the
reviewer.  If it becomes too cumbersome, I don't have any major qualms with
an automated formatting script _as a last resort_.  An automated system
could breed lazy programming practices, or even introduce bugs if not
implemented properly.  However, unification is better than fragmentation.
 It's why we chose a common programming language to begin with, right?

A disciplined programmer is an invaluable programmer, especially when it
comes to mundane details like this.

(please don't look at my personal projects as an example of good code...
nobody is perfect :P)


On Mon, Apr 1, 2013 at 1:10 PM, Victor  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  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"  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  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"  wrote:
>>>
 I agree with Victor. Consistency matters because it makes readability
 and therefore maintainability better.

 --
 Jaap
 Op 1 apr. 2013 09:09 schreef "Victor"  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  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 

Re: [Elementary-dev-community] Granite's IconFactory

[Victor]

Yes Chris, it is possible.

Vala allows adding annotations to symbols. You only need to add the 
following annotation at the top of the symbol you want to deprecate. 


[Deprecated (replacement = "ReplacementClass", since = "0.3")]
class MyDeprecatedClass { ... }

On Mon, Apr 1, 2013 at 12:25 PM, Chris Timberlake  
wrote:

Is there a way to add compile time warnings to it?

In the event developers are using it and are unknowing? I'm not 
knowledgeable about adding compile time warnings in Vala but it might 
be worth it.


On Apr 1, 2013 11:23 AM, "Sergey "Shnatsel" Davidoff" 
 wrote:

I suggest deprecating it instead of removing it right away.


2013/4/1 David Gomes 

I can only remove it when Noise stops using it.


On Mon, Apr 1, 2013 at 7:21 PM, Victor  
wrote:

I'm sure Mario has used it in many of his projects.

In my humble opinion, that class it not a big deal. It's only a 
wrapper/facade around one method from GTK+.


Would you mind removing the StatusBar class too? It is hacky, ugly 
and incomplete and only Noise is using it.


On Mon, Apr 1, 2013 at 12:06 PM, David Gomes 
 wrote:

Hello there,

There's a class/object/file in Granite called "IconFactory.vala", 
you can check it out here - 
http://bazaar.launchpad.net/~elementary-pantheon/granite/granite/view/head:/lib/Services/IconFactory.vala.


Is anybody using it and definitely dependent on it?

We're considering removing it and I need to know if it's 
necessary.


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






--
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] cmake, vala and internationalization

[Victor]

Merged, thank you Sergio!

On Sat, Mar 23, 2013 at 3:09 PM, Sergio Costas  
wrote:

Hi Victor!

Yes, it works fine. You can merge it.

Thanks!

El 23/03/13 20:29, Victor Eduardo escribió:

 Hi Sergio,

 Thank you for the patch!

 I've applied it to a separate branch for testing purposes, and it 
has

 worked well so far. You can find that branch here:
 
lp:~elementary-apps/+junk/cmake-modules-translations-patch


 I have been testing the module during this week. I've also added a 
revision
 that simplifies things a bit, and it works perfectly here. Could 
you please
 test it and tell me if it works for you as well? I just want to 
make sure I

 have not introduced any regressions.

 Anyway, I should be merging your changes soon. Thank you again for 
your

 work.

 Regards,
 Victor.


 On Sun, Mar 17, 2013 at 6:58 AM, Sergio Costas 
 wrote:



 Ok, that explains why I was incapable of finding that option :)

 Anyway, I already sent the diff file to Victor.

 El 17/03/13 13:47, Raphael Isemann escribió:

 You can't make a merge proposal to +junk branches AFAIK.

 - Teemperor

 2013/3/17 Victor Eduardo :

 Hi Sergio,

 Thank you for your time and work.

 You can find the most recent version of our CMake modules at
 lp:~elementary-apps/+junk/cmake-modules.

 It would be great if you could create a merge proposal for your
 modifications to Translations.cmake into the branch mentioned 
above.



 We'd
 review it as soon as possible. If you have no time for that, 
just let us

 know and we'll take care of manually merging the changes.

 Best Regards,
 Victor.



 On Sat, Mar 16, 2013 at 1:40 PM, Sergio Costas 




 wrote:

 Hi all:

 I'm working on a project to easily generate the CMake scripts 
for any

 Vala project, and found that the CMake Vala scripts for
 internationalization has two little bugs:

   * uses the C language for processing the vala source code, 
when the



 C#

 would be better
   * it doesn't check the glade's .ui files

 I modified the Translations.cmake file to support both things 
(and



 still
 can search .c files too), but I'm not sure where should I 
upload the
 diff. The github repo from Jakob Westhoff seems to be outdated 
compared

 to the file available at http://ubuntuone.com/p/1F3R/

 Thanks.

 --
 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



 --
 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] Granite's IconFactory

[Victor]

My bad, I was actually referring to "deprecating" it. Moving the file 
back into Noise is the logically implied action. I'm sorry for 
deviating the discussion.


Regarding the original topic, I'm assuming that the primary reason for 
the removal (and not deprecation) of IconFactory would be licensing 
issues?


On Mon, Apr 1, 2013 at 12:22 PM, David Gomes  
wrote:

I can only remove it when Noise stops using it.


On Mon, Apr 1, 2013 at 7:21 PM, Victor  
wrote:

I'm sure Mario has used it in many of his projects.

In my humble opinion, that class it not a big deal. It's only a 
wrapper/facade around one method from GTK+.


Would you mind removing the StatusBar class too? It is hacky, ugly 
and incomplete and only Noise is using it.


On Mon, Apr 1, 2013 at 12:06 PM, David Gomes 
 wrote:

Hello there,

There's a class/object/file in Granite called "IconFactory.vala", 
you can check it out here - 
http://bazaar.launchpad.net/~elementary-pantheon/granite/granite/view/head:/lib/Services/IconFactory.vala.


Is anybody using it and definitely dependent on it?

We're considering removing it and I need to know if it's necessary.

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

Re: [Elementary-dev-community] Granite's IconFactory

[Chris Timberlake]

Is there a way to add compile time warnings to it?

In the event developers are using it and are unknowing? I'm not
knowledgeable about adding compile time warnings in Vala but it might be
worth it.
On Apr 1, 2013 11:23 AM, "Sergey "Shnatsel" Davidoff" <
ser...@elementaryos.org> wrote:

> I suggest deprecating it instead of removing it right away.
>
>
> 2013/4/1 David Gomes 
>
>> I can only remove it when Noise stops using it.
>>
>>
>> On Mon, Apr 1, 2013 at 7:21 PM, Victor  wrote:
>>
>>> I'm sure Mario has used it in many of his projects.
>>>
>>> In my humble opinion, that class it not a big deal. It's only a
>>> wrapper/facade around one method from GTK+.
>>>
>>> Would you mind removing the StatusBar class too? It is hacky, ugly and
>>> incomplete and only Noise is using it.
>>>
>>> On Mon, Apr 1, 2013 at 12:06 PM, David Gomes 
>>> wrote:
>>>
>>> Hello there,
>>>
>>> There's a class/object/file in Granite called "IconFactory.vala", you
>>> can check it out here -
>>> http://bazaar.launchpad.net/~elementary-pantheon/granite/granite/view/head:/lib/Services/IconFactory.vala
>>> .
>>>
>>> Is anybody using it and definitely dependent on it?
>>>
>>> We're considering removing it and I need to know if it's necessary.
>>>
>>> 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
>>
>>
>
>
> --
> 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] Granite's IconFactory

[Sergey "Shnatsel" Davidoff]

I suggest deprecating it instead of removing it right away.


2013/4/1 David Gomes 

> I can only remove it when Noise stops using it.
>
>
> On Mon, Apr 1, 2013 at 7:21 PM, Victor  wrote:
>
>> I'm sure Mario has used it in many of his projects.
>>
>> In my humble opinion, that class it not a big deal. It's only a
>> wrapper/facade around one method from GTK+.
>>
>> Would you mind removing the StatusBar class too? It is hacky, ugly and
>> incomplete and only Noise is using it.
>>
>> On Mon, Apr 1, 2013 at 12:06 PM, David Gomes 
>> wrote:
>>
>> Hello there,
>>
>> There's a class/object/file in Granite called "IconFactory.vala", you can
>> check it out here -
>> http://bazaar.launchpad.net/~elementary-pantheon/granite/granite/view/head:/lib/Services/IconFactory.vala
>> .
>>
>> Is anybody using it and definitely dependent on it?
>>
>> We're considering removing it and I need to know if it's necessary.
>>
>> 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
>
>


-- 
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] Granite's IconFactory

[David Gomes]

I can only remove it when Noise stops using it.


On Mon, Apr 1, 2013 at 7:21 PM, Victor  wrote:

> I'm sure Mario has used it in many of his projects.
>
> In my humble opinion, that class it not a big deal. It's only a
> wrapper/facade around one method from GTK+.
>
> Would you mind removing the StatusBar class too? It is hacky, ugly and
> incomplete and only Noise is using it.
>
> On Mon, Apr 1, 2013 at 12:06 PM, David Gomes 
> wrote:
>
> Hello there,
>
> There's a class/object/file in Granite called "IconFactory.vala", you can
> check it out here -
> http://bazaar.launchpad.net/~elementary-pantheon/granite/granite/view/head:/lib/Services/IconFactory.vala
> .
>
> Is anybody using it and definitely dependent on it?
>
> We're considering removing it and I need to know if it's necessary.
>
> 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

Re: [Elementary-dev-community] Granite's IconFactory

[Victor]

I'm sure Mario has used it in many of his projects.

In my humble opinion, that class it not a big deal. It's only a 
wrapper/facade around one method from GTK+.


Would you mind removing the StatusBar class too? It is hacky, ugly and 
incomplete and only Noise is using it.


On Mon, Apr 1, 2013 at 12:06 PM, David Gomes  
wrote:

Hello there,

There's a class/object/file in Granite called "IconFactory.vala", you 
can check it out here - 
http://bazaar.launchpad.net/~elementary-pantheon/granite/granite/view/head:/lib/Services/IconFactory.vala.


Is anybody using it and definitely dependent on it?

We're considering removing it and I need to know if it's necessary.

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

Re: [Elementary-dev-community] How to review and merge branches

[Victor]

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  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"  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  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"  
wrote:
I agree with Victor. Consistency matters because it makes 
readability and therefore maintainability better.


--
Jaap

Op 1 apr. 2013 09:09 schreef "Victor"  
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  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" 
 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 
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  
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" 
 wrote:

Cool, it's pretty thorough.


On Wed, Mar 27, 2013 at 7:58 AM, David Gomes 
 wrote:

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     : eleme

[Elementary-dev-community] Granite's IconFactory

[David Gomes]

Hello there,

There's a class/object/file in Granite called "IconFactory.vala", you can
check it out here -
http://bazaar.launchpad.net/~elementary-pantheon/granite/granite/view/head:/lib/Services/IconFactory.vala
.

Is anybody using it and definitely dependent on it?

We're considering removing it and I need to know if it's necessary.

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

[Elementary-dev-community] On Contractor and Luna

[Sergey "Shnatsel" Davidoff]

I have some progress to report! Michael, Akshay, Fabian and me have
developed a new API for
Contractorand
Michael went ahead and implemented
stub 
methodsin
code, so you can now stare at the new API in D-feet too. Invoking
listing functions crashes Contractor though XD

Also, lp:contractor is not being built to Daily PPA because the
consequences of handling the API break improperly are not entirely
predictable. I'm not even kidding.

-- 
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] How to review and merge branches

[Craig]

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"  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  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"  wrote:
>>
>>> I agree with Victor. Consistency matters because it makes readability
>>> and therefore maintainability better.
>>>
>>> --
>>> Jaap
>>> Op 1 apr. 2013 09:09 schreef "Victor"  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  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 
>
>> 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  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" 
>>> wrote:
>>>
 Cool, it's pretty thorough.


 On Wed, Mar 27, 2013 at 7:58 AM, David Gomes <
 da...@elementaryos.org> wrote:

> 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

 --
>

Re: [Elementary-dev-community] How to review and merge branches

[David Gomes]

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  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"  wrote:
>
>> I agree with Victor. Consistency matters because it makes readability and
>> therefore maintainability better.
>>
>> --
>> Jaap
>> Op 1 apr. 2013 09:09 schreef "Victor"  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  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 

> 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  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" 
>> wrote:
>>
>>> Cool, it's pretty thorough.
>>>
>>>
>>> On Wed, Mar 27, 2013 at 7:58 AM, David Gomes >> > wrote:
>>>
 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
>>>
>>>
> --
> Mailing list: https://launchpad.net/~elementary-dev-community
> Post t

Re: [Elementary-dev-community] How to review and merge branches

[Craig]

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"  wrote:

> I agree with Victor. Consistency matters because it makes readability and
> therefore maintainability better.
>
> --
> Jaap
> Op 1 apr. 2013 09:09 schreef "Victor"  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  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 
>>>
 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  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"  wrote:
>
>> Cool, it's pretty thorough.
>>
>>
>> On Wed, Mar 27, 2013 at 7:58 AM, David Gomes 
>> wrote:
>>
>>> 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
>>
>>
-- 
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] How to review and merge branches

[Jaap Broekhuizen]

I agree with Victor. Consistency matters because it makes readability and
therefore maintainability better.

--
Jaap
Op 1 apr. 2013 09:09 schreef "Victor"  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  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 
>>
>>> 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  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"  wrote:

> Cool, it's pretty thorough.
>
>
> On Wed, Mar 27, 2013 at 7:58 AM, David Gomes 
> wrote:
>
>> 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
>
>
-- 
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] How to review and merge branches

[Victor]

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  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" 
 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 
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  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"  
wrote:

Cool, it's pretty thorough.


On Wed, Mar 27, 2013 at 7:58 AM, David Gomes 
 wrote:

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] Stable Audience-like video player surfaces

[Victor]

That is not necessarily true. From our experience we know that 
sometimes agreeing on goals and project vision consumes more time than 
actual development; merging projects seems trivial but it's certainly 
not an easy task.


Besides, there are no hurries with Audience development at this moment. 
Snappi is a very nice project, but Audience is not lacking any of its 
features, as Tom has already pointed out.


On Sun, Mar 31, 2013 at 10:59 AM, steven ferreira 
 wrote:
I agree with Shnatsel. elementary could team up with this guy even if 
Audience has all or nearly all functions of Snappy.
Maybe there could be a collaboration this would accelerate 
the development of Audience.

Don't say things like i'm not impressed by the current sate etc. 
elementary should take all little help for a better development.

Date: Fri, 29 Mar 2013 20:21:25 +0400
From: ser...@elementaryos.org
To: elementary-dev-community@lists.launchpad.net
Subject: [Elementary-dev-community] Stable Audience-like video 
player	surfaces


http://www.omgubuntu.co.uk/2013/03/minimal-gnome-video-player-snappy-hits-0-3-improves-feature-set

I wonder if we could team up with that guy.
--
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