Re: [Geeqie-devel] Geeqie++ fever dreams

[Omari Stephens]

On 12/24/2016 05:18 PM, Alexander Antimonov wrote:
>> We should have a good expectation of improving life for our users ...
> Users are important, but with such move we could improve developers'
> life at least.
More to the point, code that is easier maintain benefits developers as 
well as users.  And having a language that actually encourages code 
encapsulation, reuse, and adaptation would help us build UIs and 
subcomponents that are more consistent, and consequently, that are 
easier and more intuitive for users to understand and to become familiar 
with.

>> - Introduce new bugs (because big rewrites always do)
> Sure, but with C++ port we can also simplify code, and less code - less bugs.
> Now considerable part of Geeqie's code is plain C which builds UI.
> It's a rare method of building UI nowadays. It should be replaced with
> something like Glade description.

It would also be a great opportunity to _remove_ latent bugs that 
already exist.  _Especially_ typing-related bugs.  Just yesterday (which 
is what spurred me to send this email), I fixed a latent buffer-overflow 
bug in the rcfile parsing code ([1]), because someone passed a short* to 
a function that was going to stuff an int into it.  So I fixed it by 
manually copying and pasting the uint helper functions and replacing 
"uint *" with "uint16 *" in the prototype.  Except I didn't copy all of 
them because it simply increases the maintenance burden for no benefit 
yet.  Except not having a unified API across all of the types creates 
its own dev usability burden.  If that's not a 100% prototypical "just 
throw templates at it" problem, I don't know what is.

Also, say you've got a GList*.  How do you avoid sticking the wrong type 
into it?  In C, you've gotta be perfect (including when returning to 
code that hasn't been touched in 4 years) or your code will magically 
crash when a user is trying to get work done.  In C++, your code isn't 
going to compile if you get it wrong.

