Hi!

Second week of GSOC has passed. This time refactoring effort was continued.

Most of the changes were connected to color selecting widgets in fill and stroke dialog. After discussion with Jon and Krzysztof, a new class design was implemented. GObject based classes are now derived from gtkmm widgets.

Class Inkscape::UI::SelectedColor represents state and actions triggered by color selecting widgets. It stores actual color, alpha value and some flags to differentiate between dragging and changing colors. It defines following signals: * signal_grabbed * signal_dragged * signal_released * signal_changed It behaves somewhat similarly to Gtk::Adjustment. It can be shared between multiple widgets. It is converted from ColorSelector class.

The users of color selecting widgets store a reference to SelectedColor and interact with it. This reference is passed to color selecting widget constructor. The reference to constructed widget is only needed during initial set-up and doesn't have to be tracked.

Widgets, whose state is held in SelectedColor are: * ColorEntry (separated from SPColorNotebook) * ColorICCSelector (formerly SPColorICCSelector) * ColorNotebook (formerly SPColorNotebook) * ColorScales (formerly SPColorScales) * ColorWheelSelector (formerly SPColorWheelSelector)

The widgets were moved from src/widgets directory to src/ui/widget. They are all in Inkscape::UI::Widget namespace.

I found a dead code in ColorNotebook. It implemented a pop-up menu for available card selection (RGB, HSV, CMYK...). I commented it out, leaving explanation in src/ui/widget/color-notebook.h. Hovewer, new design of ColorNotebook supports furure re-addition of this feature. Instead of using g_type_children and advanced introspection to populate the cards, a solution using abstract factory is used. The factory is defined in file src/ui/selected-color.h. Concrete factories are together with classes, whose objects they produce. Currently, the content of the tabs is set up in ColorNotebook constructor.

Known issue is application crash after multiple switches between fill types in stroke and fill dialog. I've collected core dump and will fix it up.

Please review the code. It is contained in branch lp:~penginsbacon/inkscape/svg-paints-support.

I would like to merge my code with experimental branch. Do you know if it's legal to merge to/from my development branch during GSOC?

The work on new pattern selector has started. I worked out the design and began the implementation. For some days, the widget will be developed separately in lp:~penginsbacon/+junk/tile-view.

Regards, Tomasz

On Mon, May 26, 2014 at 6:51 PM, Tomasz Boczkowski <penginsbacon@...400...> wrote:

Hi!

GSOC 2014 program started a week ago. I would like to describe, what I have done since then in my project.

The branch, I'm doing my development in is lp:inkscape/~penginsbacon/ inkscape/svg-paints-support.

Week 1:

1. The main objective was to refactor c-style UI widgets to c++ and gtkmm.

I managed to fully port SPColorSlider. It is now called Inkscape::UI::Widget::ColorSlider. The class works with both GTK2 and GTK3 libraries. Sadly, this partial task took me longer than I expected. Understanding gobject object model was quite difficult. 2) The topic of refactoring ColorSelector and related classes is being actively discussed with Jon A. Cruz at the mailing list. He mentioned possible problems with Gtkmm widgets that I was not aware of before. 3) Simple changes to SPPattern class are in progress. They consist in: a) moving c-like functions to class methods b) getting rid of GSList c) replacing gchar* by Glib::ustring d) converting *_set fields from guint to bool e) converting giuint fields to enums.

Tomasz

On 2-6-2014 2:21, Josh Andler wrote:

On Sun, Jun 1, 2014 at 4:33 PM, Tomasz Boczkowski <penginsbacon@...400... mailto:penginsbacon@...400...> wrote:

I would like to merge my code with experimental branch. Do you
know if it's
legal to merge to/from my development branch during GSOC?

Merging to your development branch is fine and will help you from diverging too much. However, merging to trunk should not happen until your mentor has given the approval and this generally waits to happen until after GSoC has finished.

If you have a nice portioned piece of work, I encourage you to propose that for merging (as you say, to the experimental branch). Having one large merge at the end of GSoC is not very nice, and sometimes that means it does not happen at all. From what I read about your project here on the mailinglist, it seems your work is very suited for small merges to exp branch along the way. It makes it much easier to disect what changes belong to what topic. I am convinced that trunk/experimental gets orders of magnitude more testing done than your branch, and small merges make it easier to find bugs if any do arise.

A disadvantage (at this moment) might be that experimental and trunk may diverge a lot, to the point where it becomes a burden to apply/backport bug fixes to both branches.

At the end of GSoC, Google wants you to submit an overall diff, so make sure you keep track of all your changes if some of your work gets merged in along the way.

Thank you for the updates on this btw, we all really appreciate it!

Indeed :)

-Johan

Great widget!

On Mon, 2014-06-09 at 01:04 +0200, Tomasz Boczkowski wrote:

Hi!

It's time to describe, what I did during the third week of GSOC. Actually I can show some results. At the beginning I have implemented new TileView widget. It is a container widget that shows it's items as rectangular tiles. They are divided into categories. It conforms to GTK MVC design and accepts Gtk::TreeModel as data source. It supports native scrolling, GTK styles, GTK versions 2 and 3. The video demonstration is shown in [1].

It looks like you are doing some great work!

Then I've integrated the widget with glyphs dialog. Dialog UI is not changed besides one "side-effect". Glyphs previews are now rendered with selected font.

Keep the side-effects coming!

Integration with symbols dialog patterns dialog are in progress.

As you progress with converting existing dialogs to the TileView widget and adding new dialogs that use the widget, have a look at what behaviors should be common to all the dialogs. For example, I would think that users would want to control the size of the tile (as is done in the Symbols dialog).

Note, I just updated the Symbols dialog to allow scaling of what is shown in each tile in addition to setting the tile size.

Tav