Re: pspp-error msgs

[Ben Pfaff]

You're right, that's better.  I made the suggested change.

On Tue, Jan 12, 2016 at 12:53:50PM +0200, Elias Estatistics wrote:
> Dear Devs,
> 
> a suggestion on editing error msg:
> 
> from
> #: src/language/data-io/list.c:236
> "The first case (%ld) to list is less than 1.  The value is being reset to
> 1."
> 
> to
> 
> "The first case (%ld) to list is numbered less than 1.  The value is being
> reset to 1."
> 
> sincerely,
> elias "estatisticsEU" tsolis
> 
> 
> 
> On 09/01/2016 07:00 μμ, address@hidden wrote:
> >Send pspp-dev mailing list submissions to
> >     address@hidden
> >
> >To subscribe or unsubscribe via the World Wide Web, visit
> >     https://lists.gnu.org/mailman/listinfo/pspp-dev
> >or, via email, send a message with subject or body 'help' to
> >     address@hidden
> >
> >You can reach the person managing the list at
> >     address@hidden
> >
> >When replying, please edit your Subject line so it is more specific
> >than "Re: Contents of pspp-dev digest..."
> >
> >
> >Today's Topics:
> >
> >    1. Re: Sheet replacement discussions (Friedrich Beckmann)
> >    2. Re: Keywords required for the software center (John Darrington)
> >    3. Re: Sheet replacement discussions (John Darrington)
> >
> >
> >----------------------------------------------------------------------
> >
> >Message: 1
> >Date: Fri, 8 Jan 2016 20:25:37 +0100
> >From: Friedrich Beckmann <address@hidden>
> >To: John Darrington <address@hidden>
> >Cc: address@hidden
> >Subject: Re: Sheet replacement discussions
> >Message-ID: <address@hidden>
> >Content-Type: text/plain; charset="utf-8"
> >
> >
> >>>     I remember that we both came to the same conclusion that the column 
> >>> width should
> >>>     be derived from the rendering result of the column header width as 
> >>> default width plus
> >>>     manual changes via mouse. Those manual adjustments should be possible 
> >>> per
> >>>     column.
> >>Yes.  The only way I can think of implementing this is to have a hash table 
> >>of
> >>all the columns which have manual overrides.  Potentially the hash table 
> >>could
> >>grow arbitrarily, but users will not make manual changes to thousands of 
> >>columns
> >>so in practise that need not be a problem.
> >Nice idea.
> >
> >>? In that case, perhaps we can use
> >>the GtkTreeModel.
> >>
> >>The only problem I see now, is that there needs to be a method to query the 
> >>number of
> >>columns.  GtkTreeModel assumes that all rows have variable numbers of 
> >>columns whereas
> >>we will require it to be fixed.
> >I don?t think that is right. The call is gtk_tree_model_get_n_colums 
> >(treemodel).
> >
> >See: https://github.com/fredowski/lazytree/blob/master/lazytreeview.c#L381
> >
> >>>>Finally I don't think it appropriate that the text displayed in the 
> >>>>row/column
> >>>>headers should be part of the data model - at least they should not be 
> >>>>part of the
> >>>>*same* data model which contains the contents of the cells.  The column 
> >>>>titles
> >>>>are metadata - not "real" data and the two should not be treated 
> >>>>identically.
> >>>     Yes, there are good arguments for that. On the other hand we a have a 
> >>> strong linkage
> >>>     between column headers and the data in the column. If there is that 
> >>> strong linkage, then it might be safer
> >>>     to have the strict relation also in the data model. For example it 
> >>> should not be possible
> >>>     by design to have a different number of columns when you ask the body 
> >>> data model and the
> >>>     column header model. If a variable is removed, then the data and the 
> >>> header is removed because
> >>>     the belong together, right? Maybe it is easier to think of different 
> >>> interfaces to one data model.
> >>>     Then the data model would have a GtkTreeModel interface for the body 
> >>> data and a ColumnHeader Interface
> >>>     for the column header data.
> >>Well there is strongish linkage in some instances.  For example, the column
> >>headers of the variable sheet are pretty strongly linked (but that might 
> >>change
> >>if and when we support "variable attributes" in the var sheet).
> >>The linkage between the column headers in the data sheet is less strong - it
> >>is linked indirectly through the dataset's dictionary.
> >Maybe I just look at the sheet replacement more independent from pspp. I see 
> >a
> >data store which provides the data via the GtkTreeModel Interface. Our new 
> >view
> >can optionally display a row of this data as column headers which are 
> >rendered in
> >a special way (not scrolling). It can also optionally display a column as 
> >row headers. Therefore
> >you tell the view which row should be used as column header and which column 
> >should
> >be used as row header data. By design there could not be a different number 
> >of
> >column headers and columns for the data.
> >
> >This would be different from the way GtkTreeView does it. But in GtkTreeView 
> >there
> >is a complex relation that you manually select which column in the data 
> >store provides
> >which attribute of the cell_renderer, e.g. the displayed column 8 takes the 
> >content of
> >column 3 in the data store as ?text? attribute and the content of column 51 
> >as background
> >color. Each column in the view uses possibly several columns in the data 
> >store for attributes.
> >It is also possible that there are columns in the store which are not used 
> >in the view at all.
> >This allows of course that you can have different views of the same store.
> >
> >After writing these two paragraphs I noticed that there is a good reason not 
> >access the column
> >headers as a normal row. If we ever want to render a different type than 
> >G_TYPE_STRING, then
> >the view would probably not know how to render a column header row if there 
> >is a
> >G_TYPE_OBJECT inside? And in GListStore the type of each column is fixed, 
> >e.g.
> >row 1 col 5 cannot provide a different type than row 15 col 5. So our view 
> >could not
> >work with GListStore if we ever render other types than G_TYPE_STRING and 
> >want a column
> >header.
> >
> >>And the linkage between
> >>the row headers and the data in the data sheet is non-existant - regardless 
> >>of
> >>how you reorder the data, the row headers should still read 0, 1, 2, 3, ?
> >You can argue that the row headers are strictly generated without any
> >information relating to the cases. If we see it as in Excel with no/never
> >any relation to the data, then it would be part of the view, right?
> >
> >Fritz
> >
> >
> >
> >
> >
> >
> >-------------- next part --------------
> >An HTML attachment was scrubbed...
> >URL: 
> ><http://lists.gnu.org/archive/html/pspp-dev/attachments/20160108/e84e76ce/attachment.html>
> >-------------- next part --------------
> >A non-text attachment was scrubbed...
> >Name: signature.asc
> >Type: application/pgp-signature
> >Size: 495 bytes
> >Desc: Message signed with OpenPGP using GPGMail
> >URL: 
> ><http://lists.gnu.org/archive/html/pspp-dev/attachments/20160108/e84e76ce/attachment.pgp>
> >
> >------------------------------
> >
> >Message: 2
> >Date: Sat, 9 Jan 2016 10:13:23 +0100
> >From: John Darrington <address@hidden>
> >To: "Richard Hughes (semi-automated)" <address@hidden>
> >Cc: address@hidden
> >Subject: Re: Keywords required for the software center
> >Message-ID: <address@hidden>
> >Content-Type: text/plain; charset="us-ascii"
> >
> >Thanks for the information.
> >
> >We will look into this.
> >
> >For your records a better email address to use in the future is 
> >address@hidden instead
> >of the users' email addres.
> >
> >J'
> >
> >On Fri, Jan 08, 2016 at 04:08:28AM -0800, Richard Hughes (semi-automated) 
> >wrote:
> >      Hi!
> >      First, apologies for the direct email. I'm emailing you directly as 
> > you've been listed as the update contact in one or more AppData files. In 
> > the software center we allow the user to search using case-insensitive 
> > keywords, for instance searching for 'excel' could match Libreoffice Calc 
> > or many other free software spreadsheet applications. At the moment we use 
> > the translated keywords set in the desktop file, any extra <keyword> 
> > entries in the AppData file, and then fall back to generating tokens from 
> > the name, summary and description using a heuristic. This heuristic works 
> > most of the time, but a human can often do much better when we know what 
> > the most important words are. I've noticed your application does not have 
> > any manually set keywords and thought I should bring this to your attention.
> >      So, what do I want you to do? Basically, I would like you to add some 
> > keywords in the pspp.desktop file or the pspp.appdata.xml AppData file. If 
> > you want the keywords to be used by GNOME Shell as well (which you probably 
> > do), the best place to put any search terms is in the keywords section [1] 
> > of the desktop file. This can also be marked as translatable so non-English 
> > users can search in their own language. This would looks something like 
> > Keywords=3D;printer; (remember the trailing semicolon!)
> >      The alternative is to put the keywords in the AppData file so that 
> > they are only used by the software center and not the desktop shell. You 
> > can of course combine putting keywords in both places. The AppData keywords 
> > can also be translated, and would look like this:
> >      <keywords>
> >      <keyword>3D</keyword>
> >      <keyword>printer</keyword>
> >      </keywords>
> >      Of course, you don't have to do a release with this fix straight away, 
> > and if you have a stable branch it would be a good thing to backport this 
> > as well if it does not add translated strings or you have no string freeze 
> > policy. Nothing bad will happen if you ignore this email, but please be 
> > aware that matches from keywords are ordered higher in the search results 
> > than other partial matches from the name or summary. You also don't have to 
> > add keywords that are the same as the application name or package name, as 
> > these are automatically added as case insensitive search tokens.
> >      When you've changed the file(s) and committed, please email me back 
> > and I'll mark your application as completed. If you don't want to hear from 
> > me ever again just edit the <update_contact> in the AppData file and change 
> > it to somebody else. I'm not planning on emailing more than once every 6 
> > months, so don't worry about me spamming you with even more work to do. If 
> > you don't add the keywords then your application will still be visible in 
> > the various software centers, but it may be harder to find.
> >      Thanks,
> >      Richard
> >      [1] 
> > http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#recognized-keys
> >      _______________________________________________
> >      Pspp-users mailing list
> >      address@hidden
> >      https://lists.gnu.org/mailman/listinfo/pspp-users
> >
> 
> 
> _______________________________________________
> pspp-dev mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/pspp-dev