Here's another easy example: does Geeqie have any double-free or memory 
leak bugs?  I can pretty much guarantee that it does, because they're so 
hard to detect.  C++ features enable (but don't force) you to actually 
guarantee that those classes of bugs don't exist.  Fewer crashes and 
less unintended memory use both offer significant quality-of-life 
improvements for users.

>> - Maybe exclude some core developers who just don't have as much fun in C++ 
>> as in C
> It might be a good chance for them to improve their skills a bit.
>
> My 5 cents, I prefer do not use love/hate words when it comes to
> technical things.

Agreed, Jeff, which is specifically why I posed this as a question and 
not as a proposal.

That said, I also agree with Alexander.  Learning C++11 (and 
_specifically_ C++11, as opposed to any earlier version) has made me a 
better C programmer, because it's made me more aware of the kinds of 
bugs I write in C that the compiler _doesn't_ catch.  Especially around 
pointer memory ownership.  And those problems are exacerbated by the 
asynchronous patterns used in Glib and GTK, as well as Geeqie itself 
(FileData, I'm looking at you).

std::unique_ptr is annoying, but it's specifically so annoying because 
it exposes so many of my bad pointer-handling habits and forces me to 
fix them.  Those bad habits also have a user impact (*cough* double 
free/memory leak), and being more aware helps me to write better code. 
But that awareness wouldn't have developed anywhere near as quickly 
without std::unique_ptr kicking me in the face every time I got it wrong.

--xsdg

[1] 
https://github.com/BestImageViewer/geeqie/commit/a43d40845dcc2fb63c1ad6cae31b8b1ff5527701

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel
___
Geeqie-devel mailing list
Geeqie-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geeqie-devel

Re: [Geeqie-devel] Geeqie++ fever dreams

[Alexander Antimonov]

> We should have a good expectation of improving life for our users ...
Users are important, but with such move we could improve developers'
life at least.

> - Introduce new bugs (because big rewrites always do)
Sure, but with C++ port we can also simplify code, and less code - less bugs.
Now considerable part of Geeqie's code is plain C which builds UI.
It's a rare method of building UI nowadays. It should be replaced with
something like Glade description.

> - Maybe exclude some core developers who just don't have as much fun in C++ 
> as in C
It might be a good chance for them to improve their skills a bit.

My 5 cents, I prefer do not use love/hate words when it comes to
technical things.


On Sat, Dec 24, 2016 at 5:57 PM, Jeff Abrahamson  wrote:
> Is there a case for what users will get if we make these changes?  We should
> ...
> (Bias: I do quite like C++.)
>
> Jeff Abrahamson
> +33 6 24 40 01 57
> +44 7920 594 255
> http://ml-week.com/ prochaine edition, 2016
>
> http://purple.com/jeff/
> http://blog.purple.com/jeff/

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel
___
Geeqie-devel mailing list
Geeqie-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geeqie-devel

Re: [Geeqie-devel] Geeqie++ fever dreams

[Jeff Abrahamson]

Is there a case for what users will get if we make these changes?  We
should have a good expectation of improving life for our users or something
similarly worthy if we were to undertake the risk of such a project.

The following user effects come to mind, and they aren't overly positive:

- Introduce new bugs (because big rewrites always do)
- Distract for a while from new features (if there are projects to improve
the package)
- Maybe exclude some core developers who just don't have as much fun in C++
as in C

If we're very lucky, we might get new developer interest from folks who
like C++ but were discouraged from contributing in C.  But community is one
of the hardest parts of open source projects, changing the filter on who is
likely to want to contribute is something to do with great trepidation.

(Bias: I do quite like C++.)

Jeff Abrahamson
+33 6 24 40 01 57
+44 7920 594 255
http://ml-week.com/ * prochaine edition, 2016*

http://purple.com/jeff/ 
http://blog.purple.com/jeff/


On 24 December 2016 at 16:39, Alexander Antimonov <
alexander.antimonov.od...@gmail.com> wrote:

> Hi,
> I could take part in porting Geeqie to C++1x if it is decided to do so.
> ​[...]
>
> On Fri, Dec 23, 2016 at 10:42 PM, Omari Stephens  wrote:
> > It is at least hypothetically possible to port Geeqie to C++11 / GtkMM.
>
>
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel___
Geeqie-devel mailing list
Geeqie-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geeqie-devel

Re: [Geeqie-devel] Geeqie++ fever dreams

[Alexander Antimonov]

Hi,
I could take part in porting Geeqie to C++1x if it is decided to do so.

I've been using different kinds of C++ (98/2003/201x) for more than 10
years. I believe the fundamental thing why C++ is better than C is C++
destructor and all the automatic actions that can be taken in it. It
is very convenient for a programmer. Sure, C++ has much more than just
that.

While porting to C++1x it is good chance to make Geeqie more
cross-platform. But it seems Gtk is becoming (has become) an auxiliary
tool for the "GnomeOS". And some of the well-known projects was/is
migrating from Gtk. Maybe we should consider Qt instead? Anyhow, I
guess it's more correct to talk about re-implementation than just
port.

On Fri, Dec 23, 2016 at 10:42 PM, Omari Stephens  wrote:
> It is at least hypothetically possible to port Geeqie to C++11 / GtkMM.
> ...
>
> Thoughts?
> --xsdg
>
> --
> Geeqie-devel mailing list
> Geeqie-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geeqie-devel

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel
___
Geeqie-devel mailing list
Geeqie-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geeqie-devel

Re: [Geeqie-devel] Geeqie coding standards? Third edition :o)

[Ian Zimmerman]

On 2016-12-24 15:00, Klaus Ethgen wrote:

> In any case. If we agree about a specific style, it should be
> configured via vim modeline in all files. Currently we have the
> following:

>set shiftwidth=8 softtabstop=0 cindent cinoptions={1s:

> It is nothing more wrong than a mismatch of that options with the
> current used style. (Does someone here use different editor than vim
> that does not respect such a setting?)

I use Emacs.  The C style in Emacs is extremely customizable, but still
I can't say for sure there is a 1-1 mapping of the settings with the vim
style settings.

Other points:

- I strongly prefer spaces only indentation

- I too prefer K ish style (opening brace after keyword on the same
  line)

- I think it's helpful to code function declarations and calls like this:

int
foo_func (long arg)
{
call_to_bar(arg);
}

  I mean in particular the hoisting of the return type on its own line,
  the space before the opening paren of the arg list declaration, and
  OTOH no space before the opening paren of the call.

- I am actually pretty religious about keeping to 80 chars per line.
  IMO if an expression is longer than that it needs to be factored
  anyway to be readable.  Of course some cultures (cough..Java) make
  this hard by adopting reallyInsaneLongDescriptiveNames, and then the
  people from such cultures move into your project ... ARRRGH!

-- 
Please *no* private Cc: on mailing lists and newsgroups
Personal signed mail: please _encrypt_ and sign
Don't clear-text sign: http://cr.yp.to/smtp/8bitmime.html

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel
___
Geeqie-devel mailing list
Geeqie-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geeqie-devel

Re: [Geeqie-devel] Geeqie++ fever dreams

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Omari,

Am Fr den 23. Dez 2016 um 21:42 schrieb Omari Stephens:
> It is at least hypothetically possible to port Geeqie to C++11 / GtkMM.
> 
> Ignoring the inevitable ridiculous mountain of work that it would take, 
> does the end state seem like a good idea?

Well, except from the Idea that I personally love C and hate C++... ;-)

Regards
   Klaus
- -- 
Klaus Ethgen   http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-BEGIN PGP SIGNATURE-
Comment: Charset: ISO-8859-1

iQGzBAEBCgAdFiEEMWF28vh4/UMJJLQEpnwKsYAZ9qwFAlhegCcACgkQpnwKsYAZ
9qwg6gv9HkaHgo+J6i0pSNQRScgpHgwpweLNMHlKOcQm/7mpqfKLYY4va5qeMw5B
9v2mEKfmh0hWNRNqR5m0UEKskacuql9van+Mu0Ah2hYlKNS3gOkbSQ5OkV7r5Z7W
ehBXWFgkSn27meFuodbvAN4+lNk3zfOoDlvOXWBp1XOeMeLFl2dzRSqNeoleGyT4
4GB70R7ZhiEwjVN0BI0BlJ8c8lNCdCtVIS9lQjd8HsTCD8NN+dbyYpC+ghzeTXke
6cR7MWFy8nd7/fWrmaq+hdU7Iorxb7e5jGWOzYPAmVE5UQCmQ5PYpf97ATThQxmZ
/g4V4taK0iZpQxuO7zJv9tXd8oz8XC1R1b5x7YsfF4IAQ5IXvipce8oxUGCFUqY9
9s/K7aGKP5+7Rn/VydcObKCCzt7VhiM2PhMsLWkBTdqGOFmYmZ4B+5OItAoJfldw
ApE6Na+70x6U1Ez8mhdPH+HUl8Wcwo/FVgopUppSvS5z9Z9QCL/8BxmudZmOrZO1
uRYMm36c
=ZaoO
-END PGP SIGNATURE-

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel
___
Geeqie-devel mailing list
Geeqie-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geeqie-devel

Re: [Geeqie-devel] Geeqie coding standards? Third edition :o)

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Omari,

