Association Subscribers Manager and Open source stuffs

To content | To menu | To search

Tag - C

Entries feed - Comments feed

Saturday 30 August 2008

slack-get user interface: step 1, how I see the futur

By Arnaud Dupuis on Saturday 30 August 2008, 00:43 - slack-get

Hi,

as I already said I am currently developping the C++ API of slack-get. I also wrote that I am concentrating on usefull part of the API, skipping the generative parts that are not absolutly required at the moment. So in parallel to this development, I made some tests for the graphical user interface. I came up with the conclusion that there is 2 different way to use slack-get :

  1. Keep a Slackware box up-to-date by installing security fixes and Slackware patches
  2. Keep a box up-to-date, upgrade and install packages (but not patches)
So, considering that I decided to come with 2 different GUI : a dock application to tell users that there is patches available and the full graphical client (like the previous slack-get GUI).
I starts coding a little widget (Slackget::QSimpleUpdate). This one looks like that :


I am interested in any opinion/advice/suggestion concerning this. The code of this proof-of-concept is available on the SVN (in trunk/src/QSimpleUpdate/). I made it themable thanks to Qt4 support of CSS.
So far, I think it is a quite fine dock application. I wanted it to be simple to get working, and I also wanted that this widget is able to display enough informations.

That's all for today :)

Arnaud Dupuis

no comment no trackback

Wednesday 27 August 2008

First parts of the C++ API

By Arnaud Dupuis on Wednesday 27 August 2008, 00:29 - C++

Hi,

I uploaded on the SVN repository the first part of the slack-get C++ API.

I am coding this one to be as close as possible to the Perl one. So the first two classes uploaded are, of course, Slackget::Package and Slackget::PackageList. As you can see I am using the Slackget:: namespace in order to identify slack-get's classes.

As usual, the documentation and all doxygen needed files are already on the SVN too.

I am focusing on usability and stable features for this C++ API. This means that, in a first time, I will not translate all features. All classes that will fall in those exceptions will be adequatly documented.

My goal with this API is to start coding the graphical user interface as quickly as possible.

Arnaud Dupuis

no comment one trackback

Saturday 2 February 2008

SGNCC - Slack-Get Naming Convention Compliant : the new slack-get's naming convention document

By Arnaud Dupuis on Saturday 2 February 2008, 17:35 - slack-get

Document purpose :

The purpose of this document is to "standardize" slack-get development by imposing a naming convention for both (but not only) : slack-get clients, sg_daemon, all Perl modules and the C++ library.
This include of course, all plug-in which can be released in the futur.

Vocabulary :

In the future, we will refers to the slack-get naming convention as :
SGNC: for Slack-Get Naming Convention.

Additionally, we will refers to SGNC compliant code as SGNCC (SGNC Compliant).

Scope of the SGNC :

All the code released under the "slack-get development team" label must be SGNC compliant (SGNCC).
More generally, all code released and packaged with slack-get must be (and will be) SGNCC.
The SGNC apply to all API visible method names. Every methods in a class or bundle must be SGNCC. By extension to this principle all methods in the sg_daemon, slack-get and the upcoming slack-get GUI have to be SGNCC.
All script released and packaged with slack-get should be SGNCC too. But in order to not slow down some developments it is acceptable to keep not SGNCC code in the branch/ SVN tree. If released with slack-get, this code will be optional at building and installation time. It will also be released in a different package.

Rules of SGNC :

We refer to functions and methods as the same generic term of "method".
The SGNC consist in the following 3 simple programing rules :
  1. a method name consist of lower case, English words where space are replaced with underscores ;
  2. if the method name is conflicting with Perl or C++ built-in function or language syntax, change the case of the first letter to upper  case.
  3. if a conflict was solved according to rule 2), and if the name conflicts with only one of the supported languages (Perl and C++), add a wrapper method around the renamed one, in order to comply with the rule 1).


The slack-get development team

no comment