Reset Initial window configuration

Lately I’ve been resetting to the initial window configuration lot of times to try to trigger the dock dialogs mangling discussed in other thread.
I’ve realized two things:

  1. The numbers of the initial configuration seems to be custom and not calculated.
  2. More things than the reset of the initial window configuration is done there.

Here the code:

void App::reset_initial_window_configuration() { synfigapp::Main::settings().set_value("dock.dialog.1.comp_selector","1"); synfigapp::Main::settings().set_value("dock.dialog.1.contents","navigator - info pal_edit pal_browse - tool_options history canvases - layers groups"); synfigapp::Main::settings().set_value("dock.dialog.1.contents_size","225 167 207"); synfigapp::Main::settings().set_value("dock.dialog.1.pos","1057 32"); synfigapp::Main::settings().set_value("dock.dialog.1.size","208 1174"); synfigapp::Main::settings().set_value("dock.dialog.2.comp_selector","0"); synfigapp::Main::settings().set_value("dock.dialog.2.contents","params children keyframes | timetrack curves meta_data"); synfigapp::Main::settings().set_value("dock.dialog.2.contents_size","263"); synfigapp::Main::settings().set_value("dock.dialog.2.pos","0 973"); synfigapp::Main::settings().set_value("dock.dialog.2.size","1045 235"); synfigapp::Main::settings().set_value("pref.distance_system","pt"); synfigapp::Main::settings().set_value("pref.use_colorspace_gamma","1"); #ifdef SINGLE_THREADED synfigapp::Main::settings().set_value("pref.single_threaded","1"); #endif synfigapp::Main::settings().set_value("pref.restrict_radius_ducks","0"); synfigapp::Main::settings().set_value("pref.resize_imported_images","0"); synfigapp::Main::settings().set_value("pref.custom_filename_prefix",DEFAULT_FILENAME_PREFIX); synfigapp::Main::settings().set_value("pref.preferred_x_size","480"); synfigapp::Main::settings().set_value("pref.preferred_y_size","270"); synfigapp::Main::settings().set_value("pref.predefined_size",DEFAULT_PREDEFINED_SIZE); synfigapp::Main::settings().set_value("pref.preferred_fps","24.0"); synfigapp::Main::settings().set_value("pref.predefined_fps",DEFAULT_PREDEFINED_FPS); synfigapp::Main::settings().set_value("window.toolbox.pos","4 4"); }

I propose:

a) Calculate the values of the windows position and sizes according to the screen geometry that the user has at the moment of calling. It will be much more user friendly for people with dual monitor or with other screen resolutions.
b) Separate the default settings to other function so the user can just reset the windows position and configuration and optionally reset all the preferences too.

This makes me think on create a better preferences system than includes hotkeys, and more preferences that are just hard coded now. But that will be for the next release.

The idea of this post is to know what you people think on the ideas a) and b) to start to work on them for the next release.

Thanks
-G

I agree with your proposals, except that maybe we should do a) for this release, not the next.

For me, scale factor used to resize the panels to fit my screen. I use a laptop with a small monitor, so the raw default settings are bad for me. (see screenshots)
noscalefactor.png
scalefactor.png

It’s difficult to find a solution that works for everyone. For example, while I have a dual display setup, only one screen has stylus input, and that’s where I want all my Synfig windows displayed. For the most part this works, but a couple of the dialogs insist on showing up in the top left hand corner, no matter what I do to try and re-educate them…

Same here :confused:
-G

You got my support for both separated screen/other settings.

Thanks for the support nikitakit, pixelgeek and rylleman.

Yes I think so. But before start coding anything I would like to agree a layout of the panels.
I’ll post here some proposals later.
Thanks
-G

Ok, the idea I have is this:
When the user ask to place the windows in the default position and configuration the program will:

  1. Determine the numbers default Display: static Glib::RefPtr Gdk::Display::get_default ()
  2. Determine the default screen for the default Display: Glib::RefPtr Gdk::Display::get_default_screen ()
  3. Determine the primary monitor of that screen: int Gdk::Screen::get_primary_monitor () const. As this member is only available since gtkmm 2.20 I will use the monitor number 0 as primary.
  4. Determine the geomtry of the primary monitor: void Gdk::Screen::get_monitor_geometry (int monitor_num, Rectangle& dest) const
    Once I have the rectangle of the monitor I can think on place the windows properly.
    So, here are the questions:
    There are two panels, a toolbox and a initial instance:
    a) Vertical panel on the right and toolbox on the left or toolbox on the right and vertical panel on the left?
    b) Should the horizontal panel take all the monitor width? or should the vertical panel take all the monitor height?
    c) What’s your preference for the layout of panels?

Here are mine:


As you can see my preferences are:
Disposition:
Horizontal Panel: Layer Children | Keyframes Params | Timetrack Curves
Vertical Panel: Navigator Pallete - Tool options Info Canvas Browser History Groups Meta
Where the relative sizes are:
Horizontal Panel: 20%|30%|60%
Vertical Panel: 30% - 70%

Horizontal panel layout:
Position: Bottom left
Size: width=100% monitor_width; height= 25% monitor_height
Vertical panel layout:
Position: Top right
Size: width=20%monitor_width; height=75% monitor_height
Toolbox layout:
Position: Top left

Please add your preferences here to try to satisfy to most of the people. Try to use the same template that I used. Just position the windows at your prefernce and then calculate (an aproximation) the sizes, position and relative position for each panel.
Thank you very much for your time.
-G

Just a question; is it possible to have “minimal mode”? The purpose of that would be to have enough space for drawing/animating without sending the canvas to a new desktop and switching between em (gets annoying sometimes).

Doesn’t matter how you decide to implement it, but it could be pretty useful and might speed up production. But it shouldn’t have “docks” (layer docks, tool docks, etc.) otherwise the purpose is destroyed. Instead, to access the sliding layer, tools, navigators, keyframes, etc. all you’d require are buttons like 1, 2, 3, etc. It’s just sorta slide in and back out again. Well just a suggestion.