Am Fr den 23. Dez 2016 um 19:09 schrieb Omari Stephens:
> In #2, I had created a one-liner to compute a line-length histogram our
> codebase.  I've rerun it and included the results below as [1].  If also
> attached a list of max-line-length by source file.  As of my git clone from
> earlier this week, Geeqie has 106k lines.  227 of those lines are over 160
> characters.  That's 0.2%

I personally doesn't care about long lines if they make stuff more logic
than a hell of linebreaks with indentations.

Longer lines are also better sometimes for merging purpose.

Moreover, most editors shows long lines in a better way as short ones
with indentations. Especially if you resize the window. I do many perl
coding and what I hate most is that limitation to 80 chars. When I use a
windows that is smaller, the code gets unreadable as the linebreaks from
the editor interfere with the artificial linebreaks.

> But beyond that, ClangFormat exists now.  Because it's part of Clang, and
> actually lexes/parses the C language, it can make actual semantically-driven
> decisions about how a piece of source code should look.  This means that
> _if_ we decide on some style, ClangFormat should make it relatively
> straightforward to update the codebase in one fell swoop.  (And FYI, the C++
> standard at Google, where I work, is to run all code through ClangFormat,
> with exceptions specified as per [2])

I didn't know that tool. But if there is something that works well, why
not adapt it...

