Re: Gnucash and css (was: Gtk3)

[John Ralls]

> On Jul 31, 2017, at 11:02 PM, Geert Janssens  
> wrote:
> 
> Bob,
> 
> As hinted in my previous message in the Gtk3 thread, I'd like to zoom in a 
> bit 
> on using Css for gnucash.
> 
> Let me start with a basic context for this discussion:
> * css in gtk (and hence gnucash) is used to define the visual representation 
> of the graphical user interface (defined through a set of "widgets").
> * for the best user experience the GUI should be consistent in style.
> * for standard widgets, gtk defines a default style (the Adwaita theme). 
> However users are free to configure a different style (or theme) for their 
> environment. Optionally each property in a theme can be overridden at a user 
> level by a user-defined css file.
> 
> So for standard widgets, gnucash usually doesn't have to do anything. This is 
> different for our custom widgets, such as the register and the SX overview 
> calendar (both based on a GtkLayout and doing custom drawing via cairo), or 
> widgets that define their own functional colors (like the transaction matcher 
> in the generic import code).
> 
> These widgets don't have a style by default, and hence we need to define it. 
> At the same time though, themes should be able to override whatever default 
> style we choose. This suggests our own styling should generally have a 
> FALLBACK priority rather than APPLICATION priority.
> 
> For any style property that is defined in the theme set by the user, this 
> will 
> then be used. If we define gnucash-only properties, these will most likely 
> not 
> appear in any theme and hence the values from our fallback will be used 
> instead.
> 
> The tricky part here is to define a fallback that goes well with whatever 
> theme the user has set for his environment. Take for example the colors used 
> in the SX overview calendar (white background/black text). These may not work 
> well with all themes so we should avoid to hard-code properties as much as 
> possible. I would instead propose to leverage the style classes as defined in 
> GtkStyleContext as much as possible [1]. Again for the SX overview calendar, 
> add a style class GTK_STYLE_CLASS_CALENDAR and then use whatever styling 
> information that gets set because of this [2]. Perhaps it requires more than 
> one style class to be added to get this to work completely. You can look for 
> examples in the Gtk source, like the use of the RUBBERBAND class in 
> gtktreeview.c [3]. I believe/hope when done carefully this can result in a 
> much more consistent GUI for gnucash and may reduce the amount of css we have 
> to maintain ourselves.
> 
> Then, specifically for the register we have an option that allows the user to 
> switch between the system level theme or our yellow/green theme. Building on 
> the above, the system level theme should be composed using the right style 
> classes. The yellow/green theme on the other hand is the first example I have 
> found that warrants a separate css definition. And this time with APPLICATION 
> priority because it's supposed to override theme specific styles. I would 
> define a new style class (something like "gnc-custom-colors"). And in css 
> write a section like this:
> 
> .gnc-custom-colors
> {
>color a: xyz;
>color b: abc;
>...
> }
> 
> What the exact properties should be will depend on the properties we combine 
> from the built-in style classes. If the built-in style classes for example 
> provide a property "separator-color", we should set this property also in the 
> .gnc-custom-colors class.
> 
> With this css in place, switching from default theme colors to our gnucash 
> yellow/green theme is a matter of adding/removing the gnc-custom-colors style 
> class from all register related widgets.
> 
> This same technique could be used for the label colors (negative numbers in 
> red). Only define an additional class ("negative-numbers-in-red" would do 
> fine) in which you explicitly set the red color to use and then add or remove 
> this class from all widgets that need to be able to display negative numbers 
> in red based on the user preference.
> 
> The last thing I'd like to bring up is the choice of property names. I read 
> in 
> your initial conversion to css you have chosen names very close to the 
> internally used variable names. While this is not wrong, I would prefer to 
> use 
> names that better describe the property's function.
> Let me explain with an example: the rows in the import matcher can have 3 
> colors (currently red, yellow or green). These colors support the state of 
> each line (unmatched, partially/potentially matched, matched? This may not be 
> the exact state meanings).
> The name of the class you have chosen describes which property gets changed 
> to 
> what. That's 1) redundant, 2) little informative and 3) restrictive. The 
> property itself already holds the information (hence redundant), it doesn't 
> tell the user why this property is changed (little informative) and will make 

Re: Gnome dropping Bugzilla

[John Ralls]

The problem with both YouTrack and Jira is that they're free for open source 
until they're not, and when they're not we're screwed. We've already had that 
experience with Uservoice, which was free when they rolled it out--and our 
account is grandfathered at least for now--but no new free accounts can be 
created.

Regards,
John Ralls

