User talk:Hooray: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
Line 161: Line 161:
: But this is a simple, and clear, issue of coming up with a few guidelines first - which should not be "personal". Otherwise, we're simply facing a situation similar to code/Nasal contributions, where different contributors don't quite agree with the style/nature and design of certain code - which usually boils down to statements like "not high on my todo list, but please be me guest" - which kinda goes to say, that this is not uncommon at all, and people -like me- who don't like certain contributions, more often than not, have to roll up their own sleeves to establish "best (better) practices", be it in the form of tailored tutorials, guidelines or corresponding contributions in the form of patches (or even just fixing broken newsletter templates so that they become editable again).  
: But this is a simple, and clear, issue of coming up with a few guidelines first - which should not be "personal". Otherwise, we're simply facing a situation similar to code/Nasal contributions, where different contributors don't quite agree with the style/nature and design of certain code - which usually boils down to statements like "not high on my todo list, but please be me guest" - which kinda goes to say, that this is not uncommon at all, and people -like me- who don't like certain contributions, more often than not, have to roll up their own sleeves to establish "best (better) practices", be it in the form of tailored tutorials, guidelines or corresponding contributions in the form of patches (or even just fixing broken newsletter templates so that they become editable again).  
: Honestly, the number of people contributing to the newsletter isn't exactly large - there's really just a handful of regular contributors, so it should be fairly simple for '''us''' to establish a set of common rules. I am sure that the [[Instant-Cquotes]] script can be adjusted accordingly. But like I said previously, it's a cost/benefit issue from my standpoint: '''not''' contributing to the newsletter the way I do, would take away some less-structured entries, but also quite a lot of content. I don't think we need to make this any more problematic: there's really just 3-5 regular newsletter contributors - those should obviously be the ones to come up with corresponding guidelines.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 21:08, 2 August 2014 (UTC)
: Honestly, the number of people contributing to the newsletter isn't exactly large - there's really just a handful of regular contributors, so it should be fairly simple for '''us''' to establish a set of common rules. I am sure that the [[Instant-Cquotes]] script can be adjusted accordingly. But like I said previously, it's a cost/benefit issue from my standpoint: '''not''' contributing to the newsletter the way I do, would take away some less-structured entries, but also quite a lot of content. I don't think we need to make this any more problematic: there's really just 3-5 regular newsletter contributors - those should obviously be the ones to come up with corresponding guidelines.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 21:08, 2 August 2014 (UTC)
:: Hi,
:: it wasn't me who retracted your contribution yesterday, so not sure how I would be pushing my own rules. I asked you to clean it up, not to remove it. I've raised my concerns over using quotes on the wiki various times, so that should be no surprise. If I wasn't interested in hearing your opinion I wouldn't have come here.
:: We could have lengthy discussions about it, but in the end you're the only one contributing quotes this way. It might be more efficient to just talk to you ;-) I think the following quote (ha!) is quite representative for my opinion (and yours as well?):
::: ''Last month I rewrote several of such quote sections. You explained you'd added them as place holders, so I thought we were on the same track now. I don't have the time nor desire to rewrite quotes into text every month, so that's why I asked you to do it this time.''
:: With slightly more effort you can make an enormous improvement in readability and styling. The effort is smallest if done by the person who's read up on the subject (i.e. the one adding those quotes). Just look at the difference between [http://wiki.flightgear.org/index.php?title=FlightGear_Newsletter_June_2014&oldid=73574] and [http://wiki.flightgear.org/index.php?title=FlightGear_Newsletter_June_2014&oldid=73577] (ignore the broken heading templates there). In general I prefer quality over quantity, especially for something that we release into the world to promote FlightGear.
:: We've got 28 days to show what we would like to end up with this month :-)
:: Cheers, [[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 14:28, 3 August 2014 (UTC)

Revision as of 14:28, 3 August 2014

Dump space

Aircraft-set validation

Procedurally creating Cockpit GUI wrappers

See http://flightgear.org/forums/viewtopic.php?f=4&t=16438&p=187343#p187343

High-Level Architecture

Hi,

do you plan to write subtantial articles on all the HLA subjects? If not, it might be better (for now) to list all the abbreviations/terms on the High-Level Architecture page. The articles I mean include Federate, Federation, RTI. Please let me know what you prefer (or perform the merge if you support that ;-) ).

Cheers, Gijs 13:33, 18 April 2012 (EDT)

Nominating articles for deletion

Hi,

could you please use the "new" template in the future? See {{Delete}}

Thanks! Gijs 20:33, 16 July 2013 (UTC)

Bump. The new template has some mandatory fields, so please check the template page to see how it should be used.
Gijs (talk) 15:30, 5 August 2013 (UTC)

The done, not done and pending templates

I undid your addition of parenthesis to the {{done}}, {{not done}} and {{pending}}. I can't any longer stand the combination of parentheses, which are usually a way to mark text as less important, and bold text, which usually is a way to have the text standing out or emphasize something. Really a typographical shouting whisper, that kind of made my eyes sore. ;-)

If you want to de-emphasise the text Done|Not done|Pending, I would instead suggest using italics, which are generally less of an emphasise than bold text, while still standing out from the surrounding text. Alternatively, to emphasise the text further I would instead suggest using bold and italic text.

Johan G (Talk | contribs) 10:35, 9 August 2013 (UTC)

fps does not rise up when I turn shaders off

Regarding: http://www.flightgear.org/forums/viewtopic.php?f=37&t=21046 Please check the Article: Troubleshooting problems for a possible solution.

--HHS (talk) 18:14, 14 October 2013 (UTC)

Canvas Documentation/TODO

Hi,

please don't mix documentation and TODO lists (like http://wiki.flightgear.org/index.php?title=Canvas_Element&diff=63398&oldid=63381) Especially the Reference section of the Canvas (see sidebar) is meant as user documentation. As using the Canvas doesn't require knowing C++ we should not mention anything there on how to extend the C++ code base. Also a documentation should describe to the user what is possible and how do use it. Not what will maybe get possible in the future.

You can move this to a separate page, but please always keep in mind who is going to read a certain page, and what is the information intended to be presented.

TheTom (talk) 23:18, 16 October 2013 (UTC)

Recommended Property Tree Enhancements#Permission handling related

Hi Hooray, just so you know, what Thomas committed today is just a wrapper API to set a value and mark it as read-only. The ability to have read-only nodes has existed for a long long time, e.g. see /sim/fg-root, by using setAttribute (READ vs READ | WRITE, also possible from Nasal). So I think the point in the article is mute? —Philosopher (talk) 16:10, 20 October 2013 (UTC)

Yeah, I know - I looked at the commit when I left a comment there. But most of the article is outdated anyways, OTOH as can be seen, some of the old ideas are not all that bad, and may even become increasingly important again - I haven't checked when the code was added or when the article was written - but one thing is true: until today, we haven't really differentiated between property mutability like initial startup state, and that's definitely something that's going to be important as part of efforts like Reset & re-init. As mentioned in response to the commit, we would ideally show SG_LOG() warnings whenever such "readonly" properties are modified. Many related issues are not immediately obvious, but property-based subsystems like the canvas would ideally also declare their own properties as input-only or output-only (readonly), e.g. by extending the PropertyObject<> code - this would be particularly useful for anything related to the replay system, or the flight recorder system - but the multiplayer system would also benefit from being able to directly tell what properties are input/output properties, and obviously this also applies to our existing multi-instance master/slave code, which needs to be currently set up manually. So setting attributes to communicate property mutability/scopes seems like a sane idea still today (regardless of how long the underlying code has been in place) - sync'ing multiple fgfs instances with canvas displays would also become simpler that way. So while many things in that article are kinda outdated/moot, I think the last 18-24 months of core development have shown some of the underlying ideas to be still applicable to a certain degree. Thus, I'd hesitate to delete anything there at the moment - but I'm also not overly eager to update things... I just ended up updating the section because I saw todays commit. --Hooray (talk) 16:25, 20 October 2013 (UTC)

Latest newsletter edition – Nice edit

That was a pair of nice edit-saving edits. :-)

Johan G (Talk | contribs) 22:33, 3 December 2013 (UTC)

The needed Git navigation template

Err, did you have a look at the source of {{building}}, I think you would consider it quite feasible to add the template yourself... ;-)

The {{navbox}} template is currently undocumented, it is one of those more tricky ones to document. In (un?)due time it will be, I hope.

Johan G (Talk | contribs) 00:45, 7 December 2013 (UTC)

This wasn't intended for you, I just didn't want to copy/paste things (yet), but also didn't want to forget about it - thanks though, yes, I do realize that I should have the mental capacity to handle the implementation of this :-) --Hooray (talk) 00:51, 7 December 2013 (UTC)
Ah, ok. :-)
Johan G (Talk | contribs) 01:04, 7 December 2013 (UTC)

TODO and FIXME templates

I saw that edit. ;-P

I have sometimes pondered {{todo}} and {{fixme}} templates, though I'm not sure they are an all too good idea, at least not in articles meant as user documentation.

As for mockups, how would something like these look: User:Johan G/Todo and fixme template sandbox?

Johan G (Talk | contribs) 16:46, 8 December 2013 (UTC)

In this particular case, {{Incomplete}} would be more fitting I'd say...
Gijs (talk) 17:05, 8 December 2013 (UTC)
Indeed it is, but sometimes it is a bit too general. For those cases when someone needs to mark a paragraph or maybe just a sentence there is currently only {{clarify}}, I think. For a sanbdox or a page under heavy development it is a bit discrete I think.
Johan G (Talk | contribs) 17:22, 8 December 2013 (UTC)

The colour coded MVC diagrams are great

I really like those colour coded MVC diagrams you added to the MapStructure article. While I am familiar with the MVC concept I have not even tried to get a concept for how it is implemented, since I am not that interested in Nasal presently. Those diagrams give me at least some understanding of the structure with even a quick glance.

When I first stumbled upon the MVC concept when reading about some of the ideas behind SmallTalk, either on Wikipedia or more probably WikiWikiWeb (The Portland Pattern Repository), there where no illustrations and it took a day or two to wrap my mind around the concepts. Those diagrams will probably help new Nasal and aircraft developers immensely. Thank you! :-)

Johan G (Talk | contribs) 02:46, 8 February 2014 (UTC)

They're cute too! ~.^ —Philosopher (talk) 04:12, 8 February 2014 (UTC)

lol, "cute" ? You aren't in a good position to judge things, this is primarily YOUR work Philosopher that we're documenting here!!
The primary idea was to document the main concepts.
We are facing the problem that we're having an increasing number of people wanting to do related projects, without knowing how to do them properly.
They would often rather start from scratch than try and understand a framework that's too difficult/obscure.
In general, MapStructure has become a solid foundation already - and we have enough people here who should be able to pick up the concepts and help maintain it over time.
But speaking from experience, the code isn't exactly straightforward - i.e. had you used conventional classes and inheritance, we might have 3-5 more people willing to play with it - but what you have come up with is a bit too sophisticated for the average FG contributor.
As you may remember, I also faced a steep learning curve there when I was working with it - and you even said that you had the same issues when you abandoned the code for a while.
Which is why I added some more explanations and diagrams.
So as long as the framework is sufficiently documented and self-explanatory, it will be less work for us, because others can help with it over time.
I am not sure if MapStructure is a good place for people to start with Nasal hacking though...
That's basically the whole plan. So there'll probably be more diagrams. They are simple to add, using yuml - i.e. just 2-3 minutes even for complex diagrams.--Hooray (talk) 06:29, 8 February 2014 (UTC)

FGCamera not yet in Git

Hi,

FGCamera is not yet in Git.

Gijs (talk) 21:25, 6 March 2014 (UTC)

I know, but it's available for download, and we've previously promoted addons that never made it into git. On the other hand, I do agree that it would be better to focus on features (=including aircraft) commonly available in "stock" FG - then again, most people do not seem to bother updating the changelog regularly. It seems to be pretty safe to add things early on and review things when editing the changelog later. Otherwise, we tend to forget most recent additions, because most of us don't really enjoy going through 6 months of forum threads, devel list postings, newsletters and commit logs. FGCamera is just a base package addon so far, so doesn't need to be committed to SG/FG to be useful. Still, I do agree that it would make sense to get it reviewed/discussed and committed. Would you be willing to help get it reviewed in time for 3.2 ? --Hooray (talk) 21:59, 6 March 2014 (UTC)

Talk:FlightGear Newsletter June 2014

Hi,

please have a look at my comments on Talk:FlightGear Newsletter June 2014

Cheers, Gijs (talk) 20:51, 23 June 2014 (UTC)

FlightGear Newsletter July 2014#FGCanvas Updates

Hi,

could you please clean up FlightGear Newsletter July 2014#FGCanvas Updates so we can publish the newsletter?

Thanks! Gijs (talk) 14:45, 2 August 2014 (UTC)

What exactly do you have in mind ? It looks fairly clean to me - or is this about the usage of instant-cquotes ? If that's the case, we should come up with a consensus if we want to encourage such additions or not. --Hooray (talk) 14:51, 2 August 2014 (UTC)
Hi,
Last month I rewrote several of such quote sections. You explained you'd added them as place holders, so I thought we were on the same track now. I don't have the time nor desire to rewrite quotes into text every month, so that's why I asked you to do it this time.
To list a few instant-cquote bugs (though that is not the main issue here, as explained above):
  • quotes in quotes are hard to identify
  • year is lacking from the date
  • lots of unneeded nowiki tags
  • html tags like br, ul and li
Cheers, Gijs (talk) 18:54, 2 August 2014 (UTC)
I've fixed a couple of the issues you pointed out - but like I briefly mentioned in the "commit" message: I am not sure where we're headed here. If there is to be some kind of "standard" to be established, that's great - but it better be made known first, or fellow contributors (like myself) won't know what to look for. As you may remember, I was the one to originally suggest that the newsletter be wiki-based - so I am fully supportive of the whole idea here, and want to follow proper procedures - and it is great that some folks are working towards improving things (including yourself and Johan_G) - but please don't just come up with your own rules and guidelines without 1) communicating and discussing them upfront and 2) coming up with a consensus that we all agree on.
I certainly don't want to make your job more difficult - and I am sure you don't want to make mine more difficult.
But this is a simple, and clear, issue of coming up with a few guidelines first - which should not be "personal". Otherwise, we're simply facing a situation similar to code/Nasal contributions, where different contributors don't quite agree with the style/nature and design of certain code - which usually boils down to statements like "not high on my todo list, but please be me guest" - which kinda goes to say, that this is not uncommon at all, and people -like me- who don't like certain contributions, more often than not, have to roll up their own sleeves to establish "best (better) practices", be it in the form of tailored tutorials, guidelines or corresponding contributions in the form of patches (or even just fixing broken newsletter templates so that they become editable again).
Honestly, the number of people contributing to the newsletter isn't exactly large - there's really just a handful of regular contributors, so it should be fairly simple for us to establish a set of common rules. I am sure that the Instant-Cquotes script can be adjusted accordingly. But like I said previously, it's a cost/benefit issue from my standpoint: not contributing to the newsletter the way I do, would take away some less-structured entries, but also quite a lot of content. I don't think we need to make this any more problematic: there's really just 3-5 regular newsletter contributors - those should obviously be the ones to come up with corresponding guidelines.--Hooray (talk) 21:08, 2 August 2014 (UTC)
Hi,
it wasn't me who retracted your contribution yesterday, so not sure how I would be pushing my own rules. I asked you to clean it up, not to remove it. I've raised my concerns over using quotes on the wiki various times, so that should be no surprise. If I wasn't interested in hearing your opinion I wouldn't have come here.
We could have lengthy discussions about it, but in the end you're the only one contributing quotes this way. It might be more efficient to just talk to you ;-) I think the following quote (ha!) is quite representative for my opinion (and yours as well?):
Last month I rewrote several of such quote sections. You explained you'd added them as place holders, so I thought we were on the same track now. I don't have the time nor desire to rewrite quotes into text every month, so that's why I asked you to do it this time.
With slightly more effort you can make an enormous improvement in readability and styling. The effort is smallest if done by the person who's read up on the subject (i.e. the one adding those quotes). Just look at the difference between [1] and [2] (ignore the broken heading templates there). In general I prefer quality over quantity, especially for something that we release into the world to promote FlightGear.
We've got 28 days to show what we would like to end up with this month :-)
Cheers, Gijs (talk) 14:28, 3 August 2014 (UTC)