I just want to have some thinking about one or the other style. Some
"common" styles are not really helpful.

Other think I do prefer is the K style instead of the unbalanced
braces GNU style.

Maybe we can have a style config like perltidy config.

> With that said, I would love for us to get away from a style that encourages
> us to mix tabs and spaces.  See, for instance, [3].  There is no way to
> match an arbitrary paren on the prior line without using spaces for some
> indentation.  But if our style is to use tabs for most indentation, it
> either means that you can't match the exact paren offset from the previous
> line, or you have to mix tabs and spaces.

Yes. That I also swear sometimes about.

Usually I have my vim to use smart tabs what is okish for most cases.
They replace all 8 spaces on the begin of the line with one tab and
handles the rest transparent.

However, it might be better to switch to a expand tab setting. At least
for the line begin.

> My personal preference would be to switch to using spaces for all
> indentation, but I would be okay with using tabs for all indentation as
> well, so long as we avoid situations where the tabs need to be padded with
> spaces.

:-)

In any case. If we agree about a specific style, it should be configured
via vim modeline in all files. Currently we have the following:
   set shiftwidth=8 softtabstop=0 cindent cinoptions={1s:

It is nothing more wrong than a mismatch of that options with the
current used style. (Does someone here use different editor than vim
that does not respect such a setting?)

Regards
   Klaus
- -- 
Klaus Ethgen   http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-BEGIN PGP SIGNATURE-
Comment: Charset: ISO-8859-1

iQGzBAEBCgAdFiEEMWF28vh4/UMJJLQEpnwKsYAZ9qwFAlhef4IACgkQpnwKsYAZ
9qxUkgwAqO8UxIEqpwlXWCwjo7Rgn7AEpg0qkWbbzBSO5sl/W3sSVin2dByaHDGR
pI075ZWwo5+h/rZM9D68NGNhpEngxcRdxNqBE9Ed4y0vMx2DyOvwJDkAEDYDrDzs
QuWaXa9Jr4fpWyItKMRjV8Fn1SnciJuGmLrhecqaJcKNGKb0TK+miKTtNvFjT6XC
PRtLyCLZox7hsu2V2nm6yyFUuHCodbJR2ANT0scUuXjGLqEmj4PD0sklW9KcyAeJ
jqco08LcH6LLQ+PVAxCOT/yg42rGS94c3tTq3S+eWze4wAwYfI6cD20TIesgUTCj
zlpGCeuILaEVcPpIcrIShekitSRT3nM3niqmL1Ay28mWx0W1KCB080QJZiWeDbU2
zdy4s9r20e7iarYRgK7VX2S3Stssoi7YepmTeqtZtIlWhmHrdnJk/2WaviLynRXp
VXC82TkXcQl2M6jN37ubTMgPQ6zWrwnfUzKeO1GnMI3xIAMsfjRQHm5b7oNN1zt5
YUhSO2fj
=7nDq
-END PGP SIGNATURE-

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel
___
Geeqie-devel mailing list
Geeqie-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geeqie-devel