> On Aug 1, 2017, at 8:11 AM, Herbert Mühlburger  wrote:
> 
> What about using Jira?
> 
> -- 
> Herbert Mühlburger
> 
> Email: m...@muehlburger.at
> Web: https://blog.muehlburger.at
> 
> Am Mo, 31. Jul 2017, um 21:56, schrieb John Ralls:
>> As I think everyone knows, we use bugzilla.gnome.org
>>  for bug and enhancement tracking.
>> 
>> There's a new banner on every BZ page saying that Gnome plans to drop
>> Bugzilla and the CGit repository browser, replacing them with Gitlab.
>> 
>> That isn't going to work for us. I don't think it's going to work for
>> Gnome, either, because a bug tracker that can't do word searches isn't
>> capable of managing thousands of open bugs
>> (https://docs.gitlab.com/ee/user/search/index.html
>> ), but that's not our
>> problem. Our problem is that with our repository not at git.gnome.org
>>  there won't be a GnuCash project in GitLab and so
>> there won't be a bug tracker. We'll need to get a new one.
>> 
>> Since we do mirror our repos to Github it is a viable option and it does
>> at least have better search facilities (or at least they're better
>> documented) that Gitlab, see
>> https://help.github.com/articles/searching-issues-and-pull-requests/
>> .
>> It lacks many other features of BZ: All categorization and status
>> tracking is by "labels" and they have no inherent hierarchy or
>> organization.
>> 
>> So I think we're going to need our own bugtracker.
>> 
>> BZ is Free and it should be fairly simple to get the Gnome bug team to
>> ship us a dump of our part of the database and set up a redirect once we
>> have our instance up and running. The web display on whatever it is that
>> GNU uses (e.g. https://savannah.gnu.org/bugs/?group=guile
>> ) but I dislike that it is
>> operated entirely by email. Mantis is popular but is managed by a bug
>> list. It's filterable to a fare-thee-well but lacks controlled
>> vocabularies on many of its fields so managing a large number of open
>> bugs is a PITA. RT (used by perl's CPAN) is also completely email driven.
>> Trac is a little less rudimentary than Github--it at least has categories
>> and status fields, but I don't believe it's capable of managing thousands
>> of bugs. SourceForge's built in tracker is on the same level as Github's
>> with less capable search.
>> 
>> There's a sort of conceptual timeline on the DevelopmentInfrastructure
>> page but nothing concrete. I'd guess we have at least several months and
>> perhaps as long as a year to have a replacement up and running.
>> 
>> Regards,
>> John Ralls
>> ___
>> gnucash-devel mailing list
>> gnucash-devel@gnucash.org
>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Gnome dropping Bugzilla

[John Ralls]

The problem with both YouTrack and Jira is that they're free for open source 
until they're not, and when they're not we're screwed. We've already had that 
experience with Uservoice, which was free when they rolled it out--and our 
account is grandfathered at least for now--but no new free accounts can be 
created.

Regards,
John Ralls

> On Aug 1, 2017, at 8:11 AM, Herbert Mühlburger  wrote:
> 
> What about using Jira?
> 
> -- 
> Herbert Mühlburger
> 
> Email: m...@muehlburger.at
> Web: https://blog.muehlburger.at
> 
> Am Mo, 31. Jul 2017, um 21:56, schrieb John Ralls:
>> As I think everyone knows, we use bugzilla.gnome.org
>>  for bug and enhancement tracking.
>> 
>> There's a new banner on every BZ page saying that Gnome plans to drop
>> Bugzilla and the CGit repository browser, replacing them with Gitlab.
>> 
>> That isn't going to work for us. I don't think it's going to work for
>> Gnome, either, because a bug tracker that can't do word searches isn't
>> capable of managing thousands of open bugs
>> (https://docs.gitlab.com/ee/user/search/index.html
>> ), but that's not our
>> problem. Our problem is that with our repository not at git.gnome.org
>>  there won't be a GnuCash project in GitLab and so
>> there won't be a bug tracker. We'll need to get a new one.
>> 
>> Since we do mirror our repos to Github it is a viable option and it does
>> at least have better search facilities (or at least they're better
>> documented) that Gitlab, see
>> https://help.github.com/articles/searching-issues-and-pull-requests/
>> .
>> It lacks many other features of BZ: All categorization and status
>> tracking is by "labels" and they have no inherent hierarchy or
>> organization.
>> 
>> So I think we're going to need our own bugtracker.
>> 
>> BZ is Free and it should be fairly simple to get the Gnome bug team to
>> ship us a dump of our part of the database and set up a redirect once we
>> have our instance up and running. The web display on whatever it is that
>> GNU uses (e.g. https://savannah.gnu.org/bugs/?group=guile
>> ) but I dislike that it is
>> operated entirely by email. Mantis is popular but is managed by a bug
>> list. It's filterable to a fare-thee-well but lacks controlled
>> vocabularies on many of its fields so managing a large number of open
>> bugs is a PITA. RT (used by perl's CPAN) is also completely email driven.
>> Trac is a little less rudimentary than Github--it at least has categories
>> and status fields, but I don't believe it's capable of managing thousands
>> of bugs. SourceForge's built in tracker is on the same level as Github's
>> with less capable search.
>> 
>> There's a sort of conceptual timeline on the DevelopmentInfrastructure
>> page but nothing concrete. I'd guess we have at least several months and
>> perhaps as long as a year to have a replacement up and running.
>> 
>> Regards,
>> John Ralls
>> ___
>> gnucash-devel mailing list
>> gnucash-devel@gnucash.org
>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Gtk3

[Robert Fewell]

I had come across those resource files but was not sure how to implement so
stuck to what I could figure out and it also allowed me to change the css
file without having to rebuild as I understood it.

I have also created a pull request for the register changes / fixes that I
had done without any of the colour updates that I was playing with, need to
digest your other email while I do my monthly VM system update.

Bob

On 31 July 2017 at 20:52, Geert Janssens  wrote:

> On vrijdag 28 juli 2017 18:07:41 CEST Robert Fewell wrote:
> > All, just for information I have been tinkering in the register code,
> > mainly on the appearance, hopefully have some thing to pull after the
> > weekend.
> > What I have done so far is get the header alignment working, added a css
> > class to set the background, text and border colours.Changed the sheet
> cell
> > alignment so all the borders are visible, added a css class for the
> > GncItemEdit with the border colour used for the cursor and made it fit
> the
> > cell.
> >
> > Question, all of the css stuff is stored in the application gnucash.css
> > file but if that is missing should there be hard coded defaults so the
> > register is still readable or should that file missing stop the
> application
> > being loaded.
> >
> > Bob
>
> Bob,
>
> I'm back in town as of today and I'm slowly processing my backlog.
>
> I see you have been busy while I was away. Great!
>
> To answer your question: I would suggest to use the same approach as gtk
> itself does. As the css is critical for the proper display of some of our
> custom widgets, it should be included in the form of a GResource [1]
> directly
> into the binary instead of a file on disk that may or may not be present.
> Gtk
> does this for example for its (default) Adwaita theme. More details may be
> found directlyin the gtk sources.
>
> Your css work so far and this mail made me think some more about the css
> concept for gnucash and perhaps we need to refine our initial idea. I'll
> post
> those in a separate mail though.
>
> Geert
>
>
> [1] https://developer.gnome.org/gio/stable/GResource.html
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Gnome dropping Bugzilla

[Adonay Felipe Nogueira]

There is also Debbugs ([[https://en.wikipedia.org/wiki/Debbugs]]), and
also GNU Savane (the software which is used to host Puszcza and GNU
Savannah) ([[https://savannah.gnu.org/projects/administration/]]).

We could also make use of GNU Savannah itself, no need to host our own,
and no need to go entirely to GitHub, while in any case we would still
keep compatibility with Git, and also have other stuff that GitHub
doesn't provide by default.

-- 
- [[https://libreplanet.org/wiki/User:Adfeno]]
- Palestrante e consultor sobre /software/ livre (não confundir com
  gratis).
- "WhatsApp"? Ele não é livre, por isso não uso. Iguais a ele prefiro
  GNU Ring, ou Tox. Quer outras formas de contato? Adicione o vCard
  que está no endereço acima aos teus contatos.
- Pretende me enviar arquivos .doc, .ppt, .cdr, ou .mp3? OK, eu
  aceito, mas não repasso. Entrego apenas em formatos favoráveis ao
  /software/ livre. Favor entrar em contato em caso de dúvida.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Missing invoice in Business->Customer->Find Invoice

[Eric Wheeler]

Hello all,

We have an invoice that cannot be found in the  "Business->Customer->Find 
Invoice" dialog, neither by invoice number nor by customer name.  

However, both the post and payment do show up in "Accounts Receivable" and 
I can find the invoice if I do Reports->Business->Customer report.

So, interestingly, the invoice appears to be there but the "Find Invoice" 
dialog can't find it.

What might this indicate?


--
Eric Wheeler
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel