Re: [Elementary-dev-community] Renaming Noise
gt; > >What is "many"? Seems like a trivial thing to me... > > > > > >-- > > >Jaap > > > > > >"Sergey "Shnatsel" Davidoff" schreef: > > > > > >>2012/11/19 Jaap Broekhuizen : > > >>> Is there an actual logical reason to rename Noise? > > >> > > >>"Noise" is perceived as something negative by many (the kind of > > people > > >>who are not crazy about metal or industrial), that's it AFAIK. > > >> > > >>-- > > >>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 > > > > > > > > > > > > > > >-- > > >Best Regards, > > >Chris Triantafillis > > > > > > > > > > > > > > > > > > > > >-- > > >Mailing list: https://launchpad.net/~elementary-dev-community > > >Post to : elementary-dev-community@lists.launchpad.net > > >Unsubscribe : https://launchpad.net/~elementary-dev-community > > >More help : https://help.launchpad.net/ListHelp > > -- Darcy Brás da Silva signature.asc Description: This is a digitally signed message part -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] Luna beta 1 can be here...
How bad is it, if too bad I can try get some time and have a look at it. Not that I'm an expert in file managers, but have some C karate on my backpack. On Tue, 2012-10-02 at 18:02 +0530, Voldyman wrote: > I have started reading Files source code but i am not very > comfortable with C code so cant guarantee much. But i'll try. :-) > > On Oct 2, 2012, at 5:14 PM, Mario Guerriero > wrote: > > > > > Studies are killing me so I can't promise anything about Files but > > it is nice to see interest of other devs like David :) > > > > > > Well, are they so critical to break a release? > > > > Regards, > > Mario > > > > Sent from iPhone 5 > > > > Il giorno 02/ott/2012, alle ore 12:09, "Sergey \"Shnatsel\" > > Davidoff" ha scritto: > > > > > > > 2012/10/2 Cody Garver > > > Regarding switching to stable PPAs I would defer to Sergey > > > about that, he just moved the bug about switching PPAs to > > > luna-beta2. It may come back to haunt us if we advise > > > users that beta will eventually turn into luna final, > > > since there could be some unforeseeable issues that create > > > a bad experience that does not happen in luna final. > > > > > > IMO we should create separate "testing" branches for all apps > > > shipping in Luna and recipes that build them into testing PPA and > > > merge changes from trunk to testing once in a while, when we're > > > sure they are not going to kill kittens. Similarly, along with > > > final release we should create "stable" branches that build to > > > stable PPA and stage all changes in "testing" branches/PPAs before > > > merging there. > > > > > > The bug is an ongoing item till release candidate so I believe it > > > will be re-targeted on and on. > > > > > > -- > > > 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 > > -- Darcy Brás da Silva signature.asc Description: This is a digitally signed message part -- 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] INK and model based design
Here it goes something that might help those that are still unfamiliar with it : http://www.youtube.com/watch?v=FkRwbVUVFvE On Wed, 2012-09-26 at 09:58 -0700, Daniel Foré wrote: > I agree it'd be nice to get an overview of what exactly UML is. Don't > forget many of us are not software professionals but merely > hobbyists ;) > > On Wed, Sep 26, 2012 at 7:44 AM, Craig wrote: > First of all, I want to apologize as autocorrect insists on > changing UML into INK. > > Secondly, I was purposefully vague so as to glean some > understanding as to what elementary developers know about > these design disciplines. Furthermore, I haven't had time to > find and link-to a good article explaining these disciplines, > and, while I'm working on a blog post of my own explaining the > issues, I think it would be beneficial to start some > conversation on the subject in the meanwhile. > > So I apologize for the inconvenience, but I promise it is out > of necessity. > > On Sep 26, 2012 9:22 AM, "Cassidy James" > wrote: > Hey Craig, > > Thanks for bringing this up on the mailing list. I > know Cody has been looking into model-based design and > UML a bit lately, but I don't know much about it. It > might help me and the developers who aren't as > familiar with it if you could give a quick description > and/or some links for note info. > > Thanks! > Cassidy James > > On Sep 26, 2012 6:35 AM, "weberc2" > wrote: > UML and model based design principles are the > "next big thing" in the world of software. Why > aren't these being employed at elementary? > Discuss. > > > > > Sent from my U.S. Cellular® Smartphone > > -- > Mailing list: > https://launchpad.net/~elementary-dev-community > Post to : > elementary-dev-community@lists.launchpad.net > Unsubscribe : > https://launchpad.net/~elementary-dev-community > More help : > https://help.launchpad.net/ListHelp > > > -- > Mailing list: https://launchpad.net/~elementary-dev-community > Post to : elementary-dev-community@lists.launchpad.net > Unsubscribe : https://launchpad.net/~elementary-dev-community > More help : https://help.launchpad.net/ListHelp > > > > > > -- > Best Regards, > > Daniel Foré > > > elementaryos.org > -- Darcy Brás da Silva signature.asc Description: This is a digitally signed message part -- 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] Geary Naming
Ok. this is a tricky subject. From my perspective, I see a great advantage on de.branded apps it becomes easier to know what the program does. On the other end, That's why icons exist, to represent what the application is/does. Having that said, I think is far more beneficial to have all apps with their custom name, and maybe with an hover of a more generic name. This would not only avoid the clashing apps problem, but also make it easier in the future when other developers decide to bring their apps to elementary. Note that Elementary is an OS project, which means it is a "platform" for deployment of applications. So -1 on de-branding apps, overall results would only lead into inconsistency and give foreign look to post_default installations. On Wed, 2012-09-19 at 14:00 -0500, Cassidy James wrote: > I just want to re-base this discussion on Geary, as that's what Dan is > specifically asking about. > > I'm +1 on branding it as "Mail" on our desktop. We're sort of in the > process of moving in that direction. That would mean its full name > would be "Mail" and its generic name could be "Email Client" or > something (I'm not suggesting specifics, just that we should make them > different). I am pretty sure we're not moving to make Slingshot > display only generic names, and that's not what this discussion is > about. > > Regards, > Cassidy James > > On Sep 19, 2012 1:36 PM, "Sergey "Shnatsel" Davidoff" > wrote: > I'm all for using debranded apps too, but switching to showing > GenericName instead X-GNOME-Fullname alone is not sufficient. > > Okay, let's say we have debranded apps. Now Totem is "Movie > Player" and Audience is too. What happens if elementary OS > user installs Totem or Ubuntu user installs Audience? They get > two "Movie Player"s with the same icons which are in fact > different apps. > > So *if* we go for it, we'll also have to make Slinghot detect > and handle such collisions: either show X-GNOME-Fullname for > each "colliding" app (resulting in "Totem Movie Player" and > "Audience Movie Player" respectively), or show GenericName for > apps that are set as default ones and X-GNOME-Fullname for > other colliding apps (resulting in "Movie Player" for default > player and full branded name for the other one). > > And please, read "X-GNOME-Fullname" thread in the archives > before commenting on this further, it has a good list of pros > and cons of this approach. > > -- > 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 > -- Darcy Brás da Silva signature.asc Description: This is a digitally signed message part -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
Re: [Elementary-dev-community] OEM Installation mode
I use qemu, and for graphical frontend aqemu ... as long you have support for KVM module you are good to go. Works 10/10 times for me On Wed, 2012-09-19 at 04:59 +0400, Sergey "Shnatsel" Davidoff wrote: > I'm glad it works in VirtualBox sometimes, but you'd better avoid > using it for Linux guests, especially for testing purposes. Its guest > additions are known to cause weird issues and crashes all over the > system (see http://www.phoronix.com/scan.php?page=news_item&px=OTk5Mw) > and without guest additions you won't get 3D acceleration that's > currently required by Gala. > > -- > Sergey "Shnatsel" Davidoff > OS architect @ elementary -- Darcy Brás da Silva signature.asc Description: This is a digitally signed message part -- 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] [Bug 1050321] Re: Closing Terminal does not warn about open background tasks
Another note on this, I'm not talking about `status' , but rather about _Importance_ . So the answer "You are right, that is whishlist" doesn't make any sense to me :/ On Mon, 2012-09-17 at 20:16 +0100, David Gomes wrote: > We use Launchpad ones:http://i.imgur.com/I15LH.png > > On Mon, Sep 17, 2012 at 8:14 PM, Darcy Brás da Silva > wrote: > Problem is i still don't know what metric is used to determine > it's > importance. > Or is just, oh i feel I'm in a bad mood and this looks bad, > critical ? > I think it's important to have rules when evaluating bug > reports, only > that way we can accurately pay attention to the importance > when fixing > bugs. > > On Mon, 2012-09-17 at 19:55 +0100, David Gomes wrote: > > You are right, that is wishlist :) > > > > On Thu, Sep 13, 2012 at 1:18 PM, Darcy Brás da Silva > > wrote: > > Is this really low priority ? > > What are the metrics on raking bug_report priority? > I was just > > searching > > for a blueprint after reading getting the notice it > was set as > > low, and > > found this > > > > https://blueprints.launchpad.net/pantheon-terminal/+spec/background-execution > > > > which apparently ranks it differently. > > > > On Thu, 2012-09-13 at 10:27 +, David Gomes > wrote: > > > ** Changed in: pantheon-terminal > > > Milestone: None => 0.2 > > > > > > ** Changed in: pantheon-terminal > > > Status: New => Confirmed > > > > > > ** Changed in: pantheon-terminal > > >Importance: Undecided => Low > > > > > > > -- > > Darcy Brás da Silva > > > > -- > > 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 > > > > > > -- > Darcy Brás da Silva > > -- Darcy Brás da Silva signature.asc Description: This is a digitally signed message part -- 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] [Bug 1050321] Re: Closing Terminal does not warn about open background tasks
Problem is i still don't know what metric is used to determine it's importance. Or is just, oh i feel I'm in a bad mood and this looks bad, critical ? I think it's important to have rules when evaluating bug reports, only that way we can accurately pay attention to the importance when fixing bugs. On Mon, 2012-09-17 at 19:55 +0100, David Gomes wrote: > You are right, that is wishlist :) > > On Thu, Sep 13, 2012 at 1:18 PM, Darcy Brás da Silva > wrote: > Is this really low priority ? > What are the metrics on raking bug_report priority? I was just > searching > for a blueprint after reading getting the notice it was set as > low, and > found this > > https://blueprints.launchpad.net/pantheon-terminal/+spec/background-execution > > which apparently ranks it differently. > > On Thu, 2012-09-13 at 10:27 +, David Gomes wrote: > > ** Changed in: pantheon-terminal > > Milestone: None => 0.2 > > > > ** Changed in: pantheon-terminal > >Status: New => Confirmed > > > > ** Changed in: pantheon-terminal > >Importance: Undecided => Low > > > > -- > Darcy Brás da Silva > > -- > 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 > > -- Darcy Brás da Silva signature.asc Description: This is a digitally signed message part -- 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] Maybe a Design Bug - fix dificulty Easy
I'm ok with that, please do note that it was a user posting this bug, he/she dropped by #elementary to ask why and if it was or not a bug. I said fill a bug so it can be evaluated by the team since I was not the indicated individual to reply. On Mon, 2012-09-17 at 16:05 +0200, Eshat Cakar wrote: > 2012/9/17 Brendan : > > I personally think a black cursor would look ugly on that. It looks fine the > > way it is. > > +1 > > I don't think this is worth a bug. Also I think that hardly anyone > notes this or is even confused. > In opposite, IMOH a black cursor would not fit well in the color > scheme of that icon, hence I'd also leave as is. > > > > > On Sep 16, 2012 5:41 PM, "Darcy Brás da Silva" > > wrote: > >> > >> The bug report is : > >> > >> Why is the mouse cursor in Files' icon white? Elementary's cursor is > >> black, so the Files' icon should display a black cursor. > >> https://bugs.launchpad.net/pantheon-files/+bug/1042804 > >> > >> What's your take on this designers ? > >> > >> -- > >> Darcy Brás da Silva > >> > >> -- > >> 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 > > > -- Darcy Brás da Silva signature.asc Description: This is a digitally signed message part -- 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] Maybe a Design Bug - fix dificulty Easy
The bug report is : Why is the mouse cursor in Files' icon white? Elementary's cursor is black, so the Files' icon should display a black cursor. https://bugs.launchpad.net/pantheon-files/+bug/1042804 What's your take on this designers ? -- Darcy Brás da Silva signature.asc Description: This is a digitally signed message part -- 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] Bikeshedding about parentheses (Was: Re: Coding Style parentheses exception)
Unfortunately that's nothing new, it is a problem well known (years of debate)
but and nobody got the grips yet create such automation.
Hence why i said. I personally can't be worried about single space rules. it's
just
insane.
>This discussion is veering off into Bikeshedding.
>
>I will now rescue it:
>
>- A commit hook which formats source code on commit, is the ONLY way to
>have a followed formatting policy.
>
>Any other approach will result in nothing but bikeshedding, or worse, flame
>wars.
>
>best regards,
>Jakob
On September 13, 2012 at 11:42 PM Daniel Fore wrote:
> Not that I do a lot of coding, but I'm +1 on the "((" exception. It looks
> much more readable imho.
>
> On Thu, Sep 13, 2012 at 10:45 AM, Sergey Shnatsel Davidoff
> wrote:
> IMHO we should keep the style comprehensible and easy to remember. Maybe
> that way we'll manage to actually follow it.
>
> If you're willing to put a lot of time into developing the coding style, I
> can suggest reading the relevant Code Craft chapter first (I can lend a copy
> of the book if you don't have it handy).
>
> I can't +1 or -1 because I don't code in Vala, but in BASH and Python I use
> both "( (" and "((", depending on readability of the content. I wouldn't be
> able to keep all those little rules in mind, I guess.
>
> --
> 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
signature.asc
Description: This is a digitally signed message part
--
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] Coding Style parentheses exception
I have only seen your _David_ and _Dane_ replies not everyone... so ...
Also as I already told you "David" in IRC, but now I'm saying to
everyone:
If this project cares more of single space then the actual code quality
I'm telling upfront don't count with me. There are other projects were i
can work ...
Style is already a very personal thing to mess with. And I don't mind
following a standard of a given project. But at this level is just wast
of time and idiotic
not to mention that even the current projects established in Elementary
can't follow the current CGL wish kind shows that they are ineffective
towards developers actually concern/need.
Even in kernel development where changes have a larger impact are way
more loose then in here... Doesn't that tell you something ???
When I'm programming I care more on solving the actual problem then
rather bogging my mind with single space style related _issues_
On Thu, 2012-09-13 at 17:55 +0100, David Gomes wrote:
> All those cases have been handled. It took less time for us to decide
> that this exception is a +1 than it took you to write that post, I
> don't think this is a waste of time.
>
> On Thu, Sep 13, 2012 at 5:40 PM, Darcy Brás da Silva
> wrote:
> I agree that we should have consistency but at this level just
> seems
> unproductive and a wast of time...
>
> I think the things that really make a difference in this
> situations are
> in cases like:
>
> if(condition){
> }
>
> vs
>
> if(condition)
> {
>
> }
>
> or in functions:
>
> return_type
> func_name(param, param) {
> }
>
> vs
>
> return_type func_name(param, param {
> }
>
> vs
>
> return_type func_name(param, param)
> {
>
> }
>
> or cases like
>
> if(cond) {
> }else if {
>
> }
>
> vs
>
> if(cond){
> } else {
> if(cond){
> }
> }
>
>
> now getting to the _single_ space level just seems rather
> picky.
> Also it's not like all current projects managed to correctly
> apply
> the CGL ...
>
> There are things far more important that have not seen being
> address.
> Such as warnings and unreachable code. But apparently they
> don't seem to
> be a problem since they are IN the submitted code. :/
>
>
>
> On Thu, 2012-09-13 at 11:07 -0500, Dane Henson wrote:
> > I agree that the space should only be on the first opening
> > parentheses, but not before the second. It looks cleaner to
> me.
> >
> > On Sep 13, 2012 8:32 AM, "David Gomes"
> wrote:
> > Hey there guys, attached is the elementary OS coding
> style (We
> > have this on a Google Doc, but the formatting is
> broken on it,
> > so I'm rewriting it with Writer to then port to
> Google Docs
> > again).
> >
> > I want to add an exception regarding the space
> character
> > before opening parentheses, and I want to know if
> you all
> > agree:
> >
> > Usually, we put a space character before opening
> > parentheses:
> >
> > public string get_text () {}
> >
> > if (a == 5) return 4;
> >
> > for (i = 0; i < maximum; i++) {}
> >
> > my_function_name ();
> >
> > Object my_instance = new Object ();
> >
> > However, if we have something like this:
> >
> > if ((e.state &
> Gdk.ModifierType.MOD1_MASK) != 0) {
> >
> > Before the second opening parentheses on that line,
> I didn't
> > put a space character because I think it looks quite
> bad. Do
> > you guys agree that when we have 2 parentheses in a
> row we
>
Re: [Elementary-dev-community] Coding Style parentheses exception
I agree that we should have consistency but at this level just seems
unproductive and a wast of time...
I think the things that really make a difference in this situations are
in cases like:
if(condition){
}
vs
if(condition)
{
}
or in functions:
return_type
func_name(param, param) {
}
vs
return_type func_name(param, param {
}
vs
return_type func_name(param, param)
{
}
or cases like
if(cond) {
}else if {
}
vs
if(cond){
} else {
if(cond){
}
}
now getting to the _single_ space level just seems rather picky.
Also it's not like all current projects managed to correctly apply
the CGL ...
There are things far more important that have not seen being address.
Such as warnings and unreachable code. But apparently they don't seem to
be a problem since they are IN the submitted code. :/
On Thu, 2012-09-13 at 11:07 -0500, Dane Henson wrote:
> I agree that the space should only be on the first opening
> parentheses, but not before the second. It looks cleaner to me.
>
> On Sep 13, 2012 8:32 AM, "David Gomes" wrote:
> Hey there guys, attached is the elementary OS coding style (We
> have this on a Google Doc, but the formatting is broken on it,
> so I'm rewriting it with Writer to then port to Google Docs
> again).
>
> I want to add an exception regarding the space character
> before opening parentheses, and I want to know if you all
> agree:
>
> Usually, we put a space character before opening
> parentheses:
>
> public string get_text () {}
>
> if (a == 5) return 4;
>
> for (i = 0; i < maximum; i++) {}
>
> my_function_name ();
>
> Object my_instance = new Object ();
>
> However, if we have something like this:
>
> if ((e.state & Gdk.ModifierType.MOD1_MASK) != 0) {
>
> Before the second opening parentheses on that line, I didn't
> put a space character because I think it looks quite bad. Do
> you guys agree that when we have 2 parentheses in a row we
> should not put a space character before the second one?
>
>
> if ( (e.state & Gdk.ModifierType.MOD1_MASK) != 0) {
>
> That's how it would look like.
>
>
> Thank youg uys.
>
> --
> 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
>
--
Darcy Brás da Silva
signature.asc
Description: This is a digitally signed message part
--
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] -lm and building the terminal
Humm, if the fix was passing m, i guess cmake passes l prefix for us...
Nice!
On Thu, 2012-09-13 at 11:23 +0100, David Gomes wrote:
> Well Darcy, that email was @voldyman ;)
>
> Regarding the general issue, I found a way to fix it, thanks to
> devidfil's Github link, I just added:
>
> link_libraries (m)
>
> Right before the add_subdirectory call and it's working for everybody
> now.
>
> On Thu, Sep 13, 2012 at 11:16 AM, Darcy Brás da Silva
> wrote:
> I'm not saying to implement it ourselves. I'm saying to make a
> vapi to
> have access of it from C library in Vala, which is a
> very
> different thing :)
> On Thu, 2012-09-13 at 09:50 +0100, David Gomes wrote:
> > Implementing Math.floor and Math.ceil ourselves would work,
> but I'm
> > trying to avoid that for obvious reasons :)
> >
> > On Thu, Sep 13, 2012 at 4:22 AM, Voldyman
>
> > wrote:
> > If we implement Math.floor function in pantheon
> terminal
> > source wouldn't that work?
> >
> >
> > On 13-Sep-2012, at 3:29 AM, David Gomes
> > wrote:
> >
> >
> >
> > > On the terminal we now need Math.floor and
> Math.ceil for
> > > zooming in and out using Ctrl-+ and Ctrl--.
> > >
> > > This brought along an issue when building the
> termina:
> > >
> > > /usr/bin/ld:
> > >
> CMakeFiles/pantheon-terminal.dir/src/TerminalWidget.c.o:
> > > undefined reference to symbol 'floor@@GLIBC_2.2.5'
> > > /usr/bin/ld: note: 'floor@@GLIBC_2.2.5' is defined
> in
> > > DSO /usr/lib/libm.so.6 so try adding it to the
> linker
> > > command line
> > > /usr/lib/libm.so.6: could not read symbols:
> Invalid
> > > operation
> > > collect2: error: ld returned 1 exit status
> > > make[2]: *** [pantheon-terminal] Error 1
> > >
> > > In order to fix this, Ricotz suggested using the
> "-lm" flag
> > > on the linker. I tried to do it and then it worked
> just
> > > fine. However, for Victored and Eshat on Ubuntu
> (Luna), that
> > > made it stop working.
> > >
> > > It seems that on Ubuntu the linker includes lm by
> default,
> > > and on Arch it doesn't, and reincluding it causes
> troubles
> > > on Ubuntu.
> > >
> > > On CMakeLists.txt I just added the following to
> make it
> > > compile:
> > >
> > > set (CMAKE_EXE_LINKER_FLAGS "-lm")
> > >
> > > Either way, I want Pantheon Terminal to compile
> across all
> > > GNU/Linux distributions, so I need a way to solve
> this.
> > >
> > > === modified file 'CMakeLists.txt'
> > > --- CMakeLists.txt 2012-07-26 20:23:31 +
> > > +++ CMakeLists.txt 2012-09-12 19:18:34 +
> > > @@ -30,6 +30,7 @@
> > > find_package(PkgConfig)
> > > pkg_check_modules(DEPS REQUIRED gthread-2.0 gtk
> +-3.0
> > > granite vte-2.90 libnotify gdk-3.0)
> > >
> > > +set (DEPS_LADD "${DEPS_LADD} -lm")
> > > add_definitions(${DEPS_CFLAGS})
> > >
> > > link_libraries(${DEPS_LIBRARIES})
> > >
> > > Ricotz suggesting the avobe path to fix the issue.
> I applied
> > > that patch and my patched CMakeLists.txt is
> attached.
> > > However, with this patch I can't build it on Arch,
> but
> > > Victored managed to built it on Ubuntu. I get the
> same good
> > >
Re: [Elementary-dev-community] [Bug 1050321] Re: Closing Terminal does not warn about open background tasks
Is this really low priority ? What are the metrics on raking bug_report priority? I was just searching for a blueprint after reading getting the notice it was set as low, and found this https://blueprints.launchpad.net/pantheon-terminal/+spec/background-execution which apparently ranks it differently. On Thu, 2012-09-13 at 10:27 +, David Gomes wrote: > ** Changed in: pantheon-terminal > Milestone: None => 0.2 > > ** Changed in: pantheon-terminal >Status: New => Confirmed > > ** Changed in: pantheon-terminal >Importance: Undecided => Low > -- Darcy Brás da Silva signature.asc Description: This is a digitally signed message part -- 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] -lm and building the terminal
I'm not saying to implement it ourselves. I'm saying to make a vapi to
have access of it from C library in Vala, which is a very
different thing :)
On Thu, 2012-09-13 at 09:50 +0100, David Gomes wrote:
> Implementing Math.floor and Math.ceil ourselves would work, but I'm
> trying to avoid that for obvious reasons :)
>
> On Thu, Sep 13, 2012 at 4:22 AM, Voldyman
> wrote:
> If we implement Math.floor function in pantheon terminal
> source wouldn't that work?
>
>
> On 13-Sep-2012, at 3:29 AM, David Gomes
> wrote:
>
>
>
> > On the terminal we now need Math.floor and Math.ceil for
> > zooming in and out using Ctrl-+ and Ctrl--.
> >
> > This brought along an issue when building the termina:
> >
> > /usr/bin/ld:
> > CMakeFiles/pantheon-terminal.dir/src/TerminalWidget.c.o:
> > undefined reference to symbol 'floor@@GLIBC_2.2.5'
> > /usr/bin/ld: note: 'floor@@GLIBC_2.2.5' is defined in
> > DSO /usr/lib/libm.so.6 so try adding it to the linker
> > command line
> > /usr/lib/libm.so.6: could not read symbols: Invalid
> > operation
> > collect2: error: ld returned 1 exit status
> > make[2]: *** [pantheon-terminal] Error 1
> >
> > In order to fix this, Ricotz suggested using the "-lm" flag
> > on the linker. I tried to do it and then it worked just
> > fine. However, for Victored and Eshat on Ubuntu (Luna), that
> > made it stop working.
> >
> > It seems that on Ubuntu the linker includes lm by default,
> > and on Arch it doesn't, and reincluding it causes troubles
> > on Ubuntu.
> >
> > On CMakeLists.txt I just added the following to make it
> > compile:
> >
> > set (CMAKE_EXE_LINKER_FLAGS "-lm")
> >
> > Either way, I want Pantheon Terminal to compile across all
> > GNU/Linux distributions, so I need a way to solve this.
> >
> > === modified file 'CMakeLists.txt'
> > --- CMakeLists.txt 2012-07-26 20:23:31 +
> > +++ CMakeLists.txt 2012-09-12 19:18:34 +
> > @@ -30,6 +30,7 @@
> > find_package(PkgConfig)
> > pkg_check_modules(DEPS REQUIRED gthread-2.0 gtk+-3.0
> > granite vte-2.90 libnotify gdk-3.0)
> >
> > +set (DEPS_LADD "${DEPS_LADD} -lm")
> > add_definitions(${DEPS_CFLAGS})
> >
> > link_libraries(${DEPS_LIBRARIES})
> >
> > Ricotz suggesting the avobe path to fix the issue. I applied
> > that patch and my patched CMakeLists.txt is attached.
> > However, with this patch I can't build it on Arch, but
> > Victored managed to built it on Ubuntu. I get the same good
> > old error:
> >
> > /usr/bin/ld:
> > CMakeFiles/pantheon-terminal.dir/src/TerminalWidget.c.o:
> > undefined reference to symbol 'floor@@GLIBC_2.2.5'
> > /usr/bin/ld: note: 'floor@@GLIBC_2.2.5' is defined in
> > DSO /usr/lib/libm.so.6 so try adding it to the linker
> > command line
> > /usr/lib/libm.so.6: could not read symbols: Invalid
> > operation
> > collect2: error: ld returned 1 exit status
> >
> > So I'd appreciate some help guys, since I'm fairly new to
> > CMake. Oh, and this is the branch we're working on:
> >
> >
> https://code.launchpad.net/~elementary-dev-community/pantheon-terminal/zoom-in-out
> >
> > Thank you.
> >
> >
> > --
> > 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
> >
>
--
Darcy Brás da Silva
signature.asc
Description: This is a digitally signed message part
--
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] -lm and building the terminal
Hi, I'm not quite sure, but from what I know in the C level is
just a matter of adding a linker flag -lm
Having that said, if doesn't work through vala make a vapi call to the C
math lib...
Cheers
On Thu, 2012-09-13 at 08:52 +0530, Voldyman wrote:
> If we implement Math.floor function in pantheon terminal source
> wouldn't that work?
>
> On 13-Sep-2012, at 3:29 AM, David Gomes
> wrote:
>
>
>
> > On the terminal we now need Math.floor and Math.ceil for zooming in
> > and out using Ctrl-+ and Ctrl--.
> >
> > This brought along an issue when building the termina:
> >
> > /usr/bin/ld:
> > CMakeFiles/pantheon-terminal.dir/src/TerminalWidget.c.o: undefined
> > reference to symbol 'floor@@GLIBC_2.2.5'
> > /usr/bin/ld: note: 'floor@@GLIBC_2.2.5' is defined in
> > DSO /usr/lib/libm.so.6 so try adding it to the linker command line
> > /usr/lib/libm.so.6: could not read symbols: Invalid operation
> > collect2: error: ld returned 1 exit status
> > make[2]: *** [pantheon-terminal] Error 1
> >
> > In order to fix this, Ricotz suggested using the "-lm" flag on the
> > linker. I tried to do it and then it worked just fine. However, for
> > Victored and Eshat on Ubuntu (Luna), that made it stop working.
> >
> > It seems that on Ubuntu the linker includes lm by default, and on
> > Arch it doesn't, and reincluding it causes troubles on Ubuntu.
> >
> > On CMakeLists.txt I just added the following to make it compile:
> >
> > set (CMAKE_EXE_LINKER_FLAGS "-lm")
> >
> > Either way, I want Pantheon Terminal to compile across all GNU/Linux
> > distributions, so I need a way to solve this.
> >
> > === modified file 'CMakeLists.txt'
> > --- CMakeLists.txt 2012-07-26 20:23:31 +
> > +++ CMakeLists.txt 2012-09-12 19:18:34 +
> > @@ -30,6 +30,7 @@
> > find_package(PkgConfig)
> > pkg_check_modules(DEPS REQUIRED gthread-2.0 gtk+-3.0 granite
> > vte-2.90 libnotify gdk-3.0)
> >
> > +set (DEPS_LADD "${DEPS_LADD} -lm")
> > add_definitions(${DEPS_CFLAGS})
> >
> > link_libraries(${DEPS_LIBRARIES})
> >
> > Ricotz suggesting the avobe path to fix the issue. I applied that
> > patch and my patched CMakeLists.txt is attached. However, with this
> > patch I can't build it on Arch, but Victored managed to built it on
> > Ubuntu. I get the same good old error:
> >
> > /usr/bin/ld:
> > CMakeFiles/pantheon-terminal.dir/src/TerminalWidget.c.o: undefined
> > reference to symbol 'floor@@GLIBC_2.2.5'
> > /usr/bin/ld: note: 'floor@@GLIBC_2.2.5' is defined in
> > DSO /usr/lib/libm.so.6 so try adding it to the linker command line
> > /usr/lib/libm.so.6: could not read symbols: Invalid operation
> > collect2: error: ld returned 1 exit status
> >
> > So I'd appreciate some help guys, since I'm fairly new to CMake. Oh,
> > and this is the branch we're working on:
> >
> > https://code.launchpad.net/~elementary-dev-community/pantheon-terminal/zoom-in-out
> >
> > Thank you.
> >
> >
> > --
> > 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
> >
--
Darcy Brás da Silva
signature.asc
Description: This is a digitally signed message part
--
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] Design input on bug 1045511
Sorry but I completely disagree. This also would mean that later down the road if we decide to change visual schemes on the project the tools were already there. Also the whole point of Elementary is Bring a new User Experience (the way I see it at least)... Else why would we create pantheon-terminal... Sticking to a tested tool like gnome-terminal would have been a wiser choice if the point is to _have_ what people are _used__to__ On Tue, 2012-09-11 at 13:00 +0100, David Gomes wrote: > That sounds way too complex when compared to just using Gnome's scheme > (to the which people are used). > > On Tue, Sep 11, 2012 at 12:37 PM, Darcy Brás da Silva > wrote: > Yes, definitely it does look pretty bad... So, ideas for the > fix... What > about some kind of filter on issued commands, that way each > app could > *temporarily* change it's color scheme and we could keep our > current > theme, and just _fix and maybe even improve those that fail > miserably ... > I know some work would be required, but in overall i don't > think would > be extremely difficult. It would be a matter of keeping a list > of known > names (exceptions like aptitude) and check the argument that > is going to > be executed... How does that sound to you guys ? > > On Tue, 2012-09-11 at 12:19 +0100, David Gomes wrote: > > https://launchpadlibrarian.net/115431046/screenshot.png > > > > The bug report just posted that picture, it looks pretty > bad. > > > > On Tue, Sep 11, 2012 at 9:04 AM, dkotrada > wrote: > > +1 > > > > 2012/9/10 Darcy Brás da Silva > : > > > I think we should first look at some kind of print > screen, > > because the > > > current color scheme is most likely the best > 'default' I > > have found. And > > > note that I program with emacs -nw mode, so > readability is > > definitely a > > > concern to me. > > > PS: some packages can be installed that alter the > color > > scheme of > > > certain programs, not quite sure if there isn't > something > > like that on > > > the system were the bug was detected. > > > > > > On Mon, 2012-09-10 at 15:07 +0100, David Gomes > wrote: > > >> I need some design input on this bug: > > >> > https://bugs.launchpad.net/pantheon-terminal/+bug/1045511 > > >> > > >> If our color scheme is not working alright, we > need to use > > Gnome > > >> Terminal's color scheme, and if we do need to > change the > > color scheme, > > >> I think it should be done in time for Luna, hence > I'm > > asking for your > > >> help guys. > > >> > > >> Thanks, > > >> David (Munchor) > > > > > > -- > > > Darcy Brás da Silva > > > > > > > > -- > > > 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 > > > > > > > > > -- > Darcy Brás da Silva > > -- Darcy Brás da Silva signature.asc Description: This is a digitally signed message part -- 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] Design input on bug 1045511
Yes, definitely it does look pretty bad... So, ideas for the fix... What about some kind of filter on issued commands, that way each app could *temporarily* change it's color scheme and we could keep our current theme, and just _fix and maybe even improve those that fail miserably ... I know some work would be required, but in overall i don't think would be extremely difficult. It would be a matter of keeping a list of known names (exceptions like aptitude) and check the argument that is going to be executed... How does that sound to you guys ? On Tue, 2012-09-11 at 12:19 +0100, David Gomes wrote: > https://launchpadlibrarian.net/115431046/screenshot.png > > The bug report just posted that picture, it looks pretty bad. > > On Tue, Sep 11, 2012 at 9:04 AM, dkotrada wrote: > +1 > > 2012/9/10 Darcy Brás da Silva : > > I think we should first look at some kind of print screen, > because the > > current color scheme is most likely the best 'default' I > have found. And > > note that I program with emacs -nw mode, so readability is > definitely a > > concern to me. > > PS: some packages can be installed that alter the color > scheme of > > certain programs, not quite sure if there isn't something > like that on > > the system were the bug was detected. > > > > On Mon, 2012-09-10 at 15:07 +0100, David Gomes wrote: > >> I need some design input on this bug: > >> https://bugs.launchpad.net/pantheon-terminal/+bug/1045511 > >> > >> If our color scheme is not working alright, we need to use > Gnome > >> Terminal's color scheme, and if we do need to change the > color scheme, > >> I think it should be done in time for Luna, hence I'm > asking for your > >> help guys. > >> > >> Thanks, > >> David (Munchor) > > > > -- > > Darcy Brás da Silva > > > > > -- > > 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 > > > > -- Darcy Brás da Silva signature.asc Description: This is a digitally signed message part -- 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] Design input on bug 1045511
I think we should first look at some kind of print screen, because the current color scheme is most likely the best 'default' I have found. And note that I program with emacs -nw mode, so readability is definitely a concern to me. PS: some packages can be installed that alter the color scheme of certain programs, not quite sure if there isn't something like that on the system were the bug was detected. On Mon, 2012-09-10 at 15:07 +0100, David Gomes wrote: > I need some design input on this bug: > https://bugs.launchpad.net/pantheon-terminal/+bug/1045511 > > If our color scheme is not working alright, we need to use Gnome > Terminal's color scheme, and if we do need to change the color scheme, > I think it should be done in time for Luna, hence I'm asking for your > help guys. > > Thanks, > David (Munchor) -- Darcy Brás da Silva signature.asc Description: This is a digitally signed message part -- 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] Experimental Branch - Possibly fixed bug #1038291 nonexistent files like read-only
It's +junk mainly made it that way to avoid me getting confused when doing this kind of changes, also because I'm waiting for mefrio as he requested, but I wanted to have so possible solutions/ideas to present to him :) . And thanks for grabit I will have look. On Mon, 2012-09-10 at 16:59 +0400, Sergey "Shnatsel" Davidoff wrote: > I take it you mean lp:~darcy-develin/+junk/scratch-experimental? I > wonder why it's in /+junk/ and not in /scratch/. > > In case you're into testing, the code can be pulled along with its > build dependencies, merged with latest trunk, and then built into .deb > packages for ease of your "dpkg -i *.deb" using: > > $ grabit lp:scratch lp:~darcy-develin/+junk/scratch-experimental > > grabit can be obtained from lp:~elementary-os/elementaryos/grabit > > -- > Sergey "Shnatsel" Davidoff > OS architect @ elementary -- Darcy Brás da Silva signature.asc Description: This is a digitally signed message part -- 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] Experimental Branch - Possibly fixed bug #1038291 nonexistent files like read-only
Hey guys, just to let you all know that I have made an experimental branch so I can try fix some of the things that involve larger changes, while I wait for mefrio to come back... The current state of the experimental contains what its hopefully a fix to https://bugs.launchpad.net/scratch/+bug/1048186 and https://bugs.launchpad.net/scratch/+bug/1038291 Testing and feedback would be appreciated... -- Darcy Brás da Silva signature.asc Description: This is a digitally signed message part -- 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] Review + Asisstentece for Scratch required!
It should be fixed now, I have done with the cost of reopening a less serious bug https://bugs.launchpad.net/scratch/+bug/1046534 merge was proposed : https://code.launchpad.net/~darcy-develin/scratch/fix-1048186/+merge/123499 On Mon, 2012-09-10 at 00:08 +0400, Sergey "Shnatsel" Davidoff wrote: > Guys, it's great that you're going to invest in code quality. I didn't > tell you that, but it might be a good idea to throw in some unit > testing too, since Scratch is being used as a shared component and > there are lots of combos of all the autosave and autoupdate options so > it's hard to test them all manually. > > By the way, any idea what causes http://pad.lv/1048186 ? Scratch is > hardly usable for me because of it, I had to fall back to Gedit for > the first time in months. > -- Darcy Brás da Silva signature.asc Description: This is a digitally signed message part -- 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] Review + Asisstentece for Scratch required!
No problem, I'm looking forward to work with you :)
I can wait a couple days. While doing so I'll try prepare some possible
solutions :)
On Sun, 2012-09-09 at 18:23 +0100, Mario Guerriero wrote:
> Scratch is becoming every push a bigger project which make it a bit more
> difficult to maintain.
>
> I'll return home Wednesday, please wait me to discuss about it :)
>
> Thanks for your love on the project.
>
> Mario Guerriero
> Sent from iPhone 3GS
>
> On 09/set/2012, at 18:08, Darcy Brás da Silva
> wrote:
>
> > I indeed can, sorry for taking long, I had to sleep a bit, couldn't
> > think straight after a code marathon :).
> >
> > Instead of pasting code in here I will link to the respective lines and
> > explain a bit what's wrong with what.
> >
> > For instance:
> >
> > from-line:77 to: 88 {Services/Document.vala}
> > http://bazaar.launchpad.net/~elementary-apps/scratch/scratch/view/head:/src/Services/Document.vala#L77
> >
> > line 86
> > return _state;
> >
> > various problems:
> >
> > 1 - Never Runs due to else statement on line 84 which covers the last
> >possible scenario.
> > 2 - This creates the bug https://bugs.launchpad.net/scratch/+bug/1038291
> >
> > Where the correction is not very clear. For some reason returning _state
> > fixes it but then we get into another problem, which is
> >
> > We return _state without a way of knowing that _state was assigned before
> >
> > Just in this file we have more hairy stuff, lets see,
> >
> > line 67 : public string filename {get; public set; }
> > so anyone can change this variable ?
> > most functions using this variable use it directly and they check it,
> > if it's not null, they might perform checks in an unassigned situation
> > which can become a bug witch hunt.
> >
> > some proof of what I just mentioned
> > line 111:
> > http://bazaar.launchpad.net/~elementary-apps/scratch/scratch/view/head:/src/Services/Document.vala#L111
> >
> > relies on the previously shown `buggy' line :
> > http://bazaar.launchpad.net/~elementary-apps/scratch/scratch/view/head:/src/Services/Document.vala#L77
> > http://bazaar.launchpad.net/~elementary-apps/scratch/scratch/view/head:/src/Services/Document.vala#L273
> >
> > And is also incoherent, if we just want state, shouldn't we just use the
> > private member, which should be storing the current state of it ?
> > why do we keep requesting a full check ?
> >
> > line
> > http://bazaar.launchpad.net/~elementary-apps/scratch/scratch/view/head:/src/Services/Document.vala#L719
> >
> > this one is so precious that I'm posting it all:
> > the function had no comments, so the ones there are my notes
> >
> > public bool can_write () {
> >
> > //check that we never know if the var is set
> >if (filename != null) {
> >
> >FileInfo info;
> >bool writable;
> >
> >try {
> >
> >info = file.query_info (FileAttribute.ACCESS_CAN_WRITE,
> > FileQueryInfoFlags.NONE, null);
> >writable = info.get_attribute_boolean
> > (FileAttribute.ACCESS_CAN_WRITE);
> >
> >return writable;
> >
> >} catch (Error e) {
> >
> >warning ("%s", e.message);
> >//redundancy, this is writable variable job
> >return false;
> >
> >}
> >
> >} else {
> >//heres were we win, so if filename == null, we can_write to the file
> >return true;
> >
> >}
> >
> >}
> >
> > line 697:
> > http://bazaar.launchpad.net/~elementary-apps/scratch/scratch/view/head:/src/Services/Document.vala#L696
> >
> > Both error on line 708 and filename set to null the return is 0
> > Note: 0 is a valid size, while one want's indicate an error scenario
> > so -1 and -2 would be more appropriate.
> > Probably trowing an error would also be a good idea.
> >
> > file Scratch.Vala
> > this one was introduced by me actually, but is something that can be easily
> > fixed.
> >
> > http://bazaar.launchpad.net/~elementary-apps/scratch/scratch/view/head:/src/Scratch.vala#L135
> >
> > I did not handled File exception which now make scratch crash if the
> > decoding of filename files.
> > bu
Re: [Elementary-dev-community] Review + Asisstentece for Scratch required!
I indeed can, sorry for taking long, I had to sleep a bit, couldn't
think straight after a code marathon :).
Instead of pasting code in here I will link to the respective lines and
explain a bit what's wrong with what.
For instance:
from-line:77 to: 88 {Services/Document.vala}
http://bazaar.launchpad.net/~elementary-apps/scratch/scratch/view/head:/src/Services/Document.vala#L77
line 86
return _state;
various problems:
1 - Never Runs due to else statement on line 84 which covers the last
possible scenario.
2 - This creates the bug https://bugs.launchpad.net/scratch/+bug/1038291
Where the correction is not very clear. For some reason returning _state
fixes it but then we get into another problem, which is
We return _state without a way of knowing that _state was assigned before
Just in this file we have more hairy stuff, lets see,
line 67 : public string filename {get; public set; }
so anyone can change this variable ?
most functions using this variable use it directly and they check it,
if it's not null, they might perform checks in an unassigned situation
which can become a bug witch hunt.
some proof of what I just mentioned
line 111:
http://bazaar.launchpad.net/~elementary-apps/scratch/scratch/view/head:/src/Services/Document.vala#L111
relies on the previously shown `buggy' line :
http://bazaar.launchpad.net/~elementary-apps/scratch/scratch/view/head:/src/Services/Document.vala#L77
http://bazaar.launchpad.net/~elementary-apps/scratch/scratch/view/head:/src/Services/Document.vala#L273
And is also incoherent, if we just want state, shouldn't we just use the
private member, which should be storing the current state of it ?
why do we keep requesting a full check ?
line
http://bazaar.launchpad.net/~elementary-apps/scratch/scratch/view/head:/src/Services/Document.vala#L719
this one is so precious that I'm posting it all:
the function had no comments, so the ones there are my notes
public bool can_write () {
//check that we never know if the var is set
if (filename != null) {
FileInfo info;
bool writable;
try {
info = file.query_info (FileAttribute.ACCESS_CAN_WRITE,
FileQueryInfoFlags.NONE, null);
writable = info.get_attribute_boolean
(FileAttribute.ACCESS_CAN_WRITE);
return writable;
} catch (Error e) {
warning ("%s", e.message);
//redundancy, this is writable variable job
return false;
}
} else {
//heres were we win, so if filename == null, we can_write to
the file
return true;
}
}
line 697:
http://bazaar.launchpad.net/~elementary-apps/scratch/scratch/view/head:/src/Services/Document.vala#L696
Both error on line 708 and filename set to null the return is 0
Note: 0 is a valid size, while one want's indicate an error scenario
so -1 and -2 would be more appropriate.
Probably trowing an error would also be a good idea.
file Scratch.Vala
this one was introduced by me actually, but is something that can be easily
fixed.
http://bazaar.launchpad.net/~elementary-apps/scratch/scratch/view/head:/src/Scratch.vala#L135
I did not handled File exception which now make scratch crash if the decoding
of filename files.
but to be fair, this tactic is wrong since the very start.
The open_file function should get a file and this would not be required.
However i don't know every part of the code that uses this, and some of what
I saw do have a legitime reason to send an URI instead of a File (like drag &
drop ).
Since the moment of the patch I explicitly told that it was also inefficient
so yeah...
However that does require to be handled with a try-catch
We run a bit out of options if we fail the access to a name though.
line
http://bazaar.launchpad.net/~elementary-apps/scratch/scratch/view/head:/src/Widgets/Tab.vala#L145
get_basename to a presentation element
remind you valadoc's where it says that it does NOT return a UTF-8 string
so improper for that.
I also noted that most file check happen at filename level, which is wrong, one
can possibly have
two files named the same from different paths, and so unique id of the files
should be made based
on full path and not just filename
Maybe an hash don't know... needs checking.
I think this is enough for the sample requested. Isn't it ?
I can go find more if required though.
PS: I have also found Many CGL violations...
Hope to hear from all soon.
cheers
On Sun, 2012-09-09 at 16:02 +0400, Sergey "Shnatsel" Davidoff wrote:
> Could you provide a few examples of the suspicious code/behaviour?
>
> I'm no dev, but as a script kitty I can tell that grep is your best
> friend when it comes to locating function calls in the
[Elementary-dev-community] Review + Asisstentece for Scratch required!
Hi everyone, Most of you probably knows I have been following the project for quite a long time. I have done some translation suggestions and some bug reporting, but not much other then that. Due to availability I can now focus on helping out more, including code. Which I already did to scratch and pantheon-terminal. While fixing a bug in scratch I had to compile scratch to test it, just regular procedure. It's when I start panicking , I see a large amount of Warnings, which I tried to initially ignore, because they weren't related with files i have edited. But it got stuck in my mind. So after preparing the patch branch and proposing the merge I decided to investigate them a little further. I found from unhandled errors, unused variables to unreachable code. And these are vala [level] code. So for me that's pretty serious... Decided to help out and make good use of my free time, here I go try to fix this issues and find logical errors in certain functions. The weird thing is that the functions that are affected by this have some fundamental responsibilities to other parts of the project, which leads me to think that if scratch works, it probably means that somewhere somehow the rest of the code also uses and expects the "incorrect" result of such functions... So please I need your help. Maintainers... Thanks in advance -- Darcy Brás da Silva signature.asc Description: This is a digitally signed message part -- 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] [Merge] lp:~darcy-develin/pantheon-terminal/fix-1047106 into lp:pantheon-terminal
Regarding that problem I just followed what was there. HBox wasn't using Gtk. prefix and the code does include a "using Gtk" at the top. so in others words. The problems with this CGL(Coding Guide lines) come from the example given by the project itself. I should also take the moment to say that until the CGL is made publicly available in the elementary website, it shouldn't be enforced. People are not wizards that guess them. None the less , it's fixed now... And I already proposed a merge. It's up to you ... On Fri, 2012-09-07 at 15:44 +, Victor Eduardo wrote: > The coding style guidelines also suggest using "Gtk.Box" instead of simply > "Box". The "using" keyword should be avoided. -- Darcy Brás da Silva signature.asc Description: This is a digitally signed message part -- 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] Need love on BUG #1046534 fix already provided
Ok i have probably been "*flooding" irc channel asking for some love (since i don't have commit rights) to the scratch bug i reported and later on provided a the diff's for fixes. Since not everyone checks irc that often here is the link: https://bugs.launchpad.net/scratch/+bug/1046534 it's fairly straight forward, i hope it's good enough to get in... cheers -- Darcy Brás da Silva signature.asc Description: This is a digitally signed message part -- 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] Developer Environment For Elementary OS
No, I wasn't aware of such blueprints, I guess it's a bit faulty on my side on not checking it before other the talking about the idea on IRC. I will certainly have a deep look at it. Thanks On Tue, 2012-09-04 at 23:46 +0400, Sergey "Shnatsel" Davidoff wrote: > > Now I am fully aware that maybe this would be a hard work, and > possiblylimiting to the fact that having everything shipped, > would mean largeriso imageswhich then could be "bad" in terms > of upload + updated state of the iso.So another idea to > support this view would go towards a "ElementaryDeveloper > MetaPackage" that would take care of preparing a nice > development environment. > > > Yep, it's on the radar, see > https://blueprints.launchpad.net/elementaryos/+spec/dev-metapackage-elementary > (and http://elementaryos.org/journal/how-see-what%E2%80%99s-our-sleeves on > using blueprints, if you're not familiar with them). > > But first we need an SDK to put into the metapackage, which we > currently don't have (in a complete or stable state at least). There's > GrabIt but it's not that great for novice devs anyway and Tom has a > project creation script, both of which should probably become a part > of Euclide, our work-in-progress IDE at some point... > > Right now we're too busy with getting Luna out of the door, but I'd > expect toolset and SDK work to happen right after Luna release. > > If you want the libraries needed for developing our software, > just use "sudo apt-get source", any developer should know how > to get this kind of tools. Using bazaar to branch and build > our tools from source is also something our developers > must know how to do. > > apt-get source and bzr are by far not the most developer-friendly > things. In fact, apt-get source has absolutely nothing to do with > developers at all, and the fact that some people consider it so only > proves that our toolset is confusing. > > Not to mention that we don't even have an into into all these things, > yet. > > > -- > Sergey "Shnatsel" Davidoff > OS architect @ elementary -- Darcy Brás da Silva signature.asc Description: This is a digitally signed message part -- 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] Developer Environment For Elementary OS
Sorry sending the message twice, I think I didn't set my email client to assume elementary filter as mailing list and thus was only replying to one individual. On Tue, 2012-09-04 at 19:01 +0100, David Gomes wrote: > Shipping more packages in my opinion is anti-developping philosophy. To start, the idea behind this IS NOT to put into the _main release_ but rather having a developer environment, something developers would use, Not the everyday joe (unless he/she/it wanted to). > Each developer has his own preferred tools. Shipping more text > editors, more libraries, etc is just more bloat in my opinion. Ubuntu > and its derivatives have enough bloat already, since most of these > distributions ship with more than 2000 packages. In my system I have > around 1000 packages installed, but it came with around 600. Who is talking about shipping more text editors ? The way I see it is quite simple, ship a default bundle, possibly with notes, and core libraries to develop elementary apps. Nobody is talking about making a code factory. Things like offline documentation available maybe even pdf's. Even a collection of pre-set bookmarks would do a whole lot for someone that wants to try fixing a bug but has little experience. Makefile, Cmake, templates that are commented and explained, compiler ready to use in the version elementary apps are using, alias set to generate directory structured and so on. > > > Besides, developers should face bugs. It's the best way we can know > about them and fix them (see > http://elementaryos.org/journal/eating-our-own-dog-food). I agree with "eating-our-own-dog-food", however i think you are misinterpreting what it _"really"_ means. My perspective of what it means goes more inline with, have elementary installed on your "home" computer, and use in day to day tasks. That way one can detect (pains, problems, bugs, that a regular user would see/feel). When developing what we want is maximum stability and minimum interference, so we can accurately debug the software we are developing, instead of being misguided because of bugs that we are unaware off, because that actually delays the development speed, and hardens the debugging process, not to mention that also hides bugs when mistaken/confused by other source of errors. > > If you want the libraries needed for developing our software, just use > "sudo apt-get source", any developer should know how to get this kind Yes any _developer_ ... Remind you that not everyone is already one, there are quite a few that still want to become one. > of tools. Using bazaar to branch and build our tools from source is > also something our developers must know how to do. Version control systems tend to be a pain for new comers, and even for some other experienced developers that don't use the one elementary uses. > > > This "iso" has no real advantages in my honest opinion. > > On Tue, Sep 4, 2012 at 6:02 PM, Darcy Brás da Silva > wrote: > Today while talking to some fine folks at #elementary-dev that > go by the > handles of > victored and voluntatefaber , I wondered if there was any iso > build > ready to start working/developing > for elementary. > Now what would be the advantages of having the extra work on > getting > this iso out. > > 1) Errors and bugs can be very damaging to a development > environment, > which lead to a constant fight wen testing highly unstable > packages. This makes the developer hell much bigger since > everyone tends > to test and run this packages in a somewhat different > configuration. > In case of failure, the developer then needs re-set the > development > environment to a known stage. This can be very time consuming, > that could be in better use. > It would also reduce the potential hidden errors, and the > known phrase > "That's weird, It works in my machine". > > 2) Individuals that want to start developing in/for elementary > could > start right away hacking their way in. And if for some reason > they mess > up big time, > guess what ? The iso is right there, re-install, start fresh. > > Now I am fully aware that maybe this would be a hard work, and > possibly > limiting to the fact that having everything shipped, would > mean larger > iso images > which then could be "bad" in terms of upload + updated state > of the iso. > So another idea to support this view would go toward
[Elementary-dev-community] Developer Environment For Elementary OS
Today while talking to some fine folks at #elementary-dev that go by the handles of victored and voluntatefaber , I wondered if there was any iso build ready to start working/developing for elementary. Now what would be the advantages of having the extra work on getting this iso out. 1) Errors and bugs can be very damaging to a development environment, which lead to a constant fight wen testing highly unstable packages. This makes the developer hell much bigger since everyone tends to test and run this packages in a somewhat different configuration. In case of failure, the developer then needs re-set the development environment to a known stage. This can be very time consuming, that could be in better use. It would also reduce the potential hidden errors, and the known phrase "That's weird, It works in my machine". 2) Individuals that want to start developing in/for elementary could start right away hacking their way in. And if for some reason they mess up big time, guess what ? The iso is right there, re-install, start fresh. Now I am fully aware that maybe this would be a hard work, and possibly limiting to the fact that having everything shipped, would mean larger iso images which then could be "bad" in terms of upload + updated state of the iso. So another idea to support this view would go towards a "Elementary Developer MetaPackage" that would take care of preparing a nice development environment. Please feel free to contact me, on any elementary subject. I'll be glade to reply as soon as I can. -- Darcy Brás da Silva signature.asc Description: This is a digitally signed message part -- 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
